[Cuis-dev] About learning Smalltalk. About documentation and &A. Re: ODBC error
Jaromir Matas
mail at jaromir.net
Mon Oct 21 14:14:11 PDT 2024
Hi Juan,
> I had always learned by myself, reading books and experimenting with
the computer. This approach failed completely with C++. I read 3 or four
books, cover to cover. I did a lot of experiments, and could not see the
value.
Thanks very much for sharing this experience, Juan! I loved everything
about computers and programming in the '80s but then I learned Pascal at
school (no objects, just plain imperative) and was disappointed. Fast
forward 30 years, I decided to learn OOP on my own and failed miserably
(unfortunately tried Python... bad choice indeed). But then googled
"best OOP language" and discovered Smalltalk at last :)
> I don't know how it is to discover Smalltalk without a great teacher!
Painful :D
> I think it would be best to take a Smalltalk course with great
teachers.
Absolutely, if you're lucky to be near some. None here in Prague but I
hear Smalltalk is taught in Potsdam (Berlin) where Squeak has a great
support in case you're in Germany.
> What is next best to that? I think that Dan Ingalls' "Design
Principles Behind Smalltalk" is the best presentation of the ideas.
Looking back, I should have taken a good OOP course at the university
and then tackle Smalltalk, not the other way round :)
Speaking of "ideas" in the code - I meant not only the "big" ones but
also the small ones present in every non-trivial method. Understanding
those is paramount when attempting to modify (fix or enhance, or just
simplify) someone else's code without degrading it. These should get
commented more thoroughly.
> In Smalltalk, all the libraries are "white box". You are encouraged to
see what they do. Time spent learning how to inspect and query the
system is the best investment you can do in Smalltalk.
> [...] if you succeed in finding the answer before asking, your benefit
is much bigger.
I agree absolutely; besides, studying the system is a joy BUT the time
investment for a **beginner** (without a teacher) is just overwhelming
(unfamiliar syntax and IDE, lack of "usual" mainstream knowledge sources
- SO, documentation, etc.). This may be a deciding factor before one
commits to Smalltalk rather than Python ;)
> Hey Jaromir, you are in a better position than almost anyone (me
included!) to write about the areas where you digged really deep and
made great contributions. I know your code is clear, and with great
comments. Still, if you ever feel like writing some .md documents on the
stuff you know better than most, it would be a very welcome
contribution!
Thanks Juan, writing some sort of partial documentation is still on my
mind. I'd like to figure out how to incorporate such an information
directly into the image though. It's not a method comment, not even a
class comment, let alone a "book" but my idea is such info should be as
close to the code as possible and ideally accessible from the code
(whether a hyperlink or a button or something else I don't know yet).
Recently I've kind of stepped aside and took courses in Python, Haskell,
Javascript and Rust to get the bigger picture but very much look forward
to getting back to Smalltalk soon.
Best regards and many thanks,
Jaromir
On 21-Oct-24 8:47:54 PM, "Juan Vuletich" <juan at cuis.st> wrote:
>Hi Jaromir, Mark, all,
>
>Comments inline. Please read in detail. I think this is important.
>
>On 10/21/2024 12:25 PM, Jaromir Matas via Cuis-dev wrote:
>
>>Hi Mark, all,
>>
>>I myself discovered Smalltalk as late as 2020 and found that, at least
>>in my case, learning Smalltalk was pretty difficult despite the
>>simplicity, consistency and overall beauty of the language. And I too
>>love it :) (in my case it's both Squeak and Cuis)
>>
>
>I discovered Smalltalk in 1995. By that time, I had been programming
>for 10 years. After the obvious (at that time) start with Basic, I
>quickly moved to 6809 Assembly and did pretty advanced real time music
>stuff. Then, I moved to C, as a kind of "portable Assembly". When C++
>seemed to take over the world, I assumed it was the obvious next step.
>Up to this moment, I had always learned by myself, reading books and
>experimenting with the computer.
>
>This approach failed completely with C++. I read 3 or four books, cover
>to cover. I did a lot of experiments, and could not see the value.
>Never understood the "TurboVision" library. I did value what is called
>C+, that is statically determined "polymorphism" based on parameter
>types.
>
>Then, I was lucky. I was around 3rd year in my CS studies at
>UniBuenosAires. An elective course called "Object Oriented
>Programming" was offered. I knew that was what I'd failed to grasp with
>C++, so I signed up for it. The teacher, Máximo Prieto changed my life
>forever, as he changed the life of may of us then. He introduced us to
>Smalltalk, and the whole idea of dealing with complexity. He also
>started the thriving Smalltalk community in Buenos Aires. Today
>Smalltalk is taught at several universities here, there are several
>companies using it for real product development. Buenos Aires is the
>main source of Smalltalk talent for almost all the Smalltalk systems
>currently in active development, not just Cuis.
>
>So, I don't know how it is to discover Smalltalk without a great
>teacher!
>
>> > Early in my learning I had a lot of beginner questions for which I
>>failed to easily find answers. [...] and there is a high expectation
>>that beginners will read through the source code and try hard to find
>>answers on their own.
>>
>>I so much share your frustration! In my experience no amount of
>>reading the code can replace guidelines from experienced users
>>enlightening the **intentions** behind the code as some parts of the
>>code are just implementation details and trade-offs while some other
>>parts are the "good stuff", bear the ideas. But which is which?! This
>>is where I struggle the most, to be able to extract the ideas and
>>filter out the "noise", and where I consider expert advice
>>irreplaceable. And this is one of the things I'd love to find in
>>comments.
>
>I think it would be best to take a Smalltalk course with great
>teachers. I know, I know, that is even harder to find than good
>developers for your Smalltalk project (unless you look at Buenos
>Aires!).
>
>What is next best to that? I think that Dan Ingalls' "Design Principles
>Behind Smalltalk" is the best presentation of the ideas. I can't stress
>how important it is to read it and really try to understand it. There
>are many other good introductory books on Smalltalk, all freely
>available on the web. Adele Goldberg's "Smalltalk-80, the language and
>its implementation" is great. There are several others, including our
>own "The Cuis Book" by our friend Hilaire Fernandes. In the
>Documentation folder of our mail repo you can also find some good
>material, including lots of references for further reading. There are
>also many videos online that will help.
>
>Books, magazine articles and videos include descriptions of the ideas
>and intentions behind the code that are generally better than answers
>in the mail list, because they were written with great care. Questions
>on the mail list are better for filling in details, especially if they
>are specific to some dialect (like Cuis) not directly addressed in the
>book. For instance, this email is taking an hour to write, and the mail
>thread leading to this has had me thinking at least 5 times more. Maybe
>I'd turn this email into an .md document for the Cuis repo. Then, will
>people read it?
>
>> > So I frequently asked questions on this mailing list. Over time I
>>learned that doing that is frowned on [...] While some in the
>>community may have been annoyed by the number of questions I have
>>asked [...]
>>
>>I honestly don't believe it's the case! Otherwise I'd be afraid to ask
>>next time :)
>
>Questions are most welcome. In this space we value free speech, and at
>the same time we want an open and warm place where everybody can feel
>comfortable.
>
>For any Open Source project, questions are especially valuable if they
>point to some aspect not covered in enough clarity and detail in the
>documentation. Good questions help us refine documentation, or fix
>annoyances in the system. You know, we old timers don't read the
>documentation we wrote very often, and we tend to get used to
>annoyances in the system to the point where we don't see them any more.
>Good questions, complaints and bug reports are extremely helpful!
>
>Still, questions that can be addressed by reading the documentation, or
>a quick query to the system can sometimes feel annoying, at least to
>me. I can carefully write some explanation, investing several hours,
>and making that part of the documentation. Or I can write 10 times
>about the same issue, when someone asks, each time improvising a low
>quality ten minutes email. The first option results in higher quality
>material, that can benefit many people over the course of years. The
>second option gives a low quality answer to just one person, that will
>most likely not be read again.
>
>So, if you read the documentation first, and then point to flaws or
>missing parts, you are really helping us make a better system. I can't
>stress this enough. I really, really, really, very much, prefer this!
>
>> > I really want to contribute via the documentation I'm creating and
>>hope that at some point all of that content can be the basis for a
>>book focused on Cuis Smalltalk.
>>
>>I wish you succeeded in this endeavor :) Again, my beginnings with
>>Smalltalk were painful due to the lack of documentation and an
>>availability of a vast knowledge base of the Stack Overflow type where
>>you can sooner or later find a question similar to the one you're
>>struggling with. I'm learning Rust at the moment and at least most of
>>my beginner questions and confusion have been covered by the
>>documentation so far. But I very much realize how much work it is to
>>provide such a documentation and that it's only possible thanks to the
>>size of the community; the amount of work to create (and maintain!)
>>such a documentation is, I believe, about the same regardless of the
>>language hence it's so much more difficult for small communities like
>>Squeak/Cuis's where just a few individuals must carry the burden.
>
>While this is true, most languages and frameworks are what is called
>"black box". You only get the APIs or language constructs to use. If
>documentation is unclear or missing, your only resource is to ask
>someone for help. As Dan Ingalls says in his "Design Principles Behind
>Smalltalk", Smalltalk tries to offer a completely different experience.
>In Smalltalk, all the libraries are "white box". You are encouraged to
>see what they do. Time spent learning how to inspect and query the
>system is the best investment you can do in Smalltalk.
>
>>Quite recently I've discovered that the github Copilot can be a
>>tremendous help in learning a language (accelerates learning the
>>syntax, explains features and bugs, auto-fills simple examples and
>>even more complicated code snippets - not always correct but even that
>>helps!). I wish such a tool was available for Smalltalk as a lot of
>>beginner questions could be solved right away.
>>
>>I wish there were more up-to-date sources like the Cuis book, Squeak
>>by example but also introductory books on more advanced stuff like
>>Stephane Ducasse's books on concurrent programming in Smalltalk or
>>Eliot Miranda's blog on contexts & friends.
>
>Hey Jaromir, you are in a better position than almost anyone (me
>included!) to write about the areas where you digged really deep and
>made great contributions. I know your code is clear, and with great
>comments. Still, if you ever feel like writing some .md documents on
>the stuff you know better than most, it would be a very welcome
>contribution!
>
>>Best of luck,
>>
>>Jaromir
>
>Cheers,
>
>>
>>On 21-Oct-24 2:34:10 AM, "Mark Volkmann via Cuis-dev"
>><cuis-dev at lists.cuis.st> wrote:
>>
>>>I apologize if the way I worded my question came across as rude. That
>>>was certainly not my intent. I think I should explain why I've tried
>>>to be a part of the Cuis Smalltalk community for the past eight
>>>months or so.
>>>
>>>I'm pretty new to Smalltalk and it turns out I love it. And so far
>>>Cuis Smalltalk is my favorite distribution.
>>>
>>>Early in my learning I had a lot of beginner questions for which I
>>>failed to easily find answers. So I frequently asked questions on
>>>this mailing list. Over time I learned that doing that is frowned on
>>>and there is a high expectation that beginners will read through the
>>>source code and try hard to find answers on their own. I've tried
>>>hard to do that, but haven't always been successful.
>>>
>>>I decided that I wanted to help future beginners find the answers to
>>>all the questions I had more easily. So I started documenting
>>>everything I learned about Smalltalk at
>>>https://mvolkmann.github.io/blog/ (select Smalltalk in the left nav
>>>to see a long list of subtopics). As you can see, I have spent a
>>>large amount of time on this. It's nothing compared to those of you
>>>that have been contributing to Cuis Smalltalk for years, but I think
>>>it provides a good resource for anyone new to Smalltalk in general
>>>and Cuis Smalltalk in particular.
>>>
>>>I do not have a particular app in mind that I want to build with
>>>Smalltalk. Instead I'm constantly thinking about how I would convince
>>>non-Smalltalk developers to give Cuis Smalltalk a try. A perfect
>>>example of that is my investigation into database access. Many of the
>>>developers I know are web developers. Accessing relational databases
>>>is a fundamental part of implementing most web applications. So I
>>>need to be able to demonstrate how that is done from Cuis Smalltalk
>>>to have any hope of convincing my web developer friends to try it. As
>>>far as I know, based on many searches, there is not currently a web
>>>page that shows step-by-step how to access a relational database
>>>using Cuis Smalltalk. I want to provide that if I can learn how to do
>>>it.
>>>
>>>While some in the community may have been annoyed by the number of
>>>questions I have asked, I do hope there is a feeling that my presence
>>>in the Cuis community has had a net positive impact. In addition to
>>>the documentation I've created in my blog I have identified a number
>>>of minor issues that have been fixed, contributed a small change set
>>>that added the ability to set a background image in cover and tile
>>>modes, and most recently contributed a library for implementing web
>>>servers that has many advantages over the WebClient library (
>>>https://github.com/mvolkmann/Cuis-Smalltalk-WebClientPlus).
>>>
>>>I really want to contribute via the documentation I'm creating and
>>>hope that at some point all of that content can be the basis for a
>>>book focused on Cuis Smalltalk.
>>>
>>>P.S. I honestly didn't know that the
>>>Cuis-Smalltalk-Dev/Documentation/Technical directory existed. Thanks
>>>for pointing that out. I'll read that now.
>>>
>>>On Sun, Oct 20, 2024 at 5:48 PM Juan Vuletich < juan at cuis.st> wrote:
>>>>Hi Mark,
>>>>
>>>>What follows may be an intricate reading involving language,
>>>>manners, and how the Open Source world works. Please read carefully.
>>>>
>>>>On 10/20/2024 7:31 AM, Mark Volkmann via Cuis-dev wrote:
>>>>>I should have asked “Is it possible that nobody that uses Cuis
>>>>>Smalltalk in macOS accesses relational databases?”
>>>>
>>>>Who knows? Cuis Smalltalk is MIT license you get the whole system,
>>>>free for any use, without any obligations. That means that you are
>>>>not required to disclose what you do with it. As a consequence of
>>>>that, the answer to "it is possible that nobody that uses Cuis
>>>>Smalltalk does XXX?" is true, for any XXX. Does this matter? I don't
>>>>think so.
>>>>
>>>>A much better way to react would be something like "Hi Folks. I'm
>>>>trying to do XXX. I know the system is fully open and explicitly
>>>>designed to make it easy for me to solve my technical problems, but
>>>>I'm still unable to do so. Has anybody faced these kinds of problems
>>>>I'm seeing before, and is willing to help me?".
>>>>
>>>>That will indeed work much better.
>>>>
>>>>Additionally, some comment from you revealing that you have already
>>>>read the contents of the /Documentation/Technical folder would be
>>>>appreciated. Your first message made me believe you hadn't realized
>>>>you had trouble calling an API via FFI. But Jon's answer doesn't
>>>>tell you that, and assumes you already know that. Your following
>>>>message makes me now believe that you know that the problem may be
>>>>"how to reference a lib path in the Open Smalltalk VM", indeed being
>>>>aware that this is a problem with FFI.
>>>>
>>>>Once you realize that, you may also realize that this problem has
>>>>almost nothing to do with Cuis Smalltalk. A bit of googling shows
>>>>people asking similar (but better formed) questions in nginx and
>>>>lua.
>>>>
>>>>I'm starting to have doubts about your intellectual honesty while
>>>>asking these questions. I think the Cuis community deserves better
>>>>than this.
>>>>
>>>>Thanks,
>>>>
>>>>>
>>>>>---
>>>>>R. Mark Volkmann
>>>>>Object Computing, Inc.
>>>>>
>>>>>>On Oct 20, 2024, at 6:26 AM, Mark Volkmann
>>>>>><r.mark.volkmann at gmail.com> <mailto:r.mark.volkmann at gmail.com>
>>>>>>wrote:
>>>>>>
>>>>>> Yikes! Sounds complicated. Can you point me to any documentation
>>>>>>that describes how I could reference a lib path in the Open
>>>>>>Smalltalk VM?
>>>>>>
>>>>>>Is it possible that nobody that uses Cuis Smalltalk accesses
>>>>>>relational databases?
>>>--
>>>R. Mark Volkmann
>>>Object Computing, Inc.
>
>
>--
>Juan Vuletich
>cuis.st
>github.com/jvuletich
>researchgate.net/profile/Juan-Vuletich
>independent.academia.edu/JuanVuletich
>patents.justia.com/inventor/juan-manuel-vuletich
>linkedin.com/in/juan-vuletich-75611b3
>twitter.com/JuanVuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241021/7a7fcfa9/attachment-0001.htm>
More information about the Cuis-dev
mailing list