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

341–350 of 467 posts

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

#341

Post by grumpyprole »

waprin wrote: post #220
emodendroket wrote: post #154

Earlier quoted context omitted.

I don’t disagree that it makes things much more pleasant, but I started doing this around 2013, which, while old, was still a year beginning with 20, and consensus was trending the opposite way and people were bullish about stuff like Ruby. The pendulum has really swung in the other direction.

I noticed this too and I have a simple explanation. Ruby and Python overtook Java and C++ in the early 2010s in _spite_ of their lack of a good typing system, not because of it. On the whole, they are much more productive languages. Now we're seeing languages that have Ruby / Python productivity but also have much better ways of static typing such as Typescript and Swift. And the Ruby / Python community is more open…

> [Swift] it's such a great example of how you can have a language that feels like a scripting language but with much more advanced type safety.

There are great examples far older than Swift, for example ML that dates back to the 1970s, or OCaml that's as old as Java.

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

#342

Post by MrJohz »

outworlder wrote: post #337
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…

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

IntelliJ and VSCode have both worked pretty well with anything I've thrown at them, I'd consider them both fairly successful as IDEs "to rule them all". Obviously they're both very different ends of the IDE spectrum, but they've both had intellisense, debugging, type revealing, and refactoring features for all the mainstream languages I've tried with them. VSCode particularly tends to integrate well with LSPs.

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

#343

Post by closeparen »

outworlder wrote: post #337
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…

> 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 polarize people against IDEs for life. The JetBrains products are pretty good and, importantly, modular and consistent enough across languages that I don't mind.

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

#344

Post by closeparen »

acchow wrote: post #223
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…

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?

There's a pendulum swing back and forth between local compilation being supported or not... currently settling onto VSCode remote, with Jetbrains Gateway trying to catch up in usability.

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

#345

Post by morelisp »

abraxas wrote: post #224
pcthrowaway wrote: post #167

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…

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...

LSPs turn a M*N problem into an (ideally) M+N problem. You can't do that with any existing single editor's plugin architecture, basically by definition.

Ctags is a better analogy, and LSP has fairly obvious advantages compared to it.

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

#346

Post by hardwaregeek »

c7b wrote: post #118
hardwaregeek wrote: post #95

Earlier quoted context omitted.

Sure there are tradeoffs, but I disagree that it’s always so balanced. When people moved from assembly to high level languages presumably there were tradeoffs but in retrospect it’s a pretty clear cut choice. I’m not saying typed languages are as big of a shift as high level languages but it’s possible they are the unequivocal right choice.

Does that also hold for people doing data science in Jupyter notebooks? They're also programmers, arguably. At this point in the trajectory of software engineering, it's fair to assume that most of the low-hanging fruits have been picked, and solutions that are unequivocally better would have to bring something fundamentally new to the table (which types are not at all). Most solutions will be picking a particular po…

Why are you sure that all of the low hanging fruits have been picked? The origins of software development are pretty much still within living memory. We’re still extremely new to programming. I wouldn’t be surprised if the field looks completely different in 50 years.

As for types, I’m not saying they’re flawless. I’m pointing out that in the transition from assembly to high level languages there were flaws and criticisms that came out. But looking back fifty years, were these flaws and criticisms genuine tradeoffs that kept assembly as a reasonable option for most developers? No, they were not. Now we look back on programmers who insisted on writing assembly as oddities, as niche figures. I cannot say if this will be the case for types, but I won’t rule it out.

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

#347

Post by nmarinov »

yellowapple wrote: post #267
Our_Benefactors wrote: post #245

Earlier 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.

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 ;)

Have you tried the latest couple of releases?

I used to have that issue 5 years ago but since then it opens under 5 seconds and loads the solutions I need for not much more. Currently using it on a cheapish recent windows laptop but even on a 8gb x220 it works fine, just loads for 30 sec in the beginning and then it's smooth.

Granted I'm only opening .net solutions with under 100 projects each but anything above that is unnecessarily more difficult to navigate with just vim.

And in my experience VSCode is many times slower than Visual Studio on the same projects. None of them are as fast as barebones sublime or vim on an m1 mac but when I load the latter with plugins it's not a huge difference.

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

#348

Post by closeparen »

maxbond wrote: post #165
PainfullyNormal wrote: post #73

Articles 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

Ever so slightly longer compile times. It's pretty close to a free lunch. There are only tradeoffs when we are at the frontier of what's possible with a set of technologies, and so must trade off on something in order to move along that frontier[1]. Many languages aren't operating at that frontier, and adding static typing is free (in the marginal case, ignoring the substantial effort to implement the type system). I…

People using dynamic languages deeply, especially library and framework authors, regularly write abstract/generic code for which a suitable type declaration would be mind-bendingly difficult in a very sophisticated type system and impossible in a weak one. You can argue that this is ill-advised! But static typing with normally-powered type systems leads to more voluminous and more purpose-specific code. Very powerful type systems are possible, but treated as academic and too difficult to use in the real world.

A way this often gets worked around is code generation. Anywhere you have or reach for codegen in a static language, you probably could have used a plain old function in a dynamic language.

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

#349

Post by jmull »

hither_shores wrote: post #244
jmull wrote: post #231

Earlier quoted context omitted.

(Replying to my own post) Wow, lots of great, thoughtful replies, thanks! But I'm not convinced... Maybe it's just a bad example (this is what the main article is about, though)... Generally speaking, you need to be able to send emails to both verified and unverified emails. The difference is in what the email you are sending is about. That's why VerifiedEmail as a type doesn't make a lot of sense to me. You'll need…

> 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 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.

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

#350

Post by drpixie »

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…

We (the industry) are still so quick to disregard the benefits of strict typing.

"Back in the day..." I worked on a collection of vital (to the company) infrastructure apps written in Borland Turbo (object) Pascal. Strong static type checking was enforced by the language. Good type design and strict type checking meant that it was normal that when a program compiled, it was bug free!

Much as I enjoy the flexibility of python, I know that every refactor or significant change means that there are now execution paths that have not been exercised - the burden of comprehensive testing is enormous, far outweighing the convenience of dynamic typing.

Post reply on HN