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

141–150 of 468 posts

Re: Things I Was Wrong About: Types

#141

Post by TeMPOraL »

cconroy wrote: post #99
TeMPOraL wrote: post #72

Earlier quoted context omitted.

Same here! I've started with C++ and Java, learned to hate excessive typing, went through a long period of dynamic typing, and now I'm at the point you and the the author are. I still code a lot of Common Lisp on the side, but my Lisp code now looks entirely different than it looked just 3 years ago. The language standard does support optional typing declarations, and there's an implementation (SBCL) that makes use o…

"statically, strongly typed Lisp that still doesn't sacrifice its flexibility and expressive power" SML

... with sane (i.e. s-expression based) syntax.

:).

But I'll check out SML. That's Standard ML, right?

Re: Things I Was Wrong About: Types

#142

Post by svieira »

aazaa wrote: post #95

> Type inference: because having to write out every type, however obvious, is an incredible waste of time. Person me = new Person(); is ridiculous. let me = new Person(); may seem like a small improvement, but spread over the body of an entire program and generalized to all sorts of contexts means that type annotations become a tool you employ because they’re useful — for communicating to others, or for constraining…

Once you get to Java 11+ you get `var`, so you can spell it `var me = new Person()`.

Re: Things I Was Wrong About: Types

#143

Post by kybernetikos »

tluyben2 wrote: post #100
kybernetikos wrote: post #78

Earlier quoted context omitted.

The view I've heard expressed is that deep thought on a piece of code reduces bugs. Whether that takes the shape of religious TDD, rigorous proofs or detailed type design doesn't make such a lot of difference. I used to be fully bought into types, but I've since realised that they have a number of downsides that in many cases more than offset their benefits: 1. Ergonomic typesystems require a lot of work to happen at…

I am positive about a lot of these points for the future. Especially the performance points; that's going forward fast. But yes, that's often pretty slow; not that bothered by it for my work though. Also, linters work well for statically typed languages too; I usually don't have to compile for 100s of lines of code. If the editor does not complain, it'll probably all work fine. Like I said; do what works for you , bu…

> you cannot program without knowing what data you are getting

Types almost always overconstrain. Each part of your code relies on some very specific properties of your data, yet most type systems end up restricting your function to only work with data that meets a whole bunch of other properties that your code doesn't actually care about.

Re: Things I Was Wrong About: Types

#144

Post by edem »

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 this is the "profound enlightenment experience" ESR was talking about in his seminal paper "How to become a hacker?".

Re: Things I Was Wrong About: Types

#145

Post by edanm »

wutbrodo wrote: post #129

I which there was a little more elaboration on _why_ he originally disliked types so much. This perspective is still very strange to me, as the value of types seems self-evident for systems more complex than a script, and I'd like to understand it better. As it stands now, my only assumption is that this comes from the place the author is coming from: people who don't think types are useful are generally coming from…

I originally worked with C++. I then moved to Python and loved it, partially because of the dynamic type system. I'm still in the dynamic-types camp, though I haven't really learned a language with a good static type system yet, and the little I've learned of Haskell has made me super interested in a good type system.

To answer your question, the reason I prefer Python to C++, in terms of types at least, is that I feel the type system makes you get the order of building a program wrong. I think the right way, in most cases, is an agile-style, prototype-first approach. You should usually start with the simplest prototype of something that does what you want, then slowly expand and generalize as you learn more about the problem domain and make product and design decisions.

With C++, you usually start off with lots of decisions on how your data looks, and it's usually really hard to make changes afterwards. This forces you to make a lot off the architectural decisions when you know the least, and are fairly locked into those decisions.

The main benefit proposed benefit of a type system, or at least of C++'s type system, is that the compiler can help you catch type errors. However, these errors represent a small fraction of possible buga - so you're going to have to write tests anyway, and it's not hard to add type tests as well (where relevant- the idea is that it's often less relevant than you think!).

Caveats to my opinion:

1. I haven't worked in C++ for many years, and I know that there's been a lot of changes. Not sure how my opinion stacks up to current cpp.

2. If the type system gives you more than just catching some class of errors, I can see that it might be worth it. Again, no real experience with anything other than Python and js in many years.

3. I'm pretty sure I'm right about the correct way to build software in terms of steps. The older waterfall approach where everything is designed to front makes little sense in most projects I've seen, or at least in the early phases. Possibly something like Excel, in exchange there's very little new product development and in which the product domain is super well understood, has different trade offs.

Having said that, I might be wrong about how much cpp forces you to do things the other way. That was my experience and most people's that I know- but that was also the common way to do things in the past anyway. Possibly, there are good ways of doing that kind of development in cpp today.

