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

311–320 of 379 posts

Re: In defense of complicated programming languages

#311

Post by WalterBright »

robertlagrant wrote: post #176
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!…

> Years later, Java appears. I couldn't figure that out, either. I thought those variables were value types. Finally, I realized that they were reference types I will resist replying to this.

Don't resist too hard, I don't want you to have an aneurysm!

Re: In defense of complicated programming languages

#312

Post by astrange »

marcosdumay wrote: post #285
loa_in_ wrote: post #278

Earlier quoted context omitted.

I always expect them to use (thread-) global state, not unlike good old errno just more structured. There's always at most one bubbling up so that's how I would do it.

But then you'll have a branch on every failable operation and slow down the happy path. This is not too different from passing the error as a value. Instead, compilers use long jumps and manually edit the stack. I'm not sure it makes a lot of difference today, but branches were really problematic by the time the OOP languages were popularizing.

They're not bad these days if they're predictable. There's a code size cost, but there's also a cost to emitting all the cleanups and exception safety too.

For instance Swift doesn't have exceptions - it has try/catch but they simply return, though with a special ABI for error passing.

Re: In defense of complicated programming languages

#313

Post by astrange »

jhgb wrote: post #144
WalterBright wrote: post #89

Earlier quoted context omitted.

Just try, my pretties, just try to understand how exception handling actually works without staring at a lot of assembly.

Well, I imagine that it would be possible by expressing its semantics using continuations. Implementing exception handling using call/cc seems like one of them favorite Scheme homeworks. And if you implement it that way, you should then know exactly what it does.

Although it's said that call/cc is a poor abstraction that's too powerful, and it'd be better to have its components instead.

https://okmij.org/ftp/continuations/against-callcc.html

Re: In defense of complicated programming languages

#314

Post by astrange »

habibur wrote: post #52
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!…

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

Unfortunately that's not quite how C pointers work - there are also things called pointer provenance, type aliasing, and out of bounds UB.

Re: In defense of complicated programming languages

#315

Post by astrange »

Banana699 wrote: post #122
raverbashing wrote: post #26

Earlier quoted context omitted.

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…

The sheer irony is that "lite" object systems like python and ruby are actually purer and more faithful to the ideals of OOP (as envisioned by Alan Kay and those with him and before him) than Java can ever be, with its ugly and unnecessary seperation between classes and primitives, a completely irrelevant distraction that is primarily a VM optimization detail which only compilers and other bytecode producers or consu…

It's not really an optimization detail, it's because Java doesn't have user-defined value types. The primitives are there because they're value types copied from C.

(Java is a memory-safe variant of Objective-C with all the interesting features removed.)

Re: In defense of complicated programming languages

#316

Post by astrange »

aix1 wrote: post #268
garethrowlands wrote: post #230

Earlier quoted context omitted.

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.)

Programs are proofs and so this follows from Godel's incompleteness theorem. But "invalid program" needs defining.

Re: In defense of complicated programming languages

#317

Post by cogman10 »

astrange wrote: post #305
cogman10 wrote: post #225

Earlier quoted context omitted.

Is it possible to really learn how programming concepts work, though? Modern optimizing compiler are pretty amazing and just seeing the assembly output may make a concept harder to grasp. To your bridge analogy. At this point what we are saying is "give me a method to traverse this river" and compilers are either building bridges, shooting out maps to fallen trees, or draining the river all together. If you looked at…

> Is it possible to really learn how programming concepts work, though? Modern optimizing compiler are pretty amazing and just seeing the assembly output may make a concept harder to grasp. They usually have debugging options that let you read the internal steps (SIL, LLVM, GIMPLE, etc). That can be easier to understand than full asm, but also, the asm can't hide anything from you unless it's obfusticated.

> the asm can't hide anything from you unless it's obfusticated.

I think that misses the point. It's not the case of the ASM hiding things, it's a case of the optimizing compiler erasing things.

Here's a simple example: You say "Ok, the time I need to wait is 30 minutes. This method takes seconds, so I'll send in 60 (seconds in a minute) * 30 (minutes). The compiler is free to take that and say "Oh hey, 60 * 30? I know that's simply 1800 so I'll put that there instead of adding the instructions for multiplication".

Trying to learn how something like that works from the ASM output would leave you confused trying to reason where that "1800" came from. It's not hidden, it's not obfuscated. It's simply optimized.

That's a simple example, but certainly not the end of the optimizations a compiler can apply. The ASM isn't lying, but it also isn't telling the whole picture. The very nature of optimizing compilers is to erase parts of the picture that's ultimately only there for programmers benefit.

Re: In defense of complicated programming languages

#318

Post by lispm »

ncmncm wrote: post #303
marcos100 wrote: post #199

Earlier quoted context omitted.

Flexibility usually has a cost. It's not better or worse.

Correct! When the language provides apparatus to do the thing, everybody doing the thing is incentivized do it the same way, making libraries implicitly compatible. Cobbling things together yourself (which you can always do: these languages are Turing-complete) you are unlikely to do it compatibly with what anybody else does. This might be why Lisp never developed an ecosystem. Everybody can make their own pile of ma…

Example: GNU Emacs comes bundled with 1.5 million lines of Lisp code. How was that possible, given that Emacs Lisp has macros?

Re: In defense of complicated programming languages

#319

Post by 62951413 »

verdagon wrote: post #4
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.

Is it possible to optimize too much for experts, and sacrifice learning curve too much?

Haskell comes to mind.

In all seriousness, not really. Learning curve doesn't matter for a language that we'll pay your bills for the next twenty years. And once you fully internalize a JVM/.NET-level platform or Scala/C++-level language a lot of that will be reusable in learning others.

Re: In defense of complicated programming languages

#320

Post by skohan »

AnimalMuppet wrote: post #277
skohan wrote: post #236

Earlier quoted context omitted.

I disagree that you'll be a worse computer scientist. Computer science doesn't happen in Plato's heaven, it happens in real processors and memory. I tend to think focusing on abstractions is almost always the wrong approach. Abstractions should arise naturally as a solution to certain problems, like excess repetition, but you should almost always start as concrete as possible.

I would disagree with where you are drawing that line. I would say that computer science does happen in Plato's heaven; software engineering happens in real processors and memory. But most of us are actually software engineers (writing programs to do something) rather than computer scientists (writing programs to learn or teach something).

I agree that there is some value to purely theoretical work, but I think this is over-valued in CS. For instance, in the first year of physics instruction at university, problems are often stated in the form of: "In a frictionless environment..."

I think a lot of problems are created in the application of computer science because we treat reality as if there are no physical constraints - because often it is the case that our computers are powerful enough that we can safely ignore constraints - but in aggregate this approach leads to a lot of waste that we feel in every day life.

I think incremental cost should play a larger role in CS education, and if every practitioner thought about it more we would live in a better world.

Post reply on HN