[Cuis-dev] About learning Smalltalk. About documentation and &A. Re: ODBC error

Tue Oct 22 07:47:04 PDT 2024

Hi to all!
This is a very interesting conversation. I feel totally identified with the
difficulties posed by learning Smalltalk without a teacher / tutor. It's
really hard despite the joy and fun that Smalltalk is.

Regarding documentation Jaromir, I too, considered the same issues you
mentioned. I found Erudite to be a very good choice. The ability to mix
code with text and form "books" is ideal to document progress. It's the
closest thing I found to "Literate Programming with Smalltalk" in Cuis.

Best
Nacho

On Mon, Oct 21, 2024 at 6:22 PM Jaromir Matas via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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>
>> <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 Vuletichcuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletichlinkedin.com/in/juan-vuletich-75611b3twitter.com/JuanVuletich
>
> --
> 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/20241022/f41e28e7/attachment-0001.htm>