3 ms·
Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control?
by kabdib 10y ago
Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control?
For a long time, Smalltalk and its brethren were terrible at sharing code; you had a bunch of stuff in an environment, and importing and exporting stuff was a nightmare. Has this changed?
Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run".
I'd be happy to be wrong about any of this. Smalltalk is my favorite language (that I'll never ship a product in) . . . but when you look at a couple of my recent projects, which are PHP + JavaScript + WebGL that interpret and let you look at a bunch of back-end statistics, I'd sure like to be using something better.
- vanderZwan 10y agoRegarding your last comment: surely there's a good compiles-to-JS option available these days? There's even a Smalltalk for client-side programming: http://amber-lang.net/index.html http://amber-lang.net/index.html ... not sure how that would work with WebGL though.
- david-given 10y agoAmber's quite heavyweight and requires server-side support to do anything useful. But Smalltalk's so simple that writing your own transpiler isn't that hard --- I have an entirely browser-side prototype in about 2kloc: https://github.com/davidgiven/stellation/tree/stellation5/client https://github.com/davidgiven/stellation/tree/stellation5/cl... Performance is adequate, but not great. Method lookup is the dominating factor, because you need different code paths based on the type of the receiver (number, string, object...) Of course, writing the libraries is the bulk of the work.
- yaowenjiaozi 10y ago> Is that because Java is more a traditional "source code in files, run a compiler" culture, where you can scale teams just by getting better at source control? Possibly. But you may be looking at history through modern lenses. Java was released in mid 90s, and the open source VC tools of the day were RCS and CVS. SVN came in 2000. The explosive growth of DVCS came after that. > Also, it's probably a lot harder to scale a Smalltalk app out to a server farm than it is to just rsync a bunch of java packages and hit "run". A Smalltalk image is similar to a bunch of Java packages bundled into a jar/war/ear/*ar file. You can run any number of OS processes, each a Smalltalk VM running an image, on a single computer. You can scale out by running Smalltalk VMs across multiple computers. Just as with Java and JVMs.