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

321–330 of 379 posts

Re: In defense of complicated programming languages

#321

Post by astrange »

cogman10 wrote: post #317
astrange wrote: post #305

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. 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 kn…

That's true, but often the things it erases are what's confusing you. For instance, it can remove highly abstracted C++ templates and dead code. Or if you don't know what a construct does, you can compile code with and without it and see exactly what it does.

Often new programmers think asm/low level programming is scary, but because it's so predictable it's actually quite easy to work with… in small doses.

Re: In defense of complicated programming languages

#322

Post by geenat »

Python modules are basically a singleton class. It's somewhat unique among languages (JS has this too).

Makes it so you can "unit test" modules without actually using a Python Class. I see the Python Class as a way to get a "module within a module".

Nice side effect of Python modules as singletons: The "self." is implicit to the scope of the module- This makes them a joy to write.

In most other languages, yeah, you'll want some form of encapsulation so you can write tests.

Type checking can cut down on the amount of tests you need to write, but you're continually paying for it with dev time. This is a decision that needs to be made depending on what the project is, whos working on it. If I'm on a team with a lot of new people who will try shoving data where it shouldn't go, yes, gonna force type checking and take the velocity hit.

Re: In defense of complicated programming languages

#323

Post by coldtea »

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

>Anyhow, I essentially have a hard time learning how languages work without looking at the assembler coming out of the compiler. I learn languages from the bottom up, but I've never seen tutorials written that way.

Funny, that's similar to how I learned assembly! I wrote some small program, and then used lab equipment to monitor the bits flipping in the PC circuits...

Re: In defense of complicated programming languages

#324

Post by weavejester »

pjmlp wrote: post #294
weavejester wrote: post #284

Earlier quoted context omitted.

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.

It's when it's part of the core language, as any Turing complete language can implement any feature of any other Turing complete language. It's not a useful statement to say all languages support all features.

Re: In defense of complicated programming languages

#325

Post by weavejester »

Supermancho wrote: post #293
weavejester wrote: post #273

Earlier quoted context omitted.

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

Alan Kay defined object-orientated programming as having messaging, state hiding, and late binding. I think the ship has sailed on the last one, but the first two properties hold true for at least all the object orientated languages I'm aware of.

A closure lacks messaging by default, so it's not an object. You can certainly make an object from a closure, and in an object orientated language a closure may be itself represented by an object; but responding to messages is not an inherent property of a closure.

It's not useful to say that all languages have all features; the line has to be drawn somewhere. Being able to theoretically write an object system for a language doesn't make the language object orientated.

Re: In defense of complicated programming languages

#326

Post by patrick451 »

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…

I don't really buy this. It's like saying we should teach about fields before addition of real numbers, or about measure spaces before simply C^n. The most abstract version of a concept is usually much more difficult to grok.

Re: In defense of complicated programming languages

#327

Post by wruza »

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.

I believe that today a cold branch is just gets predicted as not taken and stays as such because it never jumps (in terms of a predictor’s statistics, not literally).

Re: In defense of complicated programming languages

#328

Post by novok »

adwn wrote: post #135
novok wrote: post #66

Earlier quoted context omitted.

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.

I'm curious to hear where you've seen Rust not scaling to large teams or codebases?

Generate 1 million lines of stupid repetitive code that varies slightly with a 100 line script and you'll see it happen quickly. Same issues with swift and even kotlin to some level. I don't have specific experience but I've run into it with other people who use both languages. My personal experience is swift.

If 1 million lines sound crazy to you, you just need 200 engineers working on one project for a year or two.

Re: In defense of complicated programming languages

#329

Post by novok »

dchftcs wrote: post #235
hypertele-Xii wrote: post #123

Earlier quoted context omitted.

To me, the abstraction is an oversimplification of actual, physical, systemic processes. Show me the processes, and it's obvious what problem the abstraction solves. Show me only the abstraction, and you might as well have taught me a secret language you yourself invented to talk to an imaginary friend.

I don't believe most productive programmers learned the quantum physics required for representing and manipulating 1s and 0s before they learned out to program. Abstractions are useful and efficient. You're more comfortable with a certain level of abstraction that's different from others. I can't endorse others that try to criticize your way of understanding the world, but I'd also prefer if some people who in this t…

I think part of it comes from believability, or the inability to make a mental model of what is going on under the hood. If something seems magical, you don't really understand what is going on, it can make it hard to work with because you can't predict it's behavior in a bunch of key scenarios. It basically comes down to what people are comfortable with what their axiom set is. It gets really bad when the axiom set is uneven when your teaching it, and some higher abstractions are treated as axiomatic / hand waved, while other higher abstractions are filled in. This is also probably an issue for the experienced, because they have some filled in abstractions that they bring from experience, so their understanding is uneven and the unevenness of their abstraction understanding bugs them.

Like limits in calculus involved infinity or dividing by unspecified number seems non functional or handwavy in itself. Like how the hell does that actually function in a finite world then? Why can't you actually specify the epsilon to be a concrete number, etc? If you hand wave over it, then using calculus just feels like magic spells and ritual, vs. actual understanding. The more that 'ritual' bugs you, the less your able to accept it and becomes a blocker. This can be an issue if you learned math as a finite thing that matches to reality for the most part.

For me to solve the calculus issue, I had to realize that math is basically an RPG game, and doesn't actually need to match reality with it's finite limits or deal with edge cases like phase changes that might pop up once you reach certain large number thresholds. It's a game and it totally, completely does not have to match actual reality. When I digged into this with my math professors, they told me real continuous math starts in a 3rd year analysis class and sorry about the current handwaving, and no, we wont make an alternative math degree path that starts with zero handwave and builds it up from the bottom.

Re: In defense of complicated programming languages

#330

Post by ncmncm »

lispm wrote: post #318
ncmncm wrote: post #303

Earlier quoted context omitted.

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?

You have maybe noticed that Emacs is a single program? (OK, two or three, historically.) Emacs Lisp code that doesn't integrate with the rest of Emacs just doesn't work.
Post reply on HN