Is this argument about the value of REPL vs IDE in general, or in the context of teaching someone a language?
On Sun, Dec 25, 2011 at 8:05 PM, Kevin Wright <[email protected]>wrote: > > > On 25 December 2011 22:05, Reinier Zwitserloot <[email protected]> wrote: > >> On Sunday, December 25, 2011 9:51:18 PM UTC+1, Simon Ochsenreither wrote: >>> >>> Yes, they are a useless addition to a language provided there's already >>>> an advanced debugger, scrapbook tool, etc, available. >>>> >>> Doesn't that pretty much apply to Scala, too? Seems like pretty much >>> everyone having experience with a REPL and a debugger disagree with you... >>> :-) >>> >> >> I count Dick Wall so far. That's one. I'm not sure he's ready to be a >> proxy for 'pretty much everyone'. You could name 20 examples, even - I'll >> counter that with: Did you know Twilight grossed 300 million dollars? >> > > So add another in myself. I'd also be willing to bet that *most* Scala > devs are familiar with the full gamut of Java tools. The most common route > into the language seems to be from experienced developers getting > frustrated with Java's limitations and looking to up their game. > > > >> Scala had a REPL many many many years before having an advanced debugger, >> scrapbook tool, etc. As far as I know (but the scala IDE integration has >> been moving at a lightning pace of late, so this might be outdated), it >> still doesn't actually have an advanced debugger, at least, it's nowhere >> near what you can do with java. >> >> >>> Comparing debuggers with a REPL is like 99% missing the point. >>> >> >> And your paragraph ends there? It feels 99% incomplete. When I say >> somebody is missing the point, I then proceed to explain the point I >> thought they missed. Seems rude to just leave it hanging like that. >> > > Hopefully I can fill in some of the missing details... > > > >> Pretty much not having to start a whole IDE isn't a minor thing, imho. >>> >> >> It is the most trivial of trivialities. Eclipse is always open. If it >> isn't, then I'm about to open it anyway, might as well start it now. >> > > Oh no it isn't. It's very often closed if I wish to conserve memory whist > working on some aspect of artwork/design. Or perhaps if I've simply been > playing portal 2 on the train that morning. > > > >> >> >>> If I want to communicate with a webservice I want to fire up my REPL >>> and just do it. In seconds. Not waiting until Eclipse has started, creating >>> a new project in Eclipse, configuring Maven, creating a new file or >>> starting the scrapbook, setting breakpoints and running the debugger (which >>> seems to be the essential tool for you) ... >>> >> >> If you have to 'configure maven' in order to do this hypothetical >> 'communicate with a webservice' job, then you'd have to be doing the same >> thing if you were doing this in scala, python, or anywhere else. Unless >> this just turned into an argument for 'more stuff included in the standard >> libraries for platform X', which is an entirely different argument, quite >> irrelevant to the REPL discussion. >> > > Using SBT, I can define a simple project with 1 line per dependency, 1 > line to specify the target Scala version, 2 lines of boilerplate and 2 more > of whitespace. Then drop me straight into a console with the classpath > fully configured using nothing more than "sbt console". This is *so* > useful that I'll even retrofit it to legacy Java projects - either that, or > add the scala plugin to an existing maven project so I can use "mvn > scala:console". Both techniques work quite well against otherwise > pure-Java codebases. > > > This happens almost always when I talk to scala fanboys. They make a bunch >> of non sequitur statements that my pile-of-manure detector picks up on, >> stuff where scala gets a free ride when java doesn't. In this case, your >> scala REPL magically has the libraries you need but your java scrapbook >> doesn't. Does not add up. If these are the arguments you come up with, I'm >> tempted to conclude there aren't any valid ones at all and you're just >> grasping at straws. It's of course a lot more complicated than this, but >> this is just personal advice to you: You're not convincing anyone with >> arguments that contain such obvious bias. >> > > I believe you yourself are guilty of confirmation bias here. Having > decided it to be the case, you then proceed to interpret everything you > read based on the assumption. Do you honestly believe that those of us who > prefer to program in Scala against the Java platform are so clouded by some > agenda that we've lost the capacity for reason? > > > >> Do you even know what the scrapbook feature does? It's an alternative to >> setting breakpoints; it's a bit like starting a do-nothing app with a >> breakpoint right after 'main'. You obviously don't make a scrapbook AND >> fire up a debugger unless I actually want to debug an actual, live, >> existing app, and I want to eval some code snippets in the context of some >> frame or other. If I want to play around with some API we don't get to the >> breakpoint phase of things until after I eval a bunch of expressions in a >> scrapbook. >> > > A bit like this then? > http://stackoverflow.com/questions/2160355/drop-into-interpreter-during-arbitrary-scala-code-location > > Actually we can go further, and connect to a REPL on a remote machine, or > otherwise host it in an existing app - which is the basis of > http://www.simplyscala.com/ > > Better still: > http://blog.homecloud.ca/2010/03/scripster-interactive-scala-repl-using.html > No breakpoints required. > > > In fact, setting breakpoints then having REPL-like features (what's this >> thing? Eval this thing. Change this bit of code and rerun this frame, etc) >> is one of the many reasons why debuggers/scrapbooks are superior to REPLs, >> at least, in the context of 2011 java debuggers and 2011 python/scala REPLs. >> > > I trust I've already given enough counterexamples to demonstrate otherwise. > > > >>> >>>> Making scala's REPL a full breakpoint-capable debugger is a dozen man >>>> years. >>>> >>> Thanks, but no. I like my less-than-1-second start-up time. If I need a >>> "full breakpoint-capable debugger" I just use ... a full breakpoint-capable >>> debugger. >>> >> >> That's it? That's your argument? Every 2 months I have to wait a fraction >> of a minute while eclipse boots? Colour me not at all convinced, if that's >> all you can come up with. >> >> You might have the most tenuous of points if you somehow have the bad >> fortune of being stuck on 5 year old hardware, but I'm not exactly on a >> racehorse here and I have zero issues with this. Heck, I'm on one of the >> slowest computers for sale when I bought it (early air 11"): 21 seconds to >> launch eclipse. Just enough time to pick out a playlist. >> >> If you're running into trouble on this front, I suggest you just leave >> eclipse running. I do. Months on end. >> > > I often work on multiple projects, this eclipse startup cost is incurred > every single time I switch workspaces. Furthermore, the memory burden gets > a bit silly if I need multiple consoles running e.g. when I'm debugging two > or more interacting components being run in distinct JVMs. A REPL is > *considerably* more lightweight here. > > > >> Great, just use a debugger then. It is not like REPL and a debugger are >>> even remotely used for the same thing. >>> >> >> That's where you're wrong. I use a debugger to do REPL-like things all >> the time. The scrapbook feature of eclipse is an afterthought of the >> debugger's featureset (why don't we make some concept where the debugger >> will attach to a dummy JVM that does 1 NOP with a breakpoint on it and >> allow you to eval/execute stuff in that one 'blank' frame? - That's it. >> That's ALL the scrapbook thing does). >> >> I'm still not sure if this is advanced trolling or meant serious ... >>> whatever, good job! >>> >>> Nice holidays, >>> >>> >> Same to you buddy, on both accounts. >> >> > Ramen, > May the flying spaghetti monster touch wou with his noodly goodness during > this festive season. > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Jeb Beich http://www.red-source.net/jeb -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
