Live data from Hacker News

The type system is a programmer's best friend

dusted.codes

361–370 of 467 posts

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

#361

Earlier quoted context omitted.

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…

> since the shared libs have generics and I'm always casting things. This indicates to me that you're trying to write code that isn't correct (not doesn't work , but rather only works because of implicit couplings between components) and/or doing exotic lisp-style metaprogramming. In the latter case, yeah, C#'s type system isn't powerful enough. Others are (to an extent: arbitrary code execution at compile time is ne…

I mean casting to get mocks to work in unit tests, not live code.

Probably there's a better way. I'm not a C# expert. But I was a Java dev for 10 years so it's not super unfamiliar.

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

#362

Earlier quoted context omitted.

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

If you think ctags or rtags are even remotely comparable to what an actual IDE brings you you have absolutely never used more than 10% of what an IDE with semantic understanding of your code can do

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

#363

Earlier quoted context omitted.

I know it happens "all the time" but these runtime errors happen fast and quick. You catch most of these issues while testing your program. Statistically more errors are caught by python runtime then an equivalent type checked c++ program simply because the python user interface fails hard and fast with a clear error message. C++ on the other doesn't do this at all. The symptoms of the error are often not related to…

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 fundamental in itself.

>As for C++ "non-determinism": If you write buggy code that overwrites memory, then of course you're going to get segfaults. This isn't C++'s fault.

This doesn't happen in python. You can't segfault in python. No language is at "fault" but in terms of safety python is safer.

This language of "which language is at fault" is the wrong angle. There is nothing at "fault" here. There is only what is and what isn't.

Also my point was that when you write outside of memory bounds, anything could happen. You can even NOT get a segfault. That's the problem with what makes C++ so not user friendly.

>I've seen plenty of code in all languages (including Python) that appears to exhibit chaotic run time behavior. At a previous company, we had apps that Python would bloat to gigabytes in size and eventually OOM. Is this "non-determinism"? No, it's buggy code or dependencies.

This is literally one of the few things that are non-deterministic in python or dynamic languages. Memory leaks. But these are Very very very hard to trigger in python. But another thing you should realize is that this error has nothing to do with type checking. Type checking is completely orthogonal to this type of error.

>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 you read the code, you have no idea. "Determinism" of code is determined based on inputs. Type checking helps constrain those inputs.

When you get a lot of experience, you realize that "sooner" rather then "later" is better but not that much. Again the paradox reels it's head here. Python forwards ALL type errors to "later" while C++ makes all type errors happen sooner and Python is STILL FAR EASIER to program in. This is evidence for the fact that type checking does not improve things by too much. Other aspects of programming have FAR more weight on the the safety and ease of use of the language. <-- That's my thesis.

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

#364

Earlier quoted context omitted.

HTML escaping requires you to look for characters to escape for it to not interfere with HTML. This is quite literally validating symbols in the input. If they fail validation they need to be escaped. It's literally IMPOSSIBLE to do escaping without first validating every single symbol in the input.

So you're "validating" symbols now (strange choice of word). But certainly validating that the higher-level construct that we're escaping is an email address. Because the escaping procedure doesn't care.

Validating is just the process of ensuring an input is admissible in the way you want to use it. That can be symbols in a string, whether a string is an e-mail or even if a number is in a certain range. Escaping is just validation + fixup which can be used in some cases. Anyway the only way to validate an e-mail in practice is to use it and confirm.

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

#365
post #288

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…

> 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? Because C++ sucks, but static types are not to blame for that.

My point here is that static types didn't do much to improve C++. We should be focusing on what made C++ bad. The things that made C++ bad and the fixes for those things are what makes python Good.

I'm saying type checking is not one of those things.

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

#366
post #349

Earlier quoted context omitted.

