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.
In defense of complicated programming languages
121–130 of 379 posts
Re: In defense of complicated programming languages
#122> 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…
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
#123Earlier 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.
Re: In defense of complicated programming languages
#124In 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…
Re: In defense of complicated programming languages
#126Earlier 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…
Re: In defense of complicated programming languages
#127As 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…
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
#128Earlier 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.
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
#129This is a great pedagogical insight, expressed in a very nice way. Thank you for this goldnugget :)
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.
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.