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.
