71–80 of 122 posts
What I'd really like to see is a full stack clojurescript framework like next.js or meteor. I think fulcro comes close but it uses JVM clojure on the server side, so it's not entirely possible to re-use code on either end.
Clojurescript on Node could be a good contender, but last time I tried it, the development experience was very poor and the power of Clojure doesn’t really shine in serverless functions, so I just use Python for that which is a perfectly adequate scripting language.
Earlier quoted context omitted.
Clojure has the same number of parens as Javascript, C/C++, Java, and similar languages have parens+squiggle-brackets. (print "foo") vs print("foo"). same same. There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know…
>(print "foo") vs print("foo"). same same. If you look at things other than function calls, it starts to look different: let x = 5, y = 10 foo(x,y) vs (let [x 5 y 10] (foo x y)) I actually like Lisps and think the S expression syntax is one of their best features, but I'm not going to pretend there are the same number of brackets in Lisps as there are in C family languages.
In your lower example, Clojure has only one more non alphanumeric character than the other example.
Furthermore, in Lisp, you always know that you have (function-name param param etc). Reading it becomes not just easier - it removes an entire layer of abstraction (syntax rules). Also, with smart editors, you gain the ability to move these around rapidly in ways that you simply cannot do with other languages.
Funny thing is, the biggest annoyance I have when not using Clojure is having to type commas between items in data structure. [1 2 3 4 5] just looks so much cleaner than [1, 2, 3, 4, 5]. I forget who wrote it, but they complained of seeing all the mouse turds "," in normal programming languages.
If anyone is interested, there is an up and coming Clojure web framework called Coast, https://coastonclojure.com/ For those that aren’t as familiar with Clojure - there isn’t a rails or Django for web apps, so Coast is trying to fill that void.
I've used Luminus to fill that space, and I gotta say I don't think that's the best way to go for Clojure. Getting started with Luminus was fine, but it was often very confusing and I didn't understand a lot, whereas when I added things as I needed them and checked out a couple libraries, I had a lot easier time debugging what was wrong. What's going to make Coast different?
Earlier quoted context omitted.
I have not investigated Coast yet. I know it aims to be a Rails for Clojure... maybe it is, and maybe it would meet my needs. But given the incredible power and expressiveness of Clojure, I find no reason to believe that the best rapid web development framework could be developed in Clojure if the right motivated people attempted to do so. I don't know how many people (Plataformatec?) were behind Phoenix, but even in…
I'm not denying that something better than Rails can be built with Clojure, just implying that it doesn't exist, so for quickly pushing out a CRUD webapp multiple times without repeating yourself again and again(avoiding all the trivial/tedious stuff), there is Rails.
We use pedestal+fulcro3+pathom om.next was before that, but it seems to be almost abandoned, also fulcro author have solved a lot of depressing pain points of om.next. Those three work like a perfect Lego.
What made you choose pedestal over compojure/compojure-api or other alternatives? Similarly, why fulcro3 over something like reagent/re-frame. I have used the latter choices and am considering switching for the my next project.
Pedestal, on the other hand, is offering compact single data structure with linear complexity increase, plus very neat async functionality out of the box.
As for fulcro3, I have chosen it first because it was kind of successor of om.next, and in om.next I was in love with its transactional data model and all that pull syntax, - fulcro3 turned out to be even better with that.
I was and am still using reagent for simpler setups, but query language and transactions is what helps to keep sanity with larger projects.
Earlier quoted context omitted.
>(print "foo") vs print("foo"). same same. If you look at things other than function calls, it starts to look different: let x = 5, y = 10 foo(x,y) vs (let [x 5 y 10] (foo x y)) I actually like Lisps and think the S expression syntax is one of their best features, but I'm not going to pretend there are the same number of brackets in Lisps as there are in C family languages.
I can't reply to your lower example because it's too deep, but I would point out that clojure does not have the other symbols - equal and comma. In your lower example, Clojure has only one more non alphanumeric character than the other example. Furthermore, in Lisp, you always know that you have (function-name param param etc). Reading it becomes not just easier - it removes an entire layer of abstraction (syntax rul…
Earlier quoted context omitted.
Clojure has the same number of parens as Javascript, C/C++, Java, and similar languages have parens+squiggle-brackets. (print "foo") vs print("foo"). same same. There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know…
>(print "foo") vs print("foo"). same same. If you look at things other than function calls, it starts to look different: let x = 5, y = 10 foo(x,y) vs (let [x 5 y 10] (foo x y)) I actually like Lisps and think the S expression syntax is one of their best features, but I'm not going to pretend there are the same number of brackets in Lisps as there are in C family languages.
(let [x 5
y 10]
(foo x y))
(foo x y) ;; now different x and y!
{
foo *ptr = ...; // scope this just to this block.
}
The braces will be there if you program sanely and care about scope.
Earlier quoted context omitted.
Python has too few parentheses, Clojure has to many. There’s just no winning. Ultimately, these complaints are superficial and serve only to justify one’s laziness.
Clojure has the same number of parens as Javascript, C/C++, Java, and similar languages have parens+squiggle-brackets. (print "foo") vs print("foo"). same same. There's so much more to it than this. I can say without reservation that people who do not take a couple/few weeks to learn a Lisp just do not know what they are missing, and their arguments against it are viewed as children who lack enough experience to know…
Some of my favorite Clojure libraries in this space: - instaparse: takes EBNF (and other formats) as a string and gives you a parser instantly (!!!) https://github.com/Engelberg/instaparse - re-frame: React-Redux alternative that IMO is much easier to work with https://github.com/day8/re-frame - reagent: React wrapper https://reagent-project.github.io/ - ring https://github.com/ring-clojure/ring - fulcro https://gith…