Live data from Hacker News

Things I Was Wrong About: Types

v5.chriskrycho.com

441–450 of 468 posts

Re: Things I Was Wrong About: Types

#441
post #419

Earlier quoted context omitted.

Also, many beginner programmers work on small code bases in every sense of the word. These days I will often have to glue together some tiny part of two or three enormous APIs, some of which are "auto generated" from some other system. Think LINQ-to-SQL or WCF. It's amazing when you can take a 100 MB chunk of code, and simply "navigate" to the thing that you want using tab-complete, in the sense that "somefactory.som…

> If you're working with a "blank slate" PHP app (or whatever), where you've personally written most of the lines of code involved, typing can feel unnecessary. > If you're glueing together Enterprise Bean Factory Proxies all day, then strong typing is practically mandatory. Might that not be a problem, though? Shouldn't more software systems be small, elegant and well-architected rather than a spaghetti nightmare na…

Have you seen the enormous scope of something like Azure Resource Manager? Amazon Web Services releases several new products or major features per day. They all have APIs.

Office and Office 365 is also a behemoth that covers entire suites of business products, front-end and back-end.

If you start to seriously talk about integrating these things with a bunch of third-party components, you're talking tens of gigabytes of binaries.

> But … maybe we could stand a little simplification?

Always. Unfortunately, that runs up against the limitations of our squishy meat brains. Especially when they're numbered in their tens of thousands. Simplification, refactoring, and code reuse requires coordination.

I too am horrified that a mere database engine no longer fits on a standard DVD disc... when compiled into a binary.

But I can download the ISO image in a matter of minutes, and use the system with a few button clicks in an IDE to produce functional software.

I know that the raw numbers should qualify as a nightmare, but at the end of the day, things get done anyway and it doesn't seem to matter that much.

I guess we're just horrified because we know how this particular sausage is made...

Re: Things I Was Wrong About: Types

#442

Earlier quoted context omitted.

I think you misread the post! I very much like TypeScript, am a core contributor to the TS work in the Ember.js ecosystem, and am actively involved in efforts to make TS a first-class supported language in my day job!

Oh, I was referring to this: > If you talked to me about types in programming languages six or seven years ago, you would quickly have learned that I was not a fan. > I was working with Python and JavaScript and simply didn’t miss types at. all > I understand why I thought that types were worthless from 2012 – 2014. In fact, for the specific languages I had used up to that point, I continue to think that the types do…

Ah, I can see how you got there. I was not working with TS then; like most people I didn’t yet even know it existed. At the time, I preferred untyped JS and Python to typed C, Fortran, Java, C++.

Re: Things I Was Wrong About: Types

#443
post #251

Earlier quoted context omitted.

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.

Python/JS/PHP/Ruby are still plenty popular... but the weight they are putting on "dynamically typed" is decreasing over time. Basically, all the dynamic languages are creeping towards the statically-typed side with various partial annotations and optional features. But there are no statically-typed languages I know of rushing to add more dynamically-typed support to their languages. If you draw all those language trends out, they don't meet in the middle; they meet solidly in the "statically-typed" area.

I phrased that carefully; obviously they aren't going to stop being "dynamically typed" under the hood. But, slowly but surely, those language's contribution to "dynamically typed" is decreasing, and I expect, will continue to decrease.

In another 20 years, I expect "dynamically typed" will be looked at as a complete mistake by the oversimplification process of history, as the number of people who were around when they were getting popular and understand why they were so attractive decreases. I do, myself; I experienced being liberated from some really, really crotchety languages by the freedom of Python 2.0, and I understand why the people of the time analyzed the programming landscape, and decided that the problem was "static typing" rather than "bad static typing", because there weren't any examples of good static typing. But now there are, and they aren't going to go away, and I expect that barring legacy languages, the choices in the future are going to be simple static typing like Go, complicated static typing like Rust, really complicated dependent typing like $LANGUAGE_YET_TO_BE_BUILT, and tiny languages like shell designed to never write programs in them large enough for typing to even matter.

Re: Things I Was Wrong About: Types

#444

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 used JavaScript for years and then used C# for years. During all those years, I also use languages with advanced type systems like TypeScript, Scala, Idris, etc.

I still hate typing in Java / C#. I feel intellectually insulted from time to time. There are too many times I can naturally express something in natural languages or just JavaScript, but cannot easily express those in Java or C#.

TypeScript is great, it lets me express many things I want, but it's more or less bloating and inconsistent. I always have to worry if the signatures are hard to read for the team members.

Interestingly, TypeScript reveals a lot of use cases to the mass - there's more to type systems. It's not possible to write a typesafe 'printf' in most of the statically typed languages. Maybe a full-sized dependent typed language like Idris will come in sight in the following decades.

Re: Things I Was Wrong About: Types

#445
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 love types.

I just didn't when I was new to programming. I learned Python because that's what I saw pitched to me all the time. There was a local Python meetup, MIT's CS courses taught Python and Udacity eventually taught Python. I loved the language and learned quickly how to do a bunch of basic stuff

But I wanted to make Android apps and, ugh, Java confused the crap out of me. It wasn't so much the language, but rather "URI? Where in the world do I get one of those?! Oh, you instantiate a URI with the string. In Python this is just a String..."

