puredanger

ClojureCLR is up to date with the Clojure on JVM, so not dead at all.

Has been a long topic of conversation trying to figure out the best way to do some of these while also retaining best performance, etc. High in our list of candidate things to work on!

Spec 2 can be used without touching any macros if desired and has a lot more programmatic options.

You can argue whether Lisp is a functional language, but Clojure certainly is. When written well, the bulk of your code will be pure functions taking and returning immutable data or passing around pure functions. https://clojure.org/about/functional_programming

In Clojure, first and rest apply to sequences, which are a logical list abstraction. They apply to lists, but they can also be used on sequential views of indexed vectors, maps, sets, database result sets, files in a dir, lines in a file, and an open world of "things that can be seen in some order". head and tail I suspect are much more tied to linked lists and data structure than the more plain first and rest.

Build tools like lein or Maven attempt to build a "declarative" definition of a project and then apply a set of plugins to that model using an implicit lifecycle. In reality, simple projects don't need that complexity and complicated projects only match 80% to either the lifecycle or the plugins available, so you end up wedging imperative things onto the build, hunting down obscure plugins, or hacking your own. Other build tools (like boot, or even Ant) acknowledge that builds are actually programs built from similar tasks.

deps was designed to find a sweet spot in the middle of this with deps defined as data, aliases capturing program executions as data, but builds as programs. As such, the scope is drastically narrowed in deps to just a) building classpaths (by resolving dependency graphs) and b) launching programs.

As such, this tends to be a dramatically simpler model to start with (your initial deps.edn can be empty), and a model that is easy to understand as you scale up. I think there is more to do in how we model "tools" (esp tools shared across projects) and program composites, but nothing prevents you from building these yourself if needed (as you have the full power of Clojure at your disposal).

You can find a pretty comprehensive list of deps.edn tools at https://github.com/clojure/tools.deps.alpha/wiki/Tools

FYI, there are edn implementations in many other languages: https://github.com/edn-format/edn/wiki/Implementations

The demand and supply for Clojure both exist, but they are not equally distributed geographically.

Yeah, it's only used at weird startups like Walmart, Apple, Amazon, Cisco, etc.

"Increased comfort" and "clear progress" are subjective measures about which people may disagree (to whit, I disagree).

I argue that in ten or twenty years from now, we will have great tools in dynamic languages to express constraints when needed, without requiring proofs.

These are opinions, not facts.

docstrings are intended to be a concise statement of what the function does and we would like to stick with that.

Examples are also great. We would love to have documentation pages (or even doc functions in the repl) that combine multiple sources of information to help you out (docstrings, examples, see alsos, etc). That stuff does not have to be "in the docstring" for it to be available to you as a user.

