5 ms·

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 p

by 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?
- jvanderbot 4y ago
  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).
  - cutler 4y ago
    Facebook is the classic example of this. Hackish procedural PHP that REALLY worked.
    - DeathArrow 4y ago
      Also Twitter. They started with Ruby on Rails and rewrote in Java at a later time.
      - lisasays 4y ago
        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.
      - cutler 4y ago
        They went all-in on Scala first after Ruby. I think the Java is more recent.
  - lisasays 4y ago
    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.
IshKebab 4y ago
> you better have chosen python 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.
- mejutoco 4y ago
  > Or "we'll write the bottlenecks in C++"... until you realise that it's all bottleneck. Isn't this exactly how python works with pytorch, polars, and similar very fast libraries?
  - IshKebab 4y ago
    Yes it works for highly numerical code. Most code is not like that.
    - mejutoco 4y ago
      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/ 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.
- cutler 4y ago
  Stripe, Shopify and AirBnB did quite well with Ruby.
blippage 4y ago
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/).
- mmargerum 4y ago
  Have a look at glamorous toolkit and you'll understand why separate documentation is an arcane idea.
  - pdxpatzer 4y ago
    ^^^ this guy gets it
- rlupi 4y ago
  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/ https://mooc.pharo.org/ - http://books.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/ 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.html 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.html https://reference.wolfram.com/language/ref/FindShortestPath.... Basic Examples and run code on that).
AnimalMuppet 4y ago
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.
a_c 4y ago
> 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. 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 https://news.ycombinator.com/item?id=35157049
mmargerum 4y ago
Build Glamorous toolkit in C++ LOL. The language matters.
- carapace 4y ago
  "Liberating the Smalltalk lurking in C and Unix" by Stephen Kell, Strange Loop Conference, https://www.youtube.com/watch?v=LwicN2u6Dro https://www.youtube.com/watch?v=LwicN2u6Dro > 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.
  - Volt 4y ago
    Neat. Now where's the Glamorous toolkit?
    - carapace 4y ago
      Here: https://gtoolkit.com/ https://gtoolkit.com/
sebastianconcpt 4y ago
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.
- justoreply 4y ago
  Which smalltalk implementation are you using?
taylodl 4y ago
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.

by wruza 4y ago

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?

jvanderbot 4y ago
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).
- cutler 4y ago
  Facebook is the classic example of this. Hackish procedural PHP that REALLY worked.
  - DeathArrow 4y ago
    Also Twitter. They started with Ruby on Rails and rewrote in Java at a later time.
    - lisasays 4y ago
      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.
    - cutler 4y ago
      They went all-in on Scala first after Ruby. I think the Java is more recent.
- lisasays 4y ago
  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.

IshKebab 4y ago

> you better have chosen python 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.

mejutoco 4y ago
> Or "we'll write the bottlenecks in C++"... until you realise that it's all bottleneck. Isn't this exactly how python works with pytorch, polars, and similar very fast libraries?
- IshKebab 4y ago
  Yes it works for highly numerical code. Most code is not like that.
  - mejutoco 4y ago
    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/ 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.
cutler 4y ago
Stripe, Shopify and AirBnB did quite well with Ruby.

blippage 4y ago

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

mmargerum 4y ago
Have a look at glamorous toolkit and you'll understand why separate documentation is an arcane idea.
- pdxpatzer 4y ago
  ^^^ this guy gets it
rlupi 4y ago
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/ https://mooc.pharo.org/ - http://books.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/ 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.html 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.html https://reference.wolfram.com/language/ref/FindShortestPath.... Basic Examples and run code on that).

AnimalMuppet 4y ago

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.

a_c 4y ago

> 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. 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 https://news.ycombinator.com/item?id=35157049

mmargerum 4y ago

Build Glamorous toolkit in C++ LOL. The language matters.

carapace 4y ago
"Liberating the Smalltalk lurking in C and Unix" by Stephen Kell, Strange Loop Conference, https://www.youtube.com/watch?v=LwicN2u6Dro https://www.youtube.com/watch?v=LwicN2u6Dro > 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.
- Volt 4y ago
  Neat. Now where's the Glamorous toolkit?
  - carapace 4y ago
    Here: https://gtoolkit.com/ https://gtoolkit.com/

sebastianconcpt 4y ago

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.

justoreply 4y ago
Which smalltalk implementation are you using?

taylodl 4y ago

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.