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

71–80 of 379 posts

Re: In defense of complicated programming languages

#71

Post by skinkestek »

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!…

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 always win in the end even if it means picking apart files, debugging huge stacks and a whole lot of reading docs and searching for docs, but why oh why can't even amazingly well funded projects make good documentation..?)

Re: In defense of complicated programming languages

#72

Post by usrbinbash »

>Encapsulation, modularization, abstraction - let's not pick nits about the precise meaning of these terms, they are all about the same thing, really: Managing complexity of your own code.

The thing is, code complexity can be managed superbly without the concept of a class.

Golang doesn't have classes. C doesn't have classes. But both have structs and they have functions taking a pointer to, or a struct of type T. (what OO calls a "method" for some reason). So we can have "objects" as in, custom datatypes, and we can have functions to act on them.

And on top of that, we have modularization in libs and packages.

So, why do we need more complicated languages? "Show a locked door before you show a key" indeed.

Re: In defense of complicated programming languages

#73

Post by tluyben2 »

teataster wrote: post #51
WalterBright wrote: post #40

One difficult thing to accept in programming language design is that what mathematically is simple, consistent, and straightforward is not simple, consistent, or straightforward to people. For example, a simple, consistent, and straightforward expression syntax would be RPN (Reverse Polish Notation). But humans dislike, and much prefer infix with its complicated operator precedences. The real trick to programming lan…

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 think this is the takeaway as well; I prefer RPN (and I can read and I like k which is considered 'unreadable/readonly' and Lisp which is also apparently 'hard to read') because I am used to writing a lot of forth(likes); I like discovery while programming and it is quite trivial to stuff in a forth into anything, even when no-one did it before. For instance, 10 years ago, to speed up Xamarin (which was compile/run and quite slow at that), I sped up development by adding a Forth into C# so I could rapidly discover and prototype on my device without having to compile. And I have done that for the past 30 years, starting on my 80s homecomputer to avoid having to type hex codes and risk more crashing during discovering what I wanted to make.

Re: In defense of complicated programming languages

#74

Post by IshKebab »

cttet wrote: post #56

The definition of "simple" and "complex" is very vague here. If we use Clojure's philosophy of simple, Python is by no means a simple language, even without classes. There are a lot of special syntax like `with` `as` `elif` `for .. else` and concepts such as `nonlocal`, not even mention generators, decorators and lots of fancy stuffs, although it is easy to learn... I don't agree with the author that static type make…

Static types are definitely make the language more complicated. It will have a bigger specification and more complicated implementation.

You could even argue it makes writing programs more complicated. But they definitely also make writing programs much much easier.

Kind of like how algebra is more complicated than basic arithmetic, but good luck proving Pythagoras's theorem without algebra.

Re: In defense of complicated programming languages

#75

Post by IshKebab »

teataster wrote: post #51
WalterBright wrote: post #40

One difficult thing to accept in programming language design is that what mathematically is simple, consistent, and straightforward is not simple, consistent, or straightforward to people. For example, a simple, consistent, and straightforward expression syntax would be RPN (Reverse Polish Notation). But humans dislike, and much prefer infix with its complicated operator precedences. The real trick to programming lan…

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.

Re: In defense of complicated programming languages

#77

Post by eitland »

usrbinbash wrote: post #72

>Encapsulation, modularization, abstraction - let's not pick nits about the precise meaning of these terms, they are all about the same thing, really: Managing complexity of your own code. The thing is, code complexity can be managed superbly without the concept of a class. Golang doesn't have classes. C doesn't have classes. But both have structs and they have functions taking a pointer to, or a struct of type T. (w…

> What more do we need?

Good languages with good IDE support?

I'm old enough that at some point assembly and C were my favourite languages and PHP was what I was most productive in and Python was also something I enjoy.

These days no way I go back for new projects.

After Java "clicked" for me and the introduction of Java generics shortly afterwards it became my favourite language and later TypeScript and C# had been added to that list.

I'm not to dumb, but I prefer using my smarts to develop programs, to work together or even pair program with the language to mold something, not to babysit languages that cannot even help me with trivial mistakes.

Re: In defense of complicated programming languages

#78

Post by oaiey »

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.

I think Excel shows us that you can do a lot with a beginner friendly toolbox.

Re: In defense of complicated programming languages

#79

Post by dmurray »

usrbinbash wrote: post #72

>Encapsulation, modularization, abstraction - let's not pick nits about the precise meaning of these terms, they are all about the same thing, really: Managing complexity of your own code. The thing is, code complexity can be managed superbly without the concept of a class. Golang doesn't have classes. C doesn't have classes. But both have structs and they have functions taking a pointer to, or a struct of type T. (w…

Yes, I would agree that structs are the solution to the complexity the author describes. But Python doesn't have structs: if you don't learn about classes you will probably eventually organize some data using dictionaries or heterogeneous tuples.

In another language you might introduce structs first (C and Go only have structs, C++ has both classes and structs but they are the same thing) but in Python you don't have that option - you can use data classes or named tuples but those already need most of the ceremony you introduce for dealing with classes.

Re: In defense of complicated programming languages

#80

Post by Zababa »

cttet wrote: post #56

The definition of "simple" and "complex" is very vague here. If we use Clojure's philosophy of simple, Python is by no means a simple language, even without classes. There are a lot of special syntax like `with` `as` `elif` `for .. else` and concepts such as `nonlocal`, not even mention generators, decorators and lots of fancy stuffs, although it is easy to learn... I don't agree with the author that static type make…

> If we use Clojure's philosophy of simple, Python is by no means a simple language, even without classes. There are a lot of special syntax like `with` `as` `elif` `for .. else` and concepts such as `nonlocal`, not even mention generators, decorators and lots of fancy stuffs, although it is easy to learn...

Beware of the Turing tarpit where everything is simple but nothing is easy! Python is by no means perfect, but using different syntax when doing different things can make a lot of sense. "Everything is a X" can be a nice mental model, but on the other hand, as we've seen with classes, mixing data structures, structs and namespaces all in one concept is not always the best solution.

Post reply on HN