5 ms·

From my understanding, to adopt Smalltalk, I’d have to give up my editor, my SCM, my code review practises, my deployment strategies, my whole way of working. L

by mikl 6y ago

From my understanding, to adopt Smalltalk, I’d have to give up my editor, my SCM, my code review practises, my deployment strategies, my whole way of working. Learning a new language is already a big ask. If you then also require the would-be adopter to change everything around the language, everything about how they work, don’t be surprised if people choose something else. I think a modern parallel is darklang.com. It might be great, but it faces the same resistance for the same reasons. You can do some amazing things if you integrate everything into a big monolith, but that also makes it impossible to adopt a technology part-way.

cmrdporcupine 6y ago
Indeed, for Smalltalk-80 and its cousins at least. There were/are versions of Smalltalk that integrated better with the OS, but classic Smalltalk's vision was always to _be_ the OS and surrounding tools, really. Perhaps Smalltalk was too far ahead of its time at the time it initially appeared. The computing machinery of the age couldn't run it efficiently enough. If they had, it just might have displaced everything else. At the time there really were no IDEs, no good SCM, no review tools, etc. And so it could have made that world in its image, which at the time was frankly superior. But for the broader point, yes -- Smalltalk does not play well with others. I'm sure it can be made to, but that was not its first instinct.
non-entity 6y ago
I'd almost be willing, but im still not sure I "get" smalltalk. I mean sure, I've started to understand why people talk so highly of the language but the whole sandboxxed environment feels like a outdated relic from the time it was created and makes it look today like nothing more than a toy. It feels like a concept that just doesn't realistically fit in the world of software today. I want to like Smalltalk but I just can't ever see it being an option even for most of my side projects.
- ragnese 6y ago
  I don't know. A bunch of people are writing Electron apps. That's surely also a sandbox, right?
  - chris_st 6y ago
    Kind of... but, to quote the grandposter, I don't "have to give up my editor, my SCM, my code review practises, my deployment strategies, my whole way of working." It's just JavaScript, I get to bring my React/Vue/Vanilla.js workflow and the kajillion (for better or worse) npm libraries. And, I get a double-clickable app that runs on Windows, MacOS, and Linux. Last I looked there wasn't an open-source way to do this with smalltalk.
    - ragnese 6y ago
      But the one I replied to said that he/she would "almost" be willing to give all that up, except something-something-sandbox.
plafl 6y ago
So you need to make a new language similar enough to preexisting ones but on the other hand it should give you noticeable more power to justify the change. It's a very hard to solve problem.
- evgen 6y ago
  The activation energy required to make someone give up everything familiar and proven to (mostly) work in order to use a new language is huge, so it would need to offer a lot. OTOH, a language that only needed you to replace a few of your daily conventions and practices Could offer less and still get you to give it a try. All-or-nothing is a losing proposition for convincing someone to give a new language a try.
tluyben2 6y ago
> I’d have to give up my editor, my SCM, my code review practises, my deployment strategies, my whole way of working This is bad? Everything (besides maybe reviews) is horribly broken for most (modern) dev, so not sure it's a negative to just nuke it from orbit.
- ReactiveJelly 6y ago
  Every other language works fine with Kate and Git, my favorite editor and SCM. Having fewer options is not inherently good.
  - tluyben2 6y ago
    No, but some people have to try. You are not mainstream, but the amount of people who think vscode is a lightweight and stable editor is slightly painful. Working every day with 100s of people seeing them killing/restarting is some sign we generally just gave up. Taking the current low bar as 'good enough' (or even great as some people seem to think it is) is definitely not a good think imho.
    - waheoo 6y ago
      When I ask why something isn't working with typescript in vscode at work people recommend restarting the language server with a keybind. I'd send them a table flip emoji but im pretty sure they wouldn't get it, they legitimately think they're giving me good helpful advice. They simply don't understand that if you need to restart something, said something is fucking broken.
      - im3w1l 6y ago
        Having to restart the language server is surely a disadvantage, but why make it be a dealbreaker? Maybe they see it as a cost worth paying?
        throwaway_pdp09 6y ago
andi999 6y ago
And you cannot deploy it easily...
- cmrdporcupine 6y ago
  This is an interesting argument in an era where people now deploy Docker, etc. images as their deployment strategy. That looks suspiciously similar to the Smalltalk image model. I'm not a Smalltalk fan really (though it's neat) but it was doing "containers" quite intensely long before anybody else.
  - mcguire 6y ago
    A Smalltalk image runs Smalltalk. A Docker image can run an app written in JS, C++, Python, Haskell, brainfuck, whatever. Smalltalk was not doing containers.
