Hi Christoph,

On Mon, Feb 7, 2022 at 3:05 PM <christoph.thiede at student.hpi.uni-potsdam.de>
wrote:

> 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.
>

Agreed.  It *is* interesting.  One of the things I've found in working on
Smalltalk and on the VM in Smalltalk is that avoiding conditionals by using
polymorphism is great, a very powerful style, but one that works at a
granularity of class hierarchies, and is not one that works, for example,
on bit level twiddling.  So in the VM there are points where the caseOf:
statement is very important, and useful (and the same goes for
ifTrue:/ifFalse:).  I also find that it takes time to evolve a beautiful
polymorphic solution and sometimes we are in a position where there is code
to be written quickly, and its quality is of less importance than its
timeliness.  When we're lucky we get to revisit and replace the old crud
with nicer, better designed code.  But I do know that not all code is able
to be so reduced to a beautiful minimum, and that caseOf: &
ifTrue:/ifFalse: have their place, and hence that ifTrue:/ifFalse:'s
static frequency argues strongly for the keyboard shortcuts.

> 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.
>

OK.

> 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. :-)
>

I don't find it a straw man.

>
> > 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 ... :-)
>

Well, I think there's a lot of work still remaining to do with completion.
I find completion great only some of the time.  I find myself fighting the
completion tool a lot when I'm done and want to exit from selecting a
completion and return to normal typing.  Is it better that, for example, up
or down arrow would cause one to exit completion if doing up-arrow on the
first completion or down arrow on the last, or that one is trapped within
the completion menu and has to type escape to leave it?  Would a right
arrow be a good escape choice?  I think we shoudl be video taping people's
editing sessions and analysing it to do a better job because my
relationship with completion verges on love/hate :-)


> Best,
> Christoph
>
> ---
> *Sent from **Squeak Inbox Talk
> <https://github.com/hpi-swa-lab/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
> >
> >
> >
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220207/bc287a0b/attachment.html>