The type system is a programmer's best friend • Hacker News Board

Re: The type system is a programmer's best friend

#191

Post by icedchai » Sat, Nov 05, 2022, 5:56 PM UTC

bluGill wrote: post #149

highwaylights wrote: post #145

Earlier quoted context omitted.

I’d take this further. I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis. Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job…

I'm adverse to debuggers as i've more than once caught myself following a rabbit hole of steping through code instead of thinking. IDEs have some use, and static analysis has proven to catch the same mistake over and over, but only as the authors of those tools have discovered that false positives cannot be allowed ever, once there is a false positive the tools is worthless.

I find debuggers more valuable with dynamically typed languages, especially Python. It's handy to be able to drop a `breakpoint()` in the middle of a script when you have no idea what a function is actually returning. The happens more often than you might think.

Re: The type system is a programmer's best friend

#192

Post by tikhonj » Sat, Nov 05, 2022, 5:56 PM UTC

deltasevennine wrote: post #168

gary17the wrote: post #104

This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20. Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible. Getting rid of bugs by experiencing, diagnosing and f…

But there's a paradox. Why does 100,000 lines of code of python tend to be safer and more manageable then 100,000 lines of C++ despite the fact that python has no type checker and C++ has a relatively advanced type checker? Why do startups choose a python web stack over a C++ web stack? I don't think it's "self-evident." I think there's something more nuanced going on here. Hear me out. I think type systems are GREAT…

There is no "paradox". C++ is dangerous because of memory management and awful semantics (undefined behavior/etc), both of which are orthogonal to static typing.

It's a bit like saying that there's a paradox: everyone says that flying is safer than driving, but experimental test pilots die at a much higher rate than school bus drivers!

Re: The type system is a programmer's best friend

#193

Post by hgomersall » Sat, Nov 05, 2022, 6:00 PM UTC

jdrek1 wrote: post #177

hgomersall wrote: post #138

Earlier quoted context omitted.

It's possible to go even further than just protecting against the wrong unit in the wrong place. You can generalise units: https://docs.rs/dimensioned/latest/dimensioned/ (Edit, that's not possible in c++)

