Hi Eliot,

I was not sure whether we should continue this debate, because I believe that we are actually not disagreeing but just talking about different things. :-) Anyway, it is an interesting debate and I thank you for your insightful comparison of different language models for choice.

So in general, I was talking about an abstract/conceptual/a priori argument about the pure syntax only where all selectors are equal. I claim that you could *describe* an algebra or a state machine in Smalltalk without using conditional selectors. #ifTrue:/#ifFalse: is common but not without alternatives. As stated before, I did not request to change the existing behavior.

On the other hand, you are talking about statistics and numbers, and I agree with you that #ifTrue:/#ifFalse: are definitively under the top five (how could I deny it...). Actually, in my image, #at: is used more frequently than #ifFalse: (#(ifTrue: 4.56 at: 3.16 ifFalse: 2.7 = 2.33 assert: 1.93)). So consequently, we would also have to talk about mapping Cmd + Shift + A to #at:, since I do think that dynamic state accesses are a general property of programming languages just like explicit conditional choice. Please pardon me if this is an uninteded straw man, in this case I'm interested about learning the difference between those two fundamental properties. :-)

> Personal preference is no argument for changing the behaviour of a community-developed programming system, is it?

You're right. :-) Neither we should break a harmless feature that many people are used to (again: I never requested this...), nor we should ignore statistical evidence when publishing a new tool. I guess I was rather having the idea of a minimum complete tool in mind which is intrinsic to Smalltalk, and which would not require any shortcuts at all. Just treat it as a small thought experiment ... :-)

Best,
Christoph

---
Sent from Squeak Inbox Talk

On 2021-12-26T12:26:19-08:00, eliot.miranda at gmail.com wrote:

> Hi Christoph,
> 
> On Sun, Dec 26, 2021 at 6:52 AM <christoph.thiede at student.hpi.uni-potsdam.de>
> wrote:
> 
> > Hi all,
> >
> >
> >
> > *Ad discussion theme #1: *
> > > If you really want to mess around with this kind of thing I'd suggest
> > making a proper config tool that let's you configure every available key
> > and meta combination, with saveable mappings attached to the prefs so you
> > can have whatever you personally want.
> >
> > Sure, why not? But definitely not before the release. :D
> >
> > > That's why I would vote for showing off all the bells and whistles by
> > default, and make it easy to disable them if they are annoying.
> >
> > +1
> >
> > > "Did you find that useful? If not you can disable it in the preferences
> > _here_ ..."
> >
> > +1, but only if it can be turned off, and only after the release, of
> > course. :D
> >
> >
> >
> > *Ad discussion theme #2: *
> > > Just a remark: out of the box, Cmd-[ is not accessible on a German
> > Windows-type quertz keyboard because we have to use Alt Gr (which is
> > equivalent to Ctrl+Alt) + 8 to type [ in the first place, so all modifiers
> > that could possibly map to Cmd are already held down. Same issue with curly
> > braces.
> >
> > Just to note what I have already written to Jakob in private: Even when
> > switching my keyboard layout from Qwertz to Qwerty, I was not able to make
> > use of Ctrl-[ or Alt+[ (Win32, VM 202112201228). Is this feature only
> > available on Linux/macOS?
> >
> >
> >
> > *Ad discussion theme #3: *
> > > General purpose, programmable, mumble, see above. It seems as if you are
> > making the mistake of assuming there can only be one editor setup.
> > Currently in Squeak we do rather do that, with the editors for pretty much
> > all text-things being the same with the same menu even when inappropriate.
> > We should do better.
> >
> > +1. We already have #pluggableTextSpec vs #pluggableCodePaneSpec but
> > something like a #contentType flag would not harm, too. :-)
> >
> > > > I did *not* request to remove this shortcut because I understand that
> > some long-standing Squeakers might have gotten used to it. My argument was
> > only not to cement this kind of "leaky abstractions". IMHO the editor
> > should be a tool that is suitable for all applications or domains in the
> > same way, without putting advantages or disadvantages to certain domains.
> > >
> > > But the editor is explicitly divided into a domain-independent
> > TextEditor and a domain-specific SmalltalkEditor anyway. So your objection
> > is not relevant. We?re discussing (I hope) the accelerator keys for the
> > SmalltalkEditor.
> >
> > IMO this should rather be part of a separate subclass of SmalltalkEditor:
> >
> > Editor: Minimal tool for editing strings (e.g., backspace).
> > TextEditor: Tool for editing formatted strings (e.g., adding/removing
> > attributes).
> > SmalltalkEditor: Tool for editing Smalltalk code (e.g., <opt>1 for adding
> > method parameters).
> > ControlFlowStyleSmalltalkEditor: Tool for editing Smalltalk code in the
> > style of low-level control-flow operations such as #whileTrue,
> > #ifTrue:/#ifFalse:, etc.
> >
> > > > A developer working in another domain (that abstracts from
> > booleans/for instance, a query DSL) will be less likely interested in
> > special shortcuts for ifTrue:/ifFalse: but more likely interested in
> > shortcuts for message sends such as #collect:, #select:, etc. I only wanted
> > to present this perspective before we start occupying even more shortcuts
> > for randomly chosen selectors that might be of increased importance for a
> > subset of users of the Smalltalk workspace.
> > >
> > > ifTrue:/ifFalse: are hardly randomly selected selectors, now are they?
> >
> > They don't play a special role in the Smalltalk syntax, do they? Booleans
> > are just objects like Collections or Morphs. #ifTrue: is just a selector
> > like #select: or #openInWorld. They are only handled differently by the
> > VM/interpreter for the sake of optimization (value types, inlined special
> > selectors, ...). But conceptually, they are nothing special in our
> > beautifully minimal Smalltalk grammar. They do not need to be mentioned on
> > the Smalltalk Postcard.
> >
> > Statistically, you are right of course that #ifTrue: might be one of the
> > most popular selectors in most Smalltalk programs. But that is not an
> > intrinsic property of Smalltalk [...]
> 
> 
> but it is.  In fact, it is a general property of programming languages.
> Choice is intrinsic in general purpose programming (less so in stream
> oriented programming), so much so that it is available in many
> different forms.  Smalltalk provides polymorphic dispatch and closures,
> from which we derive ifTrue:ifFalse: et al.  In functional languages one
> sees pattern matching.  In machine languages one sees conditional jumps and
> conditional skips.  In fact it is definitional that interesting programs
> involve choice.  Even the Mandelbrot set depends on choice: the typical
> implementation is to ask how many iterations of [image: {\displaystyle
> f_{c}(z)=z^{2}+c}] does it take for z to converge or diverge to infinity.
> 
> So you can rail against ifTrue:/ifFalse: but you are pissing in the rain.
> 
> Now let's have a look at the numbers.  One might think one could could
> keywords using:
> 
>     | keywordCounts |
>     keywordCounts *:=* Bag new.
>     CurrentReadOnlySourceFiles cacheDuring:
>         [self systemNavigation allSelect:
>             [:cm|
>             cm selectorsDo:
>                 [:s|
>                 s isKeyword
>                     ifTrue: [keywordCounts addAll: s keywords]
>                     ifFalse: [keywordCounts add: s]].
>             false]].
>     keywordCounts sortedCounts
> 
> but of course this doesn't count inlined messages.  So we have to
> decompile; amd let's generate a report in percentage terms:
> 
>     | keywordCounts keywordCount |
>     keywordCounts *:=* Bag new.
>     CurrentReadOnlySourceFiles cacheDuring:
>         [self systemNavigation allSelect:
>             [:cm|
>             cm methodNode nodesDo:
>                 [:n|
>                 n isMessageNode ifTrue:
>                     [n selector key isKeyword
>                         ifTrue: [keywordCounts addAll: n selector key
> keywords]
>                         ifFalse: [keywordCounts add: n selector key]]].
>             false]].
>     keywordCount *:=* keywordCounts size.
>     String streamContents:
>         [:s|
>         (keywordCounts sortedCounts first: 100) do:
>             [:assoc|
>             s nextPutAll: assoc value; space; print: assoc key * 100.0 /
> keywordCount maxDecimalPlaces: 2; cr]]].
> 
> #(ifTrue: 5.31
> ifFalse: 3.13
> = 2.65
> at: 2.5
> + 2.36
> assert: 1.98
> == 1.82
> new: 1.57
> to: 1.41
> , 1.41
> - 1.35
> do: 1.32...
> 
> So ifTrue: and ifFalse: are more popular than the next three combined,
> almost the next four.  ifTrue: is twice as likely as the third (=).  And
> lest you think this is my style, the percentages in a VMMaker image are
> slightly less: ifTrue: 5.24%, ifFalse: 3.05%.
> 
> [...] and personally I dislike the idea of coupling statistic insights
> > about API usage to globally predefined shortcuts in the default Trunk
> > image. It is possible to write Smalltalk programs that use alternative APIs
> > (the Collection API would just be one example) that never make use of the
> > Boolean protocol.
> >
> 
> Personal preference is no argument for changing the behaviour of a
> community-developed programming system, is it?
> 
> 
> >
> > Best,
> > Christoph
> >
> > ---
> > *Sent from **Squeak Inbox Talk
> > <https://github.com/hpi-swa-lab/squeak-inbox-talk>*
> >
> > On 2021-12-25T16:03:32+01:00, marcel.taeumel at hpi.de wrote:
> >
> > > Hi all --
> > >
> > > Done. See Morphic-mt.1829. cmd+[ etc. is back if you enable the "legacy
> > shortcuts" preference.
> > >
> > > Best,
> > > Marcel
> > > Am 25.12.2021 12:47:15 schrieb Marcel Taeumel <marcel.taeumel at hpi.de
> > >:
> > > Hi all --
> > >
> > > I am currently collecting the US-specific TextEditor shortcuts that got
> > lost since Squeak 5.3 to make them available again as a preference-driven
> > event filter on instances of TextEditor. Shouldn't be that hard. I will
> > call the preference "Legacy keyboard shortcuts (US only)" or something like
> > that.
> > >
> > > You can help me do that by answering here:
> > >
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217783.html
> > [
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217783.html
> > ]
> > >
> > >
> > > Thanks. :-)
> > >
> > > Best,
> > > Marcel
> > > Am 23.12.2021 21:09:53 schrieb tim Rowledge <tim at rowledge.org>:
> > >
> > >
> > > > On 2021-12-23, at 4:39 AM, Jakob Reschke wrote:
> > > >
> > > > I believe that because Squeak does not have a
> > > > reputation of being a state of the art, customizable code editor, as
> > > > far as I am aware. (Admittedly, no hard facts in this paragraph.)
> > >
> > > Which is kind of sad because of course all the code is right there and
> > is almost infinitely customizable. :-(
> > >
> > > tim
> > > --
> > > tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> > > Eagles may soar, but weasels aren't sucked into jet engines.
> > >
> > >
> > >
> > > -------------- next part --------------
> > > An HTML attachment was scrubbed...
> > > URL: <
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211225/321ca36f/attachment.html
> > >
> > >
> > >
> >
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211226/d4a38d48/attachment-0001.html>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220208/6c0f4fef/attachment.html>