Hacker News Reader

Comment by handrous | Hacker News Reader

> Honestly will never go back to languages without type checking, it prevents so many bugs and is a huge help in understanding code you haven’t worked with previously.

I see static types as one of the most powerful communication tools around, as far as code goes. I can't relate at all to people complaining that they waste time. They must work very differently from how I do, is all I can figure. It's that, or they don't realize how much time they're losing to communication-related tasks, or refactoring, or writing (and maintaining!) extra or more verbose tests, or having even one more bug per year make it to production, or whatever, that'd be saved by static types, so aren't correctly accounting for the time savings. One of the two.

View on HN

Consider these 4 possible combinations for programming languages:

(1) Low-level, static types

(2) Low-level, dynamic types

(3) High-level, static types

(4) High-level, dynamic types

For whatever reason, historically #1 and #4 have been most popular. C, C++, Pascal, Ada, and Java are #1. Python, JavaScript, Perl, and BASIC are #4.

There haven't been a lot of #2 or #3 languages. Some #3 languages (TypeScript and Python with types) have come along, but relatively recently.

A person who experiences only #1 and #4 might notice that they can whip up programs faster in a #4 language than in a #1 language, then falsely attribute that difference to the static types. Whereas the real reason is working at a different level of abstraction.

I don't really see how Java is closer to C than it is to Python in terms of what level of abstraction it's working on, could you elaborate?

It's a matter of opinion whether Java's level is closer to C or Python. But I can name a bunch of high-level features in Python that aren't in Java:

List literals, dictionary literals, tuples, bigint literals, byte strings, f-strings, sequence unpacking assignment, named parameters (kwargs), decorators, closures (functions within functions), metaclasses, generators, async, list/set/dict/generator comprehensions, multiple inheritance, natural JSON support, ...

However Java do support dynamic typing for every object even if it is a bit cumbersome so putting it at the same level as C++ isn't accurate either.

C# has most of this stuff and I think Java has at least a few of these but I wouldn't say any of these are really much of a differentiator.

And at what level of abstraction does ISO C work on?

"C Is Not a Low-level Language, Your computer is not a fast PDP-11."

https://queue.acm.org/detail.cfm?id=3212479

That would be a good point if you actually could write the final code for CPU's, but you can't since the CPU internals do that for you. So from an application programmers perspective machine code is as low as it gets and C maps really well to machine code so C is a low level language.

> So from an application programmers perspective machine code is as low as it gets and C maps really well to machine code so C is a low level language.

C only "maps really well" to PDP-11 style machine code. If you want SIMD, parallel algorithms, heterogeneous programming, memory hierarchies/domains, etc then ISO C is completely useless.

Only if that machine is a 8 or 16 bit CPU, with code compiled as -O0.

And even then, it's impossible to write something like malloc() without using either an external Assembler or language extensions.

#3 languages have been around since the 80's (SML) and 90's (Haskell)

Exactly. IMO we still don't have a good #3 language - in particular, all of the popular languages that can be compiled into native code are in category #1.

I'd say rust and swift are in the #3 category. Really, C++ is pretty damn high level, just not a sound type system. But it's static

I'd say that f# haskell ocaml and such labguages fall under #3.

I can remember that in the beginning it felt cumbersome to me because I wasn't all too familiar with that language's type system and so I had all kinds of errors thrown at me.

But it's something you just have to get used to, and now that I understand it much better I feel more productive and have more confidence in my code. And the communication aspect is definitely a great help too. No handwritten documentation can be this consistent, completely independent of who touched the code (though to be fair, it's still difficult to get the naming right).

I can't imagine the people calling it a waste of time got over the hump in the beginning. To me it's obviously a timesaver. It does a tedious, difficult (for humans) task and does it quickly & with perfect accuracy. Beforehand worrying about all the type signatures and interfaces felt like 4D Sudoku across various modules, now I can concentrate on the interesting parts.

Reply on news.ycombinator.com