[HN Gopher] Pharo 12
___________________________________________________________________
Pharo 12
Author : xkriva11
Score : 192 points
Date : 2024-04-26 10:41 UTC (12 hours ago)
(HTM) web link (pharo.org)
(TXT) w3m dump (pharo.org)
| peter_d_sherman wrote:
| Related:
|
| Pharo Syntax in a Nutshell:
|
| http://rmod-pharo-mooc.lille.inria.fr/MOOC/PharoMOOC/Week1/C...
|
| https://en.wikipedia.org/wiki/Pharo
|
| >"Pharo is an open source, cross-platform implementation of the
| classic Smalltalk-80 programming language and runtime.[3]"
|
| https://en.wikipedia.org/wiki/Smalltalk
| anilakar wrote:
| Syntax is the easy part.
|
| The real difficulty is in trying to make sense of the whole
| ecosystem, including the strange runtime-IDE-hybrid approach.
| elviejo wrote:
| Just imagine that is:
|
| - docker image - vscode preibstalled - and everything used
| the same programming language.
| twixfel wrote:
| Yes last time I checked they had their own versioning system
| as well... it's one thing to learn a language but having to
| learn a whole new set of tools put me off in the end. I guess
| I can see the argument that the Smalltalk files are not plain
| text but rather images (or something), but having to
| basically download a second OS within the OS just to write
| Hello World was off putting. I realise that that's also can
| make Smalltalk so powerful, at least in principle.
|
| Also lack of retina display support put me off. Of course it
| is purely cosmetic but when it's literally the only app I
| used that looks like shit, it is sufficient to nudge me away.
| Maybe fixed now, not sure.
| igouy wrote:
| > to learn a whole new set of tools
|
| The tools are how we find functionality that can be re-used
| and re-purposed to do what we need. A lot of exploring and
| reading existing stuff, less writing new stuff.
|
| > Smalltalk files are not plain text but rather images (or
| something)
|
| Mostly Smalltalk files are plain text files!
|
| There's a plain text log file with a replayable record of
| what you've been doing. There's a sources file with the
| source code. There are plain text file outs and change
| sets.
|
| There's the VM like the JVM -- not a plain text file.
|
| There's the image, a cache of byte code (like Java .class
| files, Python .pyc files) and application state -- not a
| plain text file.
|
| With a previous Pharo version: $
| bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image
| hello.st
|
| pharo is the VM.
|
| Pharo10-SNAPSHOT-64bit-502addc.image is the image.
|
| hello.st is a plain text file. $ cat
| hello.st Stdio stdout nextPutAll:
| 'hello world'; nextPut: Character lf.!
| SmalltalkImage current snapshot: false andQuit: true!
| twixfel wrote:
| That's fine, I understand that a lot of my criticisms are
| arguably actually advantages, but after doing the MOOC
| about 8 years ago I just couldn't stick with it. Fun
| though, and a great way to really learn OOP at the time
| when I was just starting out programming.
| igouy wrote:
| That's fine, people have some strange ideas about
| Smalltalk, both +ve & -ve.
| alexisread wrote:
| Funnily enough, I'd compare the image and versioning
| differences to managing Postgres rather than non-image
| based languages.
|
| Postgres has to deal with images (backups) and versions
| (migrations). Maybe selling image-based systems in both
| cases needs a little work or formalisation (best practices
| and all that)?
|
| Image-based systems seem more about data management rather
| than code management. Just some random thoughts
| orthoxerox wrote:
| Is not calling it a Smalltalk implementation still a marketing
| decision, or has Pharo diverged sufficiently from Smalltalk-80 to
| become incompatible?
| pjmlp wrote:
| One thing that comes to mind is that Smalltalk-80 doesn't do
| traits, or the UI is completly different.
| xkriva11 wrote:
| +Traits, +Slots, different class definition syntax and its
| processing, different file API, full block closures, different
| source file syntax, ByteArray literals, different comments
| syntax, many differences in the standard and UI library, etc.
| No, Pharo is not Smalltalk-80.
| igouy wrote:
| I think incompatible Smalltalk implementations were one of
| the bigger barriers to Smalltalk adoption. In contrast, Java
| standard libraries have been a huge benefit.
| Decabytes wrote:
| How does Pharo compare to Squeak? I'm interested in doing more
| with Smalltalks but Pharo just does not play nice on Fedora 40
| with Wayland right now
| no_time wrote:
| 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 wrote:
| You can try to look at Rosetta Code if you want examples.
| krylon wrote:
| 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/
| 0x445442 wrote:
| 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 wrote:
| "Quick-UI-Tour"
|
| https://github.com/Cuis-Smalltalk/Learning-
| Cuis/blob/master/...
|
| "The Cuis Book"
|
| https://cuis-smalltalk.github.io/TheCuisBook/
| andsoitis wrote:
| 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//
| 0x445442 wrote:
| 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.
| selykg wrote:
| 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.
| xkriva11 wrote:
| This is a complex issue. In fact, you can work with Pharo
| in a Unix-like manner. Use an external editor to modify the
| source code and run the image without any GUI. However, by
| doing so, you lose the most interesting and enriching
| aspects of it. The Pharo team has worked hard to integrate
| better with the world outside the Pharo image. People still
| complain that it is not like anything else they know, but
| if it were, they would miss the opportunity to learn how to
| do things differently and possibly better. There is also a
| lot of excellent documentation available, especially the
| MOOC, but it requires newcomers to invest some time.
| selykg wrote:
| That totally makes sense. I'm not saying there aren't
| advantages to what is being done, but what is being done
| does add a level of complexity to it all.
|
| I think there is a valid reason for tools like Pharo to
| exist, I don't know the answer to how to improve the
| situation outside of a (selfish) desire to see better
| beginner documentation that talks about using it for
| people that have zero knowledge of Pharo and similar
| tools. Explain it like I'm 5 type stuff. I suspect it all
| becomes easier once the general primitives are explained
| but until they are there's an inscrutability to it.
| Qem wrote:
| 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/
|
| Also there's lots of free books at https://books.pharo.org/
| melvinroest wrote:
| 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
|
| [2] https://esug.org
|
| [3] https://days.pharo.org
|
| [4] https://discord.gg/QewZMZa
|
| [5] https://pharo.org/community
| nsm wrote:
| 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/
| em-bee wrote:
| i agree. here is a screencast i made:
| 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.
| azinman2 wrote:
| Looking over the syntax, it seems that lines end with a
| period, much like in English. This makes much more sense
| than semicolon!
|
| That said, it looks like you end up with a million
| windows to do anything. Seems like the UI could be better
| UX'd, no? Guessing this a community that would treat such
| a comment as harassment.
| em-bee wrote:
| why would it be considered harassment? it's not like your
| comment is any more critical than many of the others
| here.
|
| as for the million windows, if you go that from my
| videos, then i'd like to point out that the interface has
| indeed improved since. for one it added the ability to
| group windows with tabs: https://youtu.be/GGJZeajjWGU?lis
| t=PLqbtQ7OkSta0ULYAd7Qdxof85...
|
| (interestingly, that video is older than mine, so it
| seems that i just hadn't discovered this feature yet)
| batman-farts wrote:
| My initial burst of enthusiasm was dampened by the big gap
| between the entry-level introductions (ProfStef tutorial, the
| introductory MOOC) and the sheer complexity of everything the
| image includes. I'm not a big-time Java developer, I
| certainly appreciate the elegance of the language and dev
| environment compared to, say, Python, but that huge list of
| packages and their Baselines in the left pane of the system
| browser makes it really difficult to tell where to get
| started. I attended an online Smalltalk meetup recently, and
| one of the veteran Smalltalkers there was preferentially
| rebasing his code on Cuis because he felt Pharo had become
| too heavyweight.
|
| I also fear that leaning so heavily on a closed, corporate
| platform like Discord as the community hub may lead to tears
| in a few years. If you're leaning into the idea that "the
| community is the documentation," you're at Discord's mercy
| for community sustainment, on top of the already hairy
| problem of surfacing solutions from within the depths of a
| long-running discussion forum. Sure, running everything off
| of mailing lists + IRC like older open source projects do
| would be a clear step backwards, but being stuck with Discord
| has been a mild turn-off for me.
|
| Finally, it's worth noting that development is spearheaded by
| folks in France and Latin America for whom English may not be
| their primary language. That doesn't affect their ability to
| do good work! It's totally worth reflecting on how something
| attempting to approximate natural-language programming in
| English ended up forked outside the Anglosphere! But I also
| feel like it'd be worth having an editor take a cleanup pass
| at future versions of the main ebooks. I've got both the
| books that Alexandre Bergel published through Apress, and
| they're both solid, but if the first-resort resources were up
| to the same standard, I think perhaps fewer people would come
| away with an unfavorable impression. Of course, that's over
| and above simply keeping them up to date as development
| progresses - I believe Pharo by Example is still on version
| 9?
| cess11 wrote:
| Start with the Finder and the Examples-category if you want
| to know how to do something, don't browse the full package
| list in the hope you'll stumble over something useful.
|
| There are small communities outside the Discord having
| meetups and whatnot. Would probably be nice to have a
| Discourse-instance for a more documentation-like meeting
| place, but that requires money and volunteers doing
| moderation.
|
| I enjoy that some docs and other resources aren't expressed
| in US:ian advertising lingo. It's not a bug, it's a
| feature.
| mark_l_watson wrote:
| 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 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 and maybe
| more promising 1 year old project by Bracken
| 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 wrote:
| > 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 wrote:
| 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...
| znpy wrote:
| 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 wrote:
| 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 wrote:
| > Al Gore read the intelligence briefing.
|
| Wasn't that George W. Bush?
| cess11 wrote:
| Not in the alternate timeline.
| charlysl wrote:
| Ha ha, I see, nice
| derefr wrote:
| > 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.
| cmrdporcupine wrote:
| Don't threaten me with a good time!
|
| And I still to this day enjoy combining your #3 (emacs)
| with your #5 (MOO) via e.g.
| https://github.com/toddsundsted/rmoo
|
| You might appreciate my project:
| https://github.com/rdaum/moor
|
| (Though it's in a bit of a slow period because of Real
| Life(tm))
| jdougan wrote:
| Also Inferno on DisVM, various Forths, and modern web
| browsers (especially running Lively JS)
| cess11 wrote:
| 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.
| dmpk2k wrote:
| Is any thought being put into adding parallelism in the future?
| andsoitis wrote:
| No, but you can do concurrent programming in Pharo:
| https://books.pharo.org/booklet-ConcurrentProgramming/pdf/Co...
| ginko wrote:
| So the entire dev environment and any programs you have
| running in it only uses a single thread?
| andsoitis wrote:
| Pharo uses green threads https://www.pharo.org/features
|
| https://en.wikipedia.org/wiki/Green_thread
| batman-farts wrote:
| https://github.com/smarr/RoarVM is the main thing that comes up
| when trying to learn about this, and it hasn't been touched in
| over 10 years. I have also seen people working on spawning
| child VMs to handle parallelism, though unfortunately I don't
| have links to those discussions immediately at hand. It seems
| like perhaps an unnecessarily heavyweight approach, too, not a
| canonical solution that you would want to use in production.
|
| I assume that step 1 towards parallelism, at least on the image
| side, would be going through the class library and making sure
| everything is thread-safe. I'd love to know where one would
| even get started with that effort. The Roar project claims to
| support Pharo 1.2, which doesn't seem to be very far after they
| forked from Squeak, but obviously a lot has changed since then.
| And the challenge is that Pharo is still rapidly developing all
| the overhauled classes that distinguish it from Smalltalk-80.
|
| Meanwhile, if I want to play with parallel image/REPL-based
| programming, I can go over to Common Lisp and, while lacking an
| equally coherent GUI, be able to load up bordeaux-threads and
| off I go.
| germandiago wrote:
| Great idea but not pragmatic enough. I did try.
| tasuki wrote:
| In what way is it not pragmatic?
|
| I don't know Pharo at all, but "not pragmatic" often means just
| "too different from what I'm used to"...
| throwaway918274 wrote:
| 7 minutes of Pharo smalltalk for Rubyists:
| https://youtu.be/HOuZyOKa91o
|
| Is a pretty good overview how the environment works.
| krmboya wrote:
| Many comments in the vein that pharo is weird and different from
| what they're used to. I'd say programming is such a young field
| programmers should dedicate time to try out the weird stuff that
| they aren't used to, opportunities to rewire your brain for
| better.
|
| Let's not get stuck in a local minima on how to do programming.
| There could be better ways not yet popular enough. Smalltalk came
| out of an environment of innovations that were ahead of their
| time.
|
| EDIT: while doing the Pharo mooc, I was able to create a DSL for
| what I understand to be D&D dice representation without using
| special metaprogramming syntax of the language or parsing and
| tokenizing strings. Just plain old OOP of the Smalltalk/Pharo
| flavour. This were just basics btw
| igouy wrote:
| Smalltalk had a moment at the transition from green screen to
| PC's, fumbled the everything is a string internet, and never
| showed-up for the multicore + GPU party.
|
| Meanwhile the nasty statically type checked languages lowered
| the pain level with non-nullable and type inference for local
| vars.
| cess11 wrote:
| Pretty sure Pharo has had GPU-support for a long time, and
| there's RoarVM for "manycore" applications in Smalltalk.
| igouy wrote:
| > Pharo has had GPU-support for a long time
|
| For highly parallel general-purpose computations? Tell us
| more!
|
| https://chapel-lang.org/docs/technotes/gpu.html
|
| As-already stated in this discussion RoarVM "hasn't been
| touched in over 10 years". This discussion is about the
| Pharo 12 release and supposedly RoarVM is "compatible with
| Squeak 4.1 and Pharo 1.2 ".
|
| https://github.com/smarr/RoarVM
| kingspact wrote:
| I don't like Pharo because they changed it too radically from
| Squeak, which I _DO_ like very much.
| wk_end wrote:
| As a curious outsider - what are the key differences between
| Squeak and Pharo that make it worse in your eyes?
| anothername12 wrote:
| Man the responses here are most interesting. So many people in
| _hacker_ news complaining about its "unconventional" approach,
| the perceived inconveniences of it, or how it wouldn't be useful
| in corporate environments.
|
| It's like listening to a bunch on middle managers deciding on the
| tech platform rather than bunch of hackers contemplating the
| possibilities.
| pvg wrote:
| _Please don 't sneer, including at the rest of the community._
|
| https://news.ycombinator.com/newsguidelines.html
| john1203 wrote:
| It seems too research-oriented programming IDE+language, where
| there is not a big market compared to other areas.
|
| Who does Pharo want to compete with? Maybe developers think they
| shouldn't compete with other platforms? With the amount of real
| Pharo apps right now even on GitHub, it would be extremely
| difficult to "sell" Pharo to any decision maker.
| cess11 wrote:
| Why would that be hard? Once you're fluent in it development in
| Pharo is very, very fast, you can build a GUI application while
| a prospect or customer is watching and supplying inputs about
| what they need.
|
| Many companies that buy software don't care about programming
| languages, they care about functionality and price. With Pharo
| you can show them immediately what the application could look
| like and how their processes could be implemented. Fast
| development means you can sell at a lower price and reach
| customers that can't afford more 'classic enterprise'. You can
| also reach customers that do work in quickly changing
| regulatory environments, like insurance.
|
| When you've banged out the frontend and some logic you return
| to your office and figure out things like database schema.
|
| Pharo is specifically designed for commercial and industrial
| applications and not as a research environment. Partnering with
| private capital has been one source of funding for the project.
| sigzero wrote:
| Smalltalk is one of those "I'd like to learn" but haven't found a
| good resource that I like (oh and the time, sigh).
| mifa201 wrote:
| I started a new job in Smalltalk one year ago without any
| previous experience with the language (background in Scheme, a
| bit of Common Lisp / Clojure, C, C++, Java, Python, Haskell and a
| couple of other languages). I had three pair programming sessions
| in the beginning and that was it, it took me one month to get a
| grasp of the codebase I have to maintain/develop further. The
| application is huge, but the tooling and discoverability of the
| programming environment (including best debugging experience I've
| ever seen) made it super easy to dive into the system and learn
| everything practically by myself. This and the fact that
| everything follows the same basic design principles (objects all
| the way down) make it a perfect match for solving complex
| problems.
|
| Honestly my experience at work was mostly with Visualworks. But
| I've been using Pharo in two side projects and I'm loving it. It
| became one of my top 3 programming languages I've ever used
| (together with Scheme and CL). It's impressive how much this
| rather small community achieved, thanks for the awesome work and
| this new release!
___________________________________________________________________
(page generated 2024-04-26 23:01 UTC)