pka

But, as you surely know, types prove something about a piece of code. This means they can very well prove the absence of (certain) bugs.

So generally, the more invariants you manage to capture in your types, the more categories of bugs you can statically prove will never happen.

Leaving Haskell's deferred type errors aside for a moment; after you are done with your partially working code, what then? Relying on (the surely preexisting) 100% test coverage?

Well, he said "strong" :) Probably meaning a ML-derived type system, not C's or Java's.

Purescript doesn't have a runtime, unlike Elm, so in that sense it may be a thinner layer. However, the language itself is more advanced than Elm, allowing for more powerful abstractions but also having the side effect (haha) of having the same steep learning curve as Haskell.

Also, Purescript's FFI is really easy to use (unlike Elm's), afaik this was one of its original design goals.

Finally! Been wishing for something like this for a while, good job!

Sure. In Haskell for example you can turn type errors into warnings with a compiler flag. If you then encounter a type error at runtime the program will crash, much like in a dynamic language. And if it turns out the change was a dead end, just git checkout master and you're done.

However, if not, you'll still have a list of compiler errors you have to fix to make the rest of the program work. This alone lets me refactor with confidence, much more so than every dynamic language I've ever used.

This will sound counterintuitive to dynamic language people, but prototyping is actually much easier with types. I often find myself rewriting 50 to 75% of the codebase in the early stages of prototyping, and without types I'd be much less willing to do that, settling for a less than ideal design. This design will then be the base of a potentially large project, which amplifies early mistakes even more.

In the time it took you to write your content-free comment, you could've googled Elm and seen the error messages yourself.

Sure, sucks. But anyway, would you like to live in a place where the majority of people don't like you? It's going to be a fact with our without referendums or laws.

I'm also of the conviction that everybody should do whatever they want if they don't hurt/bother anybody else. However, a consequence of this is that people will have to waive certain freedoms if the majority is bothered by them, like building whatever they'd like on their private property.

Sure, let's say not being allowed to build minarets because people don't like that is bullshit.

But let's also imagine I buy some land in front of the kindergarden your children go to and build a giant wall showing hardcore porn movies all day. Now probably you and the majority of people living there wouldn't like me to do that, but it's my damn right so gtfo.

It's a slippery slope both ways (minarets, gay people can't kiss in public, porn walls) and I have no idea how to draw the line between what the majority wants and the invasion of personal freedom. More importantly, neither the majority nor any elected officials should be allowed to draw that line (almost by definition), so it seems it's a catch 22 situation.

It's interesting to observe how almost all mainstream dynamic languages move from "who needs types? types are very very bad and just get in the way!" to some sort of gradual typing or runtime type validation.

* Javascript has Flow/TypeScript

* Python has PEP 484

* Perl6 has some sort of types

* Clojure/Script has core.typed, schema and now clojure.spec

* Don't know about Ruby, but I've seen articles on type checking/annotations

* Erland has Dialyzer (although this is not a recent development)

You are wrong. You can very much catch "key errors" at compile time.

To explain in simpler terms, what you do is promote values to types first. I.e. when a user enters a string, you have to somehow prove, using formal logic, that n < l. After that, the proof is encoded in the types and you can use functions as ngram above that depend on this proof.

And now have those 10k programmers work on a single project.

I bet the 10000 Ruby guys are gonna create a big, unmaintainable, broken mess. Even Java's primitive type system would be a big help when it's about software development at scale.

Yes yes, TDD :)

If you are building a bridge or a skyscraper, yes, you absolutely do. If you are building a house for your dog, then no.

I remember reading an "interactive" book as a kid (a book with numbered short episodes, and at the end of each one you are presented with a couple of choices how the story would continue, it was awesome) where the good guy was sent back in time by the bad guy to the wild west where he had to convince the indians to trust him and fight with him against the same bad guy, who liked to slaughter them for fun, or die with them. In order to understand the natives, he had some gadget implanted in his brain that translated their language directly into his own. I remember thinking "yeah right, never gonna happen." :)

This is probably far away from being able to translate languages perfectly, but still. The future came pretty fast.

I gave you my mail in the other reply, HN is really annoying for longer discusssions.

Drop me a mail, p<dot>kamenarsky, gmail.com.

@sklogic (can't reply directly): I know how to use macros, I've used them and I have come to the conclusion that there are much better tools.

Seeing you know what a logical phallacy is, here is one more for you: "if you don't like macros you don't know how to use them". Can you guess the name?

My question was not ad hominem. I wanted to see whether you have actually used the thing you are arguing against or instead just blindly praising something as the ultimate solution and thereby determine whether I should continue this discussion with you.

Before we continue, post a link to a free monad DSL you have written; I do not intend to waste my time in a discussion with a zealot.

(I can send you examples of macros I've had to write, if you desire.)

Free monads would like to have a word with you about simple, modular, debuggable, composable DSLs. On the other hand macros are anything but composable or modular. Debuggable for some far off definition of debuggable, maybe.

Yea, understanding macros and writing your own DSLs doesn't make you some sort of aryan ubermensch programming craftsman. Macros really aren't that hard to get, and mostly not necessary when you have more coherent constructs at your disposal.

I have to disagree.

    f x . g

reads just so much easier than

    (comp (partial f x) g)

Important, sure, for our deeper understanding of the universe. They wouldn't, however, have a detectable effect on the world around us.

No?

Probably paredit. It's really so much better than non-structured editing. That said, there are structured editing plugins/modes/editors for other languages too.

However, looking back at Lisp/Clojure now I really don't like the syntax anymore. I don't care about the brackets, it's absolutely true that you learn to look past them in a matter of days, but the homogeneity and the "denselesness" really impact my ability to quickly parse an expression. Infix syntaxes make reading code much easier, imo.

This seems to be a lost cause, but I'll try one last time.

The point is that even if there were some yet undiscovered particles or forces, they wouldn't have any effect whatsoever on the world around us. This we can say with certainty. Even if it turns out that our current understanding of QM or GR are just approximations of the real laws of physics, again, this won't matter, much as GR doesn't matter at the speed of a moving car and thus you wouldn't take time dilation into account when you calculate the time you need to get from point A to point B.

You are missing the point. The author acknowledges that there may be particles that we haven't yet discovered, but even if there were, we can prove that they wouldn't impact everyday live. In other words, "we know what we don't know".

So you would never steal, no matter the situation?

Trying to force your morals on other people (by claiming they are absolute) makes the world a worse place.