31–40 of 52 posts
Smalltalk is incredibly cool, but I think one of the main things stunting it is it doesn't have a great free implementation. The only modern smalltalk environment I've used which felt like a serious environment was VisualWorks, and to download that you have to fill out a form and you can only use it under a "personal use" license. Squeak, despite being impressive, has always felt like a toy. I like Pharo in spirit, b…
You cannot sanely use Pharo or Squeak to write native apps right now; that's totally true. You also couldn't do that for Visual Works, except for a very narrow window when they properly emulated enough Windows XP widgets you could probably fake it. But Pharo and Squeak proper look (to me) neither more nor less native than IntelliJ, which people happily use. Both have professional-looking IDEs that do not look native. That doesn't impact you if you're doing web work, command-line work, etc.
There are lots of other reasons I would finger instead (C interop was historically poor, people were historically reticent to use VMware-image-like language environments, etc.), but Pharo and Squeak have looked fine for most purposes for awhile.
Earlier quoted context omitted.
Correct. Although Smalltalk is generally regarded as the first one because the concept "object orientation" was first used in it. Still, the big thing in Smalltalk are not objects, but messages. That's something many later OO languages missed on completely. From Kay: «OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in S…
I think the reason many later OO languages "missed" messages completely is because the distinction makes little sense in more static languages that lacks a way to dynamically call a method/send a message.
Object-oriented programming is successful in part because its key technical characteristic—dynamic dispatch-is essential to supporting independent, interoperating extensions; and because interoperable extension is in turn essential to the reuse of architectural code (as in frameworks), and more broadly to the design of modern software ecosystems.
Earlier quoted context omitted.
See http://www.stanford.edu/class/cs242/slides/2007/simula-small... . The main omission is encapsulation.
Simula does provide encapsulation - it often considered the first language to do so. It does not provide an easy mechanism for information hiding of the encapsulated instance variables. I think that is an exceedingly weak argument against calling it OO, especially as you AFAIK can do information hiding in Simula by using the simulation support that was it's raison-d'etre, namely by using the object lifecycle and co-r…
Simula is generaly recognized as the first OO language, so it's a second look at the second OO language at best.
Correct. Although Smalltalk is generally regarded as the first one because the concept "object orientation" was first used in it. Still, the big thing in Smalltalk are not objects, but messages. That's something many later OO languages missed on completely. From Kay: «OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in S…
Earlier quoted context omitted.
it's a different user interface paradigm, mainly it's not graphically sophisticated (independent streams of text vs dynamic bitmap overlays)and less time integrated (you have to define how and which script to run when something change). But at the time it was thought so, that's how I felt reading bits of this book http://en.wikipedia.org/wiki/The_Unix_Programming_Environmen... .
My first UNIX experience was in 1993 with Xenix, followed by almost all commercial variants of it. By then I was already spoiled with GUI environments from Atari ST, Amiga 500, Windows 3.x and GEM, as well as the typical MS-DOS IDEs from Borland. So I never saw UNIX that way.
ref: http://shadow.cat/blog/matt-s-trout/but-i-cant-use-cpan/ | https://news.ycombinator.com/item?id=968757
NB. Though I think someone else earlier (Audrey Tang perhaps?) made a similar quote (something like CPAN is my syntax?)
Smalltalk is incredibly cool, but I think one of the main things stunting it is it doesn't have a great free implementation. The only modern smalltalk environment I've used which felt like a serious environment was VisualWorks, and to download that you have to fill out a form and you can only use it under a "personal use" license. Squeak, despite being impressive, has always felt like a toy. I like Pharo in spirit, b…
I get what you're saying, but it's also really weird to me. You cannot sanely use Pharo or Squeak to write native apps right now; that's totally true. You also couldn't do that for Visual Works, except for a very narrow window when they properly emulated enough Windows XP widgets you could probably fake it. But Pharo and Squeak proper look (to me) neither more nor less native than IntelliJ, which people happily use.…
>There are lots of other reasons I would finger instead...Lack of standardization between vendor implementations.
I feel like a lot of the really clever and elegant things about smalltalk as a language and an object model got bogged down in the program image execution model, to the point where it stunted the evolution of those ideas for a long time. We're getting to the point where such a model is more practical now, but it still strikes me as hopelessly impractical even so. It wasn't until OSX made Objective-C take off and Rail…
Back in the early 90's Smalltalk was actually starting to be used in the enterprise, but then came Java. We had access to VisualWorks at the university back then. Many developers aren't aware that Eclipse roots are in Visual Age for Smalltalk. Also that Eclipse's workspace concept was an attempt to create a virtual image out of files. Having said this, Smalltalk's image was a problem in the time when VMs weren't that…
>image based source control systems"Mastering ENVY/Developer"
Earlier quoted context omitted.
And yet people are talking about using VM images and the likes of Docker for deployment nowadays.
There is definitely a level where the concept makes a lot of sense, but even with things like docker or vagrant or ec2 images there is still an expectation that you keep around enough information to replicate the image from scratch, be it a shell script or chef or puppet or a dockerfile. Smalltalk's images didn't really have this feature.
- the original source code provided with the implementation (.sou)
- the replayable log of changes since the sources file was made (.cha)
- the compiled bytecode and objects that make up the current state of the program (.im)
The most basic approach to re-building was to take the vanilla sources file and vanilla image file provided by the vendor, and "fileIn" the changes you'd made from the change log.
And then there were change sets.
And later, a fine-grain method-level VCS database.
iirc JPMorgan had 4 people employed just as code-librarians to work on code-reuse across their Smalltalk projects.