Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Friday November 04 2016, @07:09PM   Printer-friendly
from the choose-logically dept.

We've had this question asked before I believe but it does no harm in asking it again and again. After all, opinions change as does the software ecosystem. Quincy Larson of FreeCodeCamp.com asked this question via Medium: What programming language should you learn first? He thinks JavaScript is the way to go and his arguments are cogent and well thought out. However, I am somewhat hesitant to suggest someone learn to code in JavaScript first. My first programming language (in 1981!) was Fortran on a Control Data mainframe. The interactive environment the OS provided was pretty simple and the language provided few opportunities to hang yourself. JavaScript, by comparison, while it may not have those evil pointers of C/C++, it offers functional features and plenty of rope to hang oneself.

So, opinions please.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by Marand on Friday November 04 2016, @11:31PM

    by Marand (1081) on Friday November 04 2016, @11:31PM (#422676) Journal

    There's some merit to this suggestion, but not because of your trial-by-fire logic. If you want someone to get interested in programming, they need a language that lets them do something useful and interesting. That means you want a "batteries included" type of language that comes with a lot of useful stuff out of the box. A language like that lets you dive in and start doing something useful with less time and code, so you get to that "FUCK YEAH! I MADE A THING!" rush sooner.

    If you have to fuck around with a bunch of libraries, language-specific package managers, and frameworks before you can even consider doing something useful, you're more likely to go "fuck this dumb shit" and find something else to do. That's the problem with teaching JavaScript, in my opinion, because you have to jump through a bunch of hoops to get anything useful done. The huge blob of overengineered shit that is JS + DOM + HTML + CSS just puts up hurdles between the programmer and the end result. Workarounds involve frameworks, but then you replace the original set of hurdles with new ones. When you're a beginner, you tend to know what you want to do but have no idea how to make it happen; you know you need the batteries but not what they're called. With a language like JavaScript, you end up with a massive pile of batteries and no idea which ones do what you want.

    You have a similar sort of problem with build-it-yourself languages such as Lua and most Schemes dialects. Instead of having to find the batteries, you're given the ingredients you need to make your own batteries if you want to do anything useful. Except, as a beginner, you have no idea how to do this and it gets frustrating.

    Languages like Python, Perl, Ruby, and others are all questionable for various reasons, but they're quick to get started with, easy to get results from, and have a large pile of useful built-in parts to choose from. You don't have to go hunting libraries early on, you can just keep the documentation that accompanies the language handy and look through it for the built-in things you need any time you run into something you want to do and can't figure out how. The negative to most of the batteries-included languages is they're usually complicated. Lots of syntax variation, weird tricks, and other things that get in the way. Python is no exception here, with its whitespace rules, but in general I think the benefits of a batteries-included language is worth the weirdness that tends to come with them.

    Another thing to consider is compiled vs. interpreted. The batteries-included languages tend to be high-level, dynamic ones, which means it's easier to do interactive, iterative development. You can start up a REPL and try things out, learn what works and what doesn't, and not have to worry about compile times, data types, or save-and-run cycles. Although I like Perl, I think this is what makes it less suitable as a beginner language vs. Ruby or Python. Perl lacks a REPL out-of-the-box, and the ones I've encountered on CPAN are piss-poor quality compared to the built-in ones provided with Python or Ruby (and the improved ones like Ruby's "pry" are leagues apart.)

    I probably should have mentioned Tcl+Tk along with the Ruby/Perl/Python discussion. It's batteries-included, has a passable REPL, and Tk makes it easy to make GUIs to do things. Unfortunately, any positives it has are outweighed by one massive negative: it's Tcl. I wouldn't want to wish that on anyone, even an enemy.

    Thinking about it, I believe Racket would be a good first language, at least in an educational context. It's a Scheme, so there's very little syntax to learn, but unlike most Schemes it has an extensive standard library built in, including a GUI toolkit, so you can do a lot with just the default installation. Its GUI REPL, DrRacket, is excellent and made in a way that lets it do double-duty as an IDE as well. You can make programs without ever needing to touch an external editor, and Racket has extensive documentation accessible from a menu. It's also simple to create runnable executables that can be distributed, so it would translate from educational to useful easily. The biggest hurdle to learning it would likely be that the documentation isn't as newbie-friendly as it could be, but in an educational context with a teacher, that's not as much of a problem.

    Also, because someone always brings it up: no, the parentheses are not a deal-breaker here. Don't even start. The syntax is one of the most consistent and regular you'll find; learning to group everything in parentheses is brain-dead simple compared to learning most languages' syntax from the perspective of an absolute newbie. Lisp syntax just seems weird to people because they already learned C-style syntax and forgot about the learning curve.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 1) by Ethanol-fueled on Friday November 04 2016, @11:44PM

    by Ethanol-fueled (2792) on Friday November 04 2016, @11:44PM (#422680) Homepage

    This is why C# on Visual Studio is still by far the most awesome thing to get ignorant noobs' attention. You create a Windows forms project and just drag and drop shit everywhere. Even making a simple pocket calculator is being like God to students who know only introductory console programming, and showing them the subtleties of making it authentic, how to reset variables, how to set the "LCD" text field right-to-left to simulate a real pocket calculator and when to clear it, how to handle dividing by zero, firing button events, etc.

    Of course, you can do the same with Java on Eclipse, but you lose a lot of charm and attention span fucking around with broken dependency hells just to be able to use visual classes or have a pre-written file you just load. You sit there looking like a dumbass for an hour trying to get everything to work, and by then your students think you're just another clueless moron.

    • (Score: 2) by Marand on Saturday November 05 2016, @03:01AM

      by Marand (1081) on Saturday November 05 2016, @03:01AM (#422725) Journal

      Eclipse is a clunky mess in my experience, never did like it much. I'd hate to see that be the first impression people get of programming. IntelliJ, however, is a very nice Java IDE. I bet if you combined IntelliJ with Scala, you could get a pretty good beginner experience set up, except for still having to do the compile/run thing. Though Scala does try to fake some of the dynamic language convenience with a REPL that compiles behind the scenes.

      That sort of easy experience is why I ended up suggesting Racket at the end of my comment. No drag-drop UI building, but with the combined editor+REPL setup of DrRacket, plus the built-in GUI libs, you can set up a basic window in a few lines of code, run it, and then use the REPL to modify the window on-the-fly. I'm far from being a beginner and I still think it's cool to be able to type a few lines in and see the UI change in front of me. (That's the awesome thing about using Tk as well; shame about it being dragged down by Tcl sucking.)

      Whatever the language and environment, the idea is the same: keep setup time at a minimum, avoid needing external dependencies as much as possible, and try to maximise interactivity by reducing the delay between the learner doing something and seeing the results of the action. Otherwise you're just introducing opportunities for the learner to get bored or distracted.

  • (Score: 2) by bart9h on Saturday November 05 2016, @09:14AM

    by bart9h (767) on Saturday November 05 2016, @09:14AM (#422781)

    I agree with most of your arguments, and they all point to BASIC.

    I'm obviously biased, cause that what I learnt first.