Swift does this exceptionally well and always has your back.
The type system is a programmer's best friend
251–260 of 467 posts
Re: The type system is a programmer's best friend
#252Earlier quoted context omitted.
> this is a classic case of not needing more types but needing proper names. Those are types.
no. a type is a description of a set of values and its associated operations. Types impose global meaning on entities in your program. When something belongs to a certain type receivers of arguments of that type lose control over how to interpret them. Thus types introduce coupling. Names are just labels attached to an entity for the purpose of identification and readability, they don't impose meaning.
newtype ArbitrarilyLabeled x = ArbitrarilyLabeled x
forgetLabel :: ArbitrarilyLabeled x -> x
forgetLabel (ArbitrarilyLabeled x) = x
Re: The type system is a programmer's best friend
#253Earlier quoted context omitted.
I don't know what to tell you. The downsides are apparent. There is no logic theorem that says the upsides and downsides need to be equally as apparent. The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff. Nobody's talking about the downsides of type systems except to the extent that they're worth talking about: see the comments here every time someone compares the type s…
> The trade-off is obvious: you gain confidence about your program but you need to Learn More Stuff This is why engineering/software articles in general (this one included) needs to bring up tradeoffs more often. No, "learning more stuff" is not a downside or a tradeoff, it's just a fact of learning anything. That you introduce more coupling is a tradeoff. That the program (sometimes) gets harder to change is a trade…
> That you introduce more coupling is a tradeoff.
No, the coupling (i.e. assumptions about what type this thing can be) is implicitly there in a typeless language. If you pass in the wrong thing it'll blow up. But it'll happen in production.
The coupling is always there, it's just a matter whether you make it explicit (this allowing errors to be caught early) or you pretend it's not there and let things crash in production.
Re: The type system is a programmer's best friend
#254Earlier 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…
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…
[deleted]
Re: The type system is a programmer's best friend
#255Articles 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
For a while in the codebase I was working on, we had a set of distinct types for different units. You know, a type for meters, another for centimetres, etc etc. We had types for radians, types for degrees.
We had conversion functions between them, and type inference when you performed certain operations.
The result was a disaster. Not an enormous disaster, but enough of a problem to rip the entire thing out and replace it with plain double-prevision floating points, and sensible variable names, everywhere.
Why was this? It was a combination of there being nothing sensible to infer when you, say, multiply an angle and a distance (which happens when you're doing algebra), and everything in the whole codebase needing to be aware of these types.
The downside of all these brilliant ideas is dependency. If you define an "EmailAddress" type, as the article suggests, you've got to write the code for it somewhere. Now all your projects are dependent on this library, with all the pain and anguish that versioning and linking/including/whatever the library brings.
Before, you depended on nothing but the String type, which is very likely built into your language. When all your code needed to do was pull that email address out of some persistent store (say), and send to some other piece of code, your dependency list was just the Persistence library. But with your fancy EmailAddress type, your dependencies are now much worse.
Keep things as simple as they can be. An EmailAddress type is not useful.
Re: The type system is a programmer's best friend
#256Earlier quoted context omitted.
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.
Why do you even reply to a post that you didn't bother to read? VScode is a neovim frontend. >There’s no comparison. Read the first line of my post. There literally is no comparison, because there is a category error.
> Why do you even reply to a post that you didn't bother to read? VScode is a neovim frontend.
I did read your post Mr. snark.
> There literally is no comparison, because there is a category error.
Pure pedantry. VScode takes far less effort to get a high quality feature set when compared to vim. That’s the only point of debate that matters for most people.
Re: The type system is a programmer's best friend
#257Earlier 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…
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...
The plugin architectures that I've seen require plugins to be written in the same language as the IDE. For example, Eclipse plugins need to be written in Java.
Language servers run in a separate process to the editor, and they communicate over JSON-RPC. The nice thing about this is that the language server can be written in any programming language - which usually ends up being the language of the code being edited, rather than the language that the editor was written in.
This makes it a lot easier for language servers to be written and maintained by the people who maintain the compilers for those languages, e.g. gopls is written by the Go developers, clangd is part of LLVM.
Re: The type system is a programmer's best friend
#258Earlier quoted context omitted.
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.
Yes yes, indeed. The ability to look at what's happening step by step really hamstrings my imagination. Sorry, no. A debugger is a microscope! It will help you find problems faster and will seed your imagination by filling in what is really going on. It's an augmentation, like any tool. Or do you prefer to stare into space blindfolded?
> A debugger is a microscope! ... Or do you prefer to stare into space blindfolded?
Perhaps illustrating the original point, microscopes aren't used to stare into space. A debugger is a microscope but the most pernicious bugs don't benefit from such a thing.
Re: The type system is a programmer's best friend
#259At the opening of the article, as the author describes a type, it ends up sounding like a class to me.
Re: The type system is a programmer's best friend
#260Earlier quoted context omitted.
> Would you rather litter the entire codebase with validations that this is indeed a valid email Why would you? Just use it. For most of parts of the program it's not relevant to the computation whether the string is a "valid email", whatever that means. It's a string.
"Just use it" is what lead to the big SQL injection fallout and even today we pay the price as not even a year ago thousands of crucial service were vulnerable via log4j because of the "Just Use It" mantra.
SQL injection, XSS, and similar attacks are about incorrectly encoding embedded fragments.
The solution is either not to embed (SQL parameter bindings) or to always escape embedded fragments based on the embedding context
For reference: The Last XSS Defense Talk - Jim Manico - NDC Porto 2022 | https://youtu.be/wRC7jyhTkEM