For example, clojuredocs.org does exactly this, combining multiple sources of information into one combined page (ex: http://clojuredocs.org/clojure.core/zipmap). There used to be an api for clojuredocs.org and a repl lib you could use that would give you an additional function to get those examples at the repl too (I think that fell out of maintenance).

The summary is, we can both have docstrings that don't include examples AND provide examples by merging docstrings with other things for the user.

People use Clojure for all of those. From the rationale (https://clojure.org/about/rationale), Clojure "endeavors to be a general-purpose language suitable in those areas where Java is suitable".

> Sure, static types have trade offs, but they are a clear improvement on all dimensions over dynamic types

That has not been my experience and I don't think there is much objective proof of this. Most of the (admittedly not great) studies I've seen show dynamic languages as comparing favorably or better in bug counts for example.

Some of the things we're working on in the next version of spec are is head-on the notion of how to define expressive contracts for functions and allow those to meaningfully evolve in compatible ways over time as program requirements change.

I look at FORTRAN as a great language for its domain, so maybe you're right. :)

I guess that's why all those statically typed programs don't have any bugs and don't need any tests.

Being "sound" just means you can prove things are consistent with the assumptions you can encode in it. If there are things you can't encode in the types, or if your assumptions are wrong (misapprehension being one of the main problems in software), or if your requirements change, soundness is not going to save you.

Static types and proofs are valuable. Programs like compilers have fixed inputs and outputs and are excellent places to lean on things you can prove. But most of the programs I've worked on are not like compilers. They run for years, the requirements change, they have to deal with dirty data, talk to other messy systems, etc. And I'm not saying that dynamic types are perfect either.

My point is simply that static types are not a magical end goal of programming. They are a tool with tradeoffs.

From inside the core team, I feel entirely community-focused. I spent a good chunk of last year working on improving many aspects of error messages, the top community complaint in surveys. Currently I'm spending time working on spec and trying to guide external (community!) work on clj for Windows, also two things highly mentioned in the survey. I spent all day today answering dozens of questions in HN, reddit, slack, mailing lists, jira issues, github issues, etc. Not even sure how it's possible to be more focused on the community than I am.

I don't get how you go from my comment to that. I literally talk to people all day long, every day, about what we should be doing in Clojure. The idea that this is "Rich's gift" and we're not taking input from others is just wrong.

http://insideclojure.org now has weekly journals detailing everything we're doing in Clojure dev if you're interested.

Pendulums swing....

I appreciate the feedback.

The link near the top to "command line tools" (https://clojure.org/guides/deps_and_cli) is probably the next logical step but maybe could be highlighted better. If you want to leave some comments on an issue at https://github.com/clojure/clojure-site/issues - that's a great place for me to take actionable feedback.

Fully learning the language, the tools, and how to make a project are all different topics, and have their own interactions with whatever other tooling they are using. I think a lot of that is there but I'll take your point that they aren't guided well enough. Definitely worth taking a few more passes, thanks.

I did!

I find the Clojure Slack to be a great and helpful community. There are certainly plenty of other Clojure chat systems on Zulip, ClojureVerse, etc.

Oh, do tell? Please point me at the scientific and mathematical evidence. I would be interested to see it.

I've worked on multiple large Java codebases, and on semi-large Clojure code bases. The Java ones compiled great but were full of bugs obscured by 100s of useless classes with bespoke interfaces. I found the Clojure code bases to be far more tractable because the language leads to better opportunities for abstraction and more concise code with way less incidental complexity. I think spec can add another layer of description where it's useful (and is not required where it's not).

Just a clarification, Clojure copyrights etc are owned by Rich Hickey, not Cognitect. Cognitect pays for all of the core development team salary, infrastructure, etc.

docstrings - we apply many docstring fixes in every release.

NIH - are we literally never supposed to try to make anything new? Doesn't this non-argument apply to literally the creation of every language, library, and tool? This is silly. clj has different (quite clear) goals than Lein or Boot and both doesn't do things they do (like builds) and does things they do not (like git deps).

We have been accepting PRs for docs on the site for 3 years. Who cares how long it took before we started doing that if we're doing it now? Wouldn't it be more productive to praise for what you like than crap on how someone used to do something you didn't like?

Isn't it a good thing that Clojure is such as productive tool that it can support a consulting company that can afford to pay decent salaries so the core team can continue working full time on Clojure making it even better? This is a good thing. I suppose we can also ignore the hundreds of tickets, patches, and contributors to the language, many of whom have nothing to do with Cognitect or their consulting, as that's more convenient for this line of reasoning.

Do you think Clojure would be in a better place today if it did not have this support from a company willing to champion it? How often has that been a successful strategy for languages?

Thanks!

Clojure is easy to teach. Why not just hire good devs and teach them Clojure? I think people overlook this too often.

Windows clj is a work in progress and the page will be updated when it's ready. So, it will.

The Maven example is a way to get a standalone local-only (spec libs included) jar. Some people do this (it seems weird to me, but people do).

Leiningen and Boot are not official tools and are more than you need to get started (excepting the Windows caveat, which is a small portion of the Clojure user base that will be plugged, hopefully soon).

This is not the "first step" way to get started, which is why it's at the bottom of the page. Leiningen is not any easier to install and use than what's already there at the top of the page as the recommended path.

The clj tool introduced with Clojure 1.9 is designed to help with exactly this problem. https://clojure.org/guides/deps_and_cli