When I was even more of a newbie programmer than I am now, I stumbled across Pharo and the Seaside framework. Both of them have excellent tutorials which taught me a lot about MVC, OO, and proper application design. I went on to build a prototype in Seaside and found it to be a very enjoyable experience.
For instance, if I messed up something in my code and had an error, the debugger pops up. In this debugger I can not only browse the stack trace and manipulate those objects, I can actually fix what is broken and resume execution of the program from that point.
In Seaside's dev mode I can toggle viewing all the components that make up the currently displayed page (a page isn't a textual template, but is constructed from objects). I could manipulate those objects in the browser and see the effects of those changes immediately. This was useful both in exploring solutions to problems and in debugging code.
Having experienced such tools, it's hard not to miss them when programming in another language. I used to use Light Table with Clojure and Javascript to kind of recreate the effect, but what the author writes is true: abandoning your familiar textual tools lets you do some really awesome things. It completely changes your development and debugging workflow.
I'd love to be able to program in Smalltalk professionally, but I really couldn't find that kind of gig (especially entry level) in my area. But even if you can't see an immediate business use case, just spend a weekend going through the Pharo and Seaside tutorials. If learning lisp is important "not because you'll use it but because it will forever change you" (to paraphrase) then learning Smalltalk is important in the same way. Just be aware that when you have to go back to another environment, you might be a bit sad. :)
For instance, if I messed up something in my code and had an error, the debugger pops up. In this debugger I can not only browse the stack trace and manipulate those objects, I can actually fix what is broken and resume execution of the program from that point
The developer tools in Chrome and Firefox remind me of the Smalltalk IDEs. I don't know if it's intentional or accidental, but the similarities suggest to me that some of the ideas from Smalltalk have been carried over to web development.
If learning lisp is important "not because you'll use it but because it will forever change you" (to paraphrase) then learning Smalltalk is important in the same way.
Learning Common Lisp is like learning Smalltalk in another way, Common Lisp shares some of Smalltalk's features.
For instance, if I messed up something in my code and had an error, the debugger pops up. In this debugger I can not only browse the stack trace and manipulate those objects, I can actually fix what is broken and resume execution of the program from that point.
This is also true for Common Lisp. When I hit a bug, I can edit the broken code, reload it, and resume execution from where the program stopped. I can load edited code and freeze the program to inspect objects at any time. It's enjoyable to edit some opengl code and see changes in real time.
I used to use Light Table with Clojure and Javascript to kind of recreate the effect, but what the author writes is true: abandoning your familiar textual tools lets you do some really awesome things. It completely changes your development and debugging workflow.
If anyone was wondering why some people don't like Clojure being described as a modern Lisp or the future of Lisp, this is one reason.
I used SmallTalk for a while and loved it but when I moved on to more traditional programming I never missed the SmallTalk days. I did learn a lot of stuff that I applied later on, though. Exact same experience with Lisp.
In terms of OO it is kinda awesome, with its class hierarchy and that everything is an object, even classes.
But the whole IDE-entanglement was awful.
I have the feeling, that this is a big problem, we have in many places today. You can't always have syntax A in system B and programm with IDE C. Often you have to use what is available...
Smalltalk is not the Grand Old Man of programming languages, but the future of software development created 40 years in the past.
Yup. And that future was realized in systems less monolithic than Smalltalk. The WIMP interface made it to most major platforms by 1990. Objective-C and later Ruby swiped Smalltalk's message passing semantics and basic object model and freed it from its all-or-nothing execution environment. And tons of languages (not least of which is C++) have taken Smalltalk's cue on object oriented design.
What more is there left for Smalltalk to accomplish? That's not bad, for a language which basically never made it out of PARC for two decades!
Smalltalk as a live environment blurs the boundaries between runtime and editing code. There's a video on ThingLab[1], a constraint solver, from 1978 where Alan Borning draws constraints graphically and then switches view to show the code that was generated. When he manipulates a constraint the runtime creates and compiles a new method based on the system that was graphically defined. That kind of thing would still be pretty awesome today (who generates JS at runtime for performance?).
Your comment reads a bit like "we cargo-culted the things we could see in the Smalltalk environment, but didn't understand the underlying philosophy or elegance of what had been made; what's left to learn?" (I know that's probably not what you meant, but I feel like there's a lot left to learn from Smalltalk and the tools that were built with it).
Also check out: https://github.com/cdglabs/thinglab -- there's a link to a St-78 image with ThingLab. Also interesting to note proportional fonts, text selection (by Larry Tesler) and popup menus, all of which I thought came later...
Your comment reads a bit like "we cargo-culted the things we could see in the Smalltalk environment, but didn't understand the underlying philosophy or elegance of what had been made; what's left to learn?"
Seeing features you like and porting them to a system where you can use them isn't cargo culting. It's progress.
Unless you miss the bigger picture. Of course you can use any part you like but if the main value comes from a combination which you are no longer using while you still thinks you're using the same method/idea it might be seen as cargo culture.
Reducing "Smalltalk experience" to "windows, images, menus and pointer" is a gross mischaracterisation. Reducing "Smalltalk the language" to message passing is similarly unfair.
Imagine an environment where you can modify and debug every single program you run without ever restarting it; where every little part of GUI of every program is there for you to manipulate (in real time, without restarting) if you want. Environment where you can grab an item from a deeply nested menu and pin it to the desktop, change its color and make it spin, while still being able to click it and invoke the function it's supposed to call. Environment where you can inspect and modify everything in real time (have you seen "Inventing on Principle" by Bret Victor?), from GUI artifacts to underlying models, to system resources, to the very core of the system. An environment which you can clone with one click and run anywhere with a real, not Java-like, guarantee that it will work exactly the same way as for you.
Well, that's still not quite it and there are many other things "left for Smalltalk to accomplish", but hopefully you get the picture.
We use Smalltalk for a good portion of our distributed control system on our semiconductor manufacturing equipment (at least the non-RT critical portions). It's actually sort of awesome to be able to test/rework/enhance the software on the fly as we discover things we'd like to change in the clean room without having to go through traditional implement/build/deploy cycles. There's certainly other caveats about working in the environment we have, but those we can chat about offline :).
From what I've read and played with (briefly), JRebel gives you a bit of this experience on the Java side as well, though I've never used it extensively enough to know if it delivers a comparable experience.
It's not that far removed from what many web application developers take for granted in terms of ability to make/test/refine changes on a live system with ease, but it does bring more of this experience to other functional domains.
> And tons of languages (not least of which is C++) have taken Smalltalk's cue on object oriented design.
Is that a joke? C++'s approach to OO is practically antithetical to Smalltalk's. There's a famous Alan Kay quote about it.
> Objective-C and later Ruby swiped Smalltalk's message passing semantics and basic object model and freed it from its all-or-nothing execution environment.
Actually, there have been many implementations of Smalltalk since the old days of park that have "freed it from its all-or-nothing execution environment".
"...it's interesting, again, to look at what is actually being done in the world under the name of OOP. I've been shown some very, very strange-looking pieces of code over the years by various people, including people in universities, that they have said is OOP code, and written in an OOP language—and actually, I made up the term object-oriented, and I can tell you I did not have C++ in mind. [Laughter and applause] An important thing here is—I have many of the same feelings about Smalltalk..."
Software developers are human. Therefore, they are also creatures of habit. Once inured to the clumsy use of files and folders and lifeless, non-dynamic programming methods, once they grow emotionally and intellectually attached to their file-based tools and infrastructure, they are incapable of appreciating any other way to do things. They’ve become so efficient at doing things the hard way that it seems, to them at least, the best way to write software. These aren’t stupid people; they are simply habituated.
Yeah, it's the usual condescending "If you don't see the stupendousness of our approach, it's because you're not enlightened yet!" that we also get from Lisp and Haskell types. Spare us.
The rest of the article wasn't bad, but that one paragraph really turned me off. If I don't do it your way, could you please stop assuming that it's because I don't know any better? It may be because I actually do know better.
> Yeah, it's the usual condescending "If you don't see the stupendousness of our approach, it's because you're not enlightened yet!" that we also get from Lisp and Haskell types. Spare us.
Alternatively, it's the recognition that the switching costs to unfamiliar technology are non-zero.
> If I don't do it your way, could you please stop assuming that it's because I don't know any better? It may be because I actually do know better.
It may be, but there is a pretty huge in between space where you don't know any better.
I think you'll find people will believe that if you put in enough "escape effort" to pull yourself out of the habit. If you don't, you can't really know, which makes it condescending for you to assert you know better.
So there's this big space where neither party is in a position to judge, but the advocates want you to try. Somehow, that always seems to get internalized as, "they think they know better". They don't. They've found it to be a big win for them and other people, and they have an educated guess that therefore it'll be better for you, even if it initially doesn't seem like it. That's really not unreasonable.
> So there's this big space where neither party is in a position to judge, but the advocates want you to try. Somehow, that always seems to get internalized as, "they think they know better". They don't. They've found it to be a big win for them and other people, and they have an educated guess that therefore it'll be better for you, even if it initially doesn't seem like it. That's really not unreasonable.
That's fine. There's a totally reasonable case to be made for that, for Smalltalk, Haskell, and Lisp (at least). The advocates just need to express it in a way that doesn't come across as "I'm enlightened; you're ignorant. Once you're enlightened, you'll do it my way." That's counter-productive. It turns people off rather than encouraging them to try it and see.
I don't think that's what the article is saying at all. It says that when you've done things the same way for most or all of your professional life, as I have (30 years programming in FORTRAN, C/C++/C#/Objective-C, Java, Python using text editors, textual compilers, command line tools of all sorts, Eclipse, Visual Studio), you become so used to it, you become so good and efficient at it, that it seems like the only or best way to develop software. You find yourself in a comfort zone. This was my experience; I was your typical code jockey.
However, even after 30 years, I still had a tiny feeling inside of me that there was a better way to do things, one that was easier on my brain. All I had to do was "let go." Let go of my preconceptions. Open my mind to other possibilities. Recognize that my past experience was based on crude methods from decades ago (circa 1980) that have been optimized and refined to their current stratospheric levels.
When I first tried Smalltalk, it took a little while to change my mindset and adapt. Now, I see why it is such a super-productive tool. It directly aids the natural, cognitive flow of developing an application concept. There is less stress on my brain (whether I'm aware of that stress or not – most people are not). The result is that I can write an application in a fraction of the time that it would've taken me in Java or C#. And it's more fun, to boot!
If we could pit the world's best Java programmer against the world's best Smalltalk programmer in a cage match to see who finishes a moderate-size application first, I know who I'd bet on. I wasn't exaggerating when I said "a fraction of the time."
You have no idea how refreshing it is to only keep a minimalist language in your head. Thanks to the simplicity and elegance of the syntax, code is easier to write than in Java, and much, much easier to read. It takes more cognitive effort to read C++ or Java or Haskell or Clojure. How can anyone take issue with this??
People are always saying how much more expressive this language is over that one because of some much-touted language feature(s). Aside from anecdotal tales, I've never seen scientific evidence that language features overall have a great impact on how algorithms are implemented. Sure, some languages are exceptional in narrow problem domains, but for general-purpose programming across multiple domains, I've never seen much difference among the dozen languages I've used. Certainly, Smalltalk is not constrained in this respect for most use cases.
So, no, you're not ignorant. You just haven't tried to break out of your comfort zone for whatever personal reasons you may have. If the suggestion that you're human offends you, then you need to dial back your sensitivity because all I'm doing is calling it as I see it.
> The advocates just need to express it in a way that doesn't come across as "I'm enlightened; you're ignorant. Once you're enlightened, you'll do it my way."
But I think if you look at what they say, it really is as much the responsibility of the listener whether it is interpreted that way. Even the above quote, which I'm sure someone didn't say to you, can be interpreted as, "don't knock it until you've tried it".
It's impossible to just read about Smalltalk and poke around a bit, and think one knows. The language itself is a tiny part of things, and one needs to really get immersed in the environment to really appreciate things.
Maybe you know better, the author could have put things better. But I am sure a lot of people don't know, I know I was one of them. Even after a long time Smalltalker gave an enthusiastic (to put it mildly) 2 hour demo. Now I've become the rabidly enthusiastic one, but most people think I am passionate about historical programming languages.
What other environment can you trivially do this:
- can't find a method, but know what you want: provide sample inputs and an output, and (at least Pharo and Squeak Smalltalk) will find you all methods that produce the output.
- trouble visualizing relationships while debugging? Script some code in a few minutes that become part of your debugger to see what is going on.
- really code live - there is "hot swapping", but it's something bolted onto a rigid foundation, and eventually fails. In Smalltalk, it's a foundational element.
Though the author could have put things differently, it can be difficult when so much that is mainstream feels so primitive, with layer upon layer of cruft bolted on. Programming in Smalltalk is uninterrupted bliss, then I go to work and use tools that have roots that predate Smalltalk, but Smalltalk is talked about as the "old" curiosity.
Excuse the rant - Smalltalk makes me feel like I am using a polished and refined set of tools, and then day to day I run around with crude stone tools, the "modern" way. I think the author feels the same way.
And what is it that you know better? It would be difficult to defend current software development practice as being ideal or supremely productive. However, I can see other non-technical reasons for sticking with what you know. For example, your business organization may not be willing to overhaul its IT operations in order to support Smalltalk. There would be financial costs. There would be hiring issues (from what talent pool would you draw from?). There would be lack of managerial experience in running a Smalltalk project. There would be interoperability issues with existing applications. And so on.
But from the purely technical standpoint, you have to know that the way things are cannot be ideal. There will always be easier and more productive ways to write software. The trick is to find out what those ways are.
These tend to be challenges, or at least sources of complaint, for image based development environments like Smalltalk and Lisp.
Have modern Smalltalks successfully addressed these issues? Even if Smalltalk has its own tools to address some of these, are they as good, as flexible, and as well supported as the tools available to work with plain text source files?
Lisp is a family of languages and literally hundreds of implementations. Lisp is not a 'development enviroment'. Many Lisp implementations support 'image based development'. But most also support 'file based development'. A few even support only 'file based development'.
I would go so far as to say that the "MIT style" of using Lisp is file rather than image based. Saving and restoring an image is purely for minimizing startup time, and in development would only be done when you're at a point where that makes sense. And you'd start from a fresh band, LOAD all the relevant files, and then save. If you're doing an application, it might not make sense to ever go to the trouble.
On the Symbolics Lisp Machine it was common to create incremental Worlds. From an incremental image one could write a new incremental image.
For example I used to save a minimal site-configured incremental image with some OS patches first. From there I would load the software I use and dump the next incremental image. Into this image I would load more software and the stuff under development and make another incremental image. Based on this I would load additional patches as necessary...
The reason why these images were saved is not startup time. The reason was that loading code (-> applications) was quite slow on most Symbolics Lisp Machines during the 80s.
If you develop on a Symbolics Lisp Machine it first looks into the running image for many types of information, not the file system: documentation strings, arguments, who calls, ... even the documentation database needs its index to be loaded into the image.
Dependency Management: Yes.
Source code control: Yes (proprietary, file based/git)
Continuous Integration: Jenkins, TravisCI, TeamCity
Deployment: I'm aware of people using Docker and Ansible, and regular file copy/scp deployment.
I don't know what defines the verb "good", "flexible" and "well supported". I think they are. File based VCS is not out of the box, but is an available feature and many people are moving to that in order to use GitHub or similar services.
Dependency management: Metacello does that. Even though it's not as neat and easy as Bundler or Gradle/MavenCentral it does the job. There are no centralized place à la RubyGems/CPAN/Cocoapod so it can be messy to locate up-to-date packages.
Source code control: Yep. There's a slow transition from Monticello to Git but tools are still subpar. Trying to integrate thing that are not Smalltalk code into monticello is a pain.
Continuous integration: Yep. Everything is doable from the command line. The Pharo guys actually build everything with Jenkins (https://ci.inria.fr/pharo/).
My everyday job involves Ruby+Rails, Objective-C and Android development.
Programming in Pharo Smalltalk feels much better than any of those but in the end of the day, those tools get us faster at the results our clients want (usually some kind of mobile app with a backend).
First, let me say that I love Smalltalk. It's a beautifully language that follows such a consistent design philosophy. It demonstrates the power of orthogonality, generalization, and abstraction in the design of programming languages like few other programming languages have. I studied and studied the blue and green books in the eighties and they provided me with my first look at meta-object level programming.
What are the challenges of programming and how does Smalltalk address them? It seems to me that our big challenges are correctness, how we know that our programs meet the specifications; performance, across a wide range of hardware (highly parallel, wide instruction words, low power, embedded, etc.); programmability, this includes expressiveness and ease of learning the language and its fit with the problem domains where it is employed; and finally, maintainability, which entails the life-cycle costs of programs written in the language.
Smalltalk was a very important and influencial language in the history of computing. Is it the future? How does it address these important issues? Spinning some user interface component doesn't impress me. Work on immutable data and STM (ala Clojure) impresses me. Functional programming (e.g. Haskell) impresses me. Large numbers of useful packages (like Python) impresses me. Highly efficient compilers (like modern Fortran, C++, Ada and JITs like Javascript and Lua) impress me. Being able to modify a running program doesn't. How in the world does one untangle the train wreck of all the incorrect intermediate calculations when a program finally produces a wrong answer?
Smalltalk was a darling of the Computer Science community decades ago. Implementations have been around for a long long time (I have still have my Smalltalk/V 286 manual from Digitalk, it ran on my IBM PC-AT). It would surprise me if a language that has evolved as little as Smalltalk has would suddenly, after all these years, be the future of programming. Hasn't it already had it chance?
Be prepared to be surprised. Yes, historically Smalltalk has evolved rather slowly. However, with the Pharo project, Smalltalk is enjoying a resurgence because the project is working vigorously to evolve Smalltalk to the next level. Check back in another year or so and see some major improvements. That's why I say, this is not your father's Smalltalk.
BTW, functional programming does not impress me at all...
"Programming with the Object Oriented paradigm is creating a program by identifying and modeling the Problem Domain Entities as objects, and then make them collaborate between themselves to solve each problem instance. Programming with the Functional paradigm is modeling the problem as a mathematical problem, and creating a mathematical function (by composing other functions) that for each problem instance, computes the problem solution."
(From http://goo.gl/K4U0Nh)
It is unnatural for humans to model the world in a functional way. The world consists of objects, not functions. That's why I've never liked FP.
38 comments
[ 2.5 ms ] story [ 78.7 ms ] threadSure, not used by the, "cool kids" in SF, but still used.
For instance, if I messed up something in my code and had an error, the debugger pops up. In this debugger I can not only browse the stack trace and manipulate those objects, I can actually fix what is broken and resume execution of the program from that point.
In Seaside's dev mode I can toggle viewing all the components that make up the currently displayed page (a page isn't a textual template, but is constructed from objects). I could manipulate those objects in the browser and see the effects of those changes immediately. This was useful both in exploring solutions to problems and in debugging code.
Having experienced such tools, it's hard not to miss them when programming in another language. I used to use Light Table with Clojure and Javascript to kind of recreate the effect, but what the author writes is true: abandoning your familiar textual tools lets you do some really awesome things. It completely changes your development and debugging workflow.
I'd love to be able to program in Smalltalk professionally, but I really couldn't find that kind of gig (especially entry level) in my area. But even if you can't see an immediate business use case, just spend a weekend going through the Pharo and Seaside tutorials. If learning lisp is important "not because you'll use it but because it will forever change you" (to paraphrase) then learning Smalltalk is important in the same way. Just be aware that when you have to go back to another environment, you might be a bit sad. :)
The developer tools in Chrome and Firefox remind me of the Smalltalk IDEs. I don't know if it's intentional or accidental, but the similarities suggest to me that some of the ideas from Smalltalk have been carried over to web development.
So if you like Seaside, don't be shy an offer to use that power in doing something valuable to someone.
Learning Common Lisp is like learning Smalltalk in another way, Common Lisp shares some of Smalltalk's features.
For instance, if I messed up something in my code and had an error, the debugger pops up. In this debugger I can not only browse the stack trace and manipulate those objects, I can actually fix what is broken and resume execution of the program from that point.
This is also true for Common Lisp. When I hit a bug, I can edit the broken code, reload it, and resume execution from where the program stopped. I can load edited code and freeze the program to inspect objects at any time. It's enjoyable to edit some opengl code and see changes in real time.
I used to use Light Table with Clojure and Javascript to kind of recreate the effect, but what the author writes is true: abandoning your familiar textual tools lets you do some really awesome things. It completely changes your development and debugging workflow.
If anyone was wondering why some people don't like Clojure being described as a modern Lisp or the future of Lisp, this is one reason.
But the whole IDE-entanglement was awful.
I have the feeling, that this is a big problem, we have in many places today. You can't always have syntax A in system B and programm with IDE C. Often you have to use what is available...
Don't get me wrong I would love to use Smalltalk in anger. But that ship has sailed. Fight the battles you can win.
https://smalltalkjobs.wordpress.com
Yup. And that future was realized in systems less monolithic than Smalltalk. The WIMP interface made it to most major platforms by 1990. Objective-C and later Ruby swiped Smalltalk's message passing semantics and basic object model and freed it from its all-or-nothing execution environment. And tons of languages (not least of which is C++) have taken Smalltalk's cue on object oriented design.
What more is there left for Smalltalk to accomplish? That's not bad, for a language which basically never made it out of PARC for two decades!
Your comment reads a bit like "we cargo-culted the things we could see in the Smalltalk environment, but didn't understand the underlying philosophy or elegance of what had been made; what's left to learn?" (I know that's probably not what you meant, but I feel like there's a lot left to learn from Smalltalk and the tools that were built with it).
[1]: http://en.wikipedia.org/wiki/ThingLab (see link 4 for the video; it's really fun to watch).
Also check out: https://github.com/cdglabs/thinglab -- there's a link to a St-78 image with ThingLab. Also interesting to note proportional fonts, text selection (by Larry Tesler) and popup menus, all of which I thought came later...
Seeing features you like and porting them to a system where you can use them isn't cargo culting. It's progress.
Imagine an environment where you can modify and debug every single program you run without ever restarting it; where every little part of GUI of every program is there for you to manipulate (in real time, without restarting) if you want. Environment where you can grab an item from a deeply nested menu and pin it to the desktop, change its color and make it spin, while still being able to click it and invoke the function it's supposed to call. Environment where you can inspect and modify everything in real time (have you seen "Inventing on Principle" by Bret Victor?), from GUI artifacts to underlying models, to system resources, to the very core of the system. An environment which you can clone with one click and run anywhere with a real, not Java-like, guarantee that it will work exactly the same way as for you.
Well, that's still not quite it and there are many other things "left for Smalltalk to accomplish", but hopefully you get the picture.
From what I've read and played with (briefly), JRebel gives you a bit of this experience on the Java side as well, though I've never used it extensively enough to know if it delivers a comparable experience.
It's not that far removed from what many web application developers take for granted in terms of ability to make/test/refine changes on a live system with ease, but it does bring more of this experience to other functional domains.
Is that a joke? C++'s approach to OO is practically antithetical to Smalltalk's. There's a famous Alan Kay quote about it.
> Objective-C and later Ruby swiped Smalltalk's message passing semantics and basic object model and freed it from its all-or-nothing execution environment.
Actually, there have been many implementations of Smalltalk since the old days of park that have "freed it from its all-or-nothing execution environment".
Alan Kay's C++ quote comes from his speech, "The Computer Revolution Hasn't Happened Yet":
http://blog.moryton.net/2007/12/computer-revolution-hasnt-ha...
"...it's interesting, again, to look at what is actually being done in the world under the name of OOP. I've been shown some very, very strange-looking pieces of code over the years by various people, including people in universities, that they have said is OOP code, and written in an OOP language—and actually, I made up the term object-oriented, and I can tell you I did not have C++ in mind. [Laughter and applause] An important thing here is—I have many of the same feelings about Smalltalk..."
Yeah, it's the usual condescending "If you don't see the stupendousness of our approach, it's because you're not enlightened yet!" that we also get from Lisp and Haskell types. Spare us.
The rest of the article wasn't bad, but that one paragraph really turned me off. If I don't do it your way, could you please stop assuming that it's because I don't know any better? It may be because I actually do know better.
Alternatively, it's the recognition that the switching costs to unfamiliar technology are non-zero.
> If I don't do it your way, could you please stop assuming that it's because I don't know any better? It may be because I actually do know better.
It may be, but there is a pretty huge in between space where you don't know any better.
I think you'll find people will believe that if you put in enough "escape effort" to pull yourself out of the habit. If you don't, you can't really know, which makes it condescending for you to assert you know better.
So there's this big space where neither party is in a position to judge, but the advocates want you to try. Somehow, that always seems to get internalized as, "they think they know better". They don't. They've found it to be a big win for them and other people, and they have an educated guess that therefore it'll be better for you, even if it initially doesn't seem like it. That's really not unreasonable.
That's fine. There's a totally reasonable case to be made for that, for Smalltalk, Haskell, and Lisp (at least). The advocates just need to express it in a way that doesn't come across as "I'm enlightened; you're ignorant. Once you're enlightened, you'll do it my way." That's counter-productive. It turns people off rather than encouraging them to try it and see.
However, even after 30 years, I still had a tiny feeling inside of me that there was a better way to do things, one that was easier on my brain. All I had to do was "let go." Let go of my preconceptions. Open my mind to other possibilities. Recognize that my past experience was based on crude methods from decades ago (circa 1980) that have been optimized and refined to their current stratospheric levels.
When I first tried Smalltalk, it took a little while to change my mindset and adapt. Now, I see why it is such a super-productive tool. It directly aids the natural, cognitive flow of developing an application concept. There is less stress on my brain (whether I'm aware of that stress or not – most people are not). The result is that I can write an application in a fraction of the time that it would've taken me in Java or C#. And it's more fun, to boot!
If we could pit the world's best Java programmer against the world's best Smalltalk programmer in a cage match to see who finishes a moderate-size application first, I know who I'd bet on. I wasn't exaggerating when I said "a fraction of the time."
You have no idea how refreshing it is to only keep a minimalist language in your head. Thanks to the simplicity and elegance of the syntax, code is easier to write than in Java, and much, much easier to read. It takes more cognitive effort to read C++ or Java or Haskell or Clojure. How can anyone take issue with this??
People are always saying how much more expressive this language is over that one because of some much-touted language feature(s). Aside from anecdotal tales, I've never seen scientific evidence that language features overall have a great impact on how algorithms are implemented. Sure, some languages are exceptional in narrow problem domains, but for general-purpose programming across multiple domains, I've never seen much difference among the dozen languages I've used. Certainly, Smalltalk is not constrained in this respect for most use cases.
So, no, you're not ignorant. You just haven't tried to break out of your comfort zone for whatever personal reasons you may have. If the suggestion that you're human offends you, then you need to dial back your sensitivity because all I'm doing is calling it as I see it.
Denial is not a river in Africa.
But I think if you look at what they say, it really is as much the responsibility of the listener whether it is interpreted that way. Even the above quote, which I'm sure someone didn't say to you, can be interpreted as, "don't knock it until you've tried it".
Maybe you know better, the author could have put things better. But I am sure a lot of people don't know, I know I was one of them. Even after a long time Smalltalker gave an enthusiastic (to put it mildly) 2 hour demo. Now I've become the rabidly enthusiastic one, but most people think I am passionate about historical programming languages.
What other environment can you trivially do this: - can't find a method, but know what you want: provide sample inputs and an output, and (at least Pharo and Squeak Smalltalk) will find you all methods that produce the output. - trouble visualizing relationships while debugging? Script some code in a few minutes that become part of your debugger to see what is going on. - really code live - there is "hot swapping", but it's something bolted onto a rigid foundation, and eventually fails. In Smalltalk, it's a foundational element.
Though the author could have put things differently, it can be difficult when so much that is mainstream feels so primitive, with layer upon layer of cruft bolted on. Programming in Smalltalk is uninterrupted bliss, then I go to work and use tools that have roots that predate Smalltalk, but Smalltalk is talked about as the "old" curiosity.
Excuse the rant - Smalltalk makes me feel like I am using a polished and refined set of tools, and then day to day I run around with crude stone tools, the "modern" way. I think the author feels the same way.
And what is it that you know better? It would be difficult to defend current software development practice as being ideal or supremely productive. However, I can see other non-technical reasons for sticking with what you know. For example, your business organization may not be willing to overhaul its IT operations in order to support Smalltalk. There would be financial costs. There would be hiring issues (from what talent pool would you draw from?). There would be lack of managerial experience in running a Smalltalk project. There would be interoperability issues with existing applications. And so on.
But from the purely technical standpoint, you have to know that the way things are cannot be ideal. There will always be easier and more productive ways to write software. The trick is to find out what those ways are.
These tend to be challenges, or at least sources of complaint, for image based development environments like Smalltalk and Lisp.
Have modern Smalltalks successfully addressed these issues? Even if Smalltalk has its own tools to address some of these, are they as good, as flexible, and as well supported as the tools available to work with plain text source files?
Or so I remember as of the early '80s.
For example I used to save a minimal site-configured incremental image with some OS patches first. From there I would load the software I use and dump the next incremental image. Into this image I would load more software and the stuff under development and make another incremental image. Based on this I would load additional patches as necessary...
The reason why these images were saved is not startup time. The reason was that loading code (-> applications) was quite slow on most Symbolics Lisp Machines during the 80s.
If you develop on a Symbolics Lisp Machine it first looks into the running image for many types of information, not the file system: documentation strings, arguments, who calls, ... even the documentation database needs its index to be loaded into the image.
Dependency Management: Yes. Source code control: Yes (proprietary, file based/git) Continuous Integration: Jenkins, TravisCI, TeamCity Deployment: I'm aware of people using Docker and Ansible, and regular file copy/scp deployment.
I don't know what defines the verb "good", "flexible" and "well supported". I think they are. File based VCS is not out of the box, but is an available feature and many people are moving to that in order to use GitHub or similar services.
Source code control: Yep. There's a slow transition from Monticello to Git but tools are still subpar. Trying to integrate thing that are not Smalltalk code into monticello is a pain.
Continuous integration: Yep. Everything is doable from the command line. The Pharo guys actually build everything with Jenkins (https://ci.inria.fr/pharo/).
Deployment: I use ansible to provision my server and to deploy webapps. Nothing really fancy (https://github.com/fstephany/hello-pharo/).
My everyday job involves Ruby+Rails, Objective-C and Android development.
Programming in Pharo Smalltalk feels much better than any of those but in the end of the day, those tools get us faster at the results our clients want (usually some kind of mobile app with a backend).
What are the challenges of programming and how does Smalltalk address them? It seems to me that our big challenges are correctness, how we know that our programs meet the specifications; performance, across a wide range of hardware (highly parallel, wide instruction words, low power, embedded, etc.); programmability, this includes expressiveness and ease of learning the language and its fit with the problem domains where it is employed; and finally, maintainability, which entails the life-cycle costs of programs written in the language.
Smalltalk was a very important and influencial language in the history of computing. Is it the future? How does it address these important issues? Spinning some user interface component doesn't impress me. Work on immutable data and STM (ala Clojure) impresses me. Functional programming (e.g. Haskell) impresses me. Large numbers of useful packages (like Python) impresses me. Highly efficient compilers (like modern Fortran, C++, Ada and JITs like Javascript and Lua) impress me. Being able to modify a running program doesn't. How in the world does one untangle the train wreck of all the incorrect intermediate calculations when a program finally produces a wrong answer?
Smalltalk was a darling of the Computer Science community decades ago. Implementations have been around for a long long time (I have still have my Smalltalk/V 286 manual from Digitalk, it ran on my IBM PC-AT). It would surprise me if a language that has evolved as little as Smalltalk has would suddenly, after all these years, be the future of programming. Hasn't it already had it chance?
"Programming with the Object Oriented paradigm is creating a program by identifying and modeling the Problem Domain Entities as objects, and then make them collaborate between themselves to solve each problem instance. Programming with the Functional paradigm is modeling the problem as a mathematical problem, and creating a mathematical function (by composing other functions) that for each problem instance, computes the problem solution." (From http://goo.gl/K4U0Nh)
It is unnatural for humans to model the world in a functional way. The world consists of objects, not functions. That's why I've never liked FP.
Does this mean I can get a job now, despite having learned the language in 1996?