[squeak-dev] The role of #ifTrue:/#ifFalse: (was: Merge Request: autoEncloseBeforeSpace.cs)

christoph.thiede at student.hpi.uni-potsdam.de christoph.thiede at student.hpi.uni-potsdam.de
Fri Feb 25 16:06:30 UTC 2022


Hi Eliot,

Nothing more to add. Of course, conditionals have their place and n-ary dispatch is not always the most elegant solution. :-)

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

Yes, this is also an interesting construction site. I'm assuming you are using oCompletion? Personally, I'm often using the Autocompletion fork <https://github.com/LeonMatthes/Autocompletion> which does not only have nice contextual and type-guessed suggestions but also some changes to the keyboard handling iirc. However, most of the time I'm not noticing at all when I am using Autocompletion, which speaks for the intuitivity of the keyboard shortcuts. If you did not try it out yet, you also might want to check Sandblocks <https://github.com/hpi-swa/sandblocks> with a refreshingly new approach on typing. :-)

Happy Squeaking,
Christoph

---
Sent from Squeak Inbox Talk

On 2022-02-07T17:01:13-08:00, eliot.miranda at gmail.com wrote:

> 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>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220225/7fd170da/attachment-0001.html>


More information about the Squeak-dev mailing list