this post was submitted on 03 Dec 2024
5 points (100.0% liked)
Clojure programming language discussion
458 readers
2 users here now
Clojure is a Lisp that targets JVM and JS runtimes
Finding information about Clojure
- History of Clojure
- Clojure Homepage
- A Clojure Newbie Guide
- Clojure Documentation
- Clojure Cheat Sheet
- ClojureScript Cheat Sheet
- Clojure by Example
- Clojure beginner resources
API Reference
Clojure Guides
- Clojure Distilled Beginner Guide
- Clojure Style Guide
- Clojure for the Brave and True
- Clojure from the ground up
- ClojureScript in 15 minutes
- ClojureScript Workshop
Practice Problems
Interactive Problems
Clojure Videos
The Clojure Community
- Ask Clojure
- Clojure user groups
- ClojureScript user groups
- Clojure Slack Channel
- Clojurians-Zulipchat
- Clojure Discord
- Clojureverse: a forum for and by the Clojure community
- matrix/riot-im Clojure room
Clojure Books
- Clojure Book
- The Joy of Clojure
- Clojure Programming
- Clojure In Action
- Programming Clojure
- Web Development with Clojure
- Clojure Cookbook
- Professional Clojure
- Living Clojure
- Getting Clojure
Tools & Libraries
- Leiningen - Package management
- nREPL - Networked REPL
- Gorilla REPL - A rich REPL for Clojure in the notebook style
- Clojars - Clojure library repository
- The Clojure Toolbox - a list of popular Clojure libraries
- (clj-templates) - templates for Leiningen and Boot
Clojure Editors
- Emacs CIDER
- clojure-mode.el - Emacs mode
- Emacs Prelude - a gentler Emacs mode
- Cursive - Clojure support for IntelliJ
- Calva - Calva โ Visual Studio Code
- Vim Iced - Vim
- vim-fireplace - another Vim editor
- Conjure - even more Vim
Web Platforms
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If you look at the linked repo, they're not using any standard library functions that would have impact the timing.
The fundamental crux of the issue is that the author doesn't seem to understand that at the end of the day, after all of the hand waving and slight of hand, all code is executed on a processor using whatever that processors instruction set is. ALL of them.
The question isn't "what language is fastest", it is "given the instruction set has an optimal solution, how close to that can I get to that optimal solution with different languages?"
There is really no guarantee that the code samples are comparable either. Unless the author actually examines the resultant instructions, it's entirely possible one implementation is "cheating". If I have a collection I know to have certain properties (like being a range) for all you know it's pulling a Gauss under the hood. If, say, Java streams did that, then why make the C compiler write a program with two billion 64 bit additions?
Anyways, I think these types of articles/investigations are neat. The problem is that they're often accompanied with commentary and conclusions that they authours don't have the knowledge to be able to provide.
Anyhow, long story short, if you look at the repo this wasn't an apples to apples comparison to begin with.