Earlier quoted context omitted.
Which years are in the decade the Twenties?
Which days are in a Month? You dont start with june 0th and end with june 29th?
I would if I could!
A newcomer’s (angry) guide to R
211–220 of 232 posts
Re: A newcomer’s (angry) guide to R
#212Earlier quoted context omitted.
Which days are in a Month? You dont start with june 0th and end with june 29th?
I would if I could!
I may as well amuse myself here:
My ideal calendar has 12 30 day months, days 0 to 29.
If it's 10th June and you have an appointment for 0 August, that's 50 days from now.
At the end of the year, a 5 or 6 day 'month' called Holiday. 30th December becomes Christmas Day (observed) and 0 January is still New Years. New Years Eve is either 5 or 6 Holiday.
6 Holiday would be a lot of fun. ^_^
Re: A newcomer’s (angry) guide to R
#213Earlier quoted context omitted.
Another feature for this audience is the philosophy that functions shouldn't have side effects. You can still do (several types) of object oriented programming in R, but it does take away some of the ways in which non-programmers shoot themselves in the foot. I've come to really like the way environments work in R, as well.
A sane language shouldn’t need three different object systems.
Meh, S3 is nice and lightweight for a very particular kind of analysis interoperability. S4 isn't super useful IMHO. RC is very well thought out, and I've heard good things about R6. It might not be sane language design, but it works well for designing very different kinds of analytical procedures.
Re: A newcomer’s (angry) guide to R
#214As a long-time R user, I agree with all of these complaints. The language itself is ugly and actively tries to get in your way. I'll add that concepts like data frames are not really intrinsic, and you get needless complexities like "length", "nrow", "dim", each of which does the wrong thing in 90% of the scenarios of interest. The confusion of lvalues is another strange quirk -- a If you discipline yourself to learn…
> I'd love to see a NeoR arise at some point that fixes the strange historical inconsistencies […] in non-backward compatible ways.
Microsoft (or perhaps the Apache Foundation) could pull such a trick, and win a huge user base by doing so.
My guess is that several top R developers must have also thought of doing so, esp. those who write C code for R.
Re: A newcomer’s (angry) guide to R
#215Earlier quoted context omitted.
> Tidy features (like pipes) are detrimental to performance. But they are some absolutely amazing features to use. After helping my wife learn R, and learning about all the dypler features, going back to other languages sucked. C#'s LINQ is about as close as I can get to dypler like features in a main stream language. Of course R's data tables and data frames are what enable dypler to do its magic, but wow what magic…
I think your autocorrect mangled up your `dplyer`s :)
Hah! I even looked it up, then typed it wrong.
I keep trying to type something that is actually pronounceable! ;)
Re: A newcomer’s (angry) guide to R
#216Earlier quoted context omitted.
Could you please elaborate on that? My company has tons of python code producing reports with reportlab, making UIs with PyQt5, as well as a multitude of small scripts to interact with MySQL. We’ve been nothing but happy with Python in the years of using it.
"I 've done it so it's not so bad" is not a very good argument. I've done a significant data science project in Prolog (with R for the plotting btw) but that doesn't mean Prolog is the go-to language for data science :)
But it is a datapoint against the hypothesis "Prolog is inappropriate for data science".
Re: A newcomer’s (angry) guide to R
#217Earlier quoted context omitted.
I am always amazed when I hear that people use Python in any type of production pipeline.
Could you please elaborate on that? My company has tons of python code producing reports with reportlab, making UIs with PyQt5, as well as a multitude of small scripts to interact with MySQL. We’ve been nothing but happy with Python in the years of using it.
Mainly because production pipelines care a great deal about performance (speed) and Python is generally considered to have worse performance in comparison to compiled languages (Java or C++.) Depending on your pipeline that may not be a big deal.
Re: A newcomer’s (angry) guide to R
#218Earlier quoted context omitted.
That's ironic because I find Julia's documentation to be the second most clear documentation I've seen (after elixir). Notation wise, Julia is the most comfortably close to mathematics (APL is closer, but it's a write only language). I'm not a working mathematician, though i did graduate with a rather theory based math degree.
The documentation is fine but IMO written more for developers. We do need more mathematical-based introductions which introduce the right packages for working mathematicians. I am a working mathematician myself and find Julia to be the perfect language for it because its abstraction is on actions instead of on data representations which fits things like functional analysis extremely well. Things that are OO based lik…
I've written a custom GF256 data type and used Julia's builtin matrix solves (note: required monkey patching in Julia <~ 0.6 because there were one and zero literals in the builtin solver) to do Reed Solomon erasure coding... It's glorious.
Re: A newcomer’s (angry) guide to R
#219TL;DR. I just have two things to say:
R worshippers: "To a man with a hammer, everything looks like a nail." Interactively manipulating tables and producing visualizations is not what software engineers/programmers on HN would call "programming". Try learning a compiled programing language like C and creating a tool or three.
R haters: "It doesn't matter whether the cat is black or white, as long as it catches mice." Remember, R was designed by statisticians for statisticians -- nothing more, nothing less. Try manipulating a tabular dataset and producing visualizations in R, and see how easy and painless it is. There's a good reason behind all the hype.
Re: A newcomer’s (angry) guide to R
#220Earlier quoted context omitted.
> R and Lisp are hardly alike even if it was inspire by it. It's like saying Erlang and Prolog is very similar. If you want learn FP do it in Erlang, Lisp, Haskell, etc.. Don't do it in R, it's half baked. They are very alike in the underlying core design, not in how you use them. In R, everything is an expression, and every expression is a function call. Even things like assignments, if/else, or function definitions…
R certainly has a lispish code-as-data element to it, but it seems like it has some serious flaws. Don't most lisps have functions and macros as separate constructs? R has functions, but with some mucking around you can make them do macro-type stuff. Then people write these half-function, half-macro things (e.g. "non-standard evalation") that tend to break composability, either totally or sometimes only in edge cases…
Lisps do that distinction because they need it. In R, you can do everything with functions, because arguments can be lazily evaluated, or you can even get the syntax tree used for that argument at call site instead. So in R, a macro is just a function.
And yes, it's easy to break stuff that way. Just as easy as it is with macros (esp. non-hygienic ones).