Niklaus Wirth was right and that is a problem - <AUTHOR> https://bowero.nl/blog/2020/07/31/niklaus-wirth-was-right-and-that-is-a-problem/ <comment><USER5> The referenced AppSignal post about 13,000 dependencies for a todo list is conflating dependencies required for the build tooling with dependencies that are actually bundled in to the web app.

It's also hilarious that right after referencing the dependency problem in the JS ecosystem the OP then goes and advocates splitting up your library into a bunch of mini libraries. That's exactly how we got into this mess in the first place.

Also, computer speed has definitely gotten faster. There was a time period during which this was not the case, but particularly the switch to SSDs resulted in a massive jump in computer responsiveness. (The previous jump happened when we no longer needed to wait for dial up to establish a connection)

<comment><USER6> I agree with the core point of the article, but I agree with your points as well. The conclusion of the article is definitely wrong.

I recently buddied up with someone who has a CS degree to try and make a desktop app, as a side project. I asked if he is familiar with MariaDB and whether or not he's used C++ ODBC.

Our discussion quickly turned into choosing libraries / existing code. He uses Spring and Hibernate and was bewildered by the concept of tying columns to application variables "manually". After I told him I have some CentOS servers where we could put a shared database, he bought a Windows Server because he "needs a GUI". He added, "Ideally, after it's setup, we'll never even have to remote in to it." For the actual desktop application, he wants to use Electron.

It seems there are two distinct branches of computing emerging - one where performance matters, and one where it doesn't. Performance will always matter in places like the stock market or on IBM mainframes. In the consumer-facing world, All that seems to matter is perceived performance. Slack and Discord seem fast, when you watch how quickly a new message pops up on your laptop screen after you sent it on your phone. They seem egregiously slow when you open up task manager and see just how much overhead the chromium-based engine adds -- but most people won't care.

Applications made for "consumers" tend to be made like a cheap car - <USER2> are cut, the end result isn't pretty, but things in the category are what makes up 90% of ordinary use cases. Slack isn't meant to be open on your work machine while you're compiling code in the same way a Prius isn't meant to chauffeur top-level executives. It doesn't mean that the Prius is bad or unimportant - it will do far more for more people than the entire lineup of many luxury car brands.

But I am damn sure that I'd rather be engineering a Bentley than a Prius.

Edit: In the metaphor, luxury and performance are sacrificed, not efficiency. I probably should've used Fiat Chrysler, but unlike Fiat Chrysler, consumer- facing software has its place. I just don't enjoy working on it myself.

<comment><USER7> > but most people won't care.

Charity Majors said about reliability: "Nines don't matter if users aren't happy."

I'd propose an alternative view here: "Bloat doesn't matter if users are happy."

<comment><USER8> Users are happy until they saw better :)

Today bloat doesn't matter, tomorrow you're are a fat dinosaur

<comment><USER7> Sure, but... that confirms this view.

<comment><USER8> This view is more akin to working class parents telling their children to become a builder because "people have always been building".

You should not outsource your main product. And if your product is a chat application that is supposed to be fast and always on the background, then you're outsourcing your main area of expertise.

</comment></comment></comment></comment></comment></comment><comment><USER9> I was expecting Moore's Law to give us a renaissance in algorithmic thinking, but The Cloud has shown me I was wrong. First, we're going to have to fully explore Amdahl's law.

Eventually every problem goes to logn time, best case. The logn factor shows up over and over, from constraints on on-chip cache to communication delays to adding numbers of arbitrary size. We make a lot of problems look like they are O(1) until the moment they don't fit into one machine word, one cache line, one cache, into memory, onto one machine, onto one switch, into one rack, into one room, into one data center, into one zip code, onto one planet.

If we can't solve the problem for all customers, we dodge, pick a smaller more lucrative problem that only works for a subset of our customers, and then pretend like we can solve any problem we want to, we just didn't want to solve that problem.

<comment><USER10> Herb Sutter had a wonderful talk on constant factor plague. As much as I like clojure and similar convenience and algorithmic beauty.. I can appreciate the devil-is-in-the-details much more since this video (forgot the title sorry)

