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

Typing Is Hard

3fx.ch

Post reply on HN
Print view View original

81–90 of 134 posts

Re: Typing Is Hard

#81

Post by islon »

username90 wrote: post #41
yoneda wrote: post #30

Earlier quoted context omitted.

On the contrary, I find myself more productive in languages that do not have pervasive null because then I don't have to manually reason about which values might be null.

People build huge programs in untyped languages, reasoning about null is trivial in comparison. The cost of not having null is that all initialization and generic code gets much harder to write and work with, the benefit is that once in a blue moon you get a hard to debug null pointer error. I've worked as a software engineer at large companies for years and never had a hard to debug null pointer error, so at least t…

> reasoning about null is trivial in comparison

So trivial that its creator called it the "billion dollar mistake" and if I had $1 for every NPE I saw in production I'd be a rich man.

Re: Typing Is Hard

#82

Post by eevilspock »

seanmcdirmid wrote: post #65
jbluepolarbear wrote: post #47

Earlier quoted context omitted.

Typescript taught me that I actually don’t care about types and all I care about is the shape of data. In most cases I think of types/interfaces in Typescript as strict data definitions. A function takes in a collection of data; as long as the data matches the shape I expect, don’t care what the data represents.

What you use the word “type” for is a nominal type and your shapes are structural types. The utility and different trade offs between nominal and structural types were explored a lot back in the 90s.

Nominal types are on Typescript's roadmap: https://github.com/Microsoft/TypeScript/wiki/Roadmap

Side note: An Introduction to Nominal TypeScript: What are nominal types and why should I use them? : https://medium.com/better-programming/nominal-typescript-eee...

Re: Typing Is Hard

#83

Post by inbx0 »

skrebbel wrote: post #5

I think we need new, better concepts to judge type systems by. Eg TypeScript has convincingly shown to a large crowd that soundness isn't an important property for many key goals of static typing, such as programmer productivity, refactoring support, preventing stupid mistakes and navigating large codebases. Soundness was Flow's big claim to fame and it just made day to day programming harder with mostly academic/cos…

I've used both Flow and TS, and we are currently using Flow. I disagree with the notion that Flow's lack of success is due to differences in soundness. Today, I think Flow's exact-by-default object types are the biggest selling point for it and it catches real mistakes that I sometimes make when I'm using TypeScript.

