Smalltalk: An Entrepreneur’s Secret Weapon? (2020)
richardeng.medium.com
richardeng.medium.com
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/
- 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.
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?
I would describe polars a library to work with data (https://www.pola.rs/). So we have a high-performance library in Python to work with generic data.
I think that covers a lot of cases, since you can transform arbitrary parts of a program into data. Ask any lisp fan.
Typescript is great, and the approach of having native high-performance modules works great for Python. You can offload, if you want to, a big part of your program to high-performance libraries. Maybe it is not the most elegant, but it works.
Python is not cpp, but if it fits your use-case, it can be quite performant.
https://stripe.com/blog/sorbet-stripes-type-checker-for-ruby
> Unfortunately we were starting to see Ruby come apart at the seams: new engineers found it hard to learn the codebase, and existing engineers were scared to make sweeping changes. Everyone faced a constant tradeoff: run the fast, local tests which might not catch many breakages, or run all the tests, even the slow ones. Ruby was becoming a source of friction more than a source of productivity.
I'm not saying you can't make good products with inferior languages.
> 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).
Not if it comes at the cost of making your co-workers hate you for the messes you continually leave behind. And to lose faith in upper management for holding you up to be a "rockstar" for doing so. And for them to start looking for new jobs, as a result.
The optimal level for basic hygiene and defense programming in a startup is -- perhaps a notch or two lower than in a staid, manager-driven post-startup company. But certainly not zero.
"The nose knows", as they say.
I love dumb, straightforward code BTW. It's my guiding aesthetic much of the time in fact. But that wasn't what I was referring to, here.
Rather the "too smart for its own good... and utterly brain-fucked" end product which is the calling card of your average rockstar / ninja developer.
No viable position for most companies (or even most startups) to take.
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...
Interesting, what are the features of smalltalk that make that possible? Wouldn't it be very similar to JS or Lisp for representing data?? Also, given its dynamic nature, doesn't it make very hard to wrap your head around complex code bases after they grow beyond what you can keep in your head at the same time (as any other dynamically typed language)?
That's just old wives tales. Static or dynamic types don't change whether you can keep the codebase "in your head at the same time". It just provides some static guarantees regarding some invariants.
There is an interesting aspect in there - the simpler and easier to do complicated stuff, the higher the odds of NIH syndrome: while nobody would try to reinvent the wheel in Java or C#, I've been tempted to reinvent partial wheels for my very own needs that squeak and wobble in very specific ways in such languages, just because it's so easy.
It's something in the same line as seeing traditional design patterns just vanish when the language syntax has features that make their implementation trivial. You may need a library for, say, observers in C++, but they are so easy to implement in Python or Smalltalk that you'd feel no need to use something pre-built for that.
Elixir/Erlang has the messaging idea too, and Ruby has some of that model, but there's nowhere clear to how Smalltalk implements it, working withing the image/IDE, the introspection capabilities and so on...
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.
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.
How easy would it be to create a Flash product competing with Adobe's current online offerings back then it Flash existed? The simply truth is that any of Adobe's competitors could have developed an even before Adobe decided to rent their software.
To what extent would software developers depend on Apple's app store if high quality applications could be delivered through the browser?
What would happen to the 30% tax Google and Apple levy on app store sales?
Mozilla even started via Shumway then canned it because they are in Google's pocket.
Did Microsoft's Silverlight have these problems?
Why has HTML5 turned out to be such a horrible after more than a decade? It still has nothing on Flash.
I'm amazed about the kind of economic blindness that exists among "developers" which for the most part means people trying to force square pegs into round holes that characterizes web based development.
They did, Silverlight was it. MS pushed it as hard as they could, and... it bombed. Because it had the same problems as Flash, which most developers already reviled: it produced proprietary, black-box binary blobs that only one vendor knew how to run properly, and it presented big security and performance challenges.
Meanwhile, plain old html was something that everyone could work with, as long as the spec was public. The browser had a hard sandbox and very well-delimited capabilities. And that worked just fine, before Chrome ate the marketshare (thanks in no small part to Mozilla losing the plot, chasing ghosts in the OS space while Firefox floundered).
> Why has HTML5 turned out to be such a horrible after more than a decade?
Because shit is hard and browsers have different priorities.
> I'm amazed about the kind of economic blindness
Says the one with a broken website.
I suspect DabbleDB as a product, and its existing user base, was irrelevant in this decision.
https://blog.twitter.com/official/en_us/a/2010/more-than-dab...
Which companies own the online data analysis tools market now?
Why couldn't Twitter continue with the products development back then?
Did they truly consider their contribution of those employees to their company more valuable than the potential of the product, or were they against the product falling into hands of another company?
Meaning more like what Airtable does.
I don't think Twitter ever had any plans for that space.
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
I will confess, I did not know Smalltalk even existed and when I read this headline I thought it might be referencing the ability to make... well, small talk with people. And to that I did think "that might make sense to me". Because it seems like being able to communicate your ideas, entertain and keep people engaged might be very useful tools to have as an entrepreneur, after all, people need to buy into your idea to begin with.
I really think a lot of these advice pieces are just... garbage really? I mean there's good resources out there for start ups but everything that pretends to be a secret weapon, a canned solution to success is always going to be nothing but fishy clickbait. If you want to get serious about it then of course, the tech stack might matter and of course this website being tech oriented we are going to be a bit bias towards it... but the secret sauce is probably everything but the tech stack you choose for your app. In reality, if you want to be an entrepreneur in tech you probably already are capable of doing an MVP in python or javascript. And if you're not, then it might be smarter to partner up with someone that knows.
That's sad, because Smalltalk is the grandfather of modern (or arguably all) OOP languages and is referenced in a lot of famous OOP books. I've never used it, but I remember a lot of folks talking about it in very reverential terms when Java first came to the scene. From what I understand, it was largely killed by bad commercial choices that restricted adoption until it was too late to matter.
The biggest impact was when one of the biggest Smalltalk vendors, IBM, decided to reboot their Smalltalk business into Java.
Some of these problems are merely cosmetic, which doesn't mean they are to be dismissed, but the very choices those languages took were either a result of some school of thought being demanded by the market, or they created that school of thought themselves. That would cover mainly syntax and verbosity/explicitness choices.
He mentions the GIL. Well, this is a well-known Python limitation because... Python has a particular implementation in CPython that is extremely popular, and they made the choice to focus in making every running Python process being relatively fast as a single thread, which turned out to be a good compromise combined with micro-services. Perhaps it was even partly a catalyst of the trend. But by no means this is the only Python implementation, it's just an extremely popular one that needs to be taken into account. Smalltalk doesn't have this problem to have any single implementation that is so popular, it became an externality and people needed to account for its choices.
But on the positive side, I agree with the sentiment that in order to beat the averages, popularity of your tools shouldn't be the deciding choice.
There's a reason why some (powerful, useful) languages remain "secret weapons": they have characteristics that are out of step with the mainstream. But this itself is not a bad thing. Smalltalk, Common Lisp, Scheme/Chicken/Gambit/Racket etc will remain secret weapons with a focus on creation and in not being part of the rat race, while others will be more focused in industrialisation, large team management, etc. The mainstream has to do that pretty much by definition. And outsiders will have the advantage of not having this burden on top of them.
It does appear to me that many startups decide to start off with what they anticipate it will be a good choice once they are big, prematurely. Facebook started as PHP spaghetti code. The main thing is that it has to work, and it has to allow you to move fast. Scale comes later, especially so nowadays with so many scaling solutions on the hardware side that will let you survive early hits in popularity, a problem most people would wish for.
"That was true in 2003 and is not true in 2023" might be a reasonable response, but having a solid idea of why would probably pay off.
Time to market is crucial.
Second, time to market matters, but it does not follow that language matters. The GP's claim was that language didn't dramatically affect either your ability to build the right thing, or the time it took to do so. You need more than five words to refute that.
It does, though, because it teaches you what the right thing is. The more you can throw at the wall, the more sticks.
>Market demand forced me out of full time Ruby/Rails and into React/JS/TS land
Same, what a terrible fate we’ve met.
Not as much as I've wondered it about the JVM, though.
And in the short run?
For example, by using this cleverly you would have something very much like NodeJs https://github.com/pharo-contributions/taskit
I'm sure some post-grad somewhere used this to procure a monster workstation.
RoarVM, formerly known as the Renaissance Virtual Machine (RVM) is developed as part of a IBM Research project to investigate programming paradigms and languages for manycore systems of the future. Specifically, this VM is meant to support manycore systems with more than 1000 cores in the future.
The RVM was open sourced by IBM Research under the Eclipse Public License. Please see the open source announcement for further information.
Today, the RoarVM supports the parallel execution of Smalltalk programs on x86 compatible multicore systems and Tilera TILE64-based manycore systems. It is tested with standard Squeak 4.1 closure-enabled images, and with a stripped down version of a MVC-based Squeak 3.9 image.
The RoarVM provides parallel execution of Smalltalk processes and thus, the programming model is a typical shared-memory model similar to Java with its threads and classical Pthreads for C/C++. noob to guru ratio smaller than one
true & false not
& (nil isNil)
:ifFalse
[self halt].
I wonder if that was intentional.
I've run rings around my fellow Java and C# devs by writing prototypes in Lua that end up being solid enough to be deployed. It really is such an amazing, powerful, underrated technology - especially in the right hands.
Typing? Null-safety? (bolted onto Java, by default in Kotlin)
Back in the 90s my professor would have failed me for saying that, as he felt so strongly that Smalltalk has no types and that any reference to types is not Smalltalk, but particular implementation details that account for performance optimisations and concrete references to the VM being used under the hood.
But in 2023 what types have grown to mean would pretty much include Smalltalk classes and those include all sorts of checks both in theory and in practice, right from coding-time (compile time not to be considered at all in Smalltalk) in the form of "respondsTo:" "is___", "isKindOf:" and the often avoidable "isMemberOf:"
What static typing has come to mean has also shifted a couple of times since the 90s. It's now mainly meant as a software engineering tool, and as such Smalltalk really doesn't have this problem as the function and classification of variables is so much richer and explicit in purist OO than it is in any modern popular language. In terms of efficiency, SmallTalk no longer competes mainly with assembly and C as it used to in the 70s, 80s and 90s but languages that also run VMs and have often a lot more overhead than the ST industry-standard VMs.
The kind of type magic that SmallTalk really is not designed to do, except perhaps as a system on top, is Hindley–Milner (HM) type systems. But those really only shine in Haskell, ML and related languages. Those are certainly also in the "secret weapon" category and will very likely remain there for quite a while for similar reasons as SmallTalk. Reasons that I mentioned in another comment: https://news.ycombinator.com/item?id=35165801#35167103
Again, table stakes. There was a whole HN thread about how a language that couldn't do sum types is not fit for use in modern software development.
"Gradual typing for Smalltalk"
In Smalltalk, nil is an instance of UndefinedObject and responds to that protocol. Sending it a different message results in a DNU.
BUT, your core assertion that Smalltalk should be given even a moments thought as a real language to implement 2023 applications in? That’s going too far. Literally any of the other languages you mention would be a better choice if only for the single reason that they are not dead.
Perhaps we should start writing to each other in Latin or hieroglyphics!
And the article was about Smalltalk being a secret weapon due to ease of use and productivity for start-ups. If you are going to use a top 5 popular programming language like the rest, your results are going to be average. And average start-ups don't survive.
Paul Graham nailed it well about using Lisp - which you probably think it's another dead language: http://www.paulgraham.com/avg.html
Come on, this is like "All the gear and no idea" marketing victims in weekend warrior sports. Someone on a bike they bought from the supermarket manages to flog me on my S-Works Venge?? That shouldn't be possible! I'm using the best tool!
This sounds like cargo cult thinking. It also sounds like thinking that will hamstring you as you either search for developers with obscure language experience or spend time bringing them up to speed on the language you use before they can even begin generating business value.
With Lisp, you can at least say that it might select for smarter developers, or at least ones with a more rigorous CS background.
You can't rank languages on a single one-dimensional axis labeled "power". Why? Start by asking the question, "Power to do what?" Well, duh, to write programs. "What programs?" Well, just general programs.
But I've never written a general program in my life. I've written a bunch of specific ones, though. What I care about is power to write this program. (Why do I care about how good a language is at writing programs that I'm not trying to write?)
There are a bunch of things that go into how good a language is at writing a specific program. Syntax. Libraries. Ecosystem. Availability of programmers who know the language. Maintainability. (If you think languages don't differ in terms of maintainability of programs written in them, work in COBOL for a while.) I should look at the language, and look at what I need to do to be able to write the program, and pick the language that, all things considered, will make it the easiest to write that program. The best language is going to vary from program to program.
And the reason it varies has nothing to do with the "Blub Paradox" or because we're too stupid to understand how wonderful some magical language is, either Lisp or Smalltalk.
That generalization seems hard to defend. I think you assign too much importance to choice of programming language.
For one thing, I'm confident that for each of the top five most popular languages right now (whatever those are—for sake of argument let's say Python, JavaScript/TypeScript, C/C++, Java, and something for .NET like C# probably) I could find counter examples of start-ups that YOU would consider to have better than "average results" implemented entirely in that language.
Wasn't Silicon Valley Bank one of "the best banks" and "too big to fail"?
There are plenty of moderately successful businesses out there that are fine with just surviving or moderately growing in their niche.
1. How does Smalltalk compare to Clojure / Babashka? 2. I'm writing alot of shell/bash-scripts (small utilities/tools), would Babashka be a viable replacement for medium-complexity shell scripts?
I don't think that's the case; e.g. GNU Smalltalk doesn't need any graphics https://www.gnu.org/software/smalltalk
> - No multithreading
I'd rephrase this as concurrency/parallelism. Multithreading is just one (particularly awful) way of implementing that; arguably Smalltalk would be better suited to an actor model (like Erlang).
and this: https://tonyg.github.io/squeak-actors/
In practice though, processes are usually good enough.
> The syntax is ridiculously simple. It can be learned in its entirety within 15 minutes!
Right, and then you learn that things like branches, loops and similar things are method calls. So it's not just the syntax you need to learn, the included libraries have things like: ifTrue:, ifTrue:ifFalse:, ifFalse:. There is also ifNil: and ifNotNil:. And IMO there are too many ways to do things. In order to be able to program, you need to learn these things as well.
> The second major benefit is Smalltalk’s live coding capability
The following issues are not all REPL issues but this quote made me think of the issues that I've encountered.
There have been two instances where it wasn't fully live. For example, when I played with Roassal, I couldn't single step the animation through (whereas in an old Smalltalk demo this actually is possible). Or in seaside: the moment where a dynamic variable can't be evaluated properly because it spawns a different process internally and doesn't give the same value as the original process. The only way to fix that is to create a temporary variable and inspect that variable. It's an okay workaround, but the live coding ability or that seamless feeling of you can evaluate anything everywhere and debug it (with debuggers in debuggers in debuggers in...), yea... not always. The moments where it's possible (95% of the time) it is indeed magical.
Also, why can't debuggers time travel? Like, is that too much to ask for a language that prides itself on being image-based / live everything / debug everything? I know people have worked on it, but I find it odd that it doesn't exist yet in the actual language. It must not be easy to make, but then again: many things of Pharo/Smalltalk have not been easy. This means it's a matter of priority. It should be higher.
> The third major benefit is Smalltalk’s purity, clarity, and consistency in its object-oriented model. Smalltalk is the easiest object-oriented language for this reason, far surpassing C++, C#, Java, Python, and Ruby.
Oh is it? I'd agree it is. But please stay objective though. Many things are played up as objects by the VM, but they aren't internally objects! I wouldn't know examples as I don't know the internals well enough, but I've talked to people that did on the Pharo Days. They told me. When you look in kernel code, there are pragma's just below the method signatures that betray this.
> Smalltalk’s object-oriented nature makes it supremely maintainable and scalable without the headaches imposed by other object-oriented languages.
It does, in my experience.
> The fourth major benefit is Smalltalk’s system image. The image is a snapshot of an application’s total execution environment. It allows you to save the execution state of your program and to resume execution later on at your convenience. This is terribly handy.
Well, be sure to back it up. It can also randomly crash. Text doesn't crash (though your text editor might. Hello VS Code ;-) ). The snapshot is amazing though. Going down the callstack and having every variable live, where I can interrogat- I mean interact with it. It's also awesome to put the debugger open live and just rewrite a method, replay the method and bam it works, debugger never closed. Can other languages do this? Probably. However, in Pharo this stuff is a first class citizen and you can feel it in the quickness of things (when it works that is, I already gave a few examples where it doesn't).
> Smalltalk’s image also makes software deployment a breeze. You never have to worry about installing and configuring the numerous software components (like libraries and frameworks) that constitute your application in production.
Well, for my scraper projects? Yes! True. For deploying a scalable web application? As far as I understand it: you have two options. You spin up hundreds of Smalltalk images that are ready to serve requests (yikes!). Or you use GemStone, which is another Smalltalk with an object-oriented DB designed for scalability. Smalltalks are mostly interoperable, until... they aren't! :D So there's a lot of glue code for the second option.
Though, I'll say this: for creating hackable games (that you can just live program and alter) and personal scrapers... Yea, deployment is amazing.
> For data science, you have tools like PolyMath, Roassal, and Moose. For machine learning, you can use TensorFlow and Keras.
Don't forget: https://github.com/pharo-ai :D
------
The cool stuff that isn't talked about enough. Programming in Pharo makes me look different at software. It makes me more critical of GUIs of text editors and makes me look more critical at file-oriented programming. I'm a JavaScript fan too, but I find it odd that the Chrome debugger doesn't offer text-editing out of the box. It should! You can somehow make it happen? Why not make it happen out of the box. If Pharo can, why not a big well-funded thing like Chrome?
I also like how Stackoverflow almost has no answers, so I need to think more deeply about my own answers. It molds me more into being an actual software engineer rather than a "call the function of this library please."
Also, you sometimes get confronted with the VM, so your "stack-depth" is deeper than most web dev as you'll inadvertently pickup some VM things, which is basically computer architecture stuff.
In short, Pharo cares more about cognitive ergonomy for the programmer. Other languages don't seem to do that, they seem to outsource that to tool makers. It's Apple vs any other PC (tight integration vs making something extensible). Both approaches are valid, but since the tightly integrated perspective is underrepresented in the programming realm, I'd love to see more attention to something such as Pharo or similar projects.
So don't back up the image snapshot, back up text, backup the Change Set:
https://cuis-smalltalk.github.io/TheCuisBook/The-Change-Set....
:backup the Change Log:
https://cuis-smalltalk.github.io/TheCuisBook/The-Change-Log....
Any learning resources?
See my Blog Post - What is No-Code, Why use No-Code?
https://www.onedb.online/blog/what_is_no_code_why_use_no_cod...
The only people attracted to these systems are people who 1) want to create software and 2) want to avoid learning how to create software
those two attributes describe the absolute worst software developers. Learning a programming language is only marginally more effort then learning to use these tools, but grants an infinite amount of utility and flexibility
So what?