Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of complicated programming languages

viralinstruction.com

Post reply on HN
Print view View original

221–230 of 379 posts

Re: In defense of complicated programming languages

#221

Post by naasking »

WalterBright wrote: post #37

I remember first encountering classes. I simply could not understand what they were from reading the documentation. Later, I picked op Bjarne's C++ book, read it, and could not figure out what classes were, either. Finally, I obtained a copy of cfront, which translated C++ to C. I typed in some class code, compiled it, and looked at the emitted C code. There was the extra double-secret hidden 'this' parameter. Ding!…

Sounds like you have a certain mental model of computation, and you can't understand other types of semantics. I suggest playing with a term rewriting language. If you can grok that without mapping it to your existing mental model, then other languages can be viewed through that lens much more easily.

Re: In defense of complicated programming languages

#222

Post by nmilo »

One thing that isn't often mentioned is that complicated programming languages nearly always come with complicated tooling. C++ has cmake, which is self-explanatory, and even cargo is pretty complicated. I'm still not sure what is a crate vs. a package, and the amount of times I've had to look up the bindgen tutorial, and the amount of steps involved, is too much. This isn't even to mention compile times, debug-mode executable speed, etc. This isn't the complexity moving from the source code to the tooling, this is complexity created in the tooling itself required to manage the complexity created by the language.

Re: In defense of complicated programming languages

#223

Post by teataster »

dwohnitmok wrote: post #83
teataster wrote: post #51

Earlier quoted context omitted.

Some humans dislike RPN. I am yet to find whether they really dislike or just find it unfamiliar. I am convinced that unfamiliar gets conflated with unintuitive and hard all the time.

> unfamiliar gets conflated with unintuitive and hard all the time In a deep sense unfamiliar and unintuitive/hard can be viewed as the same thing (see e.g. the invariance theorem for Kolgomorov Complexity). Hence striving to be "familiar" is still a virtue that it makes sense for a programming language to aspire to (balanced of course against other concerns).

Familiarity is a characteristic of the agent.

Intuitiveness/duficult is of the object.

Re: In defense of complicated programming languages

#224

Post by travv0 »

adwn wrote: post #135
novok wrote: post #66

Earlier quoted context omitted.

One trend with complicated languages is poor scalability although. They don’t compile fast , tend to have slow iteration speeds and don’t scale with large teams or codebases well. You see this with c++ , rust, haskell, scala and swift.

I'm curious to hear where you've seen Rust not scaling to large teams or codebases?

I'd also be interested in a Haskell example.

Re: In defense of complicated programming languages

#225

Post by cogman10 »

WalterBright wrote: post #95
LEDThereBeLight wrote: post #90

Earlier quoted context omitted.

I understand this thought process, but in my opinion it's the wrong way to think about software concepts. Understanding what a bridge is doesn't mean knowing how to build one, and in fact tying your understanding to a certain implementation of a bridge just limits your ideas about what is, in fact, an abstract concept. We understood functions as "mappings" between objects for hundreds of years, and when programming c…

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…

Is it possible to really learn how programming concepts work, though? Modern optimizing compiler are pretty amazing and just seeing the assembly output may make a concept harder to grasp.

To your bridge analogy. At this point what we are saying is "give me a method to traverse this river" and compilers are either building bridges, shooting out maps to fallen trees, or draining the river all together. If you looked at that output you might consider "traversing rivers" to only be walking over natural bridges.

This gets even more sticky when talking about types. Computers don't care about types, they are strictly a concept to help developers.

Or to your class point, would you know better what a class does if you pulled up godbolt and found that the this pointer is completely removed? You might come to the mistaken conclusion that classes are simply a name-spacing technique.

Re: In defense of complicated programming languages

#226

Post by teataster »

funcDropShadow wrote: post #208
teataster wrote: post #51

Earlier quoted context omitted.

Some humans dislike RPN. I am yet to find whether they really dislike or just find it unfamiliar. I am convinced that unfamiliar gets conflated with unintuitive and hard all the time.

'unfamiliar' is 'unintuitive'. You only have an intuition for things that are similar to things you have encountered. Some unfamiliar or unintuitive things might be simpler than familiar things. But, at first, it is often easier to use familiar things, even if they are less simple. Regarding RPN, I am not convinced that they are actually simpler to a human. In order to understand an RPN expression I try to keep the s…

I never said PRN is simpler. It is just as hard as infix.

I do not like PNR any better or worse. It takes me about 5 minutes to switch from lisps to others and back. I just put the parens in the wrong place a couple of times and I am done.

Paredit + PNR makes editing slightly more comfy, but that's it. They are the same thing.

Re: In defense of complicated programming languages

#227

Post by [deleted] »

WalterBright wrote: post #37

I remember first encountering classes. I simply could not understand what they were from reading the documentation. Later, I picked op Bjarne's C++ book, read it, and could not figure out what classes were, either. Finally, I obtained a copy of cfront, which translated C++ to C. I typed in some class code, compiled it, and looked at the emitted C code. There was the extra double-secret hidden 'this' parameter. Ding!…

[deleted]

Re: In defense of complicated programming languages

#228

Post by teataster »

IshKebab wrote: post #75
teataster wrote: post #51

Earlier quoted context omitted.

Some humans dislike RPN. I am yet to find whether they really dislike or just find it unfamiliar. I am convinced that unfamiliar gets conflated with unintuitive and hard all the time.

I agree with your general principle but I do think infix notation is still better because so many equations are a tree of binary operators. Look at how binary trees are drawn - the nodes are in the middle of their children. It just makes sense for binary operators to have their operands on either side. Otherwise you end up having to maintain some kind of mental stack which is just a bit mentally taxing.

There is something I am missing here.

How does your mental model change that much from where the operator goes?

Can't you put node to right of a column of children? Like you would do on a piecewise function.

I am dislexic, maybe that's why I do not see your point.

Re: In defense of complicated programming languages

#229

Post by naasking »

> Over and over, every piece of documentation for the Go language markets it as "simple". This is a lie. Or rather, it's a half-truth that conveniently covers up the fact that, when you make something simple, you move complexity elsewhere.

I'm not sure this is strictly true. This is true of essential complexity, but not true of accidental complexity. Some programming language abstractions introduce a lot of boilerplate and accidental complexity, so "simplifying" could just mean bringing the language more in line with a natural expression of a program.

Re: In defense of complicated programming languages

#230

Post by garethrowlands »

robalni wrote: post #177

> The complexity of Rust's ownership model is not added to an otherwise simple program, it is merely the compiler being extremely pedantic about your code obeying rules it had to obey anyway. Not exactly. I remember when I learned Rust a few years ago (so maybe things are different today), sometimes the compiler didn't let me do things that should have been perfectly fine things to do. This forced me to write the cod…

Fun computer science fact: any type system will disallow some otherwise valid programs and also allow some invalid programs. The trick for type system designers is to find a sweet spot.
Post reply on HN