[HN Gopher] Smalltalk simplicity and consistency vs. other langu...
___________________________________________________________________
Smalltalk simplicity and consistency vs. other languages (2022)
[video]
Author : harryvederci
Score : 75 points
Date : 2024-01-12 10:30 UTC (2 days ago)
(HTM) web link (www.youtube.com)
(TXT) w3m dump (www.youtube.com)
| Rochus wrote:
| Interesting talk. Smalltalk (like Lisp) has indeed a very simple
| (i.e. minimal) syntax. But that doesn't necessarily mean that it
| is also simple to write and read code, or to implement an
| efficient compiler. E.g. blocks - as great as they are - make
| inlining very difficult; it eventually took 30 years to implement
| a VM with decent performance (see http://software.rochus-
| keller.ch/are-we-fast-yet_crystal_lua... for the results of
| https://github.com/rochus-keller/Som/ and
| https://github.com/rochus-keller/Smalltalk/ compared to
| Cog/OpenSmalltalk). Another language explicitly designed for
| simplicity is e.g. Oberon, which is statically typed and easier
| to implement with decent performance.
|
| In my experience, at the end of the day, it's more the
| familiarity with a language that makes it seem "simple". And
| there is a trade-off between "simplicity" of the language and
| "simplicity" of the solution; if the language is too minimal, the
| solution quickly becomes confusing instead, and vice versa.
| wslh wrote:
| > But that doesn't necessarily mean that it is also simple to
| write and read code
|
| Right, having several friends in the smalltalk/Squeak scene I
| tried "obvious" things that required to know the patterns of,
| for example, Morphic framework [1]. I understand that if you
| include a good development wizard/assistant would significantly
| improve the learning curve.
|
| [1] https://wiki.squeak.org/squeak/morphic
| Rochus wrote:
| Funny, I wrote that two days ago, here it says three hours.
| Jtsummers wrote:
| Second chance pool. When a post is on there, it will may get
| its timestamp updated to the current time and will be tracked
| as if it was submitted at that time. All existing comments
| will get that same timestamp for a while. The fake timestamp
| helps to game the ranking so it goes to the front page for
| its second chance at discussion and votes. Eventually the
| real timestamp is restored.
|
| https://news.ycombinator.com/pool
| harryvederci wrote:
| Worth watching even if you skip to the last couple of minutes,
| where he tests a Game of Life scenario in a way that is not
| comparable to anything I've seen done with any other programming
| language.
|
| This power that Smalltalk systems have where the code runs in a
| GUI that is also the editor/debugger/etc has deeply fascinated me
| recently.
|
| At the same time it makes me kind of sad, because it feels like
| we're all stuck writing code with a hand tied to our back. Almost
| makes me think that there's a happy alternative coding universe
| where the Smalltalk way is the default way, and a couple of
| weirdos are using separate IDEs/editors and restart their program
| on every change, or think they're smart if they're running
| something as primitive as a REPL.
|
| The reason why I'm not just diving in and never looking back is
| that it seems like such a big investment, and that I'm so comfy
| with my (very) extended Neovim setup. And I'd like to be able to
| create applications that run without shipping the entire
| Smalltalk VM. And I'd like to actually understand a tool that I'd
| have to dive into that deeply, and I think I'll never have the
| time to truly understand all of the VM, the classes, etc.
|
| Maybe instead, I should just create my own language that contains
| its own code editor. Seems like almost the same time investment,
| but maybe more satisfying?
|
| Sigh...
|
| Anyway, here is some other related interesting material:
|
| - Bret Victor - Inventing on Principle (Always funny to hear the
| crowd go nuts when he does the live game editing time thingy.)
|
| - Pretty much any Alan Kay video.
|
| - Dan Ingalls his "Lively Kernel", which seems to me like it's
| pretty much the same as a Smalltalk system, but where you code in
| JavaScript, and it runs in the browser.
| pjmlp wrote:
| As addedum, this experience was also available across the other
| Xerox PARC workstations, namely Interlisp-D, Mesa (XDE),
| Mesa/Cedar.
| delusional wrote:
| I think this split is way overstated.
|
| Consider the case where you fundamentally modify the invariants
| of an object. All you existing instances might now be in some
| inconsistent state. One way to avoid this is to enforce some
| unity of code and state. If we instead of modifying all the
| existing instances just modify instances created from this
| point forwards, we don't risk messing with the invariants.
|
| Well now we have a standard unix model. The executables are
| "classes" that get "instantiated" (exec'd) into "instances" or
| processes.
| brabel wrote:
| > This power that Smalltalk systems have where the code runs in
| a GUI that is also the editor/debugger/etc has deeply
| fascinated me recently.
|
| Have you tried emacs?
|
| > And I'd like to actually understand a tool that I'd have to
| dive into that deeply, and I think I'll never have the time to
| truly understand all of the VM, the classes, etc.
|
| I've recently tried to do that myself with Smalltalk via the
| Glamorous Toolkit[1] (a beautiful, modern Smalltalk environment
| based on Pharo). Because the programming environment itself
| comes with a Book teaching it, you can basically just read it
| as a normal digital book, but with the superpower that
| everything is editable and interactive: you can change the book
| itself, every code example is runnable and you can inspect the
| result objects right there, change it, modify the view for
| it... they say it's "moldable development" because you almost
| literally mold the environment as you write your code and learn
| about the platform.
|
| > And I'd like to be able to create applications that run
| without shipping the entire Smalltalk VM.
|
| That's why even though I really enjoyed SmallTalk, I can't
| really see it as anything more than a curiosity. I tried using
| it at least for my own occasional data exploration because it
| has good visualisation capabilities and super easy to use HTTP
| client/JSON parser etc., but the system is so heavy (1GB+ of
| RAM) that I couldn't justify keeping it open all the time like
| I do with emacs, on the offchance that I might need to use it
| for some small task.
|
| Anyway, perhaps that's something you might be interested in.
|
| [1] https://gtoolkit.com/
| bmitc wrote:
| > Have you tried emacs?
|
| Here we go ...
| wudangmonk wrote:
| This isn't a vim vs emacs debate. We're talking about
| smalltalk and what do you know! emacs was made to resemble
| the big expensive lisp machines which were in turn made in
| the image of smalltalk but with lisp as the language of
| choice.
|
| With this in mind, recommending emacs when someone states
| that they are interested in a system where the "code runs
| in a GUI that is also the editor/debugger/etc" does not
| seem out of place at all to me.
|
| Pharo can also be recommended but its a lot more resource
| hungry and with a mouse centric workflow compared to emacs
| which is keyboard focused.
| d0mine wrote:
| Python notebooks such as https://marimo.io/ seems to provide
| many of the same benefits
| e12e wrote:
| > And I'd like to be able to create applications that run
| without shipping the entire Smalltalk VM.
|
| There's always a javascript vm... https://squeak.js.org/
| ww520 wrote:
| Story time. When I was a young developer in a database company,
| my cubicle was next to a section where a team sat. The team
| consisted 30 to 40 people working on a secret project. Whenever I
| asked them what they were working on, they said it's a secret
| next gen technology. They spoke in secret code and big terms. The
| only thing I knew was they were using Smalltalk as the language
| as they weren't shy in speaking beamingly about it. They work on
| these powerful workstations with large monitors, a luxury at the
| time, as the Smalltalk dev studio required them. I thought these
| were god developers, working with advanced technologies in a
| covet skunk project.
|
| The project went on for couple years. Nobody knew what they were
| doing, not their goals, their product plan, their features, nor
| their designs. The only thing we knew was they were using
| Smalltalk.
|
| The high-up forced them to give a demo eventually. The talk was
| good, on Smalltalk, on OO, and on the landscape of the
| technologies. When the demo started, it showed a half finished
| login dialog box but nothing else. They said something about
| unable to package the code and do a release. Understandably
| software releases were a big bang process back then. But what
| about prior releases? Nothing. They didn't have any finished
| builds. The talk continued.
|
| The project got canceled couple months later.
| pavlov wrote:
| Smalltalk was always good for rapidly developing GUIs, so
| whatever the reason was that they only had a half-finished
| login box to demo, it probably wasn't Smalltalk's fault.
|
| Rapid development tools can't help you if you don't know what
| to build.
| ww520 wrote:
| My guess is the secrecy of the project was the main
| contributing factor to its failure. There were no vetting on
| the products, feature, design, development process,
| technologies, language choice, etc. Too many people read
| Skunk Works and thought they were Lockheed Martin.
|
| The language choice probably contributed somewhat. Smalltalk
| used to have problems with source version control and
| configuration management. It's difficult for multiple people
| to work on the same codebase. Merging change was difficult as
| the individual development environments were modified. The
| rapid prototyping was probably a false lead as it lured
| decision makers into thinking lower development cost.
|
| By and large when the only thing about the project you can
| talk about is the language used, the project is probably
| doomed to fail.
| guestbest wrote:
| I hope it was a beautifully designed login screen at least
| znpy wrote:
| I have dabbled with Pharo smalltalk a bit and got a similar
| feeling.
|
| The core "thing" (pharo it self) works well enough, other stuff
| you'll likely have to write on your own (batteries are not
| included).
|
| Also, multi-threading seems to be non-existant? No FOSS
| implementation does that AFAIK (proprietary implementations are
| irrelevant).
|
| I see the nicety of the language, but I'm not convinced (at
| all) by the implementation. Oh and Pharo seems to be the most
| advanced implementation of Smalltalk?
|
| It really doesn't look practical at all.
|
| But then again, the video starts and the guy is kinda deriding
| some Java or C++ code but then you move forward (eg: 8:31) and
| the speaker has a whole display filled with unrelated things
| and has to write code in a small text area, viewing like 4
| lines at the time? Thanks, i'll pass...
| daitangio wrote:
| I was excited in Smalltalk around 1999, during my Master Thesis.
| The sad story is Java Hotspot had more technology than
| ParcplaceDigitalk(Cincom) and kept growing. I love Smalltalk but
| Java won, even when it was closed sources. Try Squeak (or Cuius):
| it is beautiful,but sadly it has little traction.
| pjmlp wrote:
| Smalltalk technology acquired by Sun lives on Hotspot, while
| IBM's Smalltalk technology lives on Eclipse and J9, and Rogue
| Wave had one of the first collection frameworks.
|
| It doesn't help when Smalltalk vendors were the first to jump
| into Java.
| trashburger wrote:
| Small clarification: the Smalltalk technology absorbed by
| HotSpot was StrongTalk's static type-based optimization
| techniques combined with dynamic recompilation (what we now
| moniker as a JIT) originating from research done with Self
| (which was also part of Sun at the time).
| luksamer wrote:
| Jdhbf
| luksamer wrote:
| Smart Lock on
| diegof79 wrote:
| Seeing an article about Smalltalk with Hernan presenting so up in
| HN is nice.
|
| I worked with Hernan a while ago. We worked in a financial system
| with very cool things: an OO database, a workflow system that can
| work locally or remotely transparently, a good model for units
| and dates, tons of custom tools in the IDE (something that is
| only possible with Smalltalk IDEs) that allowed us to automate
| unit test generation, versioning, and database migrations. The
| last time I saw that level of productivity in any IDE was then.
|
| However, Smalltalk is not perfect, and when I see these
| presentations, I cannot stop thinking that a more balanced
| discussion is needed.
|
| The presentation shows how Smalltalk blocks are uniform with the
| if/then/while syntax. But that's only part of the history. To
| support blocks that way, the compiler optimizes those cases and
| inlines the block unless you do something else. So, while
| assigning the block to a variable looks the same, it's not
| executed similarly. That's the beauty of hiding the
| implementation details. But, sometimes, those details bite you.
| Most St programmers avoid creating custom "ifThen:else" messages
| because, in most VMs, that will break.
|
| In other words, like any design decision, the simplicity of the
| "object message" syntax has trade-offs, too. The performance
| trade-off is fixed by having exceptional cases hidden from most
| programmers. The other trade-off is the need to always dispatch
| to a receiver. Compared to Lisp or other functional languages,
| the need for a receiver dramatically impacts how you design and
| structure your program. Many things that you can resolve with a
| polymorphic function need to spread across classes in St. And
| that introduces the problem of sharing the implementation: class
| hierarchies, traits, or composition. Resolving those problems
| with a simple function is refreshing and falls under the
| statement at the beginning of the talk: the programming language
| affects how you think about the problem. When I look at the code
| I wrote back then in Smalltalk or Java, I cannot stop thinking
| about how the restriction of using classes and methods adds
| unnecessary complexity.
| JonChesterfield wrote:
| I'm a little confused by the receiver thing. Is the idea that
| each object has a dictionary mapping function names to code and
| sending a message to an object means execute whatever was found
| in that dictionary?
|
| So the example of { a < 3 } while involves evaluating a block,
| getting a boolean, then calling the while method on that
| boolean?
|
| That would seem to have a bad time with things like compare.
| Neither argument is special, you end up implementing a lot of
| compare-with methods. I.e. the expression problem. Is that
| understanding broadly correct?
| bmitc wrote:
| Does anyone have any advice on how to become an auteur software
| engineer? I've tried visual programming, functional programming,
| and several others, and they are just so much more enjoyable and
| powerful (in a specific sense akin to productive) than mainstream
| languages like Python, C++, etc. But I'm relatively exhausted by
| having platforms dictated to me by the middle of the bell curve
| and, frankly, people not experienced. Even as something as
| simple.and pragmatic as F# or Elixir seems to make people step
| back from you, as if you're cursed, much less something like
| Smalltalk. At this point in my career, I have given up and am
| just going to use Python and C++ like everyone wants you to. It's
| been a big enough hurdle yo probe that Incan write in Python and
| C++ despite having used a plethora of languages.
|
| So, how do you use these powerful platforms banished to personal
| projects? How does one get into a position such that you can
| dictate the platforms used? Is there anyone who has done this?
|
| It's an unfortunate case of people having the interesting
| applications having a very tunnel visioned view of what could be
| with software.
| shaunxcode wrote:
| It's all about doing. Next time you need to prototype something
| do it in your ideal language (this is the crux as you need to
| knock it out of the park). The next phase is showing how much
| more work it would have been in blub. The final phase is being
| prepared and capable enough to teach your co-workers!
| bluGill wrote:
| Real programmers can write Fortran in any language.
|
| I don't write Fortran, but I can make my C++ look a lot like a
| different language. Knowing how those other languages work
| makes my code better. Sure the C++ syntax is ugly, but the
| design is what matters and that take inspiration from languages
| other than C++.
| bmitc wrote:
| > Real programmers can write Fortran in any language. I don't
| write Fortran, but I can make my C++ look a lot like a
| different language.
|
| That sounds like the wrong thing to do and a nightmare to
| encounter. I guess I'm not a "real programmer", which
| bolsters my original point.
|
| > Knowing how those other languages work makes my code
| better.
|
| Knowing is good. But it goes both ways as well. But C++ devs
| are fairly notorious for not liking different things. See
| Rust's history.
|
| > Sure the C++ syntax is ugly, but the design is what matters
| and that take inspiration from languages other than C++.
|
| The syntax isn't the point, or is at least a minor one. The
| main point is that languages like C++ make designing harder
| than it needs to be. Also, in a language like C++, nearly
| anything can happen at any moment. It's like rolling dice for
| every function call. God may play dice, but I don't like to.
| bowsamic wrote:
| I recommend that you stop loving your tools and focus on
| solving problems.
| Barrin92 wrote:
| paraphrasing Russ Ackoff, intelligent people don't aim to
| solve problems but to dissolve them, and the best way to do
| this is to build whatever it is you're building on excellent
| tools. We would have significantly fewer problems in the
| world of software if people started paying attention to the
| quality and mastery of their tools.
| bowsamic wrote:
| The issue is that programmers often focus on the aesthetic
| aspects of their tools. They like smalltalk and lisp
| because they are somehow elegant and beautiful. However
| this is a red herring. The only metric that should be
| considered is how effective the tool is for solving the
| problem. Discerning between utility and aesthetics of a
| tool is an essential skill for any programmer to learn
| bmitc wrote:
| No one brought up aesthetics except for you.
| d_tr wrote:
| Speaking for myself, utility plays a big role in how I
| perceive a tool in terms of aesthetics. It's not only
| about a language's grammar fitting in a business card and
| stuff like that.
|
| Python and JavaScript are two languages that have been
| used for stuff they are obviously unsuitable for, in a
| vast scale.
| bmitc wrote:
| > Russ Ackoff
|
| Which book of his should I start with? Thanks for the
| reference.
| bmitc wrote:
| And I ask, why not both? It's gonna be a rough day at the job
| site hanging dry wall with a screwdriver.
|
| There isn't some dichotomy that makes us choose between good
| tools and solving problems.
| bowsamic wrote:
| A screwdriver is not effective at that job, that's the
| whole point. A good tool is a suitable and effective tool,
| not necessarily an aesthetically pleasant tool. Beauty of
| the tool is not a relevant metric
| bmitc wrote:
| I have no idea what you're talking about. You said to
| stop worrying about tools, and I gave an example where
| the tool does indeed matter, and then you agree with me
| but act like you're disagreeing.
|
| > A good tool is a suitable and effective tool, not
| necessarily an aesthetically pleasant tool. Beauty of the
| tool is not a relevant metric
|
| No one is hinging upon aesthetics. They simply come with
| tools that have been purposefully designed. I might
| suggest reading some architecture books, from the older
| architects like Frank Lloyd Wright, or books on complex
| systems about the relationship between form and function.
| narag wrote:
| I won't say that the platform is irrelevant, but not the main
| problem.
|
| You need to be so much more productive than the rest that,
| after following the usual useless mandatory hypertrophied
| process, you still have time to apply a sane problem-solving
| strategy.
|
| That means: make your own tools for the platform you're forced
| to use.
| bmitc wrote:
| > You need to be so much more productive than the rest that
|
| In my personal experience, one would be surprised about how
| little that (productivity) matters to people. In my
| experience, tools are primarily dictated by those less
| experienced or even unknowlegeable. Thus, their criterion is
| based upon what they've heard of and what they perceive
| theirself and others being comfortable with.
| SomeoneFromCA wrote:
| GNU Smalltalk is nice for writing small scripts, has TCL-like
| feel to it, while being a "real" programming language.
| Qem wrote:
| Is it actively developed? Tried to use it once, but the class
| browser didn't work under Ubuntu or Debian. At least not in the
| version available at the repositories.
| slim wrote:
| can I have more of this ? I mean smalltalk dev writing code while
| explaining
___________________________________________________________________
(page generated 2024-01-14 23:00 UTC)