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

311–320 of 468 posts

Re: Things I Was Wrong About: Types

#311

Post by dathanb82 »

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…

> Typically I’m as productive or more productive than my peers.

This seems like a case of assuming the conclusion, tho. Whether a text editor-based workflow is as productive as an IDE-based workflow when avoiding feature that advantage the IDE doesn’t impact on whether the IDE-favoring features are valuable enough to adopt and assume everyone has access to.

Re: Things I Was Wrong About: Types

#312

Post by zabzonk »

throwaway894345 wrote: post #295
zabzonk wrote: post #292

Earlier quoted context omitted.

> no serious team is going to switch from C++ to scheme for the type inference alone and also possibly because C++ has type inference

C++ has only recently acquired type inference, as have most of the others in the prior generation of statically typed languages.

Almost 10 years ago is "recently"?

Re: Things I Was Wrong About: Types

#313

Post by the__alchemist »

I went through an intermediate phase: Typing is good for complex projects, but not simple ones. I've found even that isn't true: In simple programs, typing pays for itself when the compiler, IDE etc catches mistakes I've made.

Maybe I just make lots of mistakes. Maybe people who prefer dynamic typing are more careful/better programmers than I. Personally, I screw things up so often, it's always easier to use typing!

Re: Things I Was Wrong About: Types

#314

Post by mumblemumble »

cannabis_sam wrote: post #277
rswail wrote: post #159

A lot of people are making comments about how they can code "faster" without types. But for the majority of the code we write, inital speed isn't that important. Understanding the code and maintaining it are orders of magnitude more important for any non-trivial code. Types are not only a way for the compiler to understand your code and impose constraints. They're also your API to other programmers. When they see a s…

It’s honestly embarrassing to hear all the worthless arguments against types. The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load??? It’s just so endlessly easier to prog…

Here's my split personality:

I love love love Python for data science, in part because it's dynamically typed. I can bang things out quickly without worrying about the engineering bits, and, since I'm working in an interactive coding environment, it's generally easy enough to just inspect the values of my variables to figure out what they are.

I hate hate hate Python for ML engineering, in part because it's dynamically typed. The same features that make it so easy to hack out a quick data analysis make it absolutely awful to build for durability. For example, since stuff in production runs hands-off, you need to feel pretty confident about the return types of every function in order to feel confident you won't throw a type error at run time. Actually pinning this down can get quite complicated, though, when you're working with a library like scikit-learn that relies heavily on duck typing. Sometimes you end up having to go on a journey down a rabbit hole in order to clearly identify and document all the types your code might accept or return.

(Disclaimer: Hate aside, it's still my preferred ML engineering language. You've got to take the bad with the good, and the language gets you access to an ecosystem that is so very good.)

Re: Things I Was Wrong About: Types

#315

Post by jkoudys »

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…

My personal favourite omnipresent php vars are `$data` and `$value`. Like, no shit, what else are you storing in variables?

Re: Things I Was Wrong About: Types

#316

Post by jkoudys »

chrismeller wrote: post #186
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 went a similar path, PHP to C#, and never looked back. When I had to switch to Node for one job I was pulling my hair out constantly (and quite literally) because of stupid things that would never have happened in what I called a “real” language (that being a typed, compiled one). I mean for $deity’s sake, there weren’t even any dependency injection options at the time and many many times it turned out a bug I intr…

If most business-side people actually knew what weak typed languages meant for their company, I can't imagine so many of them going for php/js as often as they do. You're always one expression with a `$contact` instead of a `$contract` in it away from a cancelled weekend trip or humiliating sales demo.

Re: Things I Was Wrong About: Types

#317

Post by nonbirithm »

pansa2 wrote: post #170
williamdclt wrote: post #111

Earlier quoted context omitted.

> I found that static typing actually speeds up my development. It's less work, not more. It's a point that comes back often, and that I totally agree with so it's worth reiterating. In addition to the improved dev tooling (autocompletion, hinting, refactoring), being able to write large swathes of code without actually running it and being 100% confident that it's all _valid_ (not bug-free of course) just takes a hu…

> being able to write large swathes of code without actually running it and being 100% confident that it's all _valid_ (not bug-free of course) just takes a huge load off my mind. I've heard similar things before, e.g. "static typing allows you to find bugs in your code without even running it". Perhaps the reason I'm a fan of dynamically-typed languages is that I don't see the benefit of this. Maybe my workflow is u…

