Our great sponsors
-
-
coalton
Coalton is an efficient, statically typed functional programming language that supercharges Common Lisp.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Clojure is about 2.75x slower than Java, while Python is 5.59x slower.
The fastest composite Python "framework" is uvicorn at 17.9% of the fastest run in Java (officefloor). The fastest Clojure run is Aleph at 36.4%.
https://www.techempower.com/benchmarks/#section=data-r21&l=z...
About SBCL, I get conflicting results. The Benchmarks Game shows it roughly as fast as Java for many problems:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
But here it's significantly worse than the Clojure runs, likely due to the slow DB bindings (the other test types show it roughly in line with Clojure; though it uses a "Stripped"/unrealistic HTTP implementation):
https://www.techempower.com/benchmarks/#section=data-r21&l=z...
I am not sure which Lisp implementation is used; is it SBCL? Does this file speak to you?
https://github.com/TechEmpower/FrameworkBenchmarks/blob/73eb...
I vehemently disagree with dynamically typed being a winning point of Lisp. SBCL's strong support for type checking is the main reason I was drawn from Scheme to CL, and Coalton (https://github.com/coalton-lang/coalton) is one of the most interesting Lisp projects I have encountered.
Type checking can remove an entire class of bugs from even being a consideration. Yes, it could be argued that type mismatches are a trivial class of bug, and yes, proper testing should catch any issues... but catching problems before you go to testing can save you precious seconds, especially when coding in the typical interactive style of Lisp. Lisp lets you code at amazingly high velocity, good support for type checking helps increase that velocity even further.
Well, I wrote a genetic programming library, and it was fun to parse a Lisp-like representation from Python. You still have recursion and everything (albeit no tail call optimization).
Here, `_from_source` goes from a plain array of tokens to a nested one (tree), depending on their arity:
https://github.com/danuker/symreg/blob/7c6593d3046f6c52dfb92...
Lisp is almost valid Python. The exception is the single-element tuple which needs a comma: (x,)
But I still preferred to use Python as a programming language, and Lisp as a sort of AST. It's just easier. I am curious what roadblocks you faced in your ASCII delimited parsing.
Do you by any chance still have the two parsers? I'd love to see them. If you are worried about your anonymity, you can find my website on my HN profile, and my e-mail on my website. I promise not to disclose your identity publicly.