JavasScript as a first language

[Chris Koerner]

John, y u no pick Java?  ;)

http://ejohn.org/blog/javascript-as-a-first-language/

"At Khan Academy we've been investigating teaching Computer Science to students in some new and interesting ways. The most interesting aspect of which is that we're likely going to be teaching them JavaScript as their first language..."

[Ricky Clarkson]

class Main {
public static void main(String[] args) {
System.out.println("Java is really really poor for students
entirely new to programming, and the public static void nonsense you
see here is part of the reason.");
}
}

Yes, I have taught people Java, and they got past this particular
issue. Python, Perl, JavaScript, Scala (ahem), and pretty much any
language with a REPL is better. Actually we can take Scala out of
that list, as I think worrying about types isn't useful for novice
programmers unless there is a strong mathematical background.

PHP, even with a REPL, would be crap; the error messages, when they
exist, are useless. Perl is a bit dubious because it doesn't default
to strict and warnings, but I suppose a little script would fix that.
I suppose Ruby would be ok if it can keep up with your keystrokes. ;)

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/javaposse/-/kynwmjakcrUJ.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to
> javaposse+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.

[Cédric Beust ♔]

I used to think that Python is a good first language but these days, I agree that Javascript is superior in many ways, starting with the tooling and the fact that the only installation you need to get top notch tools is Chrome or Firefox.

John mentions a lot of positive points for Javascript but I didn't see the following two:

• Instant gratification. Make a few modifications, press refresh and you see the result right away.
  
  
• No types. I think it's a positive when you are just beginning because 1) you can do away with some rabbit hole noise and 2) the errors you will get because of type errors will force you to understand your code better. Extra bonus: you will appreciate statically typed languages even more.

-- 

Cédric

--

[Cédric Beust ♔]

I forgot one important point in favor of Javascript: JQuery (which is amazing).

-- 

Cédric

2011/12/21 Cédric Beust ♔ <ced...@beust.com>

[Reinier Zwitserloot]

Fantastic. It's the 'duh!' language I ALWAYS name when someone asks me where they should start. 

Java is a _horrible_ 'my first programming language':

* You need to sprinkle a boatload of magic pixie dust over your source before it works (that would be 'public class X { public static void main(String[] args) { .... }}' and even 'System.out'). If you try and explain this right from the start you're going to spend 5 weeks explaining things with the programmer-to-be not writing a single line. If you know anything about didactics you know this is a very bad way to teach things. (You really gonna tell your student about 'out' being a public static field on the System class? Really? I didn't think so. I sure hope not. Would be very confusing!)

* Even if you accept the magic pixie dust as given, it's very discouraging because you lack that feeling of 'I know how this works now'. You keep thinking: I know a few things but I can't really grok even 'Hello, World' because who the heck knows what all this magic pixie dust is for?

* Java is very much not designed for first steps. It lacks useful shortcuts ('new BufferedReader(new InputStreamReader(new FileInputStream("foo.txt"), "UTF-8")) is great, fantastic even, in a serious project, but really quite the drag if you're just trying to play around.

* REPLs are pointless in real life (go away, Kevin), the java IDEs have debuggers that can do everything a REPL does for serious work and more... EXCEPT for first steps programming language, for the same reason: It's perfectly feasible for me to tell some programming whinging about a lack of a REPL for java to go spend a week or two becoming an ace at the eclipse debugger and then reapply for the job, or whatnot. It's completely inappropriate to tell a first-steps student to try to make heads or tails of one.

A thing or two for this could be fixed by creating a custom environment (BlueJ tries this, more or less), but then it's not really 'real java', and you get that feeling of 'I don't REALLY know anything yet', which is very detrimental to learning.

Contrast this to javascript, which is more or less simple, and you get instant and immediate payoff. You get a fantastic REPL (load up a webpage, hit the 'patch jquery into this thing' bookmarklet, then open up the webkit console and go nuts), everybody has everything they need to just start out (a webbrowser), and the payoff of "I'm making real, life, useful stuff and I just started learning this stuff 3 days ago!" is palpable.

Really - this, or logo. Any other choice, including python, is stupid, IMO.

[Ricky Clarkson]

Python's only worse than JavaScript according to your criteria in that
you generally need to install it if you're on Windows. Is that why
it's a stupid choice?

> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/javaposse/-/E0MhSRQUvaIJ.

[Cédric Beust ♔]

On Wed, Dec 21, 2011 at 9:00 PM, Ricky Clarkson <ricky.c...@gmail.com> wrote:

Python's only worse than JavaScript according to your criteria in that
you generally need to install it if you're on Windows.  Is that why
it's a stupid choice?

Python has a lot of syntactic decorum that will be hard to explain to beginners. Actually, some of it is just plain impossible to explain even to seasoned developers (why do you have to declare a method with three parameters yet call it with two?).

It also doesn't have this very fast feedback loop of running queries on the web browser console and seeing your web page react instantly. The only language I can think of that offers such a rewarding and positive feedback loop is Logo.

-- 

Cédric

[Fabrizio Giudici]

Frankly I think that JavaScript as first taught language is a horrible
choice, just as it would be Java. C is still the best option IMHO, but in
the end any traditional language that gets compiled into native code is
ok. Abstraction is good, but only after you've completely understood
what's under the hood. If a language has got a "WOW" factor, it's a very
bad choice as the first taught language.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Kevin Wright]

* REPLs are pointless in real life (go away, Kevin), the java IDEs have debuggers that can do everything a REPL does for serious work and more... EXCEPT for first steps programming language, for the same reason: It's perfectly feasible for me to tell some programming whinging about a lack of a REPL for java to go spend a week or two becoming an ace at the eclipse debugger and then reapply for the job, or whatnot. It's completely inappropriate to tell a first-steps student to try to make heads or tails of one.

 

In true xmas panto fashion: "Oh no I shan't"

If somebody complained about the lack of logging in a codebase, would you also send them off to go and become an expert in the debugger.  Or if they complained about the lack of Lombok support when the team uses IntelliJ, would they have to go and become expert at writing IntelliJ plugins?

All the best initial-learner languages have REPLs.  Logo, Scheme, Smalltalk, Scala (via Kojo, anyway, it's a modern day Logo - see Cay Horstmann's blog for more info).  They're not just for learning either, I can think of numerous experiences *every day* where I've been able to explore an algorithm faster and in more depth by way of a REPL.  I find it hard to understand how someone can claim - with a straight face - that they're agile when also accepting 2min+ redeployment times against some web server to iteratively solve a problem.

 

Contrast this to javascript, which is more or less simple, and you get instant and immediate payoff. You get a fantastic REPL (load up a webpage, hit the 'patch jquery into this thing' bookmarklet, then open up the webkit console and go nuts), everybody has everything they need to just start out (a webbrowser)

Yay, go REPLs!  I do exactly this when "serious work" is required on a website.

 

Really - this, or logo. Any other choice, including python, is stupid, IMO.

Okay, Logo, it has a REPL and it's a good choice.  I'm in violent agreement.

REPLs are a beautiful feature for any language.  The immediate feedback that they offer learners is just as useful for experienced programmers in rapid prototyping and diagnostics for much larger "enterprise-level" systems.  Don't knock 'em!

 

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Kevin Wright]

