4 ms·

Nice to see some Smalltalk examples although I'm heavily biased to terminal languages like Awk, Perl, and Python, I'd rather see something more like Pharo which

Nice to see some Smalltalk examples although I'm heavily biased to terminal languages like Awk, Perl, and Python, I'd rather see something more like Pharo which I think makes more sense in the ST world. I hear a lot about the joys of ST, but Id like to see some short coding sessions to get the idea. Most demos I see are either "let's look at all the goodies like class inspector, debugger...etc", or "let's look at this example where I can't follow along as we're like 9 classes deep". I should probably do the "profStef" tutorial.

tom_mellior 9y ago
These koans are terminal-based coding examples.
- throwaway7645 9y ago
  That's what I was saying. Although I adore the terminal, I'm not sure if it's the right approach for Smalltalk.
mark_l_watson 9y ago
I agree with you. This is a nice project but deeply interactive programming environments are the heart and soul of Smalltalk programming. Installing Pharo, and as you suggest following the interactive profStef tutorial is a good beginning.
- brudgers 9y ago
  I don't disagree that traditional Smalltalk programming environments offer some significant advantages. For me, they do not come along for free. The price is analogous to if Python could only be written using Vim or JavaScript in Sublime Text or Perl required switching between a driver and navigator every twenty to thirty minutes. In general there is a large degree of orthogonality between editor and language when it comes to ergonomics and cognitive load. GNU Smalltalk has a default environment: Emacs. Online documentation is available. A REPL is available. Is it better? Depends on what the metric is. For me, it is because I only have to learn one thing: the Smalltalk language. I don't have to learn a new workflow right away. I can continue to use org-mode and babel and literate programming. I don't have to use a mouse. I can tile my windows. I can treat Smalltalk like just another programming language and switch between it and Lisp and Python and Ruby and Javascript and HTML and Bash all without a context switch at the editor level...e.g. I can change buffers and update a Smalltalk git repository with the same mechanism I use to update a Python repository. Sure, it is a tradeoff. And if I was working in a different environment, all the features of the Smalltalk IDE might easily be worth the compromises in exchange for their advantages.
  - mark_l_watson 9y ago
    I just installed GNU Smalltalk to try it.
    - brudgers 9y ago
      In a way, I find it a bit like using Ruby but with a more formally consistent design philosophy...as one might expect when a language has a formal specification and a corporate pedigree.
    - bonzini 9y ago
      Former (10 years or so) maintainer here, nice that someone is still using it. Unfortunately, the lack of support for modern web APIs (starting from SSL) makes it a dead end for serious applications. But it is still useful to teach OOP in my opinion, the metaclass model strikes the right balance between simplicity and power; the only improvement to it might be traits, which in fact were first prototyped in Smalltalk.
    - deleted 9y ago
      [deleted]
brudgers 9y ago
One problem GNU Smalltalk addresses for me is "getting started" because it mostly takes tooling out of the equation. Mostly because my experience was of normal install a new programming language and integrate it with my current tools hiccups. But there was not an entire alien landscape filled with many overlapping windows as with Pharo or Squeak. I can focus on learning the language and its semantics without orthogonal cognitive loads. I think this helps me more readily achieve flow. Part of what made a sustained attempt at learning Smalltalk difficult for me was that traditional Smalltalk IDE's did not allow me to approach Smalltalk as just another programming language living in the same Turing tarpit as Awk or Perl or Python. Smalltalk IDE's make a set of design decisions that embody a particular philosophy regarding the "best way to use a computer" rather than "here is another way to use a computer." They are not the best way for me to use one.
- cdegroot 9y ago
  That is, of course, by design. To me (I have been a professional Smalltalk for a while), GNU Smalltalk drops the essence of a traditional Smalltalk environment and while I was "hmm, interesting, maybe if I ever have a use for it I'll look at it", I never needed it. A Smalltalk IDE is an extremely powerful fool, and IMHO the most powerful tool we've invented so far. Having said that - I do think that Pharo and friends maybe should be more friendly to what I as a developer expect today from my tools: mostly keyboard-driven, no overlapping windows, etcetera.
  - brudgers 9y ago
    I think there are two separate design issues. One is the architecture of the Smalltalk development environment in terms of displaying information about classes and objects and lists of related methods and the running system and so on. That's great and and powerful and entirely orthogonal to the WIMP interface and the particulars of the screen presentation.

