[Glass] [Pharo-users] [squeak-dev] Falsehoods programmers believe about Smalltalk

Tue Jan 29 16:38:52 PST 2019

Thank you for your notes Richard, it's really interesting to see not so
well-known projects.
I would love to have more people sharing their wisdom and knocking down
more myths.

Cheers,

Hernán

El dom., 27 ene. 2019 a las 1:17, Richard O'Keefe via Glass (<
glass at lists.gemtalksystems.com>) escribió:

> I have my own Smalltalk system implemented as a batch compiler via C.
> This was originally just going to be a baseline for a student wanting
> to work on JIT, but he went elsewhere and I found the system surprisingly
> useful.  I also wanted something that hewed closely to the ANSI Smalltalk
> standard, but could diverge in other matters (like not having dynamic code
> modification).
>
> - All Smalltalk bytecode sets are stack-based VM. (?)
>
> My system has no bytecodes.  Smalltalk=>C=>native code.
>
> - Bytecodes are always fixed-size. (?)
>
> False back in the Blue Book.  Why does it matter anyway?
>
> - Most of the time spent by a VM is in the instruction interpreter.
> (actually it's in the GC right?)
>
> There is no interpreter in my system, and many modern systems use a JIT.
> That or they generate Javascript or JVM instructions or .NET or something,
> and then _that_ gets turned into native code.
>
> - You cannot serialize objects containing blocks. (IIRC one can use
> MessageSends)
>
> True in my system but that's because blocks contain pointers to native
> code and may
> contain pointers into the C stack.  I have plans to work around this, but
> it has not been
> a priority.  Something I don't ever plan to deal with is objects
> containing references to
> external objects (memory-mapped segments, file descriptors, sockets, ...)
> and it is not
> at all clear to me what the semantics should be.
>
> BinaryObjectStorage in VisualWorks has no trouble with blocks.
>
> I meant to try this in Pharo 7.0.  The image I just installed via the
> launcher has
> no DataStream, ReferenceStream, or SmartRefStream, but the class comment
> for MCDataStream begins
> "This is the save-to-disk facility.
>  A DataStream can store one or more objects in a persistent form.
>
>  To handle objects with sharing and cycles, you must use a ReferenceStream
>  instead of a DataStream.  (Or SmartRefStream.)  ReferenceStream is
> typically
>  faster and produces smaller files because it doesn't repeatedly write the
> same Symbols."
>
> This was also the case back to  Pharo 2.0.  What *is* the persistence
> scheme in Pharo these days?
>
> - Image cannot be bootstrapped. (This is possible in ST/X and now in Pharo
> I think).
>
> There are no images in my system.
>
> - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK).
>
> It depends on what you mean by "include".  Gnu Smalltalk *has* UI classes
> but they
> are not loaded by default.
>
> - All implementations uses direct pointers, (GST?)
>
> True in my case, but that's because I'm lazy and using the Boehm collector.
>
> - All implementations uses green threads. (VAST? MT?)
>
> False in my case.  A Process is a POSIX (red) thread and no green threads
> exist.
> This meant having to keep the interface fairly lean, but honestly wasn't
> that hard,
> since the Boehm collector handled the hard stuff.
>
>
> On Tue, 22 Jan 2019 at 13:27, Hernán Morales Durand <
> hernan.morales at gmail.com> wrote:
>
>>
>> Done.
>>
>> I have some possible myths, but I'd like to confirm or reject:
>>
>> - All Smalltalk bytecode sets are stack-based VM. (?)
>> - Bytecodes are always fixed-size. (?)
>> - Most of the time spent by a VM is in the instruction interpreter.
>> (actually it's in the GC right?)
>> - You cannot serialize objects containing blocks. (IIRC one can use
>> MessageSends)
>> - Image cannot be bootstrapped. (This is possible in ST/X and now in
>> Pharo I think).
>> - All Smalltalks includes UI classes. (GemStone doesn't have AFAIK).
>> - All implementations uses direct pointers, (GST?)
>> - All implementations uses green threads. (VAST? MT?)
>>
>> I'm sure people in this list will have a lot more myths heard from
>> Conferences, Forums, Videos, Talks, etc. Like the guy who said Smalltalk
>> was dead. So if you did something which could be ignored publicly, please
>> don't hesitate to reply or ping me to get added as collaborator.
>>
>> Cheers,
>>
>> Hernán
>>
>>
>>
>> El dom., 20 ene. 2019 a las 22:41, Eliot Miranda (<
>> eliot.miranda at gmail.com>) escribió:
>>
>>> Hi Hernán,
>>>
>>> On Sun, Jan 20, 2019 at 2:31 PM Hernán Morales Durand <
>>> hernan.morales at gmail.com> wrote:
>>>
>>>> Hi there,
>>>>
>>>> I just created a GitHub repo to collect myths around Smalltalk-based
>>>> technologies: Pharo, Squeak, VW, VAST, Smalltalk/X, GNU/ST, etc. in the
>>>> spirit of the Falsehoods lists [1-4].
>>>>
>>>> This is just a draft now but please feel free to add falsehoods based
>>>> on your own experiences. Examples are greatly appreciated.
>>>>
>>>
>>> You want pull requests?  If not, would you give me write permission?
>>> I'd love to add to the "Smalltalk is obsolete" section...
>>>
>>>
>>>>
>>>> https://github.com/hernanmd/falsehoods_smalltalk
>>>>
>>>> Cheers,
>>>>
>>>> Hernán
>>>>
>>>> [1]
>>>> https://infiniteundo.com/post/25326999628/falsehoods-programmers-believe-about-time
>>>> [2]
>>>> https://chiselapp.com/user/ttmrichter/repository/gng/doc/trunk/output/falsehoods.html
>>>> [3]
>>>> https://github.com/googlei18n/libphonenumber/blob/master/FALSEHOODS.md
>>>> [4]
>>>> https://meta-package-manager.readthedocs.io/en/develop/falsehoods.html
>>>>
>>>>
>>>>
>>>
>>> --
>>> _,,,^..^,,,_
>>> best, Eliot
>>>
>> _______________________________________________
> Glass mailing list
> Glass at lists.gemtalksystems.com
> http://lists.gemtalksystems.com/mailman/listinfo/glass
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20190129/8a7afa68/attachment.html>