[HN Gopher] How does find by example work in the Pharo Finder
___________________________________________________________________
How does find by example work in the Pharo Finder
Author : rscho
Score : 98 points
Date : 2022-05-22 08:03 UTC (14 hours ago)
(HTM) web link (chicoary.wordpress.com)
(TXT) w3m dump (chicoary.wordpress.com)
| urthor wrote:
| One of the things to appreciate with Pharo Smalltalk is a code
| snippet isn't a code snippet.
|
| Pharo is not a filesystem/.txt coding environment.
|
| It's a VM runtime with _every single element_ is indexed by the
| class /traits hierarchy. And then the same code draws the GUI.
|
| OP didn't just write a code snippet.
|
| They wrote a method, tested it in an already launched dynamic
| runtime.
|
| And _deployed it into a desktop app in front of you_.
|
| Forget Jenkins, Docker-Compose or Make, their deploy tool was
| copy/paste.
|
| It's truly a pity that desktop based applications are not popular
| in the current age, and phones are locked down.
|
| Smalltalk remains truly unparalleled at producing local apps. 30
| years after its heyday, SwiftUI is still a shadow of what
| Smalltalk can do.
| agumonkey wrote:
| It's gonna be part of a benchmark for how long until
| "engineers" realize they're stupid.
| indigochill wrote:
| Engineers are still just humans which means they're
| susceptible to marketing same as any other human. Much of the
| evolution of popular programming languages is just marketing,
| most obviously in the case of Javascript.
| agumonkey wrote:
| Partly true, partly not true. It's somehow sad to see
| educated people falling for these tricks. But actually my
| issue is not about people being diverted by market
| dynamics.. i can empathize with that. It's the non
| recognition, non interest when presented with these
| artefacts. No curiosity, no reading grid to analyze systems
| or ideas.. shallow reflex criticism .. super odd to me.
| melvinroest wrote:
| My favorite example: as the game is easily extendable.
|
| https://github.com/pavel-krivanek/PharoChipDesigner
| rscho wrote:
| Very nice! Thanks for sharing!
| arnsholt wrote:
| From 2016 to 2018 I worked on a complex case management
| application that was implemented in Smalltalk. It ran on Visual
| Smalltalk Enterprise (last updated in 1999! But the app was
| first put into production in 1996...) which is really _quite_
| crufty compared to Pharo, but the development experience still
| blew me away. The Smalltalk way of working takes some getting
| used to, but once I got into the swing of it, it was the the
| smoothest development process I 've had: you log into the app
| and do your stuff. Poke some bugs, try to reproduce them, maybe
| find some completely unrelated error, and whenever you update
| the code you just save the methods and pick right back up from
| where you left off.
| draven wrote:
| First time I saw the find by example feature I thought "maybe it
| tries all applicable methods" but then immediately dismissed the
| idea because it could execute methods with side-effects. Does
| Pharo somehow knows about safe/unsafe methods ?
| tonyg wrote:
| The original method finder in squeak has a blacklist of methods
| not to try, but otherwise works just as you imagine. There's
| some very cool recent work on isolating effects at a low level
| that should obviate such grody hacks! Then the system really
| can freely and safely try all applicable methods. See thread up
| and down from here
| https://twitter.com/leastfixedpoint/status/15123917563183923...
| trashburger wrote:
| I also noticed that the reimplementation uses `receiver
| deepCopy` for each message send to preserve the original
| object, so that side effects would not affect the receiver.
| rscho wrote:
| I don't think it really does. If I remember correctly, there's
| a bit of white/blacklisting going on under there.
| samatman wrote:
| Smalltalk code is full of these kinds of unprincipled
| solutions which work better than they should.
|
| You can get away with a lot of saying "just trust me" when
| everything is exposed for immediate exploration of whether
| invariants are in fact preserved.
| geocar wrote:
| Because it starts out in English and does not say so right away,
| I think it is a good idea to point out that the article is a
| google-translate, and seeing it in English I get a different idea
| in places than when reading the Portuguese.
|
| For example, I had never before considered how this feature could
| help people navigate a foreign language so literally.
| prestonh wrote:
| La
| rubyist5eva wrote:
| 7 minutes of Pharo Smalltalk for Rubyists ->
| https://youtu.be/HOuZyOKa91o
| melvinroest wrote:
| Pharo recruitment plug: yesplan.be (Belgium) is hiring European
| Pharo software engineers. If you have little Pharo knowledge
| that's fine too, in my (personal) experience, as I am now working
| with it for 3 months.
|
| More on topic: there are many ways in which Pharo can find things
| that is not possible (or applicable) in other languages.
|
| For example, there are 4 mouse clicks you can make in your image:
|
| - left click
|
| - right click: it shows a context menu
|
| And then there are two clicks that I would need my laptop for to
| (re)figure out. One shows a "halo" around a window. The "halo"
| gives all kinds of options. The other one shows a context menu
| that allows you to figure out what objects are running with
| regards to the _pixel_ you clicked on!
|
| Because of the last click, it's easy-ish to extend your IDE.
|
| The last two clicks are some combination of CMD + Option + CTRL +
| click
| VyperCard wrote:
| What is your pay for someone who could write this ten years ago
| in Amber Smalltalk but had since worked with Python and
| typescript?
|
| https://m.youtube.com/watch?v=uUOlzr4XdcY
|
| Asking for a friend...
| melvinroest wrote:
| Feel free to email me to have a more in-depth conversation.
| My email is in my profile.
| em-bee wrote:
| would you consider part time, remote?
| melvinroest wrote:
| I do remote-ish [1] for 4 days per week. I doubt they will do
| less days or more remote.
|
| [1] I am at the office about every 6 weeks for 2 to 3 days.
| e12e wrote:
| Interesting, from: https://yesplan.be/en/vacancy/full-stack-
| software-engineer
|
| > Our backend uses Pharo Smalltalk, Seaside and GemStone/S
|
| How is your experience with GemStone/S?
| melvinroest wrote:
| For people that don't know, GemStone is a smalltalk
| descendant that has an object-oriented database behind it.
|
| I don't know much about GemStone specifics yet, I am about to
| though.
|
| My skillset before this was mostly in React and Node.
| throwawayForMe2 wrote:
| I used Gemstone/J for a number of years. This is the version
| of Gemstone DB for Java applications, same capabilities as
| the Smalltalk version. If you are familiar with Object
| Databases you will find it very easy and capable.
|
| Before using Gemstone/J with a Java application, I worked in
| Smalltalk for a number of years building an application
| backed by a different object database product, so I was
| already familiar with the advantages and pitfalls of using an
| OO DB. If you are familiar with using an OO DB, Gemstone is
| an easy transition.
| tluyben2 wrote:
| We have been working for years now on a smalltalk like IDE and a
| language (which is as language not like smalltalk at all, but as
| runtime it is). When we went down the rabbithole of prior work
| (like smalltalk, lisp, etc), it is painful to notice how far we
| actually have come but how little we actually use / have
| available to us in mainstream dev. We hope to show how it should
| be later this year!
| arnsholt wrote:
| It's kind of depressing, honestly. Smalltalk is amazing future
| technology from the 1980s, and here we are in 2022 with our
| fancy IDEs still dropping off our (metaphorical) punch cards
| for batch processing.
| tluyben2 wrote:
| Yep... Fairly bizar that a smalltalk env on an old computer
| is faster for iteration than the modern react/typescript
| stack. Better errors, easier to debug etc. All because the
| tooling was from the future. React peeps think hot reload is
| something special. It was normal and it was faster and more
| robust than it is now.
| nyanpasu64 wrote:
| I think there's an inherent conflict between languages
| creating programs like clay to be molded by the developer
| and the user, interactively (repl, smalltalk), vs.
| languages creating programs with optimal machine code with
| no extraneous computations, and/or maximal low-level
| control (sometimes even at the cost of making it harder to
| alter code, like manual data structures or hand-rolled
| assembly or vectorization). I wouldn't call Smalltalk
| technology from the future, but rather optimizing for a
| different ideal (though I've never used Smalltalk to
| experience the magic firsthand (and/or smoke and mirrors,
| ctrl+f "white/blacklisting")). Smalltalk (like Java) is
| bound to a GC, and GC wreaks havoc with using finalizers
| for manual memory management cleanup, since finalizers can
| be called while a variable is still in scope unless you use
| GC.KeepAlive() or friends.
|
| On the other hand, optimized C++ is notoriously hard to
| debug, and debug C++ is slow (especially when using "zero
| overhead" abstractions that are only zero-overhead in
| release builds). There's cool work at reversible debugging,
| binary-patching, etc. (low-overhead tracepoints, Linux
| kernel Kprobes which failed to hook some functions I think
| were actually called, CONFIG_DYNAMIC_FTRACE, most recently
| https://justine.lol/ftrace/, though both
| CONFIG_DYNAMIC_FTRACE and ftrace depend on injecting nops
| into code which can later be replaced by tracing code).
|
| JavaScript excels at neither performance nor dynamism,
| though I think it's still a lot more dynamic than C++
| (userscripts can tamper with page contents and scripting)
| and faster than Python (through herculean effort of the V8
| developers funded by Google ad revenue to make web apps and
| advertising faster). And C++/assembly, by its nature of
| allowing complete control over the machine, is difficult to
| sandbox beyond running code in an isolated process or VM
| (or compiling to WASM then to x86?), as opposed to JS/WASM
| being (theoretically) memory-safe and sandboxable by taking
| away APIs interfacing to the outside world.
| mikelevins wrote:
| I think that saying it's an inherent conflict is
| overstating it. I think it's a bit more like there are
| these two axes, a performance axis and a malleability
| axis, and they aren't completely orthogonal, but they
| also aren't diametrically opposed.
|
| Granted, if you ignore one axis and optimize the heck out
| of the other one, you're unlikely to end up in an optimal
| region of the ignored axis. But there are optimization
| paths that move in good directions on both axes at once,
| until you reach some limit where you sort of move around
| on some boundary arc by trading off one against the
| other.
|
| Apple's Dylan project was conceived with the explicit
| purpose of developing a language and runtime that would
| satisfy the highly-interactive-programming enthusiasts
| (that is, the Smalltalkers and Lispers) in Apple's ATG
| and other researchy groups, while also producing built
| artifacts that were fast and interop-friendly and compact
| enough that they wouldn't all have to be rewritten from
| scratch in C, Pascal, or assembly before the product
| groups would agree to ship them.
|
| The Dylan team did a pretty good job. I was one of their
| internal customers, working on an experimental handheld
| OS written mostly in Dylan.
|
| The Dylan team gave us a modified version of Macintosh
| Common Lisp, called Leibniz, with Dylan support. Leibniz
| was just MCL, but with a Dylan compiler, object system,
| and runtime built into it. The Dylan compiler cross-
| compiled to the handheld's hardware. Our dev machines
| were Macs, either with daughterboards stuck into nubus
| slots, or with actual handheld hardware ribbon-cabled to
| the nubus.
|
| Leibniz had a second version of everything in the MCL
| environment: there were the normal Lisp listener windows,
| but also Dylan listener windows. There were normal Lisp
| editor windows and Dylan editor windows. And so on.
|
| Code compiled and evaluated in the Lisp windows ran on
| the Mac hardware. Code compiled and evaluated in the
| Dylan windows ran on the handheld hardware.
|
| Our built software ran on the same handheld hardware as
| the C++ OS. It performed well--well enough to make some
| of the C++ team curious sometimes about how we did
| certain things.
|
| The relevant point is that you can make a highly-
| interactive and malleable language and development
| environment that also delivers fast, compact artifacts. I
| don't think there's an irresolvable tension between those
| two goals.
|
| On the other hand, optimizing toward both goals is more
| work than optimizing one at the expense of the other. If
| you elevate one goal above the other, the elevated goal
| will benefit and the other will suffer. Optimizing both
| means paying attention to both all the time, and that
| sometimes means that you will disqualify certain options.
| Optimizing both shrinks the workable solution space, so
| you have to look harder and sometimes solve problems in
| less easy ways than you would if you were thinking only
| about the one goal.
|
| On top of that, the features that make an environment a
| great, malleable, highly-interactive environment are
| extra. You still have to do all the same kind of work
| that you need if you don't care about making a highly-
| interactive environment--lexers, parsers, compilers,
| optimizers, linkers, editors, indexers, and so on, and so
| forth--but on top of that, you have to design and build
| all of the features that make an environment highly
| interactive--a repl that has visibility into everything
| in the runtime as it runs, error handling that can spin
| up an interactive session in the dynamic context of a
| signaled error, runtime facilities that detect and keep
| track of every dependency that changes dynamically and
| knows what to do about it, inspectors that know how to
| expose and edit every element of state in the whole
| system, and so on.
|
| That's really the obstacle, I think: a really malleable
| environment is just a lot more work. That, and to build
| one you need builders who know what they are and how to
| build them.
| e12e wrote:
| See also, recently posted 2013 article on GNU
| openstep/etoile project and unification of C, objective-c
| and smalltalk runtimes:
|
| "Smalltalk in a C world (2013)"
| https://news.ycombinator.com/item?id=31462735
|
| Not entirely sure about the status of the project, but
| there appear to have been a few updates in github more
| recently than the news section of the website.
|
| https://github.com/etoile/
| eismcc wrote:
| While this is a deep topic regarding the philosophical
| break between the two paradigms and one which I spend a
| lot of time on, the ideal to me seems to be a system
| which has the immersive nature of a smalltalk-like
| environment while having the finalized image run at near
| "chip speeds". JIT was added to smalltalk to solve this
| problem and so I wonder if it's more about balancing the
| two modes.
| scroot wrote:
| There is also just the simple issue of how many people
| are working on these systems. Right now there is an
| Opensmalltalk VM change in the words -- SISTA -- that has
| the potential for a 3x speedup of those systems. But it's
| largely the work of one or two people and it's unfunded.
| They are working on it in their limited free time.
|
| Additionally, there is a specific kind of dominant
| "computing culture" that we live in. Show a new language
| to mainstream developers and they will want to know how
| to do a "hello world" and which text editor / command
| line program to run in order to use it, as if these are
| the only ways to interact with a machine in any
| meaningful way. Anything outside of this seems like it's
| "not real programming".
| mncharity wrote:
| > the philosophical break between the two paradigms and
| one which I spend a lot of time on [...] I wonder if it's
| more about balancing the two modes.
|
| I don't see the break? "Clay" tooling exists for
| "industrial" code, but as secret sauce, and jig kludgery,
| and various other "making this more broadly available is
| not in/of our interest". "Clay"'s rejection of
| "industrial" has seemed more resource-starved exploit-
| not-explore group-think. Smalltalk/forth/etc audacious-
| scope rewrite-the-world efforts have seemed more "remake
| the world" than "to force us to remake ourselves". Try
| imaging a forth implementation effort that said "ok, we
| have bootstrap... so now the next obvious steps are
| supporting PICs and multiple dispatch and template jit,
| WAM and BEAM vms, linking Z3 solver, DHM type inference,
| ...". So perhaps rather than an inherent break between
| modes, and balancing to be done, there's a lack of
| available power, and of interests/resources aligned with
| ramping it.
|
| But then, I'd like a programming environment which
| provides an _powerful_ environment for making engineering
| tradeoffs, rather than ones which hardwire in very
| dramatic ones. I expect such an environment, when it
| finally exists, won 't be hard to recognize. As, for
| example, basic reimplementation of existing modern
| languages, with their big test suites, libraries,
| community repos, specs sometimes transliteratable
| directly into code, code-as-documentation and highly-
| investment-in optimization, is a natural forcing-factor
| exercise for such an environment. So when you see a small
| team spewing new language implementations... maybe we've
| at long last hit phase transition. And if one can't
| easily manage that, in bulk, even with all that
| leverage... then it's not a very powerful environment, is
| it?
| tluyben2 wrote:
| We are trying to do something novel on this intersection
| you speak of. I hope we figure it out far enough. But
| yes, you are right in sketching the current situation; I
| firmly believe we could've been a lot further than we are
| and I intend to prove it.
| coliveira wrote:
| The problem is that developers have been brainwashed to
| dislike what Smalltalk has to offer. If you tell them to use
| a Smalltalk-like system they will complain to no end about
| the lack of file-centric infrastructure, while what Smalltalk
| has to offer is decades ahead of what they can do with other
| systems.
| harha wrote:
| Any recommendations on where to get started to understand
| the idea behind it, where it's used and how to approach
| typical problems?
| TheAceOfHearts wrote:
| How is version control usually handled in these kinds of
| systems?
| throwawayForMe2 wrote:
| When I did Smalltalk in a corporate team environment we
| used a tool called Team/V. Code is stored in a shared
| repository. Everyone starts with the same clean image,
| loaded with the tools and options chosen for the project.
|
| From your clean running image, you open the Repository
| Browser window. You load app code from the repository,
| make changes etc., and commit back to the shared
| repository.
|
| There were many options for organizing "packages" and
| creating lists of packages and version numbers for a
| "build". Also different options for ownership of code,
| locking code from changes, difference reports, etc.
|
| Open source tools I have not used.
| melvinroest wrote:
| <= Pharo 8: Monticello
|
| >= Pharo 9: Git (through something called Iceberg)
| rscho wrote:
| In a much less interactive manner, the Unison language
| seems like it revolves around some stuff found in Smalltalk
| agumonkey wrote:
| market dynamics wiped lisp in the 80s, then smalltalk in
| the 90s
|
| such is life, it's gonna popup again in php10 or
| typescript5 for sure
| bradrn wrote:
| > We have been working for years now on a smalltalk like IDE
| and a language
|
| I'd be curious to know more about this!
| bowsamic wrote:
| Does anyone know how to go to a specific implementation of a
| message for an object?
|
| For example can I take "#(1 2 3) min." and go directly to the
| definition of min? It seems I can only look at _all_
| implementations, not just the implementation for that object
| throwawayForMe2 wrote:
| Use the debugger to step through, and you will see the
| implementation that is about to be executed?
|
| The debugger code itself could give clues on how to do it.
___________________________________________________________________
(page generated 2022-05-22 23:01 UTC)