A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
In defense of complicated programming languages
141–150 of 379 posts
Re: In defense of complicated programming languages
#142Earlier quoted context omitted.
I also have a hard time with learning concepts too if there are handwavey parts of it. I remember by recreating the higher level concepts from lower level ones at times.
To me, the abstraction is an oversimplification of actual, physical, systemic processes. Show me the processes, and it's obvious what problem the abstraction solves. Show me only the abstraction, and you might as well have taught me a secret language you yourself invented to talk to an imaginary friend.
I think it’s an oversimplification of what abstraction is.
Re: In defense of complicated programming languages
#143- 1. Generators that can allocate prevent comptime-overapproximation of potential stack usage (https://github.com/ziglang/zig/issues/157#issuecomment-76395...) or make analysis inside the compiler significant harder.
- 2. There is no reason why static analysis must be part of the compiler, though its still an open research problem how to present lifetimes properly to the user (https://github.com/ziglang/zig/issues/782#issuecomment-10149...)
- 3. Requiring static analysis to be inside the compiler pushes back on external static analysis. While this may be overall good to force upstreaming work and prevents monetarian incentive of introducing bugs as optimizations detectable by tool xyz, it reduces modularization incentive and extensibility for experimentation.
- 4. Trying to encompass everything in static analysis has the same problem as the all-encompassing logic: Soundness can not be proven and the proof for soundness becomes more and more problematic the more rules one adds (slow and hard to reason which rule has been applied). And this does not even account human errors or the fact that a PL does not accurately implement the logic.
- 5. The biggest problem of complicated languages is that they have no process to define what underlying logic (see point 4) the compiler should follow and "what is too complex". Somehow folks also forget about Gödels incompleteness theorem (you cant reason on everything in the compiler).
Re: In defense of complicated programming languages
#144Earlier quoted context omitted.
FWIW, thanks a whole lot! As an engineer in the forties it is somewhat encouraging to read that you felt the same way even if it was about different topics. For me, these days it is about frontend generally, Gradle on backend and devops. So much to learn, so little documentation that makes sense for me. (I'm considered unusually useful in all projects I touch it seems but for me it is an uphill struggle each week.) I…
Just try, my pretties, just try to understand how exception handling actually works without staring at a lot of assembly.
Re: In defense of complicated programming languages
#145A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
How does a short learning curve necessarily correlate to a "nearly empty" toolbox? That seems like a fallacy to me. Ruby is fairly easy to learn. Does that mean it has a nearly empty toolbox? No it doesn't. A language with a GC is easier to learn than one without a GC. Does the one with a GC have less in the toolbox? What if it also allows opting out of GC? ObjC is considered a hard language to learn, esp for people…
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.
Re: In defense of complicated programming languages
#146I 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!…
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…
You cannot really tell someone that the way their brain learns is the "wrong way". Different people's brains are wired differently and thus need to learn in different ways.
> 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.
Software development is about more than just understanding what something is. It's about understanding how to use it appropriately. For some people, simply being told "you use it this way" is enough. Other people like to understand the mechanics of the concept and can then deduce for themselves the correct way to use it.
I also fall into that category. While I'm not comparing my capabilities to Bright's I do very much need to understand how something is built to have confidence I understand how to use it correctly.
Neither approach is right nor wrong though, it's just differences in the way our brains are wired.
> There's a reason why computer science professors explain concepts at a high or abstract level and don't jump into implementation to help students understand them.
Professors need to appeal to the lowest common denominator so their approach naturally wouldn't be ideally suited for every student. It would be impossible to tailor classes to suit everyone's need perfectly without having highly individualised lessons and our current educational system is designed to function in that way.
> If an idea stays abstract in your mind, it gives you more flexibility with how you apply it and more ways to find use out of it. But it does take a mindset shift, and is an actual learned skill, to be able to see something as purely abstract and accept that how it's made doesn't matter.
The problem here is that abstract concepts might behave subtly differently in different implementations. So you still need to learn platform specifics when writing code on specific platforms, even if everyone took the high level abstract approach. Thus you're not actually gaining any more flexibility using either approach.
Also worth noting that your comment suggests that those of us who like to understand the construction cannot then derive an abstract afterwards. Clearly that's not going to be true. The only difference between your approach and Bright's is the journey you take to understand that abstract.
Re: In defense of complicated programming languages
#147As 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 don’t know. It seems to me the progression is “I like simple languages.” To “I like how expressive I can be. Look at this elegant one line program I wrote.” To “I like simple languages.” Anecdotally, as I’ve gained experience, I and most people I know have only grown in valuing simplicity. It’s one reason the the average Clojure developer is older.
Re: In defense of complicated programming languages
#148A language with a short learning curve is like a toolbox that’s nearly empty. You quickly run out of ways it could help you. We should optimize for experts, because that’s where each of us is going to spend most of his career.
Is it possible to optimize too much for experts, and sacrifice learning curve too much?
Re: In defense of complicated programming languages
#149Given 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…
Further more, its more consistent if signed and unsigned behaving identical than having to look for the type with integer promotion rules of the number.
If you prefer the current C/C++ way of less performance and inconsistency that is fine.
Re: In defense of complicated programming languages
#150I 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!…
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…
Programming is often approached from a purely abstract point of view, almost a branch of theoretical mathematics, but imho in 99% of cases it's better understood as the concrete task of programming a CPU to manipulate memory and hardware. That framing forces you to consider tradeoffs more carefully in terms of things like time and performance.
You shouldn't be able to hand translate every line of code you write into assembly, but in my experience you write much better code if you at least have an intuition about how something would compile.