discreteevent 6y ago
I would give up everything if someone could give me a completely consistent universe. For example if everything I came across was automatable via SQL I would take it. All the time wasted not solving my problem on e.g. linux, filesystems, config files, bash, docker, kubernetes, rest, git, programming languages ...
- skohan 6y ago
  I would say the two closest programming ecosystems I have found to this are Rust/Cargo and Node/NPM. With either of these tools, it seems quite dependable to clone a git repo, and get it up and running in minutes or even seconds with a couple consistent commands. That is as long as the dependencies are fully rooted within the ecosystem.
swyx 6y ago
i think darklang at least gives u infrastructure as you adopt it. so a better value proposition than smalltalk.
projektfu 6y ago
I’m now curious about implementing a long running Smalltalk server that can be accessed using command line tools and traditional editors, with some graphical or web based tools to implement inspectors and other UI.
- greggyb 6y ago
  You're not far off from describing various lisp modes on emacs. Not trying to derail, but just share some existing art in the space. Take a look at SLIME+swank for Common Lisp, or Geiser for Scheme, or Cider for Clojure. A common architectural choice is to have a REPL buffer in Emacs, connected over a socket to the language runtime which hosts the REPL. You edit a text file, sending whatever portion of your program you want to the REPL, where it is evaluated in the runtime, with results printed back to the REPL buffer. There are advanced introspection and documentation workflows supported by being connected to a live REPL. These protocols easily and transparently cross the network, so you have the ability to troubleshoot a production issue on a (hopefully previously-quarantined) production host exhibiting the issue. You can inspect state, recompile functions on the fly and replay the failure all from the comfort of an editor and REPL that you are familiar with from dev-time.
- scroot 6y ago
  There is GNU Smalltalk, but I don't think it has a big community at the moment. What you are describing, though, is conceptually easy enough to implement: modern Smalltalks (Squeak, Pharo, and friends) all have robust interfaces to Unix and stdin/stdout. You could easily create a repl. It's also easy to make TCP, HTTP, or WebSocket servers, so you can create interaction that way as well. And of course there is Seaside, which has some tools already for interacting with a Smalltalk image through the browser. Another approach is Amber Smalltalk, which is a web-based Smalltalk for frontend development (amber-lang.net)
  - projektfu 6y ago
    Yeah, I’m thinking along these lines. Just packing it up so it works in the flow.
- 6y ago
Rochus 6y ago
Not necessarily. There is a nice, file-based Smalltalk dialect called SOM (Simple Object Machine) by the people from Denmark who also developed JS V8. There are implementations based on C/C++, JVM and Truffle, see http://som-st.github.io/ http://som-st.github.io/ for more information. I currently implement yet another version based on LuaJIT, see https://github.com/rochus-keller/som/#a-som-to-lua-transpiler-with-luajit-based-vm https://github.com/rochus-keller/som/#a-som-to-lua-transpile.... You can use your favorite editor etc. and don't depend on all-including virtual image like e.g. Smalltalk-80. In contrast to e.g. GNU Smalltalk (which is also file-based) SOM is completely independent of the Bluebook interpreter and doesn't inherit its disadvantages. I had a close look at both and also implemented a Smalltalk-80 VM (see https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk). When it comes to performance optimization it's much easier with SOM than with a Bluebook based machine.
jdboyd 6y ago
Giving up your editor to tough, so I'll come back to that. I believe that Pharo and some other smalltalks no longer require giving up Git[1], and by extension, I assume that would allow keeping any git based review strategies. Some deployment strategies can also be kept largely intact[2][3], but I don't know what you give up by doing so. In those links, a lot of things aren't done how I would do them, but I can see how to adopt what is shown there to my preferred deployment tools. Getting back to giving up your editor. It should be possible to use many editors with the smalltalk of your choice. However, in practice, there are many half finished and abandoned tools for doing so[4], and fighting with that while learning the system is unlikely to be productive. [1] https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg [2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/DeploymentWeb/DeployForProduction.html https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBo... [3] https://www.slideshare.net/umejava/dockerizing-pharo https://www.slideshare.net/umejava/dockerizing-pharo [4] https://dmitrymatveev.co.uk/shampoo/ https://dmitrymatveev.co.uk/shampoo/
fulafel 6y ago
> I think a modern parallel is darklang.com. It might be great, but it faces the same resistance for the same reasons. They work similarly on the surface level, but the tradeoffs are quite far apart. The deployless nature of Dark on the backend is the central big benefit, and it's a distinction that doesn't exist when you are developing local GUI apps. Also, in Dark there isn't a peristent VM image that everything is entangled with, not to mention the lack of entanglement inherent in the FP language.

