It's just that trying to do that at their current workplace will result in a backlash.
I don't overengineer the code I write at home in weekends.
An interesting, and a fairly broad observation. Can you elaborate?
And at an early startup, making the damn thing work is all that really matters. (I'm at a laterish startup and we do attempt to follow some process and patterns where it would structure things enough to enable cleaner onboarding as we grow).
No viable position for most companies (or even most startups) to take.
Not if it comes at the cost of making your co-workers hate you for the messes you continually leave behind. And to lose faith in upper management for holding you up to be a "rockstar" for doing so. And for them to start looking for new jobs, as a result.
The optimal level for basic hygiene and defense programming in a startup is -- perhaps a notch or two lower than in a staid, manager-driven post-startup company. But certainly not zero.
"The nose knows", as they say.
I love dumb, straightforward code BTW. It's my guiding aesthetic much of the time in fact. But that wasn't what I was referring to, here.
Rather the "too smart for its own good... and utterly brain-fucked" end product which is the calling card of your average rockstar / ninja developer.
JS maybe (well TS, not JS; you'd be a fool to use actually JS) but I've seen more than a few projects strangled by their choice of Python and the terrible performance it comes with.
People always say "it doesn't need to be fast"... until it does and it's too late. Or "we'll write the bottlenecks in C++"... until you realise that it's all bottleneck.
Mercurial and Scons are obvious public examples.
Language does make a difference, despite everyone being polite and saying it doesn't. Of course that doesn't mean it is the only or even biggest factor.
Isn't this exactly how python works with pytorch, polars, and similar very fast libraries?
I would describe polars a library to work with data (https://www.pola.rs/). So we have a high-performance library in Python to work with generic data.
I think that covers a lot of cases, since you can transform arbitrary parts of a program into data. Ask any lisp fan.
Typescript is great, and the approach of having native high-performance modules works great for Python. You can offload, if you want to, a big part of your program to high-performance libraries. Maybe it is not the most elegant, but it works.
Python is not cpp, but if it fits your use-case, it can be quite performant.
https://stripe.com/blog/sorbet-stripes-type-checker-for-ruby
> Unfortunately we were starting to see Ruby come apart at the seams: new engineers found it hard to learn the codebase, and existing engineers were scared to make sweeping changes. Everyone faced a constant tradeoff: run the fast, local tests which might not catch many breakages, or run all the tests, even the slow ones. Ruby was becoming a source of friction more than a source of productivity.
I'm not saying you can't make good products with inferior languages.
I also think Racket suffers from the same problem. The libraries are documented, but how do I use them to do something?
The advantages of mainstream languages is that they have a plethora of documentation.
I'd say that if you want your language to succeed, adopt a cookbook approach. Nobody wants to figure out how all the pieces of the jigsaw should be put together.
For all that, I don't think anyone has really come up with anything better than C++, Python, or similar (Rust, if you /must/).
The paradigm is different, so if you expect file-based interactions(*), you are approaching it wrong.
I just downloaded Pharo, run the current stable image 10.0, and the first thing that pops out is a "Welcome" window with links to - https://mooc.pharo.org/
- A "Learn Pharo" section tells me to click on a link "ProfStef go." to learn the basics.
- Another one tells me to run "HelpBrowser open." to see the in-image documentation.
- In the help browser itself, I can find more tutorials and even a tutorial on how to make them.
- If I open any System Browser and filter the packages for "Examples" or "Tutorial", I get more stuff too. If I search for "Tests", I can read a lot more. Naturally, everything is hyperlinked and navigable like you'd get in a IDE for another language.
- If I open a System Browser, I can click on any package and get a UML class diagram for the package. Classes have comments, like python doc strings.
How do I open a file? I haven't touched Smallktalk in 20 years. I just opened a System Browser, searched packages for "File". Look there is a Files package with a File class. What does the comment say (the 2nd comment tab, which is formatted)? Examples of usage, how to open and write, encoding, buffering, etc. I can click on any method and then on "Senders"to see how it is used.
Then I remembered from 20 years ago, there should be a faster way to get there, so I just opened a transcript window and typed "File", selected it and Cmd-B (browse) to get to the class
---
I don't advocate Pharo or any Smalltalk environment but the reasons are not related the quality of its environment, just that developers are very hard to find and most support is moving on.
---
What has much better documentation?
I'd say Wolfram Mathematica.
The documentation is very extensive and consistent, you can see it online at https://reference.wolfram.com/language/
But if you open it from within Mathematica, it is also editable: you can change the code and execute it at any step.
e.g. you can open the documentation for https://reference.wolfram.com/language/ref/FindTextualAnswer...
and instead of doing:
question = "Who was the architect of the Sagrada Familia?"; articles = WikipediaData /@ WikipediaSearch["Content" -> question]; FindTextualAnswer[articles, question, 5, {"Probability", "HighlightedSentence"}]
You want to ask "Who was the architect of Florence cathedral?"
You can change that and see what happens.
And since Mathematica is a symbolic language that is not limited by text input, you can copy any data structure or graphic (e.g. the graphs on https://reference.wolfram.com/language/ref/FindShortestPath.... Basic Examples and run code on that).
Choosing a language for the ecosystem: You should choose languages for their all-things-considered fit for what you're trying to do. Ecosystem is part of it. The programmers you can get (or do you have to train?) are part of it. Another part is, what things make it difficult to write the program that you're trying to write? Memory management? Multithreading? Networking? Certain languages may do certain parts of that for you, and that part of the difficulty just... goes away. Pick the language that, all things considered, makes it easiest to write the program that you need to write.
This.
In another post[1] I made similar comment
> Your code is useless if no one is using it.
> This talk introduces liballocs, an infrastructure which exposes the dynamism hiding in the arcane linking and debugging infrastructure of a Unix process, along with a small extension to C toolchains that enables fast dynamic access to data created by statically compiled code. Together they can be said to unleash a "hidden Smalltalk" inside the C and Unix model of programs and processes. Come prepared for a journey that takes your perceptions of the boundaries between dynamic and static languages and turns them on its head.
I'm using Smalltalk in both the startup and corporate world and it's a good fit for both. Main current challenges are not in the language or tech stack if you architect the right thing for each case. The main challenges are in finding what's your path to walk a profitable road that makes you incrementally grow without too much drama.
Do you think we care about refactoring, DRY, patterns and all that software engineering stuff? Hell no! Ain't got time for that nonsense!
As an "archiveloper" (architect who also rolls up their sleeves and develops) I advise my developers to adhere to the KISS methodology - Keep It Stupid-Simple. We take a super pragmatic approach, not worrying about what's "cool." We use Python in AWS. Why? Are solutions are all "server-less" and it became clear that Python is AWS' preferred language for server-less development, though they never explicitly say that anywhere.
KISS allows you to quickly get today's work done without creating problems you have to contend with tomorrow. Our whole goal is to get more done while creating fewer problems.
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.