6 ms·
The cancellation of a few major Clojure conferances hasn’t helped. I’m guessing it speaks to demand. I used Clojure for a long time, professionally. Not much
by hellofunk 8y ago
The cancellation of a few major Clojure conferances hasn’t helped. I’m guessing it speaks to demand.
I used Clojure for a long time, professionally. Not much any more. Main issue is that the language is not very readable (a pain point mentioned in these slides) and very hard to find people to work in it. Also more than any other language Clojure is very sensitive to typos in your code. A misspelled keyword results in nil accidentally flowing through your app. It was frustrating to spend time on scaffolding everywhere to catch these things.
- kamaal 8y ago>>A misspelled keyword results in nil accidentally flowing through your app. Some dynamic languages, worked around this issue in the 90's. Perl for example, if you use 'use strict; use warnings' will catch most of these misadventures. Having said that, only the most novice programmers make these kind of mistakes. Like the absolute beginners, in the first day or two of exposure to programming. As a rule almost any shop these days write unit test cases, so that should flush out these kind of bugs. EDIT: Why the downvotes? People seriously work with programmers whose biggest incompetence at work is typos? Or you think writing unit test cases is bad?
- StreamBright 8y agoThey just disagree without explaining why. Anyways, I sometimes have typos in my Clojure code, but once I follow through with your mental model and just reproduce the problem in REPL it is easy to find these sort of bugs.
- kamaal 8y agoI'm not sure, but if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names, write functions hundreds of lines long, can't modularize code, write 3 nested for loops, or write nested if's where '&&' suffices. Then you are having far bigger problems related to project management, hiring and overall direction in which you are running your team/company. Clojure as a tool doesn't aim to fix these kind of problems. And it can be argued no tool will fix these problems.
- tome 8y ago> if people have problems, as bad as things like hiring programmers who struggle with indenting code, making typos in variable names Those are the kind of things that the computer is best suited to. It's better if the programmer's brain is left to other, more challenging tasks.
- kamaal 8y agoOne wonders what kind of challenging tasks a programmer who can't even indent code, can solve. By the way indenting code happens to be the most basic of code review checks.
- tome 8y agoWhy waste human time on what can be done by a machine?
- cmoscoso 8y agoIn my experience, a compiler would be wasting my time interrupting me with errors that are easily catch later, playing with the clojure REPL.
- 200px 8y agoCode indentation has been automated away since like 10 years or ago or maybe even more. Vim, Emacs, Atom, Sublime Text, Visual Studio, Eclipse, IntelliJ, NetBeans can all auto-indent code for you. Combined with linters they can also automate stylistic checks and coding convention. I don't know anyone who indents code themselves. The editor/IDE does it for them. Indenting code is certainly not a code review check. No sane workplace should waste a senior developer's precious time commenting about indentation problems during code reviews. It is a tooling check that is part of CI/CD.
- jurassic 8y agoYou don’t have to be an absolute beginner to make this mistake. You just need to be on a project with inadequate test coverage.
- nosefrog 8y agoWith all due respect, I think your argument is a little silly. Typos are the one mistake that programmers never stop making no matter how experienced they are, in my experience. For the same reason, you can pick up a book by an experienced, established writer and find typos in it as well. It's useful for your tools to help you catch basic mistakes like that instead of just saying you should work with programmers who are competent enough to never write typos.
- kamaal 8y agoI don't think we are talking about that kind of typos. But there is a often a big dip in quality of people, who routinely struggle to write a half decent working program without making these kind of mistakes. Sure every once in a while its possible for any one to drop in a spelling mistake, but those are rare situations in code. Mostly because code is often not a dead piece of documentation, which is read and auto corrected in the human brain. Code works on a computer with well defined interfaces and protocols. Think of it this way, would you hire a programmer who often makes typos, to write shell scripts that have 'rm -rf'? If you wouldn't, how often do you trust these people to execute DROP DATABASE <typo_database_name_which_happens_to_be_real>? There is a big difference between programmers who can put in typos in a sentence in a code comment, and the kind of ones we are talking about.
- hellofunk 8y agoI've deployed tens of thousands of lines of Clojure for a company over several years, and I still find that I occasionally destructure a map with the wrong keyword and I end up with nil accidentally. It's frustrating as much now as it has ever been. Because the app just crashes instead of a simple compiler check that most languages would offer to capture simple stuff like this.
- sdegutis 8y agoAlso the Clojure language had a huge growth period around 1.1-1.5 which sparked a lot of excitement and spurred a lot of community growth. But since then, most of the exciting features have been adapted to other mainstream languages either as features or libraries, and most senior developers I know prefer to take the path of least resistance, which includes avoiding less-mainstream languages and frameworks. So instead of using Clojure with Compojure, it's common to move to Java with Dropwizard, or slightly less analogous, JavaScript with Express.js. And instead of using ClojureScript with Om, people mostly jumped to JavaScript + React. Edit: Removed comment about Om, since I must be misremembering something. Om uses React and has since the first commit.
- shady-lady 8y ago> he Om team later praised as being the same concept they had in mind, but with a simpler and better API. is this in public? cursory search did not return any hits.
- smneiswrngonthi 8y ago"And instead of using ClojureScript with Om, people mostly jumped to JavaScript + React, which the Om team later praised as being the same concept they had in mind, but with a simpler and better API." Om solves a different problem than js + react. Om uses react. You are comparing apples and oranges. Do you know what you are talking about? I'm guessing you have never used react or clojurescript or OM. What you said makes no sense.
- hellofunk 8y agoUm, Om is React. React came first and Om interfaced with it.
- KingMob 8y agoWhat are you referring to by "instead of using ClojureScript with Om, people mostly jumped to JavaScript + React, which the Om team later praised as being the same concept they had in mind, but with a simpler and better API"? Om uses React, it didn't predate it or anything. Many of the things Om tried are more relevant to things like Redux, not React proper, so I'm not sure what your comment is referring to. And as a counterpoint, React just introduced the State and Effect Hooks, but those are both things that Om and reagent (the most-used Cljs React lib) have been able to do for years.