3 ms·

Beautiful Failure

71 points by raganwald 17y ago

ajross 17y ago
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 17y ago
  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.
- aaronblohowiak 17y ago
  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.
cpr 17y ago
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.)
- raganwald 17y ago
  How does that differ from using Eclipse with Java? (Interesting sidebar: Eclipse is a descends directly from Smalltalk)
  - aaronblohowiak 17y ago
    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.
- aaronblohowiak 17y ago
  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-smalltalk.html 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.)
- epe 17y ago
  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?
  - aaronblohowiak 17y ago
    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 =)
  - avibryant 17y ago
mojombo 17y ago
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.
blasdel 17y ago
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 http://janestcapital.com/?q=node/41 -- and none of them involve an iota of on-the-wire self-description bloat.
- raganwald 17y ago
  That's really interesting, thanks!
j_baker 17y ago
"I suggested that IDE features are language smells." I love this quote.
- coliveira 17y ago
  What you want is a language that is also an IDE. Smalltalk did this 30 years ago.
  - iamwil 17y 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.
    - j_baker 17y ago
      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. :-)
  - deleted 17y ago
    [deleted]
collint 17y ago
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 17y ago
  You'd probably like Codekana and Ngedit. http://www.ngedit.com/ http://www.ngedit.com/
  - collint 17y ago
    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.
- krakensden 17y ago
  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.
- regularfry 17y ago
Tichy 17y ago
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 17y ago
  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.
deleted 17y ago
[deleted]

71 points by raganwald 17y ago

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 17y ago
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.
aaronblohowiak 17y ago
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.

cpr 17y ago

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

raganwald 17y ago
How does that differ from using Eclipse with Java? (Interesting sidebar: Eclipse is a descends directly from Smalltalk)
- aaronblohowiak 17y ago
  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.
aaronblohowiak 17y ago
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-smalltalk.html 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.)
epe 17y ago
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?
- aaronblohowiak 17y ago
  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 =)
- avibryant 17y ago

mojombo 17y ago

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.

blasdel 17y ago

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 http://janestcapital.com/?q=node/41 -- and none of them involve an iota of on-the-wire self-description bloat.

raganwald 17y ago
That's really interesting, thanks!

j_baker 17y ago

"I suggested that IDE features are language smells." I love this quote.

coliveira 17y ago
What you want is a language that is also an IDE. Smalltalk did this 30 years ago.
- iamwil 17y 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.
  - j_baker 17y ago
    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. :-)
- deleted 17y ago
  [deleted]

collint 17y ago

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 17y ago
You'd probably like Codekana and Ngedit. http://www.ngedit.com/ http://www.ngedit.com/
- collint 17y ago
  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.
krakensden 17y ago
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.
regularfry 17y ago

Tichy 17y ago

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 17y ago
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.

deleted 17y ago

[deleted]