GNU Smalltalk Koans(skim.la)
skim.la
GNU Smalltalk Koans
http://skim.la/gnu_smalltalk_koans/
30 comments
The grey text on white is unreadable. Which is a shame as I genuinely wanted to read it.
As a young designer I redesigned a major news site with a lighter gray text on white.
I looked great to me - perfect and very readable. But I didn't consider the older eye, or other eyes, which don't let in as much light.
Hopefully the author will learn and adjust. Contrast is good.
I looked great to me - perfect and very readable. But I didn't consider the older eye, or other eyes, which don't let in as much light.
Hopefully the author will learn and adjust. Contrast is good.
Not just eyes, shit computer and phone screens. The worst screens have half the colors and a quarter the brightness (and relative contrast) of the best.
Yup.
A lesson for the designers among us: almost no-one is viewing your site on your 5k iMac screen. Design accordingly
A lesson for the designers among us: almost no-one is viewing your site on your 5k iMac screen. Design accordingly
I'm actually having trouble with the contrast as well.
But I don't think the colours them selves are absolutely unusable together, I think the combination of the colours and the font weight/size is really the issue (although that could be less the case on a retina screen).
It also doesn't help that I'm viewing it on a older monitor with poor colour control (particularly with contrast).
But I don't think the colours them selves are absolutely unusable together, I think the combination of the colours and the font weight/size is really the issue (although that could be less the case on a retina screen).
It also doesn't help that I'm viewing it on a older monitor with poor colour control (particularly with contrast).
Light grey on white is readable on my work macbook pro, but unreadable on my old x201. It really depends on the display.
All of the content is also in the github readme: https://github.com/sl4m/gnu_smalltalk_koans
The "Reader View" available in at least Firefox and Safari fixed this for me.
Reader view is such an invaluable feature for me.
The icon sometimes doesn't appear in the address bar though (apparently because Firefox is unable to identify where the text content is in the page.)
I've also found the extension - Open in Reader View [1] to be useful for those situations.
[1] http://firefox.add0n.com/reader-view.html - Firefox, Chrome and Opera
The icon sometimes doesn't appear in the address bar though (apparently because Firefox is unable to identify where the text content is in the page.)
I've also found the extension - Open in Reader View [1] to be useful for those situations.
[1] http://firefox.add0n.com/reader-view.html - Firefox, Chrome and Opera
High Contrast is another option for chrome that changes only the text and/or background colors.
https://chrome.google.com/webstore/detail/high-contrast/djcf...
https://chrome.google.com/webstore/detail/high-contrast/djcf...
[deleted]
If only there were any technology available to you, a software developer, that could render that text in a different color. Alas, your genuine desire to read it must go unfulfilled.
There is so much written in 2017, the least the author can do is make it readable if they actually want people to read it.
Smalltalk is very efficient according to function point analysis that is how many rows of code you need to produce code.
http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm
http://www.cs.bsu.edu/homepages/dmz/cs697/langtbl.htm
I mistrust a list that rates C++ as more concise than Common Lisp (in which one can create domain-specific languages), and Visual C++ as somehow 50% more concise than both.
This study is more than twenty years old. Smalltalk would score very low compared to today's languages.
Function points are a pretty useless metric anyway.
Function points are a pretty useless metric anyway.
>Smalltalk would score very low compared to today's languages.
Citation needed. Why would it "score very low compared to today's languages"? At best "today's languages" caught up with some things Smalltalk offered, but they still don't have the base model so succint and flexible, so it's just piles of sugar on top of algol.
Citation needed. Why would it "score very low compared to today's languages"? At best "today's languages" caught up with some things Smalltalk offered, but they still don't have the base model so succint and flexible, so it's just piles of sugar on top of algol.
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.
I should probably do the "profStef" tutorial.
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.
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.
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.
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.
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.
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.
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.
I just installed GNU Smalltalk to try it.
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.
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.
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]
These koans are terminal-based coding examples.
That's what I was saying. Although I adore the terminal, I'm not sure if it's the right approach for Smalltalk.
This reminded me of a tool that my college professor created many years ago called The World of the Actors [1]. He used in his class to teach Smalltalk and OOP.
I can't seem to be able to find the source, though.
[1] https://pdfs.semanticscholar.org/4fb7/5b3cb8ef7adb36c0871931...