Javascript is weakly typed. And untyped does not mean no type declarations. It means no types, just like it says. Assembly is untyped. Javascript is dynamically typed. Very different. http://en.wikipedia.org/wiki/Programming_language#Typed_vers...

Javascript does not define the implementation details. It does not have to be interpreted, and in fact I don't believe any modern implementation is interpreted. Javascript is generally compiled to byte code which is then run in a VM, or native machine code (V8 at least does this). There is no reason javascript could not have a static type system, there are statically typed scripting languages. It is dynamically typed by deliberate decision, not "we can't do it any other way".

>I accept that I will be downvoted for this.

Why would that happen? Ignorantly bashing haskell strawmen is pretty common here. Btw, while you hit two of the biggest ones, you did forget to complain about it being "academic" and thus unusable for "real world" programming. That should be pretty much standard by now.

>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.

>Welcome to the world of languages with type systems that don't suck

Go is not in that world. It isn't even in the same star system.

Consider the fact that I am probably the only one in this thread who is actually getting paid to write Clojure. And yes Clojure is horrible.

I am honestly curious what you have against Clojure. I dabbed with CL and Clojure, not as much as I would have liked to, but for me they felt similar. I would be curious to have a list of things that can easily be achieved with CL but not with Clojure.

Common Lisp is a multi-paradigm language (imperative, functional, object-oriented) in the Lisp 1 / Maclisp tradition. It has a language spec and multiple different, but very compatible, implementations. Among its goals are portability across different machines/systems, efficiency, power and stability. Thus complex Lisp software can be ported or written in Common Lisp and usually runs on top of several implementations (examples: Maxima, Axiom, ACL2, ACT-R, Common Lisp Music, ...).

"Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs."

SLW? Single-language... weirdo?

Smug Lisp Weenie

He also gets a lot wrong in that talk, so that doesn't seem like a particularly compelling case.

Could you point out some of the issues you noticed in the talk? (Asking from the point of view of someone curious about monads.)

From watching half of it, he mistakes monads for being a trick to avoid Io, which is not true. Io really does happen in Haskell, it is just contained. Also he mentions types not being necessary to understand monads, but immediately launches into a description of the bind and unit functions by, you guessed it, stating what the types of the function's were and what kinds of things they returned (I.e. the exact thing he said he wouldn't talk about on the previous slide).

That being said, I liked his reworking of bind to be a method on an object. I agree monadic computation is tedious to read when you don't have an infix bind operator, and his trick of turning bind into a method solves that pretty well in a language like JavaScript.

I think he's probably overstating the case that what he calls ajax chaining is always monadic (but what most of us who didn't write a competing library would call jquery style method chaining). I would guess most implementations of this kind of APIs do not adhere to the monad laws.

I'm not interested in watching it again, but my impression from the last time is that he's about 3/5ths of the way to "true monad nirvana" if such a thing were a place. There are higher levels above that where we start to really understand the category theoretic and PLT theoretic mechanism of monads, but I think that's truly a different tier.

>If anything it's the old "Goto statement considered harmful" that's a little too naive.

No, people who didn't read it and just repeat the title without knowing what he was talking about may be too naive, but the original point was not.

>You can do that with ctags

And I can do it without ctags. That's the point.

>Depends, one proeminent C project doesn't use that: the linux kernel

That doesn't make his statement "depends" at all. A single project not using that style does not contradict it being "pretty common".

Are you sure you aren't confusing it with K&R style with the argument names on a different line? That would indicate old code. Having the return type on a different line is incredibly common, virtually every C project with decent code uses it.

Odd. I have cookies disabled period, and only enable them for specific domains where I want to log in to something. I still get constant ads on youtube unless I use an ad blocker.