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.
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.
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.
> complex engineering problems where the data model is inherently very complex, Smalltalk can really help
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)?
This. And also Smalltalk is so succinct and has simple syntax, that one can "see the wood for the trees" when dealing with an inherently complex data model. I am unfraid for example of a long multi-pronged inheritance hierarchy of classes in Smalltalk, as its still reasonably easy to see what's going on, and there isn't a huge amount of code, whereas in other languages that'd be a nightmare. Java is notorious for that but actually that'd be bad in Python too
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.
Ruby's object model is based on Smalltalk's so I wouldn't expect much of a difference. And Elixir, courtesy of Erlang, has a "model the world through communicating processes" model which strongly mirrors the Smalltalk model. So developing a program in each of these languages can be, though doesn't have to be, very similar in style. With a focus on communicating entities (be they processes or objects) allowing them to manage their own state over time in response to messages from other entities.
It does, as neither Elixir nor Ruby (Ruby even less) give the same developer experience.
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...
"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)?" - I'd say Smalltalk's really nice simple development environment, with the debugger being super easy to use, saves your bacon here. I always found it very easy indeed to inspect code, find out what it's doing. And there was less code in the first place. I think you raise a valid concern, but other strengths of the language and its development environment make this less of an issue than it might be. Somewhat hard to explain - best to download Pharo, read Pharo By Example, and have a play :)
>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.
>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"...
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.
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.
Python has multithreading, they just don't run concurrently. Which may or may not be suitable for your application. E.g. you can't simultaneously utilize multiple cores, but you can listen to several blocking IO bound tasks.
That's not technically correct: you can use the multiprocessing library (or the concurrent.futures one, for a more ergonomic api) to spawn cpython processes over multiple cores.
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).
Come on... ad populum appeal is not a strong one. And you can run most Smalltalk distros with a headless option. Let's not pretend using it for IDE is the same as deployed to production. Be fair.
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.
First, I agree Pythons lambdas are an abomination.
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.
> 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.
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!
> If you are going to use a top 5 popular programming language like the rest, your results are going to be average.
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.
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.
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.
The big lie about "No-code" systems like this is -- you're still coding, but without text. you have to click around in some obscure, usually proprietary interface to create every object and define its interactions with every other object. You end up with a big (usually binary) construct that doesn't lend itself to revision control or reuse, and building it requires a ton of knowledge about the toolset.
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
Absolutely. And, this idea is not at all new. Here's an example from the early 90s of a similar thing. https://en.wikipedia.org/wiki/Shlaer–Mellor_method. It was tried on projects, then failed to deliver. Some people at the time asked Qs like "How would one debug the code that has been generated from UML models?" and were waved aside. EDIT - its the automatic generation of code from that methodology that I particularly took issue with, although, not a big fan either of tons of custom UML-like diagrams
I was unhappy with my answer above right after I sent it, but that's pretty much how it goes in 2023 speak.
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
> 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.
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.
It's a tough claim to say that modern software development cannot be done with a language without HM typing facilities as first class, when most software development is done without it.
What means "strong typing" is very well defined. But most understandings I found do not allow implicit null returns to be "strong" typing. Also: the "strong" thing is at odds with the "dynamic" thing, you cannot have both.
To his credit, I think I first heard about Pharo, and got my foot in the doorway to the Smalltalk world thanks to one of his posts. People mock languages that have lots of newbies asking stupid questions in the Internet, but in the end of the day, given programmers are mortal, if your favorite language has a noob to guru ratio smaller than one, that means it is stale, dead or dying. Even in this thread there's people claiming they never heard about Smalltalk before. For me that means that evangelism efforts like Richard's could benefit the Smalltalk community a lot. There's a lack of awareness in the broader programming community about it, and that's unfortunate.
Since he speaks as positively about Smalltalk than about the Chinese Communist Party I'd indeed question that. But it might be better than just silence.
I think Ruby is an acceptable Smalltalk (also an acceptable Perl), with a better syntax. Last Rails project I worked on I had a console open up whenever I run into an exception, allowing me to monkey-patch the problem right away: that's about as much live-coding as I need professionally.
I haven't been part of the Ruby community in a few years - Market demand forced me out of full time Ruby/Rails and into React/JS/TS land. Is Pry still a thing? I remember being able to drop into IRB via Pry within a running Rails process was extremely powerful and (IMHO) way better than any debugger I have ever used.
Yes, the Rails console runs pry. It is indeed very powerful. My only gripe with it is that when you modify your code, you have to run ‘reload!’ and wait for the entire shebang to rebuild itself. This is opposed to Lisp REPLs where you can send individual expressions into the image with a simple key chord. But again, most of the value is there.
>Market demand forced me out of full time Ruby/Rails and into React/JS/TS land
I refused to go all into the React/JS/TS and since I had some leverage to choose the tech I chose Elm for the front-end in my new job where I inherited a Java code base (that's now mostly Kotlin).
I love Smalltalk but image saving is overrated. It suffers all the cache inconsistency pathologies in the long run. Many things need to be as stateless as possible to scale properly.
I honestly don't think that it's the tech stack that will make or break most startups in any sector really. I mean, of course, unless you are trying to solve some very specific tech problem then you will need the right tool but if you're in that position you're really not going to be looking at programming languages for their simplicity.
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.
First, time to market with the right thing is crucial. Time to market with the wrong thing doesn't matter at all.
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.
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.
I don't appreciate the criticisms in the article made to languages that have problems which are artefacts of their popularity.
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.
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.
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.
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).
Meaning that if we cargo-cult the alleged (and probably overhyped) development rationale of Twitter-like startups, we are implicitly banking on their "It's a rocket ship to the moon or nothing, baby!" growth plans as well.
No viable position for most companies (or even most startups) to take.
And at an early startup, making the damn thing work is all that really matters.
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.
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.
If we are pedantic all code running in a computer is numeric, but I get your point for gpu calculations for pytorch or numba, so I won't make that point :)
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.
> 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.
That's after they had already made billions with Ruby and, BTW, Patrick Collison is still passionate about Ruby and has no plans to drop it even at Stripe's scale. No-one says Ruby will cater for all scaling scenarios but it can take you a long way with the advantage of moving quickly and developer happiness. Twitter started with Ruby and nothing stopped them form switching to Scala when the time was right. What is more common than ditching Ruby is splitting-off services to be written in a faster language. Best of both worlds. Your designation of Ruby as an inferior language begs the question inferior to what and inferior by what metric?
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.
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.
> 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
> 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.
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.
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.
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.
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.
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?
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.
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.
> How easy would it be to create a Flash product competing with Adobe's current online offerings back then it Flash existed?
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.
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.
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.
In my experience getting a company to function is mostly about things like people, vision, marketing, and when it comes to coding that starts with understanding how data should flow so the next step is usually not decisions about a language or database but what existing contextually relevant data processing tools to leverage. Often the best libraries and frameworks to consider support several languages but that is not always the case. And different product elements may use different tools as needed with the user interface being inevitably necessary and a world in itself that does not necessarily strongly shape how the back end generates, stores, and finds data.
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.
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 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...
> 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?
All of this is also applicable to Lua, which offers all the same advantages and has the extra bonus of being very widely deployed, with tons of 3rd-party support, in a variety of different markets.
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.
Smalltalk is fun, but after having programmed with it for a year (Pharo only), I don't fully agree with the hype. And in certain cases, I feel the hype is undersold. But I'd love a bit more nuance. In my opinion, if you really want to convince the hardcore crowd on anything: nuance as best you can so people have an accurate sense of what they're getting into. I can talk a lot more about Smalltalk, but this comment got big enough as it is. I think in certain cases it can definitely be a secret weapon.
> 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 th...
Last time I played with Smalltalk, most computers were single core. What is the current multi-threading situation in Smalltalk? Can I spawn a thread to send an object a message, which in turn might send more messages in their own threads?
More than once I thought it'd be cool to have each in-flight message assigned to a separate thread, dispatched asynchronously when you don't assign the message response to anything (or in the same thread as the caller when not), and see how it goes on processors with hundreds of cores.
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++.
There was a financial services company that created a stock transfer service in smalltalk in the mid to late 90's; apparently they had some folks who were very forward thinking. They used IBMs visual age products. The product had some initial success, landed a few customers. But ultimately languished and was shut down. I don't have information on what happened, failure was probably due to mismanagement more than technology. I was at the company after those events, and management was inept to say the least. So that's one data point.
Where to begin - libraries, frameworks, hiring, third party APIs. Is there even a decent PostgreSQL driver for Smalltalk? Ecosystems matter much more than languages when you want to move fast.
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.)
148 comments
[ 2.3 ms ] story [ 193 ms ] threadThe "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.
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)?
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...
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.
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.
and this: https://tonyg.github.io/squeak-actors/
In practice though, processes are usually good enough.
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).
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
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!
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.
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.
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.
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
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.
In Smalltalk, nil is an instance of UndefinedObject and responds to that protocol. Sending it a different message results in a DNU.
https://en.wikipedia.org/wiki/Strong_and_weak_typing
"Gradual typing for Smalltalk"
https://www.johanfabry.be/assets/allendeAl-scp2014.pdf
>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?
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.
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.
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.
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.
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.
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.
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).
No viable position for most companies (or even most startups) to take.
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.
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.
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).
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.
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
> 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'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.
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.
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
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.
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.
> 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.
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.
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.
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.
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...
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?
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.
> 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 th...
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....
I wonder if that was intentional.
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.
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.)
https://www.youtube.com/watch?v=v1CmGbOGb2I
So what?
Any learning resources?