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

241–250 of 379 posts

Re: In defense of complicated programming languages

#241

Post by maxwell86 »

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…

Have you taken Rust appart yet?

Re: In defense of complicated programming languages

#242

Post by dasil003 »

LEDThereBeLight wrote: post #90
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!…

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…

The issue with viewing programming concepts as purely abstract is that the abstractions have varying degree of leakiness. Even with the most mathematically pure languages like Haskell you run into implementation details space leaks which you have to understand to build reliable systems.

There’s certainly something to be said for abstract understanding, but one thing I’ve learned in software and in business is that details matter, often in surprising ways.

Re: In defense of complicated programming languages

#243

Post by convolvatron »

maxwell86 wrote: post #241
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…

Have you taken Rust appart yet?

it would have helped me a lot.from the outside it looks very complicated and capricious. I really do get the sense that the little axiomatic ur-language inside is a lot more tractable - would love to have learned that first.

Re: In defense of complicated programming languages

#244

Post by kstenerud »

kaba0 wrote: post #219
kstenerud wrote: post #215

Earlier quoted context omitted.

Generics were a necessary thing, but the type erasure is a huge problem, and unfortunately one that can't be fixed without a completely new bytecode format. Also, annotations, while a necessary thing to bring it up to speed with modern practices (such as nullability contracts), add to the bureaucracy of Java and make it more painful to work in. Don't get me wrong; I do like Java, and have written hundreds of thousand…

Why do you think type erasure is problematic? Haskell and basically every language absolutely gets away with type erasure so it really shouldn’t pose a serious problem, other than for reflection usages which are rare.

It was too long ago so I can't remember why it was problematic, only that it was, and required a bunch of workarounds in some cases to get what you take for granted in other languages.

Re: In defense of complicated programming languages

#245

Post by jksmith »

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…

>>"But the notions of sending a "message" to a "method" just was way way too handwavy for me."

This. I've felt like I haven't been able to keep up with commodity programming because I can't stand the way today's drivers (MSFT) control mindshare by emphasizing frameworks over mechanics. I feel like it's a people aggregation move instead of facilitating more creative solutions. The most enjoyable classes I had in uni were 370 assembler and all the Wirth language classes taught by the guy who ran the uni patent office.

Re: In defense of complicated programming languages

#247

Post by blub »

nmilo wrote: post #222

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…

And they attract programmers which love complicated code. Of course they don’t actually call it complicated and in fact they see it as elegant and state of the art.

People have figured this out about C++, but they’re still in denial about Rust. Notice how in the article the borrow checker is the best kind of feature which emerged to handle an existing problem.

In reality the borrow checker is a hammer which forces all code to look like something the borrow checker can nail down. Rust is similar to C++ and it looks like it will be used outside low-level programming or systems programming and in those cases one can gladly give up e.g. manual memory management, obsessively avoiding copying, having to specify how wide an integer is and so on at least in parts of the code.

Re: In defense of complicated programming languages

#248

Post by preseinger »

erik_seaberg wrote: post #3

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.

Most software is written and maintained by non-experts. Consequently you should optimize for time-to-onboard. Good tools are intuitive and easy to master; a hammer is basically better than a scanning electron microscope.

Re: In defense of complicated programming languages

#249

Post by KptMarchewa »

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…

To be honest, I don't care about classes itself. What I do like are the interfaces - which are usually expressed as collection of methods. Classes provide easy grouping of those methods, so you can not only type-safe implement particular methods, but make sure that whole group of methods implement particular contract.

To be honest, this does not require classes per se - Golang manages to have interfaces without classes, Rust has traits.

Re: In defense of complicated programming languages

#250

Post by pron »

kaba0 wrote: post #183
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 o…

> how would the ideal low and high level language look like in your opinion?

I really don't know. I didn't know about the utility of affine types for memory safety in a low-level language before Rust, and I didn't know how much could be done with just comptime before Zig, so I certainly can't say what would be ideal for me. In terms of values, I would like a very simple language that helps write correct code and has fast compilation. None of the low-level languages I know about fully meet those goals, but so far Zig comes closest. Then again, it's easy to look good before you're actually out there, so we'll see.

> Regarding the high level languages, do you find java’s Valhalla plans good?

TBH, I haven't been following Valhalla closely, but knowing the people involved, I have the utmost confidence in what they'll do.

Post reply on HN