Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The type system is a programmer's best friend

dusted.codes

Post reply on HN
Print view View original

221–230 of 467 posts

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

#221

Post by lapcat »

saagarjha wrote: post #106
PainfullyNormal wrote: post #102

Earlier quoted context omitted.

> What's more, for a programmer who doesn't get the value of types, the major downsides are already apparent, at least at a basic level. How could the downsides possibly be apparent if the upsides are so mysterious they need an article to spell them out? > It's an article design to help certain programmers learn a particular thing Have they actually learned that particular thing if they don't know the tradeoffs they'…

How can the downsides of having to wear a seatbelt possibly be apparent if the upsides are so mysterious they need an article to spell them out? People have a quick aversion to things all the time. Sometimes the actual benefits need to be carefully explained. (“You are statically likely to be in a car crash. Wearing a seatbelt multiplies your chance of living through it.”)

I think almost everyone understands the benefits of both types and seat belts. The fact that a seat belt keeps you restrained during a crash is pretty intuitively obvious. The idiots who don't wear seat belts either (1) believe they'll beat the statistics, and thus no statistical argument will convince them or (2) value their "freedom" a lot more than they value their own lives.

In any case, though, wearing a seat belt or not is a choice one can make independently of all other factors. The cars come with seat belts, it's the same car either way. You click or not, nothing else changes about the car.

With types, however, that's not how it works. The tradeoff is... you may have to change your entire programming language, change your IDE, change your frameworks, rewrite existing code, etc. It's not analogous to seat belts at all. Do programmers want the compiler to catch mistakes? Of course they do, in an ideal world. Why wouldn't they? But there are a lot of tradeoffs here that don't exist in the case of seat belts.

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

#222

Post by acchow »

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…

You say “prefix 20” but there was this weird trend in the early-mid 2000’s where Ruby evangelists really believed that TDD is just as good as static types - even better because you’re forced to test actual business logic! And they even managed to convince masses of programmers that this is true!

Glad that’s over.

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

#223

Post by acchow »

highwaylights wrote: post #145
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…

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…

This must be strictly an old school Valley problem. Up in the city, IDEs are standard. How would you even write Scala at Twitter without an IDE?

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

#224

Post by abraxas »

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…

Kind of a perpendicular discussion but it amazes me that with this language server thing hipsters turned what was a very mature and proven pattern (a plugin architecture) into a distributed software problem. My god talk about doing shit the hard way...

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

#225

Post by abraxas »

I'm learning Python after 35 years of working with statically typed languages (Pascal, C++, Java, a bit of Typescript lately) and by god this is hard. Not because there is anything in the language that I don't understand but the lack of any type info is killing me. I just can't build up a rhythm of coding. I feel like every five lines I have to sprinkle in print() statements to keep track of the data transformations as there is nothing useful that can be captured about it even with these weak ass "type hints". I know that even when I get this crap to work I'll hate going back to that code in a few months as I'll have forgotten what the hell it all did and will have to spike it with print() ad df.shape() again to make sense of it. And naming discipline can only get you so far.

Maybe dynamic typing just isn't my thing and I need a new gig...

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

#226

Post by tremon »

tsimionescu wrote: post #184
mikewarot wrote: post #3

I once attended a meeting where a Professor from a University somewhere in Chicago gave a brilliant demonstration of using a similar type system for dealing with values in Electrical Engineering. It made quite sure you couldn't do things like add volts and amps. [Edit] it also handled things like parallel resistances, etc. It was in C++ if I recall correctly. This is a great idea, that I've haven't had cause to use y…

Note that most such solutions break (or become much much much more complex) if you want anything more than simple arithmetic from them. For example, matrix multiplication with typed values (where each element of the matrix can have a different type/unit of measure) is extremely ugly code, and basically no such library supports it - even for matrices of fixed size (say, code that could multiply 3x3 matrices with 9 typ…

matrix multiplication with typed values (where each element of the matrix can have a different type/unit of measure)

Is this really a common occurrence? In most situations I've come across, it's the matrix itself (rows/columns) that has a unit of measurement, not the invididual columns. Tensors, rotation matrices, lighting maps: they all use the same units of measurement.

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

#227

Post by jlarocco »

noveltyaccount wrote: post #151
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…

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…

> When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code competition...well, there are no bonus points for doing things the hard way.

I can't speak for Vim, but Emacs has stepped debugging, code completion, etc.

Part of the reason I use Emacs is that I get those features and (and a ton more) with the same light weight interface across multiple languages and platforms. At the same time, it's usually very easy to make Emacs work with third-party tools. On Linux I can step through code using GDB through Emacs, but at work I spend most of my time in Emacs, but have it bring up the MSVC++ debugger when I need it. It's the best of everything.

Meanwhile, I get to listen to my coworkers celebrate new features in VSCode that I've used in Emacs for years...

There are no bonus points for learning a new IDE for every project, either.

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

#228

Post by tremon »

mhaberl wrote: post #7

>A string value is not a great type to convey a user's email address or their country of origin. So we have a type for "country of origin". And then some country that you have in the records splits up into 2 countries, what do you do then? Do you keep a list of all countries that ever existed and keep it up to date? This approach works good in some cases, but not always

What would be a use case for having a type for "country of origin" rather than a type "country"?

Do you keep a list of all countries

Why would you assume that once you create a type "country", it must explicitly enumerate all possible countries?

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

#229

Post by posharma »

highwaylights wrote: post #145
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…

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…

Oh man! why did you bring up IDEs. Now we'll argue ad nauseam about emacs vs vi vs vim vs etc.

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

#230

Post by mostlylurks »

mhaberl wrote: post #26
Ygg2 wrote: post #10

Earlier quoted context omitted.

That's an unrelated problem, that's outside the scope of model presented. Remember the physicists adage: All models are wrong, some are useful. You can have your name change as well, or your calendar can change, or etc. Does that mean we stringly type everything? No. You model changes either via a separate field(s) or some kind of change table.

> You can have your name change as well, or your calendar can change What do you mean by that? Having a type for "country of origin" would mean that the type gives you limits on what values it can hold (any country known to ever exist) so you can not say something like: Country c = "Foo" because Foo is not a country. I can't imagine having a type for a persons name that holds checks anything but perhaps a strings len…

Restricting the space of possible values is only one of the possible advantages of declaring a dedicated type for something. Even if it is not possible to restrict the space of possible values (e.g. with names, which can't realistically be restricted to any smaller subset than all possible strings), there are other advantages to having a dedicated type, such as preventing the user of the type from putting a value of that type into somewhere it doesn't belong, which is a very realistic scenario in stringly typed codebases, especially where there are similar but different sets of values, all stringly typed.
Post reply on HN