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

371–380 of 467 posts

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

#371

Post by aidos »

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…

Everything is pretty much just language servers behind the scenes these days anyway. Neovim supports those natively, so those young chaps aren’t talking about your vim of yesteryear.

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

#372

Post by aidos »

closeparen wrote: post #343
outworlder wrote: post #337

Earlier quoted context omitted.

> 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. Why do you think they are doing things "the hard way"? Emacs can have all the things you have described. And it can do that for languages that are not part of the .NET Framework, they just have to have a language…

>Why do you think they are doing things "the hard way"? Emacs can have all the things you have described In the first few years of my career I would try every few months to get these things actually installed and working in emacs. It was definitely the hard way. >The problem with "IDEs" was placing all your eggs into a single basket Eclipse is a uniquely terrible piece of software and I understand why it might polari…

I believe they’re talking about a different “hard way” in that they’re suggesting you can’t have those features in vim / eMacs etc and have to do something else instead.

You’re not wrong, configuring these editors is 100% the hard way (that doesn’t stop me from doing it though).

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

#373

Post by kaashif »

sixstringtheory wrote: post #319
kazinator wrote: post #306

> A string value is not a great type to convey a user's email address or their country of origin. These values deserve much richer and dedicated types. I want a data type called EmailAddress which cannot be null. Sure, I'm on board: I also want an e-mail address type. Just not in your shit language in which something can be of type String, yet be null reference.

Are there any widely used statically typed languages where there is no such thing as null? Wish I could find a job using one of those!

No such thing as null? No.

But in Kotlin non-nullable types are the default. In C++ references are non-nullable. Both include nullable types too.

In that specific example, String can't be null in Kotlin and neither can string in C++, although you can make them nullable by using e.g. a pointer or an optional type.

Having everything be nullable like in Java is unarguably 100% a mistake.

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

#374

Post by kaashif »

pipeline_peak wrote: post #351
dgan wrote: post #336

Earlier quoted context omitted.

that's the issue: there is no other way to create new types aside from creating a new class in mainstream languages. Those two concepts are separate, and should be treated as such. Types are not Classes, the last is just a lousy "embodiment" of the first

Classes are composite data types, what you are referring to are primitive data types. A class isn’t necessarily some wrapper around primitive types, they can contain data structures, other type instances, etc. Obviously that eventually leads to an end object containing a primitive, you can’t just have fancy trees of nothingness lol. https://en.wikipedia.org/wiki/Data_type#Classification_of_da...

> Obviously that eventually leads to an end object containing a primitive, you can’t just have fancy trees of nothingness lol.

You absolutely can have types with only one value, e.g. a class with no members.

Then you can have a tree type composed of those nothing types, where the information is in the tree structure, not in any primitive value stored anywhere.

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

#375

Post by kaashif »

Jtsummers wrote: post #123
mrkeen wrote: post #105

Earlier quoted context omitted.

If you can construct an EmailAddress, then you have a valid EmailAddress . That's the point. If an EmailAddress can be a valid or invalid email address, then just leave it as a String (since that can also be a valid or invalid email address). > You check that stuff when the data enters the system. Yes > If that place is the EmailAddress type, then you have built your system wrong. No If you validate & construct an Em…

My advice: Relax and don't argue. People who don't understand that constructing an EmailAddress type is also validating the raw email string (in this case) will never understand it. They'll remain convinced for a very long time, possibly the rest of their lives, that they know better. That passing a string around is fine as long as either you always validate it everywhere (yes, kill your performance, that's smart) or…

Your comment reads as extremely harsh but I'm also tired of this argument at this point.

In real life, I don't actually work with anyone arguing against this stuff.

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

#376

Post by za3faran »

deltasevennine wrote: post #358
za3faran wrote: post #310

Earlier quoted context omitted.

