You need a well-organized linear pipeline system, this is "The Pure Function Pipeline Data Flow v3.0 with Warehouse / Workshop Model"
Clojure: A Lisp that wants to spread
161–170 of 306 posts
Re: Clojure: A Lisp that wants to spread
#162Earlier quoted context omitted.
I think you are omitting the main reason why Clojure never succeeded: it's dynamically typed at the core. It's on the wrong side of history in that respect. I know it's trying very hard to catch up to statically typed languages now by retrofitting some type system, but it's too little, too late. Static types are where the current state of the art is, and we're not going back. Clojure missed that train and will never…
Static types are the new religion, like OOP was in the 90s. Types solve 2% of programming errors. They lead to coupling for the sake of the compiler, and make code harder to change, harder to write, and often needlessly constrain the utility of the code where they're applied. But they do make the IDE code-completion go, so there's that.
https://news.ycombinator.com/item?id=19131272 . It don't know where your 2% number is coming from, but in Airbnb's experience it was much more. It feel like it would also be more, imo, but I guess it depe nds.
Typescript can be annoying but usually it helps a lot with refactoring. It's also pretty great for detecting unused props with react.
I don't use IDEs so my defense of typescript is only based on its type checking merits
Re: Clojure: A Lisp that wants to spread
#163Earlier quoted context omitted.
Looks like its peak was in 2014[0] and since then it has been declining. https://trends.google.com/trends/explore?date=all&geo=US&q=c...
How is it declining? Every single year we're adding 3-5 new conferences, last year alone - Ukraine, Russia, Brazil, India, Canada. New books being published. There are number of active podcasts (more than for any other FP lang). Latest JVM survey shown - Clojure has become more popular than Scala (largely due to Kotlin), but still surprisingly so. There's a Clojure related post on HN top, almost every week, sometimes…
Maybe it just means that there is a small and vocal community around Clojure - being on HN means that something is interesting for HN community, but it does not translate to wider adoption necessarily.
When Clojure was started it didn't have much competition in JVM languages space. There was Scala only. Right now we have also Kotlin, which seems to be hitting the sweet spot between being a better Java and being difficult to grasp (like Scala or Clojure). In addition Java alone is getting better, so it is harder and harder to eat its cake.
Re: Clojure: A Lisp that wants to spread
#1641. In India, there are only ~100 jobs for a Clojure developer. That includes people just throwing in Clojure just to hire Java/Scala developer.
2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means.
3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning java's ecosystem.
4. Error messages. Even after years of Clojure. I still find it hard.
5. Documentation. Most of the packages I use don't have dedicated websites or good documentation.
Even after all the issues. It's still worth the investment. I started working on a crawler for a freelance gig. we first built it using Golang. But due to its complexity and lots of bugs due to mutation. We ported it to Clojure and we are not looking back.
Re: Clojure: A Lisp that wants to spread
#165My personal perspective (after 8 years clojuring, half of that professionally) is that Clojure keeps progressing, with ever better tools and ideas for getting stuff done, optimally. I remain optimistic. At the same time, it still fails at my "golden test": can I gather 5 random freelance engineers and get them to ship a project within a few months, wasting almost no billable time? I can (and have) with Ruby, Typescri…
> I can (and have) with Ruby, Typescript That's precisely the reason why Clojure attracts seasoned, experienced, grumpy developers. Over and over again, they have been perfecting the art of "building things fast." The problem [with the most] programming languages today, that although they provide frameworks, command-line tools, code generators, etc. to build things quickly, the codebases very quickly become difficult…
I don't disagree with anything you've said, and might be myself one of those grumpy programmers :)
But that isn't at odds with the view that Clojure is more fit in some environments than others, depending on existing knowledge, deadlines, budget etc.
Maybe I'd introduce Clojure in ~6 out of 10 projects. I want that N to be 9.
Re: Clojure: A Lisp that wants to spread
#1661. In India, there are only ~100 jobs for a Clojure developer. That includes people just throwing in Clojure just to hire Java/Scala developer. 2. The learning curve for the Clojure. Clojure is simple but it's not easy by any means. 3. JVM interop if you are not a java developer it adds in more learning time. Most of the Clojure libraries use java heavily. It's a good thing but it adds in an extra layer of learning j…
If you're in Pune or willing to shift, Helpshift uses clojure heavily.
Re: Clojure: A Lisp that wants to spread
#167Earlier quoted context omitted.
What got me started with Clojure was a coworker at megacorp. He's since moved on to a company that makes widespread use of Clojure in production. Startup time was a huge factor for me because I wanted to write command line tools with it. The leaky abstractions were the other painful part – Clojure itself wasn't so bad, but Clojurescript (which would sidestep the startup issue) always seemed to leave me in callback he…
Clojure seems like an odd choice for command line tools. I can see why a committed Clojure programmer would want to reuse their existing skills for a slightly mismatching domain. But Rust/Go (even C) would seem like a more obvious choice if you weren't setting off from Clojure as a starting point.
Clojure's extensive support for lazy evaluation and sequences actually makes it decent for command line tools that process streams of data. At least in terms of program architecture and elegance. The biggest mismatch used to be startup time, but with GraalVM you can get very good startup times.
I made a couple of simple command line programs at my previous workplace and the functional style of Clojure combined with lazy sequences made processing an unknown amount of resources on our server a breeze.
I would think that the language of choice for a command line program would have more to do with the task you need the program for and not the command line format itself.
Obviously for performance critical stuff such as implementing something like ffmpeg you would want to use rust to squeeze out every last bit of performance.
Re: Clojure: A Lisp that wants to spread
#168Earlier quoted context omitted.
That’s an exaggeration. You’re not entirely wrong, though. First, it is not called deps.edn, it is called tools.deps. Second, it is without a doubt, 100% untrue that projects that Cognitect employees work on, exclusively use tools.deps. Cognitect has client projects they start from 0, and existing projects they shepherd and grow responsibly. Their first priority is to help their clients succeed in their goals, not ch…
Most of Cognitect's projects use either Maven or tools.deps, though. I don't think I've see any of them use Leiningen, but perhaps you can show an example? Anyway, I'm mostly concerned by the fragmentation of it all. It doesn't help that there are now three (or four if you include maven) package / build tools for Clojure. The community is barely large enough to support a single one.
For the most part I’m not sure it matters. What specific problems have you had as a result of fragmentation in clojure project build tools? I don’t much care what the name of the command is: if running it produces an artifact I can depend on and use in my app, then it did the job. Different types of build pipelines have different needs.
Re: Clojure: A Lisp that wants to spread
#169Earlier quoted context omitted.
Clojure would not gain widespread adoption even if all your points were fixed. The sad reality is that 99% of developers out there are instantly turned off by the parens and absence of while loops.
Clojure for a Lisp dialect has already gained quite some adoption. I like Lisp, and of course, I would love to see Lisp being used everywhere and used more. But honestly, if someone asked me ten years ago if Clojure would ever become more popular than languages like OCaml, Haskell or Scala, I would've said: "very few people would probably know that such language has ever existed." I'm not trying to bash on other PLs,…
I don't worry about Clojure's future either. I think it'll stay strong for at least another ten years, and it's hard to see beyond that for any language. I use it professionally, and would strongly consider it if I was founding a startup.
But as you say, it's popular "for a Lisp dialect" and I don't expect it to reach past that. I would love to be proven wrong.
That being said, your post made me realize that instead of lamenting the nicheness of Lisps, I should be encouraging other people to give Clojure a shot. And not only to help Clojure be more successful, but also to bring a little bit of joy to their daily life like Clojure often does. (It sounds trite but it's true.)
Re: Clojure: A Lisp that wants to spread
#170Clojure is a FP (Lisp) language based on RMDB theory, which is very suitable for dataflow and data-driven programming, so it is suitable for large-scale industrialized pipeline software development using Warehouse/Workshop Model model. https://github.com/linpengcheng/PurefunctionPipelineDataflow
In the last ~18 months you have been /very/ energetic in promoting your theory here, I have some alerts since about a year and you are always popping up with the same link. Looking into your posting and commenting activity, there not much more.
By now I guess that you have had enough exposure, but most of your comments and links to github have not sparkled a lot of interest or comment, and reception has been skeptical / lukewarm.
Take this as just one datapoint but for me your insistent reposting is more noise than any other thing. If you really care about your theory that is cool and all, but may I suggest that you create something like some practical application examples in blog form, edit them thoroughly, and then post them as new topics, intead of polluting "related" conversations? That way you can better gauge what interests this community, and what not.
By the way interleaving english and chinese such as in your repo README.md makes for an unpleasant read - better to separate both in two distinct documents.
Best luck!