+100. Smalltalk for me is a hobby which comes after the music (guitar and keyboards) and gun habits. I used to code in Smalltalk professionally, but haven’t had a paid job in 26 years. I used to produce code for Squeak back in the early 2000’s, but stopped because my code never made it into the image that I know of. I just code for myself now.
/————————————————————/ For encrypted mail use jgpfers...@protonmail.com Get a free account at ProtonMail.com Web: www.objectnets.net and www.objectnets.org > On Sep 3, 2019, at 04:39, Richard O'Keefe <rao...@gmail.com> wrote: > > Ad 1. > To cut a long story short, > the ANSI Smalltalk standard is the nearest thing we have to a clear > specification > of the nearest thing we have to a consensus. > One of the reasons that Smalltalk gets less use than many of us would like > is that it can be extremely unpleasant trying to port from one dialect of > Smalltalk to another, so you have to commit to a dialect. > And dialects of Smalltalk have an unpleasant habit of disappearing. > I really liked Ambrai. What was I to do with my Ambrai code when > Ambrai disappeared? > I have never met a better-looking Smalltalk than Dolphin. > ObjectArts stopped selling Dolphin a year or two ago, and open sourced it. > Today the ObjectArts website has an expired certificate, > pages have the date 2016 on them, > and the GitHub link points to a GitHub site containing an Amber fork > but no Dolphin. > Imagine my relief at discovering that Dolphin *is* still being maintained, > it's just not where ObjectArts said it was. But I am worried about > whether I should bother with it any more. > Then there's ST/X. > ... > > Code written for C99 is still useful. > I have four different C compilers and I don't have to care which one I use. > > Code written for Fortran95 is still useful (and yes I know about Fortran > 2018). > I have two different Fortran compilers; the one that does the best job > handles > Fortran 2003 but not 2008 or 2018, and as long as I stick to 2003 I don't > have > to care which I use. > > The Common Lisp standard came out in 1994 and the HyperSpec is still useful > to me for writing Lisp today. > My copy of Common Lisp the Language, 2nd edition, is still useful to me. > > Ad 2. > In the Pharo 7.0 sources there are on the order of 600 senders of > #signal[:] > -- exceptions and semaphores both use #signal so this is approximate -- > and on the order of 1000 senders of #error:, which really should be > exceptions. (It is surprisingly hard to make this change.) The newer > components use exceptions a lot more than the old ones. > Of course some exceptions (like subscript out of bounds) are raised > inside primitives, which Ctrl-N doesn't show you. > > One quite strange thing about the ANSI Smalltalk standard is that it > introduced an elaborate exception-handling system into the language > -- much more complicated than C++ or Java or Ada -- but introduced > almost no standard exceptions that a portable program could catch. > Let's take one consequence of this. > What does > (OrderedCollection withAll: #[3 1 4 1 5 9]) copyFrom: 2.5 to: 4.2 > do? > My Smalltalk: currently reports 'bad start' coming from the call to > #copyFrom:to: with culprit 2.5. > This is going to be an IndexError some day; cleaning > up the code to use well-chosen exceptions is a mammoth task. > > Squeak: 'Array called #basicNew: with invalid argument 2.7' > Of course there is no 2.7 in our code... > > Pharo: 'PrimitiveFailed: primitive #basicNew: in Array class failed' > > VW: 'Unhandled exception: This message needs a positive integer argument' > appearing to come from OrderedCollection>>new: > > VisualAge Smalltalk: drops you into a debugger with no actual explanation; > the only number in sight is 2.7, which is not one of the numbers we > provided. > > GNU Smalltalk: 'Object: 1 error: The program attempted to divide a number > by zero'. > I kid you not. > > Exceptions could be useful IF you knew what to catch. > > Just for grins, sending #copyFrom:to: to an OrderedCollection with a start > or stop value out of range raises an ExCLDTIndexOutOfRange exception but > sending it to an Array with the same contents does not. > > Ad 3. > allButFirst: n ^self copyFrom: n+1 to: self size > and then ask what #copyFrom:to: should do. > > This is actually one tiny symptom of a pervasive issue in Smalltalk. > When commercial Smalltalks are riddled with not-quite-working and/or > not-self-consistent stuff in basic classes, what can we expect from > an open source project, unless someone is prepared to donate serious > money for a cleanup? > > >> On Tue, 3 Sep 2019 at 04:01, Kasper Østerbye <kasper.oster...@gmail.com> >> wrote: >> This is actually an intersting discussion. There are several levels to it. >> >> 1. Should Pharo be compatible with a standard from 1998? >> 2. What is the general view on using exceptions in Pharo? >> 3. What should allButFirst: do? >> >> Ad 1) I am relatively new to Pharo, If backwards compatibility is important, >> it should adhere to the standard and the spirit of the standard. If we want >> a different semantics in some areas, it seems like new methods are needed, >> with names which is not confused with existing standard. >> >> Ad 2) I am so new to Pharo I do not even know how efficient (or expensive) >> exceptions are in Pharo. In most programming languages they are expensive, >> and should not be used as an alternative to an if statement. My views on >> exceptions are very influenced by Bertrand Meyer, which lead me to the view >> that a) Asking for the all but the first three elements of a two element >> array is most likely a broken pre-condition. Hence an error. b) As it is the >> clients responsibility to ensure precondition, we might as well help the >> client of the collection by offering an other method with a different >> pre-condition. >> >> Ad 3. Should follow from the first two :-) >> >> Best, >> >> Kasper