Hi Christoph,
On Mon, Feb 7, 2022 at 3:05 PM christoph.thiede@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@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....
[
http://lists.squeakfoundation.org/pipermail/squeak-dev/2021-December/217783....
]
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.