6 ms·

Weirdest programming language/IDE/Runtime/everything I've ever attempted learning. The sheer oddity + lack of real world example code floating around made it f

Weirdest programming language/IDE/Runtime/everything I've ever attempted learning. The sheer oddity + lack of real world example code floating around made it feel impenetrable. To put it into perspective, picking up Rust and writing entry level but real world applications was a walk in the park after coming to terms with the ownership system.

DeathArrow 2y ago
You can try to look at Rosetta Code if you want examples.
krylon 2y ago
I had a similar experience when I tried to learn Smalltalk. Pharo By Example is a thing. I haven't read it, but I assume it is forked from or inspired by Squeak By Example, which made things click for me (at least a little). https://books.pharo.org/pharo-by-example9/ https://books.pharo.org/pharo-by-example9/
- 0x445442 2y ago
  IIRC, Squeak By Example is heavily Morphic centric, which is going to immediately diverge from other language Getting Started sections. Not sure if one exists but a Getting Started that focuses on just the Workspace, the Transcript and data processing might be a better introduction to those with experience in more traditional languages.
  - igouy 2y ago
    "Quick-UI-Tour" https://github.com/Cuis-Smalltalk/Learning-Cuis/blob/master/Quick-UI-Tour.md https://github.com/Cuis-Smalltalk/Learning-Cuis/blob/master/... "The Cuis Book" https://cuis-smalltalk.github.io/TheCuisBook/ https://cuis-smalltalk.github.io/TheCuisBook/
andsoitis 2y ago
Fwiw, you can inspect the Pharo code from within the running Pharo itself. If you’re looking for a good real life code base that is not the bare Pharo, you can check out Glamorous Toolkit: https://gtoolkit.com// https://gtoolkit.com//
0x445442 2y ago
Learning Rust is at least an order of magnitude harder than learning Smalltalk. This is not to dismiss what you have said. On the contrary, it highlights what must be an enormous miss in how Pharo presents documentation on its landing page.
- whartung 2y ago
  Rust the language is certainly more difficult than the Smalltalk language. The language isn't the issue. You have Smalltalk the language, which is this [] big, and Smalltalk the environment and class libraries, notably the GUI system, which is this [.....**.....] big. And, sure, you have all of the source code, but, for me, the source code may as well be organized in a stack of index cards. You get the individual methods, but not the sweeping picture. I can learn a lot more scanning a file full or source code, compared to the little snippets of code you're presented with screen by screen. Just being able to scroll and absorb is useful. But even then, especially being OO, with lots of abstraction, tracing through the GUI code, blind, is very difficult. You end up at top level, "do nothing" abstraction classes. Much like in Java, where everything you click on is an interface, which doesn't tell you a whole lot. Navigating a Smalltalk image is a skill all its own.
  - cess11 2y ago
    When I realised there was a difference between inspecting a class and an instance it became much easier to find the things I was looking for.
- selykg 2y ago
  I don't think that's necessarily what the OP is saying. I agree with OP. Finding documentation to learn to use this absolutely obscure system is near impossible. I seen an announcement about a Pharo release a couple years ago and was like "huh, that sounds cool." Proceded to download it and had no clue about anything. It is not at all like any other IDE. Learning it might not be hard, but when the IDE is absolutely different from anything else you've ever used, combined with very little documentation that speaks to how to do the basics, it can be a very mysterious and difficult thing. Rust is like any other programming language, in that you write code in a file, then compile it. Yes, there's other stuff to deal with in between and it can get way more complicated. But the IDE is the real culprit, combined with documentation for a developer to learn to develop real applications with, that makes Pharo infinitely more difficult in my personal opinion. I guess to simplify this a little with an edit. If you already know another programming language, learning Rust is not fundamentally different. Some parts of it will be difficult like the borrow system and stuff that's very Rust centric. But in most ways it behaves like a lot of other languages in terms of using it at a bare bones basic level. Pharo is ... otherworldly in that nothing else really compares, you have to learn a completely different paradigm for how to program it, and that is the difficult part imo.
