Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

Post reply on HN
Print view View original

301–310 of 468 posts

Re: Things I Was Wrong About: Types

#301

Post by joelbluminator »

jerf wrote: post #251
deckard1 wrote: post #209

I see a lot of comments on HN the last few years that just assume the dynamic vs static debate was settled at some time. It never ended. Static typing merely became trendy because dynamic typing was the trend for many years (Ruby, PHP, Python, Perl, JavaScript). Like all fashion, things that are trendy will once again become untrendy, and the cycle repeats. With that said, it's important to note that type inference i…

I don't think dynamic typing will ever swing back. They came out of an era when types were expensive and had moderate benefit. Now they are cheap (in modern languages) and have significant benefits. There will always be things like shell scripts and stuff, but I don't expect to ever see a big language without a good typing story ever again. The problem to solve now is to lower the costs more and raise the benefits, n…

> will ever swing back.

Does it need to swing back? Python/JS/PHP/Ruby are still plenty popular. And no, JS isn't typescript.

Re: Things I Was Wrong About: Types

#302

Post by solidasparagus »

ysavir wrote: post #285
SebastianKra wrote: post #282

Earlier quoted context omitted.

These features are now available in all common text editors. Also keep in mind that you're missing out on many other arguably essential tools such as debuggers, smarter shortcuts, and other static analysis. Therefore, yes, I think it should be expected of a programmer to pick the right tools for the job, in the same way that it can be expected of a designer to be able to work with Adobe files. If classic VIM doesn't…

> These features are now available in all common text editors. It's not just a matter of whether they're available, it's a matter of whether it's a fair expectation. I've been developing for a decade and never found that I'm "missing out on many other arguably essential tools". Typically I'm as productive or more productive than my peers. I get that you think usage of these features is a fair expectation. Can you pro…

Working with code as if it is raw text is strictly inferior to working with code as raw text + AST. If that’s how you want to work, that’s fine, but it’s probably not good to choose your team's technologies because you want to work at that lower lever of abstraction.

Re: Things I Was Wrong About: Types

#303

Post by AnimalMuppet »

pavel_lishin wrote: post #118

A lot of people in the comments are saying how they started off in Java, or C, and hated types, but eventually grew to love them. I started off in PHP. It was wild. Anything could be anything. Refactoring was a nightmare. Our codebase was littered with mystery variables like $hold, $hold1, and $holda, which were re-used all over the place. (Granted, this two other problems entirely orthogonal to types.) Then I got a…

I had almost the same experience, first learning Basic and Fortran, then coming to Pascal and C. The difference is, I just was a student. I didn't write anything big enough to really get the need for types. For a couple hundred lines, that only had to live for maybe a week, who needs types? So when C and Pascal demanded them, I was annoyed.

A few decades later, I really value them. My code now lives for decades, not for weeks. Lines are measured in the hundreds of thousands. Other people work with me. Types eliminate a set of errors. They're worth the effort.

I think time is where the tradeoff lies. How long are you writing for? If your code is only for this week, types maybe are a net loss. If you're writing for a month, maybe it's a toss-up. But if you're writing for a year, types are a net win.

Re: Things I Was Wrong About: Types

#304

Post by cuddlybacon »

throwaway894345 wrote: post #138
temporallobe wrote: post #130

Earlier quoted context omitted.

Even though I learned C/C++ in school, I started off my career with a typeless language, Perl. I loved it for its simplicity and power to quickly spool up working code, but realized it was problematic to use for large projects for many of the same reasons you state. I then switched to a Java project and was immediately frustrated with types because of how verbose it was, but after a while I came to appreciate just ho…

I've often felt that some people dislike types because they expect to be able to write code in a certain way that they know will make some very narrow happy path work now and they get really frustrated when the compiler tells them that there are other paths in the code that don't work. "Why is this stupid compiler slowing me down?!". This frustration betrays the programmer's indifference toward the broader quality of…

I think types also get in the way of writing speculative code, which is something I did a lot more often when I was new.

Run what you have so far. Print the last value you computed. Crash. Verify the data has the "shape" you expect it to. Write a bit more code. Repeat.

Re: Things I Was Wrong About: Types

#306

Post by solidasparagus »

bdavis__ wrote: post #252
ysavir wrote: post #225

