[Pharo-project] Smalltalk for small projects only?

dimitris chloupis thekilon at yahoo.co.uk
Sat Jan 28 17:50:53 CET 2012


I think this is a post that clearly illustrates the big problem with smalltalk. The very fact that is compared with Java and Java survives. 

You know I dont find it mysterious at all that smalltalk is unpopular as it is. If I go to the python website I know in 4 second why I should use python, if I go to a Java site in 10 seconds I know what Java is good for, if I go to a C/c++ again in seconds it becomes clear what is the goal, even Assembly websites explain in a few lines what the language is all about. 

With Squeak and Pharo on the other hand it took me literally hours to figure out what they are good for and by the time I did I was amazed how underhyped smalltalk is. For me at least is the most underhyped piece of software I have ever used. 

The issue with image here its easy to totally miss the whole point. An image is loading lighting fast , a java application is not, its also great way to organise object orientated code because it allows you to quickly navigate through it, loading files , is expensive and frankly quite archaic. The idea behind filesystem was created on the basic that computer could only load just a few kbs or even less because of limited memory. 

In the age we live , filesystems are unnecessary anyway. I am not saying that hardware storage  is , just file systems,  and I think smalltalk moves towards that direction. You dont really need files and extensions to separate data and  code,  OO  can do the job just fine in that area. 

I cant comment on the specifics of the image I am new to smalltalk and still exploring the basics, but let me say that I would love to take the idea of image abit further maybe following the brilliant architecture of our brains which stores information not in packages but via association, I think this kind of workflow is alot closer to what OO tries to be. 

For me the image play a pivot role inside the OO of smalltalk, which unlike Java does not stop at class definition. Besides an oversize clumsy library , smalltalk has very little to be envious of Java.

Regarding huge project I will boldly say that inside a system of gazillion files a single file can easily lost its identity, OO can plays a huge role here, it can create that association I was talking about earlier and it can make sure that the user and coder has immediate access to information that he want to focus on at that particular moment but also has a structure that is obvious and simple to navigate. 

About the limitation of an image , i think that is a matter of implementation , obviously smalltalk has not been used as extensively in large projects as Java. But then what stops us from implementing an image that can brake any barrier, even do direct streaming from disk when the memory is not enough or when we dont want to occupy its entirety ?


________________________________
 From: Janko Mivšek <janko.mivsek at eranova.si>
To: "Pharo-project at lists.gforge.inria.fr" <Pharo-project at lists.gforge.inria.fr>; Squeak <squeak-dev at lists.squeakfoundation.org>; 'VWNC' <vwnc at cs.uiuc.edu> 
Sent: Saturday, 28 January 2012, 17:46
Subject: [Pharo-project] Smalltalk for small projects only?
 
Hi guys,

Ralph Johnson in his InfoQ interview made an interesting observation:

2:55 minute: "Smalltalk made an fundamental error ... image ... you can
build something with 4-5 people what 50 people can build in Java, but if
you take 200 people in Java ... it is really designed for small systems
...  "

Are we because of the image really destined for relatively small
projects and small systems (of Java 50 people project size)?

Are we really not able to scale to bigger projects/systems because of that?

Ok, there are few exceptions of course (JPMorgan, OOCL, ..), but still...

[1] http://www.infoq.com/interviews/johnson-armstrong-oop

Best regards
Janko


-- 
Janko Mivšek
Aida/Web
Smalltalk Web Application Server
http://www.aidaweb.si
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20120128/faa68dd6/attachment.htm>


More information about the Pharo-project mailing list