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

111–120 of 134 posts

Re: Typing Is Hard

#111

Post by mariusor »

Chris_Newton wrote: post #29

Those interested in this subject might also enjoy What To Know Before Debating Type Systems : https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wr... It’s one of those older articles where not everyone will agree with everything, but there’s still a lot of insight and food for thought.

> The knowledge of the compiler in a statically typed language can be used in a number of ways, and improving performance is one of them. It’s one of the least important, though, and one of the least interesting.

Erm... no. I don't mean to invalidate the whole article from just this quote, but it's this kind of thinking is what makes today's applications slow, from browsers to office suites and web-sites. Wasting computing resources because you can, is a lazy way of thinking about development in my opinion.

Re: Typing Is Hard

#112

Post by seanmcdirmid »

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.

I think that’s where our experience with type systems could be used to improve our testing methodology and technology. Having the ability to reuse tests in client modules would effectively fix that gap (eg by generating fakes for the original modules from its tests).

Re: Typing Is Hard

#113

Post by Measter »

saurik wrote: post #68
dwhitney wrote: post #27

it drives me absolutely insane that this TypeScript compiles: const num: number = [][0]

FWIW, most (arguably any/all) non-dependently-typed languages would let that slide, as [] is of type "array of (at best) X (which could be inferred as number by working backwards from the declaration)" and one of the operations you can do on an array is to index it, by a (maybe unsigned) integer, with 0 (either way) thereby being a valid index. For this to fail, in addition to the type of the array being parameterize…

While not a dependently-typed language, the Rust compiler can do this here for arrays. Arrays in Rust have the length as part of their type, which is compile-time constant, and if you're indexing with another compile-time constant the compiler will check it. So for a line:

    let number: i32 = [][0];
The compiler knows the array is 0-length, therefore the index is out of bounds, and emits this error:

    error: this operation will panic at runtime
     --> src/main.rs:2:23
      |
    2 |     let number: i32 = [][0];
      |                       ^^^^^ index out of bounds: the length is 0 but the index is 0
      |
      = note: `#[deny(unconditional_panic)]` on by default
Of course, it's trivial to defeat by converting the array to a slice first, then you get a runtime error.

As an aside, am I the only one who got Four Candles'd by that title?

Re: Typing Is Hard

#114

Post by skrebbel »

scubbo wrote: post #44
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…

> infloop I had never seen this word before, and while I assume it's probably short for "infinite loop", I initially parsed it as "in-floop", as opposed to "out-floop".

Yep, correct! Thanks :-)

Btw i love "out-floop" and I'm going to try to find applications for it.

Re: Typing Is Hard

#115

Post by clownpenis_fart »

cryptica wrote: post #84

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

that's the dumbest thing i've read today, grats

Re: Typing Is Hard

#116

Post by wutbrodo »

ygra wrote: post #108
wutbrodo wrote: post #50

Earlier quoted context omitted.

That seems like a pretty insane default. Do you happen to know what the thinking is? While I'm fortunate enough to have never needed to spend significant time working in JS and its spawn, I've heard a lot of good things from people I respect about TS and its incremental typing approach, so I'm starting from the baseline assumption that this is a reasonable choice.

There seem to have been a few options that are disabled by default and emit additional errors, that slowly get turned on by default in later versions. Perhaps this is one of them.

That's reasonable, thanks for the info

Re: Typing Is Hard

#117

Post by panzerklein »

wutbrodo wrote: post #50
panzerklein wrote: post #36

Earlier quoted context omitted.

It won't with --noUncheckedIndexedAccess on.

That seems like a pretty insane default. Do you happen to know what the thinking is? While I'm fortunate enough to have never needed to spend significant time working in JS and its spawn, I've heard a lot of good things from people I respect about TS and its incremental typing approach, so I'm starting from the baseline assumption that this is a reasonable choice.

This option is too extreme to be enabled by default. Even --strict shortcut that turns on a bunch of useful checks does not include it.

Re: Typing Is Hard

#118

Post by oalae5niMiel7qu »

nullifidian wrote: post #103
cryptica wrote: post #99

Earlier quoted context omitted.

If a surgeon needed the help of a computer to make sure that he/she didn't confuse your heart for your kidney, would you trust that surgeon to do an operation on you?

And yet medical mistakes occur pretty frequently. "We removed the wrong kidney" and the like.

Off-by-one errors occur frequently in programming, and static typing does nothing to prevent them, since n and n+1 are always of the same type.

Re: Typing Is Hard

#119

Post by Person5478 »

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…

> 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.

Typescripts goal was to interoperate with existing javascript in an easy manner, and doing so forced them to relax the type system in specific ways.

It turns out more typing is better than less typing so typescript > javascript. That doesn't mean something with stronger typing than typescript isn't strictly better in all of the facets you mentioned, just that typescript made that particular tradeoff and had MS behind it.

Re: Typing Is Hard

#120

Post by alephu5 »

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…

I also predominantly use python and JavaScript professionally, but have written a lot of Haskell, and a bit of go, rust and others.

I love haskell and GHC but it's not a builder's language. That's not to say it can't be used in production, the language is very powerful, easy to refactor, performs well and is hard to make mistakes in. Some of the tooling like QuickCheck, STM and lenses are decades beyond other ecosystems whereas simple things like logging are hard and debuggers/autoformatters/IDE tooling are less polished than their counterparts in mainstream language. I have both Haskell and Django web applications in production and it pains me to say that python is a lot more convenient and easier to iterate on.

Finally, in answer to your question I would recommend rust. It is a rising star with a decent type-system derived from ML languages. I would also characterise the language and it's ecosystem as being focused on building production software. As an added bonus it integrates well with python and JavaScript applications, and is a useful tool to have for optimising expensive algorithms.

Post reply on HN