[HN Gopher] Pharo 10
___________________________________________________________________
Pharo 10
Author : xkriva11
Score : 177 points
Date : 2022-04-05 10:52 UTC (12 hours ago)
(HTM) web link (pharo.org)
(TXT) w3m dump (pharo.org)
| selykg wrote:
| What are some good resources for learning to develop using Pharo?
| Anything others would recommend?
| fmakunbound wrote:
| There's a ton of practical Pharo books here
| https://books.pharo.org and Smalltalk books here
| http://stephane.ducasse.free.fr/FreeBooks.html
| Qem wrote:
| There's a MOOC[1] on it, and there are several free books that
| cover the basics of the language itself[2][3], data
| visualisation[4] and numeric stuff[5]. The only issue is, as it
| is developed at a fast pace, documentation tends to get a bit
| dated quickly. [1]. https://mooc.pharo.org/ [2].
| https://github.com/SquareBracketAssociates/PharoByExample9/r...
| [3]. https://books.pharo.org/deep-into-pharo/ [4].
| http://agilevisualization.com/ [5].
| https://books.pharo.org/numerical-methods/
| indigochill wrote:
| IMO the better approach, given how dynamic and fast-moving
| development is, is to put this kind of information directly
| into the image. Pharo even already has a mechanism for
| authoring tutorials and it has an example tutorial using that
| mechanism, but I wish there was just more to that content
| that covered the material in the books/MOOC.
|
| The reason is then hopefully the documentation stays aligned
| with the state of the particular image you're working with
| rather than hoping some volunteer has updated a book for the
| particular version of Pharo you're using.
|
| I took a stab at doing this myself, but I was learning as I
| went and eventually ran out of gas since writing Pharo
| tutorials didn't beat other stuff on my personal priority
| list.
| xkriva11 wrote:
| This is a list of quite rare features that make Pharo
| interesting: https://pharo.org/features
| cout wrote:
| That is a good introduction to what makes pharo appealing.
|
| It sounds a lot like Smalltalk though. Do you know of a similar
| page that highlights the differences between pharo and
| Smalltalk?
| Jtsummers wrote:
| Pharo follows from Smalltalk, particularly through Squeak. It
| started off as a fork of Squeak and retains Smalltalk's
| syntax, but has gone its own way in terms of the capabilities
| it provides and rewriting portions.
| brandonbloom wrote:
| This page is great!
|
| If any Pharo folks are reading this, here's a small website
| feature request: Let me click on the images of this page to get
| full-resolution, un-cropped versions.
| Jeff_Brown wrote:
| Wow. The density of ideas I've never heard of before on that
| page is high.
| Qem wrote:
| Pharo and Smalltalk in general always remind me of that
| famous William Gibson quote: "The future is already here--
| It's just not very evenly distributed".
| ok123456 wrote:
| I went through the MOOC material and tried it out for a few small
| things. It inherited a lot of the unique Smalltalk features which
| make it sort of alienating to a modern programmer. For instance,
| all your code resides in an image file, and if you want a copy of
| your code the environment does some extra epicycles to copy it
| outside. The choice to make everything a message, including basic
| flow control takes some getting used to. As you just sort of hack
| your image to do what you want, it just sort of turns into a ball
| of mud. The paradigm they're going for is TDD for everything.
| Personally, I feel this is a big step backwards from most
| mainstream scripting languages adding on type annotations. It's
| not easy to use a simple text editor. You pretty much have to use
| their integrated environment.
|
| Then, there were a few problems that were specific to Pharo.
| Pharo went through a couple different package systems and the
| different package systems don't necessarily have the same
| packages. Pharo has had major breaking changes in their GUI
| toolkit, so if you found a package that did exactly what you
| wanted and were able to install it, it just wouldn't work.
| fmakunbound wrote:
| > a copy of your code the environment does some extra epicycles
| to copy it outside
|
| Iceberg https://github.com/pharo-vcs/iceberg is the Git/etc.
| integration built into Pharo and works extremely well. You
| don't need to "file out" code if that's what you meant.
| scotty79 wrote:
| Do you have any examples of Pharo github repositories created
| with Iceberg? What do they even contain? Does Pharo even have
| a notion of source file?
| kencausey wrote:
| The github link in the comment above is one such example.
| scotty79 wrote:
| On the screens in Getting started tutorial I found this:
| https://github.com/pharo-spec/Spec
| igouy wrote:
| > Does Pharo even have a notion of source file?
|
| Same as other Smalltalk implementations -- VM + .image file
| & .sources file & .changes file.
|
| .image is a snapshot/cache
|
| .changes is recovery log text of what has been done with
| the .image file
|
| .sources is source code text for the .image smapshot
| igouy wrote:
| > As you just sort of hack your image to do what you want, it
| just sort of turns into a ball of mud.
|
| No, it doesn't just turn into a ball of mud all-by-itself.
|
| As you said, we can export our app code and bake a new working
| image (vendor image + our app code -- kind-of like a container,
| kind-of like a reproducible development process.)
| gjvc wrote:
| > The paradigm they're going for is TDD for everything.
|
| Smalltalk _facilitated_ Kent Beck 's invention of TDD.
| mark_l_watson wrote:
| As a very long time occasional Smalltalk user (on my 1108 Lisp
| Machine, Commercial on early Mac, later Squeak, then Pharo), I
| agree with you, except that Pharo has nice git integration that
| I can recommend spending the time to set up.
|
| Also, I used to create Squeak headless standalone applications
| - plenty of tutorial material for this.
|
| Lisp used to get a similar bad rap, but SBCL has good app
| packaging available and the commercial LispWorks makes it easy
| to build small standalone apps.
| zelphirkalt wrote:
| For version control they have Iceberg, which should allow you
| to use git for your projects. It doesn't have to be all in an
| image.
| andjd wrote:
| This is kinda the point of smalltalk. It's a radically
| different programming model _and_ paradigm than most C-derived
| languages. If you're looking for a language that feels
| comfortable to developers with a background in [insert widely-
| deployed language here], there are better options for you.
|
| Smalltalk has been around for over 40 years, which makes it a
| contemporary to C. Just like FORTRAN or COBOL, there's a corpus
| of deployed code, and institutions that are invested in a
| maintained runtime, but that dosen't mean that you would
| necessarily want to use it for a new project today.
|
| A lot of the great things about smalltalk, such as block syntax
| for anonymous functions, have been copied into many modern
| programming languages, and we probably wouldn't have them
| without smalltalk taking it's unconventional approach.
|
| > The paradigm they're going for is TDD for everything.
| Personally, I feel this is a big step backwards from most
| mainstream scripting languages adding on type annotations.
|
| So, the push to add types to JS, Python, Ruby and other dynamic
| languages is largely from developers accustomed to Java,
| C-Sharp, and other enterprisy languages who would probably
| rather not work in a dynamic language at all. Put another way,
| it's a concession of these languages to try and be everything
| for everyone. But statically typed complied languages do not
| provide an inherently better programming paradigm than dynamic
| programming. Smalltalk commits further and deeper to a live,
| dynamic programming experience. It's different, and I don't
| feel like saying that it fails to conform to expectations
| brought in from other, very different programming paradigms is
| a meaningful criticism of the language.
| theamk wrote:
| > So, the push to add types to JS, Python, Ruby and other
| dynamic languages is largely from developers accustomed to
| Java, C-Sharp, and other enterprisy languages ...
|
| Nope, this is not true. I am personally pushing to add types
| to our Python codebase, and I have no love for "Java, C-Sharp
| and other enterprisy languages".
|
| It's just that as the codebase grows, and especially as
| number of contributors grows, people start to make more
| mistakes. A rarely used code path, like an error handler,
| might fail in production because of wrong type or missing
| argument. We can require unit tests with 100% coverage, but
| this is very hard -- and typing linter finds you many more
| bugs per effort spent.
|
| That does not mean that we should always specify every type
| in program explicitly, like Java does. Unspecified types are
| great for interactive exploration, or a quick hack. But as
| you move to production, don't understimate typecheckers --
| they can help a lot.
| ok123456 wrote:
| This is pretty much my feeling. I'm not adding types
| because I have some kind of brain rot that makes me need
| AbstractFactoryBeanContainerAnnotationFactory. I like
| adding type annotation because it means you can do static
| analysis on your code base. Without it, you need exhaustive
| coverage tests to demonstrate what exactly can be returned.
| cxr wrote:
| > That does not mean that we should always specify every
| type in program explicitly, like Java does. Unspecified
| types are great for interactive exploration, or a quick
| hack.
|
| It's also helpful to consider whether they constitute
| unnecessary requirements[1]. Most mainstream JS code is
| rife with problems like this--including rampant mis-/over-
| use of triple equals. (I call this "going out of your way
| to do the wrong thing".)
|
| 1. https://www.teamten.com/lawrence/programming/dont-
| invent-unn...
| wirrbel wrote:
| > the push to add types to JS, Python, Ruby and other dynamic
| languages is largely from developers accustomed to Java,
| C-Sharp, and other enterprisy languages who would probably
| rather not work in a dynamic language at all
|
| I recall Guido van Rossum stating once, that he got convinced
| of the necessity for type annotations by JetBrains explaining
| to him how hard it was to provide good code completion. Not
| sure its the full answer, but back then I found it
| interesting as an example how lobbying can work.
|
| (I feel rather indifferent on the type annotations for Python
| actually, I can see their usefulness, but also the
| shortcomings of retroactively introducing such a system into
| a dynamically typed language).
| cout wrote:
| Typically in Ruby (which is heavily Smalltalk-influenced)
| we do ad-hoc type annotations anyway and call it
| documentation.
|
| So you've got the camp that favors type annotations for
| various reasons and the camp that is opposed. There is also
| a third camp: the DBC (design by contract) camp. Their
| argument is that type annotations don't go far enough and
| that's what you really need is to enforce preconditions and
| postconditions. While I see their point, I think DBC lacks
| a "killer app" -- which as you pointed out, for type
| annotations, is static analysis (which leads to tools like
| code completion, refactoring browsers, performance
| improvements, and more).
| svc wrote:
| Congrats !
| wslh wrote:
| Is there an updated Pharo native Wiki like:
| https://wiki.squeak.org/squeak
| kkfx wrote:
| SmallTalk as a language is IMVHO terrible BUT it's strength came
| from it's concept, an user-programmable environment, that's
| matter so much.
|
| SmallTalk was the language of first commercial desktop
| environments, modern desktops with keyboard, mouse, a similar
| form factor than today desktop, networking etc and those
| historical systems are still far more advanced than today's ones.
|
| Personally I prefer Lisp as a base language, but in any case the
| concept is far more important than the rest. A thing humanity
| lost years ago and that need to recover ASAP.
| rileyphone wrote:
| For reference:
| http://augmentingcognition.com/assets/Kay1977.pdf. Modern
| Smalltalk is quite different from Smalltalk-76, to the chagrin
| of Kay.
|
| I agree on the Lisp part, textual syntax is nice for human
| understanding but will one day be no longer necessary. If only
| they had made a cheap Lisp machine!
| sebastianconcpt wrote:
| I find preferences-wars a source of evil. Lisp is fine, not the
| subject here, tho.
|
| Back to the subject, Smalltalk's syntax allows the most elegant
| expression of computer code similar to natural written language
| I've seen. And that at the lowest cognitive load to learn and
| read that the computer world provided so far.
|
| I'm with you about raising the importance on concepts and that
| humanity needs to rescue its capacity for making that relevant
| again. I'm afraid Post-modernism is liquifying intelligence and
| is making everything regarding to intelligence to be harder to
| flourish.
|
| PS:
|
| We use a lot of camel case but please remember it's _Smalltalk_
| (instead of SmallTalk).
| butterisgood wrote:
| Nice release! And yes, for a short iteration, there's a lot of
| good stuff in there!
|
| Congrats!
| ramesh31 wrote:
| Who's using Pharo in production? Every time Smalltalk comes up,
| it's almost like it's this Loch Ness monster that everyone claims
| to be enamored with but doesn't actually exist. I _want_ to love
| Pharo so much, I just can 't think of a single thing it would be
| useful for.
| Kototama wrote:
| Please don't let the _hacker_ in hackernews fads away. We need
| alternative technologies. These alternatives should not be
| judged on one singe metric.
| ilrwbwrkhv wrote:
| Hacker News has become mainstream. Which means leet code
| grind with Java Python or JavaScript. The hackers are still
| here. But they are just a minority.
| tormeh wrote:
| HN is owned by Y Combinator. It's at least as much a tech
| finance/industry board as a pure tech board.
| andrewl wrote:
| I've heard there's a lot of Smalltalk (not necessarily Pharo)
| used on Wall Street. There's a fairly extensive page listing
| companies who use Pharo at:
|
| https://pharo.org/success.html
| sebastianconcpt wrote:
| Telna [1] is using Pharo to resolve roaming for an incredible
| amount of daily network traffic. I'm in their dev team.
|
| Here you have may others using it in production:
| https://pharo.org/success.html
|
| [1] https://www.telna.com
| theamk wrote:
| This is super interesting! Do you have more information about
| this?
|
| - How many developers are working on that codebase
| simultaneously?
|
| - What is your workflow like? Do you have any sort of CI
| system? How does it work?
|
| - How does your deployment works? Is it a single beefy
| machine or a fleet of smaller ones?
|
| - What kind of network protocols do you use? Any code
| generation?
|
| - How do you deal with errors -- are there equivalents of
| "coredumps" or "logs" in the Pharo world?
| sebastianconcpt wrote:
| Yes, in the Pharo world there are coredumps, logs,
| serialization of the context of the exception (so you can
| open a debugger later from another host and see the
| messages walkback and inspect the values of all objects and
| its instvars on any step of that wallback), also I've made
| a RESTful REPL [1] to interact live with headless images
| and I'm _cough_ secretly working in websocket based IDE.
|
| For the rest I can tell you that:
|
| - The CI doens't have anything special in it, just build
| and delivers, after many categories of tests, a docker
| image with the app ready for production.
|
| - Iceberg for a shared repo. Devs usually use one fresh
| image per new branch to work on. Flow is reasonably
| approximated to git-flow.
|
| - The app is generally architected as stateless as it can
| be so it can enjoy undefined horizontal scaling capacity.
|
| [1] https://github.com/sebastianconcept/REPLEndpoint
| igouy wrote:
| > websocket based IDE
|
| ? Like Resilient Smalltalk
|
| https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1
| .84...
| igouy wrote:
| Curious -- Why not Erlang?
| sebastianconcpt wrote:
| The GTP client that touches Pharo is done in Erlang.
| igouy wrote:
| So Pharo for the front-end?
| sebastianconcpt wrote:
| Pharo runs in the backend for resolving roaming for SS7,
| GTP and DIAMETER. It orchestrates _a lot_ in there in
| order to provide Network Virtualization [1]
|
| [1] https://www.telna.com/blog/why-virtualization-is-
| critical-to...
| igouy wrote:
| > I just can't think of a single thing it would be useful for.
|
| Have you wanted to love Pharo enough to install and use it?
| agumonkey wrote:
| around 2009 there were a few websites running on pharo object
| db IIRC
| butterisgood wrote:
| Why does knowing who else is using something have any impact on
| your ability to love it? Sounds like it's just a motivation
| problem perhaps?
|
| For example, I make use of Plan 9 daily, and I don't really
| give a whip if anyone else thinks it's worth anything at all.
|
| I also use Emacs lisp in pretty strange ways (automating
| workflows by cross-querying REST services in ways I used to do
| by hand). I've even demonstrated it for coworkers, and I think
| some of them may be using the same techniques, but I'm not
| sure, and I don't care. If they have questions about it, I'll
| answer them. If not, they can say "that guy's weird", and I'm
| totally fine with that.
|
| Outnerd the nerds I say! Let your freak flag fly!
|
| In all seriousness I encourage people to write some code. Play
| around! Share your experiences. It's good for you and everyone
| else to foster new ideas and be innovative. It's especially
| good if the technology in question is surrounded by a welcoming
| community. It provides an additional sense of belonging to
| something, and who knows you might just actually enjoy
| yourself!
|
| You've got the first spark of curiosity, now you've just got to
| stoke the flames, or not!
| ramesh31 wrote:
| >Why does knowing who else is using something have any impact
| on your ability to love it? Sounds like it's just a
| motivation problem perhaps?
|
| Not making a value judgement. I agree that it doesn't need
| any more reason to exist than for its own sake. But I'm just
| genuinely curious what advantages Pharo has that make it
| useful in a professional setting.
| rscho wrote:
| > what advantages Pharo has that make it useful in a
| professional setting.
|
| Pretty much, the ultimate quick-and-dirty prototyping
| engine, especially for GUI projects. In the sense that
| you're prototyping largely from scratch, not cobbling
| myriads of huge libs. So, ball of mud. Not brick wall.
| igouy wrote:
| Sculpting clay.
|
| Funny thing. Back-in-the-day Smalltalks were attractive
| because the source code was included to be studied and
| re-used (When that wasn't true of many other development
| tools).
| scotty79 wrote:
| > Why does knowing who else is using something have any
| impact on your ability to love it?
|
| It's easier to learn to love something if you see how other
| people love it.
| [deleted]
___________________________________________________________________
(page generated 2022-04-05 23:01 UTC)