GC was one of the most important and relevant features (if not the most important) that allowed Java to penetrate, and eventually dominate the space where C++ used to be relevant in terms of middleware/business type applications. This detail matters a lot in this discussion. Then once that is taken as a given, you can compare different GC enabled languages based on other factors, such as type safety (or lack thereof…

If it does matter to the conversation then it's evidence supporting my point. I'm saying type checking isn't a key differentiator between something like JS/ruby/python vs. C++. You're implying the GC is the key differentiator. If you're saying that you CAN'T compare the python to C++ because of the GC then I disagree. GC only stops memory leaks. That is not the most frequent error that happens with C++. Clearly if yo…

GC is not just for memory leaks, but memory safety in general. It also enables several paradigms that are extremely difficult to get right without memory safety.

In order to have a proper comparison, you should control for variables that are irrelevant to the experiment. In this case, you want to look at the effect of typing, so you should control for GC. Which is why you should compare python to other GC'd static languages, but not to static non-GC'd languages.

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

#377

Post by saagarjha »

lapcat wrote: post #221
saagarjha wrote: post #106

Earlier quoted context omitted.

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

Replace it with helmets if you want a more controversial option.

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

#378

Post by jjav »

deltasevennine wrote: post #357
jjav wrote: post #303

Earlier quoted context omitted.

> A type checker won't catch everything. That's a strawman, nobody has claimed a statically typed language will catch all possible errors. It will however catch an important category of common errors at compile-time, thus preventing them from reaching production and blowing up there. Other types of logic error of course exist, in all languages. > Something like c++. You get a runtime errors. You have no idea where it…

>I don't know what this means? You seem to be suggesting that code in a statically typed language cannot be debugged? You don't know what it means probably because you don't have experience with C++. These types of errors are littered throughout C++. What you think I'm suggesting here was invented by your own imagination. I am suggesting no such thing. You talk about strawmen? Literally what you said can be viewed as…

> You don't know what it means probably because you don't have experience with C++.

I started developing in C++ in 1992, so I have a few years with it. I've never run into the problems you seem to be experiencing.

> Type errors that happen at runtime or compile time contain the same error message.

Yes. But for the runtime error to occur, you need to trigger it by passing the wrong object. Unless you have a test case for every possible wrong object in every possible call sequence (approximately nobody has such thorough test coverage) then you have untested combinations and some day someone will modify some seemingly unrelated code in a way that ends up calling some distant function with the wrong object and now you have a production outage to deal with.

If you had been catching these during compile time, like a static type system allows, that can never happen.

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

#379

Post by lapcat »

saagarjha wrote: post #377
lapcat wrote: post #221

Earlier quoted context omitted.

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

Replace it with helmets if you want a more controversial option.

How do helmets change the argument?

Like seat belts, you can choose to wear or not wear a helmet independent of all other factors. The motorcycle or bicycle is exactly the same regardless of whether you're wearing a helmet. Also, everyone understands the benefits of a helmet. The benefits don't make everyone wear a helmet, but everyone is clear about why there are helmets.

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

#380

Post by icedchai »

deltasevennine wrote: post #363
icedchai wrote: post #315

Earlier quoted context omitted.

I think it's better to catch errors sooner than later. This is where type checking helps. I've seen plenty of Python code that takes a poorly named argument (say "data").. is it a dict? list? something from a third party library like boto3? If it's a dict, what's in the dict? What if someone suddenly starts passing in 'None' values for the dict? Does the function still work? Almost nobody documents this stuff. Unless…

>I think it's better to catch errors sooner than later. This is where type checking helps. Agreed. It is better. But it's not that much better. That's why python is able to beat out C++ by leagues in terms of usability and ease of debugging and safety. This is my entire point. That type checking is not the deal breaker here. Type checking is just some extra seasoning on top of good fundamentals, but it is NOT fundame…

Well, we do agree on something! I too much prefer programming in Python over C++. I honestly hope I never have to touch C++ code again. It's been about 5 years.

I try to add typing in Python where it makes sense (especially external interfaces), mostly as documentation, but am not overly zealous about them like some others I know. Mostly I look at them as better comments.

Post reply on HN