tom_mellior 9y ago

These koans are terminal-based coding examples.

throwaway7645 9y ago
That's what I was saying. Although I adore the terminal, I'm not sure if it's the right approach for Smalltalk.

mark_l_watson 9y ago

I agree with you. This is a nice project but deeply interactive programming environments are the heart and soul of Smalltalk programming. Installing Pharo, and as you suggest following the interactive profStef tutorial is a good beginning.

brudgers 9y ago
I don't disagree that traditional Smalltalk programming environments offer some significant advantages. For me, they do not come along for free. The price is analogous to if Python could only be written using Vim or JavaScript in Sublime Text or Perl required switching between a driver and navigator every twenty to thirty minutes. In general there is a large degree of orthogonality between editor and language when it comes to ergonomics and cognitive load. GNU Smalltalk has a default environment: Emacs. Online documentation is available. A REPL is available. Is it better? Depends on what the metric is. For me, it is because I only have to learn one thing: the Smalltalk language. I don't have to learn a new workflow right away. I can continue to use org-mode and babel and literate programming. I don't have to use a mouse. I can tile my windows. I can treat Smalltalk like just another programming language and switch between it and Lisp and Python and Ruby and Javascript and HTML and Bash all without a context switch at the editor level...e.g. I can change buffers and update a Smalltalk git repository with the same mechanism I use to update a Python repository. Sure, it is a tradeoff. And if I was working in a different environment, all the features of the Smalltalk IDE might easily be worth the compromises in exchange for their advantages.
- mark_l_watson 9y ago
  I just installed GNU Smalltalk to try it.
  - brudgers 9y ago
    In a way, I find it a bit like using Ruby but with a more formally consistent design philosophy...as one might expect when a language has a formal specification and a corporate pedigree.
  - bonzini 9y ago
    Former (10 years or so) maintainer here, nice that someone is still using it. Unfortunately, the lack of support for modern web APIs (starting from SSL) makes it a dead end for serious applications. But it is still useful to teach OOP in my opinion, the metaclass model strikes the right balance between simplicity and power; the only improvement to it might be traits, which in fact were first prototyped in Smalltalk.
  - deleted 9y ago
    [deleted]

brudgers 9y ago

One problem GNU Smalltalk addresses for me is "getting started" because it mostly takes tooling out of the equation. Mostly because my experience was of normal install a new programming language and integrate it with my current tools hiccups. But there was not an entire alien landscape filled with many overlapping windows as with Pharo or Squeak. I can focus on learning the language and its semantics without orthogonal cognitive loads. I think this helps me more readily achieve flow. Part of what made a sustained attempt at learning Smalltalk difficult for me was that traditional Smalltalk IDE's did not allow me to approach Smalltalk as just another programming language living in the same Turing tarpit as Awk or Perl or Python. Smalltalk IDE's make a set of design decisions that embody a particular philosophy regarding the "best way to use a computer" rather than "here is another way to use a computer." They are not the best way for me to use one.

cdegroot 9y ago
That is, of course, by design. To me (I have been a professional Smalltalk for a while), GNU Smalltalk drops the essence of a traditional Smalltalk environment and while I was "hmm, interesting, maybe if I ever have a use for it I'll look at it", I never needed it. A Smalltalk IDE is an extremely powerful fool, and IMHO the most powerful tool we've invented so far. Having said that - I do think that Pharo and friends maybe should be more friendly to what I as a developer expect today from my tools: mostly keyboard-driven, no overlapping windows, etcetera.
- brudgers 9y ago
  I think there are two separate design issues. One is the architecture of the Smalltalk development environment in terms of displaying information about classes and objects and lists of related methods and the running system and so on. That's great and and powerful and entirely orthogonal to the WIMP interface and the particulars of the screen presentation.