Why it's clear Squeak is never going to be the Dynabook (was: The Trunk: Chronology-Core-eem.61.mcz)
Locked
Why it's clear Squeak is never going to be the Dynabook (was: The Trunk: Chronology-Core-eem.61.mcz)
 
|
I have to get this off my chest. Is anyone proud of this smorgasbord of various clock values available in our, uh, "API". Time class>>#eventMillisecondClock Time class>>#highResClock Time class>>#localMicrosecondClockPrimitive Time class>>#localMicrosecondClockWithOffset Time class>>#millisecondClockValue Time class>>#posixMicrosecondClockWithOffset Time class>>#posixMicrosecondClockWithOffset: Time class>>#primPosixMicrosecondClockWithOffset Time class>>#primPosixMicrosecondClockWithOffset: Time class>>#totalSeconds Time class>>#utcMicrosecondClock DateAndTime class>>#millisecondClockValue (same as Time class>>#millisecondClockValue) DateAndTime class>>#totalSeconds (same as Time class>>#totalSeconds) It's already embarrassing to present to a new Smalltalk-80 user, but it can actually add injury [2] to unsuspecting users who were trusting enough to think that Squeak's API is a deliberate, crafted API. For all its technical capability and verbosity, there's still no elegant way for a Smalltalk-80 user to simply, and efficiently, access the underlying microsecond precision of the VM for use in the object environment. Nothing we have for this is user-friendly in the slightest. Last April I submitted a minor improvement to this situation to the Inbox[1]. A completely beautiful and elegant, Smalltalk-80'ish addition of just two methods, #asMicroseconds and #fromMicroseconds: for users to have as a high-res complement to #asSeconds and #fromSeconds:, with comments that were written to and for the user audience, and not the VM-developer audience. Sadly, but not really surprisingly, such user catering was handily rejected. I couldn't even finish addressing the first protester's "alternative suggestions" -- none of which acknowledged my core requirement (above) -- before someone else jumped in with their own "-1" on these grounds: "There is no need to add to the API. You already have Smalltalk seconds at any level of precision care to use." He was talking about requiring the user to introduce inefficient Fractions and/or ScaledDecimals into their domain, despite my having already explained the requirement not to create unnecessary garbage or complexity. Mind-bogglingly, this was from the same person who revamped and distilled the whole of Chronology's DateAndTime down to the efficiency of just two scalar values. So, to this day, in spite of its sprawling family methods, Squeak's class library, still, remains inadequate and needlessly stunted. Power available in the VM untapped, efficiency of the design, thwarted. Over the following weeks[3[4] I submitted multiple alternatives based on the feedback (all accommodating degradations that, again, failed to recognize the core requirement (argh!)), such as, only eliminating the vicious trap. But, after countless hours having addressed every random concern you could never imagine, my final submission[4] was basically left to die on the doorstep, with nothing more than a rude comment from someone who never really participated in the discussion at all. It was after this episode that I more or less stopped participating in trunk development. ________ Fast-forward to today. Three days have passed since Eliot popped these two new, but duplicate, methods right into the trunk. No discussion. Code so fresh, not even the spell-checker had finished. Two useless methods with comments addressed to a VM developer audience. Already a "+1," (post trunk, lol) from a fellow VM-developer, and none of the former objections leveled against my submissions seem important anymore, I guess. But, users are still out in the cold. Trygve was right. - Chris (DateAndTime utcMicroseconds: Time utcMicrosecondClock offset: 0) "looks reasonable, but it's VERY NOT!" On Tue, Oct 6, 2020 at 12:19 AM <[hidden email]> wrote: Eliot Miranda uploaded a new version of Chronology-Core to project The Trunk: |
Re: Why it's clear Squeak is never going to be the Dynabook (was: The Trunk: Chronology-Core-eem.61.mcz)
|
Hi Chris!
The Cuis-Smalltalk API seems to be simpler, although I can't tell about its quality. https://cuis-smalltalk.github.io/#/Kernel-Chronology I will be curious to read your opinion about it. Hilaire Le 09/10/2020 à 09:00, Chris Muller a écrit : > I have to get this off my chest. Is anyone proud of this smorgasbord > of various clock values available in our, uh, "API". > -- Dr. Geo http://drgeo.eu https://pouet.chapril.org/@hilaire |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |