Comment by pcwalton | Hacker News Reader

Comment by pcwalton | Hacker News Reader

> lack of module system

ES6 fixes this with, well, a module system.

> weak-typing,

Yup, this is a problem.

> verbose function syntax,

ES6 fixes this with arrow functions.

> late binding

Does this just mean dynamic typing? Well, yes, JavaScript is dynamically typed, but I wouldn't call that a language flaw. Static vs. dynamic typing is a tradeoff.

> which has led to the creation of various static analysis tools to alleviate this language flaw

The footnote talks about JSLint and friends, but none of those impose a type system, which means that they do nothing about dynamic typing.

> but with limited success (there is even a static type checker)

Well, yeah. It's very hard (read: "research problem") to impose a good static typechecker on a dynamically typed system, though.

> finicky equality/automatic conversion

Yeah, this is bad. I really wish tools like restrict mode [1] had caught on: together with ES6 they eliminate a lot of what people dislike about JavaScript.

> this behaviour,

Fixed in ES6 if you use arrow functions (finally!)

> and lack of static types.

Again, I wouldn't say it "sucks" for this reason, just that it's dynamically typed. That's a tradeoff.

[1]: http://restrictmode.org/

> Again, I wouldn't say it "sucks" for this reason, just that it's dynamically typed. That's a tradeoff.

This is the Haskell wiki. I would expect most participants to view having a single global implicit union type to be a flaw, not a trade-off.

It's sad that we should expect Haskell users to be chauvinistic about static typing. I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw".

>It's sad that we should expect Haskell users to be chauvinistic about static typing.

We don't expect that. We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way.

>I have yet to read anyone who advocates for dynamic typing describe static typing as a "flaw".

Try looking on the internet. Every "static vs dynamic" argument has 99% of the dynamic side arguing that static typing is bad because java's type system limits them and doesn't prevent any bugs.

> We expect them to recognize that better type systems are better than worse type systems. Which seems pretty obvious when stated that way.

Obvious - because you just said "with better defined as has more static typing, static typing is better". That's an empty statement if I ever saw one.

That it's better to accurately and reliably modeling complex systems and invariants through provable assertions is objectively is no more an empty statement than to say that it's better to apply informed materials and structural engineering to the design of complex physical products than to build ad-hoc designs of unknown parameters through guesswork.

If you think that building software is like building bridges, then yes. If you think that it's the exploration of a problem domain that may not be known to you at the start of the process and is subject to various degrees of iteration (e.g. a process more like writing a script/play), then you get vastly different requirements. That's what I meant by "if you define better as more static typing". "Better" is a normative statement and can never be absolute, it's always relative to a choice.

I don't see how it follows that iteration reduces the degree to which one must understand a system. That's just a rephrasing of the attractive but ultimately empty "dynamic typing is just more creative."

Bridges (or car engines, or any other engineered product) aren't invented whole cloth sans iteration. However, it's understanding of the invariants of the iterated system that allow for directed iterative design and ultimately better products.

Rather than repeat this argument, I'll refer to https://news.ycombinator.com/item?id=7656184

You just proved djur's point.

What's wrong with being passionate about something you believe in?

It seems to me that this "chauvinism" is in the eye of the beholder, offended that others are suggesting that the tools they have invested time in may not be the best way to do things.

Personally, I am quite excited by the prospect of learning and investigating better tools. I think we're only just beginning down the road to finding better ways of programming.

There's nothing chauvinistic about it. If you want to hear people honestly and accurately describe "static" type system's flaws -- talk to type system theorists.

Type systems can be provably flawed.

What you can prove about a uni-typed late-bound ("dynamic") languages is quite simply that they're unilaterally flawed.

The chauvinism involved is the assumption that a type theory is the only legitimate way to assess the quality of a programming language's type system. Haskell is, of course, a near-ideal language when judged by the values of its creators and advocates. The inability to recognize that those values are subjective is chauvinism.

It's chauvinistic to believe that the only way to assess math is through deductive reasoning?

By that measure, all "STEM" fields are inherently "chauvinistic".

Programming isn't math.

That's really, really funny.

Engineering isn't math either, but you can't do it right without math.

I know some people really want programming to just be an application of the lambda calculus. It's a model that really appeals to people who prefer a top-down, deductive model to their work. It's similar to the appeal that draws people to Austrian economics.

And yet that is not the original model for thinking about software, nor the only valid one. Haskellers who rely solely on deductive arguments in favor of their method are going to be stuck forever wondering why so few people are using their clearly superior tool.

Less accurate "models" for "thinking about software" are less accurate, and whether they were thought of first or last has no bearing on that. The fact that you're using "earliest date of discovery" as supporting evidence demonstrates that you're not approaching the question as an objective observer.

This isn't a popularity contest, though if you were measuring popularity based on positive impact, that of Haskell has been substantial.

The only advantage to leveraging simpler and less accurate models is that they're easier for the people using them to understand at a micro scale -- at the cost of systemic accuracy and verifiability.

In being less accurate, they create systems that are more difficult to understand, more difficult to abstract and compose, more difficult to optimize, and more difficult to measure.

There's something destructive and anti-intellectual about trying to convince the world that deductive reasoning is just a matter of opinion.

> The fact that you're using "earliest date of discovery" as supporting evidence

It was a fun discussion while it lasted, but conjuring words out of thin air and putting them in my mouth is where it ends. Thanks.

"And yet that is not the original model for thinking about software ..."

Best languages allow both type systems with dynamic being opt-in.

Reply on news.ycombinator.com