Live data from Hacker News

Static Typing is not enough

blog.fogus.me

31–40 of 65 posts

Re: Static Typing is not enough

#31
post #4

Sometimes, I wish I could downvote stories... Accidentially, almost everything that the author suggests, except luck and user testing, can be provided by static type systems - e.g. Haskell's type system is Turing-complete, so you can make up any kind of contracts/tests and embed them into the type system...

    Haskell's type system is Turing-complete
So? What does that buy you in the face of attempting to prove that your system can run with two simultaneous users? How does the type system prove that it can withstand a DoS attack? Likewise, how can it prove that your system properly handles the case where the user types some garbage into a textbox? How does it help prove that your system keeps running if someone pulls the network cable out of the wall? How does it help prove that you wrote the system that your client wanted?

Re: Static Typing is not enough

#32
post #28

Earlier quoted context omitted.

Ah, f k man, another REPL? I don't want a repl for editing. I want to write code in a friggen editor and have dot completion work. I also want a repl for trying stuff out and debugging/light weight testing, but that's a different use case for me.

https://github.com/pry/pry/wiki/Editor-integration

But that doesn't give you autocomplete within the editor, it seems like it just opens up the editor and evals the file after exiting the editor.

Re: Static Typing is not enough

#33
post #31
post #4

Sometimes, I wish I could downvote stories... Accidentially, almost everything that the author suggests, except luck and user testing, can be provided by static type systems - e.g. Haskell's type system is Turing-complete, so you can make up any kind of contracts/tests and embed them into the type system...

Haskell's type system is Turing-complete So? What does that buy you in the face of attempting to prove that your system can run with two simultaneous users? How does the type system prove that it can withstand a DoS attack? Likewise, how can it prove that your system properly handles the case where the user types some garbage into a textbox? How does it help prove that your system keeps running if someone pulls the n…

True, and unit tests don't help with those concerns either. I'm confused by the original post and these comments. What are you trying to convey? Can you state your point directly? I am not understanding.

Re: Static Typing is not enough

#34
post #32
post #28

Earlier quoted context omitted.

https://github.com/pry/pry/wiki/Editor-integration

But that doesn't give you autocomplete within the editor, it seems like it just opens up the editor and evals the file after exiting the editor.

Technically true, but I write most of my code in the REPL, then use edit-method to get it into my editor.

Fom the link: NOTE: If you're using Ruby 1.9, you can use edit-method on methods defined from the Pry console. As these methods have no associated file, this implies the -p switch. This functionality doesn't yet work for Ruby 1.8.

Re: Static Typing is not enough

#35
post #18

Earlier quoted context omitted.

Pry for ruby gives me great dot completion and isn't batshit insane. Most diehard dynamic typists live in their repl. When I use java with IntelliJ I miss my repl. I do gain some things from the IDE, but I feel hamstrung compared to my repl.

I'll give pry a try, but I've tried a lot of dynamic IDE environments and none have come close to IJ w/ statically typed langs.

Minus the part about t only working well for java and having to write your code in java ;)

I also use rubymine for ruby development and it gives me a lot of the IntelliJ stuff, but it doesn't always work. I.e cmd-b to jump to the method definition.

Re: Static Typing is not enough

#36
Doesn't anyone view static typing as done in a language like Haskell as a form of documentation? I am not saying ALL Haskell code can be deciphered by its types - hell no. But a useful technique is to express the semantics of the program into the type system (as much as possible anyways) to communicate intent. This is a huge benefit over dynamic languages imho. So there is more too it than just verification, even if that is extremely nice.

Re: Static Typing is not enough

#38
post #9

Earlier quoted context omitted.

With appropriate compiler flags, you can make up any sort of contracts you like in Haskell. But there's no guarantee that the compilation process will terminate if you do, even putting aside the impenetrability of the resulting code. Haskell is not a general purpose proof assistant, and the typing definitely has limits both practical and theoretical. Abstractly, static types can represent anything, however we (by whi…

Why do people worry about compilers hanging or giving up? If I know how to kill the failed compile and fix my program so that it is provably type-safe before shipping, I don't really care how many undecidable programs could also exist because I no longer have to ship one of those.

While we're at it, what would be really cool is if we could design a program to automatically look at the Haskell program, decide if it's undecidable, and fix it.

Re: Static Typing is not enough

#39
post #3

Earlier quoted context omitted.

(any of the other stuff mentioned) .. ensure correctness The post says that. Dot-completion in your IDE is not enough either, nor is it something particularly unique to static languages.

Reliable dot completion without some batshit insane state-dependent VM-as-a-dev-env-or-constantly-running-tests system is... well, let's just say made much easier with static typing. I really could give a shit about what people think is "enough" (IMO, keeping stuff simple, as in simplicity of implementation, as in worse-is-better, is the only answer) I just want to hit dot and have a pretty good idea what I'm allowed…

Reliable dot-completion for dynamic languages exists, right now, and is not batshit insane or dependent on VMs or any such thing.
Post reply on HN