Earlier quoted context omitted.

Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be wr…

i tend to agree with you. maybe more than just agree. if any of these "IDE's", or "tools", or whatever they are called actually provided a universal improvement in software quality and development time, then i would change my view. experienced developer, the tools don't make a difference. VSCode, VisualStudio, Eclipse, tried many of them. This is from my experience, it may or may not be universal.

It's weird to make this argument in a thread about how type inference is only problematic if you aren't using a modern tool that understands the code at a level higher than raw text. Clearly the tool is making a difference.

Re: Things I Was Wrong About: Types

#307

Post by dcre »

ysavir wrote: post #225
billisonline wrote: post #212

Earlier quoted context omitted.

> Types are meant to document code. Without the annotations, you can't look at code and know what is going on With the rise of VSCode IntelliSense/JetBrains code inspection, do you believe this is still true today? The programmer now has easy ahead-of-time access to inferred types that used to become available only at compile time or runtime

Should it be expected that all programmers use these text editors and have access to these tools? As someone that likes to keep his editor simple (to an extent--I'm using VIM after all), I always get frustrated when people try to introduce policies or procedures that work for them and their preferred setup, and who look at me as an obstacle because I prefer a different setup. I'm of the opinion that code should be wr…

You can use these features very easily in Vim with ALE. Map a shortcut to :ALEHover and that's it.

https://github.com/dense-analysis/ale

Re: Things I Was Wrong About: Types

#308

Post by SPBS »

TooCreative wrote: post #4

I code without types. My "proof", that types do not pay for themselves goes like this: Every time I encounter a bug (during coding, testing or in production) I make a note what type of bug it was and how it could have been prevented. Types are way down on the list of what could have prevented the bug. Especially for production bugs, which are the most important of course. It is so rare, that a bug could have prevente…

It's not just about preventing bugs. Types restrict what you can do with each variable, such as what methods/members exist on the variable and what valid operations you can do with it. It makes development easier because you don't have to hold it all in your head. Every member/method access is validated at compile time, without needing to write any tests.

You may not make such mistakes when writing dynamically typed code, but if you ever need to change something (like the name or type of a variable/method/member) it inevitably means trawling through all references in your codebase manually and changing them by hand. Please correct me if there's a better way to do it in dynamically typed languages.

Re: Things I Was Wrong About: Types

#309

Post by joelbluminator »

mattgreenrocks wrote: post #224
jgilias wrote: post #19

I once told a JavaScript guru colleague of mine that I was spending my free time dabbling in Haskell. His response was 'lol, why would you do that?'. His point was that spending time learning things that you're not going to be using directly any time soon is a waste of time. My point was (and still is), that learning such things opens up a completely new way of thinking about problems and potential solutions.

Anti-intellectualism in programming is fascinating to me. The variance in skill between individual programmers is immense, and languages act as force multipliers on that. There are huge opportunities that emerge from pushing yourself to explore new paradigms and domains.

> There are huge opportunities that emerge from pushing yourself to explore new paradigms and domains.

What are those opportunities? As a Rubyist, to me it makes more sense to become really good in Ruby. As I get older and more expensive, I need to be better than the 3 year experience 26 year old colleague. And if not better at least not noticeably worse. Learning Elixir, Go, Haskell or you name it isn't gonna help me. Not in intellectual terms and not in practical terms. Also there are so many other worthy things a person can do with his time other than learning a new programming language (both within programming and outside programming), we shouldn't judge people by their passion or lack of passion for learning new languages.

Re: Things I Was Wrong About: Types

#310

Post by AnimalMuppet »

cel1ne wrote: post #236
cel1ne wrote: post #37

Types are important and necessary. Can you skip them in a typed language? Yes, just use any, Object or whatever the equivalent. Can you add them to an untyped language? No. They are not needed anywhere. But I argue that especially JavaScript module-systems would have benefited greatly from them. A million lost hours in fixing obscure "undefined is not a function"-errors from output of highly dynamic pluggable build/t…

"They are not needed anywhere." -> This should have been "They are not needed everywhere."

No, they are not needed anywhere. Anything you can write, you can write in an untyped language.

That's a pretty strict definition of "need", though. There are many situations where types can help, even if they aren't absolutely needed.

Post reply on HN