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

The Anti-Human Consequences of Static Typing

jeapostrophe.github.io

Post reply on HN
Print view View original

11–20 of 67 posts

Re: The Anti-Human Consequences of Static Typing

#11

Post by themstheones »

grannyg00se wrote: post #2

The first example of a "good" program contains an if statement that should only ever branch in one direction. I question whether that is a "good" program.

There are only four options for removing a block of code you no longer want to use:

1. Add a comment around the whole block. This may not always work, as comments within the block may need to be removed.

2. Add string delimiters before and after the block, making the block an in-place string literal. This can be broken by strings within the block.

3. Use a goto statement to skip the block. This is a pretty good method but you have to worry about the label getting moved, and fellow developers laughing at you for using goto.

4. Wrap the block with a big if (false) { }. This is the most bullet proof method, but it violates your goodness criteria.

Re: The Anti-Human Consequences of Static Typing

#12

Post by jeapostrophe »

finnw wrote: post #8

> Other more quaint languages like Java may have type systems that check properties such as "The program does not add numbers and strings" Poor example. In Java, number + string means "convert the number to a decimal string then concatenate", and it can be invoked unintentionally.

That's not a counter-example. I'm not saying that Java doesn't allow syntax that might look like "number + string", just that it does not actually add them, like C does where: 3 + "4" means something very surprising.

Re: The Anti-Human Consequences of Static Typing

#14

Post by gngeal »

chipsy wrote: post #3

I don't think I've ever seen someone use such gleefully religious rhetoric to advocate dynamic types before.

When was this a non-religious issue? But I believe the problem is following: Either the type system is incomplete (there are programs out there that you might want to run but won't be able to), or it's unsound (some programs will get a pass the type checker but fail at run time), or the type system will be so complex as to being undecidable. Since people generally aren't happy with number one, you either have to rely on the programmer (number two) or force everything to pass through a potentially loopy process every time you compile something (number three)

Ot, one might go the Qi/Shen route...

Re: The Anti-Human Consequences of Static Typing

#15

Post by freyrs3 »

dustyleary wrote: post #7

> In the final analysis, we may appeal to the Gödel Incompleteness Theorems and conclude that in every logic there are statements which are true, but not provable, or provable, but not true. Is this wrong? "true but not provable" is easy. What is an example of a statement that is "provable but not true"?

Poorly worded, and a bit disingenuous to bring Gödel's theorem in this context. Taken to it's logical conclusion, by his argument we shouldn't bother analyzing the properties of programs at all.

Re: The Anti-Human Consequences of Static Typing

#16

Post by jeapostrophe »

Kliment wrote: post #13

Are there any languages that have a type mismatch warning rather than a type mismatch error? Something like how gcc warns about incompatible pointer types when compiling C programs, but lets you use them if you insist, but for all types?

I suggest reading about progressive types:

http://blog.brownplt.org/2012/09/01/progressive-types.html

Re: The Anti-Human Consequences of Static Typing

#17

Post by Someone »

finnw wrote: post #8

> Other more quaint languages like Java may have type systems that check properties such as "The program does not add numbers and strings" Poor example. In Java, number + string means "convert the number to a decimal string then concatenate", and it can be invoked unintentionally.

Does it? I thought string + number does that, but number + string does not compile.

Re: The Anti-Human Consequences of Static Typing

#18

Post by majormajor »

themstheones wrote: post #11
grannyg00se wrote: post #2

The first example of a "good" program contains an if statement that should only ever branch in one direction. I question whether that is a "good" program.

There are only four options for removing a block of code you no longer want to use: 1. Add a comment around the whole block. This may not always work, as comments within the block may need to be removed. 2. Add string delimiters before and after the block, making the block an in-place string literal. This can be broken by strings within the block. 3. Use a goto statement to skip the block. This is a pretty good metho…

Delete it and refer to your version control system's history if you need to bring it back?

Edited addition to reduce the snarkiness a bit: if I see a block of dead code like that left in a file, regardless of which way it's been killed, I'm going to consider that bad unless there's a very clear comment explaining why this isn't needed anymore but was worth leaving in the code instead of fully deleting it. But if that comment's there, and the reason makes sense, it's still breaking the "rule" but becomes an example of knowing when to break the rule.

Re: The Anti-Human Consequences of Static Typing

#20

Post by Permit »

>The logic goes that if you reject "bad" programs then only "good" programs remain, and who would want to run "bad" programs anyways?

I thought the logic was: if you reject all bad programs and some good programs, only good programs remain, is it not?

Post reply on HN