Qem 2y ago
Did you try the MOOC? At first the environment may feel a bit confusing, but the videos in the MOOC help to walk through it, visually, and get familiar: https://mooc.pharo.org/ https://mooc.pharo.org/ Also there's lots of free books at https://books.pharo.org/ https://books.pharo.org/
melvinroest 2y ago
I agree with you. I've worked for a while at a company using it in production [1]. For learning Pharo (while not working at a company), I've learned that going to ESUG [1] and Pharo Days [2] (2 conferences) is the best way to actually learn. On ESUG there are many professional Smalltalkers, including people that write Pharo. And on Pharo Days there are many OG Pharo devs. They can teach you certain things much quicker than any course can. For example, on ESUG, I was shown how to write a debugger extension on the spot for a particular debugging case (with animations) that had no good working debugging support yet. It was amazing to see how quick people can develop it when they have strong knowledge on it. The fact that the language is inspectable helps a ton. Another way to learn is by asking many questions on their Discord channel [4]. The community seems really active there and I found them to be really friendly. The Pharo website [5] sort of understates how active their spun off communities are as they simply mention that they exist, but the site doesn't really convey the vibe of how lively the communities are. I'm not sure how one would go about that, but it's a shame you can't directly see that from a website. [1] https://yesplan.be https://yesplan.be [2] https://esug.org https://esug.org [3] https://days.pharo.org https://days.pharo.org [4] https://discord.gg/QewZMZa https://discord.gg/QewZMZa [5] https://pharo.org/community https://pharo.org/community
- nsm 2y ago
  I think Pharo would benefit a lot from having lots and lots of screen casts, since so much stuff is visual. I don't think something like ESUG is a sustainable way to spread techniques. A lot of stuff that is well documented in the Pharo ecosystem is old. A lot of the new stuff doesn't have great docs. Just reference docs and code is not enough. There has to be a coherent narrative around an API to put it together. Also, I'm all onboard having a UI environment for programming, but it needs to have great keybindings that follow platform HIGs, and at least my Pharo 10 experience of the window management was really bad. I wrote about this some https://nikhilism.com/post/2021/experiencing-smalltalk/ https://nikhilism.com/post/2021/experiencing-smalltalk/
  - em-bee 2y ago
    i agree. here is a screencast i made: https://news.ycombinator.com/item?id=38995507 https://news.ycombinator.com/item?id=38995507 i don't know how much has changed since then. but if pharo has changed so much that this screencast can no longer be used then that's a problem in itself. we are not going to gwt more screencasts if their halflife is to short.
mark_l_watson 2y ago
I would like to disagree with you, but I can’t. Pharo, and Squeak that it is derivative from, is an odd development experience. A long time ago I experimented with making web apps with Pharo, fun, but I wouldn’t use it in production. When I saw this announcement I was motivated to update my Pharo NLP library https://github.com/mark-watson/nlp_smalltalk https://github.com/mark-watson/nlp_smalltalk but I may not. Many NLP tasks are now done infinitely better using deep learning and LLMs. I just looked for OpenAI API support and found 2 year old Pharo project library https://github.com/pharo-ai/open-ai https://github.com/pharo-ai/open-ai and maybe more promising 1 year old project by Bracken https://github.com/brackendev/OpenAI-Pharo https://github.com/brackendev/OpenAI-Pharo EDIT: to be fair to Pharo, I am not really a Smalltalk person. In 1983 someone at Xerox arranged for me to get a trial Smalltalk system on My Xerox 1108 Lisp Machine, and I removed it within a few weeks.
fizfaz 2y ago
> The sheer oddity + lack of real world example code floating around made it feel impenetrable not sure if I understand you, but you have the code of the whole system at your fingertips. Which is certainly "real world" because you are running it :)
- em-bee 2y ago
  real world example means end user applications, not developer tools. i want to see how an application looks like that my mother could use, or that i could sell to my customer. websites. desktop applications that hide the IDE...
  - igouy 2y ago
    Your applications would look however you wanted them look. https://pharo.org/success/ https://pharo.org/success/
    - em-bee 2y ago
      that's not the question. we are looking for examples that come with source that can be studied. the success page lists 53 projects. only one of them came with a direct link to the source. one included an un-clickable link. one linked to a non-english website where i could figure out that it was licensed under the LGPL, but i could not find the link to the source. a surprise was that DrGeo which is known to be Free Software links to a dead website. grafoscopio which i also believe to be FOSS as well has a dead download link on its website. several other projects had dead links too. the only source i found was for HoneyGinger: https://github.com/tomooda/HoneyGinger https://github.com/tomooda/HoneyGinger OpenPonk https://github.com/OpenPonk https://github.com/OpenPonk and record: https://github.com/estebanlm/record https://github.com/estebanlm/record (7 years old) btw, DrGeo is here: https://github.com/hilaire/drgeo https://github.com/hilaire/drgeo that is three source examples under active development for a project as old and as large as pharo is that is surprisingly little. more accessible source examples are needed to attract developers. especially given the difficulty to get used to the pharo developer tools. i have actively explored working with pharo. i just could not find any useful apps that i could use and contribute to. and i had no ideas for an app that i'd be interested enough to create from scratch. for a while i even tried to use it as a desktop and used an app that provides a commandline inside pharo. the primary problem was that upgrading to a new version of pharo each year was difficult. given the image based development you tend to start with a current version of pharo and then keep to that version until you are done.
