In defense of complicated programming languages • Hacker News Board

Re: In defense of complicated programming languages

#181

Post by CogitoCogito » Tue, Jan 25, 2022, 1:18 PM UTC

Koshkin wrote: post #173

CogitoCogito wrote: post #109

Earlier quoted context omitted.

> if you need to see an implementation then you're not really understanding the idea for what it is. I 100% disagree. At the very least, I think you're wrong if your assumption is that such a statement applies in general. That statement certainly doesn't fit me as well as many people I've taught in the past. I got my PhD in (pure) mathematics and I could only understand high level abstractions _after_ I worked throug…

But there's a difference between trying to understand, say, a theorem by applying it in concrete situations and by studying its proof.

> But there's a difference between trying to understand, say, a theorem by applying it in concrete situations and by studying its proof.

There may be a difference or there may not. You could study a proof within the context of a specific example. That is how I usually would do it. But yes of course it's possible not to do like that (many people don't study proofs that way). In any case, I don't really understand your point.

Re: In defense of complicated programming languages

#182

Post by tialaramex » Tue, Jan 25, 2022, 1:21 PM UTC

Asooka wrote: post #158

Asooka wrote: post #42

Given their example about classes and "don't show the key before showing the lock", it's ironic the writer pans languages aiming to be "simpler" without understanding the kind of complexity they're actually avoiding. Zig, Go, (and Java and C# and other not as sexy and modern examples) are avoiding C++'s complexity - features with complicated interactions between each other that can sink your program without you being…

And now I see that HackerNews ate my multiplication symbols. What I meant to type is that unsigned short a = 0xFFFF; unsigned short b = a; unsigned short c = a * b; Is currently undefined behaviour on platforms where int has more bits than short (like x64 and arm) due to the interaction between the integer promotion rules and undefined integer overflow.

Rust here says OK, we'll define Mul (the * operator) for the same type (and for references to that type) so

  let a: u16 = 0xFFFF;

  let b: u16 = a;

  let c: u16 = a * b;

... is going to overflow, Rust would actually detect that because 0xFFFF is a constant, so, this says "Silently do overflowing arithmetic" and er, no, it doesn't compile. However if you achieved the same thing via a blackbox or I/O Rust doesn't know at compile time this will overflow, in a Debug build it'll panic, in a Release build it does the same thing as:

  let c: u16 = a.wrapping_mul(b);

Because the latter is not an overflow (it's defined to do this), you can write that even in the constant case, it's just 1, the multiplication evaporates and c = 1.

In C++ if you can insist on the evaluation at compile time there is no UB, so you get an compiler error like Rust.

Re: In defense of complicated programming languages

#183

Post by kaba0 » Tue, Jan 25, 2022, 1:28 PM UTC

pron wrote: post #121

As someone who strongly dislikes complicated languages, it's obvious to me that it's a matter of personal preference; personal aesthetics, if you like. If the choice is between complexity in the language and elsewhere, often I'd rather it be elsewhere. But while that preference is entirely subjective, what isn't subjective is the distribution of that preference among programmers. I think that we can say with as much…

I’ve seen many of your comments (sorry, I’m not stalking you, just find both your work on Loom and your fresh take on some CS problems really interesting) regarding languages and would like to know how would your ideal language look like? I know that you are quite fond of Zig’s simplicity, especially the way they replaced many complex features of c++, rust by a simple constexpr feature. I would wager you also think of Java as a simple language, and I remember seeing Clojure as a positive example somewhere as well.

You also seem to suggest that a “high level low level” language is not really possible (the trap c++ and rust falls into) due to low level details always seeping through, making refactors much slower. So my question is: how would the ideal low and high level language look like in your opinion? Regarding the high level languages, do you find java’s Valhalla plans good? I personally really like the semantic-only distinction of basically loss-of-identity, and loss-of-tearing, giving ample grounds for optimizations behind the scenes, and over time (in part thanks to some of your comments), I grown to really like the simplicity a language with simple classes and methods can bring.

Re: In defense of complicated programming languages

#184

Post by sirwhinesalot » Tue, Jan 25, 2022, 1:29 PM UTC

tsimionescu wrote: post #43

Supermancho wrote: post #25

Earlier quoted context omitted.

> Classes are not a design inevitability, but just one way of managing state What "Classes" are is a tragedy of things. Classes are closures, with a syntactic form that allows for nested composition. This is a particularly brittle form and these qualities are found in all languages with Classes. Language maintainers, as they currently exist, have failed to concede that this is a bad idea, because "it works good enoug…

Classes are closures just as much as closures are classes (as Java showed). What classes are at their most core is bundles of behavior, possibly with encapsulated state, and usually some way to decide at runtime which of a family of classes' behavior to use. Closures are naturally tied to 1 single behavior (though of course you can invent ad-hoc methods of extending that, such as a "methodName" parameter, but no one…

Closures are the superior mechanism though, you can implement classes plus all the crazy decorators / metaclasses / mixins / etc. The reverse is true of course but in the dumbest way possible.

A closure-based implementation of a class is just a function that returns a structure full of closures (an interface if you will) all with the same shared state.

But now because a class is just a function, you can do all kinds of crazy things with it, the "constructor" can even pick and choose which functions to use to implement the interface at runtime, while retaining full typesafety.

Classes are not just unnecessary, they're a bad abstraction.

Re: In defense of complicated programming languages

#185

Post by qayxc » Tue, Jan 25, 2022, 1:29 PM UTC

dTal wrote: post #174

ozim wrote: post #166

Earlier quoted context omitted.

Example from the article is a nice one. Now you want to make 100s of different dogs in your program and you want make them to bark at each other. You want to loop over all the dogs and feed them. You can make infinite loop that will check all the dogs and if one is hungry call Feed and if one is not then not. Learn what is the difference between Object and Class. You can create objects and let them live in your progr…

That's not very convincing. Why can't a "dog" be a perfectly ordinary data structure that you manipulate the usual way? while True: for dog in dogs: if dog["hungry"] == True: dog["lastfed"] = time() dog["hungry"] = False Okay, I hear you say, but the fact that a dog is an associative array is an implementation detail. Supposing I want to abstract that - don't I need objects then? No! Just define some functions: while…

> Is there any advantage to "gluing" the functions to the data?

Depends on the capabilities of the language. If the language supports function overloading and type-checking, then no.

Otherwise the "fun" begins if you add different variations of the same basic data that require subtle changes for working with them.

In the case of Python you'd end up with a manual type-checking pattern and nested if-else statements within the functions. In the OO case you can leverage protocols, composition and (to a lesser extent) inheritance.

Re: In defense of complicated programming languages

#186

Post by Mikeb85 » Tue, Jan 25, 2022, 1:30 PM UTC

account-5 wrote: post #124

As a non-professional and in essence beginner programmer who likes to learn about programming and writes simple to moderately complicated scripts I have to say I am currently in the mindset of not needing classes. In fact the first part of the article I was like: yeah no need for classes there, a function is way simpler. Now like I say I write fairly simple scripts, I mostly automate manual processes, but even after…

Classes are about encapsulation. They contain state and have funtions (methods) to change said state. It's nice to have things encapsulated when programs get very big. For one off scripts though, not really needed.

Re: In defense of complicated programming languages

#187

Post by foxfluff » Tue, Jan 25, 2022, 1:30 PM UTC

lerno wrote: post #153

yxhuvud wrote: post #145

Earlier quoted context omitted.

> Ruby is fairly easy to learn No, its not. Ruby as a language is about as complex as they come. It is easy to get to a productive state though, but that is not the same thing as having learned the language. Length of learning curve and accessibility are vastly different things.

Getting productive easily is the pretty much the definition of not having a steep learning curve. So I have difficulties making sense of your argument.

yxhuvud referred to length of the learning curve, not slope of the learning curve.

Even if getting started is easy (no steep slope), mastery can take long.

Re: In defense of complicated programming languages

#188

Post by LEDThereBeLight » Tue, Jan 25, 2022, 1:32 PM UTC

yxhuvud wrote: post #134

WalterBright wrote: post #95

Earlier quoted context omitted.

I didn't understand how engines worked until I took them apart, either. I was taking things apart to understand them long before computers :-) But the notions of sending a "message" to a "method" just was way way too handwavy for me. I like examining the theory after I learn the nuts and bolts. > Understanding what a bridge is doesn't mean knowing how to build one If you don't know how to build one, you don't underst…

On the other hand, you can walk over a bridge any amount of times without understanding the nuts and bolts of it. There are plenty of ways to build a bridge, there are static concrete bridges, there are bridges that can open, there are hanging bridges and a lot more variants. But for the people making use of them, the implementation matter a lot less than the purpose - connecting two places. But yes, you are of cours…

Thank you, what you wrote is exactly what I meant.

Re: In defense of complicated programming languages

#189

Post by nrabulinski » Tue, Jan 25, 2022, 1:32 PM UTC

hnlmorg wrote: post #151

sanxiyn wrote: post #46

Earlier quoted context omitted.

You've never seen tutorials written that way because roughly nobody but you learns programming languages from the bottom up. There is just no demand. By the way, where can I read a D tutorial from the bottom up?

Is there really no demand? Or do those of us who like to learn that way just get used to researching these things ourselves so quietly get on with it. Many of the existing tutorials are at least a good starting point to teach engineers what topics they need to examine in more detail. Anecdotally, when I've mentored juniors engineers I've had no shortage of people ask me "why" when I've explain concepts at a high leve…

There’s a difference between understanding something and learning how and why it works the way it does. You can understand how a compilation pipeline works never working with any low-level code and never writing a compiler yourself. You can walk across a bridge and understand it connects point A with point B and don’t understand how a specific bridge has to be constructed. A concrete implementation is just an implementation detail and if you focus too much on it you’ll get tunnel-visioned instead of understanding the concept behind it

EDIT: And I say that as someone who likes both learning and teaching from the ground-up. But there’s no demand for it because that’s not how you efficiently learn the concepts and understand the basics so you can take a deeper dive yourself

Re: In defense of complicated programming languages

#190

Post by Mawr » Tue, Jan 25, 2022, 1:33 PM UTC

jchw wrote: post #48

I agree with almost everything about this article. I am also a known Go zealot. What gives? Well, I think the author underestimates just how much needs differ across different programs. Go excels with services because they are often written with a shared-nothing mindset for horizontal scalability. If you’re using S3, Redis, PostgreSQL and RabbitMQ for all of your persistence and coordination, it leaves only small bit…

> There is something in video games called minmaxing, which is where you maximize one attribute at the expense of all of the others. For me C++, and now Rust, feel like they are guilty of this with their weight on zero-cost abstractions.

> I think it was literally just meant to be the bare minimum to try to solve the most important parts of the problem, and at that it succeeds.

In other words, it's the cost effectiveness of a language feature. You want features to provide as much value for as little cost as possible. This is what Go's going for; to paraphrase Russ Cox - "If a feature is not clearly above the bar, it's below it." [1].

> Just as reducing programming language complexity doesn’t remove it, but only moves it around, removing runtime cost doesn’t remove it either. And the problem here isn’t that compile time isn’t a better time than runtime; it’s the hidden costs that suck. Sure, maybe the compile times in Rust will improve, and maybe it’s not even that big of a deal. But every little feature the language has puts some additional stress on the ecosystem. The language server has to bear this load, for example.

The worst hidden cost that's often missed is the impact on the programmer.

Take Python's controversial walrus operator [2]. If you look at the reasoning and the examples, the change seems reasonable. But consider that once the feature gets implemented, every single Python programmer will have to learn what it does in order to be able to read others' code. Does this feature provide enough to justify this weight? Undoubtedly not. Of course, it got implemented anyway, because the impact of making the code slightly more readable in some cases is clearly visible, but the cost incurred on every single programmer's mind is not.

This is how languages reach untenable levels of complexity. By the time you realize your language is getting complex, you're 20 features in and it's too late to turn back. "A frog dropped in a pot of boiling water will jump out of the pot to save his own life. If the frog is put into cool water and slowly brought to a boil, he will remain there until he is cooked through."

[1]: https://github.com/golang/go/discussions/47203#discussioncom...

[2]: https://www.python.org/dev/peps/pep-0572/#abstract