> (Edit, that's not possible in c++) Mind expanding on that? Because what that readme there shows is absolutely possible in C++, I have used a similar system for dealing with natural units.

I'm happy to admit I'm wrong on that. My understanding is the bit that makes (kg.m)/s^2 type equivalent to a N, equivalent to J/m is not implementable in the same generic way.

Re: The type system is a programmer's best friend

#194

Post by jstimpfle » Sat, Nov 05, 2022, 6:01 PM UTC

Izkata wrote: post #179

jstimpfle wrote: post #129

Earlier quoted context omitted.

> What? Would you rather have JSON as a string or as something like Map ? This question can't be answered without additional context. What are the requirements? But as a heads up, Map couldn't be representation of all valid JSON documents. Lists are valid Json as well AFAIK. So I think this is making a point.

Based on the casing JsonValue is an object, not a primitive, so there's no reason that interface wouldn't work. It would just by a different subtype depending on what type the value is, and lists/dicts would also implement the Map interface.

As much as I can just happily ignore JSON because I don't do webdev, I think there is a strong case to make that lists should be implemented using a native list, array, or vector class. But I won't argue because it's not necessary. The possibility for argument already proves my point.

My point is to show that "the type system" provides endless rabbit holes, and often is just a waste of time. There are a lot of situations where you want to represent a JSON document as a string. (Trivial example, as an embedding in an HTTP response object).

Re: The type system is a programmer's best friend

#195

Post by jrumbut » Sat, Nov 05, 2022, 6:01 PM UTC

pcthrowaway wrote: post #167

noveltyaccount wrote: post #151

Earlier quoted context omitted.

When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code…

For the people responding to you who are saying you can get all the same things in vim, they're right of course, but a lot of this modern functionality is now built on top of the Language Server Protocol[1], which is an open standard created by microsoft for VS Code. Kudos on the people who have ported this to Vim[2], but I suspect the support for LSP features will still be better in VS Code [1] https://microsoft.git…

Code completion, search, cross referencing, and all sorts of other features in vim, emacs, and all kinds of other editors (including Visual Studio) predate LSP by decades.

LSP is cool though, an advancement certainly, but it is not a completely new thing.

https://en.m.wikipedia.org/wiki/Ctags

Re: The type system is a programmer's best friend

#196

Post by Izkata » Sat, Nov 05, 2022, 6:01 PM UTC

an1sotropy wrote: post #72

Spivak wrote: post #65

Earlier quoted context omitted.

But it shouldn’t be an error in any unit system. # oops my scaler has a unit x unit * x unit = x unit^2 The value isn’t catching this line of code since it’s potentially valid. It’s catching the line of code where you pass the result to a function that expects unit.

I agree, but the original article at dusted.codes hopes types will "prevent silly mistakes like multiplying $100 with £20". I don't know what that author would think of multiplying $100 with $20, but my point is that this embrace of type systems is apparently not just about function interfaces; it also includes the operands of things like multiplication, and preventing that operation if the types are fishy.

For better or worse hopefully they think the two examples the same.

Using the example above, "multiplying $100 with £20" can be achieved just by making the better engineer a remote employee paid in pounds. It adds the exchange rate into the mix, so the math will change over time, but conceptually the math is the same as the "dollar * dollar" example.

Re: The type system is a programmer's best friend

#197

Post by icedchai » Sat, Nov 05, 2022, 6:01 PM UTC

suzzer99 wrote: post #128

c54 wrote: post #110

Earlier quoted context omitted.

I agree with this, yet look at some of the extremely salty comments in this thread. People are upset that something might be useful and that they might benefit from learning it or changing their ways.

It's weird to me how scanning the comments all seem to refer to systems with 100k-ish LoC and dozens of contributors. A big chunk of my job is writing node microservices in AWS Lambda. I do everything I can to avoid shared library code, since past experience tells me there be lots of dragons (mainly in when and how to push or pull lib updates to components). I have a very tiny shared lib that I try to never touch and…

I've seen plenty of Lambda code developed in a "copy-and-paste" style, with little to no code sharing, similar to early CGI scripts from 25+ years ago. It makes maintainability incredibly difficult. The more shared code the better, in my opinion.

Re: The type system is a programmer's best friend

#198

Post by tsimionescu » Sat, Nov 05, 2022, 6:02 PM UTC

bjourne wrote: post #2

I don't understand. Isn't classes what the author asks for?

Class as a concept is somewhat orthogonal to type, at least to people into programming language research, who consider "type" to implicitly mean compile-time type. Classes are taken to refer to support for virtual method dispatch, while types refer to compile-time expression type-checking. In languages like Java, C++ or C#, the type of an expression corresponds to the class of the value it will have at runtime. However, in Python for example, compile-time expressions always have the type "any", but can have various classes at runtime.

This difference between class and type can even be seen in some of those languages. For example, the type *X has no corresponding class in C++ for any X. In Java, the type int doesn't have a class, and the types ArrayList and ArrayList have the same class.

Re: The type system is a programmer's best friend

#199

Post by kgeist » Sat, Nov 05, 2022, 6:08 PM UTC

ReflectedImage wrote: post #86

mrkeen wrote: post #43

Earlier quoted context omitted.

No, there should only be the one EmailAddress type. If it's not valid, it's not an EmailAddress. Does having an EmailAddress type guarantee you won't accidentally accept crap? No, but when you get it wrong, you edit the validation in one place in the system.

If that place is the EmailAddress type, then you have built your system wrong. You check that stuff when the data enters the system.

> You check that stuff when the data enters the system.

There can be N entrypoints where data enters the system (different controllers, CLI), so you must always remember to validate emails in N places, otherwise broken data could end up being passed to business logic. Data can also be constructed inside the system. It's nice to have one centralized place where email is validated. Placing it in the constructor of a special type and using only that type for email guarantees it's impossible for business logic to receive invalid emails in principle, no matter what you do, because when an exception is thrown from a constructor no object is created at all. No object = no invalid data to deal with. You know that when you see EmailAddress (or any other type where state is validated in the constructor) it's in a valid state, there's no ambiguity, and, in my opinion, it's also more readable than just some string, the intent is clearer.

Re: The type system is a programmer's best friend

#200

Post by pca006132 » Sat, Nov 05, 2022, 6:12 PM UTC

AnimalMuppet wrote: post #174

PainfullyNormal wrote: post #73

Articles like this bug me. You've given me a list of why types are awesome. Great. Now, tell me what the tradeoff is. Nothing is free in engineering. To get something, you have to give up something else. Even grug[0] understands this. [0]: https://grugbrain.dev/#grug-on-type-systems

The tradeoff is that I have to explicitly say (and know) what type I'm dealing with at every point in the program. But I'm not sure that's much of a tradeoff. If I don't know what type this thing is, how do I know what operations I can safely do on it? How do I know that I can make it do what I'm trying to do? Or will it blow up at runtime when I do that? I consider "I coded it, it's done, but it might blow up at run…

Most modern languages can do type inference and doesn't require explicit type annotation for variables. Hack, even C++ gots auto! For declarations, I think it does make sense to ask for the annotation because it can also serve as documentation. Have you ever tried scala, rust, haskell or typescript?