Total rubbish.  We must start with a solid grounding in VLSI design and the core principles of modern processor architecture - paying particular attention to pipelining, branch prediction, virtual addressing and shared memory schemes in a multi-core design.  Then progress onto raw machine code.

Only after that should something as high-level as C be considered.

Anything else is just a slippery slope, before you know it we'll have people expecting to be able to drive without having rebuilt so much as a single engine!

</flippancy>

On Thursday, 22 December 2011, Fabrizio Giudici wrote:

Frankly I think that JavaScript as first taught language is a horrible choice, just as it would be Java. C is still the best option IMHO, but in the end any traditional language that gets compiled into native code is ok. Abstraction is good, but only after you've completely understood what's under the hood. If a language has got a "WOW" factor, it's a very bad choice as the first taught language.

--

[Carl Jokl]

One shame with JavaScript is its limited approach to being able to
include or import other libraries. In a web page though as long as the
JavaScript tags are in the right order so that they are included
properly it may not be such an issue.

I suppose people need to start with something simple. I would hope
thought that they would move on to something more powerful eventually.
I think the industry is tending to churn out far to many mediocre
programmers these days. As much as starting with C was a really tough
learning curve, it is good for separating the wheat from the chaff in
terms of those who have the aptitude to be good programmers rather
than just mediocre ones. I am glad at least that we aren't talking
about teaching using VisualBasic. It is one thing hiding detail for
simplicity and another to use a language that teaches bad programming
style.

[Fabrizio Giudici]

On Thu, 22 Dec 2011 10:07:32 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> Total rubbish. We must start with a solid grounding in VLSI design and
> the
> core principles of modern processor architecture - paying particular
> attention to pipelining, branch prediction, virtual addressing and shared
> memory schemes in a multi-core design. Then progress onto raw machine
> code.
>
> Only after that should something as high-level as C be considered.
>
> Anything else is just a slippery slope, before you know it we'll have
> people expecting to be able to drive without having rebuilt so much as a
> single engine!
>
> </flippancy>

Misused flippancy, I'd say. :-) I'm not expected to be the guy who builds
the car, but as the guy who drives it I should know what happens when I
drive it pushing to the limits, for instance using a lower gear than the
manual says (americans please find another appropriate example). In fact,
what's happening now with cars stuffed with technology is that people are
fine in 90% of cases, but get helpless in unusual conditions. If you
answer by pointing out the fucking manual, that's academia, because
manuals won't explain how to behave in very unusual (and maybe unexpected)
conditions.

In fact, I'm constantly seeing new generations of engineers that have been
only taught with fun high level languages being totally unable not only to
understand a trivial cause of a performance hit, but even lacking the
mental tools to investigate it (which is truly a disaster). Just because
they are unable to go under the hood for the required amount (which is not
of course understanding VLSI, but the basics such as machine instructions,
memory, caches, hits and misses, stacks, heap, compiler optimisations,
etc...). This is blatantly demonstrated by the more and more frequent blog
posts where people present a surprising result of a micro-benchmark, just
to be debunked in a few minutes when somebody points out that they just
understand nothing about how the JIT works...

[Kevin Wright]

Slightly less flippant then... I *would* draw an analogy between someone being expected to crank-start a car, and someone expected to roll their own reference-counter / garbage collector.

Mechanics nowadays will begin on engines with a starter motor, the only difference compared to "mere drivers" is that they learn how the thing works so they can fix it if broken.  Raw physical labour to turn over the engine is no longer an expected part of attaining that knowledge.

Even as just a driver, there's a world of difference between what a stunt driver must learn and what a normal road user must learn.  We certainly don't start people on a skid pan before progressing to teach the 3-point turn, knowledge of unusual circumstances is *always* taught after the first 99% of common driving use-cases.

I consider advanced low-level work in C to be "stunt programming".  Amazing cool and powerful, but too focused and dangerous for most programming needs.

I'll just run off now to teach my kids how this abacus works.  We'll be progressing to calculators next month :)

On Thursday, 22 December 2011, Fabrizio Giudici wrote:

--

[Fabrizio Giudici]

On Thu, 22 Dec 2011 11:01:52 +0100, Kevin Wright
<kev.lee...@gmail.com> wrote:

> I consider advanced low-level work in C to be "stunt programming".
> Amazing
> cool and powerful, but too focused and dangerous for most programming
> needs.

I didn't talk of advanced low-level work in C. We were talking of the
"first taught language", right?

[Ricky Clarkson]

Python does have a REPL, the rest depends on the libraries you use.

I had lots of fun using Python's REPL to send commands to a camera that guides tank operators to fire at the right thing before putting the thing together as a wxPython GUI and distributing it. The GUI itself generated a Python script that when run would repeat the operator's actions.

Not being security-certified, my company wasn't even able to know what programming language was to be used in the final version, so I chose Python for its readability and it surprised me even then. The whole thing was less than 3 screenfuls of code.

As opposed to JavaScript or C, Python lacks the awkward moment you get when you ask 'ok, how do I write files?' or 'how can I create a graphical window?'. Batteries included.

---

From: Cédric Beust ced...@beust.com

Sender: java...@googlegroups.com

Date: Wed, 21 Dec 2011 22:15:51 -0800

To: <java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: Re: [The Java Posse] Re: JavasScript as a first language

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

[Dick Wall]

As is often the case Reinier - you seem to have got your enthusiasm making statements that are far to over general.

Here is the history from my development machine (not one of the ones I use for Scala training) along with the number of times I have started the scala REPL

dick@Apollo:~$ history | wc -l

500

dick@Apollo:~$ history | grep scala | wc -l

31

dick@Apollo:~$ history | grep "sbt console" | wc -l

40

