This post originated from an RSS feed registered with Agile Buzz by James Robertson. Original Post: Back to the past Feed Title: Cincom Smalltalk Blog - Smalltalk with Rants Feed URL: http://www.cincomsmalltalk.com/rssBlog/rssBlogView.xml Feed Description: James Robertson comments on Cincom Smalltalk, the Smalltalk development community, and IT trends and issues in general. Latest Agile Buzz Posts Latest Agile Buzz Posts by James Robertson Latest Posts From Cincom Smalltalk Blog - Smalltalk with Rants

Vince Bourgon explains why getting things done in the "modern" languages is so painful - virtually nothing has been learned from the the past - heck, MS has even forgotten what made Basic productive...

No interactive interpreter

I think this was one of the biggest annoyances of all. When I learned languages like Python, like Common Lisp, like Smalltalk, it was always possible to easily and interactively test things. The fact that to test simple things in C# I had to build a whole program, write what I wanted to test, have some output functions to see the results, compile and finally run the program. This took time, and when I had a bug, I had to go back to my editor, find the faulty line, fix it, save and try to compile again. This was much slower than using an interactive interpreter. I had never used sockets in C# and had to make a small program to see how they worked and all. Again, an interpreter would've made things easier and faster. If it wasn't for the very complete MSDN documentation, C# would be a much, much tougher beast.

Gosh knows how far I ever would have gotten with BottomFeeder with the power of Smalltalk. Clearly you can do such projects in C# or Java; there are plenty of such readers out there. But it's harder to get things done. When it's hard to get feedback, it's hard to be productive. And then look at this example:

Simple stuff is made complex

My program contains a Hashtable with the keys being school numbers their name (001 - School Foobar) and values being their IP address. When I ran the program for the first time, I realized something that I hadn't thought of: Hastables are unordered. I wanted the school to go one by one, in alphabetical order. I had this line in the program foreach (string key in ht.Keys)

So I said to myself that the simplest thing would be to change the line to:

  foreach (string key in ht.Keys.Sort())

But this resulted in a compiler error. The hashtable Keys properties returns an ICollecton object which cannot be sorted. So I thought, I just need to take the ICollection object and cast it to an ArrayList:

  ArrayList myKeys = (ArrayList)ht.Keys;
  myKeys = myKeys.Sort();
  foreach (string key in myKeys)

But this raised a runtime exception. After some googling around, I found a solution on this page. Basically, I would need to create my own class called IterSort() to sort the keys. Who else thinks this is way too hard? On the other hand, look how I could've done it in Smalltalk:

  
  d := Dictionary new.
  d add: 'Hello' -> 'World';
    add: 'Bonjour' -> 'Monde'.
  d keys class. "This returns the class of keys, which is a Set"

Now that I know it's a Set, I can just sort it by converting it to a sorted collection:

  d keys asSortedCollection.

The whole thing is just so much easier in Smalltalk than in C#.

He's got other good examples, but the two above illustrate something - yes, there are scads and scads of libraries available in Java and C# - this is something that is continually pointed out to me. On the other hand, if you have to constantly plow through crap like the above, I'm not sure the library size buys you as much as you think - especially when systems like VisualWorks already support a sizable proportion of the extant stuff you need. Take a look at his article, and let me know what you think.