Or another time, once I had mastered types, I convinced my Javascript team that Typescript was Worth It. And the ensuing chaos when nobody understood how to use Types and nothing would ever compile for anyone.

All SUPER noob-y mistakes. All because I (or my team) didn't understand how to think in Types. Furthermore, people who can Think in Types often don't know how to articulate that thought process to others.

Re: Things I Was Wrong About: Types

#446

Earlier quoted context omitted.

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 love types. I just didn't when I was new to programming. I learned Python because that's what I saw pitched to me all the time. There was a local Python meetup, MIT's CS courses taught Python and Udacity eventually taught Python. I loved the language and learned quickly how to do a bunch of basic stuff But I wanted to make Android apps and, ugh, Java confused the crap out of me. It wasn't so much the language, but…

I'll also throw out there that scripting languages w/o types tend to have a lot less tooling around the language. People are used to being able to type whatever they want and things kinda just work.

Typed languages are very different. The tooling is far more robust and more able to point out errors, but also tends to be more complex than just a simple text editor.

This is changing with VS Code and LSP being a thing, but it still influences those communities in fundamental ways.

Re: Things I Was Wrong About: Types

#447

Types are controversial because we can't measure engineer productivity. Full stop. I see people on here arguing that they are faster one way or the other, yet we have absolutely no empirical evidence for such a claim. What makes it more complex is that "fighting with types" often takes one out of the flow in a different way than usual progamming challenges. Since it's unmeasurable, we cannot see the effect of product…

Exactly. There is a lot of post-hoc rationalisation happening, along the lines of: > I like language/technology X. Why? Well I'm obviously a super smart and rational person, so my preferences could only be based on facts and logic. Therefore everything I like must be objectively correct. QED. Anecdotally, the more someone prides themselves on being intelligent and logical, the less skeptical they are of their unsubst…

Keep in mind though, the statement that "and get 3x the functionality" <- right there, that's what is unmeasurable. We can't know. We have no unit of measurement, so no one could possibly know. A practice could be 100x faster, but because software is rarely as important as marketing, sales, and luck, we'd never know. A dev team that's 100x slower could still win, and it probably happens regularly. It's the essential issue with all tech discussions. We assume that "hand waving" someone would notice. But without any unit of measurement, I posit that no one ever will. There are so many network effects that change the success of a software project that is unlikely that even in another 50 years we will have consensus.

Re: Things I Was Wrong About: Types

#448

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 been jumping between Java, ruby, Javascript for some years now.

Ruby flexibility is amazing. I love the language and syntax frameworks built around it. Amazing.

Except for investigating and refactoring. Everything in Java, even in worse written systems, was fairly easy to understand and find using intellij and friends. Meanwhile in ruby if someone gets messy it might be impossible to figure that code out.

I like the concept of typescript best. Types when you want them. No types when you just prototyping. It was actually my favorite aspect of Adobe flex when I had a short stint coding in it 12 years ago.

Re: Things I Was Wrong About: Types

#449
post #415

Earlier quoted context omitted.

> “ IMO, static typing gets blamed for problems that are usually caused by OOP: complexity caused by needless abstractions (mostly inheritance taxonomies).” That’s fair, since most of the issues are caused by poor attempts to create “concepts” that match a problem domain and encode them in the type system, which is a very OO mentality. But it’s not exclusive to OO, you can get the same problems in functional language…

Interesting. Seems we have very opposite experiences. I definitely agree that one can paint themselves into a static-typing corner where refactoring becomes painful (but as I said, usually because of OOP). Also in big projects care needs to be taken to keep compilation times manageable. > Languages should facilitate thinking of enforced correctness as a gradual concept, like gradual typing in Python, so the programme…

> “ Depends on the domain. In web-based non-critical applications, maybe. If there's a bug, users gets and error etc. reports it, you push a fix to prod and things are usually OK. In things I mostly worked with (embedded, automotive, on-premise appliances, systems, p2p, finance), the cost of debugging and fixing small bugs is far too high.”

I disagree here. The main systems I worked on using dynamic typing and treating safety and correctness like resource trade-offs have been high-frequency trading, banking, ecommerce fraud detection, and real time image processing - all cases where failures are costly and stakes were high.

In fact when the stakes are high, it’s even more critical to use gradual notions of safety & correctness, because you even more urgently need to put the trade off decisions in the hands of engineers and business / product leaders.

Re: Things I Was Wrong About: Types

#450

Earlier quoted context omitted.

> As a Rubyist Are you a Rubyist, or a developer? > 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. Yeah, I had this line of thinking. I don't recommend it. I eventually realized I don't want to play the same game as people who are willing to throw away more than I am. Specifically, I don't want to be in position…

> Younger devs will work longer, not have families I work in a country where work hours are 8.5 hours (the half hour is for lunch). Period. If you consistently do more than that you'd be seen as someone who can't get his work done in time. So it's just not culturally encouraged to do that. I come from a much more capitalistic society originally, so I know first hand these companies/societies you speak of exist, and I…

> within web dev, the question is how can I be more valuable to a Ruby team - as someone who did 3 years python, 3 years php and 3 years elixir or as someone who did 9 years Ruby?

As your career progress, your value is less the volume of code produced and more how you improve those around you, be it via processes, mentoring, abstractions, and guidance.

Post reply on HN