Why I push for Python
lorenabarba.com
lorenabarba.com
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.
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.
http://marcscott.github.io/7-WD-JS/
I'm sure there are better offerings out there though.
import turtle
For an undergraduate level course I would prefer teaching Scheme or C in an introductory class.
My first programming language in college was Scheme and I could use exactly the same words to describe my experience.
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.
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.
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.
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.
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.
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%
a = [1,2,3]
b = a
b += [1]
=> a == [1,2,3,1]
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
from __future__ import print_function
import os
def main():
print("hello world from:" + os.name)
if __name__ == "__main__":
main()
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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?
Imagine that post being about PHP vs. assembly and thus pushing PHP, or about Java vs assembly and thus pushing Java, or...
for i in range(0, 3):
for (int i; i < 3; i++)
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).
Deleted comment
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 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!