Beautiful Failure | Hacker News Reader

Beautiful Failure

github.com

71 pointsraganwald25 comments

Erlang has the ability to keep two versions of a compiled module in memory at once (but only two, not three or more), making it possible to do hot code updates and achieve zero downtime upgrades. The message passing architecture makes this possible by swapping the old code out at a message processing boundary (letting the current cycle complete before loading the new code in). This can be seen as a limited implementation of a version-aware runtime.

The irritating problem with this is when two different pieces of code--such as two separate gems--both attempt to add the same method to the same class. Classes are global in Ruby, so we end up with a race condition in our code.

Obviously not the point of the article, but it's still important to get your jargon right. This isn't a race condition. It could be, if you were trying to modify the same class from separate threads. But the mere attempt to share access to a global variable is not a synchronization bug, and you shouldn't be using synchronization terms for it. This is usually just called a "namespace collision".

Excellent point, thanks! Although it feels like one in that the behaviour sometimes comes across as a Heisenbug: depending on the order the environment loads various gems and files, you can have a code that sometimes does one thing and sometimes another.

This is also wrong. Classes aren't global in Ruby. Classes are just Objects. Constants have weird scoping issues. you can get into some really weird conditions when you start doing interesting metaprogramming. For instance, try .dup'ing a Class object whose implementation refers to another class via its name. You will get an error that the constant can't be resolved.

Protocol Buffers (and systems patterned after them) give you version control for your data structures, which are far more important than code and far harder for refactoring tools to handle.

It can be like ActiveRecord migrations but for live wire protocols -- independent apps built against different versions of the structure definition all see the data in the form they expect, not the form it was sent in. protobuf and thrift only support the simple case of adding new fields in new versions, but binprot supports full translation functions: http://janestcapital.com/?q=node/41 -- and none of them involve an iota of on-the-wire self-description bloat.

That's really interesting, thanks!

"I suggested that IDE features are language smells."

I love this quote.

What you want is a language that is also an IDE. Smalltalk did this 30 years ago.

I don't think that's what he's getting at. Much of the developer support built into IDEs are there because it's too much for the programmer to handle. His assertion is that it's because it's a weakness of the programming language that we need to do that.

Have IDEs that generates boiler plate code? Then perhaps the language is too verbose, or not powerful enough to express templates of code. Have IDEs that auto complete variable names for you? Perhaps there are too many and your program is too big to fit into your head.

This exactly. I had a programming languages professor whose hypothesis was essentially: "Programming languages were invented to minimize program complexity. So why are there so many tools to manage their complexity?"

Although in fairness, it isn't necessarily a language smell. It can oftentimes be a framework smell or a "your code sucks" smell. :-)

A lot of what he's talking about is done automatically when you're using a classic Smalltalk/Squeak environment.

(E.g., names are in one place. Refactoring can happen automatically, because the IDE can find all uses of a method and fix them.)

There's no idea that a single class might have two versions and that some bits of the program depend on the old version and some on the new. Why not? Why isn't live, running code versioned and transactioned so that we can release a patch of a few classes into a running server without taking it down? It should be possible for the old code to handle all of the existing requests and then get garbage collected when it has no further dependencies.

Isn't this also something that Smalltalk can do?

It's also something Ruby can do, when running on MagLev.

It is not a coïncidence that MagLev came from the Smalltalk community. See all the other comments here :-)

Yes. You can even have the new version get the function that called it and change the implementation of the caller so your code re-factors itself. Not that I'd recommend this, but you could do it =)

Most smalltalks ship with method and class-level versioning with browsers. Full discussion of this is here: http://objectmix.com/smalltalk/16421-version-control-systems...

Eclipse is an effort to bring the advancements of smalltalk to java programmers, as the smalltalk community got absorbed by the java borg (see also: hotspot vm history.)

How does that differ from using Eclipse with Java?

(Interesting sidebar: Eclipse is a descends directly from Smalltalk)

Eclipse attempts to bolt-on features external to the runtime to make it appear integrated. The smalltalk implementations offer exactly the kinds of changes you are asking for in your post. see my comment above.

I agree. But the name problem is only one small piece of the text problem. Text is a great deal better than punch cards and that is even a greater deal better than writing things on paper and physically setting the switches.

There exists a grotesque obsession with text and the tools to edit text among programmers.

My editor of choice can give me a great deal of help when writing HTML markup. It's actually quite amazing how good an editor can be.

But I can still jump off the track and remove a "<" where there really should be one. No, that's not really useful to me at all. I'd be much better off in a world where the angular brackes, quote marks wrapping strings, and other arbitrary delimiters of the ENCODING didn't really exist at all.

I'd much rather edit a DOM directly than through the looking glass of text.

An film editor would never open up his final cut project files and tweak them by hand. He has far better tools that more appropriately fit his domain. Why not me?

Have you ever used final cut? I really don't want to live in a world where I can fix my logic by re-aligning things to a pixel grid.

The reason programmers use text is that you can input text much faster than you can drag and drop things together, it's easy to massage with simple scripts, and if the vendor-du-jour's IDE is broken, incomplete, or unsatisfactory we can go outside of it without having to deal with some arbitrary binary file format.

Seriously, you need to make a better case that a visual language would be an improvement instead of another reason to become a park ranger.

The stock response to this is that "abstractions are leaky." For the DOM, it's conceptually nice to be able to just operate on the tree, but as soon as you start dealing with browser bugs (or even just browser-specific functionality) the chances are that it'll just break, and the system will end up more complex than if you'd just stuck with text.

Also, presumably you'd want a non-textual Javascript layer to go with your non-textual DOM layer. I think the jury's still out on general non-textual programming.

I think the reason programmers get hung up on text and its editors is that it's like C: it's the lingua franca. Every system uses it at some level, so if you've got a good tool for using it, it's applicable to any domain you care to look at. Without it, you'd be reduced to domain-specific abstractions which might not have any wider applicability at all.

You'd probably like Codekana and Ngedit. http://www.ngedit.com/

I'm solidly anti-text. And as a hobby work on non-text programming tools.

It's entirely unproven. But I hope one day I can say it's a better way to do things.

Seems easy to fix the "too many files touched to fix a bug" problem: just write the whole code in one big file. Lot's of languages allow you to do that.

My goal was for as few files as possible in each commit, and as few commits as possible for each file. One big file solves the former problem at the expense of the latter.

Reply on news.ycombinator.com