<comment><USER11> I went looking for the talk and all I could find was this paper: [https://www.researchgate.net/publication/337590358_Inflation...](https://www.researchgate.net/publication/337590358_Inflationary_Constant_Factors_and_Why_Python_is_Faster_Than_C)

I'd like to watch the actual talk. Hope you could try remembering the name.

<comment><USER10> maybe this one [https://www.youtube.com/watch?v=L7zSU9HI-6I](https://www.youtube.com/watch?v=L7zSU9HI-6I) .. damn memory (sic)

</comment></comment></comment></comment><comment><USER12> This article is the problem.

It's the same freaking fallacy I see again and again on here - It's simple, easy to understand, and dead fucking wrong.

The vast majority of the complexity you're dealing with in modern computing comes from three sources. In the order of impact

1\. Networking. It turns out there are real and hard limits on how fast we can pass data around over copper wires. Fiber is better, but you just literally cannot move faster than light, and latency is a big deal when the items you're accessing and changing live somewhere else (and basically everything of _value_ does live somewhere else, or thinks you are "somewhere else").

2\. Security. This is a direct consequence of number 1. When everything is connected, _everything is connected_. You can't just lock the lab door and call it a day now.

3\. Compatibility. This is a direct consequence of both 1 and 2. Value is a consequence of compatibility (this is why a good chunk of you on here still support IE, even though you don't want to). We have more devices, of more kinds than ever before. We have more people, with more use cases than ever before. There is value in being as compatible as possible with all those devices and people. All those devices are connected in ways designed to keep them compatible, but also secure. It turns out this is not an easy task.

If you'd like to go wank off over how fast your pre-network, unsecured, unsupported, inaccessible and manually configured systems are, be my guest (oh, and I hope you read english...). The rest of us will continue to produce items of value.

<comment><USER13> No, it's the other way around. Advances in computer hardware have allowed the use more inefficient programming languages allowing more inexperienced and unskilled programmers to create programs leading to more resource hungry programs. When there are little resource constraints the only real constraint becomes developer time.

I don't see how having IDEs implemented in browsers has anything to do with security, the speed of light or compatibility. It's just the lack of constraints allowed by advances in computer hardware.

Most software is written with no performance considerations in mind at first and the performance issues are addressed only when they become visible. However, if there is abundant memory available, why bother?

<comment><USER14> > I don't see how having IDEs implemented in browsers has anything to do with > security, the speed of light or compatibility. It's just the lack of > constraints allowed by advances in computer hardware.

This isn't a compatibility issue? We've seen about 8-16 branches of the write- once, run-everywhere tree over the past 25 years, I'm not sure how that isn't seen as a constraint on programmers. JWT, Swing, Web, Cordova, QT, React/<web front-end> Native, Xamarin, Electron, Flutter and even quirky ones like Toga have all attempted to solve this problem. The only unifying thread has been that managers follow greedy algorithms and choose the lowest common denominator platforms as possible. QT, the Java tools and Xamarin at least can't be lumped into the inefficient language bucket, though the UX is just awful. Other than hardware drivers, it's hard to think of a clearer example of compatibility constraints.

<comment><USER15> > JWT, Swing, Web, Cordova, React/<web front-end> Native, Xamarin, Electron, > Flutter and even quirky ones like Toga have all attempted to solve this > problem, and

... and for the most part they have. You can write your app right now and the only thing you need to worry about is screen size. If you use bootstrap, even this is mostly solved. Your app is accessible on Windows, Linux and Mac; Chromebooks and Tablets; iPhones, Android and even the one Symbian user. Of course it's not perfect yet, there _are_ edge cases and you cannot do everything, but let's not act like things have gotten worse.

> The only unifying thread has been that managers follow greedy algorithms and > choose the lowest common denominator platforms as possible.

Yes, I agree. But for nearly every use case, it's good enough. Take HN as an example: Does it need anything more?

Of course, if you need access to specific hardware, you'll have to go deeper. But if you do not, it would simply be you taking the lowest common denominator. And I'd argue that the framework probably did a more thorough search.

<comment><USER14> I basically agree, with the caveat that I'd still prefer a world where our write-once-run-everywhere lowest common denominator at least required native widgets and an ability to integrate new platform-specific capabilities at the expense of writing a small amount of native code, rather than barfing up web UI/UX at users (e.g. the execrable MS Teams).

</comment></comment></comment></comment></comment><comment><USER16> The argument got rather confused at the end. The todo list has 13,000 dependencies precisely because the NPM community follows the advice here to create many small libraries. So is that supposed to be a good or bad thing?

<comment><USER17> Yeah...not sure where they were going there. The many small libraries becomes a problem when said libs go out of sync, i mean that is where dependency hell bites.

<comment><USER18> After 40 years I've decided that dependencies are the root all evil. There is something to be said for curated libraries and frameworks.

</comment></comment></comment><comment><USER19> >A good way to start would be to split up libraries. Instead of creating one big library that does everything you could ever possibly need, just create many libraries. Your god-like library could still exist, but solely as a wrapper.

This isn't it. It's literally what is creating the problem. Small libraries mean duplication, a lack of shared abstractions and dependency hell. The reason garbage collection was such a huge win is that before that every C library shipped with it's own completely different way of managing memory, that's a nightmare.

We need bigger libraries providing better abstractions that are reused through out and written to allow composition and dead code elimination('tree shaking' for the JS crowd) to work well. So you can opt in to functionality you need and opt out of functionality you don't need.

Communities working on big libraries can actually do good release planning, backwards compatibility and timely deprecations. React is a example of a library that does a really good job of this. All the smaller libraries in the JS ecosystem are the cause of the pain in modern JS development.

<comment><USER20> I think we should continually fold new libraries into the language. Basically "batteries included", collapse the dependency tree.

I found that the standard python library has enormous functionality that makes it possible to solve many problems in a self-contained fashion.

This sort of solution will give you a big toolbox spread out in front of you. You will be less likely to re-invent the wheel. Many eyes on the standard library may lead to optimizations used by everyone.

And it makes it possible to share effectively. You can talk about functions with others using common terms. You can share your code and it will work in other environments. Education can teach in an unambiguous fashion.

</comment></comment><comment><USER21> > 1995 was the year in which programmers stopped thinking about the quality of > their programs.

Oh, please. There are some good points in the article but that hyperbole was unnecessary. I was programming in 1995, and nobody stopped thinking about the quality of their software.

<comment><USER22> I've been programming since 1965, read Dijkstra, Niklaus Wirth. And these days I break software at people's request. There is in fact much less concern and emphasis on quality these days.

It is also interesting to note that Knuth also does not do libraries

<comment><USER21> > I've been programming since 1965, read Dijkstra, Niklaus Wirth.

Well sir, you have me by ten years, and believe me I respect that extra decade. That said, I think you're falling into the trap many of us greybeards tumble into as we get older: the things we cared about and focused on become, in our minds, the right and true perspective that has been lost or disregarded by younger practitioners. It's really not very different from "When I was your age I walked to school every day, uphill, both ways!" Or maybe it's just me.

Yes, there are far fewer programmers hand optimizing assembly code, and yes every programmer now cobbles together applications by reusing code written by other programmers, some of which is very good, and some of which is not. But if programmers were still spending their time optimizing low level loops and eschewing any code that they did not personally write and verify the beauty of, the world we have today would not exist. Instead of zooming with my family in the middle of a pandemic we'd be exchanging emails, or posting on a BBS to say "Hi!" There's obviously still a need and role for people who like to work at that level, and that kind of engineering remains fascinating (one of the reasons I love to read the linux kernel mailing list), but I don't bemoan the rise of high level languages, libraries, package management ecosystems, frameworks and the like. That stuff has given us the world we have today, and a few warts notwithstanding I still like it much better than the one we had.

<comment><USER22> Whippersnapper. I grew up in Montana back when winters were severe. I did walk to school—about 25 feet as my parents drove me.

None of what you seem to think about my rant represents what my position is. Read my other note in my thread about the NYT article concerning Knuth and Norvig's commentary. There is a time today for total deep dive. There is skill involved to do this and wisdom when to do this.

There are folks who write with minimal libraries cf qmail.

What seems to be completely missing from today's discourse about programming is something dijksata said about interrupts. Paraphrasing "If you don't see the code on the page in front of you, you will make mistakes. "

Take a look at modern Java. Levels of abstraction in use require serious deep dive to truly know what is going on. There is a famous Node package issue where code that wasn't even on your computer crashed a swath of applications.

Quality in the context of the article means the code is pleasing to read, doesn't crash unexpectedly and doesn't have side effects that you may only discover when Brian krebs emails you about your customer's data ending up in some remote online flea market

</comment></comment></comment></comment><comment><USER23> There is an analogous problem in city design, wherein it was discovered that it was empirically not possible to get the average commute down below a certain time, because as more roads were built people moved further away from town. If you build more lanes to your roads, you don't get a faster commute, you get more sprawl.

People spend time making software less bloated, when it's the number one problem they have. When hardware speed is taking care of making that only the #2 or #3 problem they have, then they will work on whatever the #1 problem is, meanwhile adding more software bloat.

When Moore's Law once and for all stops, due to some law of physics reason, then software bloat will become a priority. Until then, other things are.

<comment><USER24> Yeah, you are describing Braess's Paradox: [https://en.wikipedia.org/wiki/Braess%27s_paradox](https://en.wikipedia.org/wiki/Braess%27s_paradox)

It is a form of Induced Demand: [https://en.wikipedia.org/wiki/Induced_demand](https://en.wikipedia.org/wiki/Induced_demand)

</comment></comment><comment><USER15> I guess it's more of a natural selection process - the software house which can deliver a good enough _working_ piece will (nearly) always beat the one which adds another two years of development time (and cost) to make the app a bit snappier. Ask Lotus Notes and Netscape.

I don't want to say that performance does not matter at all - it does - <USER3> with hardware being as cheap as it is and developer time and time-to-market being as expensive, optimizing that last 500ms and 200MB out simply is not going to be worth it.

And let's not disregard the expense of performance optimization - you'll not only need a reference to benchmark and test against, but also spend a lot of time debugging and writing very plattform-specific code with tons of edge cases. It's not like saving 2GB of memory comes for free.

<comment><USER25> Multiply that 500ms and 200mb by more than a few thousand users and you are talking about real time and money.

Everything seems to have been optimized for the enterprise market.

<comment><USER15> That's why I've mentioned time to market. Take GitHub as an example: It's neither the fastest/most lightweight git hosting page (that would probably be Gogs/Gitea) nor the most feature-rich (GitLab is far more advanced, as far as I can tell). They are where they are because they've made a viable product first. Same with slack: Electron is not a good solution, but it was a desktop app in 5 minutes - can't beat that.

I'm not trying to say performance doesn't matter - I'm using lower-powered devices myself - but development time is also a big factor for b2c.

</comment></comment></comment><comment><USER26> What gets me is part of the '95 quote about computing in the 70s

"About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage"

Such a text editor likely couldn't handle lowercase in English, let alone any other Latin script language, let alone cjkv or bi-di. The bloat in software of 95 and the present day is real, but there is no real effort to make an apples to apples comparison in what our expectations of software are, and it massively weakens the argument

Parallel arguments can clearly be made for compilers etc.

<comment><USER27> [http://www.texteditors.org/cgi- bin/wiki.pl?TinyEditors](http://www.texteditors.org/cgi- bin/wiki.pl?TinyEditors)

A lot of these are less than 8K, none of them can't handle lowercase, and I bet the majority of them will be fine with "high CP437" bytes (so other Latin languages.)

<comment><USER26> Of course, but editors written in 1970 (25 years before the Worth quote in question) often couldn't handle lowercase (and neither could early versions of Pascal) often because platform support was limited or missing.

Much of the cability of a modern tiny editor comes from the environment in which it is running, we just expect more from an editor now, and the developer expects more from their operating system.

</comment></comment></comment><comment><USER28> There are many complaints but there doesn't seem to be a real movement to make/use/cultivate small and fast software for all purposes.

I'd join.

Fragmented parts could be suckless.org, old cheap thinkpads from ebay, fast Linux distros, unix command line tools, retrocomputing, raspberry pi; all things with communities and fans who like a certain quality, simplicity and the good old days.

<comment><USER29> check out the suckless suite of software. it's neat :)

<comment><USER30> Suckless is neat, but it stuck in the past, in a way. Using modern programming languages and native frameworks is the way to go. But the philosophy is exactly what required.

</comment></comment></comment><comment><USER31> Software speed is a usability feature, and usability is a subset of economic value.

It turns out, people are perfectly happy to put up with slightly slower software for all of the other benefits we get from modern software: rapid development, rapid deployability, ease of code comprehension, and more.

When users complain about slow software enough to buy a different product (in whatever variation of 'buy' that may be) then it becomes a high priority thing to fix. Software today is precisely as fast as it needs to be- and no more, typically.

To me, this article is just the software engineer's version of Grandpa complaining that things were better in the old days- he's ignoring the reasons why things changed.

<comment><USER32> >people are perfectly happy to put up with slightly slower software for all of the other benefits we get from modern software

I don't think this is true. I think this is more of a 'boiling frog' situation. Increase the temperature one degree at a time and it won't jump out of the pot.

Every individual piece of software slowly eating up more resources is something the user barely notices or doesn't even attribute to the software in question, but give it a few years and everything grinds to a halt, _and people very much dislike this_ , hence the infamous 'Windows rot' that everyone has suffered from at one point of their lives.

</comment></comment><comment><USER33> "In economics, the Jevons paradox (/ˈdʒɛvənz/; sometimes Jevons effect) occurs when technological progress or government policy increases the efficiency with which a resource is used (reducing the amount necessary for any one use), but the rate of consumption of that resource rises due to increasing demand.[1]"

[https://en.wikipedia.org/wiki/Jevons_paradox](https://en.wikipedia.org/wiki/Jevons_paradox)

<comment><USER18> See modern IRC clients that take 500MB of memory on the desktop. Compare with Orcad Capture a mid 90's schematic capture program that would run acceptably on a 486 with 16MB of memory.

<comment><USER33> To be clear, the "efficiency with which a resource is used" in this case can be represented roughly by dollar per unit compute. As that value goes down, you would expect software "waste" to go up. That's how the Jevons Paradox applies here.

</comment></comment></comment><comment><USER34> There's a few issues with this post. It starts off great but falls down hard.

For one, PHP did not start out object oriented. Nor did it come with an IDE. Sure, it was dynamically typed (unlike Java). If I recall, it was 1994 too but I can't be sure.

It was only PHP4 that added an abomination of a class system that motivated the current object system in PHP5. In fact, the problems with PHP have more to do with that pattern: creating abominations that motivate the development of something that isn't a total abomination (often whilst retaining said abomination for a while).

And, as others have said, small "libraries" is exactly why the todo app needs 13k NPM packages.

I say "libraries" but you can't call them that. I mean where's the analogy? A library of one function? Behave

</comment><comment><USER35> For the most part, the output object/exe size should be the realm of the tooling, not the programmer's concern -- a dependency-walking package-manager, linker or loader -- and in dynamic languages, unused code should never be JITed. Of course, surrounding issues such as choosing _bad_ or incompatible libraries, etc., is another matter.

<comment><USER36> There's no way a linker, no matter how smart, can give us back the object size and performance of the '90s.

For starters, there's 64-bits. Pointers were a quarter of the size in the '90s.

Then, there is Unicode. All programs need ICU ([http://userguide.icu- project.org/icudata](http://userguide.icu-project.org/icudata)). Even if you dynamically link it, many of its symbols (or entry point IDs) end up in your executable.

Unicode isn't an exception, though. Every library choice you make adds a bit more in size and takes a bit more in performance than the solution from the '90s would have.

For example, the moment you decide to use json, you get its entire feature set (arbitrarily nested arrays, a multi-line string parser, ability to read fields in arbitrary order, etc), even if all you need to do is pass two integers and get one back.

A parser generator that generates code for the json subset you need would help here, but would mean extra work for the programmer and the overhead typically isn't that large, so why bother? It all adds up, though.

Even if you can't remove some code, you still could optimize memory layout to move code you expect will rarely run into separate code pages so that it likely will never be mapped into memory, but that's serious work.

And of course there's all that argument checking/buffer overflow protection people do nowadays that 'wasn't necessary' in the '90s.

<comment><USER35> The article clearly focuses size due to the use of libraries.

As for pointer size, personally I agree -- most processes can get by just fine with their own 32bit address space, so I'm not sure why we need to double the working-set size of all pointer-based data-structures.

<comment><USER37> > so I'm not sure why we need to double the working-set size of all pointer- > based data-structures.

If your data structures can fit in a 32-bit address space, you can just place them in an arena w/ 32-bit indexes. You do need to use a custom allocator for every element of that data structure, but other than that it ought to be feasible. Link/pointer-based data structures should be used with caution anyway, due to their poor cache performance

</comment></comment></comment></comment><comment><USER38> Sidenote: Niklaus Wirth designed Oberon, one of the coolest operating systems I've ever seen. You can run it on an emulator. It's basically a graphical OS, which sounds like an oxymoron, until you realize that the programming language itself is also graphical.

It's so unknown that it's shocking. Imagine designing an entire OS that was used by dozens of people, and no one knows about it. [http://worrydream.com/refs/Wirth%20-%20Project%20Oberon.pdf](http://worrydream.com/refs/Wirth%20-%20Project%20Oberon.pdf)

</comment><comment><USER39> "Languages like these made programming a lot easier and took many things out of the programmer's hands. They were object-oriented and came with things as an IDE and garbage collection.

This meant that programmers had fewer things to worry about"

Yeah, right. Those lazy programmers.

It's obviously become easier to build complex software, but software is now required to be much more complex. There are still many things to worry about (actually far more than previously, I'd say), but they're not the same things.

</comment><comment><USER40> I think a lot of this is governed by Conway's Adage: the software reflects the social systems that built it. If you look at the larger software ecosystem, it reflects the larger society that built it. The priorities and social customs of communities are leading to the "bloat." It's hard to say whether that is a growth on society's part or that software is simply still catching up with society.

<comment><USER41> Back when a ton of software was written by graduate students... it was small (because no time), fast-ish (because small), and buggy as all heck (because no time).

</comment></comment><comment><USER27> One only has to look at the demoscene to realise that limitations inspire creativity and efficiency. It's just a form of art, but gives a glimpse at what computers are capable of, if only we would try to use them more efficiently. I think award-winning 4k or 64k demos should be required watching for every software developer. Here are some personal favourites which have also appeared on HN:

[https://news.ycombinator.com/item?id=11848097](https://news.ycombinator.com/item?id=11848097)

[https://news.ycombinator.com/item?id=14409210](https://news.ycombinator.com/item?id=14409210)

[https://www.youtube.com/watch?v=Y3n3c_8Nn2Y](https://www.youtube.com/watch?v=Y3n3c_8Nn2Y)

</comment><comment><USER42> > About 25 years ago, an interactive text editor could be designed with as > little as 8,000 bytes of storage.

That would be in 1970, but my guess is that "ed" would be a hard sell today.

There is plenty of bloat to go around these days and I think we could do a lot more to address that. But we've all got too much skin in the web game to own up to the embarrassing fact that a chat program that's basically IRC with pictures feels like glue on a 2.4 GHz, multi-core CPU.

With that out of the way, we shouldn't get silly, either. Every actually useful feature added will increase complexity and resource usage. I like split-window, code-folding, auto-indented, word-completing, syntax highlighted multiple document editing more than I like saving a few fractions of a percent of my hard drive space.

<comment><USER43> That text editor quote really bugs me. Sure my Atari 800 had a word processor that came on a 8k cartridge. I couldn't type Chinese, Japanese, Korean, Russian, Arabic into. I could only type ASCII. Just the ability to do that alone would likely entail many many megabytes of code.

For one, there is no text based system like those old machines that handles all that so I have to switch to graphics. Just the font alone for all of those languages will be multi-mega bytes and I'll need multi-megabytes more for space to rasterize some portion of those fonts. Rasterising just 4 or 5 glyphs is more work than that entire 8k word processor had to do on its 40x24 text screen.

Then for each language I'll need multi-megabytes for handling the input methods. The input methods are complex and will likely need a windowing system to display their various options and UX so add more code for that.

The point being that we need the complexity. That 8k editor wasn't useful in the same sense as our stuff today. I don't know a good analogy. It's like complaining that people use CNC machines today and at one point got by with a hammer and chisel. I'm not going back.

<comment><USER27> _Just the ability to do that alone would likely entail many many megabytes of code._

 _Just the font alone for all of those languages will be multi-mega bytes and I 'll need multi-megabytes more for space to rasterize some portion of those fonts._

 _Then for each language I 'll need multi-megabytes for handling the input methods._

Those statements clearly show your lack of awareness of what things were really like 40 years ago. They had CJK input and output([https://en.wikipedia.org/wiki/Cangjie_input_method](https://en.wikipedia.org/wiki/Cangjie_input_method) was invented in _1976_ , for example) on the systems of the time, and that certainly did not entail "megabytes of code".

What it did entail, however, was a certain amount of skill, creativity, and an appreciation for efficiency and detail that lead to being able to do it with the hardware of the time, skills which are unfortunately a rarity today. Instead, we are drowning in a sea of programmers who think the simplest of tasks somehow requires orders of magnitude more resources than were available decades ago, when the reality is that there existed software at the time able to do those tasks perfectly well and at a decent speed.

 _The point being that we need the complexity._

The point is precisely that we _don 't_.

<comment><USER42> While parent's "many many megabytes" might be an overstatement, today's editors are expected to display any number of languages and alphabets simultaneously, using user-configurable, scalable, variable-width fonts that render in a variety of different resolutions with sub-pixel smoothing. Things like that add to the complexity of both the OS and the application itself.

</comment></comment></comment></comment><comment><USER44> That's why Chuck Moore, the creator of Forth, use to say that he can create any software with 99% less code that a commercial version. He always designs software thinking on how to keep it as close as possible to hardware and removing useless abstractions.

</comment><comment><USER45> Seems to me the software features interact in a kind of network effect, so that the amount of resources required grows faster than amount of functionality.

</comment><comment><USER46> I do see this as a gap/opportunity in a lot of existing markets. Huge players who dominate these areas are doing so with these giant, slow, unwieldy web apps. Look at how Figma managed to take over in the design market by creating a lighter/faster product than what everyone else was offering. I wholly endorse any other teams that want to use Wasm to kick stagnant old web apps off their thrones.

<comment><USER47> Surely Figma actually took over that market by 1) making a web-based version of a category of software that was primarily desktop-based, and 2) giving it away for free? I don't think performance has much to do with it.

</comment></comment><comment><USER48> Modern software is doing orders of magnitude more than the software of the past. The feature set of a word processor in 1980 is a rounding error compared to the 2020 word processor's print dialog.

The OP's viewpoint is akin to claiming that aviation has not advanced beyond Kitty Hawk because modern aircraft are simply wasting fuel when they take to the skies. It doesn't take into account the huge differences in the modern computing environment.

The computers of the recent past weren't even powerful enough to encrypt a modern TLS session. Does that mean using all that power to encrypt the session today is "bloat"? Of course not. _One person's bloat is another person's feature_. Note that sometimes that feature is that the software can actually exist and be maintained on your preferred platform.

If you think about it, it would be an utterly bleak future if we were just running the exact same software stack on faster and faster hardware. That would represent stagnation, not progress.

<comment><USER49> I think you'd be surprised how few extra features Word in Office 365 has compared to WordStar 2000 considering the forty year gap. And also how poorly designed, inelegant, and - yes - pointlessly bloated Word feels in comparison.

The biggest differences are screen size - full document vs a few lines of text - and support for colours and outlining. Also, PDFs, which weren't a thing in the early 80s.

But the core features in WS2000 are a lot more than a "rounding error" compared to Word.

</comment></comment><comment><USER50> The central conceit being we are all doomed as software becomes more bloated and less efficient while processing power remains at it's current levels?

While Moore's law may be over in terms of number of transistors per chip, we are still seeing growth in the number of cores per CPU, not to mention faster memory and the death of spindle storage.

ImO software will start leaning more heavily towards parallelesim (if it hasn't already, building a threaded or asynchronous application is no longer an arcane dark art). Couple that with the surge in adoption of distributed architecture (yes microservices), and the emergence of languages which encourage pragmatism and efficiency (ala Go and Rust) and I think we'll be okay for the next while. Can't speak to electron though (gross).

</comment><comment><USER51> Incentives are often a big part of the problem. In many cases, people are writing software that will run on someone else's hardware. This applies to basically all front-end web development, all mobile apps, and all software licensed to someone else.

That means the programmer (or their employer) doesn't pay for the electricity it uses (or battery it drains), the RAM it allocates, the disk space it wastes, or the hardware upgrades necessary to make it run acceptably.

Why conserve a resource that you're not paying for? Especially if you have to expend your own resources to do it.

I'm not defending crappy software (nor, apparently, offering a solution), but if a programmer's personal sense of honor is the only weapon in this fight, then it's not a great formula for winning the fight.

</comment><comment><USER52> There are a lot of these type of articles that conclude that "we", the developers, need to fix this problem. But if you read the original article by Prof. Wirth, it is not up to "us".

It is the reality of the software industry. Time-to-market is the only rule. and it dictates how we write software: Agile, Scrum, don't reinvent, deploy early, fix it later, technical debt.

There are many of us who care about quality of our work. But in performance reviews, the only thing that matters is how many features you shipped. You cannot demonstrate the quality of your work in your performance review. Or better yet, the fact that the software you wrote is going to be bug-free for next 10 years.

</comment><comment><USER53> >"Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster.

[https://en.wikipedia.org/wiki/Wirth%27s_law"](https://en.wikipedia.org/wiki/Wirth%27s_law")

[...]

>"Niklaus Wirth, the designer of Pascal, wrote an article in 1995:

About 25 years ago, an interactive text editor could be designed with as little as 8,000 bytes of storage. (Modern program editors request 100 times that much!) An operating system had to manage with 8,000 bytes, and a compiler had to fit into 32 Kbytes, whereas their modern descendants require megabytes. Has all this inflated software become any faster? On the contrary. Were it not for a thousand times faster hardware, modern software would be utterly unusable.

Niklaus Wirth – A Plea for Lean Software"

[...]

>"Time pressure is probably the foremost reason behind the emergence of bulky software.

Niklaus Wirth – A Plea for Lean Software

And while that was true back in 1995, that is no longer the most important factor. We now have to deal with a much bigger problem: abstraction. Developers never built things from scratch, and that has never been a problem, but now they have also become lazy."

[...]

"The problem does not seem that big, but try to grasp what is happening here. In another tutorial that Nikola wrote, he built a simple todo-list. It works in your browser with HTML and Javascript. How many dependencies did he use? 13,000.

These numbers are insane, but this problem will only keep increasing. As new, very useful libraries keep being built, the number of dependencies per project will keep growing as well.

That means that the problem Niklaus was warning us about in 1995, only gets bigger over time."

Related: "The Law Of Leaky Abstractions" by Joel Spolsky: [https://www.joelonsoftware.com/2002/11/11/the-law-of- leaky-a...](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky- abstractions/)

</comment><comment><USER54> It's true that lots of software is slower than it should be. It's also true that software does a lot more than it used to. What's not true is that abstraction is the reason for slow software, at least not on the order of magnitude that the article claims. Even in the worst case, the cost of language level abstractions is well outstripped by advances in processing power.

I'm not actually sure we really even have "slow" software. At least not relative to how much that software can do. Latency is a different story.

</comment><comment><USER55> "1995 was the year in which programmers stopped thinking about the quality of their programs."

There are some valid points in this article, but seriously?

<comment><USER56> Actually it was the year that managers stoppped taking programmers in that know how to do quality control and focus on doing it faster with more bugs so it ships sooner. If you look at some of the MS-DOS programs they rn with little to few bugs, but Windows 95 ran them in MS-DOS mode. Later on Windows programs needed updates and bug fixes to make them work faster and every version of MS-Office fixed bugs but ran slower as CPUs and hard drives got faster they didn't focus on quality any more just shipping it with bugs and fix the bugs later on.

</comment></comment><comment><USER10> And the trend is not slowing. That said some people like low fat computing.

Another thing.. computing is over. At least in the previous era form. It's not bringing dreams anymore, will probably turn into an ubiquitous invisible form where intrinsic details such as resource usage won't matter.

<comment><USER57> I think you might be a little pessimistic here - IOT has a wealth of fruit to bear, from:

low power always-on devices with long range radio (LoRa), few resources (32k ram), the security constraints of securing every device, dealing with terabytes of log data in the cloud, ML at the edge (Kendryte K210), open- source firmware including radio (DASH7 firmware), open-source hardware (and open-source FPGA tooling) to create custom hardware designs (hardware implementation of algorithms), formal verification of OS and protocols, etc etc.

Even a handful of innovation in any of the above would be groundbreaking.

<comment><USER10> I'm a bit jaded and at the same time not much.

These are all very advanced low level technology subjects (some of which I like a lot btw).

What Wirth said only concerns a few grams of people on earth, the rest will stop using computers just like they stopped using desktops and just stream/talk on smartphones. If you ask most users they'll probably root for whatever electron app they use compared to frugal but powerful programs. For the layman computing will fade and become like roads. And I believe they never really needed nor liked computers, it just was a 20 year period where it was thought to be a technological wonder to have in your home.

</comment></comment></comment><comment><USER58> All that "bloat" enables us to do (much) more with less developer hours.

The balance is the same as ever, developer time vs. compute power. As compute power gets ever cheaper, and developer time still costs the same, we put bigger burdens on the machine to save developer time.

In other words, simple economics.

<comment><USER59> I don't think that developer time is the only metric here.

Yes, every project can get to market or to the next release with a startup company's speed, but you trade-off and generally get "startup quality" that way. That is the actual point.

This industry is so fast-moving that the costs associated with that level of quality is often paid later by other people. There are plenty of examples of this.

</comment></comment><comment><USER60> He was right in 1995 and he still is. _Bucky_ , as he was called at Standford, is one of founding generation of computer science that is still alive. Being 4 years older than Knuth he might even be the oldest one.

</comment><comment><USER61> I think this post has some validity to its main points, but I personally think it veers on the edge of "real programmers do X" and reels of rose tilted nostalgia.

</comment><comment> daniel-s Meh, I think this whole argument is wrong. Software "bloat" is fine.

I'm reminded of this [1] article comparing Bruguet and Carson numbers. You have ever cheaper hardware. The marginal utility of any given unit of new, equally serviceable computing power is going to be less than the previous one. So eventually if something can be 2% better/more functionality, etc. at 10x the bloat it is rational to accept that. When you have lots of something you become less efficient in how you use it. If you're surprised by that go and read economics.

[1] [https://www.cringely.com/2011/05/19/google-at-carsons- speed/](https://www.cringely.com/2011/05/19/google-at-carsons-speed/)

<comment><USER30> It comes with a cost. If not money then environmental footprint. Bitcoin is a good example. Or a toxic deadlands of computer and mobile scrap. Just because companies think it's cheap and blind developers think it's acceptable to bloat.

</comment></comment><comment><USER62> > 1995 was the year in which programmers stopped thinking about the quality of > their programs.

-yawn-

Prove it.

The number of books and articles about the quality of software engineering published in the past 25 years certainly seems to prove we care a great deal about code quality. Probably more than we ever did prior to 1995 when Pascal, BASIC, FORTAN, COBOL, and self-modifying assembly code were being taught in colleges.

As for the point of the article, that hardware doesn't accelerate as fast as programs using it, same challenge: prove it.

This article is all handwaving and speculation with no data to support any of its claims.

</comment><comment><USER63> Reminds me [http://www.kegel.com/c10k.html](http://www.kegel.com/c10k.html)

</comment><comment><USER30> Another solution would be to use the proper, statically and strictly typed programming languages with AOT compilation. Rust, Swift, Kotlin - these are the best of production-level languages that can produce both native code and WebAssembly. There are other, similar languages as well. They key point - <USER4> compiler knows more about your intentions (e.g. strict and sound type system) it can optimize it better. Especially with LTO or PGO.

</comment><comment><USER64> Yeah, you will always keep writing crappy software while your hardware will also keep wiping your ass

</comment><comment><USER65> I feel like we had this debate a couple months ago. Someone posted that the computer at his local library could search and display data on available books super fast. (I think it was a twitter thread). The interface was programmed in the 90s or something. And then they complained about software today.

My reply was that now days you can, at home, search for a book on a specific interlibrary system, and find what specific libraries have it, download and check out an Ecopy, find out the number due back if you still wanted the hard one - AND have someone go hold it.

It's just not apples and apples anymore. I don't care how fast you can scan a text file in 90s written software.

<comment><USER17> There is not reason you can't have the connectivity without having the unnecessary complexity of modern computing.

<comment><USER15> Alternative question: Why do I need to download 50 GB of book index to search for that one title and that index can't even do a full text search?

That complexity is Google (or your favourite search engine) running a datacenter indexing exabytes of data so that you can search it in the blink of an eye. Yes, it takes 600ms now instead of 50ms - but that's like complaining that your new eco car engine can't even properly run on aftermarket lamp petroleum.

<comment><USER17> What does google's datacenter for a book index have to do with editing a file or rendering a button? That doesn't seem relevant at all to Wirth's law and isn't an justification for the increase in abstraction that has made things slower.

</comment></comment></comment></comment><comment><USER66> Sniff sniff. What's that I smell.

Gatekeeping bullshit? The scent is unmistakable.

</comment><comment><USER67> Ah yes let's pine for the days when ~men were men~programmers were programmers and we coded real quality, unlike this current trend...

<comment><USER68> ...and furry little creatures from Alpha Centauri were real furry little creatures from Alpha Centauri.</comment></comment>


Getting more daylight can improve your mental and physical health - <AUTHOR> https://www.newscientist.com/article/mg24232320-100-how-getting-more-daylight-can-improve-your-mental-and-physical-health/ <comment><USER2> Damn, what's next? Drinking water is good for you?</comment>


A comprehensive, introductory course on Mindfulness Meditation - <AUTHOR> http://www.audiodharma.org/series/1/talk/1762/ There seems to be some interest here recently on meditation its beneficial results that are of interest to hackers. Developing the capacity for strong, calm focus and eliminating the detrimental effects of unhelpful mental functions are skills that take practice.
Many of the posts that have been floating around don't give very much substance on the nuts and bolts of how to meditate. Since HN is an erudite crowd of people who don't shy away from detailed topics, a more thorough reference is in order.
This is a 6 part introductory course that should take roughly a month to complete. It is self-paced and costs absolutely nothing. Each week you add on to the foundation you build the week prior. There are 6 lectures covering the topics and practice. Each one is a bit over one hour long and has lecture notes to go along with it.
The teacher's name is Gil Fronsdal. He was ordained as a monk and eventually returned to lay life to get his Ph.D in Buddhist studies from Stanford. He is renowned for being exceptionally clear and simple without sacrificing any detail.
If programming is one of the most powerful tools used for hacking computers, then Mindfulness Meditation is one of the most powerful tools for hacking the brain.
Good luck! <comment><USER2> This is a great audio course, but I'd still recommend that folks interested in learning how to meditate try to get to a meditation center at least once, to get face-to-face instruction. It really makes a difference.</comment>


Architects of C.I.A. Interrogation Drew on Psychology to Induce 'Helplessness' - <AUTHOR> http://www.nytimes.com/2014/12/11/health/architects-of-cia-interrogation-drew-on-psychology-to-induce-helplessness.html

<comment><USER2> The psychologists who were involved in this program should, at a minimum, have their licenses revoked.

I am so shocked and disappointed about this interrogation program that I'm still not sure how to express it.

<comment><USER3> 1 officially those people dont exist, they are REDACTED contractors

2 is would really hurt their $80mil backed retirement plans in Florida , Im sure of that ...

</comment></comment><comment><AUTHOR> I just...wow...I don't even know how to begin to say how wrong this feels.

</comment><comment><USER4> Also see [http://en.wikipedia.org/wiki/Pit_of_despair](http://en.wikipedia.org/wiki/Pit_of_despair)</comment>


How 5 minutes of work made us $50,000 - <AUTHOR> https://medium.com/p/e706a854481c

<comment><USER2> Correlation does not imply causation... that said, congratulations on your success! I would be interested to see more about the parameters of your A/B tests.</comment>


Startup lessons from Bigulo - <AUTHOR> http://www.destraynor.com/serendipity/index.php?/archives/179-Letting-go.html

<comment><AUTHOR> Liked this:

        If you can't imagine any user paying you money, then they won't.
        You can take 1 million users, and be ultra conservative and say .5% conversion,
        and very easily earn yourself $5,000 in Excel.
        Getting that money into your bank account is a different kettle of fish.</comment>


Protocol-Oriented MVVM with Natasha the Robot - <AUTHOR> https://realm.io/news/doios-natasha-murashev-protocol-oriented-mvvm/ <comment><USER2> interesting talk, but unfortunately it only shows an example where instead of having all in one (albeit big) place, the code for configuring a cell from a model is scattered throughout many protocols and extensions. And all without a single code reuse.

I'm pretty sure the approach shown here is interesting, but i'd hoped the example would be more convincing.

</comment><comment><USER3> I enjoyed the talk - thanks for doing it. There's an alternative though to the final approach of using a class template. You can actually do a typealias which fuses together multiple protocols into a single type. I've done a small example here:

[https://gist.github.com/earltedly/67ab52c3c65ba22f6fa5](https://gist.github.com/earltedly/67ab52c3c65ba22f6fa5)

</comment><comment><USER4> Is there any example code to study ? thanks!</comment>


How Hotmail changed Microsoft (and email) forever - <AUTHOR> https://arstechnica.com/information-technology/2017/12/how-hotmail-changed-microsoft-and-email-forever/ <comment><USER2> "Hotmail used Secure HTTP (HTTPS) with SSL encryption to protect users' login credentials, and Microsoft forced customers to use more complex passwords—but the rest of the service ran over unencrypted HTTP. "Just the authentication piece required us to run hardware accelerators at the time" :O

</comment><comment><USER2> I use my hotmail for all my non-business communication (i.e. whenever I have to give my email out as a consumer). The spam detection and focused inbox work great for that.</comment>


Functional Languages 101: What's All the Fuss About? - <AUTHOR> http://www.infoq.com/presentations/Functional-Languages-101

<comment><USER2> I stopped listening when she said 'code and data are the same thing in a functional language'. Well not really, code and data are the same in a homoiconic language, but really any language with sufficient reflection capabilities can mix code and data. It has nothing to do with being functional.

<comment><USER3> But all functional languages are Lisp, right?

<comment><USER4> Not sure if you're being facetious, but no, not all functional languages are Lisps. Haskell, ML, Ocaml, and Scala all come to mind as functional languages that are far from Lisp.

<comment><USER3> I was being facetious. Sorry.

</comment></comment></comment></comment><comment><USER5> One of the things Dr. Parsons mentions here is how functional programming makes it easier to reason about programming because of the lack of side- effects. That makes sense to me, and I heard it frequently whenever someone is giving the FP sales pitch.

I wonder, though, whether there is a tradeoff that is going unmentioned, and I suspect that it is that it makes it more difficult to reason about costs. I feel trapped when I'm writing in a language like Java, but at least the cost model is obvious to me. Am I off base here? Is there some way to develop a similar intuition about costs in an FP language?

<comment><USER6> You should read the introduction to Chris Okasaki's "Purely Functional Data Structures". It says there may be higher lower bounds for some problems in functional programming languages, although it's often possible to come up with something that is as fast. I interpret that as it can require a lot of ingenuity to come up with efficient data structures in functional programming languages.

It's not harder to reason about time complexity with strict evaluation. I think it's a bit harder with lazy evaluation, though. Okasaki uses both strict and lazy evaluation to achieve fast data structures.

<comment><USER5> Thank you for the pointer! I grabbed this pdf, and (by random chance) my eyes fell upon this somewhat-related gem (on page 129):

"Ironically, pattern matching — one of the most popular features in functional programming languages — is also one of the biggest obstacles to the widespread use of efficient functional data structures. The problem is that pattern matching can only be performed on data structures whose representation is known, yet the basic software-engineering principle of abstraction tells us that the representation of non-trivial data structures should be hidden. The seductive allure of pattern matching leads many functional programmers to abandon sophisticated data structures in favor of simple, known representations such as lists, even when doing so causes an otherwise linear algorithm to explode to quadratic or even exponential time."

<http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf>

</comment></comment></comment><comment><USER7> If you want to understand functional programming read SICP.

<comment><USER8> Disclaimer: I am currently going through SICP (I'm approximately 200 pages in).

So far, I do not get the impression the I'm learning _functional programming_. Sure, I learn all about map, fold and filter. Sure I've picked this up these concept and apply them almost exclusively to my "regular job" programming in Python. But I'm not learning about _functional programming_.

What I mean is that _assignments_ are simply never mentioned (so far). Everything is acting as if FP is the only natural way to program (I'm a professional programmer, but keep in mind that this book is geared towards beginners with little-to-no prior exposure to programming).

Anw, my point is that SICP will have you program a lot in FP style, but won't spend time explaining what FP is, or how is it different from your 'standard' procedural paradigms. I hear that you can write in various paradigms with Scheme, I wouldn't be surprised that they'd be mention in this book.

In short, SICP is a wonderful book that will teach you how to build (well "structure") your programs, focusing on mastering complexity to manage large systems. It's not an absolute reference about FP.

<comment><USER4> Keep reading. ;)

Seriously, if you're only 200 pages in, you haven't read chapter 3 yet, which delves deeply into the implications of introducing mutable state, and spends quite a lot of time exploring those implications, especially for concurrent programs. There is also some exploration into object oriented programming and alternative semantics and paradigms, including logic programming and laziness (chapter 4, iirc)

In short, I definitely don't think of SICP as an absolute reference to functional programming, especially since there are newer languages and approaches to these problems (STM in Clojure and Haskell, actor based concurrency etc) but SICP is an absolutely brilliant introduction, albeit a long one.

</comment></comment></comment><comment><USER9> Given that the majority of web surfing is done on mobile these days, it's pretty naïve to put pictures inside a Flash object. Wont be viewing those slides any time soon. (Also, functional programming FTW!)

<comment><USER10> >Given that the majority of web surfing is done on mobile these days

Based on what? I can't find a single article that would back that up.

Although I do agree that doing anything with Flash is just shooting yourself in the foot.

</comment></comment><comment><USER11> Seems most of the talk is actually about Lisps.

In my mind, functional languages and Lisp are two separate things.

Lisps can be functional, but most of them are not.

<comment><USER12> Sounds like your thinking of /purely/ functional programming. Although none of these terms have precise definitions so there's not really any point arguing over them.

<comment><USER11> Not really.

Functional programming for me has a feeling of a mathematically sound foundation: This means a statically typed language with a powerful type-system and type inference. Immutability/effect system are a big plus. Broad range of data-structures and a decent object system are nice, too.

<comment><USER13> > Functional programming for me has a feeling of a mathematically sound > foundation: This means a statically typed language with a powerful type- > system and type inference.

Mathematical soundness does not require type inference. It's unclear whether it requires static typing.

And, it can easily get by with almost no type-system.

<comment><USER11> That's why I wrote "for me".

</comment></comment></comment></comment></comment><comment><USER14> this is what happens when mathematicians try to understand computers

<comment><USER15> What about Jon Von Neumann (and many others)? Your comment is excessively snarky and wrong.</comment></comment>


Ask HN: Can someone explain how the stock markets can be rising now? - <AUTHOR> <comment><USER2> [https://en.wikipedia.org/wiki/Dead_cat_bounce](https://en.wikipedia.org/wiki/Dead_cat_bounce)

</comment><comment><USER3> There can be many reasons. The value is almost always based on what people think will happen at some future date. As information becomes available that sentiment changes. I would not count on this market immediately going back to where it was. Real damage has been done. 6-18 months to recover.

</comment><comment><USER4> Won't be for long. Indexes are hitting major resistance rn. S&p likely to drop to 1800-2100 area soon.</comment>


Ask HN: Would this work? Meetings with timers - <AUTHOR> So I started noticing that at most of the places I have worked meetings are always exceeding the time, or not that well structured and get off track.
Now I have been thinking about making a sample app where you just 1) define the meetings topics. 2) setup the time for each topic. 3) invite & start the meeting.
For me it would make sense because now I have a clear overview and I can go back to the meeting later and replay stuff.
Would this work for your team? and are you having similar problems with meetings? <comment><USER2> I find it interesting that deadlines for multi-month and multi-year projects are often set in meetings that overrun their allotted time.

<comment><AUTHOR> Haha yes, it would be fun (as a dev) to look back at those meetings and see who promised what</comment></comment>


Ask HN: I hate to work with my colleague what shall I do? - <AUTHOR> My colleague is a guy that make a lot pressure and everything is bad - he has a pessimist way of see everything He looks at each opportunity to make me feel bad and make fun of me. Every meeting with him is demotivating. I am loosing my patience. I don't know what to do... I'm an easy guy who loves what he does. Don't feel like arguing with him is the solution. <comment><USER3> You have already received couple of strong suggestions, excellent advise there you should try to incorporate.However, both of them are extrinsic rewards focused. When faced with external challenges (things outside of your mind or physiology) changing your outlook, circumstances or expectations in order to adapt to your situation is certainly a good way to handle it. I would only offer one suggestion - if this is an internal struggle by any chance. That would be to find your core empathy for yourself and your colleague, which means be compassionate to yourself and understand why is it bothering you so much. And be compassionate to the other person and try to determine what is driving their behavior. These are both hard things to do. I can't tell you how exactly to do that - but try reading a few books like "Dare to Lead" by Brene Brown or "The 7 Habits of Highly Effective People" by Stephen R. Covey. Good luck!

</comment><comment><USER4> If he's American and you're not, or english is his first language and your's is not, it's probably a cultural thing and the chemistry is lost in translation. He's just "busting balls" "busting chops" or making fun of you because he wants you to make fun of him. Just make fun of him - find some common ground.

The pessimism, he wants someone to commiserate with, ie share complaints with. You should complain about something with him ie your girlfriend/wife, your mom, friend, commute to work, finding a parking spot, traffic, etc - <USER2> about anything. You'll see him listen to you complaint and become more friendly to you.

Give it a shot, sounds like your already in a bad place so you have nothing to lose. Hopefully this helps - good luck.

</comment><comment><USER5> I would do the following in order:

1\. Try talking to him about it. Maybe he'll change (doubtful, but worth a try).

2\. If the above doesn't work, report to his/your boss or HR depending on the severity. Keep in mind if he is well-connected or protected in the company, this may backfire. Best case scenario is they force him to change or put him or you on a new team.

3\. If the above doesn't work, then it demonstrates your company does not give a damn about you and your only option is to find a new job. As a bonus here, you could explore legal options if harassment from this employee is illegal (race or gender discrimination, etc).</comment>


Super Glue Built Planes, Nukes and Saved Soldiers' Lives - <AUTHOR> http://warisboring.com/articles/super-glue-built-planes-nukes-and-saved-soldiers-lives/ <comment><USER2> Super glue will be needed to hold the title together as well, since an Oxford comma wasn't used.

</comment><comment><USER3> This is why The Right to Try is so important.

[http://www.wsj.com/articles/the-right-to-try- revolt-14235273...](http://www.wsj.com/articles/the-right-to-try- revolt-1423527365)

In the 1960s:

"FDA scientists put massive implants of super glue in rats, which caused tumors — some of them malignant. Almost anything that massive would cause a tumor," Coover told the Chicago Tribune.

And finally in 1998:

"The FDA didn't cave in to overwhelming research findings and international experience until 1998, when it finally reclassified cyanoacrylate for topical use"</comment>


Neptune Memorial Reef - <AUTHOR> https://en.wikipedia.org/wiki/Neptune_Memorial_Reef <comment><AUTHOR> Came across this when reading about Julia Child, since her ashes were placed on the reef</comment>


The British Ruby Conference has been cancelled - <AUTHOR> http://2013.britruby.com <comment><USER2> Reading the twitter stream (<https://twitter.com/joshsusser/status/269844125363339264>), I find it odd that one person comments that the lineup is "100% white guys", and then all of a sudden it's a foregone conclusion that the BritRuby organizers are sexist.

Even @johnsusser is a bit much with his comment: _@BritRuby I don't think adding diversity at the end works. You have to start with it as one of your goals. Who wants to be the token female?_

IMHO, I find that sentence insinuating that, unless you start with diversity as your goal, you are just racist/sexist/-ist. This is the wrong approach from the start; just perform a call for papers process and take the best ones.

If one looks at the speaker list, they seem to be from non-3rd world countries. Where are the dirt poor people speaking at this conference? I'm going onto Twitter to state that BritRuby is class-ist.

And while we're at it, I'm pretty sure (but I'm guessing here) that all of the speakers can speak. That's quite discriminatory to those people who cannot speak, but can code in Ruby.

Should I continue or can we just get on with the conference and be inclusive, instead of this faux discrimination bullshit?

<comment><USER3> If you don't have diversity as one of your goals (either from the start or tacked on at the end) you are part of the system that perpetuates racism, whether you like it or not.

2010: "We're not racist, but oh look, we organized yet another conference with 100% white guys, wonder why that happened. But really, we're not racist."

2011: "We're not racist, but oh look, we organized yet another conference with 100% white guys, wonder why that happened. But really, we're not racist."

2012: "We're not racist, but oh look, we organized yet another conference with 100% white guys, wonder why that happened. But really, we're not racist."

Yeah, okay.

<comment><USER4> I'm sorry for whoever downvoted you for disagreeing with them. Normally we're better than that.

I'm on the fence for the kind of thinking you suggest.

On one hand, the phenomenon you describe _does_ happen -- it's what MLK referred to as "the mythical concept of time." That if an un(der)represented group just waits patiently, they'll be alright. The idea that they'll get rights when the courts decide so, or that they'll get a decent education when they test well enough, or that they'll get reasonable jobs when they can afford to commute there.

I think people get upset about these observations because they think the observer is attributing malice. "Racist" is a strong term that elicits an emotional response -- people thinking of the Deep South in the 50s. I don't think that the British Ruby Conference planned on an all-white all-male conference, and I don't think any reasonable person believes that they explicitly denied presenters because they were black, or hispanic, or gay, etc.

But it's also true that year after year we see this. To be transparent, as a white male, I sympathize with meritocratic thinking ("the best person should get the job"). And I understand why people get upset over affirmative action- like policies. But what we're doing now isn't working, and I don't know the answer.

What I do know is that both sides need to be able to acknowledge that there are reasonable views and goals across the board in this debate. The emotional language that comes with this is polarizing, and people are defensive, and people are indignant, etc. We need to discuss this reasonably, and this is a forum that should be able to, but frequently doesn't.

<comment><USER5> Year after year, new people start running conferences. And year after year, people have to point out that running a conference while paying no attention to diversity will (a) ensure that your conference fails to represent whatever diversity _already_ exists in your community, and (b) do nothing to encourage further diversity in your community. It's unsurprising that the people who've been making these arguments over that time get frustrated - they've had to keep on making them in the face of wave after wave of naive conference organiser.

Sometimes an emotional response is justified. Sometimes rational discussion gets you nowhere. Sometimes it really is just time for people to say that they are sick of this bullshit and they aren't going to take it any more. In this case, the conference organisers clearly weren't acting in bad faith - but nor had they put even the most cursory effort into making themselves aware of the issue. That shouldn't be considered acceptable behaviour these days, and if rational discourse hasn't led to it being considered unacceptable then maybe emotional responses will do.

<comment><USER4> I'm not disagreeing with your first paragraph -- that's what I was trying to acknowledge in my original post.

And I think there are many people who share the viewpoint of your second paragraph. Personally I don't think I do -- compromise is rarely made in the name of strong emotion. But I understand where these feelings come from. After all, for every MLK there is a Malcolm X. Maybe it's a combination of these forces that facilitates change. I have no idea, and can't speak about much else other than the fact that there are reasonable goals on both sides of this debate. We should be working towards them.

<comment><USER5> Oh, it's definitely a combination of the two that engenders change. If the calm, reasoned position is the only one expressed, the compromise position will never reach it. You need an extreme position in order to shift public perception to the point where the calm, reasoned position _is_ the compromise position.

</comment></comment></comment></comment></comment></comment><comment><USER6> I am a ticket holder. I can not understand even a little bit the reason why it get cancelled. If I get it right, the reason is there are not enough female speakers? Seriously, if that is not gender inequality then what is?

</comment><comment><USER7> Having just finished a conference yesterday - <http://indieconf.com> \- I feel like throwing in a few words on speaker selection. OK, maybe a whole bunch, as I blogged about this a couple weeks ago:

[http://indieconf.com/2012/how-does-a-conference-select- speak...](http://indieconf.com/2012/how-does-a-conference-select-speakers/)

For my perspective, the idea of _only_ opening up a call for speakers and just 'picking the right ones' doesn't work very well. Or at least, I don't think it works very well for conferences just starting off which don't have a lot of reputation to fall back on. Borrowing some of this reputation by getting some 'superstar' speakers might help a bit, but if you do that before a CFS, you've already done some preselection.

From year one, I had a call for speakers process open, but I also had some particular speakers I wanted to talk on specific topics. I had probably half the speakers/topics nominally on board (not officially at that point) during the first year CFS, and fleshed out the rest of the slots with submissions - some of which were really good angles I hadn't thought of.

However, imo, the role of a conference organizer is largely curation of an experience, and you have to have an idea of what you want that experience to look like early on. And for me, gender is a factor - it's not a major one, but I made sure to encourage some females in my network to submit. At the same time, there were some submissions and applications from females that I didn't bring on board the conference this year, because they didn't quite fit the vibe I was shooting for.

Anyhow, sorry to see they've cancelled this. I know all too well how hard it is to organize something, and to be discouraged enough to pull the plug like this was certainly not fun or easy for the organizers. I wish them luck in future projects like this.

EDIT: Couple more thoughts - how you run the event the first year has an impact on how people view your event in subsequent years. I get props every year on the food, but mostly because I take the extra 10 minutes to organize vegan and gluten-free options, and I get people coming back partially based on the fact that I've done that (had people buy tickets and tell me that). Example: <https://twitter.com/alanstevens/status/269856351214268416>

</comment><comment><USER8> I'm pretty furious about this. I was really forward to having a reasonably- accessable world-class ruby conference in UK. I'm really only care about whether the speakers are interesting and that I can learn from their talk.

I hope that race & gender aren't used (positively or negatively) to assess the quality of speakers.

<comment><USER7> Race and gender can be (generally _are_ ) used by potential attendees to determine what comfort level they'd have at an event like that. The more people you can get to your event, generally the better the outcome will be - increased connections, networking and exchange of ideas from a broader range of people.

I made an earlier comment about my recent experiences organizing a conference, and linked to my blog which touched on this very reason.

<comment><USER8> Thanks, I hadn't considered that, and it's a good point.

Although perhaps I'm an oddity: I rarely see myself as among the speakers so I don't look at them as a guide. Also, I've been to "gender-equal" conferences where almost the only women there were speakers. So speakers != audience

<comment><USER7> Speakers != audience all the time - the audience won't be an exact match for the speaker demographics. But having done this for a bit, I've had enough feedback that indicates that having a more balanced/diverse set of speakers is a signal to a wider audience that there will more likely be a wider range of attendees to socialize and network with. Again, yes, not 100% all the time.

FWIW, at indieconf we had about 30% of the speakers were female. About half of the attendees were female as well. Interestingly 30% answered the 'gender' question as female - 30% answered 'male', 30% left blank - I'm assuming based on names given about half of the remaning were also female - that's where I'm getting the ~50% were female.

</comment></comment></comment></comment><comment><USER5> Paying attention to diversity doesn't mean picking worse proposals. It means ensuring that minority groups in your community submit proposals in the first place. It means being aware that proposals written by minorities are likely to sound less confident and may understate the value of their content. It means ensuring that your conference has a clear statement of supporting members of minority groups who may feel uncomfortable in a space dominated by white men.

If your defence against claims of your conference lacking diversity is "Well, all our proposals came from white men", that's _your fault_. Countless other technical conferences around the world can attract proposals from community minorities. If you can't, you're doing it wrong.

<comment><USER9> >It means being aware that proposals written by minorities are likely to sound less confident and may understate the value of their content.

Why do you assume that the color of someone's skin will make them less capable of writing a good, confident proposal for a conference. You are suggesting that you weight the value of the proposal based on the race of the person who submitted it.

<comment><USER5> Because there's strong social pressure that encourages anyone other than white men to sound less confident about their ability. Failing to take that into account means that you're not actually engaging in meritocracy.

<comment><USER10> There is? Is that pressure getting stronger or weaker? How will we know when it no longer exists?

</comment></comment></comment></comment><comment><USER11> People will whine about anything, unfortunately they'll do so into the amplifier that is Twitter. On behalf of everyone that was going to go (myself excluded), thanks for nothing you whinging, impatient keyboard-slacktivists.

</comment><comment><USER12> This is very disappointing, the community has moved from calling out concrete examples of sexism to dog piling on anything where a circumstantial case can be made. Not very MINSWAN*

The only solution I can see is to make the process 100% transparent and show all invitations and refusals online - maybe even move to a voting system a la SXSW.

*Matz (the inventor of Ruby) is nice so we are nice

</comment><comment><USER6> <https://twitter.com/BritRuby/status/270221926490857474>

"#BritRuby's decision to cancel was thought-out and based mainly on financial implications that arose from what happened on Twitter"

</comment><comment><USER13> It's sad how much damage can be caused by the ripple effect. First the sexualized presentations and sexist invitations, and now the TSA-style response to every hint of sexism. Conference organizers shouldn't have to worry about forcing diversity into their line-up. It starts with schools and universities, and every child having equal opportunities to tinker with computers.

Does anyone have evidence that the @BritRuby organizers intentionally excluded anyone? Has anyone ever said 'I am an experienced Ruby developer and speaker, but I feel that I was excluded based on my race or gender"?

If you really care about the issue, then there are far more productive ways to shift the balance than posting comments on twitter. I think the cancellation is a ridiculous over-reaction, and I still don't understand why 100% white males is a big deal. My Ruby meetup group is diverse, but noone is there because they feel the need to represent their race or gender. We're just all interested in Ruby!

</comment><comment><USER14> These two posts from actual successes building more gender balanced tech conferences will give a better perspective on the core issue (gender and ethnic diversity):

"Beating the Odds — How We got 25% Women Speakers for JSConf EU 2012" [http://2012.jsconf.eu/2012/09/17/beating-the-odds-how-we- got...](http://2012.jsconf.eu/2012/09/17/beating-the-odds-how-we- got-25-percent-women-speakers.html)

They were themselves inspired by:

"How I Got 50% Women Speakers at My Tech Conference" [http://geekfeminism.org/2012/05/21/how-i-got-50-women- speake...](http://geekfeminism.org/2012/05/21/how-i-got-50-women-speakers-at- my-tech-conference/)

To summarize, it takes lot of effort and thought. But it's totally doable with outreach + anonymization.

</comment><comment><USER15> I was the curator and co-organizer of RubyFringe and FutureRuby in Toronto. I'm really sorry to hear that folks organizing BRC felt so beat down by negativity that cancelation was the best option. Most people simply do not appreciate the hundreds of unpaid hours of work that are required to pull off a good event.

Several aspects of this controversy don't sit well with me, however. First off, since when does the curation of a conference have to follow someone else's value system? It's very simple: the people that organize an event should work hard to put together the most interesting line-up they can. It's then up to the potential attendees to decide if the event is worth their time to attend. That's it; there are no more rules!

If you want to solicit proposals for talks, go ahead. If you like some of them, give them a shot at speaking. If you decide that none of them match your curatorial agenda, then thank them warmly for their submission and move on. You aren't obligated to take proposals at all, and you're certainly not obligated to make your decision process transparent or part of some laborious community democracy. In fact, I would guess that one strongly opinionated curator will put together a far more coherent line-up than any popularity contest ever could. If you're looking for inspiration, consider asking attendees from previous years if they'd like to consider "leveling-up" to speaker.

When I put together our speaker lists, it wasn't arbitrary and much like test driven development we didn't just start emailing random smart people. We started with strong themes for the entire event, ideals that could pull together folks and be both entertaining and challenging. Those themes directed our branding, our choice of talks and the after-hours entertainment, which in our world is just as vital to the conference experience as anything else.

Not all meritocracy is bad. Conference curation is one such domain where winning has far more to do with subject diversity, pacing and the element of surprise than arbitrary quotas for gender, race, age or class ever could.

I'd say that the best metaphor for future curators to use is building a deck of Magic the Gathering cards. You need the right balance of mana, summon and sorcery cards. There are five colors but to be effective you choose 1 or perhaps 2 at most. And most importantly, you design your deck around a theme which is based on a hypothesis for winning which you think brings something new to the table. Most of the strategy for winning at MtG happens before game play starts, and if everyone had a say in how you built your deck, it wouldn't be very fun to play with such an unnecessarily shitty deck. You could call it the "Stop Hitting Yourself!" deck.

There's a difference between fighting for a developer community free of sexist bullshit, and pretending that a conference built on arbitrary values for diversity is automatically better than one where you nail a theme and everyone leaves happy. Those who disagree are likely to simply skip my conferences, and that's perfectly fine.

Finally, we did both of those events with no sponsorships. We cost less than an O'Reilly-backed RailsConf event and we provided logo-free swag, great wifi, amazing food, three nights of entertainment with an open bar and we helped speakers with travel and lodging while still managing to break even. It's simply not true that you can't do a successful conference without sponsors. You just have to charge money to attend, and be prepared to help those who are having financial issues find ways to volunteer.

[http://www.rubyinside.com/rubyfringe-success-and- roundup-956...](http://www.rubyinside.com/rubyfringe-success-and- roundup-956.html)

<http://unspace.ca/blog/rubyfringe-what-now>

<http://railspikes.com/2008/7/27/rubyfringe-recap-and-slides>

RubyFringe and FutureRuby are two of the things in my life that I am most proud of. My heart goes out to the organizers of BRC, and I encourage you all to try again next year but ignore the noise and focus on building the best deck ever seen.

<comment><USER16> I helped to organise the last Ruby Manor conference (<http://rubymanor.org/3>). As an experiment, we built a web app (<http://vestibule.rubymanor.org/>) which allowed anyone to submit, discuss and vote for proposals. When voting closed, the 8 most popular proposals were automatically selected.

The result? 8 white guys giving talks (<http://rubymanor.org/3/videos>).

We're going to try something different next time, but who knows if that'll work any better.

<comment><USER17> Is it brash to suggest that maybe those "8 white guys" actually did have the most merit out of all candidate speakers, and that you would have done the conference a disservice by bumping one of them for someone else, based on sex or gender alone?

Whatever racial or gender or economic biases might exist that influence the shape of the global developer community, these need to be addressed at the source: in kids' youth when many programmers take on computers as their lifelong obsession, or in high school curricula and college programs.

The conference organizer's job, as it pertains to race and gender bias, is to provide a neutral selection process that chooses the best speakers on their own merits. Their job is not to diminish the quality of the conference by imposing their own, nobly intended but horribly misguided, form of bias on the candidates. More than hurting just the conference or the candidates, I fear that this can have serious unintended consequences relating to public perception of the quality of e.g. female programmers, in the same way that "affirmative action" does on college campuses.

<comment><USER18> I think a simple estimate of the composition of the "most merit of all candidate speakers" could be to compile statistics of the contributors to the 1000 most popular gems and rails-core, or something similar. There's more heat than light in this controversy, and for a discipline that prioritizes CS techniques as a proxy for skill the flashlight is readily at hand.

<comment><USER15> While I appreciate that you're looking for solutions instead of trying to amplify the finger-pointing, the approach you are imagining is not going to generate a very good speaker line-up.

There are a huge number of variables to consider when planning a speaker line- up. As I said before, the best conferences are carefully crafted around a theme or issue. Even in the case of a regional conference, it doesn't require that the speakers live nearby. Just selecting popular, smart or friendly devs is not a theme unless your theme is "Random". :)

Sometimes there's a milestone library or development approach that you want to shine a light on. Perhaps 5 of the top 10 gems are template engines or test frameworks, and in 2012 that's a dull theme. Factually, some developers are great speakers, but many are not able or willing to give a good talk. Some speakers are amazing but have nothing interesting to show off or discuss.

Some speakers live far away or have special needs. You might be able to afford and accomodate one or three, but a roster of expensive tickets would make the event lose money.

However, the biggest reason that the algorithmic curation approach is not going to work is that curation is less like selling seats on a plane and more like making a mix tape for a fickle lover. You need to delight, surprise and enrapture people. A month after the event, they remember not what was said but how they came away feeling. It's hard but worth it to find ways to inject ideas that people are not expecting.

<http://www.infoq.com/presentations/glouberman-noises>

[http://www.infoq.com/presentations/sieger-jazzers- programmer...](http://www.infoq.com/presentations/sieger-jazzers-programmers)

<http://www.infoq.com/presentations/hirsh-california-ideology>

<comment><USER18> It wasn't meant to generate a line up, only to provide some idea of demographics. You have to start somewhere, even if only to figure out how true "curating on merit gives you white guys" is.

</comment></comment></comment></comment></comment></comment><comment><USER19> I worked with what became the Brit Ruby team on the Magrails conference last year, which did have a female speaker in the form of the excellent Rachel Davies, who is a leading Agile coach

I know the guys had the (perhaps unstated) ambition to get as many of the Ruby Rogues in a room and create the largest conference in Europe. The Rogues are all men, but if you listen to the podcast you will know that they all care deeply about these issues and have taken steps themselves in events they organise to make sure that there is no bias.

I was the old guy in the corner with Magrails and it was me who originally mooted the idea. I do remember we had some pressure from sponsors to do things like drive traffic to their websites, I was all for returning the cash and doing without their support because it was so annoying, we were creating a space for the community to gather and talk about Agile development using Rails and if we weren't driving traffic maybe they needed to make their product more compelling instead of blaming us. ;)

If I had still been on the team I would have been arguing strongly to tell the nay sayers to get their own ass in gear and submit proposals, or shut up, assuming they weren't themselves the white guys they seem to see everywhere.

The reason for sponsorship was to keep the ticket cost somewhere affordable by the jobbing developer, while still being able to pay for accommodation for the speakers. I know that a lot of people will come and talk anyway, self funding, but it's a big ask if you want some of the leaders from the US to come. Plus the cost of decent sized venues in Manchester is not cheap. Putting on Magrails cost a lot, let me tell you, and we have less than £100 left in the bank account.

</comment><comment><USER20> Can anyone explain what happened?

<comment><AUTHOR> It seemed because of complaints regarding race/gender diversity of speakers on twitter.

I think it started with this tweet: <https://twitter.com/joshsusser/status/269844125363339264>

<comment><USER21> Am I just missing something here or did they seriously cancel an entire conference just because of some random dude on Twitter imagining some nonexistent racism/sexism in the speaker lineup?

He's making this up in his own mind. Who's the real discriminator here?

<comment><USER22> > Am I just missing something here or did they seriously cancel an entire > conference just because of some random dude on Twitter imagining some > nonexistent racism/sexism in the speaker lineup?

According to <https://twitter.com/Rebeccask/status/270220165344550912> sponsors pulled out. It's not mentioned at all in TFAA though, so I'd don't know if the explanation's legit (and why they went with a non-explanation instead if it is)

</comment></comment></comment></comment><comment><USER23> If you're a conference organizer and struggling to find local women to speak at your event, it's often worth putting in a call to your local Google office. If you can show that your event has a decent level of organization & chance of success, they have a well-established Diversity Grant program where they'll give conferences funding to fly in and house prominent female speakers which smaller conferences often wouldn't have the budget to do.

Interestingly, it's run totally separate from their normal event sponsorship program. A friend was organizing a local Ruby conference and couldn't get any monetary sponsorship from Google (they said they needed six to eights months lead time to budget for it), but in a month or so turned around a diversity grant package to bring in female speakers and attendees that was worth several times the financial sponsorship that was initially asked for.

</comment><comment><USER24> Awesome example of awful business writing.

</comment><comment><USER25> Here's a thought - why not make the speaker selection process double blind, like medical trials. Whoever is reviewing submissions, should not have access to the authors' info. Though this is not perfect, it does provide a way for conference organizers to silence all criticism about demographics... #justathought

</comment><comment><USER26> They should have invited Matz

<comment><USER6> They did, Matz has not replied yet <https://twitter.com/BritRuby/status/269853833503588352>

</comment></comment><comment><USER27> Black people and women are so linguist. Not submitting talk proposals to Ruby conferences is just disrespectful.

edit: Just found out raganwald submitted a talk proposal to BritRuby. Turns out my racist general remark was entirely misguided and black people might actually not be linguist at all. A shame his talk wasn't accepted. I'd like to hear more about method combinators :)

<comment><USER28> It's irrelevant anyway since BritRuby didn't get a chance to pick proposals and announce speakers.

They were criticized on their invite list rather than their chosen proposals which were never made public :-(

<comment><USER27> Wow.. that's even more sad than I thought.

btw, thanks for scrolling down to see my comment, it was lonely down here :D

<comment><USER28> Haha, I did see it at the time, but on a revisit I noticed your update so I thought it was worth pointing out ;-)</comment></comment></comment></comment>


Show HN: Dynamic graph connectivity data structure - <AUTHOR> https://github.com/mikolalysenko/dynamic-forest

<comment><USER2> I'd like to know more about the use-case and advantages here. Anyone have professional experience with the cost/difficulty of maintaining spanning forests?

<comment><AUTHOR> The advantage of using the library is that you would be able to answer connectivity queries and traverse the connected components of the graph efficiently.

EDIT: If you want an example application, suppose you have a physics simulation with a bunch of connected rigid bodies. You would like to be able to quickly test if two boxes are connected by links to the same body or to detect if after breaking a joint the resulting body becomes disconnected into two different pieces. Using a data structure like this would be faster than brute force searching over the graph of all bodies every time you change a link by connecting/disconnecting two bodies.</comment></comment>


Ask HN:  Do you know of any time travel combinatorial puzzles? - <AUTHOR>

I've been trying to think of an interesting time travel combinatorial (e.g., Rubik's Cube-like) puzzle, but with no luck so far.<p>Are there any interesting ones I could look at? <comment><USER2> This is not quite what you want, but there are quite a few 4D puzzles.

iirc, Scott Kim, who did many of the illustrations for Douglas Hofstadter, wrote a paper presenting an optical illusion only perceivable in 4 spatial dimensions ("The Impossible Skew Quadrilateral: A Four-Dimensional Optical Illusion").

<http://www.superliminal.com/cube/cube.htm>

[http://en.wikipedia.org/wiki/N-dimensional_sequential_move_p...](http://en.wikipedia.org/wiki/N-dimensional_sequential_move_puzzles)

There is a 4D variant of tetris, such as <http://illusions.hu/4dtris/>

</comment><comment><USER3> I don't know if it is exactly what you are looking for but here is a game that came up a while ago on HN where you need to go back in time and have your robots do things to allow the other robots to make it to the door: <http://news.ycombinator.com/item?id=244594>

Pretty fun game for a little diversion though it gets old after the 3rd teeter-totter level.

<comment><AUTHOR> Yes, that's very cool, but can something interesting be done with an abstract combinatorial puzzle?</comment></comment>