Live data from Hacker News

In defense of complicated programming languages

viralinstruction.com

121–130 of 379 posts

Re: In defense of complicated programming languages

#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 certainty as we can about these things that the answer is clear: the vast majority of programmers prefer simpler languages. So much so that while language simplicity is by no means a sufficient condition for high popularity, it seems that it's a necessary one.

But I'll go further. My gut feeling, which is by no means even remotely scientific, is that those who prefer simpler languages outnumber those who prefer complicated ones 9:1. Moreover, my feeling is that the ratio is higher at the low end of programmer capability than at the higher end — and it makes sense, as more capable programmers can handle more complexity, so some — still a minority, but a larger one —prefer moving more of it to the language.

Re: In defense of complicated programming languages

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

Yes, this is one of my pet peeves as well. And what I think it's also important: don't ask for the key if the door doesn't need to be opened. The examples on the text about Python and OOO are on point. Yes, people would reinvent classes if they needed, but the great thing about classes (and type annotations) are that they're optional Compare with Java where you need a 'static void main' method inside a class just to…

The sheer irony is that "lite" object systems like python and ruby are actually purer and more faithful to the ideals of OOP (as envisioned by Alan Kay and those with him and before him) than Java can ever be, with its ugly and unnecessary seperation between classes and primitives, a completely irrelevant distraction that is primarily a VM optimization detail which only compilers and other bytecode producers or consumers should have known or cared about.

In python, nearly everything is a PyObject, data, code, source code files (which are just modules, which are just objects). It's highly misleading to name the things you get by calling a class objects, it implies this is somehow special, as if dicts and lists and ints, and classes themselves for crying out loud, aren't objects as well.

This is why I cringe so much when people associate OOP with Java bloat, the language is just unimaginably badly designed, this has nothing to do with OOP. You don't even have to be dynamic like Python and Ruby to be a good OOP system either, although that is a particularly low-friction path pioneered by smalltalk and lisp, but languages like Scala and Kotlin prove you can be highly static, highly OOP, and beautiful to read and write without the sheer amount of paperwork Java heaps on you.

Re: In defense of complicated programming languages

#123
post #63

Earlier quoted context omitted.

> You've never seen tutorials written that way because roughly nobody but you learns programming languages from the bottom up. I am indeed a unique snowflake.

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.

Re: In defense of complicated programming languages

#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 reading the article I'm still not sold on classes. I have to admit using dictionaries/associative arrays as the author showed and have often wondered over the difference between classes and objects. But I still don't see the problem.

I known my lack of knowledge and understanding is showing here; I'm no expert and have never written any massive software.

Can someone point me to an example where a class is more suitable than a function working on an object like an associative array? Genuine question from the ingnorant.

Re: In defense of complicated programming languages

#125

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

OO implies far far more than simply grouping data in a struct and passing it by reference.

Re: In defense of complicated programming languages

#126
post #102

Earlier quoted context omitted.

Just try, my pretties, just try to understand how exception handling actually works without staring at a lot of assembly.

Ah, doesn’t it just fly over to the nearest “catch”? Btw, the worst misunderstandings I’ve seen were not lacking knowledge, they actively believed in some magic that isn’t there if you dig deeper. That’s why I still think that teaching at least basic assembler is necessary for professional programming. It can’t make you a low-level bare metal genius, but it clears many implicit misconceptions about how computers real…

I recently picked up C after years of python, devops and javascript. I realized it's simply impossilbe for me to understand the tradeoffs made when other languages are designed or just understand my Unix-like operating system and other parts of it without knowing enough C. My next target is of course assembly and the compiler. And if anything I know, I want to stay away from any kind of sugar-syntax and unnecessary abstractions on top of basic computer and programming concepts.

Re: In defense of complicated programming languages

#127

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…

It's mostly a matter of scale. In some sense, classes are just "functions working on an object like an associative array", x.y(z) is a fancy way of writing y(x, z) and python even makes that explicit. The point is they're designed to keep those functions in the same place and not leaking all over the code, keep similar utility and data in the same place.

If you are writing small scripts, it really doesn't matter. If have a million lines of code and thousands upon thousands of source files, any structure you can impose on it makes a big difference.

That said, OOP is just one paradigm of imposing structure.

Re: In defense of complicated programming languages

#128
post #52

Earlier quoted context omitted.

That's how I learnt C too. Couldn't grok how pointers worked. Took a few months to work with assembly. Returned. Didn't have to read any C tutorial. Everything came naturally

Fortunately, I picked up the K+R book after I was an experienced PDP-11 assembler programmer. I had never heard of C before, and basically just flipped through the pages and instantly got it. I quit all the other languages then, too, and switched to C.

To be fair though that's just an extremely well put together book. It's exceptional.

I happen to have the Second Editions of both Kernighan & Ritchie and of Stroustrup's much more long-winded book about his language sitting near this PC.

Even without looking at the actual material the indices give the game away. If I am wondering about a concept in K&R and can't instantly find it from memory, the index will take me straight there. Contrast Stroustrup where the index may lack an entry for an important topic (presumably it was in great part or entirely machine generated and the machine has no idea what a "topic" is, it's just matching words) or there may be a reference but it's for the wrong page (the perils of not-so-bright automatic index generation) and so the reader must laboriously do the index's job for it.

Now, today that's not such a big deal, I have electronic copies of reference works and so I have search but these aren't books from 2022, Stroustrup wrote his book in 1991 and the 2nd edition of K&R is a little older. This mattered when they were written, and when I first owned them. K&R is a much better book than almost any other on the topic.

The book, I would argue, actually holds up much better in 2022 than the language.

Re: In defense of complicated programming languages

#130

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

OO implies far far more than simply grouping data in a struct and passing it by reference.

Such as?

The only other things that come to mind when I think about "OOP" are:

* inheritance, which at this point even lots of proponents of OOP have stopped defending

* encapsulation, which usually gets thrown out the window at some point anyway in sizeable codebases

* design patterns, which usually lead to loads of boilerplate code, and often hide implementation behind abstractions that serve little purpose other than to satisfy a design pattern...the best examples are the countless instances of "Dependency Injection" in situations where there is no choice of types to depend on.

Post reply on HN