znpy 2y ago
I had the same experience. Spent a couple of (vacation) weeks devoting 2-3 hours a day to Pharo and going through all of one of the books from the website (Pharo by example? can't really remember). It's really one of those things that will die out on their own, because of the many layers and the little applicability (outside of playing the gimmicks).
peatmoss 2y ago
Squeak / Pharo are alternate timeline technologies. Maybe the one where Betamax won and Al Gore read the intelligence briefing. Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes. Rust is radical in some ways, but it's fundamentally a creature of the vaguely Unixy paradigm we all live in today. I miss the weird world of possibilities we used to have.
- charlysl 2y ago
  > Al Gore read the intelligence briefing. Wasn't that George W. Bush?
  - cess11 2y ago
    Not in the alternate timeline.
    - charlysl 2y ago
      Ha ha, I see, nice
- derefr 2y ago
  > Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes. I would argue that this lineage of computing isn't as arcane and out-of-reach as people might think. Much of the "obvious" promise of Smalltalk / object-based runtime environments — specifically, all the UI stuff it enabled — was too expensive / high-overhead initially, for it to have much penetration in the microcomputer or the mainframe/batch processing space; thus relegating those specific ideas to academic experiments in workstation productivity. But fancy object-based UIs weren't the whole of what this lineage of computing was about. Microcomputer and mainframe systems were built as descendants of this lineage, repeatedly, and many of them were even in common use; but it might be harder to recognize them as such. It's the less-obvious, more low-level/internal architectural things they inherited. If you ignore the specific assumption of a UI or "strict" OOP, and instead just consider this lineage as anything fitting these criteria: 1. systems that booted into a live runtime bytecode VM, usually de-hibernating the VM state from a memory image; 2. and then exposing a shell that was more of a REPL than a command language, allowing interoperation with the data that defined the state of the VM on a high level, 3. where the "operating system" within the runtime is fully exposed to you (rather than being a black box with a whitelisted FFI API); but where each data structure within that "operating system" is protected due to the common runtime of the OS + userland, enforcing ADT-defintion-time abstraction layers in the way it allows clients (including the REPL) to interact with any given object/ADT... ...then you could say that all of the following are part of the lineage: • BASIC — especially the BASICs on microcomputers that booted to BASIC, or had BASIC on ROM, and never ran DOS (published software for these computers, was usually just precompiled BASIC bytecode!) • Object Pascal / Delphi • Emacs • most SQL databases, but especially Ingress • MOOs (object-oriented MUDs) • Plan 9, despite its Unix roots. (Especially applicable insofar as you could consider "a runtime and OS as toolkit, and applications as LEGO with clear exposed seams that the user can pick apart and remix" an additional criterion.) You can usually recognize these systems, because there's no way to get anything like a machine-code monitor / debugger on them; instead, the runtime itself usually exposes bytecode-level (or interpreter-level) monitoring / debugging, in a way that doesn't allow you to break the runtime's assumptions through it.
cess11 2y ago
Others have linked to the book collection, there you'll find walkthroughs of the basics, building web applications, tracking code in git, and so on. A lot of the common packages also have examples bundled that you can play around with and read documentation in. Once one gets over the initial hurdle of the syntax, message passing and how to use the GUI to create new projects and objects one can usually just surf around in the image and look for examples to figure things out.
agumonkey 2y ago
Without an online course or a mentor I'd be lost too. But you only need a two hour introduction to have fun IMO.
guessbest 2y ago
How would you compare this to say, writing WinForm applications in Visual Basic 6?

DeathArrow 2y ago

You can try to look at Rosetta Code if you want examples.

krylon 2y ago

I had a similar experience when I tried to learn Smalltalk. Pharo By Example is a thing. I haven't read it, but I assume it is forked from or inspired by Squeak By Example, which made things click for me (at least a little). https://books.pharo.org/pharo-by-example9/ https://books.pharo.org/pharo-by-example9/

0x445442 2y ago
IIRC, Squeak By Example is heavily Morphic centric, which is going to immediately diverge from other language Getting Started sections. Not sure if one exists but a Getting Started that focuses on just the Workspace, the Transcript and data processing might be a better introduction to those with experience in more traditional languages.
- igouy 2y ago
  "Quick-UI-Tour" https://github.com/Cuis-Smalltalk/Learning-Cuis/blob/master/Quick-UI-Tour.md https://github.com/Cuis-Smalltalk/Learning-Cuis/blob/master/... "The Cuis Book" https://cuis-smalltalk.github.io/TheCuisBook/ https://cuis-smalltalk.github.io/TheCuisBook/

andsoitis 2y ago

Fwiw, you can inspect the Pharo code from within the running Pharo itself. If you’re looking for a good real life code base that is not the bare Pharo, you can check out Glamorous Toolkit: https://gtoolkit.com// https://gtoolkit.com//

0x445442 2y ago

Learning Rust is at least an order of magnitude harder than learning Smalltalk. This is not to dismiss what you have said. On the contrary, it highlights what must be an enormous miss in how Pharo presents documentation on its landing page.

whartung 2y ago
Rust the language is certainly more difficult than the Smalltalk language. The language isn't the issue. You have Smalltalk the language, which is this [] big, and Smalltalk the environment and class libraries, notably the GUI system, which is this [.....**.....] big. And, sure, you have all of the source code, but, for me, the source code may as well be organized in a stack of index cards. You get the individual methods, but not the sweeping picture. I can learn a lot more scanning a file full or source code, compared to the little snippets of code you're presented with screen by screen. Just being able to scroll and absorb is useful. But even then, especially being OO, with lots of abstraction, tracing through the GUI code, blind, is very difficult. You end up at top level, "do nothing" abstraction classes. Much like in Java, where everything you click on is an interface, which doesn't tell you a whole lot. Navigating a Smalltalk image is a skill all its own.
- cess11 2y ago
  When I realised there was a difference between inspecting a class and an instance it became much easier to find the things I was looking for.
selykg 2y ago
I don't think that's necessarily what the OP is saying. I agree with OP. Finding documentation to learn to use this absolutely obscure system is near impossible. I seen an announcement about a Pharo release a couple years ago and was like "huh, that sounds cool." Proceded to download it and had no clue about anything. It is not at all like any other IDE. Learning it might not be hard, but when the IDE is absolutely different from anything else you've ever used, combined with very little documentation that speaks to how to do the basics, it can be a very mysterious and difficult thing. Rust is like any other programming language, in that you write code in a file, then compile it. Yes, there's other stuff to deal with in between and it can get way more complicated. But the IDE is the real culprit, combined with documentation for a developer to learn to develop real applications with, that makes Pharo infinitely more difficult in my personal opinion. I guess to simplify this a little with an edit. If you already know another programming language, learning Rust is not fundamentally different. Some parts of it will be difficult like the borrow system and stuff that's very Rust centric. But in most ways it behaves like a lot of other languages in terms of using it at a bare bones basic level. Pharo is ... otherworldly in that nothing else really compares, you have to learn a completely different paradigm for how to program it, and that is the difficult part imo.

Qem 2y ago

Did you try the MOOC? At first the environment may feel a bit confusing, but the videos in the MOOC help to walk through it, visually, and get familiar: https://mooc.pharo.org/ https://mooc.pharo.org/ Also there's lots of free books at https://books.pharo.org/ https://books.pharo.org/

melvinroest 2y ago

I agree with you. I've worked for a while at a company using it in production [1]. For learning Pharo (while not working at a company), I've learned that going to ESUG [1] and Pharo Days [2] (2 conferences) is the best way to actually learn. On ESUG there are many professional Smalltalkers, including people that write Pharo. And on Pharo Days there are many OG Pharo devs. They can teach you certain things much quicker than any course can. For example, on ESUG, I was shown how to write a debugger extension on the spot for a particular debugging case (with animations) that had no good working debugging support yet. It was amazing to see how quick people can develop it when they have strong knowledge on it. The fact that the language is inspectable helps a ton. Another way to learn is by asking many questions on their Discord channel [4]. The community seems really active there and I found them to be really friendly. The Pharo website [5] sort of understates how active their spun off communities are as they simply mention that they exist, but the site doesn't really convey the vibe of how lively the communities are. I'm not sure how one would go about that, but it's a shame you can't directly see that from a website. [1] https://yesplan.be https://yesplan.be [2] https://esug.org https://esug.org [3] https://days.pharo.org https://days.pharo.org [4] https://discord.gg/QewZMZa https://discord.gg/QewZMZa [5] https://pharo.org/community https://pharo.org/community

nsm 2y ago
I think Pharo would benefit a lot from having lots and lots of screen casts, since so much stuff is visual. I don't think something like ESUG is a sustainable way to spread techniques. A lot of stuff that is well documented in the Pharo ecosystem is old. A lot of the new stuff doesn't have great docs. Just reference docs and code is not enough. There has to be a coherent narrative around an API to put it together. Also, I'm all onboard having a UI environment for programming, but it needs to have great keybindings that follow platform HIGs, and at least my Pharo 10 experience of the window management was really bad. I wrote about this some https://nikhilism.com/post/2021/experiencing-smalltalk/ https://nikhilism.com/post/2021/experiencing-smalltalk/
- em-bee 2y ago
  i agree. here is a screencast i made: https://news.ycombinator.com/item?id=38995507 https://news.ycombinator.com/item?id=38995507 i don't know how much has changed since then. but if pharo has changed so much that this screencast can no longer be used then that's a problem in itself. we are not going to gwt more screencasts if their halflife is to short.

mark_l_watson 2y ago

I would like to disagree with you, but I can’t. Pharo, and Squeak that it is derivative from, is an odd development experience. A long time ago I experimented with making web apps with Pharo, fun, but I wouldn’t use it in production. When I saw this announcement I was motivated to update my Pharo NLP library https://github.com/mark-watson/nlp_smalltalk https://github.com/mark-watson/nlp_smalltalk but I may not. Many NLP tasks are now done infinitely better using deep learning and LLMs. I just looked for OpenAI API support and found 2 year old Pharo project library https://github.com/pharo-ai/open-ai https://github.com/pharo-ai/open-ai and maybe more promising 1 year old project by Bracken https://github.com/brackendev/OpenAI-Pharo https://github.com/brackendev/OpenAI-Pharo EDIT: to be fair to Pharo, I am not really a Smalltalk person. In 1983 someone at Xerox arranged for me to get a trial Smalltalk system on My Xerox 1108 Lisp Machine, and I removed it within a few weeks.

fizfaz 2y ago

> The sheer oddity + lack of real world example code floating around made it feel impenetrable not sure if I understand you, but you have the code of the whole system at your fingertips. Which is certainly "real world" because you are running it :)

