[HN Gopher] The Clojure Mindshare (2019)
___________________________________________________________________
The Clojure Mindshare (2019)
Author : tosh
Score : 53 points
Date : 2021-12-31 13:30 UTC (9 hours ago)
(HTM) web link (www.groundedsage.dev)
(TXT) w3m dump (www.groundedsage.dev)
| mitchbob wrote:
| Direct URL to the post: https://www.groundedsage.dev/posts/the-
| clojure-mindshare/
| dang wrote:
| Fixed above now. The page had https://www.groundedsage.dev/ as
| the canonical URL, so our software had switched to it.
| rcgorton wrote:
| christophilus wrote:
| I love Clojure, but I do miss static types. I'm hoping Carp[0]
| (mentioned in the article) comes into its own. It seems like it
| could become my ideal language. The other problem I have with
| lisps in general is that they seem to encourage clever
| programming that is hard to read / debug (or maybe they just
| attract developers who value brevity over clarity... not sure).
|
| [0] https://github.com/carp-lang/Carp
| cjohnson318 wrote:
| I don't get the "fewer libraries/modules is a good thing". I
| _like_ using libraries where some has already encountered and
| created work-arounds for all of the edge cases for a really
| domain specific problem I 'm not very familiar with so that I can
| focus on business logic. Am I missing something? What's fast
| about blindly discovering a bunch of stumbling blocks that you
| never imagined existed?
|
| All that said, I'm a fan of lisps, I've just never used one in
| production.
| didibus wrote:
| There are two types of libraries, the ones that deliver domain
| specific needs, like a web server, an encryption library, a
| midi library, a GUI library, a diagraming library, a pdf
| library, a zip library, a logging library, a database connector
| library, etc.
|
| In Clojure, those all exist, generally by simply reusing the
| ones that Java or Javascript already invested time and effort
| into building, though sometimes it has its own as well.
|
| The other type of library are generally conveniences, they
| either simplify existing APIs, add programming constructs, or
| template/establish a pattern for doing something. These are the
| ones you tend to not need as much in Clojure, because the
| language is already so expressive and succinct, and it is
| pretty trivial to implement your own custom conveniences
| directly focused to your application needs and your personal
| preferences.
| Orou wrote:
| I agree libraries are great when dealing with very specific
| domain problems (who wants to hand-roll a datetime module?).
| But there are also a ton of libraries that aren't for such
| specific domains or which attempt to bridge multiple domains
| (i.e. frameworks).
|
| The argument made by functional languages like Clojure is that
| by making heavy use of pure function composition, you don't
| actually need a million libraries to build large/complex
| systems. You can do it with a much smaller number of libraries
| where necessary and take advantage of the language's natural
| extensibility for the rest.
| filoeleven wrote:
| Perhaps it could have been stated better as "the language
| design removes the need for a multitude of competing
| libraries."
|
| The statement should not be taken out of context from the rest
| of the paragraph, which includes, "These libraries are also
| generally very high quality..." This means that the two or
| three libraries you find are more likely to handle all of those
| edge cases you mentioned. Some libraries haven't been updated
| in years because they've solved the problem they set out to
| solve, and nobody's found a fault with them since then.
| ducharmdev wrote:
| > We are in an industry that is so new, so fast-moving and so
| financially rewarding that people tend to gravitate towards
| popular programming languages. These people are quick to migrate
| to a new technology, they often skip fundamentals or simply have
| no interest in gaining fundamental knowledge.
|
| One might say that this simply signals the success of these
| languages in attracting newer programmers. Senior developers
| should have this fundamental knowledge regardless of language.
|
| I've read numerous impassioned calls to use a given language like
| this over time. Clojure, Haskell, every flavor of Lisp there is.
| More times than not, it leads me to a few weeks of buying into
| the hype, believing it's going to be the most transformational
| experience I've had as a developer.
|
| Lines like this seduce you so easily; who wouldn't want to be
| able to express their ideas with so little friction?
|
| > _ is the most expressive and flexible language. You can reach a
| flow-state where ideas can freely flow from your mind into code
|
| And these languages can be a good way to learn new ideas and
| paradigms, sure. But for me, a lot of their usefulness ends
| there.
|
| The tooling, documentation, community, and everything else beyond
| the language often matter as much as the language itself. And for
| better or worse, you simply have more eyeballs on these things as
| the language gets more popular.
| yladiz wrote:
| >The tooling, documentation, community, and everything else
| beyond the language often matter as much as the language
| itself. And for better or worse, you simply have more eyeballs
| on these things as the language gets more popular.
|
| I would argue they matter even more than the language.
|
| Community is probably the main important one, but the others
| you mention are foundational too. For example having good
| documentation is crucial and is basically the way people get
| familiar with the language over time. For Clojure specifically,
| I think the shit documentation is one reason it will continue
| to grow slowly, because it reflects poorly on the maintainers
| and shows they don't care about newcomers or people who don't
| "know it". It's such a poor reflection on the language that the
| core documentation is so bad that there's the community one
| that exists purely to show examples and explain things that the
| terse docs don't.
| kbuchanan wrote:
| It's true, the Clojure ecosystem is especially hostile to
| newcomers--in my view it's the principle reason the language
| has not grown more quickly. There are community members have
| made the documentation much more manageable, but beginners
| are still very much left to their own to discover solutions
| to pretty common problems.
|
| But I disagree that it reflects poorly on the maintainers--
| rather, I think it illustrates that, for the most part,
| Clojure was created by experienced language pragmatists, for
| other experienced pragmatists. Clojure tends to be a _refuge_
| from other languages, not something a person is born into.
| The State of Clojure each year consistently shows how many
| other languages Clojure users already knew before coming to
| the language. I appreciate how the maintainers value
| backwards-compatibility (nothing ever breaks, it only gets
| better), that they are strongly committed to making the
| language great in the long run, and are unmoved from the
| language 's founding values.
|
| I do hope as a community we can do a better job for
| newcomers, for all our sakes--new blood brings new
| perspectives, but it's okay that "growing the community"
| isn't the Core team's top priority. (But hopefully becomes
| _someone 's_ priority in the community at some point...)
| filoeleven wrote:
| > I appreciate how the maintainers value backwards-
| compatibility (nothing ever breaks, it only gets better),
| that they are strongly committed to making the language
| great in the long run, and are unmoved from the language's
| founding values.
|
| This shows even in the half-life of the Clojure repo:
| https://m.imgur.com/a/rH8DC
|
| That image is 5 years old now, I saw it in the 2016
| discussion linked below, but the trajectory is clear
| especially when compared to the other popular repos
| analyzed in the post.
|
| https://news.ycombinator.com/item?id=13112449
| sokoloff wrote:
| I am teaching myself Clojure now (starting around US
| Thanksgiving to be ready for some advent-of-code problems in
| it).
|
| I never found the docs lacking. Of course, I was using the
| community docs without knowing (nor caring) that they were
| community rather than core team docs.
|
| Clojure will grow slowly because it's different (and "harder"
| in some ways) from other language platforms. I don't think
| many people will be turned off by the fact that excellent
| docs are at a different URL.
| didibus wrote:
| > believing it's going to be the most transformational
| experience I've had as a developer
|
| Learning Clojure was probably the most transformational
| experience I had as a developer. Before that I knew Python, C#,
| Java, C++, and a bit of Ruby and JS. But learning Clojure and
| getting to use the Lisp syntax, an interactive development
| workflow, learning about FP, the simplicity of immutable data,
| and the power of macros made programming interesting again and
| it just turns out I have so much more fun using Clojure to
| program in.
|
| > You can reach a flow-state where ideas can freely flow from
| your mind into code
|
| I wouldn't say that's totally the case. While the interactive
| development and the succinctness and simplicity of Clojure does
| help with my productivity, coding still requires thoughts, and
| asking yourself how do I implement this and that and thinking
| through it is still often needed for all but trivial tasks. The
| big difference for me is that this process is now a lot more
| fun and engaging.
|
| It might not be that you'll find a niche language like Clojure
| more fun and engaging, but it could be that you do, and that's
| the appeal I think. For some, there's a niche language out
| there that they just enjoy a lot more for one reason or
| another.
| roenxi wrote:
| There are also signals that Clojure is genuinely challenging to
| learn. If a language is favoured by senior developers and the
| user base tends to be people with a decade of programming
| experience then that is a hint that newbies can't learn the
| language.
|
| Maybe that is ok. Having an expert language to bolt on to
| Javascript or the JVM might be just what the doctor ordered.
| But there are a lot of tricky aspects to Clojure, and a lot of
| ideas that are outside the mainstream (eg, not really having
| variables). And the language leads people into complex nested
| functional structures that are challenging to debug - breaking
| up a big map or reduce to debug it when something is going
| wrong is not much fun. I can see people giving up and going
| back to for loops rather than toughing it out and learning how
| to do things functionally.
|
| And the tooling can be atrocious. Running "clj --help" and
| deciphering what it all means is not for the faint hearted. A
| user needs to be familiar with Clojure data structures, Java,
| build system ideas for both (like aliases, coordinates,
| namespaces, classpath, file loading process) as a prerequisite,
| then there are no hints from the deps.edn syntax so one has to
| read the entire manual to know what options there are. Doing
| something more than running a repl or a single file can easily
| spiral into an entire weekend project in my experience. That is
| a bit silly to admit to, but I suspect it is a big barrier in
| practice. The competition is "pip install" and Python lets
| multi-file projects work quite well even without understanding
| the packaging system. For a Java hosted language it is hard to
| avoid the classpath.
| swlkr wrote:
| I went through a long clojure/lisp phase and although I'm not
| using anymore, I became a much better programmer because I can
| more easily see abstractions and how data flows through more
| complex systems using OOP or whatever.
| hota_mazi wrote:
| > Lisp is the most expressive and flexible language. You can
| reach a flow-state where ideas can freely flow from your mind
| into code
|
| This kind of claim typically comes from someone pretty new to the
| world of software development.
|
| You can say this of any language, really, and any developer who's
| reasonably proficient in language X will also claim that with X,
| their ideas flow directly into code.
|
| > The Lisp programming language Racket is used to teach
| programming fundamentals in modern Computer Science courses.
|
| Unsurprising cherry picking. How many universities teach Racket
| compared to, Javascript C/C++, or Java?
|
| The rest of the article is of the same cloth, raving about Lisp
| and Clojure as the best programming languages ever invented.
|
| You should learn Lisp, no matter what kind of developer you are.
| But by today's standards, Lisp a pretty antiquated language which
| still hasn't caught up to modern trends (static types,
| asynchronism, etc...) and with a very poor tooling (lack of
| IDE's) and library ecosystem (building websites, parallelism,
| GUI, etc...).
| Jach wrote:
| > You should learn Lisp, no matter what kind of developer you
| are. But by today's standards, Lisp a pretty antiquated
| language which still hasn't caught up to modern trends (static
| types, asynchronism, etc...) and with a very poor tooling (lack
| of IDE's) and library ecosystem (building websites,
| parallelism, GUI, etc...).
|
| Literally all of these things are present in Common Lisp (ok
| the static types "full experience" leads you to something like
| Coalton: https://github.com/coalton-lang/coalton however the
| plain SBCL experience does have some compile-time type
| checking). Meanwhile many so-called modern languages still lack
| Lisp's incremental compilation let alone the full interactive
| development experience such a feature can help support, an OOP
| system as flexible as CLOS, they can't gracefully manipulate
| their own code as data, they don't have anything like the
| condition system...
| dragonwriter wrote:
| > But by today's standards, Lisp a pretty antiquated language
| which still hasn't caught up to modern trends (static types,
|
| Typed Racket exists, as does syntactic support for static type
| declarations in Common Lisp (though whether implementations do
| anything with declarations is up to them; some, however, do
| offer compile-time checking.)
|
| > asynchronism,
|
| Racket has asynchronisn via both the thread API (which aren't
| OS thread, but asynchronous tasks with mailboxes) and via
| promises (promise/force in Racket is pretty much all the good
| parts of async/await without the bad parts; future/touch
| provides a similar API for operations that are parallel rather
| than merely asynchronous.)
|
| > very poor tooling (lack of IDE's)
|
| Racket, CL, and Clojure all have dedicated IDEs; a number of
| Java-focused IDEs support Clojure as well.
|
| > library ecosystem (building websites, parallelism, GUI,
| etc...)
|
| Clojure is designed to leverage the JVM ecosystem, so that's
| clearly not the case for Clojure unless your standard for a
| library ecosystem is something beyond what the Java world has.
| (Similarly with ClojureScript and JS.)
|
| But, sure, there's no Lisp-first platform as popular as the
| JVM, .NET, JS, or CPython.
| newplagiarist wrote:
| > which still hasn't caught up to modern trends (static types,
| asynchronism, etc...)
|
| Ignoring the fact that your modern trends aren't modern. I
| don't think any of these statements really are true for Lisp as
| a family of languages:
|
| For example Racket has typed Racket. https://docs.racket-
| lang.org/ts-guide/
|
| For asynchronicity Clojure has clojure.async
| https://github.com/clojure/core.async
|
| > and with a very poor tooling (lack of IDE's)
|
| Lisps have fantastic support in Emacs and VSCode and are in
| general simple enough languages that often the heavyweight of
| an IDE is not needed. But if you want IDEs there are:
|
| Dr. Racket - https://docs.racket-lang.org/drracket/index.html
|
| Cursive - https://cursive-ide.com/
|
| Emacs/Cider - https://docs.cider.mx/cider/index.html
|
| > and library ecosystem (building websites, parallelism, GUI,
| etc...)
|
| Websites - Reagent, a ClojureScript wrapper for React
| https://github.com/reagent-project/reagent
|
| GUIs - Clojure has the entirety of Java to steal GUIs from -
| Ex: https://github.com/cljfx/cljfx
|
| Just because the Lisp family is old and has a simple syntax
| does not mean it's an antiquated language or that there are not
| new developments going on there.
| didibus wrote:
| > Lisp a pretty antiquated language which still hasn't caught
| up to modern trends (static types, asynchronism, etc...) and
| with a very poor tooling (lack of IDE's) and library ecosystem
| (building websites, parallelism, GUI, etc...)
|
| That's pretty much the whole point of Clojure, a modern Lisp,
| built for concurrent and asynchronous programming, targeting
| modern platforms like the JVM, CLR, NodeJS, browser JS
| runtimes, with great IDE and tooling, and access to the largest
| swath of existing libraries from various ecosystems.
|
| It also has an optional static type checker, though it isn't
| very popular and so you'll lose type checks at the boundary
| between your app and all libraries you use (even most of the
| standard lib). But I wouldn't really call static types a
| "modern trend" in any way, considering we just had untyped
| languages overthrow static ones in popularity with the
| unprecedented rise of Python, Ruby and JavaScript. And the most
| popular typed languages are still playing catch up to the ML
| languages of yore in their static type checking capabilities.
| c-cube wrote:
| The untyped languages rose in popularity in the 2000s and got
| as mainstream as it gets. But static typing is having a
| comeback in the past 5-10 years, with go, rust, kotlin, and
| of course typescript. Almost every dynamic language is
| getting some flavor of gradual typing and most people seem to
| love it.
| didibus wrote:
| I guess it depends what your mesure criteria are.
|
| Based on this video:
| https://www.youtube.com/watch?v=UNSoPa-XQN0 JS and Python
| took the top spot only in the last 5 years, and I'd think
| they're only continuing to attract more people.
|
| There's been some new typed language also gaining traction,
| just not as much or as quickly.
|
| Frankly it doesn't seem types or not matter much over the
| years for popularity.
|
| What I find interesting personally now is that a lot of
| people come out of school learning Python, an untyped
| language. I wonder what effect that'll have long term,
| where as before I feel it was either Java or C++ or another
| flavor of a typed language that university and schools
| would teach.
| agumonkey wrote:
| I wonder if I other proglangs are really on par Lisp like (open
| to extension at the meta level) langs. It's true a good perlist
| or ada coder can flow. But when you reach the limit of a
| language, you're stuck. These other languages become their own
| tool, and compound on.
___________________________________________________________________
(page generated 2021-12-31 23:01 UTC)