8 ms·

The Smalltalk Revolution

84 points by horrido 12y ago

__abc 12y ago
I guess I'm the exception in that I spent a few years in Smalltalk in the mid 2000's and thus never viewed it as irrelevant. Sure, not used by the, "cool kids" in SF, but still used.
muraiki 12y ago
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. :)
- kyllo 12y ago
  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.
- sebastianconcpt 12y ago
  Don't feel limited by your area. Remote development is starting to catch on and you usually can use whatever tack that makes you a great deliverer. So if you like Seaside, don't be shy an offer to use that power in doing something valuable to someone.
- current_call 12y ago
  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.
zwieback 12y ago
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.
- k__ 12y ago
  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...
gaius 12y ago
What killed Smalltalk was the $10,000/seat licenses. There was very limited scope for anyone to "kick the tyres". But it's OK, we have C++14 now. Don't get me wrong I would love to use Smalltalk in anger. But that ship has sailed. Fight the battles you can win.
- sebastianconcpt 12y ago
  Well niche is not bad. There are gigs in Smalltalk: https://smalltalkjobs.wordpress.com https://smalltalkjobs.wordpress.com
  - gaius 12y ago
    5 jobs a month, in the entire world?
gamache 12y ago
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!
- i_am_ralpht 12y ago
  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). [1]: http://en.wikipedia.org/wiki/ThingLab 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 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...
  - gamache 12y ago
    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.
AnimalMuppet 12y ago
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.
- cbsmith 12y ago
  > 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.
  - AnimalMuppet 12y ago
    > 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.
jimbokun 12y ago
Dependency management. Source code control. Continuous integration. Deployment. 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?
- fstephany 12y ago
  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/ 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/ 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).
- lispm 12y ago
  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'.
  - hga 12y ago
    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. Or so I remember as of the early '80s.
todd8 12y ago
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?
- horrido 12y ago
  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.
- horrido 12y ago
  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 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.
MichaelCrawford 12y ago
hey I know smalltalk. I'm really good at it and I like it. Does this mean I can get a job now, despite having learned the language in 1996?

84 points by horrido 12y ago

__abc 12y ago

I guess I'm the exception in that I spent a few years in Smalltalk in the mid 2000's and thus never viewed it as irrelevant. Sure, not used by the, "cool kids" in SF, but still used.

muraiki 12y ago

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. :)

kyllo 12y ago
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.
sebastianconcpt 12y ago
Don't feel limited by your area. Remote development is starting to catch on and you usually can use whatever tack that makes you a great deliverer. So if you like Seaside, don't be shy an offer to use that power in doing something valuable to someone.
current_call 12y ago
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.

zwieback 12y ago

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.

k__ 12y ago
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...

gaius 12y ago

What killed Smalltalk was the $10,000/seat licenses. There was very limited scope for anyone to "kick the tyres". But it's OK, we have C++14 now. Don't get me wrong I would love to use Smalltalk in anger. But that ship has sailed. Fight the battles you can win.

sebastianconcpt 12y ago
Well niche is not bad. There are gigs in Smalltalk: https://smalltalkjobs.wordpress.com https://smalltalkjobs.wordpress.com
- gaius 12y ago
  5 jobs a month, in the entire world?

gamache 12y ago

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!

i_am_ralpht 12y ago
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). [1]: http://en.wikipedia.org/wiki/ThingLab 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 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...
- gamache 12y ago
  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.

AnimalMuppet 12y ago

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.

cbsmith 12y ago
> 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.
- AnimalMuppet 12y ago
  > 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.

jimbokun 12y ago

Dependency management. Source code control. Continuous integration. Deployment. 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?

fstephany 12y ago
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/ 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/ 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).
lispm 12y ago
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'.
- hga 12y ago
  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. Or so I remember as of the early '80s.

todd8 12y ago

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?

horrido 12y ago
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.
horrido 12y ago
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 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.

MichaelCrawford 12y ago

hey I know smalltalk. I'm really good at it and I like it. Does this mean I can get a job now, despite having learned the language in 1996?