Getting Back to Smalltalk
railsrx.com
railsrx.com
No, it really doesn't. This is a constant headache in Lua too. See Dijkstra's comments on the subject here: http://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EW...
The natural numbers are generally considered to start at 1. Therefore, to people in general, such a system makes more sense.
Zero is not a "natural" number, in fact many societies / civilizations never even understood or used zero in arithmetic [1].
Yeah, but those societies were uniformly terrible at math.
If I hold up my fingers to indicate elements in an array, zero fingers means the array is empty. One finger is then, naturally, the first item: of index 1.
Counting elements starting at zero (for the first element) is still unnatural...
And you only need 1...N to order N bins and their contents.
Of course, most programmers don't have math degrees and I'd suspect that most people indeed think 1st element of an array starts at 1.
| 1 | 2 | 3 | 4 |
+-----+-----+-----+-----+
0 1 2 3 4
I'm not going to tackle whether Djikstra was right or wrong, but merely to point out that there's more to Smalltalk's indexing than meets the eye.
For what it's worth: I'm not a professional Smalltalk dev by any stretch of the imagination, but I've written enough Smalltalk to tell you that you very rarely deal with the indices, anyway. Nearly all Smalltalk code ends up just using comprehensions to navigate collections. Of the remainder, they're such trivial cases that the 1-based indexing is intuitive and does not bother me the way that it does in, say, Lua or really old Turbo Pascal programs where some coder got a bit too slap-happy on arbitrarily bounded arrays.
I don't refer to the first inch of a ruler as inch 0 or inch 1, I refer to it as the first inch.
There are two things being described which I think is a set up for confusion and the many off by one errors that I've seen as a result.
1. Coordinate.
2. Interval.
But, in my list of 2 items, I index with 1 and 2, not 0 and 1. But, be sure that the first item is 1.0 not 1.1 and the second item is 2.0 not 2.1.
ARGHL!
Smalltalk is a small language (think C), so you can learn the whole language set in a few days.
The live objects concept might warp your brain a little bit. I've heard lisp does the same, so if you're from a lisp background, you might not find it shocking.
The Pharo environment (IDE) can make all the modern IDEs (Eclipse, Visual Studio) look like babies in diapers.
There is built in versionsing, DVCS, refactoring tool, unit testing framework, The most powerful debugger etc....
You will not regret trying out Smalltalk (maybe you will when you have to go back to C++) :).
Hm, not sure about that. The language itself (as in: syntax) is indeed minimal. It is much smaller than C, not even having ifs and whiles but this only means you have to learn the relevant part of the runtime to start using Smalltalk.
Fun fact: if in Smalltalk is a pair of virtual methods on the Boolean objects. True implements ifTrue as "always execute the argument" and False as "ignore the argument" and it's the other way for ifFalse.
I agree with the rest of your comment - it is definitely worth trying.
Compare it to what you need to know about Java or C++ to understand all of a codebase in that language.
Not being able to use your own editor, whichever it is, and being forced to use something that is basically equivalent to plain old browser textarea is a showstopper for calling Smalltalk environments pleasant.
Maybe Gnu Smalltalk is a cure to that, since it doesn't have live image and you can use whichever editor you like, but that kinda defeats most of the benefits of Smalltalk.
I hear that SqueakVM has a package called nvi that can emulate Vi keybindings as well as emacs keybindings.
That's hardly an apt description. My Smalltalk environment has intellisense, auto-complete, syntax highlighting, and automated refactoring. I use Pharo.
Many years back, I tried Squeak a couple of times and it didn't click. Dolphin Smalltalk did that for me (and I then went back to Squeak due to other reasons). It has a well-designed, compact class library and a decent UI. I'm not sure if it has been updated to keep up with Windows, but it's a great start.
The important thing is having an environment that supports your eventual deployment requirements and also supports short term fast development requirements.
To the best of my knowledge, there exists no faster environment to think and code in. SLIME come close, but it's too textual and doesn't seem as fast.
Much of the power of Smalltalk comes from the environment. It is pretty amazing how even now parts of Smalltalk are more sophisticated than todays programming tools.
Dan Ingalls: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.h...
Alan Kay mentions this idea in relation to Lisp and Smalltalk: http://www.youtube.com/watch?v=tQg4LquY0uU (It's buried somewhere after 24 minutes.)
It's tagline is "The Smalltalk for those who can type".
However it doesn't look very lively, and you'd be pretty lonely. I don't know any projects using GNU ST. Squeak, and now Pharo, are really the only implementations with momentum right now.
And as far as the typing thing... I am a die-hard Emacs user, and I still enjoy Pharo. This is because programming in Smalltalk is not so much about writing and editing code as it is working with objects. And, frankly, Smalltalk's way of working with objects (and remember: classes and their methods are just objects) is much more powerful than the average editor's way of working with source code.
(I'm basing this on the code for SmalltalkHub, which at least used to be available on SmalltalkHub, and which had Pharoisms in the code base. It's entirely possible they simply moved those pieces over to GNU Smalltalk, though.)
The two problems I have with it are simply that it's far slower than Pharo or Squeak, and that using the GPL for a Smalltalk makes me extremely nervous, since the concept of a derivative work gets really dicey when any half-decent Smalltalk app is going to end up throwing new methods into the base library.
This is part of the paradigm shift!
That means that you'll be spending a fair bit of your time editing, which means that you'll want the ability to use your editor of choice, rather than being forced to use someone else's editor of choice.
This has follow-on effects: refactoring, TDD and patterns are so much easier when the code resides in tiny snippets.
It's a whole new world, where the code is 'live' rather than merely contained in static 'dead' text files...
It has nothing to do with how reliable smalltalk is. With such an alien paradigm I'm sure I'll screw up and lose code somewhere and have no way of knowing how it happened.
Perhaps putting code in a binary image has also hindered the spread of smalltalk? I see fewer code fragments of smalltalk than I do of say lisp. (I'd love pointers to more smalltalk code reading.)
The image is just bytecode and a bunch of predefined objects. So where does your source code live? Inside of a file called YourImageName.changes, which contains every single line of Smalltalk you execute, including everything from class definitions to method renames to one-offs in workspaces and so on.
If you blow up your image, you simply start with a new one, open a change sorter on your old .changes file, and file in the exact pieces you want, skipping over the part where you, say, accidentally did "Integer become: Boolean" or something equally stupid.
So far, so good: your code is indeed in text, and it's always up-to-date, and it's trivially machine parsable. So what's the issue?
The issue, for me, is that there isn't, by default, a dump of code that represents your program as it exists right now. With that trivial change, using traditional source-control becomes a royal pain the ass, if not outright impossible. That's why you see almost zero Smalltalk code on sites like GitHub, even though the community's active: they end up developing their own systems, such as Monticello, and their own hosting solutions, like SqueakSource and SmalltalkHub, that work with Smalltalk .changes files, rather than Smalltalk code living in text files.
If Smalltalk made one-file-per-class, or something similar, the default, and if it automatically generated "compacted" changes on a regular basis (basically a .changes with all of the stuff you deleted thrown out--in other languages, you'd call these the source files), then I think it'd go a long way to helping adoption. Hell, as a side-benefit, writing Smalltalk code in Emacs would be a lot easier, for those who like that particular path. But in the meantime, that's the way things work.
If everything is in file xyz.changes, and the file is trivially parsable, could you write a program to parse the file, replay the changes up to time T, and dump out a textual representation of the program as it existed at T?
I get that this isn't the Smalltalk way. Typically it's best to approach a system on its own terms. Ideas like this are probably the equivalent of a newcomer to Lisp trying to "improve" things by getting rid of the parens. I'm just curious about what the technical barriers to doing such a thing would be.
But at the same time, this meant that collaboration between users was hard, and that people were locked out of their favorite editors and VCSs.
Use the tools you are used to, use the language that is super productive and run the result on the JVM.