What made Flow fail in terms of popularity is that it lagged so far behind in editor support, the openness of development (what's a roadmap?), performance, and just overall usability and utility.

They have since picked up on performance and added some features that - you know - actually leverage the types to help you write code. Autocompleting property types works at least half the time. There are some very simple refactorings available. We are _finally_ getting autoimports.

But it's too little too late, when you use TS for a while you notice that the refactoring tools are like from some other planet than those in Flow, and then coming back to Flow and, say, rewriting imports by hand feels like coming back to stone age. Even worse, it's a self-perpetuating cycle, because the community has overwhelmingly settled behind TS and created these amazing tools to complement it, while Flow is left as a niche at Facebook's mercy. I look at projects like ESBuild or Prisma with envy.

At the end of the day, Flow feels like it was never meant to actually compete with TypeScript. It's Facebook's internal development tool that you are free to use if your priorities happen to align with Facebook's.

Re: Typing Is Hard

#84

Post by cryptica »

Static typing is a learning tool for junior level developers. Like training wheels on a bike. After 10 years or so of programming experience, the training wheels need to come off. People's attitude towards static vs dynamic typing would make a great topic for interview questions to weed out junior devs.

Senior recruiter: "How do you feel about TypeScript?"

Candidate: "I like it. It helps ensure that I don't accidentally pass the wrong type of instances to functions... Which is a very big problem for me and the people I usually work with."

Senior recruiter: "Thank you for your time... We'll be in touch..."

... Candidate walks out the door.

Recruiter: "That's a definite no... This candidate is the Neglectful type (pun intended)"

Junior recruiter: "Could have fooled me! Too bad there are no automatic candidate type checkers for us junior recruiters... That would be the greatest thing since adult diapers."

... Both recruiters break into laughter while watching their email inboxes struggle to render the massive, never-ending flow of new resumes.

Re: Typing Is Hard

#85

Post by username90 »

rowanG077 wrote: post #57
username90 wrote: post #41

Earlier quoted context omitted.

People build huge programs in untyped languages, reasoning about null is trivial in comparison. The cost of not having null is that all initialization and generic code gets much harder to write and work with, the benefit is that once in a blue moon you get a hard to debug null pointer error. I've worked as a software engineer at large companies for years and never had a hard to debug null pointer error, so at least t…

People also used to build huge castles without any power tools. That something can be done with a tool is not an argument for that tool to be efficient or even good at it.

That is your opinion though, my opinion is that type systems stricter than C# detracts rather than adds and most agree with me. People who like to discuss language theory don't, of course, since the major reasons to discuss language theory is that the popular languages don't have the features you like or that you want to specifically solve software engineering problems in the language level rather than the code level.

Re: Typing Is Hard

#86

Post by lmm »

arcturus17 wrote: post #74
refenestrator wrote: post #45

Earlier quoted context omitted.

Consider that you might be the weirdo here. Kotlin is eating scala's lunch by specifically jettisoning the advanced type stuff. If you can give 80% of the value with 20% of the confusion, that's a win for most devs.

Slightly off-topic, but say I know Python and JavaScript and I wanted to add a multi-paradigm language with strong typing to my toolbelt. I'm looking for something with a strong functional programming core but with object-oriented facilities as an "escape hatch". The languages I've been eye-balling are Scala, Kotlin and F# (I'm separately eyeing Elixir, but since it's dynamic, I'd leave it out of this particular disc…

> Slightly off-topic, but say I know Python and JavaScript and I wanted to add a multi-paradigm language with strong typing to my toolbelt. I'm looking for something with a strong functional programming core but with object-oriented facilities as an "escape hatch".

If you're looking for a language that will let you keep writing Python/Javascript in that language, you'll find it, but you won't learn anything from the experience. You won't appreciate the benefits of those type systems unless you really commit to them. (I actually learnt Standard ML first, and it made me a better Python programmer; I imagine Haskell would have a similar effect). If you're looking for "languages in my toolbelt" you'll end up "knowing" a dozen languages but coding the same way in all of them, which is useful in some ways but ultimately limiting. What's your actual goal here - e.g. are you trying to learn more languages so you can get a better job?

> My main requirements are that it's a "builder's language" with a great ecosystem for web development and growing mainstream adoption. I'm a general-purpose product engineer building apps end-to-end, and I favor general ergonomics and ease of use over other characteristics (performance, functional purity, etc.)

If by "growing" you mean you want a language on the left hand side of the hype cycle, then Kotlin is what you want. If by ease of use you mean easy to write, Kotlin will serve you well - it has that Perl-like feel of it does what you want, unless you want consistency. I pity anyone who has to maintain a Kotlin app in 5 years' time, but it sounds like it'll do what you want it to.

Re: Typing Is Hard

#87

Post by username90 »

islon wrote: post #81
username90 wrote: post #41

Earlier quoted context omitted.

People build huge programs in untyped languages, reasoning about null is trivial in comparison. The cost of not having null is that all initialization and generic code gets much harder to write and work with, the benefit is that once in a blue moon you get a hard to debug null pointer error. I've worked as a software engineer at large companies for years and never had a hard to debug null pointer error, so at least t…

> reasoning about null is trivial in comparison So trivial that its creator called it the "billion dollar mistake" and if I had $1 for every NPE I saw in production I'd be a rich man.

When you have a hammer everything looks like a nail. A language theorist trying to fix issues will of course look at changing the language first, doesn't mean he is right.

Re: Typing Is Hard

#88

Post by nicoburns »

arcturus17 wrote: post #74
refenestrator wrote: post #45

Earlier quoted context omitted.

Consider that you might be the weirdo here. Kotlin is eating scala's lunch by specifically jettisoning the advanced type stuff. If you can give 80% of the value with 20% of the confusion, that's a win for most devs.

Slightly off-topic, but say I know Python and JavaScript and I wanted to add a multi-paradigm language with strong typing to my toolbelt. I'm looking for something with a strong functional programming core but with object-oriented facilities as an "escape hatch". The languages I've been eye-balling are Scala, Kotlin and F# (I'm separately eyeing Elixir, but since it's dynamic, I'd leave it out of this particular disc…

Kotlin's a good bet with your requirements. You could also consider C# (not as new and cool, but still adding more features, and particularly well-designed language) and Rust (admittedly a little harder to use, but excellent multi-paradigm support and a strong web ecosystem).

Re: Typing Is Hard

#89

Post by WJW »

jcelerier wrote: post #73
seanmcdirmid wrote: post #64

Earlier quoted context omitted.

Or the converse “your type system is basically a very limited test suite.” Seriously though, these two concepts have some overlap that should be explored more.

> Or the converse “your type system is basically a very limited test suite.” the converse doesn't hold. You can write new code that will benefit from the guarantees of existing types. But you'd have to write new tests if you didn't have types.

Not necessarily. If you add new code to the user signup (let's say some additional checks on the shape of their username) and the integration test for the happy path of a user signup still passes, the new code is absolutely covered by existing tests (though probably not completely, there are probably edge cases not covered).

The tests/types correspondence still holds: if you write new code, you will often also need to alter the types to correctly describe the changed domain. In the username example above, after adding username validation it would be a good idea to have a dedicated `Username` type that can only contain valid usernames instead of just stuffing everything into `String`. If you count extra time writing and refactoring tests after adding new code, you should also count the extra time writing and refactoring additional types after adding new code.

Re: Typing Is Hard

#90

Post by rowanG077 »

username90 wrote: post #85
rowanG077 wrote: post #57

Earlier quoted context omitted.

People also used to build huge castles without any power tools. That something can be done with a tool is not an argument for that tool to be efficient or even good at it.

That is your opinion though, my opinion is that type systems stricter than C# detracts rather than adds and most agree with me. People who like to discuss language theory don't, of course, since the major reasons to discuss language theory is that the popular languages don't have the features you like or that you want to specifically solve software engineering problems in the language level rather than the code level…

It's not possible to solve problems at the code level. That would require every single developer writing in that language to account for all the holes in the type systems. That's completely unrealistic. And can be seen to be disastrous in practice. I mean just walk through some python code. There are almost no None or manual type checks. These are just bombs waiting to explode.

The problem with type systems like C# and Java are that they are too strict. Look at the polymorphism mess in those languages. The entire reason people hate static typing is because of the shittiness of precisely those two languages. That's the reason we need better type systems.

Post reply on HN