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: 4, Insightful) by The Mighty Buzzard on Friday November 04 2016, @07:26PM

    by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Friday November 04 2016, @07:26PM (#422569) Homepage Journal

    Have them bail off into the deep end right from the start; teach them perl. Yes, it's confusing having thirty ways to do any given task and they can very easily shoot themselves in the foot. Which will make other languages seem fresh and relaxing when they go on to learn them. Except java, it will still suck balls.

    --
    My rights don't end where your fear begins.
    Starting Score:    1  point
    Moderation   +2  
       Troll=1, Insightful=2, Interesting=1, Disagree=1, Total=5
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 3, Funny) by BsAtHome on Friday November 04 2016, @07:44PM

    by BsAtHome (889) on Friday November 04 2016, @07:44PM (#422579)

    "...very easily shoot themselves in the foot."

    That is an underestimation of programmatic proportion which a supercomputer mainframe has trouble calculating. I seriously doubt that such mainframe can come close to calculating the amount of horrible deaths you may encounter on the journey into Perl. Shooting your foot should be considered the pleasant form of mutilation you suffer. Most generally come out in small pieces from a shredder and are too fine-grained to become coherent again in the remainder of conscious thoughts that may resurface.

    Then again, it surely filters the good from the bad. So, yes, Perl is a good starting point.

    • (Score: 0) by Anonymous Coward on Friday November 04 2016, @08:05PM

      by Anonymous Coward on Friday November 04 2016, @08:05PM (#422589)

      > Then again, it surely filters the good from the bad. So, yes, Perl is a good starting point.

      Dont you mean

      for test
            %? || Die

      • (Score: 1) by sce7mjm on Friday November 04 2016, @08:36PM

        by sce7mjm (809) on Friday November 04 2016, @08:36PM (#422614)

        No, I don't believe he did

  • (Score: 2) by JoeMerchant on Friday November 04 2016, @08:39PM

    by JoeMerchant (3937) on Friday November 04 2016, @08:39PM (#422615)

    If you code in Perl as it was originally intended, your programs should never be more than a dozen statements, tops.

    "Powerful" scripting languages are by their very nature difficult to use. People who abuse them and write million line of code applications with essentially no groundwork rules of expected structure get what they deserve.

    --
    🌻🌻 [google.com]
    • (Score: 3, Touché) by The Mighty Buzzard on Friday November 04 2016, @10:10PM

      by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Friday November 04 2016, @10:10PM (#422647) Homepage Journal

      You mean like the site you just posted to?

      --
      My rights don't end where your fear begins.
      • (Score: 2) by JoeMerchant on Saturday November 05 2016, @12:53AM

        by JoeMerchant (3937) on Saturday November 05 2016, @12:53AM (#422696)

        If Soylent requires 1M lines of Perl to do what it does, the programmers should be given an obfuscation award.

        --
        🌻🌻 [google.com]
        • (Score: 2) by The Mighty Buzzard on Saturday November 05 2016, @02:22AM

          by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Saturday November 05 2016, @02:22AM (#422718) Homepage Journal

          Nah, only a little over 175K. Not counting external perl modules.

          --
          My rights don't end where your fear begins.
          • (Score: 2) by JoeMerchant on Saturday November 05 2016, @02:30AM

            by JoeMerchant (3937) on Saturday November 05 2016, @02:30AM (#422721)

            That's teamwork, and libraries for you. I've developed a couple of "big things" solo, and I can usually get more or less any "big thing" done in 100KLOC (C or C++). Put more people on the team and things tend to inflate. Bring in big libraries that need tweaking and things inflate fast (as you start adding the forked library code to your maintenance base.)

            --
            🌻🌻 [google.com]
            • (Score: 2) by The Mighty Buzzard on Saturday November 05 2016, @09:30AM

              by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Saturday November 05 2016, @09:30AM (#422783) Homepage Journal

              Mind you, there's thousands of lines of dead code in there that we simply do not use. There might still be some D2 code in there as well as all of the AJAX code, for instance.

              --
              My rights don't end where your fear begins.
              • (Score: 2) by choose another one on Saturday November 05 2016, @11:02AM

                by choose another one (515) Subscriber Badge on Saturday November 05 2016, @11:02AM (#422797)

                Yeah, but as ever the trouble is you don't know exactly _which_ thousands of lines are unused so it all just has to stay there with (possibly) no function except to scare and confuse the uninitiated...

                • (Score: 2) by The Mighty Buzzard on Saturday November 05 2016, @12:33PM

                  by The Mighty Buzzard (18) Subscriber Badge <themightybuzzard@proton.me> on Saturday November 05 2016, @12:33PM (#422811) Homepage Journal

                  Oh the bits we do use do that just fine. Which I don't quite understand. Sure, it takes a while to really get a handle on the overall functionality but most of the fixing we do only requires minor changes to one or two files, so you don't need to understand the whole thing to get some useful work done.

                  --
                  My rights don't end where your fear begins.
              • (Score: 2) by JoeMerchant on Saturday November 05 2016, @01:17PM

                by JoeMerchant (3937) on Saturday November 05 2016, @01:17PM (#422819)

                That's why my solo projects topped out around 100KLOC, around 5 or 6 years in we'd do a major refactoring (language change once, reboot on new hardware and systems the other), and rebuild without the cruft. Even along the way I endeavor to get the dead code out - it causes more trouble than benefit when you're sifting through it years after the last time it was active.

                --
                🌻🌻 [google.com]
  • (Score: 0) by Anonymous Coward on Friday November 04 2016, @10:53PM

    by Anonymous Coward on Friday November 04 2016, @10:53PM (#422661)

    the deep end = machine language

  • (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.

    • (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.