Hacker News Reader

Comment by anonzzzies | Hacker News Reader

... which is not a bad reason in some cases.

I for instance find Python the most horrible language + ecosystem outside the js ecosystem (but I like js the language more and that's saying something), so I would always opt for lisp (or pen + paper) over Python. R / Rstudio are nice though.

I don't think it really tracks either; Lisp is quite ergonomic for this type of thing and, if you have been doing it for a while, you'll have your own tooling to work faster/more efficient in that lisp and of course, the comparison falls down then as the swiss knife now has a chainsaw option which is as good or better than other options to cut down trees.

View on HN

Yeah I don't get it either. Lisp is perfectly fine for this task although probably makes less sense now that Julia is a thing.

Reminder that before Python was used for data science, people used things like BioPerl and PDL and that didn't stop people from working on pandas and the like.

Also let people have fun.

Lispers might not like that it's not a Lisp, but I remember Luke Tierney also making a statement to the effect that the statisticians have spoken and they don't prefer the Lisp syntax.

So Julia is a happy middle ground - MATLAB-like syntax with metaprogramming facilities (i.e., macros, access to ASTs). Its canonical implementation is JIT, but the community is working on allowing creation of medium-sized binaries (there has been much effort to reduce this footprint).

Julia isn't a lisp, but I think it's the most lispy non-S-expression based language around these days. The language creators took the lessons from lisp very seriously, and it shares a lot of functionality and philosophy with lisps.

Well I think the original author was a fan of Lisp and implemented the first Julia parser in femtolisp, IIRC. (And femtolisp was a lightweight Lisp of his own.)

Julia is somewhat different:

1. readability with explicit broadcast operators

2. interoperability with other languages including R and Python

3. performance often exceeding numpy and C/C++ code

4. usability in numerous workflows:

https://www.queryverse.org/

The idea of using Lisp or Prolog in a production environment doesn't sound fun at all. Yet, they do make some types of problems easier to handle. =3

Reply on news.ycombinator.com