Are you kidding me?
PJ Hyett relays this from a JavaLobby thread:
Have you ever tried to go back an make significant changes to a large Smalltalk application that you haven't touched the code for in 3-5 years or maybe didn't even a part in writing? Try that some time if you haven't and then tell us what you think of Smalltalk. If a language can't pass that battle test, it sucks. IMO, Java passes that test very well, much better than Smalltalk or C/C++.
Well, yes. I've picked up Smalltalk code at customer sites that I've either:
- Never seen before
- Have not seen in years
It's never been a big deal to figure out what's going on, even with large codebases that are badly written (and yes, I've seen plenty of large, badly written Smalltalk systems). I spent a number of years as a C programmer previously, and leaving code alone for a week or two would result in a long period of ramp up - along with lots of printouts. I've been using Smalltalk for 13 years now, and I've yet to print code out in order to understand it. Back in the C language family, printing code out in order to eyeball it was a constant experience. Smalltalk, in my experience, is vastly easier to pick back up than C, C++, or Java code. Ruby, I have no idea, but I expect it falls over on the Smalltalk side in terms of ease of pickup.
Comments
Familiarity
[Justin Rudd] September 18, 2005 19:14:26.668
I think a lot of this is familiarity. You use Smalltalk almost exclusively. I use C++, Java, and C# exclusively. I can look at projects that I worked on years ago and pick up where I left off usually within a couple of hours. There is only one C project that I wasn't able to make heads or tails of and it had nothing to do with the language. The developer decided to name every variable a swear word. And functions were basically combinations of those swear words made into verbs :) Interesting project to say the least... With that said, I can pick up someone elses Ruby code and pretty much figure out in an hour or so what is going on. And I don't use Ruby that often. It is much easier to read. And I've been meaning to dig into Smalltalk again since languages like Ruby are so similiar. Might as well learn at the source.
Justin...
[ James Robertson] September 18, 2005 19:32:24.513
Comment by James Robertson
There's a lot of that, but I specifically recall trying to grok other people's C code back when I did that exclusively. It was a lot harder.
Yeah...
[Sean M] September 18, 2005 20:06:33.126
The worst of C is when someone decides to program by macro.
Macros are fine some times. But if you start to write multi-line macros I think perhaps code is showing off some sort of design flay (I'm thinking of a specific case I deal with on a current project where they generalised a whole lot of Windows APIS call into a GENERALDISPLAY macro, but the macro contents contains refs to structures with the same names, but different layouts...
Compiler errors in those are fun
I'll take badly written Smallatlk (That would be *ahem*, my own) over any C/C++.
[sander] September 19, 2005 3:14:39.378
Don't think it is really a language issue. I've seen badly written code in many languages.
No REPL ... No Thank You
[Sanjay Pande] September 19, 2005 3:30:27.190
If a language does not have an REPL (Read Eval Print Loop) or code snippet evaluation, it is not worth my time. C, C++, Java and C# all fall in that bracket (Languages not worthy of my time). Give me Smalltalk, Lisp, Scheme or Python anyday over those. It really does not matter how bad the code is when you have that and yes you can write bad code in any language. One thing I will give to Smalltalk is that its hard to write bad code.
Groking highly factored code
[Terry] September 19, 2005 9:20:41.979
I understand where he is coming from.
It can be painful to try to understand smalltalk code that has been highly factored vs a few large routines. When you look at a few large routines, particularly if you print them out, I find that it can be easier to locate what the code dependencies are and what I need to change vs trying to trace though several layers of small methods.
I agree with Terry
[ Troy Brumley] September 19, 2005 10:40:16.295
Comment by Troy Brumley
This is a non-linear presentation that makes it more difficult for some of us to grok code in Smalltalk, or maybe anything that can be highly factored. There's a "wtf" interval that I still go through when I'm looking at most anyone else's code. Avi mentioned this difficulty that many people have approaching Smalltalk code in a comment on this literature post.
invisible sequence
[Isaac Gouy] September 19, 2005 12:49:47.162
James Smalltalk for 13 years now, and I've yet to print code out in order to understand it
Then you have yet to see really badly written Smalltalk :-)
With ordinary Smalltalk there's no point printing out the code because (as Terry and Troy mention) the source code isn't like prose text - Smalltalk source code is like hyper-media; Smalltalk source code is like a webpage full of URLs.
Of course, it is much easier to understand a little piece of functionality in isolation - the problem is that these little pieces of functionality are not in isolation, we have to figure out the preceding state changes, so we have to figure out the sequence of messages that led to this particular method send.
no REPLs - really?
[Isaac Gouy] September 19, 2005 13:02:00.631
Sanjay If a language does not have an REPL (Read Eval Print Loop) or code snippet evaluation, it is not worth my time. C, C++, Java and C# all fall in that bracket (Languages not worthy of my time).
Are you certain that those languages don't have a REPL, or is this an assumption based on limited information?
REPLs for C/C++
"DrJava : Using the Interactions Pane"