by mikl 6y ago

cmrdporcupine 6y ago

Indeed, for Smalltalk-80 and its cousins at least. There were/are versions of Smalltalk that integrated better with the OS, but classic Smalltalk's vision was always to _be_ the OS and surrounding tools, really. Perhaps Smalltalk was too far ahead of its time at the time it initially appeared. The computing machinery of the age couldn't run it efficiently enough. If they had, it just might have displaced everything else. At the time there really were no IDEs, no good SCM, no review tools, etc. And so it could have made that world in its image, which at the time was frankly superior. But for the broader point, yes -- Smalltalk does not play well with others. I'm sure it can be made to, but that was not its first instinct.

non-entity 6y ago

I'd almost be willing, but im still not sure I "get" smalltalk. I mean sure, I've started to understand why people talk so highly of the language but the whole sandboxxed environment feels like a outdated relic from the time it was created and makes it look today like nothing more than a toy. It feels like a concept that just doesn't realistically fit in the world of software today. I want to like Smalltalk but I just can't ever see it being an option even for most of my side projects.

ragnese 6y ago
I don't know. A bunch of people are writing Electron apps. That's surely also a sandbox, right?
- chris_st 6y ago
  Kind of... but, to quote the grandposter, I don't "have to give up my editor, my SCM, my code review practises, my deployment strategies, my whole way of working." It's just JavaScript, I get to bring my React/Vue/Vanilla.js workflow and the kajillion (for better or worse) npm libraries. And, I get a double-clickable app that runs on Windows, MacOS, and Linux. Last I looked there wasn't an open-source way to do this with smalltalk.
  - ragnese 6y ago
    But the one I replied to said that he/she would "almost" be willing to give all that up, except something-something-sandbox.

plafl 6y ago

So you need to make a new language similar enough to preexisting ones but on the other hand it should give you noticeable more power to justify the change. It's a very hard to solve problem.

evgen 6y ago
The activation energy required to make someone give up everything familiar and proven to (mostly) work in order to use a new language is huge, so it would need to offer a lot. OTOH, a language that only needed you to replace a few of your daily conventions and practices Could offer less and still get you to give it a try. All-or-nothing is a losing proposition for convincing someone to give a new language a try.

tluyben2 6y ago

> I’d have to give up my editor, my SCM, my code review practises, my deployment strategies, my whole way of working This is bad? Everything (besides maybe reviews) is horribly broken for most (modern) dev, so not sure it's a negative to just nuke it from orbit.

ReactiveJelly 6y ago
Every other language works fine with Kate and Git, my favorite editor and SCM. Having fewer options is not inherently good.
- tluyben2 6y ago
  No, but some people have to try. You are not mainstream, but the amount of people who think vscode is a lightweight and stable editor is slightly painful. Working every day with 100s of people seeing them killing/restarting is some sign we generally just gave up. Taking the current low bar as 'good enough' (or even great as some people seem to think it is) is definitely not a good think imho.
  - waheoo 6y ago
    When I ask why something isn't working with typescript in vscode at work people recommend restarting the language server with a keybind. I'd send them a table flip emoji but im pretty sure they wouldn't get it, they legitimately think they're giving me good helpful advice. They simply don't understand that if you need to restart something, said something is fucking broken.
    - im3w1l 6y ago
      Having to restart the language server is surely a disadvantage, but why make it be a dealbreaker? Maybe they see it as a cost worth paying?
      - throwaway_pdp09 6y ago

andi999 6y ago

And you cannot deploy it easily...

cmrdporcupine 6y ago
This is an interesting argument in an era where people now deploy Docker, etc. images as their deployment strategy. That looks suspiciously similar to the Smalltalk image model. I'm not a Smalltalk fan really (though it's neat) but it was doing "containers" quite intensely long before anybody else.
- mcguire 6y ago
  A Smalltalk image runs Smalltalk. A Docker image can run an app written in JS, C++, Python, Haskell, brainfuck, whatever. Smalltalk was not doing containers.

discreteevent 6y ago

I would give up everything if someone could give me a completely consistent universe. For example if everything I came across was automatable via SQL I would take it. All the time wasted not solving my problem on e.g. linux, filesystems, config files, bash, docker, kubernetes, rest, git, programming languages ...

