I really hope this project pans out, because I would love to be able to program in Smalltalk for practical purposes.
(In fact, even the thought of being able to write a single application in both Lisp (Clojure) and Smalltalk (Redline) is making me giddy. We're still a long ways from this dream, but perhaps it'll be possible one day.)
Feels like you didn't read the page I linked. You can do all of this: "navigate object graphs, edit them while the program runs, inspect UI elements and modify their behavior interactively, and so on." It just isn't persisted to an image.
The OP is implying that Redline is just Smalltalk skin on a Java pig. That's not true, but if your goalposts for Smalltalk are "it must be Pharo" then, yeah, it isn't Pharo. This is basically the same unhelpful puritanical attitude that left Lisp basically dead from the end of the Lisp machine until PG started talking it up. It doesn't have to be the same to be good, or better than a lot of alternatives, or to count as a real Smalltalk.
For what it's worth, not having Morphic is a huge win IMO. A UI built on something else that attempted to achieve the original goals of Morphic but with, say, a little actual OO design and architecture, would be way better than that disgusting, unlearnable mess.
This is a seriously weird mixed metaphor. Normally the phrase is "lipstick on the pig," which makes a reasonable amount of sense: ostensibly women wear lipstick to look prettier. Pigs are ugly and won't look prettier even when they're wearing a prettying agent.
Meanwhile, there's the term 'pigskin,' which is a term for an American football.
Finally, pigs already have skins.
This phrase conjures up some sort of horrible notions of the serial killer Buffalo Bill in The Silence of the Lambs for me. Very upsetting.
"[He] sleep[s] with the fishes" is the canonical form of the idiom, whose presence in the common vernacular originates with its use in Puzo's "The Godfather"; in my entire life as a native US English speaker, I have never once heard "swim with the fishes" used with anything remotely resembling the same meaning. (It doesn't even make sense! Dead things don't swim; they can't, because they're dead.)
I've got a bit of the blub paradox going on here so this story is lost on me. Can anyone give me a concrete example of what he's talking about instead of an abstract analogy?
In Smalltalk, you can manipulate objects directly rather than just indirectly via code that operates on them. The state of your manipulation is made persistent in smalltalk's image facility. Also, the whole object graph is supposedly better exposed accordingly then what you could get sigh just a plain old debugger.
At least I think that is what the author is trying to convey.
It's pretty rare that you'd actually make ad-hoc changes and then rely solely upon persistence to preserve those changes. Ultimately, you'd want to write code to produce the outcome programatically. It's more the case that you play around and do little "what ifs", which helps you crystalize your ideas about what you're trying to implement.
The trouble is that just explaining the mechanics of it doesn't really capture the experience, and if you talk about the experience on its own, you end up talking about, er, fishes. Which is to say that it's an almost useless analogy, but one that I don't know how to better.
Still, using Python to pay the bills isn't so bad...
It exists. That's better than the alternative, and if this seems like damning with faint praise, it's because there really isn't anything else good to say on the subject -- the debugging facilities available in any Lisp environment, even Emacs, make those offered by Python (or Perl, or Ruby, or Javascript) look pitiful, and from all I've seen of Smalltalk, it is to Lisp as Lisp is to your interpreted language of choice.
There's barely any such thing as a debugger, and no such thing as an object graph, and even modifying a function in place is far more complicated than real tools would make it -- but nonetheless, in the sort of browser-based Javascript development I do on an almost daily basis, I sense a faint echo of the je ne sais quoi to which you refer; specifically, iteratively fiddling with a live system until it behaves more like how you want, then baking those changes into the serialized form of it (also called "source code") so that they're incorporated next time the system is instantiated.
Granted, I have only the most trivial experience with Smalltalk; I'm pretty sure at least some of the concepts I have in mind here are entirely meaningless in that context, but I wonder if it would be fair nonetheless to consider the modern browser Javascript environment, for example Firefox with Firebug and a proper REPL instead of the single-line console, as potentially possessing at least some of the flexibility a Smalltalker considers de rigeur.
On the other hand, if you wanted to build, for example, an object-graph generator in pure Javascript, I don't think you could do so, at least not one worth having; unless I'm very much mistaken, Javascript's reflection facilities don't suffice to allow one thing to notice when another thing changes, unless the latter thing explicitly notifies the former of the change. So you'd have what would be essentially static analysis on running code; you could recursively walk properties from the global object on down, following references where necessary, but it'd be dog-slow in modern JS implementations; worse, there'd be no way to keep it synchronized with the actual state of the objects to which it refers, short of rewalking everything to spot the changes, which would be ugly in theory and unusable in practice. So it's probably also accurate to say that the modern browser Javascript environment offers no immediate prospect of attaining anything remotely resembling the facilities a Smalltalker considers de rigeur.
Which is a shame, because what I've seen of Smalltalk has been impressive in the extreme, especially by contrast to the tools whose use I can actually justify in my professional life.
This is where my Blub programmer life bites me. I don't understand what you mean by "manipulate objects directly". I can't figure out the right abstraction level to put it at.
For instance, let's say I have an Employee object that throws an exception. Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. So I'm not acting directly on the object, but a representation of the object.
However, then it just sounds like Smalltalk lets me play with a set of bits in memory that represent the Bob object. Most debuggers I've worked with already allow me to do that in some fashion. Yet, this is always touted as one of the great, unique features of Smalltalk. There must be something that I'm missing, but I can't see what.
Basically it already knows the system/ide classes and pulls them out, and does some code analysis to remove unused bits of code and so on. It's an interactive process, but it's generally pretty smart.
Image pruning is really not a good way to do it, it's much better to take a clean base image and load your code into it as part of the deploy process. Pruning a development image is a very old fashioned way to create a production image.
> Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.
Yes it does.
> So I'm not acting directly on the object, but a representation of the object.
No, that is the object. Now, if it's backed by a relational database what you're saying might be true, but then you just change the name and then tell the object to save.
You're thinking too data centric as if only persistent objects exist, so let me explain. Smalltalk is image based, you're working in the live runtime, not on files that later become the live runtime.
Forget the debugger, it has nothing to do with the debugger. I can open up a workspace and say "SomeClass allInstances", highlight the statement, press a key to inspect it and up pops a list of all instances of that class in a window. I can then click any instance in that list and inspect it and get a window for that object where I can see and modify the state of that object. That object could be a session object for a user on the website at that moment, or it could be the application itself, or any other object in the system.
In most languages using the debugger is the only time you get to play with the running program, in Smalltalk there is only the running program and you're in it all the time. I can highlight a method name, hit one key, and be taken to the source for any method in the system including those that give me that ability; I could change code that breaks the IDE that I'm working in if I wanted. I could inspect the running IDE and change the color of the window tile while I'm using it. I can do all of this from the IDE or workspace without ever invoking a debugger.
Here's a very simple way to grok it, it's just like SQL in the sense that a database is a running image and you can query user table or even system tables that control how the server itself functions. If you change a view, clients of that view see the change instantly; you don't have to restart the database to see your code changes because you are working on the running server, not a text file that when ran becomes the server.
Smalltalk is the same, you write code in the running image and changes are seen immediately by clients using that server. This is the same as a Lisp hacker connecting Emacs to a running Lisp instance, say the one that hosts this site, and making changes while people are using the site.
Smalltalk is optimized for code navigation like no other environment I've ever seen. When I work in Ruby or frankly any other language, I have to pull up the documentation for the String class to see what methods it supports; I've never had to do that in Smalltalk, I just go to the String class and look at what methods it supports directly assuming I don't see what I'm looking for in the intellisense. If I want to extend it, I add a method to it right there, but categorize it with my package so it's part of my project and not part of String for the purposes of source control.
If I want to see how a string works, I can simply highlight a string in a workspace and inspect that instance of it in a window, and then play with it, sending messages to it to see how it reacts, or if it errors, or whatever. Pretty much anywhere in the system you can simply highlight some code and press a key to evaluate it allowing you to hack things together by trial and error much much faster than if all you have is a REPL or worse only the debugger.
A Smalltalk workspace is pretty much exactly like working in a SQL workspace; write some code, highlight it, run it, see what happens. But in Smalltalk, you're not limited to a result window, you might have a transcript up, but you also might have 10 inspectors open on all the objects you're playing with in a workspace so you can see them and watch their state change while you're playing with the code.
A Smalltalk image is a running object database, not a transactional one, you don'...
> > Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.
> Yes it does.
Okay. either I wasn't clear in my analogy or I'm actually further away from understanding Smalltalk than I thought. Let me put it a different way: If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
A lot of my confusion about whether it's the object or the representation of the object comes from this level. I tried to learn Smalltalk a few years ago. We started off with some GUI work and the teacher was quite adamant that we understand that the button on the screen was the object and not just a visual representation of the object.
If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment. For a comparison point, during my day job, I write a large amount of Python in Emacs. This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it. I can call the "help" function on an object to see its documentation or the "dir" function to view all its members and methods. I can load code at run time and patch new members onto classes or objects.
Of course, that's the classic Blub programmer paragraph. At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors. I'm also sure that the Smalltalk documentation is better written than what I usually get from "help". Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
You are thinking about the separation between source files and the running system, but there is no such thing as a separate source file in Smalltalk. You can generate them if you wish, but it is not necessary. The code, in fact, is just a representation of the real system, which is contained in an image file.
For example, when you want to modify an object in Smalltalk, the system generates a representation of it - with methods and instance variables - and you modify the representation with the system text editor. Then you ask to system to apply the changes to the object. When the changes are applied, that is it, no source files are needed anymore. The system continues to live like this. When your "programming session" is over, you save the whole image, and starts it again on the next day. No compilation of whole system is ever performed. It is said that some objects in a standard Smalltalk image have been alive for several years... they are only saved and used, never recompiled or modified.
> If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
Oh, I see what you meant, no of course not as the Bob object itself is a representation of the real world Bob, however if you did that your system and all of its clients would immediately think Bob was deceased.
> A lot of my confusion about whether it's the object or the representation of the object comes from this level.
I think you might be confusing classes with objects; objects are instances of a class and thus only exist at runtime, which is all the time in Smalltalk (and Lisp) and at debug time for other languages.
The representation you work on is the class, in most languages the class is a source file you edit that at runtime can have instances of itself created. In Smalltalk, the class itself is just another object in the system, you create subclasses and instances by sending messages to it; there are no source files. You don't work on source files, you work on live objects, the IDE doesn't edit files, it edits method objects from the classes in the running system. You can reflect, inspect, and browse the live running class system just like the IDE does.
> If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment.
Correct, but don't let that make you think the language isn't important as well. Smalltalk the language is amazing in a similar fashion to how Lisp is amazing; the syntax is incredibly flexible and simple.
The proof of this is that Smalltalk control structures, your if/then/else/switch/while/for/etc are not part of the language itself (discounting VM optimizations), they are simply implemented in the standard library using objects, polymorphism, and lots of higher order functions.
Just as Lisp macro's enable Lispers to add native control structures because Lisp itself uses the same mechanism, Smalltalk's simple lambda syntax [ code ] or [:arg | arg isX ] and special method naming syntax enable Smalltalk'ers to add native control structures because Smalltalk the language uses the same mechanism.
For example, you can't add your own "if" to Ruby that looks and works just like the built in "if", but you could in Smalltalk because that's how it was done in the first place. It's all library, classes and objects (functions in Lisp) and everything is built on top of that. Very few languages work this way, most have special keywords for control structures and you can't add to them.
> For a comparison point, during my day job, I write a large amount of Python in Emacs.
Great, also a great little language. Ah... but you're using Emacs, if you aren't aware that's just a Lisp image exactly the same thing as a Smalltalk image. You know exactly what working in an image is like, you do it daily.
> This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it.
Yup, Emacs is an image.
> I can call the "help" function on an object
On an object, or do you mean on a class in a file. Vastly different things. Object and class are not interchangeable words to use in this context.
> to see its documentation or the "dir" function to view all its members and methods.
I think you're talking about classes, not objects. And does this also include all source for the standard library as well, not just your application?
> I can load code at run time and patch new members onto classes or objects.
Yup, Python like Smalltalk is a very flexible dynamic language, but it didn't come out till a decade later and still isn't as flexible.
> Of course, that's the classic Blub programmer paragraph.
Yup, but at least you're aware of that, so you've ...
What you're missing is that, in Smalltalk, the representation on which you're acting is indistinguishable from the object; in your example, when you change the name member, Bob from Accounting's name does suddenly change to Gary; not only do future accesses of the name member on that object return "Gary", but, for example, if you have an HR management frontend open on Bob when you make the change in the inspector, you'll instantly see the effect there as well.
If all your experience and knowledge is born of Unix and the web, you don't really have available the necessary concepts to think about how a Smalltalk, or even a Lisp, actually works -- I know this because all of my experience and knowledge were born of Unix and the web, until recently, when I took it into my head to learn Lisp and also to gain at least a passing familiarity with Smalltalk. The difference is amazing -- in the preface of the UNIX-HATERS Handbook, written mostly by veterans of the Lisp years at SAIL, our modern computing environment is described thusly, by Ken Pier of Xerox PARC:
"I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."
Which I thought was hyperbole, too, until I spent some time discovering what sort of environment Pier and the SAIL folk took for granted. I don't unreservedly recommend the experiment; I earn my living in Pier's "East Africa", and sometimes I think I'd be better off if I didn't know how bad I have it. But I can certainly say that if you haven't tried it for yourself, you don't begin to know what you're missing.
I understand that changing the name member of the Bob object to Gary will cause it to be Gary in every subsequent member access. Perhaps I've grown spoiled in my old age, but I'd be shocked at any system which didn't have this property. However, if I called out "Hey Gary!" down the hall, would he respond? Would his driver's license still read Bob?
The last time that I tried to learn Smalltalk, it was drilled into me that Smalltalk works directly with objects and not just their representations. For instance, the collection of black pixels on the screen was the Mouse object itself and not just a manifestation of a Mouse object somewhere in memory. A large amount of my confusion has possibly come from those lessons.
I agree that Lisp is an enlightening experience. I spent two years using Scheme as my primary programming language at work. Then again, I may just be stuck as a Blub programmer. I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
> However, if I called out "Hey Gary!" down the hall, would he respond? Would his driver's license still read Bob?
Yes and no, respectively.
Perhaps a heavily contrived example might help: Consider a system in which there is exactly one representation of an object member's value, which is stored in that object; when you call an accessor method, what you actually get is a reference, which is instantiated with an observer attached that listens for a notional "change" event, fired whenever the referred value is modified, and whose event handler updates whatever context exists around the reference, regardless of its nature, so that the displayed value matches that newly assigned to the object member.
...and now perhaps you can see why people familiar with Smalltalk think so highly of it; what in, for example, Javascript, would require an enormous amount of manual infrastructure and completely fail to generalize, in Smalltalk happens entirely transparently. It's not so much that you don't have to think about it; it's that there's nothing there to think about.
> I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
And now you've lost me. How can this possibly be the case? What was your Lisp workflow like? I mean, I can understand not getting the appeal of Lisp if you're just talking to the REPL and not working in an actual Lisp environment of the sort you get with Emacs Lisp or SLIME, but I have trouble understanding how anyone could work with those tools for a year without recognizing their potential.
The debugger situation with Smalltalk is part of what he's talking about. You're running your application, and some part of your code throws an exception. A window pops up with the stack trace in it. You can inspect all the objects in each frame. "Inspect" in Smalltalk means, see and change the properties, call methods, change the code, clone, see the class hierarchy, etc. You can modify the method that threw the exception right there from the debug window, save it, and resume the method from where it broke. Application proceeds with new code in place and problem solved.
Look, a cosmetic bug in this window. Right click on it, click Inspect. Looks like one of the properties has the wrong value. Edit the property from the inspector, fix the problem. The application was running the whole time and now is fixed.
An impressive thing you can do with Fuel is serialize and deserialize the exception with all state. Somebody blows up your web application. You wrote a bit of code to catch unhandled exceptions and export them with Fuel. You download the binary to your local computer and deserialize it in your live Smalltalk image. You see the debugger window pop up and can examine all the state when the error happened as if it popped up locally. See, examine, change the code, all of it live the whole time. (I don't know if this is done in practice much, but it's pretty normal to run a headless Smalltalk image and connect to it over VNC when you need to debug something).
To sum up, everything is live all the time in Smalltalk, and you can interactively change all the actual running instances, both code and data, at any time without interrupting anything.
That's roughly how one works in Common Lisp as well (though most implementations don't ship with a graphical environment, so ssh is typical instead of VNC).
It's really much more pleasant than shipping text files and interpreters all over the place and sorting through logfiles and tracebacks when things go south.
Absolutely. There's a deep kinship between them. Prolog can also be used this way, though it doesn't support images, it's a homoiconic language and it's very easy to read and write terms from files.
The analogy given in the article is pretty accurate. The Smalltalk environment is unique in that it allows very easy access to the libraries, the IDE and the language’s internals (including the compiler!). The Smalltalk debuggers are among the best ones I have ever used.
(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)
I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.
Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.
Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.
I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).
These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.
Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.
Source: I used to be a professional Smalltalker for almost three years.
With respect to version control systems, I notice you didn't mention ENVY. I can't comment on Monticello nor Store, never having used them, but I still miss ENVY. Best version control system I ever used.
Source: professional Smalltalker for about four years (fifteen years ago)
> many parts of the Smalltalk IDEs are horribly outdated
My opinion is the opposite: I find the IDE in Pharo to be simple and very elegant, far more human-friendly than any I've seen in 'mainstream' languages. And this version of Smalltalk is under heavy development, with a push towards even greater cohesion. This small corner of computing is seething with hot, cutting-edge activity.
> The text editors are pretty bad
Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
> Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
This! And also, in Pharo 3.0 there's being a huge push towards better text editing, although I've never ever needed more than what Pharo 1.0 did already provide...
Just because you have shorter methods does not mean you would not benefit from Emacs-like power. I use Haskell--which has even shorter functions, often half that length--and yet I still find Emacs exceptionally useful.
Any amount of text is still text, and Emacs excels at text editing.
I problem I ran into when giving it a try. I couldn't easily find a way to print to standard output. All I wanted was to print some strings, numbers and manipulate them. Instead, it was easier to have a red ball on the screen.
While I really like Smalltalk, for some reason it does not work for me as a web development platform (and the web is my platform), or maybe I just don't grasp it.
I tried Seaside (http://www.seaside.st/) but the URLs it generates are not acceptable (unfortunately) and I find their component system quite complex. I hope someday I will find way to use the techniques behind Smalltalk (live environment, object model) in a browser or web environment. Maybe Amber will develop into something I can work with. I really hope so. Any suggestions anyone?
There are two other web frameworks in use, and I think one of them is more about generating clean URLs. Illiad?
I love the idea of Smalltalk, but it also never stuck for me. I think I just prefer to learn from books than through milling around in the image. All the great minds in Smalltalk seem to be self-driven autodidacts. I'm not.
I'm pretty good at Haskell and Prolog though, so I think it works out in the end. I'm also not good at Lisp or Forth. :)
Yep. AidaWeb and Iliad (plus many other smaller ones).
Although Iliad is not about generating clean URLs (it can, though), but more about being small and understandable, plus having Ajax for free and being pragmatic.
Articles about how great Smalltalk is usually remind me of articles about how great the Lisp Machine was. And there is a lot of merit to an entire system, hardware and software, designed to operate in a high-level language.
My complaint is that neither of these things is coming back in a relevant way.
Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore. We've moved to a system of (somewhat!) interchangeable parts. If your thoughtfully constructed, delicately handcrafted utopia doesn't play well with tools the user is used to and libraries the user needs, no one will use it in the real world.
Smalltalk, though a wonderful entire system in the 80's, hasn't kept up with computing progress. Most of its best features made it into other languages (Ruby and Obj-C are the premier examples), languages which aren't so opinionated about what OS you run, what IDE you're using, what language adjacent programs are written in, etc.
Much like Lisp Machines, the rest is left to rot, and incite wistful blog posts by old hands. And pretty much everyone else ships code in other languages.
However, the main point is that back then you haven't got HN, Reddit and the blogs of today.
As such not many geeks were fortunate enough to know and understand those systems, as consequence you have a legion of developers that cannot understand the beauty of those systems.
> Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore.
That's unfortunate. If we kept at it, we could have discovered much simpler ways of doing things than the current accumulation of leaky abstractions over leaky abstractions in a rather disintegrated environment. We can do better: http://www.vpri.org/pdf/tr2011004_steps11.pdf
>My complaint is that neither of these things is coming back in a relevant way.
Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.
This is true of any new system. There is a huge complexity in supporting even the standards that most people would consider basic. Just to surf the web you need TCP/IP, HTTP(S), HTML, JavaScript, JPEG, etc. Implementing all of these from scratch is a huge pain.
There is great danger in learning OOP with Smalltalk. Everything fits together so elegantly, the first time I opened a book about C++, I closed it in disgust (after seeing the bit-shift operator being used for console output, wtf?!), only to give the language a second chance 8 years later. I even learned Java before giving C++ a try.
When a young programmer asks me for advice about the next language to learn is, my advice is to go for the language that feels most alien. C++ won't enlighten a Java programmer significantly. Forth will.
I must admin from all the stuff I saw on the internet I am now scared even try to learn C++. I think it is the looks as a least desireable language to learn for me. Which sucks a bit because there is position at a company I wouldn't mind work for.
There are lots of C constructs that are considered bad practice in C++
- null terminated strings
- plain vectors
- manual management of resources (memory, files, db connections, locks...)
- C style casts
- pre-processor instead of using inline/const/templates
- the C subset of C++ it is also not 100% compatible with C, there are a few cases with different semantics
- since C99, new language constructs are added via macros, instead of keywords
- no use of namespaces
- lack of safety of parameters that can be changed (pointer vs reference parameters)
The best way to learn C++ is to read books like "Modern C++ Design", "Programming -- Principles and Practice Using C++" and the recently published "Tour of C++".
I have to take issue with your inclusion of "Modern C++ Design" in a reading list about learning C++. If you're new to C++, that is exactly the sort of thing you _shouldn't_ be reading.
"Modern C++ Design" is really intended for advanced C++ programmers only. I don't feel it gives a very good impression of the language to new developers - there are so many awful hacks in that book.
It's the sort of thing that you should hold off on until you have the experience with the language necessary to be wise about when such techniques are appropriate.
It's not a bad language and learning it will teach you a lot of very important concepts. My advice is to master C first, then to wrap your brain around C++.
But, again, there may be other languages more worthy of your effort.
I only leaned Java before touching C++ again because of my peculiar introduction to OOP and because I discarded the language after considering it an inelegant kludge, but, compared to Smalltalk, what language isn't?
And, finally, I decided to swallow my pride and learn C++ because I wanted to be part of the Brazilian electronic voting system projecy. Now, every ballot runs some C++ code I wrote.
Have you ever tried Eiffel? I've always found the approach taken by Eiffel as OOP done right (compared to C++). I wonder how Eiffel and Smalltalk compare together.
At the same time, so much recent tool development has focused on virtualization. Vagrant, chef, puppet, packer, ... and yet, Smalltalk has decades of experience with whole virtualized machines to we can study.
Perhaps systems like Smalltalk still have something to teach us?
From its documentation, it looks more like an attempt to expose the kind of REPL/runtime integration Emacs offers, through an interface which won't scare people off the way Emacs tends to do.
Yes. And seriously, when I saw the first Light Table demo and everyone was so amazed with it I thought "man, that's how we code every day in Smalltalk... what's so new about it?"
> My complaint is that neither of these things is coming back in a relevant way.
I think one could make the case that Android shares many design decisions with a "Smalltalk machine". And the same actually goes for iOS, as objective-c is basically Smalltalk bolted on to c.
And then there is javascript that's modelled after Self -- so by extention chrome OS is also similar to a "Smalltalk machine".
Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.
The exception might be the one-laptop-per-child project.
So, I think it's wrong to say "it's not coming back" -- even java (for set-top boxes and smart devices) was an attempt at "bringing it back".
If anything, it seems these systems keep being reinvented.
> Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.
Because Worse is Better[1]. For example Internet and the Web is a bastardized version of Xanadu Project[2]. HTML is a bastardized version of XML or XHTML. Worse is here now, when Better gets here, it's not Better anymore, only marginally more useful. That or it turns out the benefits Better has aren't that important or are highly impractical.
No. Worse is Better would explain why browsers would use Smaltalk (or Self) directly, instead of inventing a new programming language.
Javascript was probably born out of Not Invented Here. Worse Is Better only contributed the curly braces from C, and the continued use of the first widely known scripting engine.
If The Right Thing is already there, Worse Is Better simply doesn't win without exterior help. Worse is better only because it's first. And even so…
> when Better gets here, it's not Better anymore, only marginally more useful.
I would say perceived as marginally more useful in the short term. This is a point where Worse easily looks Better, but whether it is is more debatable.
I'm gonna disagree. Could you implement Smalltalk environment in browser in two weeks? I'd doubt you could (assuming you are Brendan Eich, circa 1995), realistically. It is a sloppily written language that was perfected later over course of decades.
Worse is Better is omnipresent. Linux vs Minix vs BeOS vs Windows is example of Linux despite being bad relatively, simply winning out (on servers) due to its developer base and losing to Windows that despite numerous faults/warts won the desktop market by a large margin.
When I said Right Thing being here, I didn't mean existence, but presence. Right thing may exist in heads of few masters that know it super well, but them being unable or unwilling to spread it dooms the Right Thing. A Worse Thing that spreads far and wide will win and has always won.
> Could you implement Smalltalk environment in browser in two weeks?
You're being unfair: you compare a Javascript interpreter against a Smalltalk environment. Obviously, If I were in a rush, I would start with a simple interpreter first.
Realistically, if you don't really care about performance (I doubt Brendan Eich did at the time), implementing a JavaScript interpreter is neither easier nor harder than implementing a Lisp or Smalltalk or Self interpreter. I maintain that ease of implementation simply was not an influential factor either way.
Therefore, Javascript was invented for other reasons. My best guess is, Brendan Eich wanted his language to be non-intimidating to C, C++, and Java users. Apparently, it worked.
Oh. That is a typical "Worse is Better".
Okay, I retract. "Worse is Better" is an excellent explanation for Javascript. There are just other kinds of short term benefits persisting through time than the mere ease of implementation.
Hmm… I think that's pretty much what Brendan did, although he likely started with Self instead of Smalltalk. JavaScript makes a strong emphasis on objects, and had closures from the beginning. Then it has a Java-ish syntax.
I'm not that strong, though. It could take me from a week to a month, depending on how much I need to learn. (Parsing the syntax is easy, but I'm less sure about the semantics.)
> Most of its best features made it into other languages
No. A few of them have, usually in needlessly restricted and nigh-broken forms (Ruby's blocks are a pale and pitiful shadow of Smalltalk's). I've yet to see message cascading or conditions outside of lisps and smalltalk.
So, it's a language for doped up hippies. That's what I got out of that. I recalled Jerry Garcia's stories about scuba diving and how it was better than LSD.
I have no clue what it means to live amongst your objects and touch and feel and turn and taste them. That article didn't really explain what that means, but I'll take him at his word.
Sure, downvote me. This article says nothing. You have to be a Smalltalk lifer to get it. It's all metaphors that have no meaning to anyone outside the author's bubble.
Apologies for throwing these quotes in, but they just seem so appropriate in this context:
"Unfortunately, no one can be told what the Matrix is. You have to see it for yourself."
"After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."
Try the red pill... (And think of turtles rather than rabbits!)
Here is a concrete story what happened me few weeks before, while I was working on a Nintendo emulator in Pharo. I was playing with Super Mario, and at the end of the 3rd or 4th level my emulator crashed because of some index miscalculation in a sprite drawing method. When this happens in smalltalk, a debugger window pops up, and the cursor is on the problematic line. I fixed the bug in the debugger and pressed proceed then continued my journey to save Princess Peach :).
In a live environment it is easy to make experimentations because you can get very quick feedbacks, and there is no need to switch between modes like development to execution or execution to development. Catching and fixing certain bugs is also easier as I showed before.
I think there is a need for this kind of development, that's why people try implementing code hotswapping and class reloading capabilities in various programming environemnts. But still most of them are just limited workarounds compared to smalltalk where live coding works fine for decades.
One benefit that a lot of commenters here have pointed out is very user-friendly inspection of running code. Kind of a super-REPL. I find that in Python I'm most productive in iPython's browser-based notebook interface (or Mathematica, but I find Mathematica difficult for writing things that go into web-facing applications), which offers similar features.
These notebook interfaces are REPLs, but they're a little more user friendly in the sense that you can edit history in place instead of doing a history completion and then evaluating an additional line.
Has anybody had any experience with these notebook interfaces as well as the smalltalk environment and can give a rundown of the differences?
86 comments
[ 3.0 ms ] story [ 102 ms ] threadI really hope this project pans out, because I would love to be able to program in Smalltalk for practical purposes.
(In fact, even the thought of being able to write a single application in both Lisp (Clojure) and Smalltalk (Redline) is making me giddy. We're still a long ways from this dream, but perhaps it'll be possible one day.)
http://www.redline.st/discover/is-it-smalltalk.html
The OP is implying that Redline is just Smalltalk skin on a Java pig. That's not true, but if your goalposts for Smalltalk are "it must be Pharo" then, yeah, it isn't Pharo. This is basically the same unhelpful puritanical attitude that left Lisp basically dead from the end of the Lisp machine until PG started talking it up. It doesn't have to be the same to be good, or better than a lot of alternatives, or to count as a real Smalltalk.
For what it's worth, not having Morphic is a huge win IMO. A UI built on something else that attempted to achieve the original goals of Morphic but with, say, a little actual OO design and architecture, would be way better than that disgusting, unlearnable mess.
This is a seriously weird mixed metaphor. Normally the phrase is "lipstick on the pig," which makes a reasonable amount of sense: ostensibly women wear lipstick to look prettier. Pigs are ugly and won't look prettier even when they're wearing a prettying agent.
Meanwhile, there's the term 'pigskin,' which is a term for an American football.
Finally, pigs already have skins.
This phrase conjures up some sort of horrible notions of the serial killer Buffalo Bill in The Silence of the Lambs for me. Very upsetting.
http://www.usingenglish.com/reference/idioms/swim+with+the+f...
"[He] sleep[s] with the fishes" is the canonical form of the idiom, whose presence in the common vernacular originates with its use in Puzo's "The Godfather"; in my entire life as a native US English speaker, I have never once heard "swim with the fishes" used with anything remotely resembling the same meaning. (It doesn't even make sense! Dead things don't swim; they can't, because they're dead.)
At least I think that is what the author is trying to convey.
The trouble is that just explaining the mechanics of it doesn't really capture the experience, and if you talk about the experience on its own, you end up talking about, er, fishes. Which is to say that it's an almost useless analogy, but one that I don't know how to better.
Still, using Python to pay the bills isn't so bad...
Well, and pdb isn't bad.
Granted, I have only the most trivial experience with Smalltalk; I'm pretty sure at least some of the concepts I have in mind here are entirely meaningless in that context, but I wonder if it would be fair nonetheless to consider the modern browser Javascript environment, for example Firefox with Firebug and a proper REPL instead of the single-line console, as potentially possessing at least some of the flexibility a Smalltalker considers de rigeur.
On the other hand, if you wanted to build, for example, an object-graph generator in pure Javascript, I don't think you could do so, at least not one worth having; unless I'm very much mistaken, Javascript's reflection facilities don't suffice to allow one thing to notice when another thing changes, unless the latter thing explicitly notifies the former of the change. So you'd have what would be essentially static analysis on running code; you could recursively walk properties from the global object on down, following references where necessary, but it'd be dog-slow in modern JS implementations; worse, there'd be no way to keep it synchronized with the actual state of the objects to which it refers, short of rewalking everything to spot the changes, which would be ugly in theory and unusable in practice. So it's probably also accurate to say that the modern browser Javascript environment offers no immediate prospect of attaining anything remotely resembling the facilities a Smalltalker considers de rigeur.
Which is a shame, because what I've seen of Smalltalk has been impressive in the extreme, especially by contrast to the tools whose use I can actually justify in my professional life.
For instance, let's say I have an Employee object that throws an exception. Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary. So I'm not acting directly on the object, but a representation of the object.
However, then it just sounds like Smalltalk lets me play with a set of bits in memory that represent the Bob object. Most debuggers I've worked with already allow me to do that in some fashion. Yet, this is always touted as one of the great, unique features of Smalltalk. There must be something that I'm missing, but I can't see what.
You can change anything at any time and those changes are made persistent.
This is one reason why images are prunned for deployment.
You can only avoid pruning for server side applications.
Yes it does.
> So I'm not acting directly on the object, but a representation of the object.
No, that is the object. Now, if it's backed by a relational database what you're saying might be true, but then you just change the name and then tell the object to save.
You're thinking too data centric as if only persistent objects exist, so let me explain. Smalltalk is image based, you're working in the live runtime, not on files that later become the live runtime.
Forget the debugger, it has nothing to do with the debugger. I can open up a workspace and say "SomeClass allInstances", highlight the statement, press a key to inspect it and up pops a list of all instances of that class in a window. I can then click any instance in that list and inspect it and get a window for that object where I can see and modify the state of that object. That object could be a session object for a user on the website at that moment, or it could be the application itself, or any other object in the system.
In most languages using the debugger is the only time you get to play with the running program, in Smalltalk there is only the running program and you're in it all the time. I can highlight a method name, hit one key, and be taken to the source for any method in the system including those that give me that ability; I could change code that breaks the IDE that I'm working in if I wanted. I could inspect the running IDE and change the color of the window tile while I'm using it. I can do all of this from the IDE or workspace without ever invoking a debugger.
Here's a very simple way to grok it, it's just like SQL in the sense that a database is a running image and you can query user table or even system tables that control how the server itself functions. If you change a view, clients of that view see the change instantly; you don't have to restart the database to see your code changes because you are working on the running server, not a text file that when ran becomes the server.
Smalltalk is the same, you write code in the running image and changes are seen immediately by clients using that server. This is the same as a Lisp hacker connecting Emacs to a running Lisp instance, say the one that hosts this site, and making changes while people are using the site.
Smalltalk is optimized for code navigation like no other environment I've ever seen. When I work in Ruby or frankly any other language, I have to pull up the documentation for the String class to see what methods it supports; I've never had to do that in Smalltalk, I just go to the String class and look at what methods it supports directly assuming I don't see what I'm looking for in the intellisense. If I want to extend it, I add a method to it right there, but categorize it with my package so it's part of my project and not part of String for the purposes of source control.
If I want to see how a string works, I can simply highlight a string in a workspace and inspect that instance of it in a window, and then play with it, sending messages to it to see how it reacts, or if it errors, or whatever. Pretty much anywhere in the system you can simply highlight some code and press a key to evaluate it allowing you to hack things together by trial and error much much faster than if all you have is a REPL or worse only the debugger.
A Smalltalk workspace is pretty much exactly like working in a SQL workspace; write some code, highlight it, run it, see what happens. But in Smalltalk, you're not limited to a result window, you might have a transcript up, but you also might have 10 inspectors open on all the objects you're playing with in a workspace so you can see them and watch their state change while you're playing with the code.
A Smalltalk image is a running object database, not a transactional one, you don'...
> > Clearly, if inspect that object and change the name member, Bob from accounting's name doesn't suddenly change to Gary.
> Yes it does.
Okay. either I wasn't clear in my analogy or I'm actually further away from understanding Smalltalk than I thought. Let me put it a different way: If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
A lot of my confusion about whether it's the object or the representation of the object comes from this level. I tried to learn Smalltalk a few years ago. We started off with some GUI work and the teacher was quite adamant that we understand that the button on the screen was the object and not just a visual representation of the object.
If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment. For a comparison point, during my day job, I write a large amount of Python in Emacs. This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it. I can call the "help" function on an object to see its documentation or the "dir" function to view all its members and methods. I can load code at run time and patch new members onto classes or objects.
Of course, that's the classic Blub programmer paragraph. At the very least, Smalltalk sounds like a nice environment and I'm jealous of having multiple, independent object inspectors. I'm also sure that the Smalltalk documentation is better written than what I usually get from "help". Still, I suspect that I'm missing something. Especially if I'm still wrong about what it means to work directly on an object.
For example, when you want to modify an object in Smalltalk, the system generates a representation of it - with methods and instance variables - and you modify the representation with the system text editor. Then you ask to system to apply the changes to the object. When the changes are applied, that is it, no source files are needed anymore. The system continues to live like this. When your "programming session" is over, you save the whole image, and starts it again on the next day. No compilation of whole system is ever performed. It is said that some objects in a standard Smalltalk image have been alive for several years... they are only saved and used, never recompiled or modified.
No prob.
> If I open the Bob object in the inspector and set the "deceased" member to "true", will Bob claw his way out of his casket?
Oh, I see what you meant, no of course not as the Bob object itself is a representation of the real world Bob, however if you did that your system and all of its clients would immediately think Bob was deceased.
> A lot of my confusion about whether it's the object or the representation of the object comes from this level.
I think you might be confusing classes with objects; objects are instances of a class and thus only exist at runtime, which is all the time in Smalltalk (and Lisp) and at debug time for other languages.
The representation you work on is the class, in most languages the class is a source file you edit that at runtime can have instances of itself created. In Smalltalk, the class itself is just another object in the system, you create subclasses and instances by sending messages to it; there are no source files. You don't work on source files, you work on live objects, the IDE doesn't edit files, it edits method objects from the classes in the running system. You can reflect, inspect, and browse the live running class system just like the IDE does.
> If I'm understand what you've written properly, then the Smalltalk language isn't nearly as important as the Smalltalk environment.
Correct, but don't let that make you think the language isn't important as well. Smalltalk the language is amazing in a similar fashion to how Lisp is amazing; the syntax is incredibly flexible and simple.
The proof of this is that Smalltalk control structures, your if/then/else/switch/while/for/etc are not part of the language itself (discounting VM optimizations), they are simply implemented in the standard library using objects, polymorphism, and lots of higher order functions.
Just as Lisp macro's enable Lispers to add native control structures because Lisp itself uses the same mechanism, Smalltalk's simple lambda syntax [ code ] or [:arg | arg isX ] and special method naming syntax enable Smalltalk'ers to add native control structures because Smalltalk the language uses the same mechanism.
For example, you can't add your own "if" to Ruby that looks and works just like the built in "if", but you could in Smalltalk because that's how it was done in the first place. It's all library, classes and objects (functions in Lisp) and everything is built on top of that. Very few languages work this way, most have special keywords for control structures and you can't add to them.
> For a comparison point, during my day job, I write a large amount of Python in Emacs.
Great, also a great little language. Ah... but you're using Emacs, if you aren't aware that's just a Lisp image exactly the same thing as a Smalltalk image. You know exactly what working in an image is like, you do it daily.
> This code is for an application that runs in a REPL. Emacs gives the the ability to highlight code and run it.
Yup, Emacs is an image.
> I can call the "help" function on an object
On an object, or do you mean on a class in a file. Vastly different things. Object and class are not interchangeable words to use in this context.
> to see its documentation or the "dir" function to view all its members and methods.
I think you're talking about classes, not objects. And does this also include all source for the standard library as well, not just your application?
> I can load code at run time and patch new members onto classes or objects.
Yup, Python like Smalltalk is a very flexible dynamic language, but it didn't come out till a decade later and still isn't as flexible.
> Of course, that's the classic Blub programmer paragraph.
Yup, but at least you're aware of that, so you've ...
If all your experience and knowledge is born of Unix and the web, you don't really have available the necessary concepts to think about how a Smalltalk, or even a Lisp, actually works -- I know this because all of my experience and knowledge were born of Unix and the web, until recently, when I took it into my head to learn Lisp and also to gain at least a passing familiarity with Smalltalk. The difference is amazing -- in the preface of the UNIX-HATERS Handbook, written mostly by veterans of the Lisp years at SAIL, our modern computing environment is described thusly, by Ken Pier of Xerox PARC:
"I liken starting one's computing career with Unix, say as an undergraduate, to being born in East Africa. It is intolerably hot, your body is covered with lice and flies, you are malnourished and you suffer from numerous curable diseases. But, as far as young East Africans can tell, this is simply the natural condition and they live within it. By the time they find out differently, it is too late. They already think that the writing of shell scripts is a natural act."
Which I thought was hyperbole, too, until I spent some time discovering what sort of environment Pier and the SAIL folk took for granted. I don't unreservedly recommend the experiment; I earn my living in Pier's "East Africa", and sometimes I think I'd be better off if I didn't know how bad I have it. But I can certainly say that if you haven't tried it for yourself, you don't begin to know what you're missing.
The last time that I tried to learn Smalltalk, it was drilled into me that Smalltalk works directly with objects and not just their representations. For instance, the collection of black pixels on the screen was the Mouse object itself and not just a manifestation of a Mouse object somewhere in memory. A large amount of my confusion has possibly come from those lessons.
I agree that Lisp is an enlightening experience. I spent two years using Scheme as my primary programming language at work. Then again, I may just be stuck as a Blub programmer. I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
Yes and no, respectively.
Perhaps a heavily contrived example might help: Consider a system in which there is exactly one representation of an object member's value, which is stored in that object; when you call an accessor method, what you actually get is a reference, which is instantiated with an observer attached that listens for a notional "change" event, fired whenever the referred value is modified, and whose event handler updates whatever context exists around the reference, regardless of its nature, so that the displayed value matches that newly assigned to the object member.
...and now perhaps you can see why people familiar with Smalltalk think so highly of it; what in, for example, Javascript, would require an enormous amount of manual infrastructure and completely fail to generalize, in Smalltalk happens entirely transparently. It's not so much that you don't have to think about it; it's that there's nothing there to think about.
> I spent a year focused on Common Lisp, but never found any use for SLIME, despite using Emacs exclusively.
And now you've lost me. How can this possibly be the case? What was your Lisp workflow like? I mean, I can understand not getting the appeal of Lisp if you're just talking to the REPL and not working in an actual Lisp environment of the sort you get with Emacs Lisp or SLIME, but I have trouble understanding how anyone could work with those tools for a year without recognizing their potential.
Look, a cosmetic bug in this window. Right click on it, click Inspect. Looks like one of the properties has the wrong value. Edit the property from the inspector, fix the problem. The application was running the whole time and now is fixed.
An impressive thing you can do with Fuel is serialize and deserialize the exception with all state. Somebody blows up your web application. You wrote a bit of code to catch unhandled exceptions and export them with Fuel. You download the binary to your local computer and deserialize it in your live Smalltalk image. You see the debugger window pop up and can examine all the state when the error happened as if it popped up locally. See, examine, change the code, all of it live the whole time. (I don't know if this is done in practice much, but it's pretty normal to run a headless Smalltalk image and connect to it over VNC when you need to debug something).
To sum up, everything is live all the time in Smalltalk, and you can interactively change all the actual running instances, both code and data, at any time without interrupting anything.
It's really much more pleasant than shipping text files and interpreters all over the place and sorting through logfiles and tracebacks when things go south.
(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)
I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.
Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.
Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.
I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).
These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.
Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.
Source: I used to be a professional Smalltalker for almost three years.
Source: professional Smalltalker for about four years (fifteen years ago)
My opinion is the opposite: I find the IDE in Pharo to be simple and very elegant, far more human-friendly than any I've seen in 'mainstream' languages. And this version of Smalltalk is under heavy development, with a push towards even greater cohesion. This small corner of computing is seething with hot, cutting-edge activity.
> The text editors are pretty bad
Well, you ought to know that Smalltalk is focused on relatively small snippets of code, held together in consistent OO structures. There's hardly any point in fancy text-editing features when your methods are generally 8-12 lines long!
This! And also, in Pharo 3.0 there's being a huge push towards better text editing, although I've never ever needed more than what Pharo 1.0 did already provide...
You don't work with text in Smalltalk.
Any amount of text is still text, and Emacs excels at text editing.
While I really like Smalltalk, for some reason it does not work for me as a web development platform (and the web is my platform), or maybe I just don't grasp it.
I tried Seaside (http://www.seaside.st/) but the URLs it generates are not acceptable (unfortunately) and I find their component system quite complex. I hope someday I will find way to use the techniques behind Smalltalk (live environment, object model) in a browser or web environment. Maybe Amber will develop into something I can work with. I really hope so. Any suggestions anyone?
I love the idea of Smalltalk, but it also never stuck for me. I think I just prefer to learn from books than through milling around in the image. All the great minds in Smalltalk seem to be self-driven autodidacts. I'm not.
I'm pretty good at Haskell and Prolog though, so I think it works out in the end. I'm also not good at Lisp or Forth. :)
Although Iliad is not about generating clean URLs (it can, though), but more about being small and understandable, plus having Ajax for free and being pragmatic.
My complaint is that neither of these things is coming back in a relevant way.
Perhaps the biggest shift in software engineering in the last decade or two is the fact that no one writes entire systems anymore. We've moved to a system of (somewhat!) interchangeable parts. If your thoughtfully constructed, delicately handcrafted utopia doesn't play well with tools the user is used to and libraries the user needs, no one will use it in the real world.
Smalltalk, though a wonderful entire system in the 80's, hasn't kept up with computing progress. Most of its best features made it into other languages (Ruby and Obj-C are the premier examples), languages which aren't so opinionated about what OS you run, what IDE you're using, what language adjacent programs are written in, etc.
Much like Lisp Machines, the rest is left to rot, and incite wistful blog posts by old hands. And pretty much everyone else ships code in other languages.
However, the main point is that back then you haven't got HN, Reddit and the blogs of today.
As such not many geeks were fortunate enough to know and understand those systems, as consequence you have a legion of developers that cannot understand the beauty of those systems.
That's unfortunate. If we kept at it, we could have discovered much simpler ways of doing things than the current accumulation of leaky abstractions over leaky abstractions in a rather disintegrated environment. We can do better: http://www.vpri.org/pdf/tr2011004_steps11.pdf
Where is this directed? It sounds like a criticism of Lisp, Forth, Self, etc, but please correct. The fact that the ignorant masses flocked to C and Unix doesn't grant them one _iota_ of merit. C isn't even a good low-level language. And look at the most popular platform of them all - the web browser, if you want a good laugh.
When a young programmer asks me for advice about the next language to learn is, my advice is to go for the language that feels most alien. C++ won't enlighten a Java programmer significantly. Forth will.
- null terminated strings
- plain vectors
- manual management of resources (memory, files, db connections, locks...)
- C style casts
- pre-processor instead of using inline/const/templates
- the C subset of C++ it is also not 100% compatible with C, there are a few cases with different semantics
- since C99, new language constructs are added via macros, instead of keywords
- no use of namespaces
- lack of safety of parameters that can be changed (pointer vs reference parameters)
The best way to learn C++ is to read books like "Modern C++ Design", "Programming -- Principles and Practice Using C++" and the recently published "Tour of C++".
"Modern C++ Design" is really intended for advanced C++ programmers only. I don't feel it gives a very good impression of the language to new developers - there are so many awful hacks in that book.
It's the sort of thing that you should hold off on until you have the experience with the language necessary to be wise about when such techniques are appropriate.
But, again, there may be other languages more worthy of your effort.
I only leaned Java before touching C++ again because of my peculiar introduction to OOP and because I discarded the language after considering it an inelegant kludge, but, compared to Smalltalk, what language isn't?
And, finally, I decided to swallow my pride and learn C++ because I wanted to be part of the Brazilian electronic voting system projecy. Now, every ballot runs some C++ code I wrote.
If the company is that cool, give it a shot.
Perhaps systems like Smalltalk still have something to teach us?
Isn't Light Table essentially an effort to re-create the Smalltalk environment for modern languages?
I think one could make the case that Android shares many design decisions with a "Smalltalk machine". And the same actually goes for iOS, as objective-c is basically Smalltalk bolted on to c.
And then there is javascript that's modelled after Self -- so by extention chrome OS is also similar to a "Smalltalk machine".
Now why all these systems end up with some bastardized crappy programming languages rather than just using Smalltalk -- that I don't know.
The exception might be the one-laptop-per-child project.
So, I think it's wrong to say "it's not coming back" -- even java (for set-top boxes and smart devices) was an attempt at "bringing it back".
If anything, it seems these systems keep being reinvented.
Because Worse is Better[1]. For example Internet and the Web is a bastardized version of Xanadu Project[2]. HTML is a bastardized version of XML or XHTML. Worse is here now, when Better gets here, it's not Better anymore, only marginally more useful. That or it turns out the benefits Better has aren't that important or are highly impractical.
[1]http://en.wikipedia.org/wiki/Worse_is_better
[2]http://en.wikipedia.org/wiki/Xanadu_Project
Javascript was probably born out of Not Invented Here. Worse Is Better only contributed the curly braces from C, and the continued use of the first widely known scripting engine.
If The Right Thing is already there, Worse Is Better simply doesn't win without exterior help. Worse is better only because it's first. And even so…
> when Better gets here, it's not Better anymore, only marginally more useful.
I would say perceived as marginally more useful in the short term. This is a point where Worse easily looks Better, but whether it is is more debatable.
Worse is Better is omnipresent. Linux vs Minix vs BeOS vs Windows is example of Linux despite being bad relatively, simply winning out (on servers) due to its developer base and losing to Windows that despite numerous faults/warts won the desktop market by a large margin.
When I said Right Thing being here, I didn't mean existence, but presence. Right thing may exist in heads of few masters that know it super well, but them being unable or unwilling to spread it dooms the Right Thing. A Worse Thing that spreads far and wide will win and has always won.
Xanadu vs Internet
Linux vs BeOS
MacOS vs Windows
Lisp/Smalltalk vs C
You're being unfair: you compare a Javascript interpreter against a Smalltalk environment. Obviously, If I were in a rush, I would start with a simple interpreter first.
Realistically, if you don't really care about performance (I doubt Brendan Eich did at the time), implementing a JavaScript interpreter is neither easier nor harder than implementing a Lisp or Smalltalk or Self interpreter. I maintain that ease of implementation simply was not an influential factor either way.
Therefore, Javascript was invented for other reasons. My best guess is, Brendan Eich wanted his language to be non-intimidating to C, C++, and Java users. Apparently, it worked.
Oh. That is a typical "Worse is Better".
Okay, I retract. "Worse is Better" is an excellent explanation for Javascript. There are just other kinds of short term benefits persisting through time than the mere ease of implementation.
As for actually implementing a smaltalk interpreter, it can now be done in 300 lines: http://www.youtube.com/watch?v=EGeN2IC7N0Q (I believe he used Maru http://piumarta.com/software/maru/ ) With current techniques, a language specialist can implement Smalltalk in a day.
I'm not that strong, though. It could take me from a week to a month, depending on how much I need to learn. (Parsing the syntax is easy, but I'm less sure about the semantics.)
No, HTML was an SGML language (XHTML is of course an XML language). HTML5 is more of an "HTML"-like language...
SGML, if anything, is more powerful than XML -- but XML is a great effort to simplify SGML while maintaining most of the power.
For other SGML languages than HTML, look for docbook (which now also exist in an XML dress).
http://amber-lang.net
http://www.redline.st/
http://pharo-project.org
Saying Smalltalk hasn't kept up with computing progress is an old argument that doesn't make sense anymore.
No. A few of them have, usually in needlessly restricted and nigh-broken forms (Ruby's blocks are a pale and pitiful shadow of Smalltalk's). I've yet to see message cascading or conditions outside of lisps and smalltalk.
I have no clue what it means to live amongst your objects and touch and feel and turn and taste them. That article didn't really explain what that means, but I'll take him at his word.
Crap article.
"Unfortunately, no one can be told what the Matrix is. You have to see it for yourself."
"After this, there is no turning back. You take the blue pill - the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill - you stay in Wonderland and I show you how deep the rabbit-hole goes."
Try the red pill... (And think of turtles rather than rabbits!)
In a live environment it is easy to make experimentations because you can get very quick feedbacks, and there is no need to switch between modes like development to execution or execution to development. Catching and fixing certain bugs is also easier as I showed before.
I think there is a need for this kind of development, that's why people try implementing code hotswapping and class reloading capabilities in various programming environemnts. But still most of them are just limited workarounds compared to smalltalk where live coding works fine for decades.
These notebook interfaces are REPLs, but they're a little more user friendly in the sense that you can edit history in place instead of doing a history completion and then evaluating an additional line.
Has anybody had any experience with these notebook interfaces as well as the smalltalk environment and can give a rundown of the differences?