And it is important to consider that once you commit to, say, iterating over an entire file, that the file must be reasonably small anyway to get decent performance. The same issue exists with collections. Who cares if collect: creates an extra collection or if WriteStream wastes space at the end of a long underlying collection; if these concerns are really so important then probably this huge collection should not exist and/or you should not be iterating over the entire thing anyway.

To put it very simply: you just can not expect a program to work on large data structures just because you micro optimized everywhere. If you want to handle large data structures then it takes planning and specialized algorithms and test cases. If you are not going to put in that effort, then don’t sweat the small stuff. It is very liberating to code with an eye towards correctness and towards algorithmic performance, and not to worry about getting down the constant factor. It seems to lead to lower stress, faster code production, and fewer bugs generated.

The last 20 years of the PC have been boring. PC vendors aim at businesses, who aren’t creative in their tool-use. They’re adults: they learn a system and stick to it. We should think about children. The printing revoltuion didn’t happen in Gutenberg’s day, it happened 150 years later, long after Gutenberg was dead, when all the pople alive had grown up with the press.

A small minority of Gutenberg’s contemporaries got the printing press, but it wasn’t until they were dead that the children who grew up with the press were able to put the ideas into practice.

James Licklieder: in a couple of years, human brains and computers will be coupled. It hasn’t happened yet. Except in science, where scientists and computers are indeed thinking as no human brain has ever thought before. .. craphound.com/kayetcon2003

Smalltalk is very well thought out, extremely well engineered, very flexible, and generally gives quite good performance in a multitude of situations. It’s very adaptable to many different situations, and has lots of tricks up it’s sleeve. Driving it is a bit of a paradigm shift from driving your average plane, it has some new fancy controls, but once you get the hang of it, it can be totally amazing and really fun. Even if you don’t totally know what you’re doing you can still get yourself out of a jam. Given that you’ve got a good pilot you can launch off to a quick start and really do some very heavy and impressive damage in a very short time. It also tends to perform quite impressively if you’ve got a few of them around, and easier to coordinate an army of them.

Java is pretty difficult to drive, and once you get it going in a certain direction it’s pretty hard to get it going somewhere else. It has a few turbo buttons on it so that if you really know when and where to use it, it can fly pretty well. You can surely get it going really fast if you fly it high enough and then point it straight into the ground. It’s generally not very flexible and often a real pain to deal with, but overall once you’ve got a flightplan fixed in stone you can fly it reasonably well and run it reasonably efficiently. If you are meticulous in your planning and implementation, it can really deliver the goods. If you make some mistakes, things can go very wrong that may become almost impossible to correct. Don’t count on any big changes, quick maneuvers, or any sort of fancy tricks that just might save the day, and leave yourself a good bit of time for planning and implementation before you expect to be able to deliver the goods. If you come accross any surprise attacks or come up against an Apache hellicopter, you could be doomed.

 > PPS:
 > I remember working for a company, where it took the make utility3/4 of
 > an hour to figure out *what* to compile, and the compilers a day to
 > compile- it was a C++ project b.t.w. which was canceled and replaced by
 > a Smalltalk program after they spent 50man-years on a non-working
 > program - so much for non-toy languages !

Yeah and I just spent 3 days in an inhouse J2EE workshop held by one of our chief architects. We spent most of our time fighting with the tools. Changed setting over and over. The goal of the workshop was to demonstrate how to insert a row into an oracle table. At the end of the 2 days the table was still empty. Another non-toy language.

I have written two small apps (apx 5000 LOC) one in squak and one in stx. It was a dream. Got up in the morning and fixed two or three bugs before breakfast. You can only do this with a real cool environment.

It’s probably because in order to post in the Java ng he has to be 10x as verbose as in the Smalltalk ng.

He probably has to declare himself, cast himself, wrap himself in a try catch block, bubble up any exceptions, use some external iterators, implement some interfaces, and wrap up his primitives in real objects. Maybe after auto-boxing and generics are supported, he’ll only have to post 7 or 8x as often.

Don’t worry James, we appreciate and understand your terseness over here. ;-)

(Source: Avi Bryant) I came across Avi Bryant's blog. Tons of interesting stuff, especially about Seaside. http://www.cincomsmalltalk.com/userblogs/avi/blogView

This situation provides much of the motivation for our architecture, ERP5, which offers several advantages for business. All ERP5 tools are open source, so are free and have openly available source code that a business can change to suit its processes. ERP5 incorporates, from scratch, advanced concepts such as object-oriented databases, a content management system, synchronization, variations, workflows, and a method to model and implement business processes. ERP5 is also a Web site where researchers can share innovation on management techniques and their implementation through software.

In 2001, two companies initiated the ERP5 project: Nexedi, a Zope service provider in France (Zope is a well-known open-source application server), and Coramy, a European apparel manufacturer. They aimed to develop a set of ERP software components for small and medium-sized companies. In addition to source code, the project also produced educational material and a clearly defined theoretical model. To fit the needs of smaller companies, they also designed ERP5 for distribution across distant sites with slow and unreliable Internet connections.

link

So hats off to Nucleus Research for firing a salvo at SAP for causing customers to shell out millions on software with little more than added worker productivity in return. link