181–187 of 187 posts
Earlier quoted context omitted.
I couldn't find example in the docs for that library showing concurrent async ops with simple try/catch type error handling. So it's still not clear to me how you would rewrite the above shown async/await concurrent scenario using this library.
So what you're saying is that you can't be arsed to spend 15 minutes to learn a library, but you're ok gobbling up all of ES6/7 without problems?
I was thinking to put React.js in my adopt circle, but I spent a couple of days setting up the Node.js gulp-vinyl-browserify-babelify nonsense, and it really is a witch's brew of configuration hocus pocus. Its compelling to know that React is backed by Facebook, but React is simply verbose and comes with too much stuff packed into one package. Whats the alternative? Thanks to hacker news i bookmarked vuejs.org and fi…
What does all that stuff have to do with React? Isn't it just a bunch of general purpose JavaScript tools that you decided that you needed to use?
Earlier quoted context omitted.
You're just cherry picking though. When it comes to complexity there's plenty more of it in Js than there's ever likely to be in ClojureScript.
I am biased. Just as you are.
Earlier quoted context omitted.
>I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage I'm not sure what that's supposed to mean exactly. I don't really understand what the "resorting" part refers to here. Clojure is a modern language with that has excellent syntax with tangible advantages over syntax found in most languages. The syntax is…
You are vested in Clojure/Script and biased toward it. Obviously you are biased due to the heavy investment you hve made. I see so many disadvantages in ClojureScript: Lisp is super small in terms of adoption. Lisp is like using an RPN calculator, for uber nerds not for everyone. Who will maintain my code? The few people I know who know ClojureScript? How hard is it to find a ClojureScript dev or anyone interested in…
Sure, but that's not very interesting in and of itself. The question is whether there's enough of a community to make the language viable and whether you can get a job using it.
Thousands of people are happily working with ClojureScript today, and lots of companies make accommodations such as remote work.
>Who will maintain my code? The few people I know who know ClojureScript?
I've always found this argument very strange myself. My experience is that the language is usually a small aspect of what's involved in maintaining a project. You have to learn tools, libraries, and the architecture around the project. This tends to vary greatly place to place. Learning the language is just a small aspect of that and anybody who's not capable of learning a new language probably won't do a good job with the rest either.
So to answer the question, the person you work with and train to use the language usually. As I've already pointed out, I've trained lots of people to work with Clojure and it doesn't take long for people to become productive.
>How hard is it to find a ClojureScript dev or anyone interested in working on it?
Not very, lots of people apply specifically because they want to try a new language. Last guy we hired had prior experience working with PHP and C#, and never touched a functional language in his life. His reason for applying was precisely that he wanted to try working with Clojure. He finished his first project and put it in production in his first 6 months on the job with minimal supervision.
>Can my company hire hundreds of engineers who love it and are easy to replace if they leave.
The fact of the matter is that good engineers aren't easy to replace when they leave. This has nothing to do with their choice of language.
> Clojurescript's biggest problem, however, is that it has people like yourself who want to shove Lisp Is The Truth down everyone else' throat which people like myself have no tolerance for :)
I'm not shoving any truth down your throat, at no point did I suggest that you should switch back to ClojureScript from Js. In fact, I've repeatedly stated that you should use Js if you like it.
I'm just pointing out the fallacies that you're stating when you're fumbling to justify the reason you switched back. Something nobody asked you to do by the way.
You started out complaining that core.async is hard to use. When I pointed out that there's a promises library you pivoted to complaining that libraries are hard to find, even though it's the first result for "promises clojurescript" on Google. When I asked you what specifically was hard to do, you said that it's just "an argument plot", and now you've moved on to some vague notions regarding difficulty of hiring developers to work with ClojureScript.
Why don't you just say that the actual reason that you like Js better is that you're more comfortable using it. That's a perfectly fine answer.
Earlier quoted context omitted.
It's a trivial matter to wrap promise/all in a core.async channel, providing the exact orginzation pattern you're looking for.
Show me the code! Go ahead and let's see how pretty that is, and son't forgeg error handling and concurrency.
Earlier quoted context omitted.
When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So I eschewed all the Flux stuff and just used a single nested record of app state updated with the simple built-in immutability helper. We put everything in just two or three files so we didn't need any complex build tooling. We did routing by just listening to…
Exactly. The problem is when people ask themselves "What do I need?" and then go "I don't know ... hmmm ... I better get everything then ..."
A lot of dev, like me in the college, have the tendency to get everything right before starting writing first line of code when learning something new, in hope that orthodox practice will help avoiding pitfalls on the way.
But what I really learned along those years, is that pitfalls are inevitable, and expose yourself to them at the early phase of learning is helpful so that you could later appreciate other people's solution and the reasoning behind. Trying to get everything right from beginning hinder you from getting such first-hand and organic insight, and wondering with tools too much will stray yourself from focusing on the essentials.