[Cuis-dev] Language constructs

Fri May 1 01:18:41 PDT 2020

I haven’t used backticks, because in the cases that I could have used them
the performance gain was negligible, and I’m constantly refactoring and
changing everything so I was afraid that they might introduce weird bugs
(because old instances could linger inside compiled methods).

Maybe I could live without #(), I don’t use it that much. I’m not sure it
is important for the base system, tho. Same goes for $. However, symbol
literals are important, and I can’t imagine coding without literals for
numbers and strings, it is possible but must be very annoying.

I like {} and use it often. It is relatively new, I used to code without
it, and at the beginning I didn’t like it but ended up getting used to it.
It does make code more readable.

On Fri, 1 May 2020 at 2:46 PM, Erik Stel via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Maybe I wasn’t clear (because it was part of another topic, see below) or
> tread on a sensitive subject, but I’m still eager to hear the reasoning for
> having backticks (which are not in Squeak nor Pharo) from the simplicity
> point of view. Would anyone care to elaborate?
>
> I am also eager to know what others think about language constructs such
> as #(), {} and `` for daily usage. And I mean this in the sense ‘Do you use
> these often? Could you live without them?’. I do understand how they can be
> used and what their meaning is ;-). And I can also lookup their current use
> in the default image, but that does not answer how you/we use them in our
> (application) code.
>
> Kind regards,
> Erik
>
> Hi Juan, others,
>
> Chewing on this a bit today, I have to admit I am not a big fan of the
> backticks nor adding extra globals. So although I started with a question
> that led to this thread I vote for keeping it as it is: without namespaces.
> :-)
>
> In my opinion, the backticks add additional complexity which is not
> needed. Literals for Numbers, Characters and Strings is a necessity (how
> would you otherwise create instances for these classes). Writing literals
> for Points, Arrays, etc is perfectly doable with regular Smalltalk
> expressions. And having to remember that a literal is created at compile
> time instead of runtime is not something that feels really dynamic as in
> ’the Smalltalk way’. What would happen if I change the implementation of
> Point>>#@? Will all code be recompiled which uses the literal `0 @ 0`? If
> we expect backticks to create literals at compile time, I’m not even sure I
> know what the (correct) answer should be. The performance gain is not
> something I’m interested in. We can create (lazy initialised or not)
> variables to hold instances which require more elaborate instantiation
> logic or for often used ‘values’ like [Point zero] (example, this does not
> exist).
>
> Only recently have I began to use [{ #first . #second . #third }], to be
> compatible with other code. And sure it is much more compact than [(Array
> new: 3) at: 1 put: #first ; at: 2 put: #second ; at: 3 put: #third ;
> yourself], but the later is very clear in what it does. I hardly ever use
> [#(first second third)] because it is (in my opinion) at first sight
> unclear what first, second and third are. You could use [#(first #second
> third)] or [#(#first #second #third)] which all have the same effect, but
> look different. Confusing I think (and I say this as a long time
> developer). I’m working on a project to create a development environment
> for kids (based on Smalltalk and preferably Cuis), I’m not sure I want to
> have to explain these things.
>
> I like Cuis’ simplicity, but I am unsure whether backticks (nor the other
> literal constructions {} and #()) are helping here. If any I would keep {}
> and remove the rest. So to come back to my earlier remark: I think I prefer
> Cuis without namespaces to not add complexity. And not prefixing class
> names fits fine in the simplicity corner.
>
> Eager to hear other opinions and hear the reasoning which led to the
> current literal constructions.
>
> My 2 eurocents.
>
> Kind regards,
> Erik
>
>
> On 28 Apr 2020, at 16:00, cuis-dev-request at lists.cuis.st wrote:
>
> *From: *Juan Vuletich <juan at jvuletich.org>
> *Subject: **Re: [Cuis-dev] Naming conventions*
> *Date: *28 April 2020 at 15:52:08 CEST
> *To: *Luciano Notarfrancesco <luchiano at gmail.com>, Discussion of Cuis
> Smalltalk <cuis-dev at lists.cuis.st>
>
>
> On 4/28/2020 1:16 AM, Luciano Notarfrancesco wrote:
>
> Sounds great! But the convention
>    `PackageName1@#ClassName` new
> looks a bit ugly to me, how about using upper case messages via the DNU
> mechanism? Say, a package PackageName1 is already a global in the Smalltalk
> system dictionary, then you can do send ClassName as a message to it:
>    PackageName1 ClassName new
>
>
> Yes, this is cleaner.
>
> And regarding the back ticks, normally the compiled methods would have a
> reference to the association, but if you resolve it to a class at compile
> time and a class is replaced by a new one in the package, the compiled
> method outside would keep the reference to the old class.
>
>
> Without backticks, we'd need to add packages as globals, so they can be
> resolved at runtime. With the backticks we can avoid that, because we can
> give the Compiler the context to resolve package names if in a required
> package, just like class names, at compile time.
>
> Additionally, using DNU instead of #@ has a significant performance
> penalty. I would only use DNU if in backticks, so there is no additional
> cost in every method run.
>
> WRT the class being recreated, yes, we need track and recompile
> references. Not a big deal.
>
> So, I think there are three alternatives:
>
> a)  `PackageName1@#ClassName` new         #@ message send, package name
> is required, no global needed. Evaluated at compile time.
> b)  (PackageName1@#ClassName) new         #@ message send. Package name
> is a global. Evaluated at method run time.
> c)   `PackageName1 ClassName` new             DNU mechanism. Backticks
> used for performance. No global needed.
>
> I think I prefer option c). It looks clean, has no performance penalty,
> and doesn't need additional globals.
>
> Thanks,
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> https://github.com/jvuletich
> https://www.linkedin.com/in/juan-vuletich-75611b3
> @JuanVuletich
>
>
>
>
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
>
>
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20200501/692bbabc/attachment-0001.htm>