I am a pretty experienced Scala developer now, with about 3 years behind me, and I start the Scala REPL to try stuff out every day I am developing, often several times a day (assuming I don't just leave it running constantly). REPLs are far from pointless in real life, and I would not want to use a language without one. Prior to Scala, I used to use Python every chance I got and I used to (and still do) fire up the python shell at the drop of a hat to try out some idea or other. A REPL may not appear to be all that useful to you, maybe because you are used to using languages that don't offer one, but that doesn't make it true for everyone else.

Incidentally, sbt console starts up the current project with all jars and classes in the project already on the REPL class path. Combined with tab completion in the Scala REPL, it is an excellent way of trying out ideas and exploring unknowns, like interactively experimenting with third party ReST web services (I practically developed our interface to confluence this way, using the REPL to send requests and explore the resulting XML until I got what I needed) or just getting a feel for a new API.

I don't use it as my only tool, and I don't doubt that you don't find them interesting, but I also can't let a statement like "REPLs are pointless in real life" when I use them all the time.

Dick

[Russel Winder]

On Thu, 2011-12-22 at 08:42 -0800, Dick Wall wrote:
[...]

> I am a pretty experienced Scala developer now, with about 3 years behind
> me, and I start the Scala REPL to try stuff out every day I am developing,
> often several times a day (assuming I don't just leave it running
> constantly). REPLs are far from pointless in real life, and I would not
> want to use a language without one. Prior to Scala, I used to use Python
> every chance I got and I used to (and still do) fire up the python shell at
> the drop of a hat to try out some idea or other. A REPL may not appear to
> be all that useful to you, maybe because you are used to using languages
> that don't offer one, but that doesn't make it true for everyone else.

[...]

I would suggest though that REPLs are far more useful to people who
already know a language for doing experiments, than it is for teaching
people. My experience is that teaching using a REPL rather than
file/execute leads to confusions that get in the way of learning. I
believe the GroovyConsole /IDLE model far superior to REPL for teaching
learning.

Sadly though it seems REPL use is assumed to be the way all books should
be presented for teaching people to use a language with a REPL. I
always prefer books that eschew the REPL, at least initially, for
teaching.

I am a fan of REPLs for quick experiments, but ignore them for teaching,
which seems to be the antithesis of the standard orthodoxy on teaching.

--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel...@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: rus...@russel.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder

[jon.ki...@gmail.com]

"I'll just run off now to teach my kids how this abacus works. We'll be progressing to calculators next month :)"

they'll certainly learn a lot more from the abacus than they ever will from the calculator! Don't forget the slide rule...
(very useful if you're planning on teaching them about how exponents work)

----- Reply message -----
From: "Kevin Wright" <kev.lee...@gmail.com>
Date: Thu, Dec 22, 2011 5:01 am
Subject: [The Java Posse] JavasScript as a first language
To: "java...@googlegroups.com" <java...@googlegroups.com>

Slightly less flippant then... I *would* draw an analogy between someone being expected to crank-start a car, and someone expected to roll their own reference-counter / garbage collector.

Mechanics nowadays will begin on engines with a starter motor, the only difference compared to "mere drivers" is that they learn how the thing works so they can fix it if broken.  Raw physical labour to turn over the engine is no longer an expected part of attaining that knowledge.

Even as just a driver, there's a world of difference between what a stunt driver must learn and what a normal road user must learn.  We certainly don't start people on a skid pan before progressing to teach the 3-point turn, knowledge of unusual circumstances is *always* taught after the first 99% of common driving use-cases.

I consider advanced low-level work in C to be "stunt programming".  Amazing cool and powerful, but too focused and dangerous for most programming needs.

I'll just run off now to teach my kids how this abacus works.  We'll be progressing to calculators next month :)

On Thursday, 22 December 2011, Fabrizio Giudici wrote:

On Thu, 22 Dec 2011 10:07:32 +0100, Kevin Wright <kev.lee...@gmail.com> wrote:

Total rubbish.  We must start with a solid grounding in VLSI design and the
core principles of modern processor architecture - paying particular
attention to pipelining, branch prediction, virtual addressing and shared
memory schemes in a multi-core design.  Then progress onto raw machine code.

Only after that should something as high-level as C be considered.

Anything else is just a slippery slope, before you know it we'll have
people expecting to be able to drive without having rebuilt so much as a
single engine!

</flippancy>

Misused flippancy, I'd say. :-) I'm not expected to be the guy who builds the car, but as the guy who drives it I should know what happens when I drive it pushing to the limits, for instance using a lower gear than the manual says (americans please find another appropriate example). In fact, what's happening now with cars stuffed with technology is that people are fine in 90% of cases, but get helpless in unusual conditions. If you answer by pointing out the fucking manual, that's academia, because manuals won't explain how to behave in very unusual (and maybe unexpected) conditions.

In fact, I'm constantly seeing new generations of engineers that have been only taught with fun high level languages being totally unable not only to understand a trivial cause of a performance hit, but even lacking the mental tools to investigate it (which is truly a disaster). Just because they are unable to go under the hood for the required amount (which is not of course understanding VLSI, but the basics such as machine instructions, memory, caches, hits and misses, stacks, heap, compiler optimisations, etc...). This is blatantly demonstrated by the more and more frequent blog posts where people present a surprising result of a micro-benchmark, just to be debunked in a few minutes when somebody points out that they just understand nothing about how the JIT works...

--
Kevin Wright
mail: kevin....@scalatechnology.com
gtalk / msn : kev.lee...@gmail.com

quora: http://www.quora.com/Kevin-Wright

google+: http://gplus.to/thecoda

twitter: @thecoda

vibe / skype: kev.lee.wright

steam: kev_lee_wright

"My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra

[Ricky Clarkson]

I don't know, I bought an abacus for my one-year-old and she just uses it as a rattle.

She can move on to calculators when she stops smashing things against the ground.

I'm not teaching her how exponents work, she's not ready for that kind of power.

---

From: "jon.ki...@gmail.com" jon.ki...@gmail.com

Sender: java...@googlegroups.com

Date: Thu, 22 Dec 2011 13:10:21 -0500

To: java...@googlegroups.com<java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: Re: [The Java Posse] JavasScript as a first language

[Matthew Farwell]

As Josh Suereth pointed out to me, you can do this with maven as well:

mvn scala:console

which starts the repl with all of the classpath filled in etc. You can also use this for exploring java projects, but obviously with a scala syntax.

Cordialement,

Matthew Farwell.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/KNnGpvO8rE8J.

[Andrew]

Baptism by fire using maven I'd say.

Something like this might be cool for your first programming
experience;

groovyconsole.appspot.com/

No install, no wait for massive dependency downloads...

On Dec 23, 4:50 pm, Matthew Farwell <matt...@farwell.co.uk> wrote:
> As Josh Suereth pointed out to me, you can do this with maven as well:
>
> mvn scala:console
>
> which starts the repl with all of the classpath filled in etc. You can also
> use this for exploring java projects, but obviously with a scala syntax.
>
> Cordialement,
>
> Matthew Farwell.
>

[Matthew Farwell]

Just to clarify, I was talking about for an existing project. So I've already downloaded all the dependencies.

I wasn't talking about the first programming experience, I wouldn't recommend maven for a first programming experience :-)

Cordialement,

Matthew Farwell.

[Reinier Zwitserloot]

This is just not didactically sensible. That's not how you get people excited. Unexcited people don't learn well.

And, in re: Ricky Clarkson's comment about Python, well, Cedric covered it.

[Reinier Zwitserloot]

This post doesn't even make sense. What in the flying blazes do logging frameworks have in common with REPLs vs. advanced debuggers? The only thing I can imagine is that you do not see that debuggers and REPL have rather a lot in common, but, then, being completely obtuse is something I've grown to expect of you. As is piping up when nobody wants to hear it.

The fact that you then start whining about having a 2m+ turn-around for 'some web server' further suggests you just don't know what an advanced debugger can do, so, there's not much point replying to anything else other than:

Go use an advanced debugger. Fire up your webserver setup in the debugger and just write some new code, or highlight (or type) any expression. the expressions are evaluated 'live'. The code you change is integrated 'live'. If need be a debugger will even rerun the frame. 2m+ turnaround time? No. Type, hit cmd+s, cmd+tab,cmd+r. If it's some sort of live ajax callback whatnot, no need for the reload.

[Reinier Zwitserloot]

On Thursday, December 22, 2011 5:42:12 PM UTC+1, Dick Wall wrote:

As is often the case Reinier - you seem to have got your enthusiasm making statements that are far to over general.

Here is the history from my development machine (not one of the ones I use for Scala training) along with the number of times I have started the scala REPL

dick@Apollo:~$ history | wc -l

500

dick@Apollo:~$ history | grep scala | wc -l

31

dick@Apollo:~$ history | grep "sbt console" | wc -l

40

Sure, that sounds about right. I open my scrapbook (which is the exact same thing as a REPL, just not called a REPL - you've apparently missed the point but I'll get into that next paragraph) about a tenth as often as you do, but then, java is easier to understand so there's less for me to try out.

