8 ms·

Smalltalk: An Entrepreneur’s Secret Weapon? (2020)

93 points by DeathArrow 4y ago

coldtea 4y ago
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.
- DeathArrow 4y ago
  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 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-productivity-smalltalk-is-the-most-productive-programming-language/ https://www.cincomsmalltalk.com/main/2022/07/need-productivi... http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty...
  - znpy 4y ago
    > According to some studies, Smalltalk seems to be very productive: https://www.cincomsmalltalk.com/main/2022/07/need-productivi https://www.cincomsmalltalk.com/main/2022/07/need-productivi... 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.
  - nickd2001 4y ago
    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.
    - brabel 4y ago
      > 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)?
      - rbanffy 4y ago
        The way you model systems in ST, with objects and messages being passed between them, matches some physical models very closely.
        nickd2001 4y ago
        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
  - coldtea 4y ago
    >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"...
  - cutler 4y ago
    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.
- wirrbel 4y ago
  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.
uticus 4y ago
- No multithreading - Not popular - Requires graphics interaction
- DeathArrow 4y ago
  But Python is popular and has no multithreading.
  - a2800276 4y ago
    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.
    - DeathArrow 4y ago
      Well, that seems to be concurrency without parallelism. Smalltalk has concurrency, too, at least according to this: https://books.pharo.org/booklet-ConcurrentProgramming/ https://books.pharo.org/booklet-ConcurrentProgramming/ and this: https://tonyg.github.io/squeak-actors/ https://tonyg.github.io/squeak-actors/
    - toyg 4y ago
      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.
      - dontlaugh 4y ago
        It is technically correct, multiprocessing doesn't spawn threads and that has several important consequences. In practice though, processes are usually good enough.
- chriswarbo 4y ago
  > - Requires graphics interaction I don't think that's the case; e.g. GNU Smalltalk doesn't need any graphics https://www.gnu.org/software/smalltalk 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).
DeathArrow 4y ago
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. These seems to be advantages of Smalltalk: -very easy to learn -very productive -live coding
- Qem 4y ago
  Did you try the Pharo MOOC? It's a good starting place: https://mooc.pharo.org/ https://mooc.pharo.org/ About information and documentation, lots of free books are available at https://books.pharo.org/ https://books.pharo.org/
  - DeathArrow 4y ago
    Thank you for the links!
  - agumonkey 4y ago
    seconded, very good introduction to the smalltalk world, didn't regret a single second of it
- sebastianconcpt 4y ago
  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. I've blogged how to monitor them in production recently here https://blog.sebastiansastre.co/article/pharometer-on-tlig https://blog.sebastiansastre.co/article/pharometer-on-tlig
- pdxpatzer 4y ago
  Pharo can be daunting for a complete novice. Look into Cuis Smalltalk https://cuis.st/ https://cuis.st/ and The Cuis Book https://cuis-smalltalk.github.io/TheCuisBook/ https://cuis-smalltalk.github.io/TheCuisBook/
andrewstuart 4y ago
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!
- DeathArrow 4y ago
  Doesn't seem dead to me. https://pharo.org/success/ https://pharo.org/success/ 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 http://www.paulgraham.com/avg.html
  - deleted 4y ago
    [deleted]
  - frou_dh 4y ago
    > 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!
  - cfiggers 4y ago
    > 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.
garyclarke27 4y ago
In 2023 No-Code is an Entrepreneurs secret weapon. See my Blog Post - What is No-Code, Why use No-Code? https://www.onedb.online/blog/what_is_no_code_why_use_no_code https://www.onedb.online/blog/what_is_no_code_why_use_no_cod...
- bigfishrunning 4y ago
  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
  - nickd2001 4y ago
    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 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
cies 4y ago
> I can’t think of anything that Smalltalk hasn’t done compared to Python, JavaScript, and Java. Typing? Null-safety? (bolted onto Java, by default in Kotlin)
- muyuu 4y ago
  Smalltalk is dynamically but strongly typed
  - bitwize 4y ago
    Static typing is table stakes for a real-world software engineering language in 2023.
    - muyuu 4y ago
      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 https://news.ycombinator.com/item?id=35165801#35167103
