[weberc2]

Thanks for the response! +1! Let me take a stab at these points, bearing in mind that I'm not a JS fan or a Clojure opponent; just playing devil's advocate for my own learning purposes:

1. I accept that there are only lists and maps and primitives in Clojure, but I think the same is true of JS. The problem is that functions depend on these map/list structures having a particular schema, so in essence you can't just pass any old list or map to a function and have it do the right thing. I guess I don't see how Clojure and JS differ here.

2. What's stopping you from programming JS in a functional style? It's very possible to avoid `for` in JS (not sure what Clojure uses instead of `if` though). The JS standard library offers many functional features, and there are libraries dedicated to exactly this. I don't see how JS differs from Clojure here, except that it also supports an imperative style and "less is more".

3. If you're disciplined, you can do the same in JS or Python, but I accept that having rails in a language is better than resorting to discipline. The problems I mentioned with scaling JS and Python were related to typing (see point 1), not mutating state. I'm not sure what you mean by mutability introducing scaling problems, but Go is a mutable-by-default language which scales very nicely, both in terms of project size and parallelism (while I accept that immutability makes for easier parallelism, JS and Python's lack of parallelism have nothing to do with mutability except in the runtime). Clojure supports parallelism, which JS does not, so +1 for Clojure here.

4. I hear this a lot from Clojure proponents. The only REPL I've used is Python's, and I'm not a fan, but I understand that the Clojure REPL is a different beast entirely. I'll have to take you at your word here. Clojure beats JS here.

5. JS doesn't actually compile, so you can do all the metaprogramming you like. I also understand that JS has generators and coroutines, which should make async JS suck less; however, I haven't used them yet.

It seems like the biggest advantages Clojure has over JS are:

A) REPL B) Parallelism C) Rails + conventions > discipline

Thoughts?

[hacker_9]

True Javascript has maps, and you could use immutable.js for your structures. It also has functional capabilities too thesedays. But the difficult part of language design is actually making all these pieces work together fluidly. This is what Clojure achieves.

Immutable.js is great until I need to use a 3rd party lib that doesn't support the structures, so there is a copy involved and performance is lost and the code gets ugly. Functional constructs were botched into JS, so most code out there is a litter of imperative and functional, as well as containing lots of mutable global state. It's object orientated, losing much of the benefits that come from being functional first.

> I'm not sure what you mean by mutability introducing scaling problems

Side-effect free programming makes reasoning about your code easier. More here: https://stackoverflow.com/questions/214714/mutable-vs-immuta...

> The only REPL I've used is Python's

I've not used it, but the point is you can change code and upload it as the programs runs. Great for tweaking stuff. And because there's no global mutable state, you don't have to restart the REPL very often as everything just works.

> JS doesn't actually compile

Actually it is compiled on page load. Also JS has no macros, but it does have some metaprogramming capabilities at runtime (reflection mainly). Again though, having a feature doesn't make it any good. Clojure's consistent and easy API blows JS out of the water.

[weberc2]

> Immutable.js is great until I need to use a 3rd party lib that doesn't support the structures, so there is a copy involved and performance is lost and the code gets ugly.

Don't use a library for immutability, just don't mutate. Easy-peasy.

> Functional constructs were botched into JS, so most code out there is a litter of imperative and functional, as well as containing lots of mutable global state. It's object orientated, losing much of the benefits that come from being functional first.

Yeah, multi-paradigm code is a pain.

> Actually it is compiled on page load. Also JS has no macros

If we're being pedantic, it compiles continually during interpretation as most popular implementations use JIT compilation. But my point is that macros wouldn't benefit such a language because there is no discrete compile phase.

> it does have some metaprogramming capabilities at runtime (reflection mainly)

I guess I'm not very familiar with metaprogramming. Most anything I can do with macros in a compiled language I could do at runtime in a dynamic language without special standard library or language support. I'll take you on your word that metaprogramming is useful and that Clojure does it better.

Anyway, I don't think you answered one of my questions--how is Clojure's IDE support? Can it do gotodef or tell you about the types of parameters, etc?

[hacker_9]

The problem is JS is built from the ground up to be mutable. For example one big difference in Clojure is that all mutation is done through the Atom, which is transactional, making it threadsafe.

I wasn't being pedantic saying JS is compiled, because it really is. Sure it's compiled to an IR though, which is then JIT compiled as needed.

Nice thing about macros is they are zero cost abstractions, so there is no overhead added by using them. For example in C# using Linq creates garbage, so you can't use it in a game engine else you get freezes every couple of seconds as the GC does a collection. With macros you can have the convenience while still compiling to something that is memory efficient.

As for an IDE, look at the Cursive plugin for IntelliJ. It's free for personal use and gives you a debugger, autocomplete, errors, goto definition, find usages etc.

[weberc2]

The following responses are terse because I'm posting from my phone. Apologies in advance!

JS is not parallelized, so whether or not it's thread safe is a moot point.

Python is also compiled to a bytecode before interpretation; were still don't call it a compiled language.

In a JIT language, macros aren't significantly faster than runtime abstractions. In the latter case, you can always precompile your abstraction on program load at the expense of slower start times (think regex engines or precompile linq queries). The cost is negligible.

I can't seem to find anything on type documentation for Cursive. How can I ask it what type a function returns or what types it's arguments should take?

[hacker_9]

> JS is not parallelized

https://johnresig.com/blog/web-workers/

https://ponyfoo.com/articles/understanding-javascript-async-...

> Python is also compiled to a bytecode before interpretation; were still don't call it a compiled language.

https://softwareengineering.stackexchange.com/questions/2455...

> macros aren't significantly faster

> you can always precompile your abstraction on program load at the expense of slower start times

http://www.ilikebigbits.com/blog/2015/12/6/the-fastest-code-...

> How can I ask it what type a function returns or what types it's arguments should take?

http://www.braveclojure.com/core-functions-in-depth/

[weberc2]

> https://johnresig.com/blog/web-workers/

Sorry, I should have said "JS doesn't support shared memory parallelism for all intents and purposes, so memory sharing concerns are a moot point".

> https://softwareengineering.stackexchange.com/questions/2455....

This supports my point; not sure why you're posting this...

> http://www.ilikebigbits.com/blog/2015/12/6/the-fastest-code-....

This is also congruent with my points; if this is meant to be contradiction, you'll have to clarify.

> http://www.ilikebigbits.com/blog/2015/12/6/the-fastest-code-....

I'm not spending any more of my time skimming these mysterious links; this is a very straightforward question and you've evaded it several times and then referred me to an 8 kiloword document. What gives?