I'm a huge Python fan (90% of my code is Python, work and private), but I don't think any more it's still the language to push. I have not much experience but it seems Go, Ruby, and Scratch seem to be the one's people should be heading towards (which one depends on the level of skill required). But it's really just my feeling, I have no data to proof it.
Go, I can understand. But why Ruby? It is just as old as Python, behaves very similarly, and its ecosystem for non-web related tasks pales in comparison. And why Scratch? I really enjoy it (I've taught many workshops to kids 6-14 yo with it) but I would absolutely not use it in anything else but introductory classes.
The reason for Ruby is that more playful things seem to happen in that ecosystem. If you want to push something you want to be at the edge right? And although I believe Python and Ruby are equal in many qualities, Ruby is closer to the edge of where the next development happens. That was the reason behind my decision to add that.
This. I don't know why more creativity seems to happen in the ruby ecosystem, but it really does. My preference of ruby over python comes down to elegance and string interpolation operators (ie. not much). But ruby attracts people trying to do interesting things.
Some examples; Puppet, Chef, Vagrant, github, Jekyll.
I'm noticing similar cutting edge infrastructure/service stuff being written in go by default.
I think Ruby hit its peak at the same time as people were deciding what language to write Puppet, Chef, Vagrant, Jekyll, and Github in, but it's more a coincidence than something inherent in the language that led to those choices.
Salt and Ansible, successors to Puppet and Chef, are written in Python. The author of Vagrant is writing his new tools in Go. The buzz and constant churn of new shiny things that I saw in the Ruby community a few years ago seems to have moved more to the node.js community these days.
I know I'm late to reply, but i'm interested. What cool stuff is happening in the node.js community. The only thing I can think of that is really cool is meteor.
I think the thing that sucks about node is that javascript sucks. It's really a horrible language, it's just that it's everywhere. It's not the most horrible, but the type coercion, scoping and standard libraries really suck.
When you say salt and ansible are successors to puppet and chef, it sounds like you are saying they are inherently better, but really they just came later.
Out of interest are you saying you don't believe in Paul Graham's language spectrum? Blub paradox and that?
> If you want to push something you want to be at the edge right?
Wrong. You need to be at the core. In many areas that I've looked at, most of the activity happening at the edge is just churn from an ignorance of history and a naive blindness or lack of understanding of root problems.
And there is plenty of interesting stuff happening in Python: compilers, visualization systems, devops orchestration, you name it. Don't mistake the noise on HN for reality.
I'd have to agree, Go is suited to more intermediate level students and Scratch for extreme beginners and younger children, but Ruby? Ruby is like a harder to read, slower, less used python. Once rails falls(and it is falling) ruby will become a niche language.
Ruby on Rails apps have started causing a lot of problems for a lot of people. Any small initial gains obtained by getting Ruby on Rails web apps put together and deployed rapidly have time and time again been lost many times over due to performance problems, severe maintenance headaches, security flaws, and other issues such as those.
In short, it hasn't managed to live up to the immense amount of hype that once surrounded it.
Those issues, combined with many other languages now offering web frameworks that are far better than Rails, have caused a lot of developers and organizations to completely abandon it and apps written using it. Few people and organizations have time and other resources to dedicate toward something that is a liability, especially when the alternatives are so plentiful and better these days.
Which frameworks are far better than Rails? I've used Flask and Django, and like Python due to the large ecosystem of general packages available via pip. However, I've heard that Rails developers can be super-productive due to the much much larger ecosystem of web-related gems.
If a Rails developer were to move to another framework, which ones would you recommend and why?
I think Go isn't particularly suited for students at any level. It is a language built for applications that aim to scale extremely well in the cloud, and usually it is being used to replace small parts of a larger infrastructure. Go does not look as inviting for general web development (when runtime speed is not as essential as features) or general programming outside the web/cloud.
Go is a highly specialized language made for very specific use cases and mind, and still missing features that are essential in many programming domains (dynamic linking and real generics come to mind).
Ruby has no real reason to be if you're already using Python. Nothing wrong with that language (although I consider its programming culture to be inferior in many aspects) but it doesn't really do anything that Python doesn't do, even if it has a few more syntax tricks, which are at best a nice but superficial advantage, at worst another point of confusion and bugs.
Scratch is impractical, and a toy language. Whatever ease of use it has is very quickly surpassed by the need to be productive.
Requires curly braces and type declarations. These are easy for beginners to screw up.
> Ruby
Ruby's syntax makes me want to gouge my eyes out -- it's every bit as bad as Perl. I'm an expert and I hate Ruby. I wouldn't dream of exposing beginning CS students to that crap unless I wanted to convince them to change their major.
> Scratch
This is a toy language in a toy environment. I don't know the language well enough to judge its syntax, but the author's goal is "...rather swiftly bringing [students] to a level of skill where they can use computing in their other courses: to analyze data for those lab reports, to learn linear algebra, to solve problems in particle mechanics, problems involving differential equations, maybe even to write a program to control a robot." Scratch doesn't seem well-suited to this role, but there's enough language and library support for Python to be used in all these roles and many more.
I feel like you're placing way too much emphasis on syntax here.
From a non-superficial standpoint, you haven't brought up a single thing wrong with Ruby— or Go, aside from explicit typing.
The thing about syntax is that, to some extent, it's subjective. You say Ruby syntax is awful? OK. Personally, when I first started programming, I hated Python syntax¹ so much that I called it quits. It wasn't until later, when I started learning Ruby and its "eye-gouging" syntax, that I could get past that hurdle. So I wouldn't exactly describe its syntax as an argument against using Ruby as a teaching instrument.
¹I've since grown to love it, but as a beginner this was very much not the case.
Yes, it's pretty universal that people find it uncomfortable to force themselves to think in a language they don't fully understand yet. Whether that's Ruby, Haskell, or Japanese. There are plenty of valid things to compare languages on ( semantics, types, runtimes, etc ) but arguments about lexical syntax are really not that interesting since they're usually just throwing opinions back and forth about which lexical construct is more "readable", as if this term had some objective cross-language meaning.
There are two things about syntax that I think are actually objective. One is that, when beginners read their own source code that isn't working, they often have more of a tendency to read what they intended to write instead of what they actually wrote, especially when it comes to punctuation symbols.
This means that, when the indentation is right, but there's a missing -- or extra -- brace or semicolon, it can be very, very difficult problem for a beginner to even see. It's also possible for a beginner to write a program with many instances of brace/semicolon issues, giving a frustrating (and sometimes bewildering) boatload of syntax errors.
The second problem is that it's difficult to remember the meaning of symbols. This is true not just for beginners, but also for experts learning a new language with different symbols. This means that the number of symbols in a language should be kept to a minimum. Furthermore, where possible, symbols identical to those used in other languages, or in mathematics, should be used. Where a language has novel ideas that don't exist in other languages, those ideas should usually be expressed by keywords, not symbols.
Ruby fails at this. See [1] for an example. I don't mean to pick on this particular project, rather this file is typical of Ruby code. The file contains the following symbols which seem to be used differently from any language I'm familiar with: Less-than sign used in class declaration, use of colons for thing(s) that are neither dictionary literals nor labels, "absolute value" bars in e.g. { |p| p.id }, shift-left operator used in class declaration, question mark used for something besides ternary operator, lines without side effects like "true" and "false" sprinkled throughout the code (is there some "empty operator" that's applied to these lines to give them side effects?).
My point is that neither a beginner, nor an expert in non-Ruby languages, can understand the above code without constantly consulting the documentation for the unfamiliar syntax elements (and good luck figuring out how to search for "meaning of -> operator in Ruby" without knowing what the -> operator is actually called!) Whereas most Python programs read like pseudocode and can be reasonably well interpreted even by someone quite unfamiliar with the language.
Good languages address that problem by limiting the number of symbols, and making the meaning of symbols as simple and intuitive as possible. Ruby fails utterly on both counts.
I think these facts should be simple and obvious to anyone who's ever attempted to learn either Ruby or Python, but I guess this is HN, where an amazing number of people think Ruby is the bees' knees for no reason I can make sense of.
Thanks for the detailed reply. Those are all good points.
It's worth pointing out that a lot of Ruby's oddities (specifically :symbols, predicate_functions?, and implicit returns) are stolen from various Lisp dialects— which is also true of a lot of significant semantic/cultural differences between Ruby and Python.
So you could argue that the syntax differences are just a surface form of the underlying semantic differences. But that's kind of cheating (except for the implicit returns, which is a straight-up semantic difference). Maybe the better point to draw is that there is a background (Lisp) in which its syntactic quirks make sense. As an expert, the fact that that background is an unusual one is a negative for intuitiveness. But as a beginner, with no backing in Algolesque languages, does it really make that much of a difference?
Of course, none of that gets into the plain syntactic quirks— ->(pointy){lambdas}, {|block|syntax}, and so forth. But every language¹ has some of those— good luck making sense of Python decorators when starting out, or for that matter list comprehensions. Or non-paren-enclosed-tuples. Ruby's are used more heavily, but that seems more like a cultural difference than a syntactic difference— generally Python favors readability ahead of 'elegance', and Ruby vice-versa, which extends to making heavier use of special syntactic forms.
¹Except Lisp dialects, ironically! But even there, `(there are ,still some . peculiarities).
Pushing for Python by comparing it to Java is a first step. But if you really want to do the right choice for all those students, you'd better compare it to other good languages. For instance I'm thinking of Haskell.
Imagine that post being about PHP vs. assembly and thus pushing PHP, or about Java vs assembly and thus pushing Java, or...
It looks like the author's audience is applied sciences (MATLAB crowd). Therefore, the author's comparison of Python vs Java is more applicable than Python vs Haskell. This may be due to more "batteries included" in Java and Python ecosystems for scientific computing. The author had 30 existing Java programs to look at for bugs. I can't tell if his/her dataset search would have found 30 student-written Haskell programs.
I think the point the author is making is that Python eliminates a lot of overhead in learning fundamental programming concepts. I think it's easier for a beginner to grasp the meaning of something like
for i in range(0, 3):
than, say,
for (int i; i < 3; i++)
Haskell is also a great language, but not a great choice for beginners, I think, because it adds a lot of overhead in learning basic programming and CS concepts because of the whole purity thing. I certainly wouldn't try to teach first-year CS students how to implement things like stacks, queues and graphs in Haskell.
I don't understand how your "easier for a beginner" example relates to fundamental programming concepts. Are you talking about variable assignments, jumps, control structure, or about syntax ?
Again how is "the whole purity thing" an overhead w.r.t. to learning the fundamentals ?
If you take your loop example in Python, how does leaking the `i` variable outside the loop's scope (actually there is no such scope) a fundamental that beginners need to grasp ?
What would you say about `map f [0..2]` ?
So Python makes a lot of things easier than in C or in Java I get it. That in itself is not an argument for teaching it instead of, say, Haskell.
If you can choose between A, B, ... Z, sure it is better to use B if it is better than A, but not choosing F because you never use it is a wrong reason (at least if your goal is to teach students).
starting with python is ok as long as theres a C class following.
At various work places ive been to, the vast majority of coders know python or ruby or similar languages. They have NO CLUE how the memory is allocated, why some things in python are slower, etc. At some point they go 'its python runtime overhead'. But most of the time they could make the program much faster just by using better data structures in python. Most of the time they don't understand why something doesnt work the way they want and basically pray to get a premade answer on stackoverflow. While they could figure it out much faster by understanding how their machine works.
C has the advantage of being close enough to what the OS does (heck even C isnt always that close with compiler optimizations but - ok). Forces you to understand how the kernel works, how the CPU works, etc. Makes you a better python programmer too.
I started typing a really verbose and roundabout answer that really just amounted to this.
I don't even really agree with learning Python first. If you can get over the hurdle that is learning C (or really even just Java), you have the benefit of learning so much more about computing and the fact that types are implicitly being adhered to, memory is being managed beneath the surface, garbage collection, etc. I learned Java for my intro programming course and luckily had an instructor who really emphasized those topics. It made learning C and subsequently assembly much simpler. Had I started in Python, I don't see really learning much more than "wow, I can do some cool things with a computer." I suppose that's okay if the class is advertised as programming for non-CS majors, but to teach Python as an introductory course for CS curriculum seems almost like robbery to me. Jump the initial hurdle of learning the (somewhat) low-level stuff, and then the rest will come easily.
That's a reflection of the skill/desire of the programmer and not their initial introductory language. A naturally curious and intelligent person who wants to get better at their craft is going to learn about this stuff. Some people are happy learning enough to get by, and that's ok. Not everyone is destined to learn everything about their machine down to how disk controllers work.
Personally, I barely learned enough C to even be dangerous, and it's had no negative effects on my work. I have a reasonably good understanding of how Python works at the abstractions that I need to. If I need to learn more, I go figure it out. In truth, the most useful stuff I learn about writing efficient code comes from reading articles/blogs that give medium-level overviews of how a language implements certain features and how it effects your software. Would knowing C help with that? Not in the slightest.
I learned Java for my intro to programming. Later, I guess 2 years or so later, I began to take an interest into how and why programming languages work. Java throws an error if my index is out of bounds, which means it needs to check it itself, but what would happen if it didn't? What do I need garbage collection for? Why can't the compiler stack-allocate most objects whose references don't escape the scope of the method? How does the runtime know when it has run out of stack space? Does it check it on every new stack frame? Does the stack grow dynamically, or is it allocated ahead of time into one continuous, monolithic chunk? Can an ideal compiler infer the maximum size that the call stack will have at run time (modulo Halting Problem)?
I don't feel that my curiosity was permanently damaged by learning Java. On the other hand, I wouldn't have necessarily have wanted to learn anything about lower-level languages for its own sake, except perhaps only out of some sense of duty that 'every programmer should know this and that'. But since I have an interest in programming languages - which I of course didn't know that I would develop when I was learning my very first programming language - these things became relevant to me later.
There are basically two things we call "programming".
One is the specification of a process in algorithmic terms - the abstract, but rigidly defined sequence of transformations on input data into output data. This is a field of mathematics.
Two is the building of a physical system to take input data and produce output data, these days by configuring a complex machine comprised of many different pieces of silicon, each of which takes a string of bits and understands a concrete machine language. We have built a high tower of abstractions, so many different silicon-based computing machines can be programmed the same way without programmers going insane. This is a field of engineering.
You need to teach both. They are two completely different skillsets and a successful developer needs to understand both sides - the mental tools necessary to make algorithms, and the engineering skills necessary to make machines that implement algorithms. You don't start from discrete mathematics and then proceed to trying to bang them inside a computer, nor do you start from silicone and then pretend this is the basis for algorithms.
Both are starting points and you need to approach both as their own thing, not a continuation of the other. To this end, it would be for the best to teach both C and Python at the same time. I find that the two aspects of programming are their own mindsets and things learned in the beginning of each don't really carry over to the other.
And then hope the student can put one and two together.
When I set out to learn Python, I'd had passing experience with Visual Basic, PHP, Javascript and even a bit of Scheme. I understood what programming was all about, but I hadn't yet overcome the initial struggling to translate the logical flow that I had in mind into code.
Now, almost a decade later, I'm still writing Python. Sure, I write my share of Javascript like most people, but Python is my first and true love.
Python is shallow. There isn't a lot to it - once you understand how magic methods work, you're pretty much at the point where reading the source of the implementation is the next step in understanding.
It wasn't long before I found myself learning the specifics of C data types in order to understand exactly how Python types worked.
In short, my contention is that someone who wants to become a better programmer will become a better programmer regardless of their preferred language.
Python was the first language I learned in college, and I have to agree with the OP's opinion on this. While transitioning to C++ in later courses did involve some pain points, I felt like python was a great way to ease into the programmer mindset and get the basic concepts out of the way before delving into the more low-level stuff like pointers, and later with OOP. Not to mention that Python is becoming the Lingua Franca for academic research due to its powerful mathematics packages, and I was immediately able to start programming for money at a university research lab right after I took the class. The realization that I could learn a skill like this and immediately earn money with it was incredibly powerful for me. While there may be "better" languages in terms of teaching programming concepts, the fact that python is so immediately useful in a large number of disciplines relevant to students (at least in a university) still makes it the best language to start learning with right now IMO.
> "I felt like python was a great way to ease into the programmer mindset and get the basic concepts out of the way before delving into the more low-level stuff like pointers"
My first programming language in college was Scheme and I could use exactly the same words to describe my experience.
Not that I am not agree with the link but Python is not caveats free either.
The fact that they have to "fix" the language in one version making it incompatible with previous versions is smelly enough to me from a design point of view.
Breaking backwards compatibility doesn't necessarily mean bad initial design. One of the main breaks of compatibility in python 3 was making strings unicode by default. The world changes, why wouldn't a language change to meet that need?
Honestly I think a lot more languages (cough, Java, cough, cough) would benefit from breaking backward compatibility (occasionally, like every 10-15 years) rather than force it to maintain cruft that no longer makes sense to keep.
There was no desperate need for Unicode everywhere when Python 2 was made. Looking back it's a fix, but other languages have this problem either and can't really be avoided.
PHP would be among the worst languages you could throw at somebody learning computer programming concepts. I'm pretty sure this was a joke, just the same.
I was learning to program around the time when php and classic asp were gaining ground (1996)... php had far more to offer for free, but the utter inconsistencies irked me to no end, and still do.
I was half joking, the parent said python was incredible powerful to him because it allow him to make money quickly, some would say php is king in that domain.
By quickly he meant from the process you start learning your first programming language to be able to make money with that language.
I both agree and disagree with the truth part of your joke.
I agree in that a bunch of people I know started out with Wordpress or even Joomla, and managed to get a site working for a paying client relatively quickly. And making money was a great motivator for them to get better, and 'grow' out of php, or at least start using better CMS' or frameworks (or write their own wordpress plugins). I've found that especially designers who 'know a bit of html' seem to get pretty far with Wordpress and a bit of jQuery they copy and paste.
The result is usually an abomination in my eyes, but hey, if they're getting by doing it, and especially if it's a gateway to getting better at actual programming, why not? That's how I did it!
But I I also partly disagree in that I've also met quite a few web 'developers' who did so well 'snippeting' their Wordpress/joomla sites together, that they never moved beyond that and eventually succumbed to fierce competition. Because now they're competing with non-programming designers who can build fancy looking websites with cool interactivity, and are better at making it look good.
Because I've seen both good and bad come out of it, I usually try to gauge what kind of person I have in front of me when they approach me for help or advice.
If it's someone who doesn't seem to have the inherent curiosity to become a better programmer, I might just help them set up their first wordpress site and do my best to keep them from doing too much 'damage'.
If I do see a bit of curiosity, I try to gently steer them towards other solutions (Middleman + heroku, or Ruby on Rails for example) that are a nice midpoint between some 'coding' and seeing quick results.
And if I think I have full-blown future programmer in front of me, I just throw tons of stuff at them, usually right in the browser dev console, (closures, callbacks, functional-style programming) and relish seeing them try to figure it out and go home and tinker with a Fiddle! Those are my favorites.
No doubt Python is a pleasant language to code with (if you don't mind forced indentation of your code). But to be fair this article should compare it to Groovy for instance and probably not Java; doing so would make the push for python a tad more challenging.
I took another look at Groovy again recently (haven't played with it since version 1.8) and i'm beginning to feel that i should have invested more time in learning/adopting it back then. The only drawback for me was the resource requirements of Grails (and the JVM) but now that Linode is giving 2gb ram for $20/mth, the attraction to Groovy is getting stronger lol!
Grails adoption share has been falling rapidly lately. It rose on Rails's coattails and it's falling that way too. Other architectures are taking over: vert.x, node.js, Play!
Standalone groovy scripting isn't used as much nowadays either. I suspect Oracle's going to push Nashorn Javascript it shipped with Java 8 for your JVM scripting needs.
Groovy has been getting lots of new users because of Gradle's increasing popularity, though your typical build file is 20 to 100 lines long. Gradle still ships with Groovy 1.8 anyway so you haven't missed out not keeping up!
I don't necessarily disagree with her reasoning, however the rundown she quotes is unimpressive. It basically amounts to "Python is Turing complete and has libraries," minus the point about it being English-like.
I think I could have written this article a few months ago, when I was a huge Python fan and would spend a significant amount of time telling my friends in academia to stop using Matlab and start using Python.
Then I started working in a research lab myself, and I haven't used Python since. Very simply, there's an immense amount of code written for Matlab that I can learn from in domain-specific instances, hardware vendors provide Matlab example code (and not Python code), and all of my peers use Matlab. When I have a problem they can usually help me solve it, if I'd been using Python I would've been all by myself and likely unable to finish the task.
And really, these are the most important things to consider when choosing a language. As it stands, Matlab is the right language to choose, at least for me.
Big existing codebases always hinder language adoption.
But Python is becoming the lingua franca of scientific computing, owing to great open source tool and libraries. Very soon hardware vendors will always provide python example code, python "drivers" or REST-like APIs.
I don't say this lightly, and this statement is hardly ever right, but in this specific instance, Python is clearly the better "language" compared to Matlab, even in scientific computing. The syntax and quirks in Python are more consistent than in Matlab and general programming is a lot easier.
Well, also consider the point she's making. So you had to switch to matlab, but you were able to, perhaps partially because you already had a grounding in programming in a language you found pleasurable.
I'll make the obligatory "I hope that Julia will replace Matlab in this role soon" statement. But I also hope that infix matrix operations will make Python 3.5 more competitive in this situation too.
This is an important point. The right tool for the job has to take into account the existing tools inertia.
Having said that, I had a similar situation at my research lab and have now almost replaced Matlab.
This process was mostly organic, starting with me changing my personal post-processing workflow when I switched to IPython Notebook as a logbook and plotting library (i still use gnuplot occasionaly).
Soon I started having to port bits of Matlab and C code to Python and Cython to allow me to continue using the logbook, and I found I was becoming a lot faster at creating new modules and tools, mainly because the programming component was now intricately linked to my workflow (and more fun)
The tipping point was when I converted a notebook into a slideshow for a presentation I had to do for the group. Everybody was more interested in how I made the presentation then in my results, and wanted access to the new tools. I provided them with the git repo (and git tutorial), gave people notebooks I had written to log coding practices and demos of my code (I have poor memory) and encouraged people to contribute back.
Getting people to contribute back is still the hardwork: Everyone is shy to share their code, but the Professors starting preferring IPython Notebooks. New code is now usually written in Python first, and sometimes ported to Matlab and even the hardcore Matlab researchers are starting to show interest because of the speed and flexibility of the new code.
Basically, I found Matlab is definitely replaceable - and can only improve workflow (speed it up if nothing else). There are a few instances when specific hardware requires Win driver access through a Matlab plugin, but there are ways to interface with these too.
Learning something new is hard, and Python is easier for students to learn.
Really, the ease of learning should trump almost everything else. Especially since Python is actually used in the real world, so it's immediately applicable.
You want students to know more concepts they won't get from just Python? I agree with you. Just not as a first language.
It seems the only argument for pushing Python is that it sidesteps the need to understand fundamental programming concepts. Sure Python is easy to read and easy to write, but that's not really the point. To teach somebody print "hello world" in Python is not really teaching them much at all... Teaching someone the C equivalent would cover functions ("what is 'void main()'?"), entry points and how programs are loaded by the OS ("why do I need void main"), libraries ("what is cout and where did it come from? iostream!", "what else does iostream have?"), operators ("if cout is a function, what is this << thing?"), etc... The verbosity is helpful because it allows the student to ask questions that lead to a more holistic understanding of computer science. If a student with no programming knowledge asked me about how print worked in python, it'd be hard to know where to start explaining!
Why do you have to teach them the boring stuff first? The point is to get them interested in programming. They can learn how the hardware, compilation, linking, and algorithms work later.
Above all, get them interested. If you capture their imagination, they'll be receptive to--even independently curious about--the details.
I'm speaking anecdotally now, but please do not bore young students. There's no way I would have stuck with it if C was my first language. Javascript and Python are excellent starting points that easily let kids create games and websites and fun things.
We probably wouldn't start someone off with Haskell, but to me C seems on the same level of impracticality for a young beginner.
Well if somebody is in higher education for computer science, I'm assuming their imagination has already been captured. I'm all for using whatever has the lowest barrier to entry in order to get young people interested in programming.
Sorry but hardware, compilation, linking, and algorithms are anything but boring. Even as a beginner I was very intrigued by all of them, even if I did not understand them as well.
Yeah, sorry, but that's you. I can bring my own anecdotal evidence to the table and say that for me, compilation, linking and algorithms were very secondary to the thrill of typing in "commands" to the computer and have it do all the work for me automagically. Programming, which I learned in college, was a very pleasant method of getting around all that boring math by letting me figure out how to solve the problem and then having my computer do the mechanical calculations.
Thrill does not allow you to solve problems (beyond what a competent engineer has solved for you behind a pretty API). In order to succeed at solving problems you must enjoy it in the first place. If you do not care about the underlying algorithms behind those calculations programming is always going to be boring.
This is like saying that when teaching people how to cook, you should start with chemistry lessons. Sure, at some point you have to have some understanding of chemistry in cooking, but does that really mean you have to start out there?
Yes, every programmer should eventually learn about the things you're talking about. But C is a terrible first language.
I would disagree that you need an understanding of chemistry to cook... (although it doesn't hurt). However, if you want to teach somebody to cook, you don't teach them how to use the microwave :)
I was about to disagree with this criticism of C, since I loved it as the introductory language in college. But then I remembered that Basic was my first programming language, and Pascal was the first language I was actually taught, and I'd been programming for a long time before actually getting to college.
So I totally agree. Python probably makes sense if most undergraduates don't have programming experience any more. And the ones that do probably have experience in JavaScript.
I think it all depends of your goals, if you learn to cook in order to impress your friends, no you probably don't need chemistry lessons, but if you plan to win 3 Michelin stars for your restaurant, you probably need to.
Same for programmation, if you just want to ease your work, compute quickly some math formulas, etc, you can start with Python. But if you plan to write the next big OS, you better start with C...
I agree with this. I started with Python, then later learned C. Taking the top down approach has several benefits when learning. You can make programs that actually do things much more rapidly, incentivising continued learning; this can not be emphasized enough. Less time is wasted wrestling with the many subtleties of something like C. Although important, knowing about pointers and memory allocation is unnecessary when trying to get across very basic fundamentals like control flow. Python also acts as a model for good abstractions. If you start out working with Python's list type, lists are already a familiar concept when it comes time to implement a linked list, because you understand how it should* work. By the time the student is ready to learn something like C, they already have a solid grasp on how things are supposed to work, so understanding how they actually work becomes substantially easier.
*CPython's list type is really a dynamic array, and it works better as a stack. However the interface is similar enough to a typical linked list, that it gets the point across.
I don't even think you need to learn it eventually. For a similar argument, ask if most programmers need to learn assembly or further down the stack, EE, eventually. The answer is a resounding no. Extrapolating this even further, in the future "programmers" will be people who are just very good at issuing NLP commands to computers. They won't type strings of characters into consoles.
Really? I would argue that every serious programmer needs to eventually learn those things, and most people I talk to agree with me. If you're a business person who wants to learn how to code, that's fine, you don't need a deep understanding of how your machine works; but to be a really good software engineer, I think you need to learn C and assembly, even if you never actually use those languages/concepts directly in your work.
I agree. We don't need to know instruction encoding, because we can use assembly, or assembly, because we can use C, or C, because we can use Python. What you need to know is, well, what's needed to use the particular language and system architecture to its maximum potential. And that's more of a training and conceptual thing than a C/assembly thing.
My guess is that a lot of people who are getting an introduction to programming don't know what their future ambitions for programming are. "Oh, you want to learn the basics of programming, do you? Well okay, we have some different offerings; do you plan on programming micro controllers embedded in amphibious robots? Maybe you want to write an SMT solver? Or maybe writing software for caching HTTP responses for web servers is more in line with your ambitions..."
You might as well start with the stuff that is common to most of (contemporary) programming.
Given actual practical experience of e.g. Software Carpentry that's an absurd view. You actually do not need to know how "print" is accomplished. Print is not a leaky abstraction unless you go into what is (these days) an absurd scenario like a serial console.
Instead of teaching them about function composition, recursion, data abstraction, and all the interesting concepts of computer science you end up teaching them a bunch of incidental stuff about memory locations and syntax.
Python suffers from this less than C, but still much more than Scheme. I really can't imagine advocating for something other than some dialect of scheme (maybe racket) for an intro undergraduate course.
For kids I can see choosing something like Javascript (as terrible as it is) just for the immediate feedback that someone before me mentioned.
You just have to explain that "b = a" means that you're adding a new name to the thing/object named "a". Whether it's in the same memory location or not is an irrelevant implementation detail.
These aren't computer science students. Most of them won't find recursion and data abstraction interesting in the slightest. If their primary interests were in computer science I'm sure they would have gone into a comp sci program.
These students are there to learn programming as a tool to help them solve problems. The elegant recursive algorithm isn't really a goal they have. Their goal is to get a reasonable answer to a problem so they can move on with more important things.
That's fair if you're only doing a one semester for non-majors thing. I just saw "our undergraduates" and the debate about learning C and took it to mean starting a CS education with C.
Those things I mentioned are how you solve problems though. What I was getting at is learning the low level details of how a computer, or at least C, works isn't problem solving.
>Sure Python is easy to read and easy to write, but that's not really the point.
That is the point. This isn't for comp. sci. students, this is for engineering students.
I know that in America, unlike other countries, "engineer" is a non-protected term and that lots of guys who don't actually have engineering degrees (such as comp sci majors) call themselves engineers.
But "actual" Engineers, i.e. the people who have engineering degrees or are in engineering programs, the people to whom this article pertains, are applied scientists. By definition, their professional concerns aren't the inner workings, or developing a holistic understanding of computers. That's for a specialist, i.e. a computer scientist who has more appropriate training. An engineer's job is to develop a solution that surpasses the design requirements (physical as well as budgetary) by the minimum amount. As a crude example, anyone with a high school education could, with unlimited funds, build a bridge that would stand up. But only a trained structural engineer can build a bridge that will just stand up.
I'm a mechanical engineer, and for people in my field the programming aspect is most often a means to and end; you're writing a simulation to give you better insight into solving a physical problem, or you're writing a program to crunch a shitload of data, or you need to plot things and present them in a particular way or output the results to a particular tool, etc. The performance of the algorithm or your code is not really paramount. If it's "good enough" then it's good enough, because the code you write is just another tool in your toolbox along with your digital multimeter, your impact driver and your wrench.
I recently wrote a quick one-off to iteratively determine the asymptotic limit of a set of physical functions with many interconnections and shared variables, subject to 4 different constraints and involving numerous irritating physical constants.
To write that program successfully, I don't have any need whatsoever to understand the intricacies of file IO, the specifics of how libraries are linked at compile time, or how the print function actually prints to the screen. All I need is for it to print a number to the console so I can compare it to my far rougher hand calculations. Anything else is a waste of my time.
Had I written that one-off in python, the knowledge that "print prints things to the console" would be perfectly adequate for me to do what I need to do in order to move on to more important things. The inner details just aren't important.
You have quite a few muddled definitions that you trip yourself over in your post. First you say that you're an engineer, which means you're an "applied scientist". Then afterwards you go on to claim that computer scientists aren't really "engineers" by your definition. Then further down you go on and say that they're instead "specialists". Sounds like you just had to find another word other than "Engineer" there, so you picked specialist.
Then again... You mention that the job of an "engineer" is to "develop a solution". Well, that's pretty much what a software developer or software engineer would do. They're all grey, and it sounds like you're not quite sure of your own definitions. I can't tell if you're just confused about what all these terms mean to you, or you're just hurriedly trying to justify your own internal view of superiority over "non-engineers" because you're a "mechanical engineer" and don't like being on the same plane as them.
All in all, I should probably disclose that I've had this argument a few times with "engineers" in the physical sciences. They all had a vested interest in protecting the term engineer because if they didn't, it would devalue their worth and the degree they hold. And the government-body given "accreditation" that they lord over people for higher pay.
>First you say that you're an engineer, which means you're an "applied scientist".
I am.
>Then afterwards you go on to claim that computer scientists aren't really "engineers" by your definition.
They're not.
At least, not in Canada. It's against the law to call yourself an engineer if you don't actually hold an engineering degree from an accredited institution.
>I can't tell if you're just confused about what all these terms mean to you, or you're just hurriedly trying to justify your own internal view of superiority over "non-engineers" because you're a "mechanical engineer" and don't like being on the same plane as them.
That's your problem. I'm not confused in the slightest nor do I feel superior. Different skills for different areas of focus.
I specifically referred to computer scientists as "specialists" having more appropriate training. If you're upset because you can't legally call yourself an engineer in my country then that's not my problem.
> They all had a vested interest in protecting the term engineer because if they didn't, it would devalue their worth and the degree they hold. And the government-body given "accreditation" that they lord over people for higher pay.
Sounds like you're the one with an inferiority complex here. I like how you put "accreditation" in quotes as if to imply that accreditation is not really worth anything. That's very mature. The term Engineer is protected in my country due to very real issues of public safety. You don't want someone certifying a skyscraper as safe, only to find out they are an architect, not an engineer, and therefore weren't trained in structural dynamics, metal fatigue, stress analysis, etc. If that architect wants to be able to certify buildings they need to demonstrate competency to the regulatory authorities by completing an accredited program.
You know how they say "don't roll your own crypto, leave it to the experts"? Same thing.
>First you say that you're an engineer, which means you're an "applied scientist".
I am.
I think that's just a ridiculous way of referring to engineering. If we're going to be strict about the term engineer, we might as well be strict about the term scientist and pounce on anyone calling themselves a scientist, applied or otherwise, if they haven't submitted articles for peer review. How many members of your graduating class of applied scientists have been peer reviewed?
They're not.
At least, not in Canada. It's against the law to call yourself an engineer if you don't actually hold an engineering degree from an accredited institution.
Protection of the term engineer in Canada, for any old BSE, is ridiculous and is inconsistent with conventions in most of the rest of the developed world. It's largely ignored by industry, frequently 'violated', and protects no one - certainly not the public at large, at least. What really needs protection is the title P.Eng, which actually is important to the safety of the public.
The term Engineer is protected in my country due to very real issues of public safety
P.Eng. yes - but a BSE? Should the full force of law really be brought to bear on someone who might be confused with having earned a BSE by calling themselves an engineer? Who does this protect?
You don't want someone certifying a skyscraper as safe, only to find out they are an architect, not an engineer
Yes - and that would be a licensed, legally entitled, and legally cupable P.Eng., not some random BSE.
Edit - for the uninitiated, P.Eng. or Professional Engineer is a legally protected (in Canada and the United States at least) title given to a graduate of an engineering program who has been through an industry mentoring process, has taken competency exams, and has taken a professional oath of ethics. These are the men and women who keep our bridges from falling down by saying 'no' when someone wants to cut corners or reduce expenses. Many projects, especially in civil engineering, require the sign-off of a P.Eng. A P.Eng. is also legally culpable if they knowingly approve of something that they shouldn't.
A BSE is someone who graduates from an undergraduate engineering program.
>P.Eng. yes - but a BSE? Should the full force of law really be brought to bear on someone who might be confused with having earned a BSE by calling themselves an engineer? Who does this protect?
I think it's pretty obvious that I meant P.Eng but didn't want to get into it for brevity. Not everyone knows the difference.
>I think it's pretty obvious that I meant P.Eng but didn't want to get into it for brevity.
That's a pretty major thing to omit considering the argument you were trying to make. Keep shifting those goalposts.
>Sorry you're butthurt.
For being an engineer, you're certainly very immature and appear to lack the critical thinking skills required to engage in an argument with valid points.
What makes 'void main()' fundamental to programming? And the syntactic sugar of cout and operator overloading? Come on. If there's anything fundamental about programming it's not the particular design choices made in your favorite language. What makes Python good is that it allows one to focus on learning to translate ideas into programs before having to deal with all the other junk that goes into programming in other languages.
I wonder if there are differing schools of thought as to what are the fundamental programming concepts. Is it more fundamental to expose students to, or isolate them from, the innards of the computer, when they are first learning to program? Short of settling that issue, the next best thing might be to expose students to at least a couple of different approaches. Python and C would be my choices. I'd teach C on a microcontroller target.
Some isolation is necessary. I doubt that I could completely explain how either print or printf turns the pixels on and off on the display.
note: void main should be int main(at least in c++)
You could just give
from __future__ import print_function
import os
def main():
print("hello world from:" + os.name)
if __name__ == "__main__":
main()
as the hello world that covers functions(main/print), entry points(python runs the code top to bottom defining classes and functions at the top level and running any other code it encounters, to allow importation of libraries we put the code we wish to run in a special block that only runs it when the script is the only being directly run, not imported), we imported os and used os.name to demonstrate a library, + is an operator.
I teach 11 to 18 year olds and I've stopped teaching them Python and started teaching them JavaScript.
My main reason for the switch is to overcome the "What's the point of this?" questions that I used to receive. With JavaScript the kids instantly see a result on a platform they're familiar with - a browser. window.alert() is instantly recognisable to them and seems far more relevant than print"" where the output is only visible in a terminal or IDE.
JavaScript has numerous caveats and idiosyncrasies that result in strange and unexpected behavior. It's scoping rules are also pretty broken. While Python does have some of its own quirks, they're far fewer in number. There are two that bite people pretty often, using a mutable type as a default function parameter, and accidentally typing a comma after an expression subtly converting it to a tuple.
A lot of the problems with JavaScript aren't "caveats and idiosyncrasies" or "quirks". They're rather horrible and unjustifiable flaws, plain and simple.
I agree, they are horrible flaws. Though to be fair, you have to understand why JavaScript has as many flaws as it does. I believe this is largely due to the context in which it was created. First, it was written in the absolute minimal amount time possible. "If it fits, it ships", really applies here. Second, JavaScript was designed to make sub 200 line scripts that add basic interactivity to web pages, not to make the complex layered applications it's often used for today.
That was true in 1995. It's now 2014. There has been ample time to fix the many flaws. There's no justifiable reason why, nearly 20 years on, JavaScript is still so inherently busted in so many ways.
Once again, I entirely agree. I personally wish browsers could run a sand-boxed Python implementation, with some sort of DOM interface. Think `import dom`. Ideally browser's would agree on a hard set of standards ahead of time, so things like jQuery would be unnecessary (even though jQuery is about the only good thing involving JavaScript).
I can't disagree with you at all, though I don't necessarily share the same level of contempt for javascript. The thought of creating a "new" and "fixed" language to replace it brings the xkcd comic on standards to mind (#927).
I would argue there is a justifiable reason. Before I do bear in mind I accept it may not be a good reason, or one without workarounds, but hindsight makes both of those much easier to see than in the day to day development.
Backwards compatibility. The two words which really haunt web developers everywhere, on so many levels. We don't want old sites to break in new browsers, or new sites to break in old browsers, so fixing major issues of such magnitude would require at a minimum a unique version that could be differentiated from older sites. And when was the last time you saw a version of javascript specified in a websites code?
So then a situation occurs where we could use the new code and "do it right," but we would need fallbacks for old browsers. Or, we could "do it wrong," only use the old way, and development would take significantly less time. While over time the new way likely would win out, it would be a long and drawn out process taking enough developers and managers putting their feet down and saying, no, while this will take more time, cost more money, for the exact same functionality, it is the right thing to do for the future of the language. And getting their bosses to accept that tough sell.
The above seems very similar to HTML5 and IE6/7 support. And how long has that fight been going on?
So yes, one would think the flaws should be fixable, but looking at it from an in the moment perspective as opposed to through the lens of history, it isn't completely incomprehensible as to why they still exist.
Another thought that just popped into my head, is for the majority of the life of javascript, it was used by web developers, many of whom would by todays standards be much closer on the spectrum to "my nephew who designs websites" than a software engineer. It wasn't until much more recently that it began to heavily be used by engineers who pushed the limits much further and ran into these problems. It makes me curious on when the first documented case of these issues was brought up. Was it 20 years ago, or maybe only in the last 5?
This may be an unpopular opinion (certainly contrary to what the majority of publications on the web would have one believe) but I wouldn't consider Javascript a beginner's programming language.
C was hard for some kids to grasp in my high school class, but I didn't struggle with it, and it certainly taught me rigor and attention to detail. Ruby (on and off Rails) helped me build things without getting bogged down in syntax; the LOC-to-output ratio was quite gratifying. Only later did I progress to writing non-trivial Javascript.
While it's an incredibly powerful language (when I hear people describe the "enlightenment" of developing in Lisp, I'm often reminded of JS), it has a lot of warts that, as you rightly stated, can throw beginners for a loop. I imagine that if I had encountered the example you described above at the beginning of my career, I would have decided that Javascript is for the birds and resolved to just write C/C++ for the rest of my life.
I've also found that most people who were curious about programming got very excited when I showed them the dev tools of browsers. For at least one it triggered a love of programming.
One option to make js a little easier to start with is to install a CoffeeScript plugin. Not sure if it's a good idea, but it's an option.
Also, one nice side-effect of getting them started on javascript is that learning another language (ruby or python, perhaps), is a wonderful next step because suddenly you're using a much 'friendlier' language! Whereas if you start with that, having to deal with js can be frustrating.
The fact he got so many things wrong trying to make a C++ hello world from memory actually reinforces his point. All these idiosyncrasies are nothing more than friction to a beginner. These only matter if you're trying to teach C++, not programming as a whole.
Why do people advocate Python and not a dialect of Lisp for beginners? Are prefix notation and parentheses really that terrible in exchange for a completely unified syntax?
I believe Lisp is a good choice for beginners too, but it's two different approaches. Lisp is interesting for the theory behind it - you can introduce lambda calculus, parsers, AST, stacks while you teach the language, and the student will have a grasp of how the computer understands code. Python is a more hands-on approach - you just teach some syntax that reads like english and the student can put some libraries together and do something meaningful, the barrier is low and you get instant gratification, which is important to keep students motivated.
When you show someone a mathematical formula using standard infix notation, and then want them to write a program to implement it, it's immensely helpful if the syntax of the language is close to the mathematical notation. Infix operators are a huge boon to readability for beginning programmers, especially those with some science/math background.
Agree with this article 100%. The reason I discarded programming (and went into Mechanical Engineering)sophomore year of college was because I was frustrated with the syntax issues with C++. Years later, once I learned Python, I started experimenting with other languages and learned to deal with the syntax. Syntax isn't a big deal for people who are used to it, but for people who are deciding whether to be interested in programming or not, syntax can but a huge turn-off.
If I had to overly generalize, programmers tend to fall into the "builder" and "curiosity" camps.
I grew up using a Borland C++ compiler that didn't list which line numbers were missing semi-colons. I didn't mind going over my code to find the missing semi-colon, but plenty of my classmates were frustrated. They weren't interested in how compilers worked, how code was parsed and debugging information was lost in the transition. They just wanted to build a game, a web site, something.
At college I had a difficult time with Scheme and looked down at it. Where's the manual memory management? The pointers? The for loops? Scheme abstracted away a lot of plumbing and let users focus on algorithms.
Nowadays I think Python is the ideal first language followed by C and Haskell. It's starting in the middle, and then moving towards opposite ends of the programming spectrum: systems and functional programming.
Some make the argument that CS students should be dedicated enough to plow through an introductory course taught in Java / C++. I think that's an elitist attitude. CS is not growing in popularity despite increased demand[0], and new students should be welcomed instead of facing artificial filtering measures like "dedication". At the same time, this is not a proposal to water down the major--just a plea to ease students in instead of kicking them off a cliff and hoping they can fly.
> One might also argue that these tools are simple enough once you learn to use them. I would only point out that, emperically, that bar is too high. Despite the clear benefits, the vast majority of the world was chosen to remain illiterate. Even tools for which there is a clear need (eg version control) have largely failed to make a dent. Clearly there is a need for a less hostile programming environment.
> Nowadays I think Python is the ideal first language followed by C and Haskell. It's starting in the middle, and then moving towards opposite ends of the programming spectrum: systems and functional programming.
I agree. My friend studied CS at UC Berkeley where (at the time?) first semester was Scheme, second semester was assembly language, and then subsequent classwork was usually C++ or Java.
The dedication filter is much of the value the college experience provides. As many people would argue, a degree in CS doesn't actually teach you marketable or relevant skills to a sufficient degree.
When teaching young children, 'to ease students in' is a good idea. But for first-year college students, it's the worst thing you can do to them. The ones who chose the right course will be okay either way, but the ones who chose the wrong course won't get to find out until it's too late to switch, at least not without having wasted a nontrivial chunk of their lives. The overriding criterion for a first-year college programming language is to have a difficult learning curve to give students accurate information as early as possible about the nature of the subject they've signed up for.
Isn't python basically the defacto OO language in undergrad CS courses today? Every CS student I've ever met did their intro courses using python. Later years would delve into C and MATLAB.
I agree, with reservations. Python is great for introducing people to programming; however, it is not necessarily great for teaching computer science concepts.
My 200 level data structures and algorithms class was taught in Python, and it just felt awkward. For example, we constructed an "array" by basically creating an abstraction on top of a list, which did nothing but remove features and introduce overhead. It kind of felt like teaching someone how to make a bike by taking all four wheels off of a car and only putting two back.
128 comments
[ 2.3 ms ] story [ 288 ms ] threadGo, I can understand. But why Ruby? It is just as old as Python, behaves very similarly, and its ecosystem for non-web related tasks pales in comparison. And why Scratch? I really enjoy it (I've taught many workshops to kids 6-14 yo with it) but I would absolutely not use it in anything else but introductory classes.
Some examples; Puppet, Chef, Vagrant, github, Jekyll.
I'm noticing similar cutting edge infrastructure/service stuff being written in go by default.
Salt and Ansible, successors to Puppet and Chef, are written in Python. The author of Vagrant is writing his new tools in Go. The buzz and constant churn of new shiny things that I saw in the Ruby community a few years ago seems to have moved more to the node.js community these days.
I think the thing that sucks about node is that javascript sucks. It's really a horrible language, it's just that it's everywhere. It's not the most horrible, but the type coercion, scoping and standard libraries really suck.
When you say salt and ansible are successors to puppet and chef, it sounds like you are saying they are inherently better, but really they just came later.
Out of interest are you saying you don't believe in Paul Graham's language spectrum? Blub paradox and that?
Wrong. You need to be at the core. In many areas that I've looked at, most of the activity happening at the edge is just churn from an ignorance of history and a naive blindness or lack of understanding of root problems.
And there is plenty of interesting stuff happening in Python: compilers, visualization systems, devops orchestration, you name it. Don't mistake the noise on HN for reality.
In short, it hasn't managed to live up to the immense amount of hype that once surrounded it.
Those issues, combined with many other languages now offering web frameworks that are far better than Rails, have caused a lot of developers and organizations to completely abandon it and apps written using it. Few people and organizations have time and other resources to dedicate toward something that is a liability, especially when the alternatives are so plentiful and better these days.
If a Rails developer were to move to another framework, which ones would you recommend and why?
Ruby has no real reason to be if you're already using Python. Nothing wrong with that language (although I consider its programming culture to be inferior in many aspects) but it doesn't really do anything that Python doesn't do, even if it has a few more syntax tricks, which are at best a nice but superficial advantage, at worst another point of confusion and bugs.
Scratch is impractical, and a toy language. Whatever ease of use it has is very quickly surpassed by the need to be productive.
Requires curly braces and type declarations. These are easy for beginners to screw up.
> Ruby
Ruby's syntax makes me want to gouge my eyes out -- it's every bit as bad as Perl. I'm an expert and I hate Ruby. I wouldn't dream of exposing beginning CS students to that crap unless I wanted to convince them to change their major.
> Scratch
This is a toy language in a toy environment. I don't know the language well enough to judge its syntax, but the author's goal is "...rather swiftly bringing [students] to a level of skill where they can use computing in their other courses: to analyze data for those lab reports, to learn linear algebra, to solve problems in particle mechanics, problems involving differential equations, maybe even to write a program to control a robot." Scratch doesn't seem well-suited to this role, but there's enough language and library support for Python to be used in all these roles and many more.
From a non-superficial standpoint, you haven't brought up a single thing wrong with Ruby— or Go, aside from explicit typing.
The thing about syntax is that, to some extent, it's subjective. You say Ruby syntax is awful? OK. Personally, when I first started programming, I hated Python syntax¹ so much that I called it quits. It wasn't until later, when I started learning Ruby and its "eye-gouging" syntax, that I could get past that hurdle. So I wouldn't exactly describe its syntax as an argument against using Ruby as a teaching instrument.
¹I've since grown to love it, but as a beginner this was very much not the case.
There are two things about syntax that I think are actually objective. One is that, when beginners read their own source code that isn't working, they often have more of a tendency to read what they intended to write instead of what they actually wrote, especially when it comes to punctuation symbols.
This means that, when the indentation is right, but there's a missing -- or extra -- brace or semicolon, it can be very, very difficult problem for a beginner to even see. It's also possible for a beginner to write a program with many instances of brace/semicolon issues, giving a frustrating (and sometimes bewildering) boatload of syntax errors.
The second problem is that it's difficult to remember the meaning of symbols. This is true not just for beginners, but also for experts learning a new language with different symbols. This means that the number of symbols in a language should be kept to a minimum. Furthermore, where possible, symbols identical to those used in other languages, or in mathematics, should be used. Where a language has novel ideas that don't exist in other languages, those ideas should usually be expressed by keywords, not symbols.
Ruby fails at this. See [1] for an example. I don't mean to pick on this particular project, rather this file is typical of Ruby code. The file contains the following symbols which seem to be used differently from any language I'm familiar with: Less-than sign used in class declaration, use of colons for thing(s) that are neither dictionary literals nor labels, "absolute value" bars in e.g. { |p| p.id }, shift-left operator used in class declaration, question mark used for something besides ternary operator, lines without side effects like "true" and "false" sprinkled throughout the code (is there some "empty operator" that's applied to these lines to give them side effects?).
My point is that neither a beginner, nor an expert in non-Ruby languages, can understand the above code without constantly consulting the documentation for the unfamiliar syntax elements (and good luck figuring out how to search for "meaning of -> operator in Ruby" without knowing what the -> operator is actually called!) Whereas most Python programs read like pseudocode and can be reasonably well interpreted even by someone quite unfamiliar with the language.
Good languages address that problem by limiting the number of symbols, and making the meaning of symbols as simple and intuitive as possible. Ruby fails utterly on both counts.
I think these facts should be simple and obvious to anyone who's ever attempted to learn either Ruby or Python, but I guess this is HN, where an amazing number of people think Ruby is the bees' knees for no reason I can make sense of.
[1] https://github.com/gitlabhq/gitlabhq/blob/2a8aa7429b6f489acd...
Thanks for the detailed reply. Those are all good points.
It's worth pointing out that a lot of Ruby's oddities (specifically :symbols, predicate_functions?, and implicit returns) are stolen from various Lisp dialects— which is also true of a lot of significant semantic/cultural differences between Ruby and Python.
So you could argue that the syntax differences are just a surface form of the underlying semantic differences. But that's kind of cheating (except for the implicit returns, which is a straight-up semantic difference). Maybe the better point to draw is that there is a background (Lisp) in which its syntactic quirks make sense. As an expert, the fact that that background is an unusual one is a negative for intuitiveness. But as a beginner, with no backing in Algolesque languages, does it really make that much of a difference?
Of course, none of that gets into the plain syntactic quirks— ->(pointy){lambdas}, {|block|syntax}, and so forth. But every language¹ has some of those— good luck making sense of Python decorators when starting out, or for that matter list comprehensions. Or non-paren-enclosed-tuples. Ruby's are used more heavily, but that seems more like a cultural difference than a syntactic difference— generally Python favors readability ahead of 'elegance', and Ruby vice-versa, which extends to making heavier use of special syntactic forms.
¹Except Lisp dialects, ironically! But even there, `(there are ,still some . peculiarities).
Imagine that post being about PHP vs. assembly and thus pushing PHP, or about Java vs assembly and thus pushing Java, or...
Again how is "the whole purity thing" an overhead w.r.t. to learning the fundamentals ?
If you take your loop example in Python, how does leaking the `i` variable outside the loop's scope (actually there is no such scope) a fundamental that beginners need to grasp ?
What would you say about `map f [0..2]` ?
So Python makes a lot of things easier than in C or in Java I get it. That in itself is not an argument for teaching it instead of, say, Haskell.
If you can choose between A, B, ... Z, sure it is better to use B if it is better than A, but not choosing F because you never use it is a wrong reason (at least if your goal is to teach students).
At various work places ive been to, the vast majority of coders know python or ruby or similar languages. They have NO CLUE how the memory is allocated, why some things in python are slower, etc. At some point they go 'its python runtime overhead'. But most of the time they could make the program much faster just by using better data structures in python. Most of the time they don't understand why something doesnt work the way they want and basically pray to get a premade answer on stackoverflow. While they could figure it out much faster by understanding how their machine works.
C has the advantage of being close enough to what the OS does (heck even C isnt always that close with compiler optimizations but - ok). Forces you to understand how the kernel works, how the CPU works, etc. Makes you a better python programmer too.
I don't even really agree with learning Python first. If you can get over the hurdle that is learning C (or really even just Java), you have the benefit of learning so much more about computing and the fact that types are implicitly being adhered to, memory is being managed beneath the surface, garbage collection, etc. I learned Java for my intro programming course and luckily had an instructor who really emphasized those topics. It made learning C and subsequently assembly much simpler. Had I started in Python, I don't see really learning much more than "wow, I can do some cool things with a computer." I suppose that's okay if the class is advertised as programming for non-CS majors, but to teach Python as an introductory course for CS curriculum seems almost like robbery to me. Jump the initial hurdle of learning the (somewhat) low-level stuff, and then the rest will come easily.
Personally, I barely learned enough C to even be dangerous, and it's had no negative effects on my work. I have a reasonably good understanding of how Python works at the abstractions that I need to. If I need to learn more, I go figure it out. In truth, the most useful stuff I learn about writing efficient code comes from reading articles/blogs that give medium-level overviews of how a language implements certain features and how it effects your software. Would knowing C help with that? Not in the slightest.
I don't feel that my curiosity was permanently damaged by learning Java. On the other hand, I wouldn't have necessarily have wanted to learn anything about lower-level languages for its own sake, except perhaps only out of some sense of duty that 'every programmer should know this and that'. But since I have an interest in programming languages - which I of course didn't know that I would develop when I was learning my very first programming language - these things became relevant to me later.
One is the specification of a process in algorithmic terms - the abstract, but rigidly defined sequence of transformations on input data into output data. This is a field of mathematics.
Two is the building of a physical system to take input data and produce output data, these days by configuring a complex machine comprised of many different pieces of silicon, each of which takes a string of bits and understands a concrete machine language. We have built a high tower of abstractions, so many different silicon-based computing machines can be programmed the same way without programmers going insane. This is a field of engineering.
You need to teach both. They are two completely different skillsets and a successful developer needs to understand both sides - the mental tools necessary to make algorithms, and the engineering skills necessary to make machines that implement algorithms. You don't start from discrete mathematics and then proceed to trying to bang them inside a computer, nor do you start from silicone and then pretend this is the basis for algorithms.
Both are starting points and you need to approach both as their own thing, not a continuation of the other. To this end, it would be for the best to teach both C and Python at the same time. I find that the two aspects of programming are their own mindsets and things learned in the beginning of each don't really carry over to the other.
And then hope the student can put one and two together.
Now, almost a decade later, I'm still writing Python. Sure, I write my share of Javascript like most people, but Python is my first and true love.
Python is shallow. There isn't a lot to it - once you understand how magic methods work, you're pretty much at the point where reading the source of the implementation is the next step in understanding.
It wasn't long before I found myself learning the specifics of C data types in order to understand exactly how Python types worked.
In short, my contention is that someone who wants to become a better programmer will become a better programmer regardless of their preferred language.
This is why Python wins. It has lower cognitive overhead, and the ecosystem is otherwise good enough to build complex projects.
Though I do wish Guido went with a variable declaration keyword in the beginning. The global/nonlocal stuff sticks out like a sore thumb.
My first programming language in college was Scheme and I could use exactly the same words to describe my experience.
The fact that they have to "fix" the language in one version making it incompatible with previous versions is smelly enough to me from a design point of view.
Honestly I think a lot more languages (cough, Java, cough, cough) would benefit from breaking backward compatibility (occasionally, like every 10-15 years) rather than force it to maintain cruft that no longer makes sense to keep.
I was learning to program around the time when php and classic asp were gaining ground (1996)... php had far more to offer for free, but the utter inconsistencies irked me to no end, and still do.
By quickly he meant from the process you start learning your first programming language to be able to make money with that language.
I agree in that a bunch of people I know started out with Wordpress or even Joomla, and managed to get a site working for a paying client relatively quickly. And making money was a great motivator for them to get better, and 'grow' out of php, or at least start using better CMS' or frameworks (or write their own wordpress plugins). I've found that especially designers who 'know a bit of html' seem to get pretty far with Wordpress and a bit of jQuery they copy and paste.
The result is usually an abomination in my eyes, but hey, if they're getting by doing it, and especially if it's a gateway to getting better at actual programming, why not? That's how I did it!
But I I also partly disagree in that I've also met quite a few web 'developers' who did so well 'snippeting' their Wordpress/joomla sites together, that they never moved beyond that and eventually succumbed to fierce competition. Because now they're competing with non-programming designers who can build fancy looking websites with cool interactivity, and are better at making it look good.
Because I've seen both good and bad come out of it, I usually try to gauge what kind of person I have in front of me when they approach me for help or advice.
If it's someone who doesn't seem to have the inherent curiosity to become a better programmer, I might just help them set up their first wordpress site and do my best to keep them from doing too much 'damage'.
If I do see a bit of curiosity, I try to gently steer them towards other solutions (Middleman + heroku, or Ruby on Rails for example) that are a nice midpoint between some 'coding' and seeing quick results.
And if I think I have full-blown future programmer in front of me, I just throw tons of stuff at them, usually right in the browser dev console, (closures, callbacks, functional-style programming) and relish seeing them try to figure it out and go home and tinker with a Fiddle! Those are my favorites.
I took another look at Groovy again recently (haven't played with it since version 1.8) and i'm beginning to feel that i should have invested more time in learning/adopting it back then. The only drawback for me was the resource requirements of Grails (and the JVM) but now that Linode is giving 2gb ram for $20/mth, the attraction to Groovy is getting stronger lol!
Standalone groovy scripting isn't used as much nowadays either. I suspect Oracle's going to push Nashorn Javascript it shipped with Java 8 for your JVM scripting needs.
Groovy has been getting lots of new users because of Gradle's increasing popularity, though your typical build file is 20 to 100 lines long. Gradle still ships with Groovy 1.8 anyway so you haven't missed out not keeping up!
Then I started working in a research lab myself, and I haven't used Python since. Very simply, there's an immense amount of code written for Matlab that I can learn from in domain-specific instances, hardware vendors provide Matlab example code (and not Python code), and all of my peers use Matlab. When I have a problem they can usually help me solve it, if I'd been using Python I would've been all by myself and likely unable to finish the task.
And really, these are the most important things to consider when choosing a language. As it stands, Matlab is the right language to choose, at least for me.
But Python is becoming the lingua franca of scientific computing, owing to great open source tool and libraries. Very soon hardware vendors will always provide python example code, python "drivers" or REST-like APIs.
I don't say this lightly, and this statement is hardly ever right, but in this specific instance, Python is clearly the better "language" compared to Matlab, even in scientific computing. The syntax and quirks in Python are more consistent than in Matlab and general programming is a lot easier.
What field are you in, if I may ask?
Having said that, I had a similar situation at my research lab and have now almost replaced Matlab.
This process was mostly organic, starting with me changing my personal post-processing workflow when I switched to IPython Notebook as a logbook and plotting library (i still use gnuplot occasionaly).
Soon I started having to port bits of Matlab and C code to Python and Cython to allow me to continue using the logbook, and I found I was becoming a lot faster at creating new modules and tools, mainly because the programming component was now intricately linked to my workflow (and more fun)
The tipping point was when I converted a notebook into a slideshow for a presentation I had to do for the group. Everybody was more interested in how I made the presentation then in my results, and wanted access to the new tools. I provided them with the git repo (and git tutorial), gave people notebooks I had written to log coding practices and demos of my code (I have poor memory) and encouraged people to contribute back.
Getting people to contribute back is still the hardwork: Everyone is shy to share their code, but the Professors starting preferring IPython Notebooks. New code is now usually written in Python first, and sometimes ported to Matlab and even the hardcore Matlab researchers are starting to show interest because of the speed and flexibility of the new code.
Basically, I found Matlab is definitely replaceable - and can only improve workflow (speed it up if nothing else). There are a few instances when specific hardware requires Win driver access through a Matlab plugin, but there are ways to interface with these too.
Learning something new is hard, and Python is easier for students to learn.
Really, the ease of learning should trump almost everything else. Especially since Python is actually used in the real world, so it's immediately applicable.
You want students to know more concepts they won't get from just Python? I agree with you. Just not as a first language.
Above all, get them interested. If you capture their imagination, they'll be receptive to--even independently curious about--the details.
I'm speaking anecdotally now, but please do not bore young students. There's no way I would have stuck with it if C was my first language. Javascript and Python are excellent starting points that easily let kids create games and websites and fun things.
We probably wouldn't start someone off with Haskell, but to me C seems on the same level of impracticality for a young beginner.
Yes, every programmer should eventually learn about the things you're talking about. But C is a terrible first language.
So I totally agree. Python probably makes sense if most undergraduates don't have programming experience any more. And the ones that do probably have experience in JavaScript.
*CPython's list type is really a dynamic array, and it works better as a stack. However the interface is similar enough to a typical linked list, that it gets the point across.
You might as well start with the stuff that is common to most of (contemporary) programming.
Python suffers from this less than C, but still much more than Scheme. I really can't imagine advocating for something other than some dialect of scheme (maybe racket) for an intro undergraduate course.
For kids I can see choosing something like Javascript (as terrible as it is) just for the immediate feedback that someone before me mentioned.
These students are there to learn programming as a tool to help them solve problems. The elegant recursive algorithm isn't really a goal they have. Their goal is to get a reasonable answer to a problem so they can move on with more important things.
Those things I mentioned are how you solve problems though. What I was getting at is learning the low level details of how a computer, or at least C, works isn't problem solving.
Agree 100%
That is the point. This isn't for comp. sci. students, this is for engineering students.
I know that in America, unlike other countries, "engineer" is a non-protected term and that lots of guys who don't actually have engineering degrees (such as comp sci majors) call themselves engineers.
But "actual" Engineers, i.e. the people who have engineering degrees or are in engineering programs, the people to whom this article pertains, are applied scientists. By definition, their professional concerns aren't the inner workings, or developing a holistic understanding of computers. That's for a specialist, i.e. a computer scientist who has more appropriate training. An engineer's job is to develop a solution that surpasses the design requirements (physical as well as budgetary) by the minimum amount. As a crude example, anyone with a high school education could, with unlimited funds, build a bridge that would stand up. But only a trained structural engineer can build a bridge that will just stand up.
I'm a mechanical engineer, and for people in my field the programming aspect is most often a means to and end; you're writing a simulation to give you better insight into solving a physical problem, or you're writing a program to crunch a shitload of data, or you need to plot things and present them in a particular way or output the results to a particular tool, etc. The performance of the algorithm or your code is not really paramount. If it's "good enough" then it's good enough, because the code you write is just another tool in your toolbox along with your digital multimeter, your impact driver and your wrench.
I recently wrote a quick one-off to iteratively determine the asymptotic limit of a set of physical functions with many interconnections and shared variables, subject to 4 different constraints and involving numerous irritating physical constants.
To write that program successfully, I don't have any need whatsoever to understand the intricacies of file IO, the specifics of how libraries are linked at compile time, or how the print function actually prints to the screen. All I need is for it to print a number to the console so I can compare it to my far rougher hand calculations. Anything else is a waste of my time.
Had I written that one-off in python, the knowledge that "print prints things to the console" would be perfectly adequate for me to do what I need to do in order to move on to more important things. The inner details just aren't important.
Then again... You mention that the job of an "engineer" is to "develop a solution". Well, that's pretty much what a software developer or software engineer would do. They're all grey, and it sounds like you're not quite sure of your own definitions. I can't tell if you're just confused about what all these terms mean to you, or you're just hurriedly trying to justify your own internal view of superiority over "non-engineers" because you're a "mechanical engineer" and don't like being on the same plane as them.
All in all, I should probably disclose that I've had this argument a few times with "engineers" in the physical sciences. They all had a vested interest in protecting the term engineer because if they didn't, it would devalue their worth and the degree they hold. And the government-body given "accreditation" that they lord over people for higher pay.
I am.
>Then afterwards you go on to claim that computer scientists aren't really "engineers" by your definition.
They're not.
At least, not in Canada. It's against the law to call yourself an engineer if you don't actually hold an engineering degree from an accredited institution.
>I can't tell if you're just confused about what all these terms mean to you, or you're just hurriedly trying to justify your own internal view of superiority over "non-engineers" because you're a "mechanical engineer" and don't like being on the same plane as them.
That's your problem. I'm not confused in the slightest nor do I feel superior. Different skills for different areas of focus.
I specifically referred to computer scientists as "specialists" having more appropriate training. If you're upset because you can't legally call yourself an engineer in my country then that's not my problem.
> They all had a vested interest in protecting the term engineer because if they didn't, it would devalue their worth and the degree they hold. And the government-body given "accreditation" that they lord over people for higher pay.
Sounds like you're the one with an inferiority complex here. I like how you put "accreditation" in quotes as if to imply that accreditation is not really worth anything. That's very mature. The term Engineer is protected in my country due to very real issues of public safety. You don't want someone certifying a skyscraper as safe, only to find out they are an architect, not an engineer, and therefore weren't trained in structural dynamics, metal fatigue, stress analysis, etc. If that architect wants to be able to certify buildings they need to demonstrate competency to the regulatory authorities by completing an accredited program.
You know how they say "don't roll your own crypto, leave it to the experts"? Same thing.
I am.
I think that's just a ridiculous way of referring to engineering. If we're going to be strict about the term engineer, we might as well be strict about the term scientist and pounce on anyone calling themselves a scientist, applied or otherwise, if they haven't submitted articles for peer review. How many members of your graduating class of applied scientists have been peer reviewed?
They're not. At least, not in Canada. It's against the law to call yourself an engineer if you don't actually hold an engineering degree from an accredited institution.
Protection of the term engineer in Canada, for any old BSE, is ridiculous and is inconsistent with conventions in most of the rest of the developed world. It's largely ignored by industry, frequently 'violated', and protects no one - certainly not the public at large, at least. What really needs protection is the title P.Eng, which actually is important to the safety of the public.
The term Engineer is protected in my country due to very real issues of public safety
P.Eng. yes - but a BSE? Should the full force of law really be brought to bear on someone who might be confused with having earned a BSE by calling themselves an engineer? Who does this protect?
You don't want someone certifying a skyscraper as safe, only to find out they are an architect, not an engineer
Yes - and that would be a licensed, legally entitled, and legally cupable P.Eng., not some random BSE.
Edit - for the uninitiated, P.Eng. or Professional Engineer is a legally protected (in Canada and the United States at least) title given to a graduate of an engineering program who has been through an industry mentoring process, has taken competency exams, and has taken a professional oath of ethics. These are the men and women who keep our bridges from falling down by saying 'no' when someone wants to cut corners or reduce expenses. Many projects, especially in civil engineering, require the sign-off of a P.Eng. A P.Eng. is also legally culpable if they knowingly approve of something that they shouldn't.
A BSE is someone who graduates from an undergraduate engineering program.
I think it's pretty obvious that I meant P.Eng but didn't want to get into it for brevity. Not everyone knows the difference.
Sorry you're butthurt.
That's a pretty major thing to omit considering the argument you were trying to make. Keep shifting those goalposts.
>Sorry you're butthurt.
For being an engineer, you're certainly very immature and appear to lack the critical thinking skills required to engage in an argument with valid points.
Some isolation is necessary. I doubt that I could completely explain how either print or printf turns the pixels on and off on the display.
You could just give
as the hello world that covers functions(main/print), entry points(python runs the code top to bottom defining classes and functions at the top level and running any other code it encounters, to allow importation of libraries we put the code we wish to run in a special block that only runs it when the script is the only being directly run, not imported), we imported os and used os.name to demonstrate a library, + is an operator.My main reason for the switch is to overcome the "What's the point of this?" questions that I used to receive. With JavaScript the kids instantly see a result on a platform they're familiar with - a browser. window.alert() is instantly recognisable to them and seems far more relevant than print"" where the output is only visible in a terminal or IDE.
Eg. > [2,1,3,10,6, 200].sort()
[1, 10, 2, 200, 3, 6]
is both unexpected, and is just one of many landmines that can completely derail beginners.
I would argue there is a justifiable reason. Before I do bear in mind I accept it may not be a good reason, or one without workarounds, but hindsight makes both of those much easier to see than in the day to day development.
Backwards compatibility. The two words which really haunt web developers everywhere, on so many levels. We don't want old sites to break in new browsers, or new sites to break in old browsers, so fixing major issues of such magnitude would require at a minimum a unique version that could be differentiated from older sites. And when was the last time you saw a version of javascript specified in a websites code?
So then a situation occurs where we could use the new code and "do it right," but we would need fallbacks for old browsers. Or, we could "do it wrong," only use the old way, and development would take significantly less time. While over time the new way likely would win out, it would be a long and drawn out process taking enough developers and managers putting their feet down and saying, no, while this will take more time, cost more money, for the exact same functionality, it is the right thing to do for the future of the language. And getting their bosses to accept that tough sell.
The above seems very similar to HTML5 and IE6/7 support. And how long has that fight been going on?
So yes, one would think the flaws should be fixable, but looking at it from an in the moment perspective as opposed to through the lens of history, it isn't completely incomprehensible as to why they still exist.
Another thought that just popped into my head, is for the majority of the life of javascript, it was used by web developers, many of whom would by todays standards be much closer on the spectrum to "my nephew who designs websites" than a software engineer. It wasn't until much more recently that it began to heavily be used by engineers who pushed the limits much further and ran into these problems. It makes me curious on when the first documented case of these issues was brought up. Was it 20 years ago, or maybe only in the last 5?
C was hard for some kids to grasp in my high school class, but I didn't struggle with it, and it certainly taught me rigor and attention to detail. Ruby (on and off Rails) helped me build things without getting bogged down in syntax; the LOC-to-output ratio was quite gratifying. Only later did I progress to writing non-trivial Javascript.
While it's an incredibly powerful language (when I hear people describe the "enlightenment" of developing in Lisp, I'm often reminded of JS), it has a lot of warts that, as you rightly stated, can throw beginners for a loop. I imagine that if I had encountered the example you described above at the beginning of my career, I would have decided that Javascript is for the birds and resolved to just write C/C++ for the rest of my life.
http://marcscott.github.io/7-WD-JS/
I'm sure there are better offerings out there though.
One option to make js a little easier to start with is to install a CoffeeScript plugin. Not sure if it's a good idea, but it's an option.
Also, one nice side-effect of getting them started on javascript is that learning another language (ruby or python, perhaps), is a wonderful next step because suddenly you're using a much 'friendlier' language! Whereas if you start with that, having to deal with js can be frustrating.
For an undergraduate level course I would prefer teaching Scheme or C in an introductory class.
This is the subject of some extended discussion in the new PEP proposing a Python infix operator for matrix multiplication. http://legacy.python.org/dev/peps/pep-0465/
I grew up using a Borland C++ compiler that didn't list which line numbers were missing semi-colons. I didn't mind going over my code to find the missing semi-colon, but plenty of my classmates were frustrated. They weren't interested in how compilers worked, how code was parsed and debugging information was lost in the transition. They just wanted to build a game, a web site, something.
At college I had a difficult time with Scheme and looked down at it. Where's the manual memory management? The pointers? The for loops? Scheme abstracted away a lot of plumbing and let users focus on algorithms.
Nowadays I think Python is the ideal first language followed by C and Haskell. It's starting in the middle, and then moving towards opposite ends of the programming spectrum: systems and functional programming.
Some make the argument that CS students should be dedicated enough to plow through an introductory course taught in Java / C++. I think that's an elitist attitude. CS is not growing in popularity despite increased demand[0], and new students should be welcomed instead of facing artificial filtering measures like "dedication". At the same time, this is not a proposal to water down the major--just a plea to ease students in instead of kicking them off a cliff and hoping they can fly.
Edit: Another front page article (https://news.ycombinator.com/item?id=7760790) discusses this issue:
> One might also argue that these tools are simple enough once you learn to use them. I would only point out that, emperically, that bar is too high. Despite the clear benefits, the vast majority of the world was chosen to remain illiterate. Even tools for which there is a clear need (eg version control) have largely failed to make a dent. Clearly there is a need for a less hostile programming environment.
[0] http://www.itworld.com/big-data/418701/american-college-stud...
I agree. My friend studied CS at UC Berkeley where (at the time?) first semester was Scheme, second semester was assembly language, and then subsequent classwork was usually C++ or Java.
My 200 level data structures and algorithms class was taught in Python, and it just felt awkward. For example, we constructed an "array" by basically creating an abstraction on top of a list, which did nothing but remove features and introduce overhead. It kind of felt like teaching someone how to make a bike by taking all four wheels off of a car and only putting two back.