[HN Gopher] Pharo 10
___________________________________________________________________
Pharo 10
Author : xkriva11
Score : 287 points
Date : 2022-04-05 10:52 UTC (1 days ago)
(HTM) web link (pharo.org)
(TXT) w3m dump (pharo.org)
| travisgriggs wrote:
| Congratulations to all the Pharo folks. It's good to see a number
| of names in the contributors list that I still recognize. I
| really impressed that Pharo has maintained ground this long.
|
| This coming June, it will be 10 years since I jumped out of the
| Smalltalk balloon, and dedicated myself to embracing polyglotism,
| right tool for right job, pragmatism, etc.
|
| I miss the community. I miss many of the elegant aspects of
| Smalltalk. Maybe, since it's release 10, and I've journeyed
| elsewhere for 10 years, I should give Pharo a spin. Any pointers
| for ye olde VisualWorks guru to get up to speed again?
|
| Or minor contributions to be made?
| VaxWithSex wrote:
| travisgriggs doIt.
| 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.
| musicale wrote:
| Rather misleading - and seemingly insulting to the people who
| created and use Smalltalk and Squeak - that it doesn't say
| "Smalltalk" (not to mention Squeak) anywhere on the front page.
|
| They should really give credit where credit is due; growing the
| Smalltalk community seems like a better idea rather than
| pretending it's something else and implying that Smalltalk is
| somehow something bad that they need to hide.
| 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
| galaxyLogic wrote:
| But, you wouldn't want to store the .sources or even
| .changes into git would you? The git-way is to have many
| small(ish) files so that you can merge them easily to
| another development branch. Having just 2 files in git
| doesn't seem to make sense.
|
| I don't know how Pharo does it but I could see that every
| class had its own source-file, committed to git ?
| igouy wrote:
| Sorry I don't have experience using Pharo with Git, so
| the best I can do is offer a book that Goole would have
| found --
|
| https://books.pharo.org/booklet-
| ManageCode/pdf/2020-05-12-Ma...
| urthor wrote:
| Don't think of it as trading source files.
|
| Think of it as version controlling a package of class
| definitions.
|
| The whole idea with Smalltalk and Pharo is that you don't
| have _files_.
|
| You have class definitions, and these are only version
| controlled in text files as a concession to the extreme
| populatity of GitHub.
|
| The answer is that each class definition should be seen
| as an atomic unit with its own version control history.
|
| Smalltalk/Pharo intrinsically doesn't focus on dealing
| with the Unix filesystem, because the Unix filesystem is
| what C deals with.
|
| And yes, the answer is Iceberg exports the package of
| class definitions as a text file.
| galaxyLogic wrote:
| > Don't think of it as trading source files. > Think of
| it as version controlling a package of class definitions.
|
| It is very useful to know whether I should load version 1
| or version 2, or 3 of a (whole) package if somebody tells
| me they have a new version of their great package.
|
| But main thing about git (and distributed version
| control) is not "trading source files". It is making
| changes by a distributed team to the same code-base and
| then being able to merge the changes made by multiple
| developers and having tools that help resolve conflicts
| between the different versions.
|
| You can and often have multiple git-repositories. So if
| multiple developers were working on a Smalltalk package
| it might make sense to create a git-repo for just that
| package. But if the only file is the package-file then
| "merging" doesn't make much sense because you can't
| combine files changed by one author with files changed by
| the other authors.
|
| So while I want to be able to 'control package versions"
| I also want to be able to "merge branches". And to
| support that it seems better to have many small files
| instead of a single big package file.
|
| I agree that Smalltalk should be able to do better than a
| typical git-application because it knows about the
| semantics of classes and methods. And I think Smalltalk
| "change-sets" are a great concept. So I'm just interested
| in how Pharo tries to solve the tension between big
| package files versus multiple developers working on small
| code-units at the same time.
| igouy wrote:
| > And I think Smalltalk "change-sets" are a great
| concept.
|
| That's from way back, Smalltalk in the mid-80s.
| page 462, Smalltalk-80 The Interactive Programming
| Environment https://rmod-files.lille.inria.f
| r/FreeBooks/TheInteractiveProgrammingEnv/TheInteractivePr
| ogrammingEnv.pdf
|
| Late-80s early-90s multiple developers might be using
| ENVY/Developer version control: https://
| www.google.com/books/edition/Mastering_ENVY_Developer/ld6
| E19QIMo4C?hl=en&gbpv=1&dq=envy+developer&printsec=frontco
| ver
| galaxyLogic wrote:
| Right. But Change-sets and Change-set browser are still a
| great concept. I wish other programming environments
| would support them. You see exactly the set of _changed
| objects_ you have changed or created, and can save them
| to a file and share that with others.
|
| One reason they work so well is that Smalltalk treats
| methods as objects, not just as functions defined in some
| file. So a change-set knows it contains specific versions
| of specific methods. That is not possible in a typical
| git-environment where the most we know about a change is
| that it consists of some specific lines changed in a
| specific file.
| scroot wrote:
| > One reason they work so well is that Smalltalk treats
| methods as objects, not just as functions defined in some
| file. So a change-set knows it contains specific versions
| of specific methods. That is not possible in a typical
| git-environment where the most we know about a change is
| that it consists of some specific lines changed in a
| specific file.
|
| People just coming to this might not realize that the
| Opensmalltalk-derived environments (Squeak, Pharo, etc)
| already had their own VCS system called Monticello, which
| worked pretty well once you understood the per-method
| diffs and how it was suited specifically to Smalltalk.
| The move to git -- Iceberg in Pharo and less so Squot for
| Squeak -- has left some of this behind in order to appeal
| to a broader base of orthodox programmers who might be
| otherwise scared off. It's kind of a shame.
| igouy wrote:
| Interesting perspective. Seems that I don't appreciate
| ChangeSet.
|
| I became accustomed to saving method changes and seeing a
| timestamped editions of that method; adding a version tag
| to what seemed like useful method editions; resolving any
| conflicts, then releasing a versioned method.
|
| I kind-of liked the early visibility that gave of what
| other people were doing.
| imtringued wrote:
| >You have class definitions, and these are only version
| controlled in text files as a concession to the extreme
| populatity of GitHub.
|
| What prevents the pharo guys from simply providing their
| own merge tool and letting git call it?
|
| The only remaining issue then is showing a file system
| tree and diffs out of the image e.g. a simple export that
| doesn't necessarily even have to be importable.
| xkriva11 wrote:
| You are missing some background. First, Pharo uses
| libgit2 and provides its own merging mechanism to this
| library. It understands the code much better than plain
| Git, so code merging usually has fewer conflicts.
|
| Second, for Pharo, the code (classes, methods...) are
| living objects. These objects are the working copy Pharo
| deals with. Not with the files. So it mostly works only
| with this object working copy + .git database. Another
| working copy of files (which other developers would use
| for editing, files outside of the .git directory) is just
| an additional source of problems and conflicts.
|
| Pharo has a nice Git integration, and they spent a lot of
| time on making it work really well. So it has functions
| like browsing the history of one particular method etc.
| You are discussing already solved problems.
| musicale wrote:
| > It inherited a lot of the unique Smalltalk features
|
| Because it is a version of Smalltalk.
| 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...
| johncolanduoni wrote:
| In what situation do you want the whole spectrum of `==`
| behavior in JS, other than possibly the `undefined ==
| null` case? I'd argue exercising any of the other type
| conversion cases like `1 == true` or implicit
| `valueOf/toString` makes the code much harder to
| understand.
| bayesian_horse wrote:
| Adding types to an overly complicated and unreadable
| javascript codebase helped me to make sure I understand it
| before I refactor it.
| Tozen wrote:
| Types exist for a reason. It's not a fad, it's a solution to
| various problems.
| hvidgaard wrote:
| > But statically typed complied languages do not provide an
| inherently better programming paradigm than dynamic
| programming.
|
| For any large long lived project with multiple contributors,
| statically type analysis definitely adds value by eliminating
| an entire class of errors at compile time.
| 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).
| blunte wrote:
| > I recall Guido van Rossum stating once
|
| There are so many ... interesting ... Python design choices
| that I'm not sure whether "Guido said" helps an argument or
| hurts it.
| 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).
| rbanffy wrote:
| > I think DBC lacks a "killer app"
|
| If Ariane 5 carried astronauts, it'd certainly be a
| killer app:
|
| https://ieeexplore.ieee.org/document/562936
| dgb23 wrote:
| One ,,killer app" for these is interactive programming
| with instrumentation and generative tests:
|
| https://clojure.org/guides/spec
| bmitc wrote:
| > 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.
|
| What a weird reason to decide type annotations are useful,
| but I suppose I am not surprised. And is that really even
| true? Code completion works fine with Elixir and ElixirLS
| in VS Code and is seemingly independent of whether
| typespecs are present or not.
| rbanffy wrote:
| Type annotations are there to help the user in figuring
| out what the parameters have to behave like, and, perhaps
| more importantly, for linters to help finding issues
| caused by mismatching the types.
|
| Invoking the .detonate() method on a pyrotechnic bolt is,
| usually, far more benign than invoking it on an instance
| of Warhead. You really want to make sure you don't pass a
| Warhead to the function you wanted to get only bolts. A
| linter will warn you about such possible mishaps.
| bmitc wrote:
| I understand how type annotations are useful for users
| and also for static analysis tools (called Dialyzer in
| Elixir/Erlang), which is exactly why I didn't see why
| code completion would be one's primary reason for wanting
| them. However, in Python's case with heavy use of OOP and
| dot notation, I suppose I could see it being beneficial
| if the tools pickup up type annotations for code
| completion (still not the primary reason though) as
| opposed to something like Elixir. In Elixir, types and
| modules are tightly coupled, which means user's being
| implicitly being aware of types and also code completion
| generally working without type annotations (which can be
| inferred by Dialyzer anyway).
|
| So your comment actually backs mine up. I don't know why
| code completion would be the tipping point for type
| annotations when their usefulness to users and static
| analysis tools are already enough. Documentation for
| users is in fact enough to have them.
| rbanffy wrote:
| It could have been that code completion was the feature
| Guido saw would seal the deal with users. Good code
| completion is a great tool for exploratory coding. I
| frequently found about new APIs through the IDE before
| reading the documentation. This has been extremely
| valuable since Visual Basic 3, IIRC.
|
| I like it - sometimes I _want_ something to really take
| an integer (or an explosive bolt) and not any number (or
| a warhead). If I can say that the argument is supposed to
| be something, then it 's harder to the IDE user to misuse
| it with unpredictable results.
|
| Or, if my library or function can do something I never
| expected it could, I welcome the patch to make it
| obvious.
| 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!
| kkfx wrote:
| > textual syntax is nice for human understanding but will one
| day be no longer necessary
|
| Can you elaborate your vision? What future you imaging in
| human-computer UI terms? Visual programming so far have well
| proved to be a failure, modern visual programming is even
| worse than past tentative (see how crappy are visual
| environment from RPA to NodeRed&c)... Vocal interfaces are
| also crappy... Even if we look at sci-fi movies the computer
| interfaces they show are ridiculously inefficient... Just see
| Star Trek as an example: vocal commands in emergency
| situations that demands multiple seconds while a direct hit
| on keys demands just few ms, the Borg with neural connections
| and visual+touch UIs in their ships etc. Oh that's sci-fi of
| course but that means that even artists have so far failed to
| imaging different means.
|
| > If only they had made a cheap Lisp machine!
|
| At that time was not possible in scale and industrial terms,
| similar to the far older Xerox workstations, it's possible
| now, but too many do not even know that original desktop
| model and MANY (very skilled PhDs included) have even issues
| imagining it... Just myself using Emacs/EXWM in a
| presentation I generally create an extraordinary WOW effect
| on techies who fail to understand what they see live on the
| screen/projector, how is that possible, and there is nothing
| extraordinary, just EXWM/org-mode normal usage. That's the
| real issue, in common with Smalltalk: people who can
| understand do not know, people who can push classic model
| again do not want it at all, it hurt they skyrocketing high
| businesses (and curiously old business were in relative terms
| more profitable for anyone, only they do not assure by any
| means the possibility do dominate the market since being
| knowledge-based anyone who happen to have developed something
| good can succeed), the large mass of the rest of humanity do
| not even know what happen yesterday so...
| 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).
| kkfx wrote:
| > We use a lot of camel case but please remember it's
| Smalltalk (instead of SmallTalk).
|
| Thanks, correction registered :-)
|
| I agree about preferences-war, I generally tell my preference
| not to start flame but to give something for a positive
| discussion, witch means "how many in a community prefer $this
| more than $that and why" but less about the "similarity" with
| a natural language: in nature we use words as tags, so
| "objects" are natural, message passing is "natural" in the
| sense of collaboration between humans, but not really in the
| OOP sense. Also Smalltalk syntax to me does not look much
| similar to natural language.
|
| The most similar language I found so far is Python,
| imperative programming is not so effective but is easier than
| functional for newcomers and it's syntax is very easy to
| read, IMVHO that's the reason of it's popularity especially
| compared with very similar (in targets) languages like Perl
| or Ruby.
|
| Lisp is easy once you have learned a bit, and probably that's
| one part of why is not much popular, the rest, in common with
| Smalltalk is that both are designed for user programming,
| while "modern industry" want to lock users depriving them of
| any possible freedom and free usage of a desktop. In the past
| that was the IBM doctrine, thereafter the GAFAM doctrine:
| they all born out of Xerox tech, small part of it, wrapped in
| ways that put a product, a service at the center instead of
| the human. It's not only about liquefying intelligence but a
| mean to make _hard_ doing certain things.
|
| A stupid example: we have Wikidata, SPARQL is not that a
| great and digestible language but it's there, why the hell
| it's not normal just for a middle-school simple research
| query Wikidata form "a buffer" (in the Emacs sense of that)
| and see results in various forms we can manipulate to plot
| graphs etc at a level easy enough for a middle-school small
| student research? That's because IMVHO making easy doing so
| means users have power in their own hand, they can move not
| only in pre-defined and controllable paths but independently.
|
| Why aggregators vs personal aggregators with RSS+Xerox style
| scoring? Again because aggregators might satisfy users demand
| BUT matching them to their hoster desire, for instance
| silencing or discrediting some news and enlarging others (try
| to see the recent polemics about Meta vs TikTok PR campaign)
| while a personal one can't be tweaked from remote so users
| might find their own path with their own ideas and tools.
|
| Why "internet banking website" instead of a common standard
| API (like EU OpenBank, but open for all) with a desktop
| client? With it, users can have their transactions digitally-
| signed on their own desktop, having multiple banks and
| banking services in the same place, with the same UI etc
| without we have surveillance on crappy banking websites,
| crappy authentication, nothing in our hands etc.
|
| All those things have a common ground: modern/classic
| software development is compartmentalized with any human
| layer religiously separated from the others, ancient
| programming languages are designed for a coherent unique
| environment without barriers.
| sebastianconcpt wrote:
| Allow me to say that Smalltalk syntax can be really really
| similar to plain english sentences if you intentionally
| refactor it to optimize an elegant API. But (hairy topic)
| not every smalltalker will have talent for writing or taste
| or care at all about that, or at least enough to develop in
| that direction (which accidentally produces software
| friendlier to maintain and extend).
|
| It doesn't have to try to be natural language, AI/ML is
| close to achieve mimicing it properly [1], it just needs to
| feel comfortable enough for the programmer to tell
| computers how to behave in a way that has less cognitive
| load.
|
| The other questions you raise I think are very real and way
| more related to how power works among _homo sapiens
| sapiens_ than computing languages. The software becomes an
| optimization of the power relationships created among
| individuals, groups and institutions /legalized-mafia-
| groups.
|
| [1] https://en.wikipedia.org/wiki/GPT-3
| dgb23 wrote:
| It has nothing to do with philosophical concepts and
| everything with business culture.
|
| There are tools that facilitate expression, innovation and
| individual contribution. And there are tools that make it
| easier to scale and for programmers to be interchangeable.
|
| These two are very hard to unify. There's cross pollination
| but that's about it.
|
| Whether you're in a top down hierarchical business model or
| in one that's more open and people centric has a significant
| impact on which type of tools you're using.
|
| Smalltalk, Lisp and their descendants belong to the former
| category. They are immersive, expressive and incredibly
| dynamic and their communities are often pioneers. But this
| type of freedom comes at a cost that some do not want to pay.
| sebastianconcpt wrote:
| I agree with everything you said except your first sentence
| :D
| kkfx wrote:
| > But this type of freedom comes at a cost that some do not
| want to pay.
|
| Who are those some? Managers or techie? Because yes,
| business choose to do it's best avoiding Smalltalk, Lisp
| etc for business reasons, but those reasons are not "their
| cost" but the fact that with them anything is open,
| integrated, there are not countless of individual "product"
| to be sold, well welded so to guarantee that no one can
| temper them etc.
|
| It's a bit like modern "open source enterprise" monsters,
| they are not monsters because doing so make easy changes
| people involved in a project, find people skilled in that
| field etc but because being monsters it's cheap to pay
| enterprise support instead of deal with issues internally,
| re-write from scratch instead of forking etc.
|
| While these days Smalltalk and Lisp are just programming
| environments on a host OS in the past they were the OS and
| so the OS is a unique environment not a container cargo
| ship with containers on top, anything rigidly separated,
| that's the business reasons behind industry choice IMO...
| 324235235235235 wrote:
| > SmallTalk as a language is IMVHO terrible
|
| Eh, it's rare that you find a language simple enough that its
| syntax fits on an index card, yet conceptually rich enough that
| you can build complex systems with it. This is a feat in and of
| itself that warrants admiration and examination.
|
| r5rs was almost this, but it lacked any real facility for
| creating ADTs, like a class system, instead just giving you the
| rudiments (closures, functions), and expecting you to do the
| rest. Racket fixes this, but it's also much more complicated
| than both r5rs and Smalltalk.
| melvinroest wrote:
| I've been using Pharo professionally for about 1.5 months now,
| and I'm beginning to getting the hang of the language, and the
| culture surrounding it.
|
| I'll share a couple of thoughts.
|
| __General Development/Hacking__
|
| 0. From Pharo 9 and onwards, it runs smooth on an M1 Mac.
|
| 1. If you're interested in developing in Pharo professionally,
| we're hiring [1]!
|
| 1b. Other ways to learn about Pharo is to come to Smalltalk/Pharo
| conferences. I've been to the Pharo Days in Lille recently and
| I've learned a lot in those 3 days! Other than the Pharo Days
| there is ESUG.
|
| 1c. Check out the Discord channel. People have been really
| helpful [0].
|
| 2. A big part of the documentation can be found inside the image.
| For example, press SHIFT + enter and type "tutorial" or
| "exercise" and a few will come up. Moreover, when you click on
| any class, there's a "class comment" tab. Some class comments
| actually have comments and they're written out in a quite
| understandable fashion when they do.
|
| 3. You can make the following clicks and they do something
| different:
|
| - Click: shows a context menu to showcase a particular window /
| tool
|
| - Right click: shows "World Contents", aka objects about your GUI
| (I haven't used this one yet)
|
| - Shift + Option + click: this shows a "halo" around a GUI
|
| - Shift + Control + Click: the coolest meta click there is, it
| shows all objects that are directly related to the pixel you
| clicked on. If you clicked on a table cell item in a GUI window,
| you can figure it out via this click. I've used this trick to
| figure out where to go in order to alter my IDE to my own taste.
|
| 4. Pharo is one of the few languages I know where you can create
| like a game or application for which it's possible to immediately
| see the source code and interact with it. The use-case this
| allows for is highly hackable open-source applications. For
| example, here's a game that allows you to design chips [2]. It's
| easy to see how you could alter levels yourself quite easily,
| just start editing the code! IMO, that's next level open-source.
|
| 5. If you want to, it's relatively easy-ish to inspect the AST
| and see how it's mapped to the VM. Be careful of setting
| breakpoints here, you'll crash your image :P
|
| 6. A Smalltalker told me that Pharo's VM enforces everything to
| be an object but _technically_ not everything is an object, as
| far as VM implementation goes. If you 're not hacking on the VM,
| then you can assume everything is an object.
|
| 7. Overwriting the #doesNotUnderstand: message can lead to all
| kinds of fun! I wrote my custom If/Elif/Else DSL. Smalltalkers
| will hate me but I found it awesome because it showcases how one
| could hack a DSL quickly. You can see about it here [3]. Here's
| some example code:
|
| ``` If _: (someCondition) _: [ "code" ] Elif _:
| (anotherCondition) _: [ "more code" ] Else _: [ "final code" ]
| ```
|
| As you can see, I've hacked the _: to be a separator of some
| sorts, but what it actually is, is an argument of a message. You
| can do all kinds of fun stuff with this. See [8].
|
| 8. When you overwrite #doesNotUnderstand then you can inspect the
| message and its arguments. So whether you send Object1 a:arg1
| veryImportant:arg2 message:arg3, then you can inspect those
| arguments. In the case above, this means you can also inspect
| _:arg1 _:arg2 or _:arg1 _:arg2 _:arg3 ... _;argN. In other words,
| you can deal with variable arguments and it doesn't matter what
| they're called. Because of this, it's easy to create a simple
| DSL, if you need another separator, then simply add one. You have
| a lot of characters at your disposal that are quite unique [4]. I
| figured that out by using by using point (2) and just looking
| around in the environment.
|
| __Web Development__
|
| 9. Seaside is capable of live and dynamic updating. MOOCs won't
| tell you this because it requires using Seaside quite
| differently. In short, the pattern that I see used at my work is
| by having server-side rendered HTML that has designated blocks as
| callbacks. So when you send your server-side rendered HTML, those
| callback blocks will transform itself into a jQuery GET/POST
| request. Pharo writes the jQuery for you. We also use React, but
| I haven't gotten around to it how it's used, I'm fairly sure we
| don't use anything like Redux.
|
| 10. In terms of testing, it's relatively easy to write tests. As
| with Go, it's all included and you're ready to test! Also note:
| if you want to use Selenium tests, you can use Parasol [5], it's
| quite easy to use.
|
| 11. The following concepts are not explained well, so I'll do it:
| Seaside heavily uses what we'd call middleware in NodeJS (filters
| in Seaside). In NodeJS/Express we also have a request object that
| exists during the lifetime of a request. In Seaside this is
| called a dynamic variable (WADynamicVariable is the class).
|
| __Stuff I wrote out in the open__
|
| 12. I've been working on refactoring i18n in Seaside [6]. I
| currently find the approach Pharo uses the nicest approach, which
| is something along the lines of:
|
| 'You have some string that needs translation in your web app'
| SeasideTranslated
|
| When you want to export a catalog file of all the strings you
| want to translate, then you send exportCatalog new exportCatalog
| and it will look through the whole image and find every tagged
| string and export it into a catalog (.pot) file that you can edit
| with POEdit (a free Mac app [7]).
|
| 13. I wrote a simple animation that shows the definition of sin
| and cos [8]. Most of the code is shown in that video, IMO it
| gives a good enough sense how to use it.
|
| __Bottom Line Thoughts__
|
| 14. I think Pharo is a production-ready language for SaaS apps
| where you can easily scale by adding instances. I am not sure if
| it'd be production-ready for consumer facing web apps with many
| concurrent users.
|
| 15. It's an amazing language to create desktop applications for.
|
| 16. The debugger capabilities are awesome and there's active
| research on it. Time travel debugging is currently in its PoC
| phase (source: Pharo Days).
|
| 17. It's also a good language for live music making (source:
| Pharo Days where someone demo-ed some live coded acid music).
|
| [0] https://discord.gg/QewZMZa
|
| [1] We're hiring developers able to work in Europe and based in a
| European time zone. The way we use Pharo is IMO the real deal, it
| goes far beyond what any MOOC can teach you.
|
| https://yesplan.be/en/vacancy/full-stack-software-engineer
|
| [2] https://github.com/pavel-krivanek/PharoChipDesigner
|
| [3] https://www.youtube.com/watch?v=BUEnRrUZ-Ug
|
| [4] ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyzauoAAAAA
| AAECEEEEIIIIDNOOOOOOUUUUYThssaaaaaaaeceeeeiiiidnoooooouuuuythy
|
| [5] https://github.com/SeasideSt/Parasol
|
| [6] https://github.com/SeasideSt/Seaside/tree/gettext-fix
|
| [7] https://poedit.net/features
|
| [8] https://drive.google.com/file/d/1Z3UwTAj4A2CRo_TXk6JNG-
| mN9yM...
| VaxWithSex wrote:
| Nice to see that yesplan is still around.
| ljm wrote:
| > Be careful of setting breakpoints here, you'll crash your
| image :P
|
| I accidentally defined `=` on a class with an incomplete
| implementation. I think I saved it just out of habit.
|
| Of course, this royally buggered the entire image because the
| class browser evaluated `=` when trying to open that specific
| class.
|
| I was doing this in Squeak rather than Pharo, but that was a
| scary moment when my mental model before that was to do a `git
| checkout` to revert the change. I think I ended up writing some
| code to find the method and delete it, before I realised there
| was a change browser where I could discard that implementation.
|
| The biggest barrier to entry was really understanding the
| concept of the image and that you do all the work in the class
| browser, rather than building a hierarchy of classes that all
| branch out from a main class.
|
| I had a lot of fun playing around with Smalltalk.
| melvinroest wrote:
| Hahaha, yep I can see how that would go wrong :')
|
| > before I realised there was a change browser where I could
| discard that implementation.
|
| Haha nice!
|
| There's also a changes file.
|
| I guess I have another recommendation: Pharo is not _just_
| about the image. When you click on an image folder there are
| other files. Try to figure out what they do and how you could
| use it to your advantage. Check out what the pharo-local
| folder does for example. The iceberg folder there, for
| example, directly hosts the .git folder. I 've used it at
| times if I couldn't get whatever I wanted to do in Iceberg to
| work (e.g. adding a remote). The .sources file shows the
| changes that you have.
| ljm wrote:
| For sure. I started off with Squeak so I eventually got the
| git package installed and, in addition to updating the
| image and the changes file, it also wrote out the classes I
| added to disk - basically a directory being the class and
| every file inside the directory being the implementation of
| a method.
|
| It's hard for me to see what I'd deploy this way, as a pet
| project, but it's teaching me a lot more about a nice way
| to do OOP that also gives you an environment in which OOP
| can thrive.
| butterisgood wrote:
| Nice release! And yes, for a short iteration, there's a lot of
| good stuff in there!
|
| Congrats!
| spdegabrielle wrote:
| A modern smalltalk for a modern era! Congratulations to the Pharo
| team, past and present, and all the contributors for a truly
| monumental achievement.
| athenot wrote:
| I really appreciate that a blog post about a language update
| starts with a simple sentence to describe what the language
| actually is.
|
| > Pharo is a pure object-oriented programming language and a
| powerful environment, focused on simplicity and immediate
| feedback.
|
| Many times I land on announcements about Foo v3.0 that is super
| awesome and describes the diff from v2.5, with no mention
| whatsoever about what Foo actually is.
|
| Thank you!
| 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...
| sebastianconcpt wrote:
| Thanks for the reference I didn't knew about that one!
|
| What I'm working on is based on Pharo tho. It's an
| alternative IDE and accidentally a way to create apps
| that have multi-platform native look and feel.
| 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]
| chunes3 wrote:
| The problem I have with Pharo is that there are hundreds if not
| thousands of types -- each with their own fiddly interfaces. I
| don't have time for that. I much prefer the Clojure philosophy of
| having few types that can do it all.
___________________________________________________________________
(page generated 2022-04-06 23:02 UTC)