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

261–270 of 467 posts

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

#261

Post by deltasevennine »

tikhonj wrote: post #192
deltasevennine wrote: post #168

Earlier quoted context omitted.

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!

Paradoxes don't exist in reality. It's a figure of speech based on something that was perceived as a paradox. This much is obvious.

Much of the fervor around dynamically typed languages in the past was driven largely by the dichotomy between c++ and other dynamically typed languages.

Nowadays it's more obvious what the differentiator was. But the point im making here is that type checking is NOT the key differentiator here.

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

#263

Post by pencilguin »

yellowapple wrote: post #249

> I want that data type to have helpful methods such as .Domain() or .NonAliasValue() which would return gmail.com and foo@gmail.com respectively for an input of foo+bar@gmail.com. No the hell you don't. Please please please do not attempt to separate the alias from an email address I submit. It's there for a reason - specifically, to hold you accountable if I experience a sudden influx of spam, and generally to keep…

True enough, as far as it goes. But if you are concerned about subscribing to something twice, you may want to try to check delivery uniqueness. They might be your own addresses.

Of more interest to me, omitted from the presentation--as almost always--is anything about what is disliked about a malformed address. You see this when some web form says it doesn't like your address, but won't say why, leaving you to guess and try things until it is satisfied.

Another example is the password filter that idiotically demands "at least one capital letter, one digit, and one swear character" in your already several-word passphrase, and dislikes your choice of swear characters but won't say so.

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

#264

Post by morelisp »

Chinjut wrote: post #132
throwawaymaths wrote: post #69

Earlier quoted context omitted.

It's also something that some languages seriously screw up. Consider multiplying a time (which is typed in go) with a numerical value... suppose what I want is a user to input number of time intervals to wait. So the user wants 5, and the interval is 2500 milliseconds. The way you get 12500 milliseconds out of that made me want to throw my computer out the window.

I don't understand. What should you get instead?

Go does not have operator overloading, and numeric operators must have identical types. So if you have `var x int = 5` and `var t time.Duration = 2500 * time.Millisecond`, you have to `time.Duration(x) * t` or `time.Duration(x * int(t))`.

It's slightly better than languages with no operator overloading nor newtypes at all (well, actually a lot better given other things you can use newtypes for) but without operator overloading using it just for units, with no other API machinery, is usually a bad idea.

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

#265

Post by deltasevennine »

gary17the wrote: post #203
deltasevennine wrote: post #168

Earlier quoted context omitted.

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…

> So basically compile time type checking just makes some of the errors get caught earlier which is a slight benefit but not a KEY differentiator. Unfortunately, I have to completely disagree here, at least based on my experience. Shifting software error detection from runtime to compile time is absolutely paramount and, in the long run, worth any additional effort required to take advantage of a strong type system.…

Your argument makes no sense. I say the type checker is not the key differentiator then you say for python the key differentiator is the garbage collector.

So that makes your statement contradictory. You think type checkers are important but you think python works because of garbage collection.

Either way I'm not talking about the implementation of the language. I'm talking about the user interface. Why is one user interface better than the other?

I bet you if c++ has sane error messages and was able to deliver the exact location of seg faults nobody would be complaining about it as much. (There's an implementation cost to this but I am not talking about this)

Even an ugly ass language like golang is loved simply because the user interface is straight forward. You don't get non deterministic errors or unclear messages.

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

#266

Post by yellowapple »

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…

Emacs (with e.g. company) can do much of the same, without my laptop making a fighter jet sound quiet in comparison :)

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

#267

Post by yellowapple »

Our_Benefactors wrote: post #245
constantcrying wrote: post #163

Earlier quoted context omitted.

Vim is not really an editor. It is a way to edit text, you can use vim in almost any environment. You are also totally wrong about vim or emacs not having code completion, that is just nonsense. I use (a version of) visual studio, the first thing that I did was installing a vim extension. Also vim itself already supports almost any of these features with some basic plugins for the completion logic. If I type "." in m…

Vim: I can do that too, I swear! Just configure some plugins, can’t tell you what they might be though. But I’m turing complete, and I’m the best! VScode: Of course I can do autocomplete bud. Here, search my package repo, I’ll tell you which plug-ins are the most popular and handle the entire download and install process for you. There’s no comparison.

Visual Studio: Of course I can autocomplete! Hold my beer while I bring your machine with 16 cores and 64GB of RAM to its knees for multiple minutes ;)

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

#268

Post by morelisp »

est wrote: post #49
photochemsyn wrote: post #45

Earlier quoted context omitted.

This approach to typing could have saved the Mars Climate Orbiter, i.e a pounds of force type vs. a newtons type. > "A NASA review board found that the problem was in the software controlling the orbiter's thrusters. The software calculated the force the thrusters needed to exert in pounds of force. A separate piece of software took in the data assuming it was in the metric unit: newtons.... Propulsion engineers, lik…

More like an i18n or l10n issue than types.

I think you've inadvertently stumbled on another great example, distinct types for TranslatedMessage, LocalizedNumber, etc. from ordinary string has been a cornerstone of localization enforcement on at least two large applications I've worked on.

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

#269

Post by pencilguin »

snickerer wrote: post #262

I summarize the article as "use OOP and design your classes well".

Has absolutely nothing whatever to do with OOP.

OOP, where it means anything at all, involves runtime selection of operations according to types organized in hierarchies.

TFA is about compile-time type compatibility enforcement.

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

#270

Post by afiori »

dwheeler wrote: post #61
cardanome wrote: post #52

Oh god, please just use primitive types. Don't make assumptions about things. Everyone thinks they are so smart validating emails, phone numbers, zip codes and all until their great design goes live and they discover that users in the real world do not follow their assumptions. I have seen that happen again and again. No, if your idea of validating an email is more complicated than "should have an @ symbol", I guaran…

Using specialized types can be useful, but if it provide s methods they need to be correct for ALL situations. Here's a subversion of GitHub's authentication (now fixed) where they assumed that "lowercasing domain name using English case rules is always fine and produces the same result" led to a vulnerability: https://dev.to/jagracey/hacking-github-s-auth-with-unicode-s...

TIL that punycode breaks email.split('@') to get the domain:

Apparently John@Gıthub.com normalizes to xn--john@gthub-2ub.com but Gıthub.com normalizes to xn--gthub-n4a.com.

For now I will go back to forgetting that emails not covered by /[A-Za-z0-9.-+_]+@[A-Za-z0-9.-_](.[A-Za-z0-9.-_])*/ exist to preserve my sanity but this does confuse me.

Post reply on HN