When moving from a dynamically typed language to a statically typed one, about the only thing I end up missing is hot reloading.

In gamedev, static types don't help when you have a constant value you have to change that tweaks the gameplay buried inside a compiled class that you want to balance out. Changing that one constant means either putting it in a script, which is usually written in a dynamically typed language, or recompiling the whole program, testing, changing the value, and repeating.

The only real reason I choose dynamic languages is because I spent hours on that last cycle just recompiling the whole program and throwing away all the state for a single small change, then getting the engine back to the previous state I was debugging in. I still don't understand if it was a bad habit or just how my mind wants me to program. I expect to be able to interact with my program and see how changing things affects the behavior very quickly, and a compile cycled shuts down that mode of thinking entirely. I remember Steve Yegge's essay that mentioned this, that "rebooting is dying." [1]

There were a lot of times I could write scripts, but the fact was that most of the time the code I wanted to tweak slightly was compiled, and that required a full module recompile every time. The fact is that if some of my code can be compiled, then I will probably end up changing the compiled code at some point, and that means a lot of waiting.

If C# had the ability to hot reload a class like a dynamic language to cut down the recompile cycle, I would be happy, but it sounds like it isn't possible. The old code will be mixed with the new code leading to instability.

So I've been spoiled by a dynamic language (Lua) while acknowledging I made a trade-off for one single feature. In my case if I used a statically typed language I would lose out on certain things and gain others, but dynamic program rewriting seems to best coincide with how I think, and I'm not sure how if I should change that.

[1] http://steve-yegge.blogspot.com/2007/01/pinocchio-problem.ht...

Re: Things I Was Wrong About: Types

#318

Post by vendiddy »

cannabis_sam wrote: post #277
rswail wrote: post #159

A lot of people are making comments about how they can code "faster" without types. But for the majority of the code we write, inital speed isn't that important. Understanding the code and maintaining it are orders of magnitude more important for any non-trivial code. Types are not only a way for the compiler to understand your code and impose constraints. They're also your API to other programmers. When they see a s…

It’s honestly embarrassing to hear all the worthless arguments against types. The cognitive load of a dynamically typed (or unityped, or “untyped” or whatever) language is massive, yet the common argument is that types «increase» the cognitive load??? How does offloading a large majority of the trivial reasoning of a program over to a type system, ”INCREASE” the cognitive load??? It’s just so endlessly easier to prog…

I agree.

And you also see many dynamic languages working around lack of types by describing the types anyway in the documentation. Like jsdoc in javascript before typescript became popular.

You are already doing the hard work of describing your types anyway, but because your compiler doesn't know the types, it can't help you out.

Re: Things I Was Wrong About: Types

#319

Post by sktguha »

TooCreative wrote: post #79
tluyben2 wrote: post #22

Earlier quoted context omitted.

What are you working on though? What algorithmic structure?

Compare this: private static function request(?string $method, ?string $url, array $options): array { ... } To this: function request($method, $url, $options) { ... } I can grasp the latter much better. It immediately forms a structure in my head that I will remember while I read other parts of the code. To do the same with the former, I think my brain uses up twice the energy or more. And even then, I will not have…

you could possible write an IDE plugin that hides the types information and only show them on hover etc. I don't think this reason is that strong of a point IMHO.

Re: Things I Was Wrong About: Types

#320

Post by mumblemumble »

joelbluminator wrote: post #309
mattgreenrocks wrote: post #224

Earlier quoted context omitted.

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

I won't speak to opportunities; I agree with you that there's a lot to be said for specialization.

But, to the point about getting older: There's a fair amount of evidence that learning new, challenging (as in, outside your comfort zone) things is a big part of maintaining your mental acuity as you age. Doing crosswords is good for your brain, but only if you're relatively new to them. If you've been an avid crossword puzzler for decades, not so much. Learning a new natural language is another example of something that is supposedly good for keeping the creative juices flowing.

I wouldn't be surprised if challenging oneself with a new programming paradigm behaves similarly. Which would mean that learning Haskell might make you a better Rubyist, not because (as people often like to say) Haskell teaches you specific things that you can't learn while using Ruby, but because the mental challenge of learning to work with such a drastically different programming language just generally helps keep you sharp.

That said, I would not go so far as to speculate that this effect is any greater for learning a programming language than it is for learning Esperanto. Just pick the one that sounds more fun.

Post reply on HN