gjvc 4y ago
This author "Richard Kenneth Eng" has done more damage than good to Smalltalk by his fanboy posts for the past few years.
- Qem 4y ago
  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.
  - sebastianconcpt 4y ago
    noob to guru ratio smaller than one That was a heavy one. Good point. Worth writing an essay or blog post elaborating on that.
- sebastianconcpt 4y ago
  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.
cies 4y ago
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.
- lobstrosity420 4y ago
  The Rails console is somewhat clunky but manages to deliver most of the value of a Lisp/Smalltalk REPL.
  - jtms 4y ago
    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.
    - lobstrosity420 4y ago
      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 Same, what a terrible fate we’ve met.
      - cies 4y ago
        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).
- regularfry 4y ago
  No image saving though. There have been times I've wondered why, and what the ruby world would look like if it had it. Not as much as I've wondered it about the JVM, though.
readthenotes1 4y ago
Christopher Alexander eventually gave his "quality without a name" that was essential to habitle structures: life. 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.
jerojero 4y ago
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.
- DeathArrow 4y ago
  >I honestly don't think that it's the tech stack that will make or break most startups in any sector really. Time to market is crucial.
  - AnimalMuppet 4y ago
    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.
    - regularfry 4y ago
blitzar 4y ago
Not knowing or giving a shit about the tech stack: A Successful Entrepreneur’s Secret Weapon
wruza 4y ago
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.
- DeathArrow 4y ago
  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.
- lisasays 4y ago
  What makes companies fast is, essentially, not hiring the industry people. An interesting, and a fairly broad observation. Can you elaborate?
  - 4y ago
tyingq 4y ago
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 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. [1] https://en.wikipedia.org/wiki/Dabble_DB https://en.wikipedia.org/wiki/Dabble_DB
- vfclists 4y ago
  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.
  - macmac 4y ago
    Do you have any evidence for Twitters motivation in this case? I don't see how dabbledb constituted even a theoretical threat to Twitter.
    - vfclists 4y ago
      Large companies may compete with each other but they will always join forces to screw the consumer. https://blog.twitter.com/official/en_us/a/2010/more-than-dabbling.html 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?
m0llusk 4y ago
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.
CraigJPerry 4y ago
>> live coding capability 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.
- regularfry 4y ago
  What frustrates me with `save-lisp-and-die` is the `-and-die`. It would be so much nicer not to have to stop the world.
- bitwize 4y ago
  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.
  - CraigJPerry 4y ago
    90% seems high. 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.
boffinAudio 4y ago
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.
melvinroest 4y ago
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 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 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.
scotty79 4y ago
true & false not & (nil isNil) :ifFalse [self halt]. when read aloud sounds like a poem. I wonder if that was intentional.
rbanffy 4y ago
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?
- sebastianconcpt 4y ago
  Only a few can take advantage of multi-core in one image. The rest would be the VM using 1 core (as in NodeJS) with the VM being multithreaded. For example, by using this cleverly you would have something very much like NodeJs https://github.com/pharo-contributions/taskit https://github.com/pharo-contributions/taskit
  - rbanffy 4y ago
    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.
    - sebastianconcpt 4y ago
      You sound like talking about https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM 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++.
throwaway1492 4y ago
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.
cutler 4y ago
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.
- xkriva11 4y ago
  https://github.com/svenvc/P3 https://github.com/svenvc/P3
neilv 4y ago
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/ 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.)
ohduran 4y ago
I feel like this post can nicely be complemented by Yaron Minsky's talk on why they chose OCaml as a programming language at Jane Street: https://www.youtube.com/watch?v=v1CmGbOGb2I https://www.youtube.com/watch?v=v1CmGbOGb2I
firemelt 4y ago
He talk ruby and php is declining meanwhile smalltalk are lesser than both So what?
anta40 4y ago
Mobile app dev here. How am I supposed to use Smalltalk to rewrite my apps? Previously used Java, now Kotlin. Any learning resources?
rsolva 4y ago
I'm LISP-curious and have just started exploring some of the many flavors. I have a few questions: 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?

