In other words, raw performance isn't that critical?

If it's an exploratory algorithm, more time would give you an edge, but only against reasonably equivalently tuned algorithms.

numpy

numpy tensorflow ml libs -- clj has nothing that matches that at the moment

What I've seen of numpy is so atrocious to read, though :X

@fellshard : yeah, I'm going to try out Hy

@cfleming Hi, I was just watching a short demo of Eclipse CHE and I wonder if you know if there is something similar planned inside Jetbrains for IntelliJ?

@nickbauman Yeah, unfortunately anybody who’s anybody doing deep learning these days is using Python just because of the ecosystem. The fact that Python is the language du jour for AI right now has got to be one of the most frustrating trends in the field, imo. There’s really nothing preventing other languages from stepping up, including Clojure, but so far, it hasn’t happened and the race is on.

About the same as JS being the preferred language of the web, because it's perceived as simple.

I do a fair amount of Python and while I love Clojure, Python has some advantages over Clojure that aren't going away AFAIK.

It's startup time is ridiculously better than the JVM, which is meaningful in really important ways.

It's Numpy library has amazing support for matrix algebra, for which Clojure has decent support (JBLAS wrappers, anyone?) but arguably not better. Finally the iPython / Juniper Notebook phenomenon had no traction in the Clojure community.

As much as I love Clojure, Python does deserve a ton of praise for good reason.

We have work to do to unseat Python any time soon, I think.

total sidenote: it's not the JVM, it's clojure's startup time http://blog.ndk.io/jvm-slow-startup.html

not really, but because we have no choice at the time, it's the only language of the web back then, https://clojurians.slack.com/archives/off-topic/p1484588955002292

I also did work with Python until I became interested in Functional Programming, the very reason why I left Python and started Clojure

what really powers Python are the libraries and the community, rather than unseat Python, I think it will be more wise to stand in its shoulders, just like what Clojure already did with Java, .Net, and now JavaScript

More referring to those who continue to swear by 'vanilla JS' when alternatives are now available 🙂

@geoffs so it's both, then.

sure, in that way where clojure's startup time dominates the JVM's.

For me the biggest pain of JS is the ecosystem. NPM is a dumpster fire. That alone is a reason to not use is in favor of ClojureScript.

There are other reasons not to use it, sure.

yeah, the weekly hype XD

and also that it's just move too fast

The language itself cloaks itself in the appearance of simplicity, but hides dozens upon dozens of minefields of inconsistency and unexpectedness.

Compare to something like Clojure that's steeped in stability, things working as expected, low levels of surprise and high levels of delight.

Partially because Clojure doesn't move fast - it moves carefully, introducing new abstractions, concepts, and tools only as needed to satisfy specific, overarching needs.

It's that greatest problem with OOP - overuse of new abstractions. Every new object that isn't using an existing interface is a new abstraction to learn and wrestle with. Then you get a language like JS that allows you to make arbitrary objects willy-nilly, and all hope of having consistent interfaces is lost.

You're stuck memorizing an ever-increasing envelope of abstraction, struggling to keep up with each new tool and all its subabstractions.

It's a siren song, and when taken too far and in too undisciplined a setting - as I'd argue most JS devs are - you end up with one horrid mess.

we're actually just waiting for the advent of web assembly, then I'd bet the JS camp will just evaporates slowly, and I think JS was initially intended to be a Scheme-like implementation, only that because of 1) deadline [10 days], and 2) business [Java] that it ended up in a mess

I don't thing web assembly is going to do much of anything until they can tie into the existing GCs, and I doubt that will happen soon

*think

@fellshard poking at JS is a very large target. Consider after all these years only recently has dependency declarations entered the language as a first class concept.

🤷

We could go on for hours.

https://medium.com/@wob/the-sad-state-of-web-development-1603a861d29f#.g9ag0mqcb

@tbaldridge give it time 😉 everything takes time, but we are already seeing it, e.g. transpilers, or compilers to js from diff languages

I think those who prefer vanilla js are out of touch or just wants some sort of bragging rights, they're actually losing more than the gaining

Right...but what do you think will happen when every JS file you download has to include its own GC, type system, polymorphic dispatch, etc.

The vastly simpler option is compile-to-js compilers, and better source mapping/tooling support in browsers.

web assembly is great if you want to port unreal 4 to the browser, practically useless otherwise.

yeah, if it's still dom you're targeting, js as the target is still saner and practical

and though my major point is, as it currently seen, more and more people are moving away from JS by means of other languages, the only similarity is that at the end, they're still JavaScript

and yeah, we can keep going on this and JS will still be there XD

LMAO XD

Good job Yahoo, you rewrote your shitty mail client in React. Your customers didn’t give a shit.

damn. that's a super good lesson to myself as a programmer. flashy stack doesn't mean anything. you can spend a lot of time and money keeping up and learning new frameworks but your customers just don't care

Reminds me of a quote from one of Rich's talks on spec, something to the effect of: "Your client doesn't care if your program type-checks or your tests pass".

Good reminder to me that all those things are just means to an end.

I have given up the hype in exchange for the joy Clojure gives me 😛 that probably will be the exception with the customer doesn't care, but I care 😄

something like, I choose the tool that makes me happy, then I make the product that makes the customers happy

... and tada, we're both happy in the end (that would be wonderful if it even takes off)

> that probably will be the exception with the customer doesn't care but I care just remember, Yahoo said the same thing and you didn't seem too impressed ...

hahaha, that's bad, but the customers wasn't even happy with them in the first place, even their own employees (but that's another story)

... oh, a friend noticed that this is Jan. 2016, I thought it was this year XD (too tired to make sense of the date)

Not that it's any less applicable. :)

There's some times where the tools and the customer are intertwined, and we need to be aware of those scenarios. But for the most part, no, it shouldn't matter.

sometimes, I find it difficult to accept that it's all about the product and/or customers and less of the tool used (and the programmer happiness), if that's the case, then people should just use COBOL since it's built for business, but ever since, people want to find tools that will make them feel and do better at their job, because a happy employee is more productive employee (they have a co-relation as far as I see them)

They pretend they don't care until they care.

Usually because they get sold on some tech by a good (read: bad) business salesman

See: "AGILE ACCREDIDATION"

> Good job Yahoo, you rewrote your shitty mail client in React. Your customers didn't give a shit. > sometimes, I find it difficult to accept that it's all about the product and/or customers and less of the tool used (and the programmer happiness)

i'd just say pick one and go with it

celebrate people writing in the tool they like

or accept that user facing stories are the only thing that matter

or perhaps recognize that there is some truth to both

Not mutually exclusive.

The latter should enable you to provide the former.

I agree on that, most of the time, the choice is not really up to us, so we just have to bare with it, happy or not

but if we have the choice (control), we'll most likely choose the tools we want and build the products we think the customers will be happy