You read that and think “wow”, but then you walk your own walk and realize that the programming language is mostly irrelevant here (and you better have chosen python and/or js for their eco). What makes companies fast is not a language, though it may help in a peculiar way. What makes companies fast is, essentially, not hiring the industry people. Both smalltalk and lisp help with that greatly.
It doesn’t matter if you can write two pages of clever code to stay competitive. Because a workday has 8-12 hours and writing ten pages of a dumb code isn’t that hard either. The hard part is to stop doing overengineering, defensive programming, daily refactorings and other things which suit a departments-and-teams-with-managers structure so good, because you have to avoid that structure to stay fast. Esoteric langs just work as a natural safety barrier here.
All of the above is a personal anecdotal opinion of a regular developer who worked in a fast company. I’m not pretending to be wise or complete here or to have a wide experience, it’s just my observation of dynamics of a company that tried to always stay fast (because of founder’s nature), observation wrt to that pg article.
Ps. Sometimes I start to think that it’s all a conspiracy (jk). Because people who advocate for doing things fast are the same people who invented programming religions like DRY, patterns, higher order something paradigms, etc. First you learn how to do all of that, then you learn how to unlearn all of that and just write the fucking code. Sometimes I sit and think like what can I do, like what’s my value if I write dumb straightforward code? Anyone can do that. But then I remind myself that I can write dumb straightforward code and you can not.
I poked around with Smalltalk recently. The language fits of a postcard. Great, but so what? How do I input and output from files, and all the other stuff that I want to do?
I also think Racket suffers from the same problem. The libraries are documented, but how do I use them to do something?
The advantages of mainstream languages is that they have a plethora of documentation.
I'd say that if you want your language to succeed, adopt a cookbook approach. Nobody wants to figure out how all the pieces of the jigsaw should be put together.
For all that, I don't think anyone has really come up with anything better than C++, Python, or similar (Rust, if you /must/).
uhm? Every Smalltalk environment I know have great documentation, integrated right in the environment, and it is a better than Python for a beginner (I have been using Python since 1.6.1; I did Smalltalk professionally in the late 90s); surely much better than C++ or Rust.
The paradigm is different, so if you expect file-based interactions(*), you are approaching it wrong.
I just downloaded Pharo, run the current stable image 10.0, and the first thing that pops out is a "Welcome" window with links to
- https://mooc.pharo.org/
- A "Learn Pharo" section tells me to click on a link "ProfStef go." to learn the basics.
- Another one tells me to run "HelpBrowser open." to see the in-image documentation.
- In the help browser itself, I can find more tutorials and even a tutorial on how to make them.
- If I open any System Browser and filter the packages for "Examples" or "Tutorial", I get more stuff too. If I search for "Tests", I can read a lot more. Naturally, everything is hyperlinked and navigable like you'd get in a IDE for another language.
- If I open a System Browser, I can click on any package and get a UML class diagram for the package. Classes have comments, like python doc strings.
How do I open a file? I haven't touched Smallktalk in 20 years. I just opened a System Browser, searched packages for "File". Look there is a Files package with a File class. What does the comment say (the 2nd comment tab, which is formatted)? Examples of usage, how to open and write, encoding, buffering, etc. I can click on any method and then on "Senders"to see how it is used.
Then I remembered from 20 years ago, there should be a faster way to get there, so I just opened a transcript window and typed "File", selected it and Cmd-B (browse) to get to the class
---
I don't advocate Pharo or any Smalltalk environment but the reasons are not related the quality of its environment, just that developers are very hard to find and most support is moving on.
It's funny because I would almost say the same but to actually make the case *for* Smalltalk and not against it. And precisely for the same reasons.
I'm using Smalltalk in both the startup and corporate world and it's a good fit for both. Main current challenges are not in the language or tech stack if you architect the right thing for each case. The main challenges are in finding what's your path to walk a profitable road that makes you incrementally grow without too much drama.
Well, I think many developers can forget patterns, over abstractions, SOLID, clean coding, overengineering, scrum and write lots of quick and dirty code at a startup.
It's just that trying to do that at their current workplace will result in a backlash.
I don't overengineer the code I write at home in weekends.
The point of things like DRY is that, if you don't do them, they can slow you down in the long term. You can forget all that and be really fast in the short term. And, if you're just focused on surviving the next six months, that can be what you need to do. But the six months after that may be slower, as the messes you made in the first six months start to have an effect.
Choosing a language for the ecosystem: You should choose languages for their all-things-considered fit for what you're trying to do. Ecosystem is part of it. The programmers you can get (or do you have to train?) are part of it. Another part is, what things make it difficult to write the program that you're trying to write? Memory management? Multithreading? Networking? Certain languages may do certain parts of that for you, and that part of the difficulty just... goes away. Pick the language that, all things considered, makes it easiest to write the program that you need to write.
I work for a Fortune 200 company and our backlog is so vast we don't have the time to engineer anything, let along over engineer anything!
Do you think we care about refactoring, DRY, patterns and all that software engineering stuff? Hell no! Ain't got time for that nonsense!
As an "archiveloper" (architect who also rolls up their sleeves and develops) I advise my developers to adhere to the KISS methodology - Keep It Stupid-Simple. We take a super pragmatic approach, not worrying about what's "cool." We use Python in AWS. Why? Are solutions are all "server-less" and it became clear that Python is AWS' preferred language for server-less development, though they never explicitly say that anywhere.
KISS allows you to quickly get today's work done without creating problems you have to contend with tomorrow. Our whole goal is to get more done while creating fewer problems.
> The hard part is to stop doing overengineering, defensive programming, daily refactorings and other things which suit a departments-and-teams-with-managers structure so good
JS maybe (well TS, not JS; you'd be a fool to use actually JS) but I've seen more than a few projects strangled by their choice of Python and the terrible performance it comes with.
People always say "it doesn't need to be fast"... until it does and it's too late. Or "we'll write the bottlenecks in C++"... until you realise that it's all bottleneck.
Mercurial and Scons are obvious public examples.
Language does make a difference, despite everyone being polite and saying it doesn't. Of course that doesn't mean it is the only or even biggest factor.
> This talk introduces liballocs, an infrastructure which exposes the dynamism hiding in the arcane linking and debugging infrastructure of a Unix process, along with a small extension to C toolchains that enables fast dynamic access to data created by statically compiled code. Together they can be said to unleash a "hidden Smalltalk" inside the C and Unix model of programs and processes. Come prepared for a journey that takes your perceptions of the boundaries between dynamic and static languages and turns them on its head.
I think they elaborated in the remainder of their comment. The point seems to be that following patterns and programming for future use necessarily slows you down because it detracts from just making the damn thing work right now.
And at an early startup, making the damn thing work is all that really matters. (I'm at a laterish startup and we do attempt to follow some process and patterns where it would structure things enough to enable cleaner onboarding as we grow).
This reads like a Smalltalk hype-man (like the guys hyping a rapper) - I think I've read this guy before on ST topics.
The "secret weapon" angle dismisses languages in wide use for all kinds of superficial reasons that didn't hurt major adoption across startups, unicorns, and huge companies like Google and Amazon.
e.g.:
"Python has many peculiarities in its design, especially with respect to object-oriented programming. Its multithreading capability is crippled by the GIL (global interpreter lock). Its lambdas are oddly restricted to single expressions. Its half-open intervals are unintuitive"
"Java is extremely verbose. It’s more awkward to use than Python. C# is Java on steroids."
etc.
while sidestepping major Smalltalk issues - first and foremost the lack of a wide and mature ecosystem of libs and a non-frequently-breaking-compatibility FOSS Smalltalk, or the lack of programmers to hire.
Well, he probably is an Smalltalk evangelist but I don't see this as something bad.
"The secret weapon" I think makes reference to Paul Graham's essay Beating the average: http://www.paulgraham.com/avg.html and he probably thinks that Smalltalk gives the same kind of "unfair advantage" as Lisp did in Paul Graham's article.
Having done some Smalltalk development, I can confirm for certain sorts of problems e:g complex engineering problems where the data model is inherently very complex, Smalltalk can really help to the point of being game-changing and allowing people to even attack certain problems at all in the first place. But Smalltalk's image-based dev, and lack of integration with the rest of the ecosystem, really hinders too! Smalltalk is both a blessing and a curse. I'd say for most companies Smalltalk doesn't give an advantage because most companies aren't actually solving problems that are all that complex. Its specific niche problems Smalltalk is good at. And even then, you'd have to do without things like numpy or scipy, i:e other languages have better more powerful libraries at your disposal. You could kind of cobble things together, get Smalltalk to call out to other languages to use their libraries, but that does start to get messy. One thing I would still use Smalltalk for would be pure computer science research. Its good for modelling things.
In fairness however, Cincom develops and dells a commercial/proprietary Smalltalk implementation... you'll hardly see somebody saying "yeah our software is a pile of garbage" in their product/company website.
What's often overlooked is that Viaweb was developed, as I recall, in the late 90s when the Internet was in its infancy and there were far less libraries than we have today which made hand-rolling everything in Common Lisp more viable.
>Well, he probably is an Smalltalk evangelist but I don't see this as something bad
Surely, not bad. Smalltalk could use far more adoption again!
But in his case, he isn't also giving the full unbiased picture, so it's more of a "marketing man/evangelist" than an "objective adopter/evangelist"...
I really like Smalltalk but basically he fails to explain what the added value of Smalltalk would be over Python as a baseline.
GIL is inconvenient but the times I was really limited by it are few. Lambdas are not Smalltalk blocks, but you can just define a local function and refer to it by name. This is like a block, the only thing you need to do is to bind the block to a name. Indentation-based syntax is not everyones preference (even not mine), but not using indentation is not a super power.
What I would say is a primary selling point of Smalltalk to this day is the seamless development experience with Class Browser/Editor/Playground/TestExecution.
A good example in this space was DabbleDB[1], a low-code environment for producing web apps that did CRUD type stuff. Their original video demo: https://www.youtube.com/watch?v=MCVj5RZOqwY
I was pretty impressed when it came out. The UI was very intuitive, and it did a better job with things like table relations than it's competitors. They were also releasing new features based on requests faster than what I typically saw. It happened to have used the Seaside web framework mentioned in the article.
Sadly, Twitter purchased it and shut it down...I assume they just wanted the team and not the product.
one of the amazing things about smalltalk was that it used continuations to track the user as they navigated and used the system. at a time before javascript ate the world, it was pretty revolutionary. the hard part was that you needed to maintain sticky sessions where a user would be directed to the same machine.
nowadays, you can get a lot of the same benefits using elixir phoenix with liveview. And unlike smalltalk, the BEAM is uniquely suited for providing a dedicated thread per user. arguably, elixir implements a type of OO thats more in the spirit of alan kay's original design to boot.
Twitter didn't shut them down because they wanted the team, they just wanted to destroy the product.
Undermining products which threaten them is the policy of the major corporations. It was a space they were not ready to enter so they destroyed the product.
It is the same reason why they destroyed Flash rather than fix it faults. More than 10 years later HTML5 does not match Flash in productivity.
Flash meant end users couldn't be locked into their app stores, and even to this date Apple is crippling Safari to undermine web based apps.
This reads like paranoia... Twitter had nothing to gain or lose from controlling the fate of DabbleDB. Chances are they were on a classic, mindless acquisition spree, and Dabble folks saw their chance to make bank.
> It is the same reason why they destroyed Flash
Lol, Flash destroyed itself. Adobe thought they could forever extract rent from Flash's early gains, slowing development momentum in order to assimilate it in their products and processes; and then they underestimated the power of Apple's influence on the web ecosystem.
My vague recollection is that, after DabbleDB, they were working on a new product - some sort of analytics dashboard (?) - they did an early demo of it, and I gather someone at Twitter saw this and thought "oh wow, we need those guys working for us".
I suspect DabbleDB as a product, and its existing user base, was irrelevant in this decision.
Since i was introduced to lisp, this is my number 1 desire everytime i write code. The js ecosystem gets a lot of hate but the power of some of the browser tooling coupled with some kinds of hot reloading (specifically the kind that maintains state), it can be super nice to work with.
EDIT: To be clear this isn't as powerful as the lisp version of this - i.e. the condition system and just the nature of how cheap/fast/quick changing code is in lisp while it's running, not the approximation way this is done in JS by stopping, swapping and potentially reinitialising
>> Smalltalk’s image also makes software deployment a breeze
When i started playing with lisp this was one of my first concerns, how do i deploy this? I was dreaming up all these rube goldberg scenarios with OCI container images. Turns out it's easy to tell sbcl to create an image (save-lisp-and-die - this would be like publishing a fat jar for a java dev) then to run that elsewhere (sbcl --core).
Everytime i poke at podman and buildah, i have this nagging annoying feeling about how much simpler this could all be.
You can get 90% of the coveted "Lisp machine experience" with a modern IDE that does hot reloading in its debugger. Today, tooling matters much more than the language itself; and the tooling around modern languages is very advanced and powerful, having had more great minds working on it than Lisp and Smalltalk ever had.
The Lisp Machine experience has obvious drawbacks, but there are things that are simply not there on modern platforms (with some exceptions, like a Smalltalk on the metal). Its OS is completely written in a high-level language, it uses a high-level OOP model (for example based on the Flavors / CLOS object systems) and running inside one memory pool.
Receiving an TCP packet is a OOP method, just like sending a mail is an OOP message. In the development environment both are fully visible, on the fly changeable, ... If I'm debugging an NFS connection, I could change a UDP method on the fly and it will be immediately active system wide - without any 'hotloading' limitations.
You can mostly edit/change everything in the OS and applications without boundaries. That offers countless ways to kill the system, but it means that the TCP implementation is open in the same way like an application is - it can always be used without much performance loss in a full debug mode, where things can be inspected, modified, replaced, edited, ... This is not hotloading of a component, it is a completely open architecture an all levels - from a mailer UI, over the SMTP implementation, the networking stack, down to the network interface. There is a single high-level stack and everything on the stack is accessible/inspectable. One is bringing the thing into a debug mode or deploying it in a debug mode, it can always run fully inspectable and changeable. As mentioned the drawback is that this makes it also fragile when there are very little protections. Make a wrong change to the UDP receive method and the running OS then won't receive any UDP packages...
Pick the best IDE hot reloading experience you know of - for me that's JRebel so not actually provided by my IDE but available to me there and way more powerful than the hot swapping natively available in the JVM and usually exposed to me through intellij IDE. E.g. i can change the arity of a function with jrebel but not with hot swapping in intellij.
Compare that experience with editing my code and inline without starting any companion process, without triggering any hotreload function, without even saving my source file, being able to evaluate the results of changing a function and seeing the results either inline or in a dedicated buffer depending on the keystroke i chose to trigger the evaluation.
I'm doing a terrible job of explaining the difference i see - what i'm digging at is the lisp approach is completely frictionless. The JRebel experience which is great, the best i know if in a non-lisp language, is full of little (and some large) frictions.
>> tooling matters much more than the language itself
I'd suggest a counterpoint to that, the tooling for java is really very good - and yet, there's a better experience to be had with "structural editing of forms" in clojure than there is going back to "normal editing of lines of code" with java.
I think most languages i've experienced can be interchanged to a large degree - java, javascript, c#, c, rust, python, ... unless the task is something exotic, i can probably complete the same task in any of those in a comparable way.
Lisp, SQL, prolog and array languages are different though. The way i would solve the task in those is likely to be radically different in approach.
We have very different experiences then - hot reloading almost never works in native development, unless the language and ecosystem have been designed around it. Which is not really the reality we live in.
It's nowhere close to "90%" when most projects cannot be reloaded.
> The js ecosystem gets a lot of hate but the power of some of the browser tooling
As a JS developer, this is what really irks me: we have this powerful, interactive, live JS-enabled environment (the browser) that also holds our application. It has great debugging and inspection tools. Why can't we develop our applications live inside the browser? Why do I have to go off to some other tool?
The two main reasons I see to do a startup in Smalltalk are:
1. You really love Smalltalk, and you'll be able to execute quickly, and be happy doing it.
2. You want to be able to hire some top programmers, and one way is to pick a beloved fringe technology that attracts top programmers disproportionately (in this case, Smalltalk, but companies can also do this with CL, Scheme, Racket, Haskell, OCaml, Rust, etc.).
(My love for Smalltalk goes back to the early-'90s, https://www.neilvandyke.org/smalltalk-chg/ , and in the mid-'90s I put together a proposal to use Smalltalk for Brown's intro CS courses. Today, if I didn't have to make money, and could just do research, I'd probably instead make some changes to Scheme/Racket, or get more comfortable with Rust, since I like both, but for very different reasons.)
I wanted to try Smalltalk, but information, documentation and examples are scarce. I am mostly interested in backend development. Most online resources I've seen are YouTube videos about Allan Kay and Xerox in the '70s.
In the backend feels great. As the powerful monolith microservice that absorbs easily all the complexity you throw at it and allows you to adapt naturally.
Readit News
It doesn’t matter if you can write two pages of clever code to stay competitive. Because a workday has 8-12 hours and writing ten pages of a dumb code isn’t that hard either. The hard part is to stop doing overengineering, defensive programming, daily refactorings and other things which suit a departments-and-teams-with-managers structure so good, because you have to avoid that structure to stay fast. Esoteric langs just work as a natural safety barrier here.
All of the above is a personal anecdotal opinion of a regular developer who worked in a fast company. I’m not pretending to be wise or complete here or to have a wide experience, it’s just my observation of dynamics of a company that tried to always stay fast (because of founder’s nature), observation wrt to that pg article.
Ps. Sometimes I start to think that it’s all a conspiracy (jk). Because people who advocate for doing things fast are the same people who invented programming religions like DRY, patterns, higher order something paradigms, etc. First you learn how to do all of that, then you learn how to unlearn all of that and just write the fucking code. Sometimes I sit and think like what can I do, like what’s my value if I write dumb straightforward code? Anyone can do that. But then I remind myself that I can write dumb straightforward code and you can not.
I also think Racket suffers from the same problem. The libraries are documented, but how do I use them to do something?
The advantages of mainstream languages is that they have a plethora of documentation.
I'd say that if you want your language to succeed, adopt a cookbook approach. Nobody wants to figure out how all the pieces of the jigsaw should be put together.
For all that, I don't think anyone has really come up with anything better than C++, Python, or similar (Rust, if you /must/).
The paradigm is different, so if you expect file-based interactions(*), you are approaching it wrong.
I just downloaded Pharo, run the current stable image 10.0, and the first thing that pops out is a "Welcome" window with links to - https://mooc.pharo.org/
- http://books.pharo.org/
- A "Learn Pharo" section tells me to click on a link "ProfStef go." to learn the basics.
- Another one tells me to run "HelpBrowser open." to see the in-image documentation.
- In the help browser itself, I can find more tutorials and even a tutorial on how to make them.
- If I open any System Browser and filter the packages for "Examples" or "Tutorial", I get more stuff too. If I search for "Tests", I can read a lot more. Naturally, everything is hyperlinked and navigable like you'd get in a IDE for another language.
- If I open a System Browser, I can click on any package and get a UML class diagram for the package. Classes have comments, like python doc strings.
How do I open a file? I haven't touched Smallktalk in 20 years. I just opened a System Browser, searched packages for "File". Look there is a Files package with a File class. What does the comment say (the 2nd comment tab, which is formatted)? Examples of usage, how to open and write, encoding, buffering, etc. I can click on any method and then on "Senders"to see how it is used.
Then I remembered from 20 years ago, there should be a faster way to get there, so I just opened a transcript window and typed "File", selected it and Cmd-B (browse) to get to the class
---
I don't advocate Pharo or any Smalltalk environment but the reasons are not related the quality of its environment, just that developers are very hard to find and most support is moving on.
---
What has much better documentation?
I'd say Wolfram Mathematica.
The documentation is very extensive and consistent, you can see it online at https://reference.wolfram.com/language/
But if you open it from within Mathematica, it is also editable: you can change the code and execute it at any step.
e.g. you can open the documentation for https://reference.wolfram.com/language/ref/FindTextualAnswer...
and instead of doing:
question = "Who was the architect of the Sagrada Familia?"; articles = WikipediaData /@ WikipediaSearch["Content" -> question]; FindTextualAnswer[articles, question, 5, {"Probability", "HighlightedSentence"}]
You want to ask "Who was the architect of Florence cathedral?"
You can change that and see what happens.
And since Mathematica is a symbolic language that is not limited by text input, you can copy any data structure or graphic (e.g. the graphs on https://reference.wolfram.com/language/ref/FindShortestPath.... Basic Examples and run code on that).
I'm using Smalltalk in both the startup and corporate world and it's a good fit for both. Main current challenges are not in the language or tech stack if you architect the right thing for each case. The main challenges are in finding what's your path to walk a profitable road that makes you incrementally grow without too much drama.
It's just that trying to do that at their current workplace will result in a backlash.
I don't overengineer the code I write at home in weekends.
Choosing a language for the ecosystem: You should choose languages for their all-things-considered fit for what you're trying to do. Ecosystem is part of it. The programmers you can get (or do you have to train?) are part of it. Another part is, what things make it difficult to write the program that you're trying to write? Memory management? Multithreading? Networking? Certain languages may do certain parts of that for you, and that part of the difficulty just... goes away. Pick the language that, all things considered, makes it easiest to write the program that you need to write.
Do you think we care about refactoring, DRY, patterns and all that software engineering stuff? Hell no! Ain't got time for that nonsense!
As an "archiveloper" (architect who also rolls up their sleeves and develops) I advise my developers to adhere to the KISS methodology - Keep It Stupid-Simple. We take a super pragmatic approach, not worrying about what's "cool." We use Python in AWS. Why? Are solutions are all "server-less" and it became clear that Python is AWS' preferred language for server-less development, though they never explicitly say that anywhere.
KISS allows you to quickly get today's work done without creating problems you have to contend with tomorrow. Our whole goal is to get more done while creating fewer problems.
This.
In another post[1] I made similar comment
> Your code is useless if no one is using it.
[1] https://news.ycombinator.com/item?id=35157049
JS maybe (well TS, not JS; you'd be a fool to use actually JS) but I've seen more than a few projects strangled by their choice of Python and the terrible performance it comes with.
People always say "it doesn't need to be fast"... until it does and it's too late. Or "we'll write the bottlenecks in C++"... until you realise that it's all bottleneck.
Mercurial and Scons are obvious public examples.
Language does make a difference, despite everyone being polite and saying it doesn't. Of course that doesn't mean it is the only or even biggest factor.
Isn't this exactly how python works with pytorch, polars, and similar very fast libraries?
> This talk introduces liballocs, an infrastructure which exposes the dynamism hiding in the arcane linking and debugging infrastructure of a Unix process, along with a small extension to C toolchains that enables fast dynamic access to data created by statically compiled code. Together they can be said to unleash a "hidden Smalltalk" inside the C and Unix model of programs and processes. Come prepared for a journey that takes your perceptions of the boundaries between dynamic and static languages and turns them on its head.
An interesting, and a fairly broad observation. Can you elaborate?
And at an early startup, making the damn thing work is all that really matters. (I'm at a laterish startup and we do attempt to follow some process and patterns where it would structure things enough to enable cleaner onboarding as we grow).
The "secret weapon" angle dismisses languages in wide use for all kinds of superficial reasons that didn't hurt major adoption across startups, unicorns, and huge companies like Google and Amazon.
e.g.:
"Python has many peculiarities in its design, especially with respect to object-oriented programming. Its multithreading capability is crippled by the GIL (global interpreter lock). Its lambdas are oddly restricted to single expressions. Its half-open intervals are unintuitive"
"Java is extremely verbose. It’s more awkward to use than Python. C# is Java on steroids."
etc.
while sidestepping major Smalltalk issues - first and foremost the lack of a wide and mature ecosystem of libs and a non-frequently-breaking-compatibility FOSS Smalltalk, or the lack of programmers to hire.
"The secret weapon" I think makes reference to Paul Graham's essay Beating the average: http://www.paulgraham.com/avg.html and he probably thinks that Smalltalk gives the same kind of "unfair advantage" as Lisp did in Paul Graham's article.
According to some studies, Smalltalk seems to be very productive: https://www.cincomsmalltalk.com/main/2022/07/need-productivi...
http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty...
In fairness however, Cincom develops and dells a commercial/proprietary Smalltalk implementation... you'll hardly see somebody saying "yeah our software is a pile of garbage" in their product/company website.
Surely, not bad. Smalltalk could use far more adoption again!
But in his case, he isn't also giving the full unbiased picture, so it's more of a "marketing man/evangelist" than an "objective adopter/evangelist"...
GIL is inconvenient but the times I was really limited by it are few. Lambdas are not Smalltalk blocks, but you can just define a local function and refer to it by name. This is like a block, the only thing you need to do is to bind the block to a name. Indentation-based syntax is not everyones preference (even not mine), but not using indentation is not a super power.
What I would say is a primary selling point of Smalltalk to this day is the seamless development experience with Class Browser/Editor/Playground/TestExecution.
I was pretty impressed when it came out. The UI was very intuitive, and it did a better job with things like table relations than it's competitors. They were also releasing new features based on requests faster than what I typically saw. It happened to have used the Seaside web framework mentioned in the article.
Sadly, Twitter purchased it and shut it down...I assume they just wanted the team and not the product.
[1] https://en.wikipedia.org/wiki/Dabble_DB
nowadays, you can get a lot of the same benefits using elixir phoenix with liveview. And unlike smalltalk, the BEAM is uniquely suited for providing a dedicated thread per user. arguably, elixir implements a type of OO thats more in the spirit of alan kay's original design to boot.
Undermining products which threaten them is the policy of the major corporations. It was a space they were not ready to enter so they destroyed the product.
It is the same reason why they destroyed Flash rather than fix it faults. More than 10 years later HTML5 does not match Flash in productivity.
Flash meant end users couldn't be locked into their app stores, and even to this date Apple is crippling Safari to undermine web based apps.
> It is the same reason why they destroyed Flash
Lol, Flash destroyed itself. Adobe thought they could forever extract rent from Flash's early gains, slowing development momentum in order to assimilate it in their products and processes; and then they underestimated the power of Apple's influence on the web ecosystem.
I suspect DabbleDB as a product, and its existing user base, was irrelevant in this decision.
Since i was introduced to lisp, this is my number 1 desire everytime i write code. The js ecosystem gets a lot of hate but the power of some of the browser tooling coupled with some kinds of hot reloading (specifically the kind that maintains state), it can be super nice to work with.
EDIT: To be clear this isn't as powerful as the lisp version of this - i.e. the condition system and just the nature of how cheap/fast/quick changing code is in lisp while it's running, not the approximation way this is done in JS by stopping, swapping and potentially reinitialising
>> Smalltalk’s image also makes software deployment a breeze
When i started playing with lisp this was one of my first concerns, how do i deploy this? I was dreaming up all these rube goldberg scenarios with OCI container images. Turns out it's easy to tell sbcl to create an image (save-lisp-and-die - this would be like publishing a fat jar for a java dev) then to run that elsewhere (sbcl --core).
Everytime i poke at podman and buildah, i have this nagging annoying feeling about how much simpler this could all be.
Receiving an TCP packet is a OOP method, just like sending a mail is an OOP message. In the development environment both are fully visible, on the fly changeable, ... If I'm debugging an NFS connection, I could change a UDP method on the fly and it will be immediately active system wide - without any 'hotloading' limitations.
You can mostly edit/change everything in the OS and applications without boundaries. That offers countless ways to kill the system, but it means that the TCP implementation is open in the same way like an application is - it can always be used without much performance loss in a full debug mode, where things can be inspected, modified, replaced, edited, ... This is not hotloading of a component, it is a completely open architecture an all levels - from a mailer UI, over the SMTP implementation, the networking stack, down to the network interface. There is a single high-level stack and everything on the stack is accessible/inspectable. One is bringing the thing into a debug mode or deploying it in a debug mode, it can always run fully inspectable and changeable. As mentioned the drawback is that this makes it also fragile when there are very little protections. Make a wrong change to the UDP receive method and the running OS then won't receive any UDP packages...
Pick the best IDE hot reloading experience you know of - for me that's JRebel so not actually provided by my IDE but available to me there and way more powerful than the hot swapping natively available in the JVM and usually exposed to me through intellij IDE. E.g. i can change the arity of a function with jrebel but not with hot swapping in intellij.
Compare that experience with editing my code and inline without starting any companion process, without triggering any hotreload function, without even saving my source file, being able to evaluate the results of changing a function and seeing the results either inline or in a dedicated buffer depending on the keystroke i chose to trigger the evaluation.
I'm doing a terrible job of explaining the difference i see - what i'm digging at is the lisp approach is completely frictionless. The JRebel experience which is great, the best i know if in a non-lisp language, is full of little (and some large) frictions.
>> tooling matters much more than the language itself
I'd suggest a counterpoint to that, the tooling for java is really very good - and yet, there's a better experience to be had with "structural editing of forms" in clojure than there is going back to "normal editing of lines of code" with java.
I think most languages i've experienced can be interchanged to a large degree - java, javascript, c#, c, rust, python, ... unless the task is something exotic, i can probably complete the same task in any of those in a comparable way.
Lisp, SQL, prolog and array languages are different though. The way i would solve the task in those is likely to be radically different in approach.
It's nowhere close to "90%" when most projects cannot be reloaded.
As a JS developer, this is what really irks me: we have this powerful, interactive, live JS-enabled environment (the browser) that also holds our application. It has great debugging and inspection tools. Why can't we develop our applications live inside the browser? Why do I have to go off to some other tool?
1. You really love Smalltalk, and you'll be able to execute quickly, and be happy doing it.
2. You want to be able to hire some top programmers, and one way is to pick a beloved fringe technology that attracts top programmers disproportionately (in this case, Smalltalk, but companies can also do this with CL, Scheme, Racket, Haskell, OCaml, Rust, etc.).
(My love for Smalltalk goes back to the early-'90s, https://www.neilvandyke.org/smalltalk-chg/ , and in the mid-'90s I put together a proposal to use Smalltalk for Brown's intro CS courses. Today, if I didn't have to make money, and could just do research, I'd probably instead make some changes to Scheme/Racket, or get more comfortable with Rust, since I like both, but for very different reasons.)
Smalltalk has a similar quality: fun.
I remember programming literally all night when I was working in smalltalk and decided to keep going until I got too frustrated to continue.
These seems to be advantages of Smalltalk:
-very easy to learn
-very productive
-live coding
About information and documentation, lots of free books are available at https://books.pharo.org/
I've blogged how to monitor them in production recently here https://blog.sebastiansastre.co/article/pharometer-on-tlig