93 points by DeathArrow 4y ago

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.

DeathArrow 4y ago
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 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-productivity-smalltalk-is-the-most-productive-programming-language/ https://www.cincomsmalltalk.com/main/2022/07/need-productivi... http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty-years-of-IFPUG.-Software-Economics-and-Function-Point-Metrics-Capers-Jones.pdf http://www.ifpug.org/wp-content/uploads/2017/04/IYSM.-Thirty...
- znpy 4y ago
  > According to some studies, Smalltalk seems to be very productive: https://www.cincomsmalltalk.com/main/2022/07/need-productivi https://www.cincomsmalltalk.com/main/2022/07/need-productivi... 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.
- nickd2001 4y ago
  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.
  - brabel 4y ago
    > 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)?
    - rbanffy 4y ago
      The way you model systems in ST, with objects and messages being passed between them, matches some physical models very closely.
      - nickd2001 4y ago
        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
- coldtea 4y ago
  >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"...
- cutler 4y ago
  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.
wirrbel 4y ago
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.

uticus 4y ago

- No multithreading - Not popular - Requires graphics interaction

DeathArrow 4y ago
But Python is popular and has no multithreading.
- a2800276 4y ago
  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.
  - DeathArrow 4y ago
    Well, that seems to be concurrency without parallelism. Smalltalk has concurrency, too, at least according to this: https://books.pharo.org/booklet-ConcurrentProgramming/ https://books.pharo.org/booklet-ConcurrentProgramming/ and this: https://tonyg.github.io/squeak-actors/ https://tonyg.github.io/squeak-actors/
  - toyg 4y ago
    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.
    - dontlaugh 4y ago
      It is technically correct, multiprocessing doesn't spawn threads and that has several important consequences. In practice though, processes are usually good enough.
chriswarbo 4y ago
> - Requires graphics interaction I don't think that's the case; e.g. GNU Smalltalk doesn't need any graphics https://www.gnu.org/software/smalltalk 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).

DeathArrow 4y ago

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. These seems to be advantages of Smalltalk: -very easy to learn -very productive -live coding

Qem 4y ago
Did you try the Pharo MOOC? It's a good starting place: https://mooc.pharo.org/ https://mooc.pharo.org/ About information and documentation, lots of free books are available at https://books.pharo.org/ https://books.pharo.org/
- DeathArrow 4y ago
  Thank you for the links!
- agumonkey 4y ago
  seconded, very good introduction to the smalltalk world, didn't regret a single second of it
sebastianconcpt 4y ago
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. I've blogged how to monitor them in production recently here https://blog.sebastiansastre.co/article/pharometer-on-tlig https://blog.sebastiansastre.co/article/pharometer-on-tlig
pdxpatzer 4y ago
Pharo can be daunting for a complete novice. Look into Cuis Smalltalk https://cuis.st/ https://cuis.st/ and The Cuis Book https://cuis-smalltalk.github.io/TheCuisBook/ https://cuis-smalltalk.github.io/TheCuisBook/

andrewstuart 4y ago

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!

DeathArrow 4y ago
Doesn't seem dead to me. https://pharo.org/success/ https://pharo.org/success/ 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 http://www.paulgraham.com/avg.html
- deleted 4y ago
  [deleted]
- frou_dh 4y ago
  > 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!
- cfiggers 4y ago
  > 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.

garyclarke27 4y ago

In 2023 No-Code is an Entrepreneurs secret weapon. See my Blog Post - What is No-Code, Why use No-Code? https://www.onedb.online/blog/what_is_no_code_why_use_no_code https://www.onedb.online/blog/what_is_no_code_why_use_no_cod...

bigfishrunning 4y ago
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
- nickd2001 4y ago
  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 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

cies 4y ago

> I can’t think of anything that Smalltalk hasn’t done compared to Python, JavaScript, and Java. Typing? Null-safety? (bolted onto Java, by default in Kotlin)

muyuu 4y ago
Smalltalk is dynamically but strongly typed
- bitwize 4y ago
  Static typing is table stakes for a real-world software engineering language in 2023.
  - muyuu 4y ago
    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 https://news.ycombinator.com/item?id=35165801#35167103

