
Clojure as a dependency - nathell
http://blog.danieljanus.pl/2020/05/02/clojure-dependency/
======
siscia
I just find amazing that the project is working with clojure 1.2.0 as
dependency,

Which is about 8 years old.

Clojure hold a soft spot in my heart for emotional reason, but the engineering
behind it is top notch.

If any of you need motivation to go and learn it! Please do it! You will never
regret invest time in clojure.

~~~
Scarbutt
_If any of you need motivation to go and learn it! Please do it! You will
never regret invest time in clojure._

Agree that Clojure is a good language to learn. If you plan to use it beyond
educational purposes though, expect to hit many walls when/if you plan to
write real world apps with it. The foundations are there but the ecosystem
isn't. Someone will mention the Java libraries, but at that point you are not
really writing Clojure. Also, be prepared to deal with the cultish obsession
of the community. They have very strong opinions but will never elaborate.

~~~
nocman
> Also, be prepared to deal with the cultish obsession of the community. They
> have very strong opinions but will never elaborate.

I'm curious to know what "cultish obsession" you are referring to. Also, what
strong opinions have you been unable to get elaboration on?

~~~
Kalium
When working with Clojure teams, I personally ran into "libraries, not
frameworks!". Interesting maxim, but I never found any kind of satisfactory
explanation. There was a general deep-seated belief that Clojure was the right
solution for every problem, with a similar amount of elaboration.

~~~
slifin
Clojure is a good solution for many problems (obviously not all) mostly
because it reaches many capable runtimes, java, js, python and interop is
first class

What you might be encountering is after a few years of Clojure becomes such
that you'd rather not be writing anything else and that is semi-practical as
opposed to many other niche specialised languages where it's not so realistic

Libraries, not frameworks is a point of contention even within the Clojure
community, libraries tend to compose and upgrade better over time but there
are also frameworks in Clojure

Luckily we don't have one that dominates the language so totally that it
cannot be ignored despite what inevitable deficiencies it has

Keep in mind most Clojure developers came from other languages and have
Vietnam flash-backs to many frameworks

~~~
ithrow
_interop is first class_

That's hardly true, not even clojure.org claims that. Interop is far from
seamless.

~~~
daveliepmann
I would say that "first class" is a perfectly reasonable way to phrase it.
While clojure.org doesn't use that exact phrase, host interop has always been
a central pillar of the language:

>Clojure is designed to be a hosted language, sharing the JVM type system, GC,
threads etc. All functions are compiled to JVM bytecode. Clojure is a great
Java library consumer, offering the dot-target-member notation for calls to
Java. Clojure supports the dynamic implementation of Java interfaces and
classes.

What do you mean by "far from seamless"?

------
diggan
I've always found this thing of projects defining Clojure as a dependency of
their project to be a artifact of that Clojure wants and aims to be a hosted
language. So while it doesn't make much sense to have a Clojure project
without Clojure included _somewhere_, it makes plenty of sense (in some
specific use cases) to use Clojure as a library in a Java project with Maven,
or JavaScript project with ClojureScript compiler as a library.

So with this, are there other languages where they are explicitly designed to
be "parasites" like Clojure?

One could argue the many "compiled to JS" language are such, but they are
always very hardcoded to JS, so not really parasitic like Clojure.

~~~
jonahbenton
The "hosted" part is not quite right. Clojure is hosted, but what I think you
are referring to with the "parasite" metaphor is called "embedded." (Distinct
use of the term embedded from its use to describe small systems hardware).

Clojure was definitely designed to be both embedded and hosted, but those are
distinct axes.

There are lots of languages designed to be embedded as scripting or automation
runtimes in other systems. Tcl, Lua, Python, Guile (a lisp)...

Why embedded- pre-web, there used to be a practice of writing your
infrastructure in systems language (C/C++) then writing your application tier
in a scripting language. Countless games and GUI line of business tools on
Windows were written this way.

Java in this case was considered a "systems" language, and there is a long
history of embedded languages for Java. My favorite JVM-embedded language was
called Beanshell.

This embedding was/is a use case for Clojure, important for "sneaking" Clojure
in to the enterprise.

The "designed" part implies that the scripting runtime plays nicely with
process-owned resources like threads and memory, and has a well defined
interface for exposing your infrastructure objects to the scripting layer.

Post-web, if you squint, you can recognize this architecture in the DOM the
browser (written in a systems language like C++ or Rust) exposes to its
scripting tier (Javascript).

------
JackMorgan
Just FYI to the author, I can't read this on Firefox mobile, the text is
clipped weirdly. Reader mode does work however.

~~~
nathell
Thanks for the report, will try to fix this.

~~~
daviddaviddavid
Since you're here, I'd just like to say that the font you're using (Bona Nova)
is wonderful. I smiled ear to ear when I saw the capital-Q in the phrase
"Quite possibly".

~~~
nathell
I'm so happy that you appreciate it!

This is typographic patriotism on my part (I'm Polish). This typeface [1] is a
design of the late Andrzej Heidrich, who also designed the banknotes of the
Polish zloty.

One of my two favourite Polish typefaces. The other is Antykwa Toruńska
(Torunian Antiqua) [2], a 1960 design by Zygfryd Gardzielewski.

[1]: [http://bonanova.wtf/?lang=en](http://bonanova.wtf/?lang=en)

[2]: [https://jmn.pl/pliki/AntykwaTorunska-doc-
en.pdf](https://jmn.pl/pliki/AntykwaTorunska-doc-en.pdf)

------
regularfry
Wouldn't this be less of an issue if you could say '[org.clojure/clojure
">1.2.0"]'? Or any of the other version number matching formats rubygems, npm,
cargo, or any of the other package managers seem to manage?

~~~
nathell
You can, but this is discouraged. Unlike in other version management systems,
Clojure tools do not use lockfiles; you're expected to be explicit about the
version numbers you want.

[https://nelsonmorris.net/2012/07/31/do-not-use-version-
range...](https://nelsonmorris.net/2012/07/31/do-not-use-version-ranges-in-
project-clj.html)

~~~
regularfry
Why no lockfiles? I'm sure there's a reason, I just don't know what it is.

~~~
nathell
This question merits a detailed answer that I can't provide right now, but
here are some pointers:

[https://hypirion.com/musings/lockfiles-are-not-the-only-
opti...](https://hypirion.com/musings/lockfiles-are-not-the-only-option)
[https://stackoverflow.com/questions/44521542/why-doesnt-
grad...](https://stackoverflow.com/questions/44521542/why-doesnt-gradle-or-
maven-have-a-dependency-version-lock-file)

~~~
regularfry
All those links really tell me is that the problem lockfiles solve has been
arbitrarily ignored. "A solution can exist, it's just not currently
implemented" seems to be the state of things, unless I've misread it.

I'm all up for saying "thou shalt specify precise versions of library
dependencies", but the specific case of `org.clojure/clojure` seems
qualitatively different in that a precise version influences your consumers,
and leaving it unspecified means your library might not work at all.

