Hacker News Reader

Comment by ConanRus | Hacker News Reader

Short answer: don't do that, use Clojure instead. It doesn't have any of listed problems.

I am sure there are plenty of people who have a preferred Lisp. It does drive me nuts how if there is a post on R the top comments are people touting Python as being the bigger player in statistics and data science (Which it isn't) or a ton of other languages.

PS I perfer Racket :)

Came here to share my love for Racket. Parameterization, custodians, threading, channels, message inboxes, and the packaging tool is also great. I just recently published my first application to the Racket package repo, and I found it to be the least painful experience so far.

R is pretty pointless though. Unless you want to rewrite everything between prototyping in R and real deployment with a real language, you are better off writing in Python.

That right there is what I am talking about. I make a point and people have to attack that that the language is pointless when it is the number one language in that domain, which just happened the last two years.

Why would you ever have to rewrite the code? Python isn't faster and has less function then R and if you want you can just drop a few lines of Python in a cell of a Notebook. I like Python and its a good choice but R is a great language that in fact that Python's pandas library is trying to make a R equivalent.

R is useful only more in pure analysis - interfacing to other systems and dealing with application/control logic is not it's strong point, so unless you are embedding R into a larger project (e.g. R batch scheduler), if you need these features, you'll likely need to rewrite.

>I make a point and people have to attack that that the language is pointless when it is the number one language in that domain, which just happened the last two years.

That's not true though, R doesn't have anywhere near the ecosystem that Python does for Natural Language Processing, Web Frameworks, Machine Learning, Computer Algebra and Symbolic Reasoning, Systems Programming, Image Processing, Document Processing, and other things I don't know about but if I needed something else then I can use Python confidently that there will be good packages for them with a community around it.

The entirety of R's unique mindshare is that it has a million variations on linear regression and contingency table tests. And frankly they're all so simple to implement that if you can't be bothered to learn how to implement it in 2 lines of Python then you probably don't know what your program is actually doing.

R is something that caught on because it made its statistics package top-level, saving keystrokes for statistics and bio-statistics professors who never needed anything else and didn't know how to otherwise program. It's unique syntax has lead their poor students to have to learn C-family syntax many years after they could have been working and being productive with it.

Now some companies are accommodating R for their entry-level data scientist positions in order to hire cheaper help that can't find better options, but their skills are limited by being disconnected from the rest of the programming world in both packages and syntax.

> That's not true though, R doesn't have ...

Your comparing a general purpose language and a domain specific language.

Domain specific just talking in statistics and data science. I don't need a webframe work I need to make my report and have the charts work. I also push out my reports in Word and PowerPoint and I can't do that in Python but I can in R with ReportR library (The whole reason why I left Python and Pandas and came to R)

I say if you want to do more then the domain specific then sure Python is an awesome language and you can use your Python skills for more, but if you want the extras that the domain specific language gives you come on board.

To say R is a "Pointless Language" is very troll like especially with companies spend millions of investment and infrastructure that have come to R in the last 24 months.

I could also say what I always say about Python. It is the World's Great Second Best Lanaguge. It doesn't do anything "best", but it is a awesome second best and if that is fine with you have fun. I love Python but I also see the limits of the language. I thought 15 years ago Python would revolutionize everything and everything would be written in it. We now have Lua that took over for game scripting. We have C++ still ruling the day for applications. Web development has been dominated by JavaScript and Mobile development and Python is well .... So the two largest platforms aren't really impacted by Python.

> Now some companies are accommodating R for their entry-level data scientist positions in order to hire cheaper help

http://www.datasciencecentral.com/forum/topics/what-pays-mos...

http://www.kdnuggets.com/2015/05/r-vs-python-data-science.ht...

It isn't a clear picture but NO way is Python dominating in pay or work. R is a GREAT language and so is Python but for some weird reason Python community hates on R. While the developers of R and Python respect and work with eachother and help both sides. I am shocked you feel Python is so over powerfully awesome.

Nope, it has new problems that are (IMO) worse.

I have dabbled in Common Lisp over the years and am quite comfortable with it. I know nothing about Clojure. What are the problems with Clojure? I am just curious. Thanks!

Usually, people tend to see the following problems:

* no native support, hosted language (js java)

* unreadable (java) tracebacks

* no tail call optimization

These are not my problems with Clojure, but then things I often read. I am interested in Common Lisp because of the native support.

I prefer loop/recur to TCO. You know exactly when you are, and are not, in tail position (which can be a bit obscure) and the compiler won't let you recur from non-tail.

loop/recur handles only a tiny part of TCO.

TCO means all calls in tail position are optimised, not just the self-recursive ones.

Personally I find loop/recur ugly. It's a partial hack around the lack of TCO.

Though I prefer looping statements like Common Lisp's ITERATE, whose design I like a lot...

https://common-lisp.net/project/iterate/doc/index.html

To add to what @macco said: No reader macros. Apparently this extraordinarily powerful tool violates a religious principle with the inventor Rich Hickey.

If it was powerful enough to warrant use, someone would hack it onto tools.reader. It's obvious where it would go. For some reason, nobody has bothered with this. Likely because the reader already has programmable data (via tagged literals) and anything beyond that results maintaining your own special reader.

