Hacker News Reader

Comment by hazelnut-tree | Hacker News Reader

There is something very appealing about learning a small(ish) language. However, a small language does not always mean simple. And it means code can be difficult to unravel.

Niklaus Wirth, the creator of Pascal, Modula-2 and Oberon, believe strongly that teaching programming is most effective when students can grasp the entirety of a small language.

From a 2018 interview with Wirth on the topic:

> "In order to do a good experience, you have to have a clean language with a good structure concentrating on the essential concepts and not being snowed in."

> "That is my primary objection to the commercial languages – they’re simply too huge, and they’re so huge that nobody can understand them in their entirety. And it’s not necessary that they’re so huge."

View on HN

An interesting example of this I came across recently is Pico:

> Pico is a tiny but expressive programming language that was especially designed to teach advance computer science concepts to students in other sciences than computer science … Currently Pico is no longer used as a tutoring language for its target group, but this is more a consequence of politics than of the astounding results we got with teaching Pico. Today, Pico is used as a means to teach principles of language design, interpreters and virtual machines in a sophomore course for computer scientists and in an adjacent course in a masters program in applied computer science.

http://pico.vub.ac.be/

That's exactly why I appreciate Go as far as I'm concerned. =) And now with AI code completion, it's even better.

I am new to go, but to me, the language looks bigger than it needs to be. Why do slices and maps need to be part of the language and not just part of a standard library? I suppose the reason is special syntax, but having to learn that special syntax makes the language feel bigger.

They are part of the language, because they require generics to be implemented if you want to implement them in the standard library. Go didn’t use to have generics, so those constructs were hacked into the core language.

I see. That makes sense. So maybe it is generics that are so fundamental that they need to be part of any language. Seems that Java, C#, and Go have all learned this lesson.

We, as a field, should be very careful about forgiving our tools of the sin of complex and tedious design because those flaws can possibly be remediate with LLMs.

The complexity of boilerplate does not only exist for the author but every future author.

It is not my experience that LLMs and other complex automations are nearly as good as refactoring and changes as they are at generating boilerplate in the first place. In the end this code lives on as a human concern despite the automation.

I agree. I also don't think there is a single perfect programming language yet.

I do think however that programming languages and libraries are the assembly language for AIs to interface with legacy systems targeting human usage.

So it's important for these to be easily understandable.

Go fills that sweetspot better imo. Until something else appears perhaps.

But you're absolutely right that we should make sure to still improve these languages and it is right to worry that LLM don't incentivize new languages (smaller code corpus, less data?). As for Go, it is improving steadily so I'm still confident in that regard.

Reply on news.ycombinator.com