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

101–110 of 379 posts

Re: In defense of complicated programming languages

#101

Post by fendy3002 »

raverbashing wrote: post #26
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…

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…

> Java where you need a 'static void main' method inside a class just to begin

C# too, but they remove the necessities to use static main for entrypoint, starting from C#9

Re: In defense of complicated programming languages

#102

Post by wruza »

WalterBright wrote: post #89
skinkestek wrote: post #71

Earlier quoted context omitted.

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…

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 really work.

Re: In defense of complicated programming languages

#103

Post by kreutzwj »

kg wrote: post #57

Modern C# is way too complicated, and I really dislike that. On the other hand, as I've tested out the new features, I have to admit that most of them are good. Part of what makes this work is that wherever possible, they made the features compiler-only, which means I can use them without having to update my application to use a newer runtime or newer libraries. This means I don't have to worry that updating my code…

> they made it possible to provide your own implementation of all the query operators so it was possible for me to define my own methods and make my linq queries not allocate at runtime. really nice (though it comes with its own tradeoffs).

I would like to know more about this, would be really useful. So you have any recommended docs to read?

Re: In defense of complicated programming languages

#104

Post by jakobnissen »

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…

Author here. Indeed, when I tested off my idea on a friend, his first response what "But what is complexity? Is J a complex language? What about assembly?". It can get tricky once you get into the weeds. But from the comments here, it looks like most people got what I was trying to express.

W.r.t whether types makes Python more complex - my point was that a type system makes the _language_ more complex, but it makes the _code_ using it easier to reason about. That's my main view of the blog post: Be careful trying to simplify a programming language if it leads to the code itself being more complex.

And sure, I have no particular attachment to OOP "classes" as such, and I don't think they are necessary. In fact I much prefer Julia's approach. What I meant with classes being inevitable is that 1) structs, or something like structs, are inevitable, and 2) methods, in the sense of functions that are semantically tried to particular structs, are inevitable. In Python, these two things are provided by classes, so in Python, there really is no escaping classes.

Re: In defense of complicated programming languages

#105

Post by hayley-patton »

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…

> But humans dislike, and much prefer infix with its complicated operator precedences

Depends on what you're writing; Gerald Jay Sussman claims that edge cases in mathematical notation (and corner-cutting of sorts in what is written) makes physics quite hard to grasp in "The role of programming" [1]; hence the Structure and Interpretation of Classical Mechanics book, which includes many Scheme programs which explicate everything.

[1] https://www.youtube.com/watch?v=arMH5GjBwUQ

Re: In defense of complicated programming languages

#106

Post by tomxor »

I had a similar experience.

As I grew more experienced I also found it peculiar how sometimes classes worked really well, and other times they were a terrible fit. Eventually I realised, as an abstraction they are far closer to high level patterns than rudimentary functions - but the fact that they are a very common pattern built into so many languages obscures that attribute from most people.

> Classes would still exist, but as implicit patterns.

Once you realise this, you also start to notice how often overused and misused classes are, because they seem to be the first thing many people reach for. Classes are not an inherently bad pattern, but that doesn't mean they work well for everything either.

I think teaching them from the perspective of a "need" as the author suggests, would not only make their purpose clearer for beginners, but also prevent them being so misused.

Re: In defense of complicated programming languages

#107

Post by zelphirkalt »

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

I do not think JSON schema and XML schema are such nightmares though. They are not that difficult to write most of the time and are quite useful. Maybe they simply are not the best examples for what you want to express.

Re: In defense of complicated programming languages

#108

Post by KptMarchewa »

skinkestek wrote: post #71
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…

Groovy? Gradle is a build tool for JVM.

Re: In defense of complicated programming languages

#109

Post by CogitoCogito »

LEDThereBeLight wrote: post #90
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!…

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…

> if you need to see an implementation then you're not really understanding the idea for what it is.

I 100% disagree. At the very least, I think you're wrong if your assumption is that such a statement applies in general. That statement certainly doesn't fit me as well as many people I've taught in the past. I got my PhD in (pure) mathematics and I could only understand high level abstractions _after_ I worked through many concrete examples. I know the same applies for many successful mathematical researchers because we discussed the subject at length. Now such a statement certainly does apply for _some_ people (I've taught them as well), but certainly not all.

If you're someone that likes this sort of abstract thinking, that's great. If you're someone that needs concrete examples to understand, that's great too. The real lesson is that everyone learns differently.

Re: In defense of complicated programming languages

#110

Post by pjmlp »

GrumpySloth wrote: post #82
pjmlp wrote: post #23

Earlier quoted context omitted.

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?

Type classes are a way to do polymorphism, but... dynamic dispatch? I don't think so; which function is called, is determined statically. As for ML functors: they're neither polymorphism, nor dynamic dispatch. First: functions for different types can't share names (unless we're talking about shadowing of names with lexical scope), the names are either qualified with the name of the struct they come from or they're no…

There are many ways to skin a cat how those declarations are written.

If I have time later I might post an example, apparently we are only right with code.

Post reply on HN