5 ms·

I did smalltalk professionally as my second job out of college, 1995-1997. It was cool learning it, and it definitely gets you into OOP. It also laid the ground

I did smalltalk professionally as my second job out of college, 1995-1997. It was cool learning it, and it definitely gets you into OOP. It also laid the groundwork for realizing that OOP isn't a great paradigm for software development. Plus it was really slow and clunky, in the end. For the time, the IDE (VisualAge and the other one I can't remember) was cool, although git crushes the model they used back then. Overall, I'm glad I learned it, much like TCL and Lisp, but I'm definitely glad I don't use it professionally. The languages basically take their premise to the extreme, where the premise for each is "What if everything, including the language itself, was ..." TCL: ...a string? Lisp: ...a list? Smalltalk: ...an object? I don't know enough about it, but I think with Haskell the suffix would be "...a function?" Neat experiments, neat learning them, but I appreciate other languages more for actually implementing large projects.

vindarel 5y ago
not to mis-interpret this comment: Lisp has of course other data structures, hash tables and all. The source code though can be seen as a list of lists, and it can be manipulated as is in macros (but you can use an AST too).
jimbokun 5y ago
For Haskell, maybe it's: "What if everything was immutable?" Which I guess doesn't really include the language itself. But it seems more fundamental to Haskell than first class functions, which exist in many other popular languages.
ljm 5y ago
I feel like Smalltalk demonstrated a better version of OOP than what you get in other languages that market themselves as object oriented. Firstly that it's consistent with itself, but mainly because it's incredibly awkward to do OOP in the Gang of Four/Clean Code/DDD style that you'd typically see in, say, a Java project. You're essentially building up a catalogue of messages and answers and so it's not particularly ergonomic to jump through several layers of abstraction in the browser to get what you need. And there's no arbitrary limitation on your code such that a class can only have 10 methods in it, or 100 lines, or some other silly thing that forces you into creating a more convoluted architecture with more indirection. I've grown weary of OOP for a long time because of how hard it is to find an effective application of it that doesn't grow into a collection of explicit design patterns with some business logic buried in the depths of the hierarchy. My brief experience with Smalltalk essentially revived my interest in it and encouraged me to be more thoughtful about my approach without throwing it all out and pining for a purer, more functional language that trades OOP's big problems with a set of its own.
- gilbetron 5y ago
  Things that are good from OOP/Smalltalk: * Interfaces * Messages * Some combining of data and functions * Some polymorphism Not so good: * Inheritance * Open/close * Most Encapsulation * Most everything else ;)
- feoren 5y ago
  > And there's no arbitrary limitation on your code such that a class can only have 10 methods in it, or 100 lines, or some other silly thing that forces you into creating a more convoluted architecture with more indirection. I've never heard of such a restriction, even in very early programming languages. What language are you thinking of where you're limited to a specific number of methods or lines per class?
  - Jtsummers 5y ago
    They're making a hyperbolic allusion to texts like Clean Code which promote short methods and relatively small source files (recommendations usually in the low 100s of SLOC). Not to actual language restrictions.
    - ljm 5y ago
      It's not particularly hyperbolic when using, say, Rubocop for Ruby. Those are pretty much the default settings (methods no longer than 5 or 10 lines, classes no longer than 100, etc.). You can change the defaults of course but there is one class of software engineer which will treat those as gospel.
kaba0 5y ago
Smalltalk shows a very opinionated type of OOP, which has little to do with the commonly accepted form of OOP done in C++ and Java. And I think it is “brave” to claim that the most commonly used and proven paradigm that does scale with complexity is not great for software development.

vindarel 5y ago

not to mis-interpret this comment: Lisp has of course other data structures, hash tables and all. The source code though can be seen as a list of lists, and it can be manipulated as is in macros (but you can use an AST too).

jimbokun 5y ago

For Haskell, maybe it's: "What if everything was immutable?" Which I guess doesn't really include the language itself. But it seems more fundamental to Haskell than first class functions, which exist in many other popular languages.

ljm 5y ago

I feel like Smalltalk demonstrated a better version of OOP than what you get in other languages that market themselves as object oriented. Firstly that it's consistent with itself, but mainly because it's incredibly awkward to do OOP in the Gang of Four/Clean Code/DDD style that you'd typically see in, say, a Java project. You're essentially building up a catalogue of messages and answers and so it's not particularly ergonomic to jump through several layers of abstraction in the browser to get what you need. And there's no arbitrary limitation on your code such that a class can only have 10 methods in it, or 100 lines, or some other silly thing that forces you into creating a more convoluted architecture with more indirection. I've grown weary of OOP for a long time because of how hard it is to find an effective application of it that doesn't grow into a collection of explicit design patterns with some business logic buried in the depths of the hierarchy. My brief experience with Smalltalk essentially revived my interest in it and encouraged me to be more thoughtful about my approach without throwing it all out and pining for a purer, more functional language that trades OOP's big problems with a set of its own.

gilbetron 5y ago
Things that are good from OOP/Smalltalk: * Interfaces * Messages * Some combining of data and functions * Some polymorphism Not so good: * Inheritance * Open/close * Most Encapsulation * Most everything else ;)
feoren 5y ago
> And there's no arbitrary limitation on your code such that a class can only have 10 methods in it, or 100 lines, or some other silly thing that forces you into creating a more convoluted architecture with more indirection. I've never heard of such a restriction, even in very early programming languages. What language are you thinking of where you're limited to a specific number of methods or lines per class?
- Jtsummers 5y ago
  They're making a hyperbolic allusion to texts like Clean Code which promote short methods and relatively small source files (recommendations usually in the low 100s of SLOC). Not to actual language restrictions.
  - ljm 5y ago
    It's not particularly hyperbolic when using, say, Rubocop for Ruby. Those are pretty much the default settings (methods no longer than 5 or 10 lines, classes no longer than 100, etc.). You can change the defaults of course but there is one class of software engineer which will treat those as gospel.

kaba0 5y ago

Smalltalk shows a very opinionated type of OOP, which has little to do with the commonly accepted form of OOP done in C++ and Java. And I think it is “brave” to claim that the most commonly used and proven paradigm that does scale with complexity is not great for software development.