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

291–300 of 379 posts

Re: In defense of complicated programming languages

#291

Post by WalterBright »

pornel wrote: post #193
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…

Rust has this problem with its module system. It has top-level "items" that can be functions, types, global variables, …or modules. The way modules are defined and imported is consistent with defining and importing of named structs and functions. But every new user is totally confused about this (I'm not even sure if my explanation above will be understood), because everyone expects modules to be a special case of im…

D's original symbol table system was completely consistent, extensible, and orthogonal. I explained it till I was blue in the face, and exactly zero people understood it. D now has a significantly more complex one.

Re: In defense of complicated programming languages

#292

Post by webjunkie »

abernard1 wrote: post #160
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…

> Can someone point me to an example where a class is more suitable than a function working on an object like an associative array? I/O or resources. Any time you're interacting with a stateful system like an API or a database, there's inevitable setup and maintenance to keep access to that resource sound. Additionally, you rarely care how that resource is kept coherent, you just need to access it at parts of your pr…

> Without a class or some system that keeps some bookkeeping data around with methods, every function has to have that bookkeeping state passed in as a handle, and all of a sudden all functions need to know something about how setup works, as opposed to what it does.

Classes make so much sense for me in this space, that I can hardly see why people would defend not using them.

Additional to your points, having things in classes with clear interfaces makes it possible to easily integrate new underlying functionality without changing the contract. For example you only store things on S3, have a nice class with store methods and so on. You can just add another different storage backend. How would you do that using functions only? If they also need to take care of setup? A nightmare.

Re: In defense of complicated programming languages

#293

Post by Supermancho »

weavejester wrote: post #273
Supermancho wrote: post #25

Earlier quoted context omitted.

> Classes are not a design inevitability, but just one way of managing state What "Classes" are is a tragedy of things. Classes are closures, with a syntactic form that allows for nested composition. This is a particularly brittle form and these qualities are found in all languages with Classes. Language maintainers, as they currently exist, have failed to concede that this is a bad idea, because "it works good enoug…

>> Languages that mostly avoid mutable state don't tend to have object systems, for instance. > They do, in the form of closures. You can build an object system from closures, certainly, but I wouldn't say closures are objects by themselves. An closure lacks inbuilt messaging, which is usually considered a requirement for an object.

> You can build an object system from closures, certainly, but I wouldn't say closures are objects by themselves.

This raises 2 issues.

1. Is a closure an object? An "object" is conceptual, not based on a specific algorithm.

Then you mention a capability of messaging being a requirement for the Object concept.

This is where arguments start going off the rails in casual language discussion because people combine the idea of what a language can do (capability), what a language was designed to do (designed-for) with the supporting ecosystem, and what's possible in a turing machine by virtue of what other languages provide (in capability/designed-for).

You can message to other closures via methods, just like the vast majority of languages currently support. This kind of messaging is not async, which seems like a stupid cheat on the idea of a message, but it makes sense once you start running lots of synchronous objects with independent lifecycles, locations, and identity characteristics...then you realize the quick cheat costs you in large distributed systems while being very efficient in smaller systems, imo.

Re: In defense of complicated programming languages

#294

Post by pjmlp »

weavejester wrote: post #284
pjmlp wrote: post #283

Earlier quoted context omitted.

Some would say that starting from lambda calculus it would be enough to reach there. I advise some reading "The Art of the Metaobject Protocol", or similar literature.

Obviously any Turing complete language can implement an object system, but that's clearly different from the language having an object system built in .

We can start discussing semantics then, when a language supports a feature, it is only when it is hardcoded on the compiler, or the language offers enough lego blocks to do it via a library.

Re: In defense of complicated programming languages

#295

Post by anonair »

marcosdumay wrote: post #207
LEDThereBeLight wrote: post #90

Earlier quoted context omitted.

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…

Yes, you are correct. But you are wrong too. People need complete understanding of their tools. And complete understanding includes both how to use the concepts they represent and how those concepts map into real world objects. If you don't know both of those, you will be caught by surprise in a situation where you can't understand what is happening. That focus on the high level only is the reason we had a generation…

IMO this is very elitist view of software developers' job.

The analogy from tangible world would be all the bridge engineers using "proven" / "boring" / "regulator endorsed" practices and techniques to build a "standard" bridge versus those constantly pushing the limits of materials and construction machines to build another World-Wonder-Bridge. There is nothing wrong with having both types of engineers.

Re: In defense of complicated programming languages

#296

Post by robalni »

duped wrote: post #261
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 be…

I made a macro because it was more complicated than just S.Y. It was more like `Something.get_stuff().unwrap().things`

Re: In defense of complicated programming languages

#297

Post by WalterBright »

Koshkin wrote: post #137
WalterBright wrote: post #95

Earlier quoted context omitted.

I didn't understand how engines worked until I took them apart, either. I was taking things apart to understand them long before computers :-) But the notions of sending a "message" to a "method" just was way way too handwavy for me. I like examining the theory after I learn the nuts and bolts. > Understanding what a bridge is doesn't mean knowing how to build one If you don't know how to build one, you don't underst…

> sending a "message" to a "method" I think you mean “to an object.” The problem with an approach like yours is that implementations of abstract concepts often vary, and learning the “nuts and bolts” of one does not necessarily give you the true understanding of the concept itself.

Yeah, sending a message to an object via a method.

Re: In defense of complicated programming languages

#298

Post by WalterBright »

yodsanklai wrote: post #113
LEDThereBeLight wrote: post #90

Earlier quoted context omitted.

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…

I tend to agree with you in principle, but for me too, a lot of high-level features are better understood in term of translations. Objects, coroutine, closures... Even in formal CS, it's common to define the semantics of a language by translation, which can give more hindsight than operational semantics. Now that I think of it, I think the problem is that most languages are defined informally which can be imprecise a…

I've found that C compiler documentation on how their extensions work to be woefully inadequate. The only way to figure it out is to compile and examine the output. Most of the time, the implementors can't even be bothered to provide a grammar for their extensions.

Re: In defense of complicated programming languages

#299

Post by WalterBright »

dogleash wrote: post #196
LEDThereBeLight wrote: post #90

Earlier quoted context omitted.

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…

>There's a reason why computer science professors explain concepts at a high or abstract level and don't jump into implementation to help students understand them. It's because they're trying to teach something to people who don't have anything to build on. Later in their education that'll be different. At the school I attended Object Oriented Programming class had Computer Organization as a pre-req and the teacher w…

I did not understand what virtual functions were at all until I examined the output of cfront.

Oh, it's just a table of function pointers.

Re: In defense of complicated programming languages

#300

Post by ncmncm »

cttet wrote: post #62
ncmncm wrote: post #36

Earlier quoted context omitted.

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.

Again, you miss the point.

Identically the same person, at different times, is confused by what seems like pointless extra apparatus, and, later, embraces it as solving a problem they have come, after experience, to recognize.

"One needs data" is, in this context, nothing better than meaningless bluster.

Post reply on HN