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

261–270 of 379 posts

Re: In defense of complicated programming languages

#261

Post by duped »

robalni wrote: post #177

> The complexity of Rust's ownership model is not added to an otherwise simple program, it is merely the compiler being extremely pedantic about your code obeying rules it had to obey anyway. Not exactly. I remember when I learned Rust a few years ago (so maybe things are different today), sometimes the compiler didn't let me do things that should have been perfectly fine things to do. This forced me to write the cod…

> The solution was that I had to write a macro that extracted Y from S and call that macro every time I wanted to pass Y to a function.

Why does that require a macro?

``` struct S { x:X, y:Y }

fn do_with_y (y:&mut Y) {} fn do_with_s (y:&mut S) {}

fn main_program (mut s: S) { do_with_s(&mut s); do_with_y(&s.y); /* ... */ } ```

I prefer seeing code like this rather than wrapping it in abstractions and macros/helpers because it's not particularly verbose and very clear where the borrowing happens ; you'd see the same in C++ or C, to be honest.

Re: In defense of complicated programming languages

#262

Post by robmccoll »

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

A thousand times this! At the very least, I always want to have good mental model of how something probably works or mostly works even if I couldn't reproduce the implementation line-for-line. To me, it can almost be dangerous to have the power to use something without any idea of what's under the hood. You don't know the cost of using it, you don't have a good basis for knowing what the tradeoffs and reasons are for using it over something else, and the concept isn't portable if you need to work in a language or environment that doesn't have it.

If I come across a feature I like in a programming language, I usually find myself trying to figure out how to implement or emulate it in a language I already know (ideally one that won't hide too much from me). Implementing coroutines in C using switch statements, macros, and a little bit of state for example.

Re: In defense of complicated programming languages

#263

Post by cowl »

usrbinbash wrote: post #136
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…

Just a quick word about polish notation: The only reason why humans seem to prefer infix notation, is because it is what's being taught in school. The first mathematical expressions most people get to see is 1 + 1 There is no reason why someone who was introduced to + 1 1 at an early age would find it less "natural" than infix. I think the only reason why infix is the dominant notation is historical: Prefix notation…

That is not necessarily true. the first tells me we are starting with 1 apple and adding another one. the second tells me that we are starting with Adding? Adding what? We never start with an action without having a object/subject in mind.

Re: In defense of complicated programming languages

#264

Post by wraptile »

usrbinbash wrote: post #136
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…

Just a quick word about polish notation: The only reason why humans seem to prefer infix notation, is because it is what's being taught in school. The first mathematical expressions most people get to see is 1 + 1 There is no reason why someone who was introduced to + 1 1 at an early age would find it less "natural" than infix. I think the only reason why infix is the dominant notation is historical: Prefix notation…

White space is bad for readability anyways. I don't think that would be doable.

Re: In defense of complicated programming languages

#265

Post by travv0 »

JoelMcCracken wrote: post #257
travv0 wrote: post #224

Earlier quoted context omitted.

I'd also be interested in a Haskell example.

Generally this problem is because someone went crazy with template haskell or generics

What problem? I'm looking for an example of where poor scalability has been a problem in a Haskell codebase.

Re: In defense of complicated programming languages

#266

Post by [deleted] »

IshKebab wrote: post #154
nbabitskiy wrote: post #118

Earlier quoted context omitted.

The proof is on the left, and doesn't require algebra. You can use another picture for the right part, like this https://microexcel.ru/wp-content/uploads/2020/05/kvadrat-sum... (it also uses algebraic notation which can be ignored)

Pythagorus's theorem is literally written using algebra. You can't even write it down without algebra.

[deleted]

Re: In defense of complicated programming languages

#267

Post by account-5 »

account-5 wrote: post #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…

I can't reply to everyone so thanks to you for your replies.

My take is that for simple stuff I don't need classes. An example is I'm writing a simple GUI calculator for my brother who's a stone mason. It's a stone calculator that accepts quality, height, width, length measurements in mm and output a tables with volume costs in either metres or feet cubed.

I could model it as a job classes that accepts a stone list class, and customer name, cubed cost, tax, parameters. And methods to get total costs, taxes etc.

The stone list class is a list of stone classes. Each stone class has quality, height, width, length parameters and methods to get cost, get taxes, etc.

But all I do is store the measurements in a list, each list (stone) is stored in another list, and I iterate. Calculations are done on adding a stone, or when you recalculate the whole list. I know it's not big, complicated, or impressive example but for me it was easier to implement it classless.

Re: In defense of complicated programming languages

#268

Post by aix1 »

garethrowlands wrote: post #230
robalni wrote: post #177

> The complexity of Rust's ownership model is not added to an otherwise simple program, it is merely the compiler being extremely pedantic about your code obeying rules it had to obey anyway. Not exactly. I remember when I learned Rust a few years ago (so maybe things are different today), sometimes the compiler didn't let me do things that should have been perfectly fine things to do. This forced me to write the cod…

Fun computer science fact: any type system will disallow some otherwise valid programs and also allow some invalid programs. The trick for type system designers is to find a sweet spot.

I'm curious if this is a provable result or an empirical observation?

(Come to think of it, I'm not even sure what's meant by program validity in this context.)

Re: In defense of complicated programming languages

#269

Post by dTal »

throwaway889900 wrote: post #255
dTal wrote: post #233

Earlier quoted context omitted.

Well respectfully, you provided the original project spec as an example of where objects were required, and I demonstrated that no, they mostly weren't. I agree that it's unproductive for you to keep adding things to the spec so that I can demonstrate that nope, you still don't need objects to do all that. All that objects are, are functions glued to data. That's it. Whether or not you choose to glue them together, t…

Make Dog implement Healable, duh.

The original author can do that. Another author cannot add that functionality later, as a library. The can only define a new kind of dog.

Re: In defense of complicated programming languages

#270

Post by weavejester »

jakobnissen wrote: post #18
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.

Right, that's true. I think structs are inevitable, and classes is the way to get structs in Python. But yes, the entire OOP-classes with namspaced methods and "self", that's not inevitable

I'm not even sure structs are inevitable. You could write a language around open sets of key/value pairs, for example.
Post reply on HN