Live data from Hacker News

In defense of complicated programming languages

viralinstruction.com

351–360 of 379 posts

Re: In defense of complicated programming languages

#351

Earlier quoted context omitted.

Just a quick word about polish notation: The only reason why humans seem to prefer infix notation, is because it is what's being taught in school. The first mathematical expressions most people get to see is 1 + 1 There is no reason why someone who was introduced to + 1 1 at an early age would find it less "natural" than infix. I think the only reason why infix is the dominant notation is historical: Prefix notation…

White space is bad for readability anyways. I don't think that would be doable.

> White space is bad for readability anyways.

Question{Which|of|these|sentences|is|easier|to|read;This|one?}

Or this one in the next line?

Re: In defense of complicated programming languages

#352

Earlier quoted context omitted.

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.

same, i'd like to see such an approach

Re: In defense of complicated programming languages

#353
post #341

Earlier quoted context omitted.

It's when it's part of the core language, as any Turing complete language can implement any feature of any other Turing complete language. It's not a useful statement to say all languages support all features.

So I guess Common Lisp, Raket, Scheme, C++, C#, F#,... just lost a couple of features.

If those features are supplied by libraries outside the core language, I don't think I'd count them.

I use Clojure a fair bit, and that has a miniKanren implementation in the form of core.logic. Would I say that makes Clojure a relational programming language? No, I don't think so, because it's not part of the core language.

Similarly, there exists an optional static typing library for Clojure called core.typed - does that make Clojure a statically typed language? Again, I don't believe so.

You can build a library to implement any feature, particularly in Lisps or other languages with support for AST transformations. Those features may even be counter to the core design of the language - you could write a library in Haskell to support dynamically typed, imperative programming, for example.

Re: In defense of complicated programming languages

#354
post #342
post #336

Earlier quoted context omitted.

The natural language is evolved by people saying what they what and the majority became the language. Not defined by some elites or some authority. Classes binds data and functions together, and object systems supports inheritance. These are some of the things that some people don't really like, but you may not care. People sometimes care about syntax as well, writing "Class" is also part of the experience of using t…

Modules also bind data and functions together. Not all object systems use inheritance, and even those that do, we can speak about delegation, interface/trait/protocols/type classes inheritance, regular classes inheritance, or some weird stuff like object patterns from BETA. That is why we have CS literature, to put the right words in place.

| Modules also bind data and functions together. Yep, but a module is still not a Class. My example was referring to you mixing concepts of Classes and Polymorphism and dynamic dispatch in your original reply.

As you said, there are a lot of object systems that are different, and the difference matters. Having inheritance or not matters. I was just making examples to show that things are different.

We all know that C++ concepts != go/typescript interfaces != Java/c# interfaces != Haskell type classes (c# concepts) != rust/scala traits.

Try to explain that using "CS literature", maybe a lot of language designs don't have a word yet made for that. Yep there are Subtyping, Bounded quantification, Ad hoc polymorphism, Row polymorphism, but still not enough to tell all of them from each other.

But to anyone in the community, people all know that they are all not Classes and what make them special is important. It is quite clear, but why don't you get that?

The concepts CS literature are quite trivial and people can spend a few weekends to learn, or maybe another few for type rule syntax or a few others for basic category theory to understand them in a more intuitive way. But the real problem of making a good language for some applications is still there and much more complex and difficult. And maybe current literature are not enough for that.

The elites will never dictate the words, the people will pick up whatever they want to express their knowledge anyway, as we know of what happened in history.

Re: In defense of complicated programming languages

#355

Earlier quoted context omitted.

It's when it's part of the core language, as any Turing complete language can implement any feature of any other Turing complete language. It's not a useful statement to say all languages support all features.

Rather, any Universal Turing Machine can be programmed to calculate whatever any other Universal Turing Machine can be programmed to calculate. It's not necessarily done with the same features, or use of resources. In some cases, the only way the features of some UTM A's architecture will be obtained through UTM B, is if UTM B is used to create a simulation of UTM A, and so then that provides a way to execute the UTM…

There are two problems with making that distinction. First, by that definition, few languages have regular expressions as a feature. Second, in languages with support for syntax rewriting, that would mean the internal implementation, not the user-facing syntax, is what decides what counts as a "real" feature.

Re: In defense of complicated programming languages

#356
post #86
post #34

def bark(dog_dict): print("WOOF!" if dog_dict["weight_kg"] > 25 else "Woof") rex = {"name": "Rex", "weight_kg": 35} This code is actually better, but it would even be better with structs and traits https://gist.github.com/rust-play/ceb5a292a22e55e27d56a83253... We separate the concept of a Dog, the concept of something that barks, and the actual implementation in this case We also don't immediately print it, but just…

