Hacker News Reader

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

Have a look at glamorous toolkit and you'll understand why separate documentation is an arcane idea.

^^^ this guy gets it

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/

- http://books.pharo.org/

- A "Learn Pharo" section tells me to click on a link "ProfStef go." to learn the basics.

- Another one tells me to run "HelpBrowser open." to see the in-image documentation.

- In the help browser itself, I can find more tutorials and even a tutorial on how to make them.

- If I open any System Browser and filter the packages for "Examples" or "Tutorial", I get more stuff too. If I search for "Tests", I can read a lot more. Naturally, everything is hyperlinked and navigable like you'd get in a IDE for another language.

- If I open a System Browser, I can click on any package and get a UML class diagram for the package. Classes have comments, like python doc strings.

How do I open a file? I haven't touched Smallktalk in 20 years. I just opened a System Browser, searched packages for "File". Look there is a Files package with a File class. What does the comment say (the 2nd comment tab, which is formatted)? Examples of usage, how to open and write, encoding, buffering, etc. I can click on any method and then on "Senders"to see how it is used.

Then I remembered from 20 years ago, there should be a faster way to get there, so I just opened a transcript window and typed "File", selected it and Cmd-B (browse) to get to the class

---

I don't advocate Pharo or any Smalltalk environment but the reasons are not related the quality of its environment, just that developers are very hard to find and most support is moving on.

---

What has much better documentation?

I'd say Wolfram Mathematica.

The documentation is very extensive and consistent, you can see it online at https://reference.wolfram.com/language/

But if you open it from within Mathematica, it is also editable: you can change the code and execute it at any step.

e.g. you can open the documentation for https://reference.wolfram.com/language/ref/FindTextualAnswer...

and instead of doing:

question = "Who was the architect of the Sagrada Familia?"; articles = WikipediaData /@ WikipediaSearch["Content" -> question]; FindTextualAnswer[articles, question, 5, {"Probability", "HighlightedSentence"}]

You want to ask "Who was the architect of Florence cathedral?"

You can change that and see what happens.

And since Mathematica is a symbolic language that is not limited by text input, you can copy any data structure or graphic (e.g. the graphs on https://reference.wolfram.com/language/ref/FindShortestPath.... Basic Examples and run code on that).

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.

Which smalltalk implementation are you using?

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.

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.

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.

> 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

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

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

Yes it works for highly numerical code. Most code is not like that.

If we are pedantic all code running in a computer is numeric, but I get your point for gpu calculations for pytorch or numba, so I won't make that point :)

I would describe polars a library to work with data (https://www.pola.rs/). So we have a high-performance library in Python to work with generic data.

I think that covers a lot of cases, since you can transform arbitrary parts of a program into data. Ask any lisp fan.

Typescript is great, and the approach of having native high-performance modules works great for Python. You can offload, if you want to, a big part of your program to high-performance libraries. Maybe it is not the most elegant, but it works.

Python is not cpp, but if it fits your use-case, it can be quite performant.

Stripe, Shopify and AirBnB did quite well with Ruby.

Ruby was such a poor choice for Stripe they ended up writing their own static type checker for it...

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.

That's after they had already made billions with Ruby and, BTW, Patrick Collison is still passionate about Ruby and has no plans to drop it even at Stripe's scale. No-one says Ruby will cater for all scaling scenarios but it can take you a long way with the advantage of moving quickly and developer happiness. Twitter started with Ruby and nothing stopped them form switching to Scala when the time was right. What is more common than ditching Ruby is splitting-off services to be written in a faster language. Best of both worlds. Your designation of Ruby as an inferior language begs the question inferior to what and inferior by what metric?

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

"Liberating the Smalltalk lurking in C and Unix" by Stephen Kell, Strange Loop Conference, 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.

Neat. Now where's the Glamorous toolkit?

Here: https://gtoolkit.com/

What makes companies fast is, essentially, not hiring the industry people.

An interesting, and a fairly broad observation. Can you elaborate?

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

Facebook is the classic example of this. Hackish procedural PHP that REALLY worked.

Also Twitter. They started with Ruby on Rails and rewrote in Java at a later time.

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.

They went all-in on Scala first after Ruby. I think the Java is more recent.

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.

How would you define “a mess”, and also why “dumb straightforward code” is a mess, if you think so?

How would you define “a mess”,

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