gjvc 4y ago

This author "Richard Kenneth Eng" has done more damage than good to Smalltalk by his fanboy posts for the past few years.

Qem 4y ago
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.
- sebastianconcpt 4y ago
  noob to guru ratio smaller than one That was a heavy one. Good point. Worth writing an essay or blog post elaborating on that.
sebastianconcpt 4y ago
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.

cies 4y ago

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.

lobstrosity420 4y ago
The Rails console is somewhat clunky but manages to deliver most of the value of a Lisp/Smalltalk REPL.
- jtms 4y ago
  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.
  - lobstrosity420 4y ago
    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 Same, what a terrible fate we’ve met.
    - cies 4y ago
      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).
regularfry 4y ago
No image saving though. There have been times I've wondered why, and what the ruby world would look like if it had it. Not as much as I've wondered it about the JVM, though.

readthenotes1 4y ago

Christopher Alexander eventually gave his "quality without a name" that was essential to habitle structures: life. 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.

jerojero 4y ago

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.

DeathArrow 4y ago
>I honestly don't think that it's the tech stack that will make or break most startups in any sector really. Time to market is crucial.
- AnimalMuppet 4y ago
  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.
  - regularfry 4y ago

blitzar 4y ago

Not knowing or giving a shit about the tech stack: A Successful Entrepreneur’s Secret Weapon

wruza 4y ago

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.

DeathArrow 4y ago
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.
lisasays 4y ago
What makes companies fast is, essentially, not hiring the industry people. An interesting, and a fairly broad observation. Can you elaborate?
- 4y ago

tyingq 4y ago

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 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. [1] https://en.wikipedia.org/wiki/Dabble_DB https://en.wikipedia.org/wiki/Dabble_DB

vfclists 4y ago
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.
- macmac 4y ago
  Do you have any evidence for Twitters motivation in this case? I don't see how dabbledb constituted even a theoretical threat to Twitter.
  - vfclists 4y ago
    Large companies may compete with each other but they will always join forces to screw the consumer. https://blog.twitter.com/official/en_us/a/2010/more-than-dabbling.html 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?

m0llusk 4y ago

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.

CraigJPerry 4y ago

>> live coding capability 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.

regularfry 4y ago
What frustrates me with `save-lisp-and-die` is the `-and-die`. It would be so much nicer not to have to stop the world.
bitwize 4y ago
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.
- CraigJPerry 4y ago
  90% seems high. 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.

boffinAudio 4y ago

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.

melvinroest 4y ago

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 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 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.

scotty79 4y ago

true & false not & (nil isNil) :ifFalse [self halt]. when read aloud sounds like a poem. I wonder if that was intentional.

rbanffy 4y ago

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?

sebastianconcpt 4y ago
Only a few can take advantage of multi-core in one image. The rest would be the VM using 1 core (as in NodeJS) with the VM being multithreaded. For example, by using this cleverly you would have something very much like NodeJs https://github.com/pharo-contributions/taskit https://github.com/pharo-contributions/taskit
- rbanffy 4y ago
  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.
  - sebastianconcpt 4y ago
    You sound like talking about https://github.com/smarr/RoarVM https://github.com/smarr/RoarVM 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++.

throwaway1492 4y ago

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.

cutler 4y ago

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.

xkriva11 4y ago
https://github.com/svenvc/P3 https://github.com/svenvc/P3

neilv 4y ago

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/ 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.)

ohduran 4y ago

I feel like this post can nicely be complemented by Yaron Minsky's talk on why they chose OCaml as a programming language at Jane Street: https://www.youtube.com/watch?v=v1CmGbOGb2I https://www.youtube.com/watch?v=v1CmGbOGb2I

firemelt 4y ago

He talk ruby and php is declining meanwhile smalltalk are lesser than both So what?

anta40 4y ago

Mobile app dev here. How am I supposed to use Smalltalk to rewrite my apps? Previously used Java, now Kotlin. Any learning resources?

rsolva 4y ago

I'm LISP-curious and have just started exploring some of the many flavors. I have a few questions: 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?