> It's a bit longer than the class example, but conceptually cleaner because multiple structs can implement the trait, some of them without a weight Sounds like premature abstraction. Instead of declaring a class, you have declared an interface.

There are no classes in Rust, and it's better for it. That's my point, some abstractions like classes are NOT necessary.

There were arguments before Rust 1.0 that people will simply try to emulate classes. But nobody actually bothered, because traits provide enough functionality that you don't actually need to have classes to actually write maintainable and understandable programs.

I'm attacking the exact point of the article that you need X. Maybe you actually don't need X, and your programs will be better for it.

Re: In defense of complicated programming languages

#357
post #17

> In video game design there is a saying: Show locked doors before you show a key This is something I've tried putting into words many times. I'll try to solve a problem and get to know its challenges deeply. Then a tool is introduced that brings it all together. In these cases, I seem to quickly get a full grasp of the operation and essence of the tool. I wish education was based around this principle. A bit like wh…

hei, just read this. That's a really cool piece of writing.

It kinda put me in a mood of going over the basic principles of mathematics again, but in this new light.

Any recommendation of content that follows the advice given in the article?

Thanks!

Re: In defense of complicated programming languages

#358

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…

I am not a child psychologist, so take all of this with a grain of salt. I believe children first learn concepts by looking at and playing with concrete things first. "Oh look at this fun thing... Oh whoops I moved it, it looks slightly different, but if I rotate it, it looks like it used to... It doesn't really taste like anything, but it feels hard... Whoa, what's this new thing over here? Oh wait, this is the same size and shape as the thing I played with previously... In fact it behaves just like the first thing did. Oh cool, there's a whole stack of them over here, I bet they work just like the first things did!" This is how one might interpret a baby's first interactions with blocks. Later in life, they might find out about dice and understand some similarities. Later, still in school, the kid learns about cubes in geometry class, and can think back to all the concrete hands on experience he had and see how the various principles of cubes apply in real life.

So, people learn by experiencing concrete things first, and then grouping all those experiences into abstract concepts. Sometimes (ok, often) they'll group them incorrectly: Kid: "This thing doesn't have fur and moves without appendages. It's a snake. Whoa, look at this thing in the water, it moves without appendages either! It must also be a type of snake." Teacher: "That's an eel, not a snake." Kid: "oh. I guess snakes are for land and eels are for water" Teacher: "Water Moccasin is a type of snake that is quite adept in the water." Kid: "oh. They look kinda the same, what's the difference?" Teacher: [performs instruction]

This form of learning by compiling all sorts of concrete things down into a few abstract concepts is so powerful and automatic that we do it ALL THE TIME. It can even work against us, "overtraining" to use an ML term, like with our various biases, stereotypes, typecasting of actors ("this guy can only ever do comedies"). Sometimes folks need a little help in defining/refining abstract concepts, and that's the point that teachers will be most helpful.

So, for me anyway, and I suspect many others, the best way to learn a concept is to get many (as different as possible) concrete examples, maybe a few concrete "looks like the same thing but isn't", and THEN explain the abstract concept and its principles.

Or, to explain the process without words, look at Picasso's first drawing of a dog, and the progressively shinier simpler drawings until he gets to a dog drawn with a single curvy line.

Re: In defense of complicated programming languages

#359
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…

Funny to see this

> As someone who strongly dislikes complicated languages

while

> Working on OpenJDK at Oracle

as if Java was uncomplicated…

Re: In defense of complicated programming languages

#360
post #356
post #86

Earlier quoted context omitted.

> It's a bit longer than the class example, but conceptually cleaner because multiple structs can implement the trait, some of them without a weight Sounds like premature abstraction. Instead of declaring a class, you have declared an interface.

There are no classes in Rust, and it's better for it. That's my point, some abstractions like classes are NOT necessary. There were arguments before Rust 1.0 that people will simply try to emulate classes. But nobody actually bothered, because traits provide enough functionality that you don't actually need to have classes to actually write maintainable and understandable programs. I'm attacking the exact point of th…

> There were arguments before Rust 1.0 that people will simply try to emulate classes. But nobody actually bothered, because traits provide enough functionality that you don't actually need to have classes to actually write maintainable and understandable programs.

It's not only traits. Traits (well, traits objects) are used for dynamic dispatch, traits themselves are used as composable interfaces, and structs + impl blocs are used for basic classes.

My point was that your example, implementing a trait that may or may not use a weight for barking, is not making the program better. It's making it more complex for no good reason. Here's what your program could be: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Adding traits doesn't make the code better. There's only dogs that are barking. You don't even need to have bark() be a method, a plain function will do.

Post reply on HN