Here's where you missed the point. Yes, what REPLs do is very handy. But I don't have to use a spoon to eat soup; I can use a spork as well.

java has no REPL. But eclipse has scrapbook pages. These do everything REPLs do and more. It's almost exactly like sbt console in that I get the project's classpath 'for free'.

Now, don't get me wrong, the eclipse scrapbook functionality has boatloads that needs to be done. Having to be a wizard at using command line foo to select expressions so I can evaluate them is frankly ridiculously (enter should just eval the expression I just typed, or at least give me a shortcut key to do it, exceptions shouldn't be pasted straight into the scrapbook but shown in the console view, etc, etc, etc), but learning an all new language just because the scrapbook functionality bothers you seems rather drastic. It would be easier to write an entirely new scrapbook plugin for eclipse!

I stand by my point that a REPL, as compared to java's advanced debuggers, is a pointless addition except as a teaching tool. I have _NEVER_ met any person that continued arguing in favour of scala / python / some other language with built in REPL that actually knew how to use the eclipse / netbeans / intellij debugger well. Then again I don't think I ever asked specifically on the javaposse groups, so maybe somebody's out there who can tell me what I'm missing.

[Kevin Wright]

On 24 December 2011 15:19, Reinier Zwitserloot <rein...@gmail.com> wrote:

On Thursday, December 22, 2011 5:42:12 PM UTC+1, Dick Wall wrote:

As is often the case Reinier - you seem to have got your enthusiasm making statements that are far to over general.

Here is the history from my development machine (not one of the ones I use for Scala training) along with the number of times I have started the scala REPL

dick@Apollo:~$ history | wc -l

500

dick@Apollo:~$ history | grep scala | wc -l

31

dick@Apollo:~$ history | grep "sbt console" | wc -l

40

Sure, that sounds about right. I open my scrapbook (which is the exact same thing as a REPL, just not called a REPL - you've apparently missed the point but I'll get into that next paragraph)

So you can write a small program in the scrapbook, to test a concept?  You can use it as a system scripting language with no more than a shebang at the top of a file? It can easily specify and pull in dependencies? (http://stackoverflow.com/a/7286545/165009)  It's a natural and obvious place to start a complete newcomer with their very first "Hello, world!" example?

These are very natural and obvious things to have in any REPL that was a part of the language from conception.  Not so much when it's a poorly-appreciated part of an ide-specific "advanced" debugging framework.

... about a tenth as often as you do, but then, java is easier to understand so there's less for me to try out.

Just as Duplo is easier to understand than Lego Mindstorms, but that's really just an indicator of the circumstances where you'd choose to use Mindstorms.  Stop trolling.

 

[Jon Kiparsky]

I actually don't see how Python is more exciting than Java - just my two cents, but it sounds to me like you're assuming that your students have no attention span. In my experience as a teacher, I've found that students tend to respond to such expectations by meeting them.

I'm not saying that Python isn't a good first language, there may be good arguments for that, but I don't think that the REPL argument is one of them. It's easy enough in Java to get immediate results. You can put the student into an IDE, and for anything they're going to write, they have instant one-step compile, so that's not a problem. Or, more responsibly in my view, you can put them in an editor and switch between two sessions for the edit-compile process. This is a two-step compile process - and if that's a deal-killer, you need to redirect that student - but it avoids one layer of magic between them and what's really happening. It also allows them to make lots of mistakes, which is the only way they'll learn anything at all worth knowing.

I don't really have a fierce position on which language you teach first, I think Java is reasonable, but I know people who started in all sorts of languages and they turned out okay. I started with perl, for Pete's sake, and I'm no worse for it. But I do think that this approach is a little worrying, because it seems to suggest that it's more important that the beginner be able to get something to happen than that they learn what makes it happen. Maybe I'm mis-interpreting the argument, but that's how it comes across to me.
Best
-jpk

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/phiQVx2GWEcJ.

[Dick Wall]

OK - let's see if I can get this straight.

On Saturday, December 24, 2011 7:19:53 AM UTC-8, Reinier Zwitserloot wrote:

]Sure, that sounds about right. I open my scrapbook (which is the exact same thing as a REPL, just not called a REPL - you've apparently missed the point but I'll get into that next paragraph) about a tenth as often as you do, but then, java is easier to understand so there's less for me to try out.

REPLs are useless, but something not called a REPL built into eclipse is super-useful and you use it all the time despite being an experienced java developer. The only difference seems to be the name. I would posit that I am not the one who missed the point here.

 

Here's where you missed the point. Yes, what REPLs do is very handy. But I don't have to use a spoon to eat soup; I can use a spork as well.

I use a spoon, always, to eat soup. Even camping. It's just a better tool for the job. I don't think I missed a point. You said REPLs were useless for anything except beginners. I said they were not. You seem to back up my position with scrapbooks.

 

java has no REPL. But eclipse has scrapbook pages. These do everything REPLs do and more. It's almost exactly like sbt console in that I get the project's classpath 'for free'.

Great, just like the REPL. As you mention below though, you still can't interact with the scrapbook as easily as with the REPL. It would be a bit like using a text editor for issuing shell commands at the command line, and having to select those lines to evaluate them one by one. Sure, you can do that, but why on earth would you want to?

 

Now, don't get me wrong, the eclipse scrapbook functionality has boatloads that needs to be done. Having to be a wizard at using command line foo to select expressions so I can evaluate them is frankly ridiculously (enter should just eval the expression I just typed, or at least give me a shortcut key to do it, exceptions shouldn't be pasted straight into the scrapbook but shown in the console view, etc, etc, etc), but learning an all new language just because the scrapbook functionality bothers you seems rather drastic. It would be easier to write an entirely new scrapbook plugin for eclipse!

I would agree that learning a new language just because your current one doesn't have a REPL is nonsense, but that is not related to your original statement that a REPL is useless for anything but beginners. Using eclipse to clean freshly caught fish is equally nonsensical, but that doesn't have anything to do with the original point either.

 

I stand by my point that a REPL, as compared to java's advanced debuggers, is a pointless addition except as a teaching tool. I have _NEVER_ met any person that continued arguing in favour of scala / python / some other language with built in REPL that actually knew how to use the eclipse / netbeans / intellij debugger well. Then again I don't think I ever asked specifically on the javaposse groups, so maybe somebody's out there who can tell me what I'm missing.

 

So the REPL is still a pointless addition even though it provides a slicker more interactive experience to experimenting with APIs and the language than scrapbooks, and scrapbooks are awesome except when they're not. Got it. Clear as crystal.

As for never meeting any person who continued to argue in favor of scala/python/some other language with a built in REPL that actually knew how to use the eclipse/netbeans/intellij debugger well? I would say you know me. I am that person and I do still argue in favor of it. Of course I use the debuggers in IDEs as well, I bring every tool I can to bear on a project that will get me to the answer more quickly. The REPL is certainly in that toolbox, as is unit testing, debugging, profiling, static analysis, reading books, being open to other peoples ideas, etc.

So, now you have met someone that has clearly made that observation. Maybe there are some others on this list who would say the same. Certainly Guido would, he seems very keen on python, and the shell is a big part of Python's value proposition, even though pydev and other tools give you a pretty nice debugger as well. 

