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

61–70 of 379 posts

Re: In defense of complicated programming languages

#61

Post by 4ec0755f5522 »

cttet wrote: post #59
Animats wrote: post #41

Earlier quoted context omitted.

That's because the use case for classes appears when the information needed to understand the program exceeds the programmer's working memory. At some point, you need some way to make something into a black box whose innards you do not need to understand when not working inside the black box. Languages which do this badly do not scale well. This is a hard problem. We have, at least, structs, classes, objects, traits,…

For the Python typing system. If you mostly code alone, you have the options to force yourself to enforce it, which would benefit the future you.

A modern IDE (I use PyCharm) also makes use of it for both warnings and autocompletion.

Re: In defense of complicated programming languages

#62

Post by cttet »

ncmncm wrote: post #36
iopq wrote: 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…

Missing the point. If you read just a little farther, you get that extra apparatus has a purpose that is opaque to beginners, that just adds confusion.

I disagree. It is maybe better for the author or you as a beginner, but not everyone. One needs data to support claims like that.

Re: In defense of complicated programming languages

#63

Post by novok »

WalterBright wrote: post #55
sanxiyn wrote: post #46

Earlier quoted context omitted.

You've never seen tutorials written that way because roughly nobody but you learns programming languages from the bottom up. There is just no demand. By the way, where can I read a D tutorial from the bottom up?

> 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

#64

Post by cttet »

pjmlp wrote: post #23
weavejester wrote: post #16

"Classes would still exist, but as implicit patterns." Classes are not a design inevitability, but just one way of managing state. Languages that mostly avoid mutable state don't tend to have object systems, for instance.

Type classes and ML functors are also a way to do polymorphism and dynamic dispatch on data structures. So which languages are left without object systems?

To be more concise classes != object systems != polymorphism and dynamic dispatch on data structures

The difference between them are important to some people. And that's why they will argue for that.

Re: In defense of complicated programming languages

#65

Post by schlupa »

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

Yeah, I also always have the necessity to look what the compiler does with the code you through at it.

Re: In defense of complicated programming languages

#66

Post by novok »

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.

One trend with complicated languages is poor scalability although. They don’t compile fast , tend to have slow iteration speeds and don’t scale with large teams or codebases well. You see this with c++ , rust, haskell, scala and swift.

Re: In defense of complicated programming languages

#67

Post by continuational »

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.

The toolbox analogy breaks down when you realize that every language feature interacts with every other language feature. So it's more like a toolbelt that you have to wear. Hopefully, the tools aren't so plentyful and heavy that you spend all your energy dragging it along!

Re: In defense of complicated programming languages

#68

Post by roomey »

I still don't get classes in python.

For now I wrap my data objects as a json and use rabbitMQ to message the json to all the other running .py's

I heard about async and want nothing to do with it thank you.

I do understand the need to maintain a mental model of the code so I gave based everything on Sherlock Holmes novels.

Re: In defense of complicated programming languages

#69

Post by drewm1980 »

Animats wrote: post #41
quirino wrote: 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…

That's because the use case for classes appears when the information needed to understand the program exceeds the programmer's working memory. At some point, you need some way to make something into a black box whose innards you do not need to understand when not working inside the black box. Languages which do this badly do not scale well. This is a hard problem. We have, at least, structs, classes, objects, traits,…

Python's static type system was kept out of the runtime object values to keep a slow language from getting slower.

Mypy is also not 1.0 yet.

You can still find bugs in advanced use cases i.e. when you are mixing inheritance, generics, data classes...

The new type system is both flawed and also a godsend for python developers.

Re: In defense of complicated programming languages

#70

Post by cttet »

quirino wrote: 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…

But I think that's the exact reason we need to learn simple languages here. So that we know the closed doors first (the abstraction problem), then we will create a key or find a key elsewhere. Otherwise if "Class" is made the part of the language, like Java, you will not appreciate the importance of it to any extent and have a overall bad experience....
Post reply on HN