em-bee 2y ago
real world example means end user applications, not developer tools. i want to see how an application looks like that my mother could use, or that i could sell to my customer. websites. desktop applications that hide the IDE...
- igouy 2y ago
  Your applications would look however you wanted them look. https://pharo.org/success/ https://pharo.org/success/
  - em-bee 2y ago
    that's not the question. we are looking for examples that come with source that can be studied. the success page lists 53 projects. only one of them came with a direct link to the source. one included an un-clickable link. one linked to a non-english website where i could figure out that it was licensed under the LGPL, but i could not find the link to the source. a surprise was that DrGeo which is known to be Free Software links to a dead website. grafoscopio which i also believe to be FOSS as well has a dead download link on its website. several other projects had dead links too. the only source i found was for HoneyGinger: https://github.com/tomooda/HoneyGinger https://github.com/tomooda/HoneyGinger OpenPonk https://github.com/OpenPonk https://github.com/OpenPonk and record: https://github.com/estebanlm/record https://github.com/estebanlm/record (7 years old) btw, DrGeo is here: https://github.com/hilaire/drgeo https://github.com/hilaire/drgeo that is three source examples under active development for a project as old and as large as pharo is that is surprisingly little. more accessible source examples are needed to attract developers. especially given the difficulty to get used to the pharo developer tools. i have actively explored working with pharo. i just could not find any useful apps that i could use and contribute to. and i had no ideas for an app that i'd be interested enough to create from scratch. for a while i even tried to use it as a desktop and used an app that provides a commandline inside pharo. the primary problem was that upgrading to a new version of pharo each year was difficult. given the image based development you tend to start with a current version of pharo and then keep to that version until you are done.