skohan 6y ago
I would say the two closest programming ecosystems I have found to this are Rust/Cargo and Node/NPM. With either of these tools, it seems quite dependable to clone a git repo, and get it up and running in minutes or even seconds with a couple consistent commands. That is as long as the dependencies are fully rooted within the ecosystem.

swyx 6y ago

i think darklang at least gives u infrastructure as you adopt it. so a better value proposition than smalltalk.

projektfu 6y ago

I’m now curious about implementing a long running Smalltalk server that can be accessed using command line tools and traditional editors, with some graphical or web based tools to implement inspectors and other UI.

greggyb 6y ago
You're not far off from describing various lisp modes on emacs. Not trying to derail, but just share some existing art in the space. Take a look at SLIME+swank for Common Lisp, or Geiser for Scheme, or Cider for Clojure. A common architectural choice is to have a REPL buffer in Emacs, connected over a socket to the language runtime which hosts the REPL. You edit a text file, sending whatever portion of your program you want to the REPL, where it is evaluated in the runtime, with results printed back to the REPL buffer. There are advanced introspection and documentation workflows supported by being connected to a live REPL. These protocols easily and transparently cross the network, so you have the ability to troubleshoot a production issue on a (hopefully previously-quarantined) production host exhibiting the issue. You can inspect state, recompile functions on the fly and replay the failure all from the comfort of an editor and REPL that you are familiar with from dev-time.
scroot 6y ago
There is GNU Smalltalk, but I don't think it has a big community at the moment. What you are describing, though, is conceptually easy enough to implement: modern Smalltalks (Squeak, Pharo, and friends) all have robust interfaces to Unix and stdin/stdout. You could easily create a repl. It's also easy to make TCP, HTTP, or WebSocket servers, so you can create interaction that way as well. And of course there is Seaside, which has some tools already for interacting with a Smalltalk image through the browser. Another approach is Amber Smalltalk, which is a web-based Smalltalk for frontend development (amber-lang.net)
- projektfu 6y ago
  Yeah, I’m thinking along these lines. Just packing it up so it works in the flow.
6y ago

Rochus 6y ago

Not necessarily. There is a nice, file-based Smalltalk dialect called SOM (Simple Object Machine) by the people from Denmark who also developed JS V8. There are implementations based on C/C++, JVM and Truffle, see http://som-st.github.io/ http://som-st.github.io/ for more information. I currently implement yet another version based on LuaJIT, see https://github.com/rochus-keller/som/#a-som-to-lua-transpiler-with-luajit-based-vm https://github.com/rochus-keller/som/#a-som-to-lua-transpile.... You can use your favorite editor etc. and don't depend on all-including virtual image like e.g. Smalltalk-80. In contrast to e.g. GNU Smalltalk (which is also file-based) SOM is completely independent of the Bluebook interpreter and doesn't inherit its disadvantages. I had a close look at both and also implemented a Smalltalk-80 VM (see https://github.com/rochus-keller/Smalltalk https://github.com/rochus-keller/Smalltalk). When it comes to performance optimization it's much easier with SOM than with a Bluebook based machine.

jdboyd 6y ago

Giving up your editor to tough, so I'll come back to that. I believe that Pharo and some other smalltalks no longer require giving up Git[1], and by extension, I assume that would allow keeping any git based review strategies. Some deployment strategies can also be kept largely intact[2][3], but I don't know what you give up by doing so. In those links, a lot of things aren't done how I would do them, but I can see how to adopt what is shown there to my preferred deployment tools. Getting back to giving up your editor. It should be possible to use many editors with the smalltalk of your choice. However, in practice, there are many half finished and abandoned tools for doing so[4], and fighting with that while learning the system is unlikely to be productive. [1] https://github.com/pharo-vcs/iceberg https://github.com/pharo-vcs/iceberg [2] https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuccessfulBuild/artifact/book-result/DeploymentWeb/DeployForProduction.html https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBo... [3] https://www.slideshare.net/umejava/dockerizing-pharo https://www.slideshare.net/umejava/dockerizing-pharo [4] https://dmitrymatveev.co.uk/shampoo/ https://dmitrymatveev.co.uk/shampoo/

fulafel 6y ago

> I think a modern parallel is darklang.com. It might be great, but it faces the same resistance for the same reasons. They work similarly on the surface level, but the tradeoffs are quite far apart. The deployless nature of Dark on the backend is the central big benefit, and it's a distinction that doesn't exist when you are developing local GUI apps. Also, in Dark there isn't a peristent VM image that everything is entangled with, not to mention the lack of entanglement inherent in the FP language.