Hacker News new | ask | show | jobs
by Tichy 6200 days ago
Some people really want static types.
1 comments

More people than you'd think, hence the current fashion for "unit tests".
Static typing hardly replaces unit tests.

And I think it's a stretch that people who use unit tests are just trying to compensate for a lack of static types. Actually, it's more than a stretch, it's false for pretty much any competent programmer.

If it were true, why would Java programmers use JUnit?

As a long time Smalltalker, let me say -- we HLL language guys should get off of our high horse about static typing. Anything that you can do to move bugs from runtime to compile time is good for the maintainer. No, static types don't catch everything. But they are desirable if they catch anything at all.

Best of both worlds -- optional static types as in Strongtalk. I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.

Strong inferred typing is (generally) superior to static in the sense that it gives you the best of both worlds, flexibility and safety. Strong typing plus a clear separation between pure and impure code gets you a lot. Test harnesses are vital still, but testing blindly (which is what most unit testing does) is scarcely better than old-fashioned manual QA.
People forget that the whole point of abandoning strong typing in environments like Smalltalk was the extreme speed of exploratory programming that it supported. If you can have strong typing and have low overhead rapid exploratory programming, then why not? Duck Typing is not a goal, it's a means!

I disagree that testing blindly is scarcely better than manual QA. If it's automated, the cost of leveraging your tests is small. The cost of adding more tests is not multiplied by iterations. With automation, increased frequency of tests can be used to localize the cause of bugs to particular changes in time.

But that's tangential. If you are doing exploratory programming, what does unit testing get you? How can you write the tests before the code if you don't have a spec to work from in the first place?

A lot of the pain of strong typing goes away with type inference - and strong typing means you get much better tool support, e.g. you can see a problem right there highlighted in your editor, you don't need to wait for the unit tests to run on your nightly build!

No, static types don't catch everything. But they are desirable if they catch anything at all.

I hear you, but come on now, static types as a replacement for unit tests? I hear they cure cancer too!

In all seriousness, optional type safety sounds pretty good to me as long as there aren't any major tradeoffs involved.

I can imagine development methodologies that demand you statically type everything before you release to production. This way, you get fast duck typing development and the security of type safety for the maintainer.

I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release? Wouldn't you then lose a great deal of the leverage of using a freedom language?

I hear you, but come on now, static types as a replacement for unit tests?

Is this a deliberate troll? Failure of reading comprehension? Where do I ever advocate static types as a replacement for Unit Tests? Why would a Smalltalker ever do that!?

I might be misunderstanding, but wouldn't this require you to rewrite your code before a production release?

There's a big difference between inserting a bunch of tags like <Integer> at the end of the development cycle, probably guided by a coding tool, possibly using Hindley-Milner type inference to automate part of the process, and rewriting. (See Haskell)

Did you not know about these sorts of tools? Are you unfamiliar with Strongtalk type annotation syntax? Please give an example that would require something as extensive as a rewrite.

EDIT: To clarify, Strongtalk type annotations are completely optional. Take almost any code, remove the type annotations, and it will run exactly the same. They are also always just the Class Name. In Strongtalk as in Smalltalk, evenything is an Object, so all types are simply Class Names. No complex types at all.

Failure of reading comprehension?

Whoa, what are you talking about? Ironically, I think you're the one failing at reading comprehension. Read the thread. Clearly my "static types as a replacement for unit tests" comment was referring to the post I'd responded to initially. It had nothing to do whatsoever with what you said. I was essentially acknowledging your point, but saying that some people seem to advocate static typing for everything. Calm down bro.

Did you not know about these sorts of tools? Are you unfamiliar with Strongtalk type annotation syntax?

Actually, no I didn't, and yes I'm unfamiliar with it ... that's why I asked you for more info.

the rest of what you said

This is all interesting to me. I'm only lightly familiar with Smalltalk and Strongtalk. I was asking for clarification because I really wasn't sure I knew enough about it. Again, no trolling intended ... no need to be defensive.

"Static typing hardly replaces unit tests."

Still, some of the errors you would catch with static typing you can catch with unit tests. It's not a replacement, but probably better than nothing.