znpy 2y ago

I had the same experience. Spent a couple of (vacation) weeks devoting 2-3 hours a day to Pharo and going through all of one of the books from the website (Pharo by example? can't really remember). It's really one of those things that will die out on their own, because of the many layers and the little applicability (outside of playing the gimmicks).

peatmoss 2y ago

Squeak / Pharo are alternate timeline technologies. Maybe the one where Betamax won and Al Gore read the intelligence briefing. Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes. Rust is radical in some ways, but it's fundamentally a creature of the vaguely Unixy paradigm we all live in today. I miss the weird world of possibilities we used to have.

charlysl 2y ago
> Al Gore read the intelligence briefing. Wasn't that George W. Bush?
- cess11 2y ago
  Not in the alternate timeline.
  - charlysl 2y ago
    Ha ha, I see, nice
derefr 2y ago
> Their lineage goes back to the Alto when people were imagining what interacting with computers even meant, and what metaphors from the real world make sense to apply to collections of bytes. I would argue that this lineage of computing isn't as arcane and out-of-reach as people might think. Much of the "obvious" promise of Smalltalk / object-based runtime environments — specifically, all the UI stuff it enabled — was too expensive / high-overhead initially, for it to have much penetration in the microcomputer or the mainframe/batch processing space; thus relegating those specific ideas to academic experiments in workstation productivity. But fancy object-based UIs weren't the whole of what this lineage of computing was about. Microcomputer and mainframe systems were built as descendants of this lineage, repeatedly, and many of them were even in common use; but it might be harder to recognize them as such. It's the less-obvious, more low-level/internal architectural things they inherited. If you ignore the specific assumption of a UI or "strict" OOP, and instead just consider this lineage as anything fitting these criteria: 1. systems that booted into a live runtime bytecode VM, usually de-hibernating the VM state from a memory image; 2. and then exposing a shell that was more of a REPL than a command language, allowing interoperation with the data that defined the state of the VM on a high level, 3. where the "operating system" within the runtime is fully exposed to you (rather than being a black box with a whitelisted FFI API); but where each data structure within that "operating system" is protected due to the common runtime of the OS + userland, enforcing ADT-defintion-time abstraction layers in the way it allows clients (including the REPL) to interact with any given object/ADT... ...then you could say that all of the following are part of the lineage: • BASIC — especially the BASICs on microcomputers that booted to BASIC, or had BASIC on ROM, and never ran DOS (published software for these computers, was usually just precompiled BASIC bytecode!) • Object Pascal / Delphi • Emacs • most SQL databases, but especially Ingress • MOOs (object-oriented MUDs) • Plan 9, despite its Unix roots. (Especially applicable insofar as you could consider "a runtime and OS as toolkit, and applications as LEGO with clear exposed seams that the user can pick apart and remix" an additional criterion.) You can usually recognize these systems, because there's no way to get anything like a machine-code monitor / debugger on them; instead, the runtime itself usually exposes bytecode-level (or interpreter-level) monitoring / debugging, in a way that doesn't allow you to break the runtime's assumptions through it.

cess11 2y ago

Others have linked to the book collection, there you'll find walkthroughs of the basics, building web applications, tracking code in git, and so on. A lot of the common packages also have examples bundled that you can play around with and read documentation in. Once one gets over the initial hurdle of the syntax, message passing and how to use the GUI to create new projects and objects one can usually just surf around in the image and look for examples to figure things out.

agumonkey 2y ago

Without an online course or a mentor I'd be lost too. But you only need a two hour introduction to have fun IMO.

guessbest 2y ago

How would you compare this to say, writing WinForm applications in Visual Basic 6?