To be even clearer, I use the REPL in addition to all of the other tools you mention here (apart from the scrapbook in eclipse, cos I don't use eclipse, but IDEA as you mention has similar features). I can even start the sbt console in IDEA, and try stuff out right from there, it's still the same REPL I always use, just with more colors. Tell you what, let's call it a scrapbook and we can all agree - it is Christmas after all.

Dick

[Ricky Clarkson]

I think the point is to maximise the chances that the student enjoys and continues programming, rather than worrying that they might be missing low-level concepts, etc., at least in the first instance.

---

From: Jon Kiparsky <jon.ki...@gmail.com>

Sender: java...@googlegroups.com

Date: Sat, 24 Dec 2011 11:47:10 -0500

To: <java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: Re: [The Java Posse] Re: JavasScript as a first language

[Alex Turner]

I can definitely say the REPL has helped learning Scala, where sometimes the IDE doesn't quite "get" the syntax 100%, and I needed to poke it a bit.  Scala's syntax is a bit obscure at times (particularly for a n00b), so for me, the REPL is pretty handy.  I recall a poll on slashdot asking what people used as a calculator and the python shell was one choice, more than a few picked it, including myself.  The javascript console in Webkit is also pretty damn handy.

As far as a teaching tool goes - I know I'm always learning new stuff, even on a language I already have familiarity with -- there are still parts I'm not about to just spew out 100% rote, so I guess, despite originally thinking that I didn't find REPLs all that useful, I'm finding myself defending them, realising I use them more than I thought.

Thinking about it, at some point the line between debugging and learning gets blurred.  If you created a program that doesn't work, you have to learn what went wrong, or you see that the original structure was sub-optimal and you have to come up with a new approach, sometimes requiring the use of new structures or techniques that can be explored either within the context of debugging or within a REPL.

I'm not sure a REPL is really the foremost argument for picking a language as a starter language.  I think even a simple choice can depend on the audience, have you ever seen a math PhD write Java for the first time?  It's madness, they should have been handed Scala or another functional language - it would have been less torture on the poor developers who came after!  The nine year old who is curious might perhaps not do so well with C either, but perhaps for an undergrad it might be a good choice where they have a structured lecture series where they can come to grips with the "pixie dust" with some assistance.

Alex

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To view this discussion on the web visit https://groups.google.com/d/msg/javaposse/-/PeYU_KRIVSAJ.

[Cédric Beust ♔]

On Sat, Dec 24, 2011 at 11:59 AM, Dick Wall <dick...@gmail.com> wrote:

REPLs are useless, but something not called a REPL built into eclipse is super-useful and you use it all the time despite being an experienced java developer.

I believe Reinier said that even though Eclipse has scrapbook pages, he hardly ever uses them. Neither do I.

I do use Eclipse's "Display" view *all the time* because when I need to try a piece of Java code, it's hardly even in a brand new state: I need a lot of context, fields initialized, the program in the right state, etc... In other words, I use Display inside a breakpoint all the time.

I haven't run a rigorous analysis but I'm pretty sure that when I want to test a piece of Java code, 90% of the time, a REPL would simply not just cut it: only a breakpoint would.

Like Reinier said, it might have something to do with the fact that the complexity is shifting between Java and Scala. Java's code is straightforward, so anyone with just a few years of experience will have quickly outgrown the need to experiment with standalone pieces of code. However, Java code inside programs can be gnarly, and that's where the Display view and the debugger come in handy.

Scala is different: it's not just live code that can be hard, but standalone code as well, so maybe there's more need to test standalone code with it.

I'm almost tempted to say that the necessity to use a REPL so often is a smell in a language. Almost.

But it's elf time, not troll time, so I'll leave it at that.

Happy holidays everyone.

-- 

Cédric

[Cédric Beust ♔]

On Sat, Dec 24, 2011 at 11:59 AM, Dick Wall <dick...@gmail.com> wrote:

Great, just like the REPL. As you mention below though, you still can't interact with the scrapbook as easily as with the REPL. It would be a bit like using a text editor for issuing shell commands at the command line, and having to select those lines to evaluate them one by one. Sure, you can do that, but why on earth would you want to?

Actually, I've always found the "line" aspect of all REPL's very limiting. Even if you use advanced shell functions such as ^r or specific language assistance like Scala's paste mode, editing in a REPL quickly becomes a chore when you are working on a piece of code that's more than a few lines long and which you need to refine evaluation after evaluation.

From this perspective, I think a free form window with real editor support like Eclipse's Display view is more powerful, although it does suffer from the shortcomings that Reinier described.

Emacs' interpreted modes come closer to the ideal blend between a REPL and the Display view, but it's still awkward to work in them. And to be honest, I'm really not quite sure what the ideal UI for such work would be.

-- 

Cédric

[Cédric Beust ♔]

On Sat, Dec 24, 2011 at 8:47 AM, Jon Kiparsky <jon.ki...@gmail.com> wrote:

I'm not saying that Python isn't a good first language, there may be good arguments for that, but I don't think that the REPL argument is one of them. It's easy enough in Java to get immediate results.

Agreed. And I also agree that immediate results are extremely important to get beginners excited. Much more important than pretty much anything else I can think of. The first weeks are decisive to ignite this spark, and this should be priority #1 of the instructor.

Like I said before, I think that Javascript scores extremely high in this aspect, probably higher than any other language.

You sit students in front of an HTML page that you have prepared, show them first how to edit some HTML and press refresh. Instant result. Very gratifying.

Then you ask them to edit some CSS. Refresh. Elements change color. Instant results.

Then you make them display an alert in Javascript when the page loads. Instant result.

Then you have them put a breakpoint (any of Chrome, WebKit or Firefox will do, they're all excellent). Magic, the code stops there, and they can navigate through the objects (probably a bit early for that though). Even better, they can modify these objects. Neat, but no visual results on the page yet.

Then you have them type a simple JQuery ($('.banner').attr('class', 'selected') and blam, the banner appears.

Then you extend this to JQueries that touch several selectors at the same time and the page lights up like a Christmas tree.

Languages that have some native graphic support are nice, but in this day and age, I think starting with web pages is the way to go.

-- 

Cédric

[Jon Kiparsky]

I suppose it depends on the student, and what they consider a good "immediate result". I've never been very excited by the world wide whatever, and web programming has always seemed more of a bore than anything else. When I make something happen with jQuery, I can admire the work that went into making it happen, but I never feel like I've done anything particularly interesting myself. This could never be exciting to me - might be to others, though. I acknowledge the likelihood that I am eccentric in this.
But if you picture a kid learning woodworking and carpentry, I'm the kid who's much more excited by the birdhouse I made myself than I would be with the product of a birdhouse-making machine. Even if my birdhouse was off-kilter and dubiously sound of structure, it'd be mine, and that's what I'd be excited by. A perfectly-made bird mansion produced by the push of a button would be boring to me.
Java seems to me to offer more latitude for building birdhouses than javascript, to me, but that's probably because I'm not as familiar with javascript. If you're teaching people how to make birdhouses, and not just how to operate automated birdhouse-makers, then I think we're in substantial agreement, whichever language you use.

Happy Newtonmas to all! May your bodies in motion remain in motion.

2011/12/25 Cédric Beust ♔ <ced...@beust.com>

-- 

Cédric

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

[Steve Lindsay]

On Dec 25, 4:12 pm, Cédric Beust ♔ <ced...@beust.com> wrote:
>
> I'm almost tempted to say that the necessity to use a REPL so often is a
> smell in a language. Almost.
>

I think repl usefulness is a function of coding style. Can't comment
on Scala (never used it), but in Clojure a function I can't test in
the repl is usually a code smell. If it requires too much setup, lots
of predefined state, etc. then I've usually written a function that
should be refactored.

No snark intended but I'd be interested to know how many of the
opinions being expressed here are based on actual experience, rather
than theorising.

- Steve

[Fabrizio Giudici]

On Fri, 23 Dec 2011 17:36:13 +0100, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> I think the point is to maximise the chances that the student enjoys and
> continues programming, rather than worrying that they might be missing
> low-level concepts, etc., at least in the first instance.

Excitement must be put in the proper perspective. Excited people about fun
languages who don't understand fundamentals have higher chances to become
useless and not making a great career (that's not exciting). I think that
there's a pedagogical value in properly focusing excitement: it's more
valuable to be excited because you are able to create something that
works, rather than the tool that you used.

Not to mention that at the university not all classes were exciting to me.
For instance, math-based ones were boring to me (to me maths is
fascinating, but not something I'd like to do, such as mountaneering).
Still I worked hard and got almost always the maximum marks. It's a good
thing that people is taught to apply also to boring parts, because they
can't be eliminated by the real life.

[Ricky Clarkson]

"Excited people about fun languages" have more chances of becoming
useful than "bored people about boring languages", because they're
more likely to continue. There are many many people who studied
programming as part of some other course and have the idea that it's
about fighting with a compiler, or taking a professor's solution and
modifying it to make it work without touching the predefined bits. Or
as in the course I studied, that programming is about remembering that
int/int gives int, and the syntax of a for loop.

Plenty of perfectly capable people avoid programming because of dull
or overly difficult initial presentation, and Java is part of that
problem. One of my colleagues is perfectly capable with Perl and is
now learning Java because the client wants him to, so he wrote
something trivial and had to learn about exceptions and static before
he was going to be interested in them. He's not put off, but I
remember when I was teaching, that as soon as you had to involve
exceptions to load an image file, eyes started to glaze and it was a
battle to bring them back to full interest.

[Ricky Clarkson]

Running a Scala REPL within emacs is quite pleasant in that regard, as emacs' shell-mode is very capable. But sure, REPLs can benefit from tooling.

---

From: Cédric Beust ced...@beust.com

Sender: java...@googlegroups.com

Date: Sat, 24 Dec 2011 21:20:05 -0800

To: <java...@googlegroups.com>

ReplyTo: java...@googlegroups.com

Subject: Re: [The Java Posse] Re: JavasScript as a first language

[Jon Kiparsky]

Ricky, it sounds to me like you're complaining more about bad teaching than about languages. I can assure you that java need not be taught badly.

Every language has syntax, of course, and you always have to learn it. Lisp folks insist that Lisp "has no syntax", and then presently you come to the loop constructions, which are far worse to learn than anything in Java. Python fans insist that it's as natural as breathing, but I remember having to learn how to make it work, and there's plenty there that's idiosyncratic and just downright weird. So I still don't see how your arguments against java hold up, or that you're making a case for any particular language (as opposed to just making a case against Java).

I'd really, really like to hear what you have to say in favor of python, or any language, as a first language. I think I understand now that you don't like Java, and that's fine, but what is it about python that makes you think it's brilliant to learn first off? Is it just that it's so simple, or is there anything about it that opens up a student to more insights about programming? (I can think of a couple of ways I'd make this case, but I'd like to hear you make it)

[Simon Ochsenreither]

Hi,

I think the main point is that teaching with a REPL has some benefits not easily simulated by an IDE:

• It works like math in the sense that later lines of definitions are based on earlier ones. That's exactly what people still know from school and it gives them a familiar feeling.
• It gives them a feedback at every step, for every single line and enforces them to solve a problem before moving on to the next. No "There are red squiggles, but let's ignore them, right?" This is a MASSIVE issue.
  
• Earlier definitions and solutions are implicitly available and solve the problem of "should I define a new class for task A?"/"how can I use method B in both C and D"/...
  

Compared to working in an IDE,

• where even the installation can be painful and
  
• doing basically anything requires them to first configure IDE specific stuff they neither understand nor care about at that moment
• which encourages copy-and-paste behavior along the line, especially in less than modern languages like Java
• which does way too much for an beginner

Imho everything depends on the goals.

Do you want to teach concepts? Stay away from IDEs until the concepts are understood.

Do you want to teach Eclipse? Sure, go on, but please be honest about it. I have seen to many "text processing courses" which more or less were instructions on how to find some menu entry in Microsoft Office 2003, while 95% of the participants lacked _any_ idea of concepts like "where to use headings/bold/italic/different fonts"/"how to use quotation marks"/"what's the purpose of footnotes"/"how to decide on consistent style guidelines"/...

Teaching with an IDE feels a bit like those office courses, because people are basically bound to spend most of their time fighting with IDE-related problems and issues.

In the end I think languages without a stand-alone REPL/interpreter/... lack some important tooling. Some languages are not that REPL-friendly, but even C# has one. So I think there aren't much excuses except laziness.

In the end I think JavaScript has some nice properties as a first language, but also suffers from the issues as PHP does: Most of the existing code out there is just horribly outdated, wrong, or often both and as a teacher you don't want your students to look at it. Teaching JavaScript without internet access though, sounds very weird.

Bye,

Simon

[Cédric Beust ♔]

On Sun, Dec 25, 2011 at 9:25 AM, Simon Ochsenreither <simon.och...@googlemail.com> wrote:

In the end I think languages without a stand-alone REPL/interpreter/... lack some important tooling.

There are a few obvious counter examples: Java has great tooling but ships without a REPL (but it has several kinds available as third party, as discussed before) and Scala has mediocre tooling but ships with a REPL.

I don't think REPL has much to do with tooling.

Some languages are not that REPL-friendly, but even C# has one. So I think there aren't much excuses except laziness.

Or usefulness. I don't think a lot of Java developers feel a burning need for REPL, including people who actually know what a REPL is. It's just never been seen as important enough to ship as part of the distribution.

 

In the end I think JavaScript has some nice properties as a first language, but also suffers from the issues as PHP does: Most of the existing code out there is just horribly outdated, wrong, or often both and as a teacher you don't want your students to look at it. Teaching JavaScript without internet access though, sounds very weird.

Not sure why, it's very easy to teach a whole Javascript course without any connection to the Internet, as I showed in my teaching example earlier.

-- 

Cédric

[Simon Ochsenreither]

Hi,

In the end I think languages without a stand-alone REPL/interpreter/... lack some important tooling.

There are a few obvious counter examples: Java has great tooling but ships without a REPL (but it has several kinds available as third party, as discussed before) and Scala has mediocre tooling but ships with a REPL.

I'm still impressed how you try to transform every thread into some Scala bashing exercise, while blaming others for it.

I don't think REPL has much to do with tooling.

 

If the REPL isn't tooling, how would you categorize it then? Aren't you pretty much trying to exclude it from "tooling" based solely on the reason that Java isn't good at it?
 

Some languages are not that REPL-friendly, but even C# has one. So I think there aren't much excuses except laziness.

Or usefulness. I don't think a lot of Java developers feel a burning need for REPL, including people who actually know what a REPL is. It's just never been seen as important enough to ship as part of the distribution.

That makes as much sense as claiming that teaching how to read is unnecessary because the students probably don't possess any books yet. For additional fun, replace "REPL" with "closures".

 

In the end I think JavaScript has some nice properties as a first language, but also suffers from the issues as PHP does: Most of the existing code out there is just horribly outdated, wrong, or often both and as a teacher you don't want your students to look at it. Teaching JavaScript without internet access though, sounds very weird.

Not sure why, it's very easy to teach a whole Javascript course without any connection to the Internet, as I showed in my teaching example earlier.

I didn't say it isn't easy. It just sounds weird teaching "the programming language of the internet" while restricting access to it.

Bye,

Simon

[Reinier Zwitserloot]

Messing with trite stuff of any sort, especially if it HAS to passed off as magic pixie dust for progress' sake, is bad, because when you're learning something its very annoying if you can already tell right from the start you're not even seeing the whole picture.

I'm taking it as axiomatic for a moment that teaching a student all about what 'static' means and such (in order to fully understand Hello, World!) _before they're let loose to write the simplest stuff imaginable_ is somewhere between criminal and retarded.

Heck, forcing OO principles is already annoying.

[Reinier Zwitserloot]

On Saturday, December 24, 2011 8:59:31 PM UTC+1, Dick Wall wrote:

REPLs are useless, but something not called a REPL built into eclipse is super-useful and you use it all the time despite being an experienced java developer. The only difference seems to be the name. I would posit that I am not the one who missed the point here.

Yes, they are a useless addition to a language provided there's already an advanced debugger, scrapbook tool, etc, available. Java _HAS_ that, therefore trying to sell scala as 'it has a REPL!' is not a good way to sell it, as that has zero upside compared to what java has, _except_ for teaching. That's the one area where I grant that a REPL has actual use. Note that advanced debuggers are _more_ useful than REPLs, which is why I said REPLs are useless. They are worse than the alternative and the alternative can do everything REPLs can do (except, more or less, to serve as a learning environment, an important omission).

If I created the impression that REPLs are useless because what they _do_ (let you type expressions and instantly see the results as you go) is useless, then I created the wrong impression.

I use a spoon, always, to eat soup. Even camping. It's just a better tool for the job. I don't think I missed a point. You said REPLs were useless for anything except beginners. I said they were not. You seem to back up my position with scrapbooks.

Scrapbooks are the proverbial spoon here vs. repl's spork, if you want to stress this analogy to its breaking point. advanced debuggers do all REPLs do and more (they inherit project classpath by default, work with full colourization, auto-complete, etc, the same way my IDE does things so I don't have to learn two environments, and as I can just add a breakpoint in the middle of a live, running app and then jump into evaluating whatever I want to evaluate, it's just easier to try and figure out what my code is doing compared to trying to fire up a REPL, then loading my app and trying to manually reconstruct breakpoint features).

 

(more on how eclipse's scrapbook feature has some gaping holes in it).

Yes, how unfortunate. Fortunately for eclipse, fixing those holes is a matter of hours (how hard could it be to add CTRL+ENTER = evaluate everything I wrote since I last asked you to evaluate stuff). Making scala's REPL a full breakpoint-capable debugger is a dozen man years. Unfortunately for us, team eclipse doesn't seem to give a toss. Which is strange, but reflective of Joe Java's opinion. Now why would that be? I just don't know. Why does Joe Java not care about any of this? I'd have a very hard time indeed trying to write large projects in a language that has no usable debugger.

I would agree that learning a new language just because your current one doesn't have a REPL is nonsense, but that is not related to your original statement that a REPL is useless for anything but beginners. Using eclipse to clean freshly caught fish is equally nonsensical, but that doesn't have anything to do with the original point either.

I don't want a REPL. I want an advanced debugger. If I can't have the latter I'll take all the scraps (i.e., a REPL) I can get, but I wont be happy about it. That's what I meant with 'REPLs are useless'. I probably should have made more clear that I meant this in the context of java (and 'REPL' in the context of what python and scala provide).

So the REPL is still a pointless addition even though it provides a slicker more interactive experience to experimenting with APIs and the language than scrapbooks, and scrapbooks are awesome except when they're not. Got it. Clear as crystal.

Yup. Except the part where REPLs are slicker and more interactive. They aren't, with the sole exception of eclipse's particular implementation of the idea having a very curious lack of a convenient key for 'evaluate everything I typed since I last asked you to evaluate things'. Right now it's a 2-key combo shortcut, though fortunately muscle memory picks it up quickly. It's the scrapbook page that is vastly slicker and more interactive. It will fit in seamlessly in my project (picking up classpath, letting me call into it, letting me open the scrapbook page and then start evaluating expressions I wrote down earlier in the context of the current breakpoint, etc). These are hard things to add to scala's REPL doohickey. Conversely, adding 'ctrl+enter means evaluate what I just typed' to eclipse's scrapbook thing is very easy. Right now it's CMD+SHIFT+LEFT followed up by CMD+SHIFT+U on my machine. Hmm, can I make 1 keyboard shortcut that does two things? Something I'll be checking out after I finish writing this post!

 

As for never meeting any person who continued to argue in favor of scala/python/some other language with a built in REPL that actually knew how to use the eclipse/netbeans/intellij debugger well? I would say you know me.

Well, that's one, touché.

 

To be even clearer, I use the REPL in addition to all of the other tools you mention here (apart from the scrapbook in eclipse, cos I don't use eclipse, but IDEA as you mention has similar features). I can even start the sbt console in IDEA, and try stuff out right from there, it's still the same REPL I always use, just with more colors. Tell you what, let's call it a scrapbook and we can all agree - it is Christmas after all.

If you abstract the features of a REPL to a sufficiently high level, I'm fairly sure we do end up concluding that what scrapbook is trying to do and what REPL is trying to do is the exact same thing, just different ways to get there.

Happy holidays :)

[Simon Ochsenreither]

Hi,

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... :-)
 

Note that advanced debuggers are _more_ useful than REPLs, which is why I said REPLs are useless. They are worse than the alternative and the alternative can do everything REPLs can do (except, more or less, to serve as a learning environment, an important omission).

Comparing debuggers with a REPL is like 99% missing the point.
 

I use a spoon, always, to eat soup. Even camping. It's just a better tool for the job. I don't think I missed a point. You said REPLs were useless for anything except beginners. I said they were not. You seem to back up my position with scrapbooks.

Scrapbooks are the proverbial spoon here vs. repl's spork, if you want to stress this analogy to its breaking point. advanced debuggers do all REPLs do and more (they inherit project classpath by default, work with full colourization, auto-complete, etc, the same way my IDE does things so I don't have to learn two environments, and as I can just add a breakpoint in the middle of a live, running app and then jump into evaluating whatever I want to evaluate, it's just easier to try and figure out what my code is doing compared to trying to fire up a REPL, then loading my app and trying to manually reconstruct breakpoint features).

Pretty much not having to start a whole IDE isn't a minor thing, imho. 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) ...
 

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.

I don't want a REPL. I want an advanced debugger.

Great, just use a debugger then. It is not like REPL and a debugger are even remotely used for the same thing.

I'm still not sure if this is advanced trolling or meant serious ... whatever, good job!

Nice holidays,

Simon
 

[Reinier Zwitserloot]

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?

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.

 

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.

 

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.

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.

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.

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.

 

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.

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.

[Kevin Wright]

On 25 December 2011 22:05, Reinier Zwitserloot <rein...@gmail.com> 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. 

[Ricky Clarkson]

If I'm complaining about bad teaching then it's my *own* bad teaching
I'm talking about, and I wouldn't say I taught Java particularly
badly, though there were definitely things I'd have liked to have
improved upon.

That Lisp has no syntax is more related to the directness between lisp
source code and an AST. LOOP is just a macro and isn't particularly
hard, but I was by no means a beginner when I met it, and I've never
watched a beginner programmer try to use it. It's so similar to LINQ
that I imagine the beginner experience to be similar, and from
watching the ##csharp IRC channel for a few months it seemed that
beginners didn't have great problems with LINQ.

My argument against Java is just as a first language. It's less
direct, more awkward and involves concepts before the novice is ready
to meet them.

Novices generally struggle with static, with having to switch syntax
entirely to go from arrays to Lists, with using 3rd party libraries,
with the difference between public X() and public void X(), with
checked exceptions, and probably a lot more if I rack my brains for
longer. What I dislike is that they generally have to meet these
before they're ready to unless they follow a very narrow path.

A language that doesn't force everything to go in classes is probably
easier to begin with, and Python doesn't even force everything into
procedures, nevermind classes. You can directly use everything in the
language without having to worry about those things until you need
them. It's much less likely than Java to force 'forward references',
i.e., learning about a concept you don't yet care about or aren't
ready for.

Does that help?

By the way, I didn't say I don't like Java. It's fine, it has some
features I miss elsewhere and lacks some features I'd like it to have.
It's a big improvement on the previous status quo, C/C++, especially
in terms of simplicity of compilation/linking.

[Jeb Beich]

Is this argument about the value of REPL vs IDE in general, or in the context of teaching someone a language?

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.

To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.

--
Jeb Beich
http://www.red-source.net/jeb

[Oscar Hsieh]

Come on people, why do we have to turn every single language thread into Java vs Scala????  Its getting really annoyed and we all know like any religion no one will convert the other just by arguing.  If you want to have a good useless infinite loop example for the next contest then this is it :)

I like both Scala and Java.  Java has been my language of choice for 10 years and it is getting old.  I really like the function aspect of Scala and its conciseness but on the other hand Scala sometime feels unnecessary complex and the tooling sucks.  I do not have any problem to work on project with either language.  Currently I am experimenting using Scala with Wicket and they seems to work well together. 

Personally I dont care about REPL.  I spent a good 9 months of this and last year working on Erlang (hate it, not the functional part but the dynamic part), I probably spent total of 2 hours on REPL when I was learning the basic stuff.  After that I just use the Erlang eclipse plugin and I will trade good debugger with REPL any time any day.  I mean every developer that I work with have eclipse running all the time, most of time I actually have two instances running (different project different workspace).  Experimenting in Eclipse is really not as bad as some of you said.  I can see others have different experience though.

I am not sure why we spend so much time arguing about languages?  At the end of the day does language have that much impact to the end product???  Is PHP a superior language because Facebook uses it???  I understand that people tend to favor one language over the other but there is no need to trash the other language.  I hate Erlang to the bone but I know it has its strength and respect people who love it. 

Maybe we should spend more time to talk about actual technology.  Does no-sql movement lost steam (have not heard about it for a while)? HTML5.  Javascript libraries such as node.js and backbone.js.  Javascript/Coffescript vs dart.  Gosh even Android vs IOS is probably better than this.

Oh ... to the OP I agree that Javascript can be a great first language.  I have been working with Javascript a lot recently and the simplicity and instant feedback are great plus to get people in.  Once in they should learn other language.  I can see people have problem to write good OO code if they stay in Javascript for too long. 

Happy holidays to you all!!!!

[Reinier Zwitserloot]

On Monday, December 26, 2011 6:21:23 AM UTC+1, Oscar Hsieh wrote:

Come on people, why do we have to turn every single language thread into Java vs Scala????

HIs name is Kevin Wright. I should have ignored him, I apologize.

 

[Ben Smith-Mannschott]

Hmm.

My main worry in choosing JavaScript as a first language is that the
language is something of a mess, but it is a well understood and
widely used mess. (Were I the instructor, I'd lean heavily on "Java
Script: The Good Parts".)

A beginners language should make it easy to get immediate feedback for
incremental changes and not require too much scaffolding. I think
JavaScript could be presented this way. If a language provides a
REPL, it can also be leveraged for quick feedback. Even a more
traditional compiled language can be used in this way if the compiler
is fast and simple.

I started with Logo (though I was too young at the time to remember
any of it), BASIC, HyperTalk and Pascal. The first two were
interactive interpreters ("REPL"). Basic was unstructured, but didn't
do any permanent harm. HyperTalk gave quick feedback ("instant
gratification") despite not having a classical REPL. (It did have the
"message box", does that count?) Pascal worked fine too because the
compiler was very fast, which kept the edit-compile-run-debug cycle
short.

In the end, I'd have to conclude that more depends on the student and
the instructor than the choice of language. I see no reason why
JavaScript couldn't work well, given a good teacher.

// Ben

On Wed, Dec 21, 2011 at 20:45, Chris Koerner <ches...@gmail.com> wrote:
> John, y u no pick Java?  ;)
>
> http://ejohn.org/blog/javascript-as-a-first-language/
>
> "At Khan Academy we've been investigating teaching Computer Science to
> students in some new and interesting ways. The most interesting aspect of
> which is that we're likely going to be teaching them JavaScript as their
> first language..."

>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/javaposse/-/kynwmjakcrUJ.

[Alexey Zinger]

I know it's piss-poor for most people in this thread, but I'll give these 2 things a shout-out anyway in case it does benefit someone:

1. Bean Shell (http://beanshell.org): Java superset (with caveats), interpreter/REPL
2. Bean Sheet (http://bsheet.sf.net): Bean Shell-based spreadsheet.  In the interest of full disclosure, it's my baby.  If you hate it, I won't be offended, but I will say that I use it every day from REPL-like duties (prototyping, sanity checking, etc.) to certain heavy lifting spreadsheet duties.  I can definitely see using it as a programming teaching tool as well.

 

Alexey

---

From: Ricky Clarkson <ricky.c...@gmail.com>
To: java...@googlegroups.com
Sent: Sunday, December 25, 2011 8:51 PM

Subject: Re: [The Java Posse] Re: JavasScript as a first language

>> > javaposse+unsub...@googlegroups.com.

>> > For more options, visit this group at
>> > http://groups.google.com/group/javaposse?hl=en.
>> >
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "The Java Posse" group.
>> To post to this group, send email to java...@googlegroups.com.
>> To unsubscribe from this group, send email to

>> javaposse+unsub...@googlegroups.com.

>> For more options, visit this group at
>> http://groups.google.com/group/javaposse?hl=en.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to java...@googlegroups.com.
> To unsubscribe from this group, send email to

> javaposse+unsub...@googlegroups.com.

> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.

--
You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.

To unsubscribe from this group, send email to javaposse+unsub...@googlegroups.com.