

Beautiful Failure - raganwald
http://github.com/raganwald/homoiconic/blob/master/2010/01/beautiful_failure.markdown#readme

======
mojombo
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.

------
ajross
_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".

~~~
raganwald
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.

------
blasdel
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.

~~~
raganwald
That's really interesting, thanks!

------
j_baker
"I suggested that IDE features are language smells."

I _love_ this quote.

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

~~~
iamwil
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.

~~~
j_baker
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. :-)

------
cpr
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.)

~~~
epe
_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?

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

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

------
collint
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?

~~~
aaronblohowiak
You'd probably like Codekana and Ngedit. <http://www.ngedit.com/>

~~~
collint
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.

------
Tichy
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.

~~~
raganwald
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.