> You'll need sendToUnverifiedEmail(email: UnverifiedEmail) and sendToVerifiedEmail(email: VerifiedEmail), and have code to get the right type to pass to the right function the in the right circumstance... Only if you're using a language with an insufficiently strong type system (e.g. Java, C#) in typescript: type UnverifiedEmail = { address: string, verified; false } type VerifiedEmail = { address: string, verified;…

I don't know Haskell, but in the typescript code the types aren't doing anything... sendToEmail sends to any kind of Email. And if the code wants to know if an Email is verified, it inspects the verified field. > Of course they do - they tell you that the bug is in the verification code, and not in any of the thousands of lines of business logic separating it from the place where the error was found. Whether you cent…

> sendToEmail sends to any kind of Email.

That's my point, you don't need a combinatorial explosion of behaviors for every possible most-specific-type, you can just reuse existing ones.

> And if the code wants to know if an Email is verified, it inspects the verified field.

That's exactly what you shouldn't do. Runtime "type" inspection is just bad overly distributed parsing. The point of typing is to move errors to compile-time.

    emailLaunchCodes = (email: VerifiedEmail): Promise  => ...
This doesn't need to inspect anything, because the type signature guarantees that someone else has already handled that.

> Whether you centralize the verification code (or otherwise have a separation of concerns for it) or not is independent of whether you use the type system to express when an email is verified or some other mechanism.

Separating the verification code - which is table stakes, really - doesn't guarantee that you're not accidentally adding or losing "verification" elsewhere. Types can and should.

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

#367

Types got a bad wrap because of C++. There was a strange dichotomy between languages like python/javascript and C++. If type systems were so good why was it easier to program with javascript and python then with C++? People got confused and promoted dynamically typed languages as better. What many people didn't realize was that C++ was hard DESPITE the type system, not because of it. This was soon rectified with type…

The above, while carefully tailored to tickle HN biases, has no connection with reality. Types are exactly equally as "traceable" in C++ as in Rust.

This is offensive. To suggest my opinion has no connection to reality?

Read what I wrote carefully. I'm not talking about type errors. I'm talking about errors in GENERAL.

Your comment is carefully tailored to incite flame war. You represent HN bias at it's finest, reading something and giving a casual dismissal without really interpreting it.

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

#368
post #352

Earlier quoted context omitted.

That's dependent on the implementation, SBCL is particularly good at it. Others may just let things pass like: (defun foo () (* 1 "aoeu")) In SBCL gives me this: ; in: DEFUN FOO ; (* 1 "aoeu") ; ; caught WARNING: ; Constant "aoeu" conflicts with its asserted type NUMBER. ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 WARNING condition But in CCL it gives me no warning…

Schemer here, so this question may be silly, but can't you declare or declaim or proclaim or whatever (safety 3) to get stricter typechecking?

Those are only advice to the compiler, but importantly `safety` is about run-time error checking. Pushing `speed` higher and dropping `safety` to 0 means that runtime type checks might be removed for certain things, but it's not required to. Like if you've similarly declared that a variable definitely holds a `fixnum`, it'll believe you whether that turns out to be the right thing in the end or not. But again, it's advice. The compiler could leave those runtime checks in place, too.

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

#369

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.

They’re different experiences for users with different priorities.

Your priority is evidently ease of configuration, VScode is definitely easier out of the box - there is no comparison.

My priority is hackabilty for streamlined editing and code navigation. Here neovim run circles around vscode.

Neither is “right”, just different preferences. Note that I’m not here to tell you my editor is better, I personally enjoy using it more, and that’s enough for me.

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

#370

Earlier quoted context omitted.

> But if you are concerned about subscribing to something twice I'm concerned about some service collecting my email address and "accidentally" exposing it to spammers. > 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…

If you don't want to store ill-formed addresses, you need to parse them before you store them. At issue here is only how much parsing is allowed.

And the extent of that parsing should be in accordance with the relevant RFCs (namely, 5322). Per that RFC, the local-part is an opaque string of permitted characters. Attempting to parse the local-part beyond that when you ain't the one who owns/controls that address is bug-prone at best and user-hostile at worst.
Post reply on HN