Re: Things I Was Wrong About: Types

#146

Post by christoomey »

Toutouxc wrote: post #18

Is 'Maybe Haskell', mentioned in the article, worth reading? Or can anyone recommend a similar book of the 'just enough to be dangerous' kind on Haskell or maybe Clojure?

'Maybe Haskell' is a fantastic intro to using types and why you might care about them. It's focused in scope and really meant to give you a taste of some functional ideas and a bit of Haskell, and in that effort it does a great job.

Also, you can't beat the price ($0). If nothing else, probably worth browsing through to see if something resonates with you.

Re: Things I Was Wrong About: Types

#147

Post by kybernetikos »

marcosdumay wrote: post #131
kybernetikos wrote: post #78

Earlier quoted context omitted.

The view I've heard expressed is that deep thought on a piece of code reduces bugs. Whether that takes the shape of religious TDD, rigorous proofs or detailed type design doesn't make such a lot of difference. I used to be fully bought into types, but I've since realised that they have a number of downsides that in many cases more than offset their benefits: 1. Ergonomic typesystems require a lot of work to happen at…

There's a lot of things, some about old-school types (Java, C), other about modern ones. I don't think most are fundamental, even though some are common experiences today. #1 is fundamental. (Yet people somehow live with the JS ecosystem that's slower than GHCi.) It's supposed to evolve into always becoming a smaller problem, since computers are always getting faster; but I don't think we've put everything we can int…

> #2 and #3 are about old-school types.

There absolutely are approaches to this that don't fall foul of my complaints, but when you say 'old-school types' I think you're talking about Java and non inferred types.

I was including other more modern languages in my criticism. Scala for example ends up with pretty hairy types very quickly for higher level code. So much so that they made the documentation system lie about the types to make it easier to understand.

And most currently popular languages don't give you runtime access to types and allow you to treat them as first class.

The languages that allow you to deal with types with the same language you write code in are not remotely mainstream. So unless by 'old school' you include all mainstream languages then I disagree.

Re: Things I Was Wrong About: Types

#148

Post by edem »

I've been using Kotlin (which is very similar to Typescript, the language the author also mentions) to great effect mostly because 2 of those points (type inference and sum types) and something else that's also very powerful and not mentioned in the article: extension functions.

Re: Things I Was Wrong About: Types

#149

Post by kybernetikos »

tluyben2 wrote: post #139
marcosdumay wrote: post #131

Earlier quoted context omitted.

There's a lot of things, some about old-school types (Java, C), other about modern ones. I don't think most are fundamental, even though some are common experiences today. #1 is fundamental. (Yet people somehow live with the JS ecosystem that's slower than GHCi.) It's supposed to evolve into always becoming a smaller problem, since computers are always getting faster; but I don't think we've put everything we can int…

> Yet people somehow live with the JS ecosystem that's slower than GHCi. I think a lot of people, including the parent, seem to equate speed of ecosystem and iteration with web development and instant reload of web pages. When other systems allow fast iteration, it goes unnoticed unless it's for web dev. Luckily, a bunch of those 'impossible' systems have to now too, like [0]. [0] https://ihp.digitallyinduced.com/blo…

Web development is an example. Fast iteration is the thing that I like. I have so far associated fast iteration with dynamic languages, and it is certainly the case that my experience is that most fast iteration systems are dynamic.

But maybe that simply reflects a concern of the relevant communities. If strongly typed language systems start adding fast iteration approaches to things and are able to achieve a similar level of quick iteration then that will definitely address one of the things I dislike about them. I haven't coded significant amounts of haskell since 2000, but back then what you could do interactively was very restricted.

At the end of the day, the compiler is doing a bunch more stuff in strongly typed languages. It's like taking a bunch of your verification infrastructure and saying 'these must run before you're allowed to see the result of what you wrote'. It will necessarily be slower, although with work maybe it won't be so much slower that it matters.

Re: Things I Was Wrong About: Types

#150

Post by TooCreative »

mplanchard wrote: post #116
TooCreative wrote: post #85

Earlier quoted context omitted.

Wishful thinking. You know it returns an array, but you don't know what the array contains. So you don't know how to use it. You still need to look into the code to see what it returns. Then you will see that it returns an array and what the array contains. And now you had to process the information that it returns an array twice. Once in the function definition and once in the function body.

Most type systems also provide information about what’s in the array, like Array or int[]

That is just another piece of metadata. But it does not help either. Now you know you get an array of strings. But you still don't know what is inside of the strings.

It might be ['headers'=>'...','body'=>'...' ] or ['status'=>'...','response'=>'...'] or god knows what.

And you are back to reading the function body.

Post reply on HN