RStudio is really nice! I'm taking some Coursera classes using R, and RStudio is great. Maybe that's because I'm an IDE kind of guy: using Cursive for Clojure, PyCharm for Python, RStudio for R, etc.
On Thursday, April 2, 2015 at 5:54:34 PM UTC-4, Jony Hudson wrote: > > I think the credit here has to go to RStudio for doing such a good job of > making an easy to install complete development environment. I'd say just > comparing base Clojure to base R, it's a wash. Install java and either > download the Clojure jar, or the leiningen script, and you're good to go. > Similar effort with R, just install the R distribution. Either way you > don't get much more than a REPL prompt. > > It is possible to get a working, fully-featured Clojure development > environment going without *much* more difficulty than RStudio. In fact, I > did precisely cover install and setup in two easy videos :-) See > http://gorilla-repl.org/videos.html , bottom of the page. > > I would still say that RStudio deserves kudos here though, as they've made > it really easy to get going. And I think there is value in this, as my > experience with getting inexperienced programmers started is that they > easily get stuck on the little set up details. I'd like to make Gorilla > REPL easier to get started with, but haven't figured out how to do that in > a way that's compatible with the amount of time I have to work on it! > > > Jony > > On Thursday, 2 April 2015 22:14:08 UTC+1, Sayth Renshaw wrote: > > >> You appear to have vastly misinterpreted my intention regards Emacs. My >> mention of Emacs (I use emacs with prelude) was not based on my usage but >> as a perception of those who might be attracted to Clojure For Purely Data >> Science And wishes to get installed and moving quickly. >> >> R offers to get you installed in 2 quick point and click installs and >> gives you the language and R studio . >> >> What would that person think when looking at Clojure? If they saw emacs >> would they know about prelude, how to configure it with so many >> configuration options? >> >> If someone out organisation was running a data science course would they >> choose R because they can cover install and setup in 2 easy videos compared >> to current Clojure options which may be less clear. >> >> Sometimes often times onboarding people to a new language is about as >> much as ease of install or at least making a default set of optiins clear. >> >> Could the default set abs best options be made easier to new comers? >> >> Sayth >> >> Emacs can use the native windowing system on every major platform. It >> still *looks* like a terminal app, but doesn't have to be one. >> >> Pretty much everything you are saying here doesn't apply to Emacs at all, >> and you would know it's all false if you knew anything about Emacs. >> >> On Wednesday, April 1, 2015 at 4:55:08 PM UTC-7, Fluid Dynamics wrote: >> >> On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: >> >> The benefit is that Emacs is that its not constantly changing, and it >> gives you some stability over the years. I like latex, for instance, for >> the same reason. I can still access a 10 year old document and use it. >> >> First of all, there are other posts in this thread complaining about >> constantly changing stuff breaking things! One such post is by Colin Yates. >> >> Second, to the extent that it isn't changing, it is legacy. Which helps >> to explain the Wordperfect for DOS style of UI, which is dependent on vast >> numbers of complex key-combinations being memorized by the user, instead of >> a just-sit-down-and-start-using-it UI like everything originating after, >> say, 1995 or so has tended to have. Of course, the result is that >> Wordperfect (and emacs) seemed to require a great deal of specialized >> training just to accomplish even the most basic tasks, whereas with modern >> interfaces the way to do such basic tasks (save, open, copy and paste, move >> around, select, etc.) tends to be obvious and special training can focus >> exclusively on doing advanced things (scripting, complicated Photoshop >> filters and tricks, things like those). >> >> Legacy also, obviously, tends to present problems in other areas besides >> UI-boneheadedness: >> >> * I18n and l10n >> * Compatibility, with modern hardware and with modern operating systems, >> though that can be alleviated by people porting the code >> * Boneheaded internal limits, along the same general lines as "640K ought >> to be enough for anybody". It may be unable to use more than a small >> fraction of what modern hardware can offer it in the way of memory, >> storage, cores, ... >> * Accessibility. Interposing a terminal emulator between the app and >> screen reading software might cause problems, though on the other hand a >> text mode app may ultimately have advantages in that area too. On the other >> hand, it may not play well with accessibility tools >> that rely on standard UI conventions. Anything that responds to some >> voice command by generating control-V keystrokes to paste, or that relies >> on the presence of normal menus and/or mouse support is going to blow up >> spectacularly when used with 1980s-vintage Unix >> (or MS-DOS) software, or at best will end up controlling the >> xterm/Command Prompt window instead of the underlying app. >> * Interoperation with other (non-operating-system) software. On Windows >> it won't speak OLE, DDE, OCX, or etc., and copying text in it and >> attempting to paste into something else (web browser, calculator, etc.) is >> doomed to failure. This is a general problem with >> pre-window-system software, much like the stuff listed under >> Accessibility, with no easy solution. Terminal emulators tend to provide >> some way to copy from their display into the host-native clipboard, but it >> tends to be clunky (the Windows command prompt appears to >> require mouse use, with no keyboard shortcuts) and runs into the >> obvious difficulties as soon as you want to copy more than will fit on one >> screen. Ironically, really primitive stuff like ls and dir that just dump >> possibly-paginated noninteractive listings to the term are easier >> to make big copies from than text-mode, interactive applications like >> screen-oriented editors, because you can copy from the backscroll buffer of >> the terminal emulator in the first case. Pre-window-system *graphical* apps >> are the absolute worst, e.g. later, WYSIWYG >> word processor versions on MS-DOS, or pre-window-system X applications. >> No internal support for the host clipboard and, at the same time, nothing >> the emulator will recognize as text, meaning if you try to native copy and >> paste you'll end up with a PNG or something. >> OCR might work on that, if you can find cheap or free OCR software >> that's any good. Your better bet would be to save the document as some >> format that can be read by a native windowed app and then open the file in >> that, then copy, and at that point you might as well >> edit in the native windowed app and throw out the legacy cruft >> entirely, since you'll have to deal with the native app anyway, and the >> cost of switching between them constantly, reloading in the native app so >> it sees changes, and re-locating the places you want to copy >> from in the native app will quickly grow to outweigh any advantage the >> legacy app might somehow have due to some feature it has that you haven't >> found in any native app. >> >> Put more simply, there are giant costs to not playing well with others, >> and these are inevitably incurred by all applications developed prior to >> the advent of a) window systems with window managers, systemwide >> copy/paste, and etc. and b) widespread user-interface standards for common >> cross-domain tasks like save and paste. Ultimately, the costs incurred >> every time you or some data need to cross the boundary between the legacy >> application and the modern world are likely to vastly outweigh whatever few >> missing features you can find only in legacy applications and never in any >> of their modern counterparts, as moving anything across that boundary is >> likely to be fiddly at best (e.g., mark/copy from Command Prompt window) >> and require saving a file manually and manually opening it in another >> application at worst (e.g. copying text from a pre-Windows *graphical* >> version of WordPerfect into a Firefox form box to use in a blog comment or >> something.) Maintaining and learning virtual machine software is likely to >> be necessary as an additional overhead, for legacy applications that can't >> be run natively at all anymore (most pre-Windows graphical apps and >> anything that assumes it can talk directly to the hardware), and even >> terminal emulators add a smaller amount of such overhead for the user. >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/vsjUlAWm64g/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+u...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