I haven't yet encountered somewhere that I'd have used reader macros for that wasn't better solved by using data literals or tagged literals. There might be some random place where I need syntax beyond clojure's data literals, but I'm far more likely to use a combination of data literals + tags. If absolutely required (it hasn't been yet in 5 years of daily production usage), I could simulate custom grammar using clj-antlr and a macro. If, for some unknown reason, I needed a custom non-sexp grammar embedded in my lisp that I wanted to serialize exactly and then read back in the same syntax (probably because I hate myself and/or my team), I could hack it tools.reader.

tldr; you have reader macros if you want them. Nobody wants them who uses Clojure day to day. If they did want them, they could trivially extend tools.reader themselves.

Virtually nothing requires reader macros. That doesn't mean they aren't useful.

Personally if I wanted reader macros in clojure I wouldn't bother implementing them because it wouldn't be worth the pain to me. However, if clojure had them I/libraries would likely make good use of them.

It has a reader as a library. It's entirely possible for you to change its lookup map to a defmethod and go to town altering s-expressions for arbitrary syntax if you wish. You're not hacking a new reader here, you'd refactoring something that probably should have been a generic method to begin with into one. Nobody has bothered with this because it's not useful to anyone, as far as I can tell. People who want non-data syntax write it with clj-antlr/instaparse (which are very easy to use) and use a macro when they want to interleave it into their code. These universally end up with a data-based AST that is readable and printable.

In addition to the other problems described, Clojure just breaks the value of Lisp's syntax. Common Lisp does have its irregularities but code littered with Java imports and square brackets might as well just use C formatting and be done with it.

The primary value, to me of Lisp syntax is that code is represented as data structure literals which can be manipulated as easily as any other data structure prior to execution. Clojure has that; it just comes with literals for a few more data structures and uses two of them, vectors and maps in the syntax of built-in forms.

Why would arguments in Lisp (= "list processor") form a vector?

Is it so that the syntax of vectors can be used? Then it has technical consequences.

Is it because of technical issues (arguments are vectors internally) and thus it can be exposed in the syntax, too?

Or both?

I think the motivation for making the sequence of arguments in function/macro definitions vectors instead of lists was primarily syntactic - to make them look different from the body. They're definitely vectors internally though.

How do square brackets break the syntax? Aren't they just syntactic sugar for (vector ...), exactly the same as ' is syntactic sugar for (quote ...)?

And imports, obviously, are just special forms. It's not like Lisp doesn't have others. It's still an S-expression, so why is it problematic?

If you know Common Lisp reasonably, you'll probably have some insight into Clojure, e.g. Leiningen is a system definition facility; seq is an extension of sequences; and multimethods are generics much like methods. I'd say Clojure stands on the shoulders of giants.

There are some Lispy things that Clojure does out of the box that are more Lispy than than Common Lisp does out of the box, e.g. lists and other seq's as functions in the function position of an x-expression. There are things Clojure will not do such as reader macros. Clojure's syntax is a bit different, but generally reads cleaner in the same way one might say a font reads cleaner. YMMV.

> lists and other seq's as functions in the function position of an x-expression.

Makes code more difficult to read. I consider this a language design error. I had that on the Lisp Machine 30 years ago (example callable arrays, ... - maybe even Maclisp in the 70s had it), few people used it and it did not make it into Common Lisp.

Common Lisp was designed such that for the programmer and for the compiler the first element of a Lisp form is easily recognisable as a function: it has to be a symbol naming a function or an actual lambda expression.

Pays back it code maintenance over time...

> but generally reads cleaner in the same way one might say a font reads cleaner.

I think it reads cleaner in the way PERL code is read cleaner.

Personally, I find code easier or harder to read in the same ways I find prose easier or harder to read -- it depends on the author's ability to tell a story and the story the author is trying to tell and my interest in hearing the telling.

Seq's as functions are sometimes more readable to me for the same reasons code that uses reader macros may be more readable to me (even though reader macros may do away with normal s-expression syntax entirely). But again, mileage varies.

Arrays are functions, by definition. They relate inputs to outputs.

That does not mean I want them in a programming language to be functions.

I guess I just don't see a disadvantage. An array is a pure function, no side effects, so it should always be safe to treat it as one.

One disadvantage: you can't inline the code for such a vector reference, unless the compiler knows at compile time that this is a vector reference.

But this is true for anything that's in the callee position, right? Either it can be determined (possibly via static flow analysis) that it's a particular function, in which case it is inlined; or else it is an unknown function, in which case it won't be. It would seem that statically verifying that something is a vector reference isn't really harder than doing the same for a function, all else being equal.

if a Common Lisp compiler sees a call to cl:aref then it can inline it, without using static flow analysis or similar...

I was under the impression that CL compilers already had to do a lot of fairly complicated static analysis to achieve acceptable performance, because of dynamic typing.

Depends. Since the developer can use low-level functions and provide type declarations, a compiler can generate usefully fast code without too much work. More advanced compilers need less declarations, since they do some amount of type inference. One of the costs: the compiler then usually is quite a bit slower.

Sorry, there is a temporary ban on speaking about clojure in OP's thread. This discussion is about Common Lisp.

But it has many other problems.

Reply on news.ycombinator.com