Python is now the most popular introductory language at top U.S. universities
cacm.acm.org
cacm.acm.org
If we then look at the table of actual data to filter a little bit, the story changes. There are certainly some schools, big ones, that use Python in CS1. But a lot of the Python representation is coming from CS0 at schools where CS1 is taught using Java.
(I can also clarify one of his other comments: he says of the AP exam using Java that "it's unclear whether that will change anytime soon." This is untrue. It will not change in the next 3-4 years at the very minimum---and that would be the time frame if the College Board said right now today that a change was happening. In fact, though, although the idea's been mentioned, there has been no study or apparent motion on that front, so a more realistic earliest-date-of-change would be around 2019 or 2020. And I wouldn't count on it, given how many CS1 courses are still taught in Java.)
As an example, take Northwestern. At Northwestern there are several intro routes you could take, depending on your major. CS Majors are not required to learn Python - it is used in some 300-level classes but not in very many 200-level classes (although that may change in the coming years). I've actually taken classes with projects using Python without ever taking classes teaching Python. CS majors will likely take C, C++, Java, MATLAB, or a variant on scheme for their first language, depending on which sequence they take, whether or not they are double-majors, or course scheduling.
In contrast, non-CS majors may learn C++, Python, MATLAB, or a variant of scheme as a first programming course, depending on why they are learning a programming language.
So while schools like Northwestern may offer introductory courses in Python, I think the truth is more something along the lines of "students may learn Python, or they may learn any of a number of different languages as their first language, depending on what their academic goals/requirements are."
A fair point of warning is that, having been at Georgia Tech 2008-2011, most of my friends in engineering and physics freshman year hated CS 1371, and spent many a late weeknight complaining about Matlab. The common wisdom, often picked up too late, was that engineering students would have a better time if they switched into the Python course, iirc CS 1301.
For my part, I had placed out with AP credit, but took CS 2110 using a combination of LogicWorks (circuits), LC-3 assembler and C. I thought it was awesome; that course is probably the reason I have my current job, but many of my friends never considered taking another CS course, or only did so several years later, because they hated Matlab so much.
Ask any non-CS Engineering professor interested in engineering undergraduate education whether engineers should take an intro course using Matlab or Python, and they'll always say Python.
This argument seems pervasive across many institutions.
I'll address each of your paragraphs in turn:
1.) Re: CS0 vs. CS1. Like you mentioned, I was very upfront about the methodology for this analysis. And I am very aware that most CS majors do not ever take a CS0 course. But please also be aware that there are a minority of CS majors that do take CS0 before moving onto CS1, usually because they feel ill-equipped to take CS1 right away. I harp on this point because even though this is a minority population, it's a very important one since those are students who, without CS0, would not major in CS. These students are more likely to be female or from underrepresented minority groups. On a related note, a larger and larger fraction of non-CS majors are taking CS courses because they recognize the value of programming and computational thinking. (Again, these non-CS majors are more likely to be female and from underrepresented minority groups.) So I would argue that CS0 is just as important as an "introductory programming" course as CS1, if not more important, due to the rise of the non-software-engineers-who-want-to-learn-programming population. [Edit: And I think that a CS department's choice of language to offer to the CS0 student population is still very significant, and a decision that is not made hastily.]
2.) Re: Python CS0 and Java CS1. You are absolutely right, and in my original article, this sentence appears in the discussion section: "Some schools have fully switched over to Python, while others take a hybrid approach, offering Python in CS0 and keeping Java in CS1."
3.) Re: AP exams using Java. Thanks for the clarification. I will remove "it's unclear whether that will change anytime soon." from the article.
[Also, as to cyorir's comment that the chosen data may have been cherry-picked, please rest assured that I tried my best NOT to cherry pick. If I had cherry picked, wouldn't I have made Python look even better? ;) Any incomplete data is strictly due to human error or oversight on my part, and I gladly welcome any correction requests via email.]
None of this is to deny the fact that Python is highly popular as an intro language.
As for your point about Penn's CS120, I guess I don't fully understand the criterion. From the way you described it, CS120 seems like a CS1 course: not for someone who has had zero programming, but the very first course taken by most CS concentrators.
FWIW, I spoke to Benjamin Pierce about the structure of the course, and he said he didn't want to use "Real World OCaml" because it's too early of a course: he has students who he thinks don't yet understand things like what a scope is. From the sense I got from him, it's quite early in the curriculum.
That said, this is mostly minor quibbling. I think there's little doubt that "very early" courses, for some reasonable definition of "very early", lean towards Python. And reasonably so.
CS1 is intended for non-concentrators or people with very little prior CS experience.
CS50 is the standard intro course that most CS concentrators (or people considering CS as a concentration) take. Although it's taken by non-concentrators, most of the non-concentrators taking the course do so because they're in some field that has a lot of exposure to programming (e.g. Applied Math).
CS51 is the "advanced" intro course and is usually not the first CS course a CS concentrator takes, if for no other reason that it's not offered until the spring semester.
i wish the blogging platform supported some version-control friendly format.
[Edit: I made a typo about Penn CS120 ... I mistakenly found another course named CS120 that wasn't at Penn. Also, Harvard CS51 calls itself "Computer Science II" [1], implying that it's a CS2 course. It probably has CS50 as a prereq, tho I haven't double-checked yet.]
[1] http://cs51.seas.harvard.edu/docs/lectures/2013/1-overview.p...
CIS120 is the course for students who have some programming experience, and probably falls under CS1. I had taken AP Java AB before and was overprepared for the old (Java) version of the course. The current course teaches basic data structures and uses Ocaml.
Indeed, I expect that when they're broken out, Python will be the overwhelming top choice for CS0, and a respectable second in CS1; but then, that's not as big a change as you might think. I'd be surprised if Java was ever a majority or even a plurality in CS0 courses. One subgroup of what you're calling CS0---the ones focussed on programming, often called a "service" course and targeted at engineering and science majors---have long been using things like C or Matlab, and never really had a strong movement towards Java. The other subgroup, what I'd call the "true" CS0 (i.e. based on what the ACM/IEEE curriculum guidelines used to call CS0) may have had no programming at all, or if they did, a short unit in a relatively lightweight language, certainly not Java.
Basically, the things that make for a good language in either kind of non-majors course are not always the same as what makes for a good language in a intro-for-majors course. That doesn't make the non-majors course unimportant and it doesn't mean that decisions are made hastily, but it's still not super helpful to conflate the two.
How prevalent is the REPL in CS education?
Does perceptualization play a role?
ideally you want to mix the best of both worlds. here's a prototype demo: https://www.youtube.com/watch?v=Q3oarDuZPL0
I'm curious - would the group be less important if they were less likely to be female/non-asian minority? I get this impression from your text, though you don't actually state it explicitly. As a result I'm curious what your actual view is.
You can delete this sentence -- These students are more likely to be female or from underrepresented minority groups. -- and the meaning of the previous sentence remains unchanged. The key point is that CS0 is important for attracting people who didn't have prior background in computing and thus could have a latent interest in CS that would otherwise go unmet. Now, it turns out that a larger fraction of those students are from certain underrepresented groups, but even if that weren't true, it wouldn't make the case for CS0 any less important for the "group" that I think you're referring to, which is "students who have latent interest in CS but not enough prior exposure to know that they would love CS." (I wish I could've expressed that in an elegant mathematical equation!)
[Edit: when I wrote "even though this is a minority population", I didn't mean "minority" in the underrepresented minority sense ... I meant that this is a small population compared to all CS majors. Again, English != set logic]
I couldn't tell if the sentence was meant to support your main argument ("we should help group X because lots of non-asian minorities") or if it was merely a curiosity that was irrelevant to the main argument ("ooh look, lots of non-asian minorities, statistically unlikely therefore interesting").
[Edit: I'm not eloquent enough to make a convincing case at 2:20am, but I don't think that extra sentence was merely a curious non-sequitur, even if it could be cut without modifying the point of that paragraph. I can list out tons of points/counterpoints in my head ("what about redheaded people with thin left eyebrows? why not mention them? would that be a non-sequitur? what about the historical and socioeconomic implications behind this demographic group and its relationship to technological access? ..."), but I don't have enough expertise to give this topic a proper treatment. So I'll leave this thread by recommending the following two books:
http://www.amazon.com/Unlocking-Clubhouse-Computing-Jane-Mar...
http://www.amazon.com/Stuck-Shallow-End-Education-Computing/...
]
As a clarification, a CS0 or CS1 course usually has no CS prerequisites, so if a course you're trying to mention has other CS prereqs, then it's probably not CS0 or CS1.
ha, feel free to DOWNVOTE so that this appears at the very bottom, so that it's visible :) but don't downvote so much that it disappears.
http://python-history.blogspot.ca/2009/02/early-language-design-and-development.html
I just remembered some people i learned with who struggled along time to get behind the concept of pointers and how to use them when they thought us c/c++ as an intro language to programming.
C++ would be absolutely horrible. Is anyone doing this?
But that's not how languages have typically been selected for 15 years or so. The direct vocational skills argument has held much more sway.
But every place isn't MIT, nor is every course a common core requirement for a college or department with diverse majors. Does a civil engineering student really need to implement lazy evaluation?
Felleisen's paper and subsequent book as well as the work of the PLT group show the current state of Scheme as a pedagogical language.
http://www.cs.brown.edu/~sk/Publications/Papers/Published/ff...
Nope, MIT has an introductory computing course that logically goes before 6.001-4 or the new 6.01-2. For a long while they didn't have one due to resource constraints, they dropped this service course about the time 6.001-4 was developed, but other departments had their own more domain specific introductory courses (see below for more details).
6.001 was canned and Scheme completely purged from the undergraduate curriculum for political reasons, after the Department, and likely School of Engineering and the Institute itself panicked when the dot.com bust more than halved enrollment, after it had been 40% of the undergraduate class for decades. Oh, yeah, after the Institute had also blown a quarter billion dollars in a not very functional new building for the EECS research labs.
"... and were there as because of a common core curriculum."
That ignores that MIT's EECS department has for a very long time insisted that EE majors have serious programming experience, and CS majors the same for hardware. 6.001 programming, 6.002-3 hardware, 6.004 both, all majors had to take all 4. This was true but less coherent in the '70s before that common core was developed, and it's still true with 6.01-2 which combine both. MIT's EECS department started as an EE department, this is not an unusual approach for such, vs. ones that started from the math side or otherwise independent of EE. If you want pure CS, you shouldn't go to MIT or U.C. Berkeley, but to CMU or Standford (or so I gather about the latter three).
"Does it really make sense to teach such people to write language interpreters in an introductory course?"
Yes, if you want them to really understand what it's all about. Since it's Lisp, that's also much less intense than it normally is, essentially all the colossal parsing messes with other language families can be skipped thanks to its S-expression syntax, and you can focus on the very basics.
As for e.g. Civil Engineers, MIT's Civil and Environmental Engineering department has its own 1.000 and 1.001 courses for its type of computing, and as I remember that was true way back when 6.001-4 was developed. In the late '70s 4 or so engineering departments got together and got VAX11/780, which they used for their own education etc. purposes, while EECS later procured first a DECSYSTEM-2060 (which had a CPU twice as fast, but a max of 1 MiB address space), then/in addition HP 68000 workstations (eventually Project Athena took over this sort of duty, I think).
Finally, whatever the pedagogical merits of Scheme and/or SICP/6.001, Python is now winning due to fashion rather than merit (although it does have some merits compared to other languages that could and are often used like Java).
Basic use of scheme requires you to think recursively. If you have that, scheme gives enormous power for a small investment of learning, thinking and typing. If you don't have that, you need to deal with that before you can use scheme.
You could take a group of elite students with a math/physics background and have some confidence that their grounding in mathematics and physics will have prepared them, or that it will be a short and healthy jump for them.
But it would be bigger hurdle for other groups. Python is a useful because you can ease people into this kind of thinking. And people who aren't there yet can still get things done.
Regarding SICP, even in early chapters, it requires you to understand maths concepts that wouldn't be available to you even if you were a professionally-employed person returning to to university. The Little Schemer path would be a better intro for groups without that.
https://docs.python.org/2/reference/datamodel.html#emulating...
Or, the earliest I could quickly find:
https://docs.python.org/release/1.5/ref/ref-5.html#HEADING5-...
The access pattern is probably the right aspect to make consistent (at least in the context of duck typing). If the access isn't generalized across various types they might as well use named methods.
edit: I corrected the anchor in the second link.
So the question is really: can you use Python to get most of the benefit of teaching using Scheme while at the same time giving the student a practical tool for future use? I haven't taken the new Python courses, so I don't know how well the material bends to the language, but I remain skeptical of the "most of the benefit" part. Maybe I'm just a curmudgeon, but I sort of think they should keep Scheme and then just have a short (e.g. over IAP) course on practical programming techniques using Python (or whatever). Or maybe someone should rewrite SICP in Clojure? Finally, I know Scheme has continued to evolve, and I wonder if it's really still true that Racket is impractical as a day-to-day language.
It's relatively new, but I'm really excited about it, and that is what I'm learning, it allows you to get the benefits of learning lisp and python at the same time. It's compatible with python in both directions, so you can use it in any practical project - with django or with machine learning libraries, etc.
I think it's really cool =)
Edit: some additions for clarification
The irony is that I teach a lot of Python programming classes. And despite that, and my love of Python, I think it's a shame that they no longer use Lisp (or Scheme, or Clojure) for the equivalent of 6.001.
Python is easier to understand and get into. And Python has some amazing features that you want, such as first-class functions. And it's a real-world language, which you can't say about Clojure, even with its growing popularity. And Python is my strong recommendation for everyone's first language, because it's so easy to get into.
But there are some things that are just easier to understand in Lisp than in other languages. Implementing Lisp in Lisp (metacircular evaluator) is a fabulous way to think about programming languages that is harder in Python than in Lisp. (Not impossible, but harder.) Lisp allowed us to think about programming in all sorts of new ways, because it handled so many of those paradigms so well.
So I still think that the intro CS class should be in a form of Lisp, because it opens your mind up to possibilities. But if you're not going to go that route, then Python is a terrific first language, and I'm quite happy to see it getting the attention it deserves.
SICP is such a great book, it is a must have for programmers...
Or is it to teach the fundamentals of programming? Then Scheme is the ideal choice, but they should map concepts to mainstream languages. I.e., here's how OO works in Java, now we'll simulate it in Scheme. If more people took a course like this, we'd have fewer language fads IMO.
1) I hope they are teaching Python 3.x instead of 2.7.x.
2) A good portion of the schools cited in the Appendix are not "computer" schools. UC Davis for example, is the last place I would attend for a CS degree (I know many students at UC Davis -- it's much better suited for other degrees).
3) My school (CSU Sacramento) does not even offer any Python courses, but there's a lot of Java and C courses (depending on your major concentration).
As for whether or not they are computer schools, that criterion was determined through USN&WR, as mentioned in the article, which is where your criticism of not being a computer school should lie. Davis is listed at #34 though, so there may be a sharp decline after the first 10, first 15, etc...
I would say that compared to learning how to write and understand a small program, the difference between Python 2.x and Python 3.x is trivial.
(I'm talking about learning the language; for a large Python 2.x code base, the transition to 3.x is likely to have unclear payoff.)
The developers have said multiple times there will be no 2.8 and the 2.7 line will only receive security fixes. Python 3 is the future of Python and not teaching it to students would be a disservice to them.
You do have to keep track of whether print is a statement or a function or how literals map onto types, and some libraries are imported using different names and some APIs have changed a bit, but if you understand all that jargon, it's not that big a deal (I'll repeat my disclaimer here about transitioning a significant code base being a different thing than managing the differences).
However, from my experience, most students don't venture off on their own until after becoming very familiar with a language. Not all students are experimental enough to hack on personal projects for fun or what-have-you. I've actually had a fellow student tell me the Java class file he emailed me for a project would only run on Java 6 since that's what the lab had installed -- obviously wrong.
The point being -- students will intern what they are taught. They should be taught on modern versions/concepts so they intern modern ways of doing things. By teaching Python 2.x to students, you do them a disservice by teaching them the way Python "used to" do it... not how it "does it" now.
As an aside -- with all of the major Python libraries now ported to 3.x -- I see little to no reason anyone should ever learn Python 2.x, or use it (with the exception of the obvious legacy codebase support issue).
It has some neat features, but nowhere near enough for me to be prepared to dump 1/3-1/5 of the python ecosystem.
I'm sure python 3 is coming eventually, but I think it's still a looooong way off.
I agree that simply learning some programming has no bearing on the language version, etc... however, as students get familiar and start to experiment on their own, they may learn "the old way" of doing things.
There is no downside to teaching Python 3.x, there might be a downside to teaching 2.7.x.
Programming isn't one of those fields, like most things in life- where 'the latest version' is always the right choice.
The best way to explain it... it's like saying everyone should adopt Windows 8, that there's no downsides.
It's hard to explain that to someone who isn't in the trenches using it because it goes against peoples natural urge to be 'updated'. Unfortunately, this transition hasn't worked out- no one is saying it but it has pretty much failed. Turned into a 20 year transition. Red Hat is supporting Python2.7 until 2027. Core dev team till 2020. Guido van Rossum works at Dropbox, who started working on a new JIT compiler (Pyston)- this year that is targeting Python 2.7. There are actual performance regressions in Python3. I'd wait this one out for a while longer. Python 2.7 is only 4 years old and the stability to the language has actually been a boon rather than churning out flawed release after flawed release like many Python3 versions have been.
To be honest, if someone forks Python2.7 and continues that branch, that's where I'll be going. Not to 3. That will be the end of 3, I assure you. That will be a -huge- downside to teaching Python3. :)
This transition is not in the bag yet.
> Short version: Python 2.x is legacy, Python 3.x is the present and future of the language[1]
This should be enough of a reason for classes to move to 3.x.
Regarding your "in the trenches comment", remember, most of the folk on HN are involved in software engineering in some capacity, myself included.
No doubt it has taken a long time to move into 3.x, and it may take a while still. That doesn't make an argument to teach students a language dialect that, according to it's maintainers, is legacy.
> In particular, instructors introducing Python to new programmers may want to consider teaching Python 3 first and then introducing the differences in Python 2 afterwards (if necessary), since Python 3 eliminates many quirks that can unnecessarily trip up beginning programmers trying to learn Python 2. [1]
As I mentioned before, most (all?) of the major Python libraries have now been ported to support 3.x, so this leaves little reason to start out learning 2.x (unless you are setting out to maintain an old codebase, but we are talking about academics here and new beginners, so that point is moot).
From the way it sounds, you don't, and Python3 is hardly a dialect. The challenges of Python3 aren't for me or you, it's for library maintainers. And anyone with years of software built on 2.x (which is nearly all of us). I assure you moving from 2 to 3 as an end user is not a challenge. I have used Python3, since 3.0. It's no different 'dialect'- but when I last did (3.4), I found major performance regressions in basic functionality (JSON processing) and I think most of us have given up on Python3 (there are plenty of reasons). I'll revisit the idea of moving to it in another 5 years.
These issues are going unchecked in Python3 because there are no users. This is a major problem and plowing forward with Py3's development is a huge mistake. It remains to be seen what the consequences of this are.
It's simply propaganda to insist everyone is taught on Python3 as if it's the future of the language. You know it is a logical fallacy to appeal to authority. Python.org is taking a political stance, not one based on the real world. Python 2.x is the present. If you don't think so and refer to Python.org you're not programming in Python for a living. There's a major disconnect between the majority of the users of Python, and the core dev team that run that website. No one knows what the future of Python is yet, TBH Python.org should not be presenting 3 that way. In reality it's the experimental branch.
If you are using Python, then use 3 if you wish. Trust me, no one cares. You won't have support from most major distros and no online hosts. Google App Engine, Azure, etc are all on 2.x. You can't be doing too much though to not be running into missing libraries and roadblocks.
The silent majority will move to 3 if and when it ever makes sense. More likely we'll either go with the a fork, or simply move onto another language for the type of work that we do. Porting/testing is very expensive, why bother with that for no gains? We'll simply move to something else and the majority of the userbase will be gone.
There's only gains by using 2 but think what you will. Everyone is free to use what you want, including schools. I'm just explaining why it's not as simple and straight forward as you put it.
If it were that easy, there wouldn't be any controversy.
You sound so certain. Tell me exactly the number of people using Python 3? Not a percentage or something else without meaning. Real numbers. Don't know eh?
Why do people keep spouting such "facts"?
Who, the royal we? Or do you mean "I think it, so everyone else does too"?
[1]: http://grad-schools.usnews.rankingsandreviews.com/best-gradu...
Not me. Are you a professional Python programmer for your day job? I don't think it matters what they're teaching as far as version. As an enduser programmer the difference really isn't that significant (not worth a breaking change in the language at least). But whether they learn 2 or 3, they'll be able to move to the other without any major issue.
I would recommend anyone pick 2 over 3 at this point in time. Everything that says 'Python' supports 2 so there's just never any worries or concerns there.
ECS10 (Intro to CS using Python) was my first formal CS class. Took it as a filler elective and was hooked. It was definitely geared toward first-time programmers and used Python to ease into fundamental CS/Programming concepts. I found it successful in that.
Following that was ECS30 which is in C and the first major-track CS class. The difference in difficulty/workload substantial, mostly due to the introduction of things like pointers, dynamic memory allocation, etc. But the intro class helped a lot. From ECS30 on, it's primarily C/C++ for OOP/Software design, Data Structs, systems, algos, etc. I don't think Python is used much if at all in major track CS/CSE classes I can remember.
I'm a little surprised at the dismissive tone toward UCD's CSE program relative to CSUS. I've audited classes at CSU in consideration of applying for a master's there, and while not outright disappointed, nor was I impressed.
I got the feeling that the CSUS programs are not as geared toward fundamental research and "CS" to the same extent as UCD and are slightly more skewed toward developing employable skill sets. That's not a bad thing, just a different goal. I also disliked the general push toward MS stacks.
Having peers at Cal that took I took summer sessions with at UCD, the feeling was that UCD was less challenging in the sense that there are smaller class sizes, better professor access (especially in classes taught by excellent lecturers like Sean Davis who devote lots of time to students), and less competitive nature of grade curving. I didn't hear anyone say it was easier, simply that it felt more collaborative. Though, that's not hard to imagine when they were in classes with nearly 1000k students split across two simulcast lecture halls in freshman CS classes at Cal.
Being in the shadow of Cal and Stanford makes it harder for UCD to get noticed, ut it has world-class faculty, smaller class sizes and great options for research. I have friends/acquaintances that ended up at Goog, Twitter, MS, SpaceX... etc. Is it MIT, Stanford, CIT? Perhaps no. Is it more known for it's Bio Sciences? Sure. But it's far from the 'last place' I would matriculate into for CS.
Just presenting (an admittedly verbose) alternative opinion.
CSU Sacramento would probably be the last place I would attend for a CS degree.
As long as signup to the class is open for all (and not just CS-students) there will be healthy benefits for other departments (economics, biology etc.)
Aside from that I've always kind of defended high level languages as entry level teaching tools. The closer to pseudocode/natural language the better. Once you start to think about solving problems like a programmer you can switch languages relatively painless anyway.
With the advent of RubyMotion etc. I'm starting to wonder if there would be some value in starting to teach programming on mobile platforms in a high level language as 101 (i.e. the first ever code they write is mobile code). From my experience the "app classes" are always popular because there's a certain cool factor in being able to show a friend stuff you did on your own mobile device. If you'd tailor those classes to low-level phones it would be pretty helpful for certain areas of the world where many families have at least one cell phone but often no computer. Writing the code on the cellphone itself is pretty painful but at least one could write it at a university/school with a computer and carry the stuff that was built home.
I don't think there's any harm in learning Python first. I think they may be harm in learning C first - it's much more likely to frustrate people and potentially even put them off programming.
This is the same reason I dislike Java as a teaching language: having to tell people "don't worry about what public static void main(String[] args) means just yet" when teaching "hello world" isn't a great introduction to programming.
This is exactly why I have always thought that the move to Java for intro courses was a terrible idea.
C/C++ were never ideal for beginners, but it was still possible to strip it down to building blocks without immediately resorting "don't worry about this now."
Java is so deeply OOP that there's just no way for somebody to grasp and understand the concept of e.g., a public method when they haven't even learned about variables or basic conditional logic yet. A total novice just plain isn't equipped to handle some of the concepts that are immediately thrown at them with a simple hello world.
I agree. Except during that first C lecture when reading console input and was told 'don't worry about the ampersand, just remember to use it for scanf variables, we'll get to that later'.
C is important to know, but there's lots of stuff you need to learn before that.
I've just started learning, please tell me If it's best to learn python (I'm not looking for an easy language, but for a powerful and versatile one :) Something to develop some ideas I have..
First post on HN!! :D From the center of Spain!
Which is more future proof: Python v2 or Python v3?
I figured that I was least likely to regret Ruby for a green-field data analysis project. So far it's been a delightful experience.
As a compromise, you might want to start people on edwin (https://www.gnu.org/software/mit-scheme/documentation/mit-sc...) instead, if you want to teach them programming. But that's probably even less useful in practice.
After learning those picking up Python will be fairly easy. Again, you'll be comparing with what you know, finding differences and similarities.
Don't worry too much about finding the perfect language, it doesn't exist. Spend your time building nice things in languages and frameworks that are good at at what they do. Be ready to try new things, you might like them, they might work well for a particular task or have a great ecosystem to accomplish specific things.
While Python has a healthy web dev ecosystem, Ruby's feels much larger to me. That's almost certainly because Rails is so wildly popular. And Rails is an excellent, mature framework. So for web dev, I would consider Ruby the winner.
Python is the clear winner for scientific computing. That's not really due to anything inherent in the language. It's an ecosystem thing. If you were using Fortran before, you might be working in a problem domain where Python dominates.
Both are excellent for miscellaneous scripting work. E.g. reading in a CSV file and doing something with each row; batch-processing a bunch of images; renaming 1000 files according to some ruleset; gathering some system data and sending nightly status emails.
In terms of syntax and features, they're very very similar. Python has meaningful whitespace, which you may like or dislike. (I think it's good for enforcing proper formatting, but you're free to disagree.) Ruby has multiple ways of expressing the mathematical concept of a function (methods, blocks, and procs), which has its pros and cons. Both have metaprogramming facilities, though I find Ruby's more pleasant. If I remember correctly, it was in large part the metaprogramming that made DHH pick Ruby for Rails.
What is there in, say, rails that would not be available for django?
I much prefer Python/Django, but when I get stuck, it always lasts longer.
The difference is in the size of the ecosystem as a whole. The Ruby web dev world appears to have more (or more visible) participants. Which affects things like Stack Overflow, web-specific packages on Github, blog posts, etc.
It's not an order-of-magnitude difference, as far as I can tell. But still significant.
These things would make a huge difference to productivity if one platform had more (and better) of these things, but I haven't noticed that to be the case.
It's funny because I actually feel the opposite: Ruby is mostly a niche language for the web community, whereas Python is now mainstream in so many different areas (graphics, scientific, sysadmin, financial...).
I've yet to see a non-webdev tool embedding Ruby as a scripting language, while Python is now featured in office suites, spreadsheets and enterprise software. Anywhere simple and clear syntax is more valued than metaprogramming features, Python is likely to appear at some point.
But many other readings and the fact twitter and groupon were coded in ruby, made the choice! I've read that twitter now is moving to scala, but as there are a lot more resources out there for learning ruby/python, I kicked it out of the list.
I like ruby, sometimes it seems a bit confusing when there are many ways to express the same thing, but it's approach to natural language is helpful.
Thank you all for your quick responses! It's a pleasure to join the HN community!!
By the way, since it happened to me: if you find Rails to be too complex for what you need, there are more lightweight alternatives. Don't get me wrong, Rails will get you up and running fast; but when I was a beginner, it left me with the sensation that I didn't really know what I was doing. Using more lightweight frameworks, like Cuba or Sinatra, can help with that.
(a) already know HTML/CSS/JS and now want to learn a server side language, or that (b) you are going from no experience straight to server side programming?
Regardless of whether you learn Python or Ruby, there is practically no way around having to learn HTML, CSS, and JavaScript for building web applications. You will be reading/writing HTML/CSS/JS in your Python or Ruby projects.
So if you have no prior HTML/CSS/JS experience, I would prioritize those skills first. Otherwise you will learn Ruby or Python then be disappointed to discover that browser technology is a giant hole in your skillset, impeding you from doing the useful things that got you to start learning in the first place.
You can do great things with just HTML/CSS/JS, especially since the browser environment supporting dynamic client-side applications in JavaScript has become so powerful.
Then when you're finally doing something that genuinely requires that logic and/or data be hosted on a server, managed by server-side tools, your knowledge of browser technologies will provide a solid foundation for stepping into that ecosystem.
If you already know HTML/CSS/JS, Ruby vs Python comes down largely to personal taste and whimsy. There are indeed differences, but the differences don't matter till much later, if ever. The greater danger is not that you will learn a language that isn't future-proofed, but that you could waste far more time picking what to learn than you ever might have wasted by picking the wrong language, especially since there isn't truly a wrong choice between two great languages. The debate between them is largely a religious war.
Since you seem focused on web apps, and have already started learning Rails, stick w/ROR. You're on a great path and your current choices won't hold you back. Good luck.
PS If you're interested in learning HTML/CSS/JS, I am thinking of teaching these subjects to beginners (no charge of course). PM me with a contact if interested.
I've started with the ruby course on codecademy, it seems it's just like a fun introduction to the ruby syntax. When I finish the codecademy course I'm thinking about going into "onemonth.com" for learning rails, and codeschool after that..
Thank you! I'll get started with those languages as well :) I'm focusing on web apps, but I'll have to use JS to take the idea to phone app (using Titan from appcelerator)
By the way! Thanks for the invite to the course! I'll contact you as soon as I find out how to send a PM haha
One reason is that Python is used for system programming (e.g: the Linux apt system), desktop applications, big data (thanks to numpy) so you might find it a better investment for general purpose software development.
Another reason, which maybe explains the first one, is that Python looks more similar to C++/Java. Basically it's a simplification of those languages (the {} pair traded for a single colon, no type declarations, etc) plus some handy shortcuts. Ruby is from a somewhat different lineage (Smalltalk) and it shows in many places (e.g. the do |variable| ... end blocks). It can be used to write more natural language looking programs and combining that with some metaprogramming sometimes both amazes and unsettles programmers that come close to the language for the first time.
I suggest that you learn a little of both of them, working on the problem you want to solve, and decide by gut feeling what you would like to work with. I went the Ruby way because I can't stand some of the syntax of Python, not that Ruby is perfect.
The main content of the course hasn't changed. Complexity, Big O notation, sorting and searching are introduced in the first two or three weeks. Students work through the usual implementations of arrays, linked lists, stacks and queues (both array and linked-list based), trees, heaps, tries, etc. All these data structures are explained first as chunks of data with external functions for the operations; then a second time as objects with methods for operations, once object orientation is introduced in week 5 or 6. Iterators are introduced as an abstract interface to list-, array- and tree- walking. Where relevant, we explain every operation twice, showing the iterative and recursive approaches. The course ends with two weeks of lower level work, where the students hand-compile pseudo-Python to working MIPS assembly.
The move to Python gained us, among other things, the freedom not to have to explain Java's generics and access modifiers. Many of our students have never programmed with a text editor before our unit, and dropping them into the big boilerplate world of Java micro-management was not good for them or for the course. We used to spend too much time on syntax and other details ("native types are like this, reference types are like htat") that we should have been spending on data structures and algorithms.
With Python, we even have time to explain idiomatic Python iterators and generators, and to discuss Python scoping rules (which come up again when we work on local variables in their hand-compilation tasks). So we still teach a bit of language-specifics, but we don't feel we are shackled to have to teach them. Also, teaching them idiomatic Python is a good deed after spending the first three or four weeks in a not very idiomatic subset of Python where we maintain explicit indices, update them by incrementing or decrementing them manually, use while loops the condition checking on the index value, etc. as required by the course content.
I don't have data on the results, because I was only the adjunct adapting the tutorial materials. The only difference I noticed was that students had less support from their IDE, and that some common errors (attempting to access attributes on None is the top one) that used to be picked up statically are now runtime errors, as expected. There didn't seem to be any big problems from Python's lack of lexical typing. Type errors are still caught, again by the runtime instead of the IDE and, if anything, this is a better exercise for students, since fixing them requires better understanding of what the program is doing.
If anyone is interested, I can ask the lecturer about the outcomes, but just from the fact that neither she nor anybody else teaching the unit has raised any issues the second and third times the unit was taught I can tell it's all going smoothly.
That said, I believe that pylint could statically catch some of the type errors that are being referred to.
This by analogy with "lexical scoping", where you know where a certain name will be bound just by looking at the program's text, while with dynamic scoping, the stack is what determines where a variable is bound, and you can only know about it at runtime.
I guess I should have said "static typing". I probably made the mistake because lexical scoping is also called static scoping, and I was writing in a hurry.
It's important to remember we're talking about an introduction, here. Creating the spark of interest in students is the most important point in this class. There's always time after this to move them toward more expressive languages.
Python can be circuit bent into any semantic you desire, so I think it is a great introductory language.
I haven't taught an introductory Python course in years, but with Ipython Notebook I think it would be a blast.
Maybe you felt you had to jump in and defend high level languages, and maybe slash the other guy's tires on the way out, but this reads as trollish. Plenty of people working in C find it plenty expressive. Is it "more" or "less" expressive to choose to express different things? I don't think so. This comes off as uninformed C bashing, sadly very common and accepted around here.
The rest of your comment, that it is good for learning or as a first language, makes more sense to me.
Secondly, it makes for an easy transition from Python to Matlab, and Matlab is used a fair bit throughout UQ's Mechanical and Mechatronics departments. They both share very similar syntax (the major issue for most mech engineers, who deal with little more than loops, is that Python is 0-indexed whereas Matlab is 1-indexed).
The above makes Python a great introductory langauge for non-programmer beginners like mech engineers. It is ridiculously simple and human-readable, and when you're outside an IT/EE department then you don't end up spending excess time explaining the quirks of a language to those who will never care for it. On the other hand, it still gives more than enough rope for those that do end up wanting to run with it and they can end up doing some pretty fancy stuff with it.
Does Monash align there in that it's used in the non-IT related technical degrees?
This means that we have ten weeks to take people who may have never programmed by typing text into an editor and teach them enough CS and programming that they can implement their own hashmap in Python and reason about its big O performance in one week, start programming in MIPS assembly the next week, and implement function calls in assembly and reason about stack frames the following week.
Anything we can do to make their learning curve less steep is good. You say that your Data Structures course was graduate level, and that you were already familiar with C from a lower course. These are two big differences between you and our first year intake.
Now, like Spolsky, I too have a bit of the Yorkshireman in me, and I wish our students would be forced to work with simple text editors and the command line, instead of having the IDE to do some of their lifting for them. I wish they were taught more maths too. And spelling, now that we are at it. And C, why not.
But when you say that in your course you "just had to focus on our algorithm and nothing else", it echoes exactly our intention when we picked Python for this unit. We wanted the language that would allow our students to focus on the fundamentals, and spend the least time and effort on the incidentals. We were already running the unit in Java, which was an inherited decision. I think Python was the best of our available choices.
But the next course would be a hardcore introduction to C, embracing the language peculiarities instead of shunning them and trying to stick to concepts. I think at least once in an undergrad's career, preferably sooner than later, they should go through the process of learning the nuts and bolts of C.
I've probably been doing my own thing for too long to know for sure whether C is still the best choice, all I know is that NOT having the sort of class I describe, early in my college career, made things far more difficult later on.
When you're teaching systems programming, all the things that have to be done by hand in C are precisely the things the students are supposed to be learning. But for almost everything else, they're pointless details that obscure what you're actually trying to teach.
Teaching multiple languages also has the advantage of showing people how they're mostly not that different.
Exactly.
1. Historically, before it was taught in Java, this unit was taught in C, and it would have been a natural transition from building data structures via explicit pointer manipulation to explaining stack frames as a specialised data structure for handling scoped variables in function calls.
2. Despite the move to a higher level language (and, from assembly and machine code, even C is a higher level language), it's good for the students to get some exposure to the machine model, and what is going on deeper in the stack of turtles.
3. The lecturer who runs the course also has a bit of the Yorkshirewoman in her. So students learn a tiny bit of MIPS like they should eat their spinach and shower with cold water, uphill both ways, in the snow, or something.
"Now, I freely admit that programming with pointers is not needed in 90% of the code written today, and in fact, it's downright dangerous in production code. OK. That's fine. And functional programming is just not used much in practice. Agreed.
But it's still important for some of the most exciting programming jobs."
Pretty much saying that everything he just spoke to us is purely for the "exciting programming jobs". And let's face it, most of us do not have that unless we go out of our way to pigeon hole business problems into being fun and exciting.
The truth is, universities shouldn't care what industry does, because "real-world" computing is more about fashion than it is about any sort of science. And if you do it right people can learn any language they need (case in point, I learnt FORTRAN at college, now I do Python for a living and OCaml as a hobbyist).
That's not what I'm seeing at all. What I'm seeing is discussion of specific traits about Python that make it especially suited for a beginner language. And I'm seeing these arguments made over and over and over again, convincingly, in a way that was NEVER done for Java.
However, if you want your Computer Science majors to be able to create the next runtime like the JVMs, .NETs etc. or be able to do some device programming they need to learn C/C++.
A decade after going through a top-tier CS undergraduate program what saddens me is that a lot of university students today, think that Computer Science is cobbling github sourced code with their choice of scripting language. Yes, the startup market is hot and sometimes that's all you need but CS is much more than that. CS is about understanding the underlying models and concepts rather than a language. If you are totally missing how memory management is done, how data structures are laid out in memory, how typing works you are missing a big chunk of code-base out there in the world today.
I think the new wave of CS students, who are expected to solve larger problems, need to understand how billions of devices/apps are running in today's technology so they can create something better in the future.
"think that Computer Science is cobbling github sourced code with their choice of scripting language." This is the beauty of programming, and I'm sorry you can't appreciate that. Not everyone is willing to stab themselves in the eyeball trying to re-implement the .NET/JVM wheel or other low-level library.
It's the same reason the majority of us don't write assembler anymore. We've moved on and abstracted away from that arcane knowledge. Does that mean that arcane knowledge is irrelevant? For most of us, yes. For others, no.
"Yes, the startup market is hot and sometimes that's all you need but CS is much more than that. CS is about understanding the underlying models and concepts rather than a language." Meanwhile, in the real world, CS is not really necessary for most business problems. No matter how much you wish to romanticize it as a discipline.
It doesn't have to be the first language introduced. It should be second. My other comment in this thread: https://news.ycombinator.com/item?id=8004582
CS is about understanding the underlying models and concepts rather than a language.
Programming Language implementations are exploratory tools critical to understanding those underlying models and concepts. Indeed, in my experience the "CS is about understanding the concepts" logic is more often than not used as an excuse NOT to teach C.
The second was assembly.
I've gotten by in my career (to put it mildly).
What "top tier" undergraduate program is graduating students that can't lay out data structures in memory, don't know types, and so on?
Those schools actually DO try to teach students about these concepts. How do I know? I personally have spoken to the deans of CS departments. Now imagine these same students, who no longer even hear of concepts such as garbage collection, pointers, etc. because it just works in their chosen language.
I believe the era of a single language for your career is long gone. Most people in their 20s and even 30s today will go through at least 4-5 different languages throughout their career.
Personally, I learned and enjoyed C++ 15 years ago but I do not find it practical for anything I do today. However, the same "impractical" knowledge allows me to get familiarized with a new language in a few weeks and start producing working software.
I don't quite care what language students learn as long as the concepts are understood. However, if the language they first start with hides most of these fundamental concepts, they no longer have any incentive to even learn how anything works.
This is not terribly different than what I suggest. I'm saying in the modern world, Python fills the role of Basic and C fills the role of assembly.
The abstract idea is:
First Language: Clean and simple, to introduce the very idea of coding algorithms for a computer.
Step two: Low-level language requiring a lot of attention to detail. Should be useful for exploring low-level details about computer architecture as well as writing real programs.
Notably: Java doesn't fit very well into either category. There's a lot of overhead for pure beginners, and too many layers between the programmer and the hardware
that seems utterly pointless to me.
Remember that if this is a 4-year curriculum, they may eventually be expected to write code for a hashmap in C or some other low-level language as part of a data structures or algorithms class. And often, a class like that will spend time on analysis and algorithm design tradeoffs. The best way to understand why accessing a hashmap can be done in O(1) time is to actually code one for yourself.
This may simply be a preview.
> This may simply be a preview.
No, this is it as far as the core units go.
This is the first course on data structures and algorithms.
There is a second year course that deals with further data structures and algorithms: we teach amortized performance, proofs by induction, some randomized data structures (skip lists and maybe another), different tree-based structures (I remember red-black trees and patricia trees), some graph search algorithms and a bit more than I forget now. And currently we are doing it in Python for the first unit, and in any language that the student and their tutor can agree on for the second unit.
Remember: these are just class exercises, not real implementations. Of course nobody is going to write actual functioning data structures in Python[1] and expect them to be usable for general purpose programming[2]. That would be daft!
[1] https://bitbucket.org/pypy/pypy/src/8920909d084ec0d42535b955...
Or even http://toolz.readthedocs.org/en/latest/
Daft, indeed! :-)
I graduated from Monash Clayton a few years ago when the Java train was in full effect and the focus on Java was a big source of frustration for me. I distinctly remember an algorithms & data structures assignment about Markov chains which had to be done in Java. I spent a good 40 minutes writing what was effectively boilerplate to load the provided files into a meaningful representation and then just snapped and did the entire assignment in Python in maybe 15 minutes. Its crazy how much Java gets in your way for small projects.
Even though it was made clear that Python submissions won't be accepted, my tutor was very understanding and gave me full marks after I stepped him through the code. If that tutor was you, I owe you.
My first year CS data structures class was in scheme, as used to be popular. I enjoyed the class a lot, leanred a lot, and also found it very challenging. I think scheme was perfect for it. But I had no particular desire to continue with scheme afterwords, which is fine. (Not because I have anything against scheme, but on to other things).
How sad, not that you only do array and linked-list implementation of data types but that you think this is an exhaustive list. Inductive data types?
If you don't drop context that's a perfectly reasonable thing to say.
Curious. Why is object orientation introduced in a data structures and algorithms course?
I find that incredible. Long before I got to university I was been programming by myself with whatever editor I could find, edt, vi etc
I hedge that many of our students have never programmed "with a text editor" before because:
1. Many of them have used spreadsheets in higschool to build quite complex formulas, and spreadsheet formulas are turing complete, so they have programmed in some form of another.
2. I didn't want to discuss this here in order not to muddle the debate, but our introduction to programming course is now ran on Scribble[1], a dialect of the Scratch family. So many of our students in this data structures and algorithms unit have previously done just 12 weeks of programming instruction, and understand many of the concepts, but our unit is the first time that they have to deal with (for instance) syntax errors in textfiles.
Many people here in HN were teaching themselves programming by age 6, but to repeat myself: you are not our first year intake. We teach the students we get. These are not bad students: they are often hardworking and smart, and do well and learn a lot in our unit.
They may be ignorant of programming, but that's also ok, because that's what we're there for. And, to go back to the OP's topic, using Python as a teaching language lowers the barriers for access to the concepts that we really want to teach: complexity and big O, searching and sorting, etc.
I love python - used it for years, but I am dumbfounded that people enter a CS degree without having ever first tried to write a program. That's like taking english lit without having read a book before.
The world has 6B+ people and HN is a very very small portion of the world, just like USA and the UK.
Groovy (the JVM version) is marketed towards programmers who already know Java, and its main use cases (e.g. manipulating/testing Java objects, gluing together Java apps, and scripting in Grails) make the syntax terser but the programmer still needs to know what's happening underneath at the Java language level or they'll quickly hit a snag they can't solve.
The only use case where they don't need to already know Java is Gradle, where the script for a whole project is typically 20 to 100 lines long, usually copied and pasted from another project, and only using a tiny subset of the Groovy grammar, i.e. the DSL which is the least Java-like, so programmers won't be introduced to Java by using Gradle.
I even tried writing a Groovy(JVM) tutorial a while back for those new to both Java and Groovy [1] but found I had to introduce most Java and Groovy concepts at the same time. Groovy only gives some syntactic tersity via collection syntax, closures (though now obsolete with Java 8), and getter/setter syntax, nothing more.
[1] http://groovy.codehaus.org/For+those+new+to+both+Java+and+Gr...
We moved from Java to python this year and I miss a few things. Due to the absence of explicit typing the students don't bother to understand types anymore and it leads them to a lot of mistakes and misunderstandings: confusion between simple types, lists, dictionaries, instances of a user created class, etc. Besides I think the verbose and rigid syntax of Java forced them to understand what their wrote and for a first language that was a good thing.
Overall I found that since it is easier to write code in python they rush to writing anything without understanding the algorithmic problem first. Thus they are less able to decompose a problem in sub-problems and write atomic functions to solve each of them.
Note that I think teaching python as a first language is a viable option but in our case the course needs to be intensively rewritten and the labs adapted. For instance my lattest point about algorithms is not a problem with the language: it could be resolved by having a part of the lab being pure algorithmics and then an implementation part.
At my university I feel that proprietary scientific programs and CAS like Matlab, Maple and Mathematica are still the preferred problem solvers for students in the hard sciences (except CS).
This is my best guess as why Python VS Ruby.
That said, Ruby includes a lot of interesting concepts, and while I don't believe it's an ideal first language, those concepts certainly belong in a CS program.
(I have to say that it was extremely good !)
I'd say that blocks might be easier to grasp for a true beginner that hasn't been "contaminated" by the notion of anonymous functions as fundamental objects.
If you've got an explanation that would work in week 2 or 3 of a CS1 course, I'd love to hear it. I never found one better than "It's shorthand for a function."
But at the end of the day, if you teach someone Python, they can turn around and write Python code to solve problems in their science classes with minimal friction, or they can go on to be software engineers, or write web scrapers, video games, whatever. Python's arguably not the best at any of those things, but it's good enough at all of them.
Much has been said on this topic. So, I'm just going to post two links that I think are interesting.
Joel Spolskey claims that Java isn't hard enough to separate good programmers from the bad: http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...
This article claims that competency of CS grads is going down: http://www.education.rec.ri.cmu.edu/roboticscurriculum/resea...
CS1 should be an introduction to the nature of the discipline. I can think of many things more important and more representative of the nature of computing than the semantics of C.
They will make mistakes, sure. But they will get the work done, and that's pretty much what most businesses need. Eventually, as problems creep in, the messes created by lack of knowledge get resolved/cleaned up.
Programming is incredibly easy and powerful, when made simple. The problem is that learning programming in C/C++ is anything but simple! And the only reason we'd think otherwise is because we already went through it, somehow.
I've seen non-technical minded people learn programming with C/C++ as their first language. They get frustrated because they don't know why certain things work magically while similar things don't. So they end up learning to memorize what works and what doesn't, and copy-pasting what the book tells them. Eventually kludging together a working solution to a problem in the book. With no hint of understanding why.
#Yes I pulled that statistic from thin air.
Besides, most of what is being asked of four-year-degreed individuals is not really worthy of it. Which is why I keep mentioning stuff to the effect of "to a client's expectation" to most of my comments on this.
I see 2 domains where this level of depth matters:
- performance (speed, resource consumption) - security
If you're not doing one of those, you shouldn't have to care about them, especially if this is your first programming language ever.
Whereas with bare C, there is no hope.
Fully agree with static analysis.
My point is that at least with C++ you get the help of stronger type checking, RAII and automatic memory management via the available collections.
But of course, the C compatibility is both an advantage in terms of helped adoption, but also a weight in terms of being able to write secure code.
It is not that I don't agree with your point, actually I think It makes perfect sense. Eventually, anyone who considers him/herself as a serious CS student has to get his/her hands dirty with those relative low level languages in order to have a through understanding of what computer really is and in reality how it works.
Ironically, it is this very same reason that makes C++ as a entry point into programming a horrible idea. Because in order to understand it, IMO, a solid understanding of computer architecture is a MUST. Things like how memory is allocated, how call stack works, and why IO interfaces looks like it is now are unrealistically hard to take in a single course for those new comers with definitely zero programming knowledge, who probably would scratch their head out all night wondering why the following code snippet doesn't work (which wasn't valid back then in my freshman year, don't know whether it is valid now):
http://stackoverflow.com/questions/737240/c-c-array-size-at-...
And as it is a entry level course, usually a lot of details are skipped which makes it even more confusing. Telling from my personal experience, it is really frustrating that I once want to quit programming for good.
Luckily enough, I got to know Python at that time. In relatively short period of time, I could come up with a simple web crawler to scrap and download movie torrent files from the web. This is important to me that for the first time I realize I could do something both INTERESTING and USEFUL with programming language, which in turn gives me the motivation to go back and look at those lessons I run away from.
1. It is weird to take the top graduate schools and ask about what they teach to undergrads. I'd rather see this done with the best national universities list - http://colleges.usnews.rankingsandreviews.com/best-colleges/... - as the basis for this study since that's where the top undergraduate students will end up.
2. I'd rather see trends than raw numbers - the fact that python has grown quickly over the last decade in terms of adoption is more interesting than it being "the top," to me.
3. It is sad that Java still has such a stronghold both in terms of being the intro language and being on the College Board curriculum. It is not the right language for beginners, or, really, anyone.
4. While I didn't take "CS1" in college (thanks AP exam) - I did take CS2 or whatever, and it was taught in scheme with SICP. Scheme was the great equalizer in that it was unlike any language anyone in the class had ever seen and that syntax no longer mattered - only concepts did. I hope it continues to keep its place in second-level courses.
5. It is unfortunate that garbage collected languages are extremely highly represented on this list - memory management may be unpleasant, but acknowledging that we are programming on limited-resource devices should be acknowledged early and often. Forcing students to experience this first hand seems that it serves both the purpose of teaching them abstraction (isn't this garbage collector great!) while maintaining a respect for the fact that resources (cpu, memory, power, network, disk, etc.) aren't free.
I'd be interested to figure out the whole intro sequence. For example, my college begins with Java for the first class, then the next two classes can be taken concurrently, which respectively consist of functional programming/basic CS theory in SML, and Data Structures/Advanced Programming (memory management!) in Java and C++. I'm sure a number of other colleges follow similar procedures.
Also - I don't think that "CS0" classes should be included on this list as most are not taught with the intention of further CS education. For example, we have an "intro" CS course that is taught within the context of cognitive science (in Python).
Even more off topic, horizontal scrolling can be less of a pain if you just hold shift and scroll up and down.
Here is the issue I feel goes unnoticed as most people place out of 110 and never take it - CMU moved both courses to Python. While this helped 110 in a way by making it more accessible, it also resulted in people getting out of 110 with far less OOP principles than they did before. On the other hand, python works great in 112 because you spend more time building datastructures rather than running into the wall with Java OOP layers over and over. It's also cleaner so how a datastructure works becomes more transparent. But since the curriculum assumes OOP mastery from that point on, with no software engineering course required - I always wonder if replacing Java from 110 (a course for people with no coding background) was a mistake.
They put the transition to vote and Python won very clearly. But I always wished they continued 110 in Java (or shifted to Scheme, or anything that follows a stricter regime than python - so one gets comfortable with one way of abstracting problems, be it OOP or Functional) and taught 112 with Python. It probably isn't worth even discussing given how few CS majors take the course, but it always makes me wonder why we needed same language for both courses.
The other problem is that the farther you get from being a freshman, the farther you get from understanding which concepts are necessary in an introductory curriculum. As a senior you might say that OOP must be taught to the freshmen because so many freshmen don't get it, as a junior developer you might want the program to teach the standard library, and as a senior developer you might want to teach people about testing. This is all wrong. The most important things to teach freshmen CS students are very simple. Control structures, data structures, references / pointers, and recursion. Never forget that while OOP is warm and fuzzy and makes you feel good, the number one priority of the intro CS courses is to get the freshmen to write programs that work correctly.
Or, since OOP is a design aesthetic, it is only useful once design becomes important. Design is not important for small programs that freshmen write. Let them get off the ground with correct programs, and teach them paradigms once they have enough context to understand them.
I learned BASIC first and started hating GOTO before I was even in my teens. Who likes GOTO, seriously?
> The other problem is that the farther you get from being a freshman, the farther you get from understanding which concepts are necessary in an introductory curriculum.
I don't know, the farther I've gotten from being a freshman, the broader my experience of other people learning programming has been (and, even though I've never been an instructor in a formal introductory course, the more experience I have teaching other people, including programming.) Even if my freshman classes were my first introduction to programming, I don't think I would have had a better idea what an intro course needed then than I do now.
At the end of the day, Python won because it could be used to express programming concepts quite clearly in both an imperative and, to a slightly limited degree, functional manner, in ways that were appropriate for a variety of domains. And it did it in a way that substantially reduced the "boilerplate" syntax burden, which most of us take for granted, but is a large pain for newcomers to programming.
print "hello, world"
is very easy for a beginner.
Depending on what your background is,
[(i*3) for i in [1, 2, 3]]
may be a very clear way to multiply every element of an array by 3. Or it may be confusing as heck. :)
Our general hope is that by the time our current first years make it through the program that there will be even less of an emphasis on OOP needed. C0, for example, introduces an additional component of formal reasoning, and my shift of 15-440 replaced C++ with Go, which has a modestly less "OOP"-centric flavor. The big drawback now is that the transition from 110/112 to the formality of C0 and the functional intro with ml is rather jarring. That's partly by design, to get people to think about computer science differently than what they might have learned about "programming" in high school, but we'll see if we can optimize it.
(I'm posting about this because I'll be teaching 15-112 with David Kosbie next Spring.)
You should go back to teaching Distributed Systems in Go next semester. Pretty please.
The "introduction to CS" course, CPSC 201, is taught in MIT Scheme. It's interesting because for CS majors, the first class is functional programming. A sizeable minority (including myself) skip that class though, since it's only offered in the fall. I chose to skip it because I started the major late, already had programming experience, and Scheme isn't actually used outside of education. From what I gather, I missed out on some valuable lessons in simulating circuits and binary logic. My knowledge there is still weak.
After that course, the rest of the core curriculum is taught in C. Scripting languages like Python/Perl/Ruby, you are encouraged to learn on your own, and will often help in assignments. But they aren't explicitly taught as the focus of any course.
I absolutely hated some of my programming assignments in C, but I think learning systems programming in such a low level language is timelessly valuable and makes picking up new, higher level languages significantly easier, since you already know the tradeoffs of the underlying data structures and algorithms. For example, if I had not been exposed to pointers, I would not understand the difference in Python between "is" and "==" when comparing strings. In general I think learning c is a valuable albeit masochistic move.
We don't even touch data structures, algorithms, composition, inheritance, etc until "CS 2," which is also in C++. When I first tried Python as part of a 1-week assignment in "CS 2.5" (a lab course), I was blown away and hooked pretty quickly. We don't get formal Python experience really until the extremely work-intensive upper division programming languages course. From my perspective, I think a large number of people are discouraged by CS 1 and how it's more of a programming class than a CS class. The only benefit of a C++ introduction is that it's easier for people to transition to C and lower level code for the operating systems class. Still, C is pretty well covered by our "CS 2.5" and "CS 3."
Other fun facts: our CS 0 (programming for non-CS majors) is split into three classes and is also in C++!
I accidentally took a C++ at a community college during high school and was forced to skip "CS 1" when I enrolled for my first quarter. I felt so unprepared for "CS 2" that I actually audited a good number of "CS 1" lectures and did half of the projects for the class even though I didn't take it.
Actual course numbers:
CS 1 -> CS 31
CS 2 -> CS 32
CS 2.5 -> CS 35L
CS 3 -> CS 33
CS 0(a-c) -> PIC 10(a-c)
I definitely saw it scare some people off though. So if your only criteria is "what is the passing rate", it probably does worse than python.
Since I'd been programming since I was 11, it seemed a little arduous to sit thought classes explaining what a variable was, etc..but in the end, I understood they had to do what was best for the whole lot, and obviously couldn't teach something more advanced to an underprepared set of people.
I think Python nowadays is really the better choice: although C has its own merits (and it should be taught at a later course, possibly together with embedded systems) , it introduces more complexity than necessary.
Python, with its readability and "batteries included" is really the ideal language for an introductory course, not to mention that it has potential lifelong use as a "Swiss Knife" type of language.
I say this knowing I hate a lot about Java, but thinking about how I would teach concepts and techniques while making a student employable and fostering the ability to experiment on their own.
I think the mission here is to ease people into coding so if they don't want to progress any further up maybe they'll just manage a companies small PHP website or something and have the knowledge to do that.
For EE major etc I would still recommend the plain C stuff though. For web-design etc Javascript might be a better course. Overall Python is a nice choice for the generic public.
Also, a lot of colleges (at least the best ones) offer functional programming in a second semester intro course (Berkeley does Scheme I believe). My own institution uses SML.
I could show this to my 80 year old grandmother and have her understand what it does with minimal help on my part.
word_list = ["hat", "dog", "cat"]
for word in word_list:
print(word)
String[] word_list = {"hat", "dog", "cat"}
for(int i=0; i < word_list.length; i++){
System.out.println(word_list[i]);
}
String[] word_list = {"hat", "dog", "cat"}
for(String word: wordlist){
System.out.println(word);
} String[] word_list = {"hat", "dog", "cat"};
for(String a: word_list)
{
System.out.println(a);
}
print(word) means it's even easier for grandma to understand!
mapM_ putStrLn ["hat", "dog", "cat"]
putStrLn "hello world"
The second piece is interesting: Is something of the sort "<mapfn> <printfn> <list>" easier to explain to someone who's new to programming than "<foreach> <print>"? I've always thought the latter was easier to understand, but I'm curious which one someone who has no previous programming experience would grasp more immediately.
The reason being that "<mapfn> <somefn> <list>" is more declarative, whereas the foreach loop is ambiguous. Something we often take for granted is how hard it was at first to come up with what exactly we need to do or mutate inside that loop to build the right result.
If nothing else, there is interesting discussion to be had ;)
repeat print ["foo"; "bar"; "etc"]
Types dont make things more complicated. Most languages have types and I prefer dealing with them explicitely rather than letting an interpreter do random coercion like Javascript.
Types lead to cleaner programming,instead of shoving random stuffs into an untyped list,a dev has to think about data structures.
Furthermore,as a non native english speaker,I dont find python more readable than staticaly typed languages like C# or Java.Especially when a codebase grows larger. I wish python was statically typed.
You're more than welcome to not think about what types you put into a structure/list. You'll quickly learn how to use that list/structure without hand-holding. For 90% of the problems out there, you don't need anything other than the basic data structures, and they're pretty straightforward to use without having to think about types.
Note. Please don't confuse Javascript's weak-typing with Python's typing, as Python is strongly-typed.
Once you've learned to think about types -- as most introductory courses, even those taught in dynamically typed languages, will teach you -- you can do that just fine in a language that doesn't put a gun to your head and force you to.
(And you can do so in ways that most statically-typed languages have too limited a type system to let you do, too.)
asList("hat", "dog", "cat").forEach(System.out::println)Functional still isn't that popular, in spite of a few vocal supporters. Even MIT went from scheme to Python for their sicp training.
Other Portuguese top level universities offered similar choices.
European computer science has traditionally been more theoretical than American computer science, but even in Europe you'll find that a lot of 101 courses teach in Python.
Transitioning first classes from C to go would make great sense, but it looks like a lot of schools already replaced C with Java and C++ as first languages.
Personally, I do think there is merit in teaching a primarily imperative language first, if only to appreciate other paradigms later and get an inkling of what is really going on beneath your code.
I won't say anything about Python.
> I won't say anything about Python.
I will try to learn from your wisdom.
SML worked well because it's more or less dead. All the documentation is basically on a single unsexy website. There aren't a bunch of blogs cluttering up Google results or even much on StackOverflow. Racket also has a single Canonical source and good clear documentation and not much noise.
I can't say the same about the Ruby ecosystem, where I saw this crazy construct in lieu of a call to super posted in a forum question. The TA asked how the person arrived at it. I knew the answer because I had landed at the same StackOverflow page from Google earlier in the week. Which is not to knock Ruby. I understand why people describe it as beautiful.
Rust would probably be too strict and annoying as a first language. Maybe the same is the case for Haskell, but maybe it isn't such a big deal for those that haven't been "spoiled" by imperative languages and thinking already.
Rust is a horrible choice now, because it hasn't stabilized. When it has stabilized, it may be a suitable choice (at one point, it looked like it would be too large of a language to a be a great intro language, but since then its been getting smaller, so I'm less convinced that it will remain unsuitable for that role.)
Python's a pretty good intro language; as is Scheme, and Haskell might be, though I haven't seen any good intro-to-programming material built around it, and while I think a good intro should prefer a largely-functional style (as the best Python and Scheme-based courses I've seen have), I'm not convinced that a pure FP language is ideal for an intro to the field (though it certainly a good thing to learn in the course of an education in the field.)
The students move on to Java, C++, Perl, Prolog and others after that; not sure about Python.
I think a strict language in the ML family would even be nicer, because students wouldn't have to reason about laziness.
Really? I thought good old imperative programming was the best starting point. Concepts like assignment, branching, looping. IMHO goto is actually useful at that point and structured programming is an abstraction that takes a little while to wrap your head around. Perhaps it's due to the way I learned that I think some things are more basic (no pun intended). Either way I don't think high level abstract concepts like functional programming are even relevant in the real world of software development - abstract stuff is CS, basic stuff is for everyone else who has to take a programming course.
x = 1
x = 2
If we stick to immutable values and recursion, and functions that are, well, functions, we get something that corresponds quite closely to first-year mathematics, which makes it easy to learn at the same time.
Using a modern imperative language doesn't prevent you from adding complexity a bit at a time, and -- especially initially -- getting the advantages of teaching things in a functional style.
[1] but not object fields, as objects are taught as containers of mutable state, usually late in the course.
Exactly! Intro courses are usually - with good reason - taught in functional style. Which suggests that a language where that style is more natural and appropriate might be a better fit for those courses than Python.
(Though OTOH I wouldn't advocate a language where IO is anything more complex than a function call)
This is nothing but FUD and you should be ashamed of yourself.
As much as I like static typing, I agree that showing people run-time errors seems to do a better job of teaching than letting them know ahead of time via the compiler that their code will likely blow up.
Python 2.7.1 (r271:86832, Apr 22 2011, 16:34:07)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> type(5)
<type 'int'>
>>> type('hello world')
<type 'str'>
>>> type({'key': 'value'})
<type 'dict'>
>>> 5 + 'hello world'
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
No. Most languages are whitespace sensitive, though what whitespace differences matter varies from language to language.
> When students eventually move to Java/JavaScript/C#/Swift/whatever, will this be more difficult?
I doubt it. If anything, the indentation discipline they've learned will make their code in those languages more readable.
I really feel like I'd have rather had Python or Java first instead, if only because being concerned about all of the strict formatting and structure in a C++ program puts a level of unnecessary complexity in front of the goal: to introduce a person to programming logic and solving problems with programs.
Those complexities are certainly important, mind you. But not as important as clearly opening the mind to the way a programmer thinks, IMO.
there is also cs61as which is entirely in scheme (but no lecture) https://edge.edx.org/courses/UCBerkeleyX/CS61AS/2014_Spring/...
Show me a sane person who succeeded to grasp these few big ideas behind SICP after Berkeley CS61A or another similar Scheme or Racket course, who had any regret for spent time and effort?)
btw, AIMA and PAIP are much better in CL than in Python.)
PHP is all about magic.That's why it is popular at first place. And its popularity is an accident we'll have to live with for decades,given the amount of PHP code deployed outthere.
But if you are meant to be a CS student,you need a proper multipurpose language.You can do almost anything in python,from 3D games,to complex scientific computation.
PHP is merely a templating language,with enough good syntax to be bearable for advanced programmers.
PHP popularity is quite unfortunate if you ask me.Not because it is easy to start with or because it's a templating language.But because it could have been way better regardless of its execution model.
It could have been cleaner and more elegant if its original author had a clue about how to design languages.
most of PHP syntax is due to Rasmus inability to write a sophisticated parser.
from flask import Flask
app = Flask(__name__)
@app.route("/")
def hello():
return "Hello World!"
app.run() print "hello world"
<?php echo "hello world" ?>http://modpython.org/live/mod_python-3.3.1/doc-html/pyapi-ps...
But it's not a very good architecture, in the meanwhile we had better approaches, such as MVC and MVVM.
Anyway, CS is not web programming, but should focus on the fundamentals of computer science, for which there are far better languages than PHP.
Contrast[1] with python:
mkdir cgi-bin
cat <<'eof' > cgi-bin/hello.py
#!/usr/bin/env python3
print("Content-type: text/plain")
print()
print("Hello, world")
eof
#try to run:
./cgi-bin/hello.py
bash: ./cgi-bin/hello.py: Permission denied
#fix error:
chmod u+x ./cgi-bin/hello.py
#test in console:
./cgi-bin/hello.py
Content-type: text/plain
Hello, world
#Ok, does it work on the web?
python3.4 -m http.server --cgi 8000 --bind 127.0.0.1
#open localhost:8000/cgi-bin/hello.py
Is this how I would start teaching web programming in python? Probably not -- but it might be useful as one approach, assuming we've started with doing some stdin/stdout stuff, and showing how we can do the same on the web. Crucially showing how if you know how to read a csv file with values, do some aggreation and format it as a text table, you can output it as html, as text over the web, or even as json paired with javascript. That again generalises to database access ... etc etc. It's python (and "invisible" c) all the way down.
[1] Comparing using a fully wrapped up install of webserver+php (either mod-php or fcgi or what not) would a) not be fair, because if you really learn python, you have all the tools to examine the whole stack (well down to the OS level anyway), and b) fair comparision wouldn't be to python but rather with something like web2py, that also bundles a lot of infrastructure.
YMMV and all that, my only point was that there isn't really anything "simple" about web development -- it's distributed development with not very clearly defined security, state or even messaging semantics -- it's a mess. A useful mess, but a mess.
[edit: formatting, spelling. Aslo I agree flask is probably a much nice place to start, if one isn't building on an introduction involving text/console i/o]
We should not be teaching impressionable students that whitespace has semantic significance. This is a fundamental design flaw of Python, and it's just a Bad Idea.
Sorry, Guido.
javascript:(function()%7Bfunction callback()%7B(function(%24)%7Bvar jQuery%3D%24%3B%3B%24('*').on("contextmenu"%2C function(evt) %7Bevt.preventDefault()%3B%7D)%3B%24('*').mousedown(function(evt)%7Bif(evt.which%3D%3D%3D3)%7Bevt.srcElement.remove()%3B%7D%7D)%7D)(jQuery.noConflict(true))%7Dvar s%3Ddocument.createElement("script")%3Bs.src%3D"https%3A%2F%2Fajax.googleapis.com%2Fajax%2Flibs%2Fjquery%2F1.7.1%2Fjquery.min.js"%3Bif(s.addEventListener)%7Bs.addEventListener("load"%2Ccallback%2Cfalse)%7Delse if(s.readyState)%7Bs.onreadystatechange%3Dcallback%7Ddocument.body.appendChild(s)%3B%7D)()
http://alexander.kirk.at/2010/02/16/collapsible-threads-for-...
That sounds like a gut reaction and not a reasoned argument. I was skeptical of it at first, but after coding some Python I decided all my reasons for hating it weren't valid. Turns out it's very practical and makes the code prettier. I don't like the language for other reasons, but the significant whitespace never gave me any problems, headaches, or weird spurious bugs.
The only negative thing about it for me was that hitting TAB in Emacs doesn't indent to the "proper" place (since it's impossible to actually determine the proper place). Instead, it would alternate amongst the valid tab points from most likely to least, which felt like a reasonable compromise to me.
Interestingly, I never hear anyone whine about Haskell's use of significant whitespace…
However, when a language comes around that actively enforces and promotes these rules... you say it's a "Bad Idea". Could you elaborate on why you think it's so bad?
Not particularly, no. Or at least I think that should be the IDE's problem.
You still have to tell the IDE what to do with your code, which you do with brackets, I guess?
So now your code is full of brackets and parentheses, which are naturally less readable (how many levels of parentheses do you use in natural language?), and their role is almost entirely to... help the IDE indent your code.
People, even before computers, invented several different types of formal logic notation just so that they'd have a language that was better suited to these sorts of puzzles. I don't think that code is a good approximation of natural language, nor do I think that it should try to be. Natural language is very poorly suited to expressing layers of abstraction, and even basic logical relationships.
Of course it's easier to write programs that resemble natural language, just as it's also easier to speak than it is to write Vx[Yx->...etc...] but that doesn't mean it's the best way to look at a problem.
#
But that's a bit besides the point. You can do it however you like, even with whitespace if that's your preference. The key is that the IDE has to be aware of the meaning of your code. Python's solution to that is to assert by fiat that the white space should be a syntactically meaningful unit in this sense, but it could be anything.
If you have the information there, then people can look at it and write it however they please.
2 or 3 (but I write mostly lisp (as a programming language) and I usually mumble them (the natural languages)..).
(seriously.)