Python is now the most popular introductory language at top U.S. universities - <AUTHOR> http://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-us-universities/fulltext <comment><USER3> This methodology is suspect, and the headline is extremely deceptive. Note that Guo has conflated CS0 (meaning: CS for non-majors) with CS1 (meaning: intro to CS major). He is upfront about this fact and he does it intentionally, but comments about "first officially-sanctioned exposure in college" and such make it sound like he's unaware that most CS majors do not ever take a CS0 course; and among instructors of CS, phrases like "introductory language" without further qualification is usually understood as referring to CS1.

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.)

<comment><USER4> Author here. Thanks for your comments blahedo. I'm a bit short on time right now, but I will convert some parts of this response into more coherent form and edit my article accordingly to clarify.

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.]

<comment><USER5> ML (OCaml and SML) seems to get short shrift in your analysis. CS51 at Harvard is in OCaml. Brown's cs017 is OCaml, Scheme, Scala and Java. Penn's CS120 is OCaml (I think. It definitely used to be, but I can't find the course online anymore. You can reach out to Benjamin Pierce to ask, though.) And CMU has an SML-based FP course as part of their intro sequence

None of this is to deny the fact that Python is highly popular as an intro language.

<comment><USER4> Thanks, will look into those and update accordingly. However, Harvard CS51 doesn't count as CS1 since CS50 is already its CS1 course. (But please correct me if I'm wrong.)

<comment><USER4> (arg can't reply to your reply) this is actually quite important ... let me keep looking into this. sorry there's a giant backlog of (often angry!) emails in my inbox right now ... might not be able to sort thru them all :)

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...](http://cs51.seas.harvard.edu/docs/lectures/2013/1-overview.pdf)

<comment><USER5> It depends on what CS1 really means. I do think cs51 is comparable to CIS120 at Penn, and I think the later is pretty clearly CS1. That said, I find it hard to really figure out what the precise criteria are. It's pretty clear that Harvard encourages concentrators to take cs50, but I think the same course at other institutions would often be skipped by concentrators.

</comment></comment></comment></comment></comment></comment><comment><USER4> Author here: Please email course correction requests to firstname.lastname@example.com ... I'll probably miss a few important corrections amidst the hundreds of comments.

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.

<comment><USER4> wow y'all are really bad at downvoting this comment; it's still hidden in the middle :) why does it have 4 points?!?

<comment><USER6> This community appreciates creators coming, sharing, explaining, and answering questions about their work.

</comment></comment></comment><comment><USER7> Python was heavily based on ABC, a language which targeted new programers and made syntax choices based on user testing:

      http://python-history.blogspot.ca/2009/02/early-language-design-and-development.html

It says a lot about our understanding of our field that new languages generally do not formally test their syntaxes (and other "mental model" features) for usability.

<comment><USER8> If programming language selection for introductory university courses was based on pedagogical research on introductory computer science courses, I suspect Scheme would be nearly universal given its roots and nearly forty year track record.

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.

<comment><USER9> Care to elaborate? I wasn't aware scheme was known for its usability (easy to learn).

<comment><USER10> IMO Scheme is one of the easiest languages to learn. Have a look at SICP ([http://mitpress.mit.edu/sicp](http://mitpress.mit.edu/sicp)), one of the best introductory programming courses available, complete in Scheme. They just _use_ the language, without actually _teaching_ it, and students just pick it up on the go. Sure, there are lots of corners omitted, but at the end of SICP, you've written your own Scheme interpreter / compiler combo that you can build upon.

<comment><USER11> It depends who you are. People who have the recursion muscle tend not to appreciate what an obstacle it is for people without it.

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.

<comment><USER8> There is a really useful criticism of Scheme implied by your comment. Idiomatic Lisp is difficult to write, and there is a willingness in Scheme based Curricula to infuse it from the beginning. Unlike implementing objects in Java, use recursion and an aversion to mutation is a stylistic choice in Scheme. Iterative looping and state variables are viable alternatives and Scheme and other Lisps do mutation really well. The language has no prohibition on imperative style.

<comment><USER12> Also, chances are, if something is difficult to write, it is at least as difficult to read.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> I've always been of two minds about this. My intro course at MIT was in Scheme, a class that has since been renamed and is now taught using Python. On the one hand, it was a great course, and the FP was an awesome mindfuck (previous programming experience: TI BASIC). Though I took it all for granted at the time, it definitely set me up to think about programming better for years, and I still reread the book sometimes. The downside was that for a little bit, I couldn't really program in anything really practical, because by 2001 Scheme kinda wasn't. In other courses, I found myself crunching data with Perl that I only sort of understood, or writing C programs in situations where C probably wasn't the ideal tool, because it was the only other language I really knew. The thing where people say "once you know all the theory, you can learn a language in a couple days" isn't really true, and anyway, you probably don't have that couple of days. Point to Python.

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.

<comment><USER14> MIT grad here. I took the new course (6.01) 5 years ago, but I'm reasonably familiar with SICP. They are _very_ different. 6.01 has an emphasis on robotics and AI, probably because it's supposed to be an intro to EE as well as CS. SICP is more focused on the semantics of programming languages and the power of abstraction. 6.01 teaches some of the latter, but with some OOP mixed in. But it also teaches circuits, discrete signals stuff (e.g., the z-transform), probability, graph search, state estimation, etc. It's a breadth-first intro to EECS, whereas SICP is more of a depth-first intro to the building blocks of computer programs.

<comment><USER13> Telling me that the class I think of as "new" has been around that long makes me feel old. Point taken that they're just fundamentally different classes, not just the same class using a different language medium. 6.001 had some OOP in there too, actually (you ended up building your own OOP impl in Scheme; it was kinda neat), but otherwise I agree with your characterization of SICP. I definitely see the value of 6.01's approach (especially since the other 6.0x classes are also different from the 6.00x classes), but I can't help but feel like that really solid exploration of programming fundamentals is crucial, and something important has been lost. So maybe this is less about Scheme and me just lamenting the loss of 6.001. (I do hear you can take 6.001 over IAP, and of course you can always learn it on your own, so I get that a lot of this is just me being attached to a formative experience.)

Edit: some additions for clarification

<comment><USER15> I'm also an MIT grad (class of 1992). I took 6.001 back in the Scheme days. I loved it, and have found that the lessons learned in that class have stayed with me for a very long time. I now teach professional programming classes, and it's a rare lecture that doesn't use some of what I talked about there.

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.

</comment></comment></comment></comment><comment><USER16> I think Python is the perfect first language for beginners. Yea we all know it's not fast or low level or the best language to teach about types or advanced CS topics etc. But it is extremely readable and easy to understand, it makes coding fun and once the students are engaged and know the basics it is much easier to teach more advanced concepts like typing and memory allocation.

<comment><USER17> Couple of thoughts:

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).

<comment><USER18> Why do you think the flavor of Python taught matters?

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.)

<comment><USER16> I think it's important teach what's relevant in the current day, every likes to parrot the "Python 3 has no support" line but it's simply not true[1].

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.

[1]: [https://python3wos.appspot.com/](https://python3wos.appspot.com/)

<comment><USER18> Sure. My point is that nearly everything you learn about writing a program in 2.x is relevant to writing a program in 3.x.

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).

<comment><USER17> Well, yes, sure... core programming concepts are the same regardless of language used and/or version.

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).

</comment></comment></comment></comment></comment></comment><comment><USER19> All imo... Python as the "101" language is a pretty good idea for universities in general because many fields do data crunching of sorts and Python is fairly widespread in the scientific community.

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.

</comment><comment><USER20> Honestly, I'm not surprised, but I believe this is bad news. Learning C programming (first) was probably the most advantageous thing that has ever happened in my life of programming. When you understand C you understand how the computer functions, and in turn can write better software. It prepared me for virtually all programming and has enabled me to understand concepts correctly, the first time, and has made my life significantly easier.

<comment><USER21> I think C makes a great second language. Use Python to teach if statements, variables, control structures etc - then later use C to teach low-level algorithms, pointers and how computers actually work.

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.

<comment><USER22> >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."

<comment><USER23> "What does `#include <stdio.h>` and `int main()` mean? Why do I have to write them?"

<comment><USER22> Those can be understood from a high level point of view in a few minutes time. I've sat through multiple classes that have done just that.

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.

</comment></comment></comment></comment></comment><comment><USER24> Hey there! I've just started learning to code for building web apps (I know about Fortran 90, it doesn't fit very well on the browser haha), and it took me a while to decide. I looked up in an endless number of hacker websites, but at the end I'm sorry for betraying Python lovers... I'm learning ruby on rails..!

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!

<comment><USER25> My take on Ruby vs Python is this:

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.

<comment><USER26> >While Python has a healthy web dev ecosystem, Ruby's feels much larger to me.

What is there in, say, rails that would not be available for django?

<comment><USER25> It's not a Rails vs Django feature comparison that gives Rails the edge. Convergent evolution means they're pretty much on par with each other all the time.

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.

<comment><USER26> It was particularly those web specific packages on github that I was curious about. For example, is there a package for doing CAPTCHAs for rails that's better than all of the ones for django? Better admin apps? Better apps to help you integrate with bootstrap more easily? Or create REST interfaces?

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.

</comment></comment></comment></comment></comment><comment><USER27> I work at Monash University in Melbourne, Australia. Last year we moved our foundational course in data structures and algorithms from Java to Python, with great success. This is a course that used to be taught in C, then moved to Java. I tutored it as a Java course, and was in charge of adapting the tutorial (classroom exercises) and laboratory (programming assignments) materials when we started using Python to teach the unit.

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.

<comment><USER28> I do not know any Python (yet) - and my comment is probably off-topic. I spent a fall semester at Northeastern U, Boston in '97 and took a graduate course in Data Structures which was taught in C. I loved this course and finished top of the class (It helped that I was already familiar with C from an undergrad engg course). I fell in love with C. Implementing dequeues, linked lists, trees etc. with C was a pleasure - I learnt a lot about memory management responsibilities, smart error handling and began to understand how programming can be beautiful. Many years later when I started learning and working with Java, I felt that if this course had been taught with Java, I would not have gained as much (I could be wrong). The simple steps of typing your code in the standed editor supported by the environment (we were using a flavour of Unix in school), saving your work, compiling on the CLI and seeing the results - <USER2> just had to focus on our algorithm and nothing else. Your sentence "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" stands out for me in this context. Since I know zero Python, I wonder how it compares. This reminds of Joel Spolsky's essay : [http://www.joelonsoftware.com/articles/ThePerilsofJavaSchool...](http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html)

<comment><USER27> Our unit is a first year unit, and runs for twelve weeks.

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.

<comment><USER29> I've commented before in a variety of places that if I were to design a first- year curriculum that would have suited me best, it would start with python in much the way that is discussed in this thread, focusing on the concepts and algorithms and general concepts of coding.

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.

<comment><USER30> Indeed, I'm surprised by how often people make arguments that seem to assume the only options are C from the start, or no C at all.

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.

<comment><USER27> > 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.

Exactly.

</comment></comment></comment></comment></comment></comment><comment><USER31> Good news! I would like to add that another advantage of Python is its usage for scientific computing (Math, Physics, Biology, ...) so students hopefully choose Python to help solving problems for their math classes e.g. using numpy and co. They can then get easiliy into IPython which is IMHO a very important FOSS project.

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).

<comment><USER32> In the engineering fields (I am an ME), I am seeing steady growth in the use of Python and declining use of Matlab. The trend does appear to be more prevalent among younger engineers.

</comment></comment><comment><USER33> Yes, Python is an excellent language for beginners, but so is Ruby in my opinion. Not trolling: why nobody is using Ruby in introductory courses?

<comment><USER34> I've taught both, and IMHO, the Ruby is less suited for the job of an introductory language because a block (i.e. an anonymous function) is a hard concept for a beginner to grasp and a core part of idiomatic Ruby. Python's syntax simply has "less magic" and is more regular. Ruby's syntax seems to be suited for either folks who don't really want to know what's going on (just give me a DSL and leave me alone) or students who have one language under their belt and are looking for to branch out.

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.

<comment><USER35> A block is not an anonymous function. Try using `return`, `next`, etc... in an anonymous functions. Ruby has anonymous functions, they are called lambdas.

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.

<comment><USER34> You are, of course, technically correct. However, I'd argue that at the level of a CS1 course, it's all just semantics. True beginners don't even understand the concept of a function, let alone an anonymous function. For a student that's struggling to understand what's happening (not just type and have faith), blocks turn into one of those 'down the rabbit hole' pieces of syntax that requires a bunch of hand waving and earnest assertions of eventual understanding.

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."

</comment></comment></comment></comment><comment><USER36> While I agree that teaching Python to non-EECS majors is a great idea, it's sad to see the decline of C/Scheme in university courses.

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...](http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html)

This article claims that competency of CS grads is going down: [http://www.education.rec.ri.cmu.edu/roboticscurriculum/resea...](http://www.education.rec.ri.cmu.edu/roboticscurriculum/research/C-Programming%20vs.%20Java.pdf)

</comment><comment><USER37> In college our intro classes were in C++. While its a tough language I do wonder if it was advantageous to forcefully learn about 1) value vs reference types via pointers and 2) how allocation maps into memory space. Not having that level of depth kinda worries me

<comment><USER38> For 90+% of the problems out there, a business programmer doesn't need to know anything about memory#. Short of a few rules, I don't see why they can't ever go without learning about memory space, allocation, reference types, etc.

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.

<comment><USER37> I can see this rationale as an argument if it was an associate's or 1 yr degree, but for four years of study I expect real depth about what's happening all the way down memory etc

<comment><USER39> For 4 years study you dont need to learn C as your first language. You also get the benefit of being able to focus on the low level stuff when you finally go over C, instead of having the language do double duty of teaching both low and high level stuff at the same time.

</comment></comment></comment></comment><comment><USER40> Is sad that students never get to learn something like [http://ocw.mit.edu/courses/electrical-engineering-and- comput...](http://ocw.mit.edu/courses/electrical-engineering-and-computer- science/6-001-structure-and-interpretation-of-computer-programs- spring-2005/video-lectures/) they could easily learn any other language after, learning just java or python is practical only to prepare them for a corporate job.

<comment><USER16> The article only talks about introductory classes, most universities with decent CS programs will teach more than one language.

</comment></comment><comment><USER41> A few points that will likely get lost in the noise here:

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/...](http://colleges.usnews.rankingsandreviews.com/best- colleges/rankings/national-universities) \- 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.

<comment><USER42> It would also be useful to include liberal arts colleges. I don't think it's representative of top institutions if you only consider research universities. For example, Harvey Mudd, has a top notch CS program, but wouldn't be considered under that metric as it doesn't have any grad programs.

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).

</comment></comment><comment><USER43> One of the classes offered in my major (biochemistry) is "Python Programming for Biology" which is generally the first exposure that most of my peers get to programming, and I tell anyone who will listen how important that class is. Especially in the sciences, Python has a plethora of scientific libraries and great resources to do just about anything that a non-career coder would need. Except in computational chemistry everyone's stuck with ancient libraries, and I recently met an anarcho-capitalist grad student doing all his research in Fortran. Cool guy.

<comment><USER44> What are the ancient libraries used by computational chemists? I hope to get some insight to the field based on the answer to this question ;-)

<comment><USER45> I work with computational chemists at the moment, major offenders are LAPACK and ATLAS in FORTRAN-90

<comment><USER46> But Fortran 90 is much more readable than 77 :-p The downside is that binding fortran 90 (95, 2003) to python is much more painful...

</comment></comment></comment></comment><comment><USER47> OT: Since I don't have permissions for an Ask-type post I'll do this here. The lines in this thread break extremely 'late' ([http://imgur.com/IzmwWBo](http://imgur.com/IzmwWBo)), causing me a lot of painful sideways scrolling - my screen only has a 1024x600 resolution, but all other threads I have open look normal ([http://imgur.com/Q45ZDQ6](http://imgur.com/Q45ZDQ6)). What causes this and how can I get rid of it (FF30 with NoScript and Disconnect)?

<comment><USER48> Same here, Chrome 35, all extensions disabled. Oddly, if I open this page up Incognito (logged out), it works fine.

Even more off topic, horizontal scrolling can be less of a pain if you just hold shift and scroll up and down.

</comment></comment><comment><USER49> CMU transitioned from Java to Python when I was an upperclassman there. I'm not sure what other similar places do, but CMU splits introductory courses into 2 parts - 110, 112. 110 is the basic programming with gradual intro to OOP and stuff. 112 is where the datastructures come in - it's a programming primer to implementing datastructures and algorithms, so to speak.

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.

<comment><USER50> I think the intense focus on OOP is a problem, and it is symptomatic of teaching students Java as their first language. Just as if you learn BASIC first you love GOTO, if you learn Java first you love classes and think everything should be a class. What especially concerns me is that some people are interested in whether a program or language is object-oriented, and endeavor to make their programs more object-oriented. Object-oriented programming is a design aesthetic, perhaps one of the most nebulous design aesthetics, and it should not be considered a goal or a dogma but rather a source of inspiration for design. Java is a particularly bad example because Java's brand of OOP conflates encapsulation, data structures, and polymorphism. The languages we'll be seeing in the 2020s and beyond will probably be more sensible about these things. Look at the new languages with the most mind share these days (Go, Rust, Swift) if you want an idea of where the wind is blowing.

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.

<comment><USER51> > Just as if you learn BASIC first you love GOTO

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.

<comment><USER52> You love GOTO for as long as it takes you to find your love for the (almost always) superior GOSUB.

</comment></comment></comment></comment><comment><USER53> At my university, Python was primarily introduced when teaching certain concepts: scripting & untyped programming, web application development, and deeper diving into list comprehension functions. It was not the first language taught in CS, but many were exposed to it. That said, it was the first language taught in non-CS/non-major courses, and I imagine several other non- CS/Engineering majors were introduced to the language later in their academic career.

</comment><comment><USER54> Yale teaches CPSC 112 (CS non majors) in Java. Or at least, they used to. I think I heard this term they switched to Python. I would say that was a wholly good move. The only downside is that CS majors who take 112, and might prefer to learn Java in a class but Python on their own, do not get exposed to Java in any part of the curriculum.

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.

</comment><comment><USER55> CIS 120 at UPenn uses OCaml for the first half of the semester and Java for the second half.

<comment><USER56> Once upon a time CIS120 used Java for the first 3/4 and Python for the last 1/4\. Get off of my lawn kids.

</comment></comment><comment><USER57> I'm an undergrad at one of the outlier schools (UCLA) where a combination of the quarter system and a relatively conservative CS department make for an interesting undergrad curriculum. Our "CS 1" is taught in C++ and is mostly dedicated to well, C++. The entire first course is essentially dedicated to teaching you how to not blow your leg off while managing memory.

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)

<comment><USER58> I went to Davis which also teaches C in the CS1/first course for concentrators, and C++ after. It was really hard, I really liked it, and I've always felt it's given me an advantage over people who have no idea how the lower layers of the stack work.

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.

</comment></comment><comment><USER59> We had an intro to programming course at our college (NIT, Srinagar) which was based on C. Seemed perfectly alright, after some thought, because most of my batch mates had never programmed before (and there was a significant population who had no access to computers prior to college)

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.

</comment><comment><USER60> It's very interesting. My introductory course was in C, but on my last year they already had switched to Java.

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.

</comment><comment><USER61> While I love python, I feel like Java has more application for beginners. While I am a backend guy, Java is better right now for split front end backend sorts as you can build a client Nd server for an Android app in Java. This lets you learn front and backend without having to know two languages.

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.

<comment><USER62> I think the idea that the simplicity, lax compiler and readability of python will serve as a easier introduction to programming and keep more students from dropping out early. Java certainly has its place in enforcing verbosity, OO, coding standards, etc.

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.

</comment></comment><comment><USER63> I honestly foresaw this and advised my kids to learn Python, it's the new BASIC and the new JAVA-in-college. That does not mean Python is better than others, but it does fit a niche in the education system somehow.

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.

</comment><comment><USER64> Bit of a reversal from that "Python is dieing" post a few weeks ago. But like i said then - just one person posting some anecdote about people switching away from python does not a trend make. While Python becoming a teaching language of choice among many universities does make a trend (to add to similar upwards trends in job postings, high TIOBE rankings, etc etc).

</comment><comment><USER65> It's not surprising to me that Python has become the most popular intro language at universities. For someone who went a school with a poor computer science program, Python was a saving grace and landed me my first job as a developer. Unfortunately the school I went to did not have any courses on Python so I took it up in my free time.

</comment><comment><USER66> This is completely misleading. Just because a course is offered at a 100 level, doesn't mean it's an introductory course. These numbers don't mean a thing... (in case people cared, yes I did go to one of these schools and at least state for that given school, this data is complete bs)

<comment><USER4> please send me mail with a correction request. thanks

</comment></comment><comment><USER67> IIRC wasn't that the entire motivation behind the creation of Python?

</comment><comment><USER68> UC Irvine has a couple ICS intro classes. It was ICS 21 back in the day and it was C++ and then Java based. However it is now ICS 31 and it is python based.

</comment><comment><USER69> Having a structured, type safe language as base works well for Computer Science. Scripting language may be tried for other courses though.

</comment><comment><USER70> a language without types, without extensive research? Then, why not C/D/Pascal. i strongly believe for universities sml/ocaml/haskell or even rust are far better choices. I prefer sml.

<comment><USER51> > i strongly believe for universities sml/ocaml/haskell or even rust are far > better choices.

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.)

<comment><USER71> The computing courses at my university use Haskell in the introductory programming course - apparently it works rather well as a vehicle for exploring algorithms and data structures.

The students move on to Java, C++, Perl, Prolog and others after that; not sure about Python.

<comment><USER72> _The computing courses at my university use Haskell in the introductory programming course - apparently it works rather well as a vehicle for exploring algorithms and data structures._

I think a strict language in the ML family would even be nicer, because students wouldn't have to reason about laziness.

</comment></comment></comment></comment><comment><USER73> Help me out. I love the idea of Python as a first language. But do you think there's an issue teaching a whitespace-sensitive language as a first language? When students eventually move to Java/JavaScript/C#/Swift/whatever, will this be more difficult?

<comment><USER51> > But do you think there's an issue teaching a whitespace-sensitive language > as a first language?

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.

</comment></comment><comment><USER74> Every intro to CS course I've ever been in has been in C++, it has always saddened me to see Java being the intro level course today. Now to see Python at the top of the chart makes my head want to explode.

<comment><USER75> I'd rather it by Python than Java to be honest. In the same time it takes to teach Java you can probably teach Python and C.

<comment><USER76> Just don't try teaching C++.

</comment></comment></comment><comment><USER77> it seems that cs61a (UCBerkeley) still uses Scheme at some point [http://www- inst.eecs.berkeley.edu/~cs61a/su13/](http://www- inst.eecs.berkeley.edu/~cs61a/su13/)

there is also cs61as which is entirely in scheme (but no lecture) [https://edge.edx.org/courses/UCBerkeleyX/CS61AS/2014_Spring/...](https://edge.edx.org/courses/UCBerkeleyX/CS61AS/2014_Spring/about)

</comment><comment><USER78> That id. 800 _1337_

</comment><comment><USER79> Universities will do anything to lower the bar and increase tuition

</comment><comment><USER80> Because classic Scheme (or Racket) courses based on SICP are too complicated by new-normal (punk) standards.)

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.)

</comment><comment><USER81> So Python is the new BASIC. Being widely introduced in the universities, could be the mark of ageing and obsoleteness. Since the university is normally teaching something very irrelevant to the real life, shouldn't the student look around for that emerging tech that will bring him a job in 5 years from now?

<comment><USER23> BASIC was taught in universities the year it was introduced.

<comment><USER81> And it became irrelevant in 5 years or so.

</comment></comment></comment><comment><USER82> Justin Bieber is very popular too.

</comment><comment><USER83> Python for web development is confusing as a beginner. I would go with PHP since everything is not magic and you can see things right away.

<comment><USER83> No reason to down vote because I prefer PHP for web development. In python you have to learn an entire framework just to do web stuff. PHP everything is right there is that simple.

<comment><USER84> you should check out flask. there isn't much to learn to get going...[http://flask.pocoo.org/](http://flask.pocoo.org/)

from flask import Flask

app = Flask(__name__)

@app.route("/")

def hello():

        return "Hello World!"

if __name__ == "__main__":

        app.run()

<comment><USER83> that would be very confusing to understand for a beginner. PHP you can write <?php echo "Hello world" ?> right in a html file and see it just by refreshing the page.

<comment><USER85> It is confusing if you don't know the difference between a page templating language and a web framework. If ease of writing "hello world" is what matters, Python:

        print "hello world"

beats PHP:

        <?php echo "hello world" ?>

</comment></comment></comment></comment></comment><comment><USER86> I know, I know, what I'm about to say is just an artifact of the Language Wars and will cost me karma. I can't help myself.

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.

<comment><USER87> Iagree100%.Therereallyisnoreasontoattributetheattributeofseman ticallysignificanttowhitepsace.Justasineverydaylanguage,comput erprogrammersshouldhavethefreedomtonotusewhitespaceastheyseefi t,justasmusicshouldnothaverests;it'sonlythenotesthathavemeanin g.Finally,gentlepeople,Iimploreyouthatwallsinhousesshouldbemad einfinitesimallythin,too,becauseIseenoneedtoseparateanything.

<comment><USER88> Can someone delete this comment please? I'd like to read the other comments here but this one means I've got to scroll back and forth for each line :(

<comment><USER89> For a temporary solution, try right-clicking on it, select "inspect element" or something to that effect and deleting the text.

<comment><USER90> I use a bookmarklet that comes in handy in cases like this:

      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)()

After clicking the bookmarklet, you can right-click on any element to remove it.</comment></comment></comment></comment></comment>


Table-Based Layout Is The Next Big Thing - <AUTHOR> http://www.sitepoint.com/blogs/2008/02/28/table-based-layout-is-the-next-big-thing/ <comment><USER2> Obviously this sort of thing is an improvement over all the various contortions one must do to achieve that w/o "css tables"... nesting and negative margins and what-have-you, but I feel like using "display:table-cell" obscures the designer's intent, kind of. That sample layout isn't a table, it's a layout.

<comment><USER3> Exactly--tables (CSS or otherwise) are meant for _tabular_ data, like you would see in a spreadsheet, not page layouts. And if you want to use a table, the semantic way is to use a <table> tag, not a <div> or something else disguising as one.

<comment><USER4> Do what the committees and bloggers tell you to, you must obey!

Does restricting yourself to using tables just for tabular data make html coding easier, faster, or more readable? No, it doesn't.

<comment><USER5> I love you tim2. Or maybe I'm just fed up at people who never have to deal with cross-browser design getting uppity about someone using a table tag to ensure consistent display.

Either way, you're right. Lack of cross-browser consistency in CSS display support (vertical centering anyone?) is what makes implementing tables in CSS a living nightmare.

</comment></comment></comment></comment><comment><USER6> Somehow that really hurts. I know it is probably a good thing, but why not just use table, instead of redefining other elements to be tables?

<comment><USER7> You aren't redefining other elements. You're styling other elements such that they're laid out as tabular data would be, without having to redefine them as tabular data.

</comment></comment><comment><USER8> Next big thing? Maybe in 5-7 years when we finally stop supporting IE6/7. Until then, all these CSS3 tricks will be for hobby sites only.

</comment><comment><USER9> The only reason I find this remotely interesting is that it stands a chance of giving table-layout loving folks no excuse to move to CSS layouts. On the other side I find it a shady under-handed not fully cross-browser supported and not backwards compatible way of making a table-layout without making a table.

Comments on the site devolved into tables vs css so I didn't read too far down.

</comment><comment><USER10> About freaking time.</comment>


What's faster: Mongo, Ruby or Postgres? - <AUTHOR> http://groups.google.com/group/mongodb-user/browse_thread/thread/7ce7ddc2f608c2df

<comment><USER2> The question, as posed, is a little misleading - it seems to be comparing apples to oranges to pears.

The question is in fact about the speed of doing fulltext search; given a collection of documents in MongoDB, what's the fastest way to perform a fulltext search on them?

My solution to this problem has been to use Xapian integrated with my Rails project via MongoMapper and Xapit. It works quite well with the MongoMapper record callbacks (indexes updated on save, etc), and provides very robust search capabilities without too much effort at all.

</comment><comment><USER3> Steve Eley, several posts down, give ths best response to the question. An excerpt from the post:

"Particularly when you're talking about using three _totally_ different classes of technology -- you're comparing apples and oranges and bananas, and asking which is fruitier."

<comment><USER4> Unfortunately, the OP manages to thank Steve while completely ignoring his points.</comment></comment>


Brave New World of Digital Intimacy - <AUTHOR> http://www.nytimes.com/2008/09/07/magazine/07awareness-t.html?hp=&pagewanted=all

<comment><USER2> I have a friend who's rabidly anti-Facebook, who says that if someone is his real friend they'll phone him (presumably a hundred years ago he'd have been rabidly anti-phone, his real friends would write him letters on parchment). What FB does it it lowers the latency and friction of interactions _that would happen anyway_. If I want to go to a restaurant, FB lets me know exactly how many I actually need to book a table for just before I call them. If I'm planning an event, everyone going gets a reminder and a map. If I want to send someone a (real) birthday gift, it's an address book that updates itself.

What it might change is the real meaning of the word 'friend', or what it implies - all you can tell from being FB friends is that you're in someone's contact list. It doesn't really supplant real-world relationships.

</comment><comment><AUTHOR> Ask the author questions here: [http://community.nytimes.com/article/comments/2008/09/07/mag...](http://community.nytimes.com/article/comments/2008/09/07/magazine/07awareness-t.html)

</comment><comment><USER3> requires registration !!!</comment>


Valve announces Steam Broadcasting - <AUTHOR> http://steamcommunity.com/updates/broadcasting

<comment><USER2> Great news, hopefully it will be better than twitch!</comment>


Games you can't win - <AUTHOR> http://www.nytimes.com/2016/03/17/opinion/games-you-cant-win.html <comment><USER2> If you haven't already, read the Wired article as well - it's great: [http://www.wired.com/2016/01/that-dragon- cancer/](http://www.wired.com/2016/01/that-dragon-cancer/)

</comment><comment><USER3> My favourite example of this genre is Photopia[1]. It's very much a railroad, as interactive fiction goes, but it packs a powerful emotional punch. I think I came close to tears the first time I finished it.

[1] [http://adamcadre.ac/if/photopia.html](http://adamcadre.ac/if/photopia.html)

</comment><comment><USER4> I remember the stupid marketing term gamification from a few years back. It was the "in" thing and my boss wanted games everywhere that promoted the product. Luckily that has gone away as far as I know.

But this is a great case of a good use of gamification.

<comment><USER5> Naw, it's still here, it's just soaked into the fabric now so you don't see it.

</comment></comment><comment><USER6> For anyone interested, Radiolab did a stellar podcast about The Dragon Cancer. [http://www.radiolab.org/story/cathedral/](http://www.radiolab.org/story/cathedral/)

<comment><USER7> Reply All also did a great episode about it.

[https://gimletmedia.com/episode/50-the- cathedral/](https://gimletmedia.com/episode/50-the-cathedral/)

</comment></comment><comment><USER8> Software development.</comment>


An interesting data structure with search time O(sqrt n) - <AUTHOR> http://firstname.lastname@example.com <comment><USER3> Per the last posts: Number of heaps: O(n^(1/3)). Maximum elements per heap O(n^(2/3)).

Lookup of an element. Find the heap with the element (i.e. element between maximum of previous heap and this heap). Perform linear search in heap. Worst cast complexity O(n^(1/3) + n^(2/3)) = O(n^(2/3)).

Insertion of an element. Find the last heap those maximum element is still larger than the element. Extract top element of the heap and insert the new element instead. Then propagate upwards (i.e. extract top of next heap and insert top of previous heap, etc). Worst case is O(n^(1/3) + log(n^(2/3)) * n^(1/3)) = O(log(n) * n^(1/3)).

Deletion of an element. Find the heap with the element (i.e. element between maximum of previous heap and this heap). Remove the element from it. Extract top of next heap and insert it into this one. Then continue propagating upwards. So this is O(n^(1/3) + n^(2/3) + log(n^(2/3)) * n^(1/3)) = O(n^(2/3)).

Building the structure. Why is this O(n)? If you have already segregated the array into segments for the separate heaps, heapifying them would be O(n). How can the segmentation be done in O(n)?

Edit: Using the suggestion of splitting up according to 1+3+5+..+(2n-1) = n^2 we'd get:

Search: O(sqrt(n) + sqrt(n)) = O(sqrt(n))

Insert: O(sqrt(n) + log(sqrt(n)) * sqrt(n)) = O(log(n) * sqrt(n)

Delete: O(sqrt(n) + sqrt(n) + log(sqrt(n)) * sqrt(n)) = O(log(n) * sqrt(n))

<comment><USER4> Deletion can't be done efficiently, as pointed out by Timon Gehr:

>> Deletion leaves a hole in one heap, which should be filled by the minimum element of the next heap, etc. The minimum cannot be extracted efficiently from a max-heap.

<comment><USER3> That's true, I got confused with min and max there. gre's suggestion of using a min-max heap (if deletion is required) seems a reasonable workaround for this issue.

<comment><USER4> Using min-max heaps should be workable; indeed, the resulting data structure seems to be a special case of the data structure described in section 3 of [1].

[1] [http://www.cs.otago.ac.nz/staffpriv/mike/Papers/MinMaxHeaps/...](http://www.cs.otago.ac.nz/staffpriv/mike/Papers/MinMaxHeaps/MinMaxHeaps.pdf)

</comment></comment></comment></comment><comment><USER5> Here's a related paper (on HN last month) which tries to find the arrangement of elements in an array which minimizes search time, measuring wall-clock time rather than theoretical complexity: [http://arxiv.org/ftp/arxiv/papers/1509/1509.05053.pdf](http://arxiv.org/ftp/arxiv/papers/1509/1509.05053.pdf). (Spoiler alert: it's not sorted order with binary search, and the answer has a lot to do with the cache).

<comment><USER4> Interesting. One layout they did not consider is the bit-reversal permutation[1] of the sorted array. Searching is straightforward: to find element i, you reverse the bits of i -- so then, you can just binary search. This layout is similar to Eytzinger, so it should perform at least as well, and it may have some advantages.

[1][https://en.wikipedia.org/wiki/Bit- reversal_permutation](https://en.wikipedia.org/wiki/Bit-reversal_permutation)

</comment></comment><comment><USER6> From some homework I did as a freshman, I remember another neat data structure with O(sqrt(n)) search: [https://ece.uwaterloo.ca/~dwharder/aads/Algorithms/Beaps/](https://ece.uwaterloo.ca/~dwharder/aads/Algorithms/Beaps/)

</comment><comment><USER7> I'm confused. I can follow the logic for O(sqrt n) searching. yeah, that's cool. But how to maintain the structure when inserting or deleting?

Insertion for example, if I want to insert a value which is smaller than the smallest element in the last heap, then it'll have to be inserted into some heap in the middle, right? And since the heap is in the middle, say heap K, its size already reaches its upper limitation K^2. Then where should the new value go? If I insist on pushing it into heap K, then the heap will violate the size limitation. Should I split the oversized heap into several heaps some time? If it does split, will the O(sqrt n) searching time still holds?

Or maybe I just have not caught the author's idea yet. :-(

BTW, why not BST, for everything is O(log n)?

Update: @nikic solved my questions. Thanks!

<comment><USER8> I think for insertion, once you find the heap the new element should be inserted into, you would remove the max element from the heap, and re-heapify that subarray with the new element. Then you would insert the max you just removed into the next heap in the same way, and so on. That sounds like it could be less expensive than shifting the whole array, but I haven't done the math (and it seems that Alexandrescu hasn't either, yet).

Note that I'm making a couple assumptions about the data structure that were left unstated in the original post:

* Each element of each heap is less than every element of every subsequent heap.

* "When the max value in a heap is less than the searched element" was a typo and "When the max value in a heap is _greater than_ the searched element" was intended.

Maybe I just totally misunderstand this data structure though :-( It's still morning for me.

<comment><USER9> You'd re-heapify all heaps greater than the one that ejected an element, since heaps greater than you are all full except for the very last one.

<comment><USER8> I said that:

> _Then you would insert the max you just removed into the next heap_ in the > same way, _and so on._

</comment></comment></comment></comment><comment><USER10> I'm not sure I'm able to visualize this correctly. Let's say we have an array of strings containing the top 20 movies from Rotten Tomatoes:

      The Wizard of Oz
      The Third Man
      Citizen Kane
      All About Eve
      Das Cabinet des Dr. Caligari. (The Cabinet of Dr. Caligari)
      Modern Times
      A Hard Day's Night
      The Godfather
      E.T. The Extra-Terrestrial
      Metropolis
      It Happened One Night
      Singin' in the Rain
      Laura
      The Adventures of Robin Hood
      Inside Out
      Repulsion
      Boyhood
      North by Northwest
      King Kong
      Snow White and the Seven Dwarfs

What would this data structure look like?

<comment><USER11> From my understanding it would be roughly: [https://gist.github.com/bpicolo/32a7fc775ce1810c88a0](https://gist.github.com/bpicolo/32a7fc775ce1810c88a0)

<comment><USER12> I won't be array of arrays. It will be just one array.

<comment><USER11>
      we decompose an array of size 35 into: an array of size 1 followed by arrays of sizes 4, 9, 16, 5

Then again, maybe he means `mentally decompose` in terms of pretending they're separate arrays? I interpreted it as `visualize this data structure`.

<comment><USER13> I also originally thought he had an array of arrays, but now I I think the run-times he mentioned for insertion and deletion would only work for a single array, not an array of arrays.

</comment></comment></comment></comment></comment><comment><USER14> From what I understand, this is how Medium organizes the fast retrieval and editing of their rich text. You might want to read this for more information: [https://medium.com/medium-eng/why-contenteditable-is- terribl...](https://medium.com/medium-eng/why-contenteditable-is- terrible-122d8a40e480#.b5dod0r3n)

I may have missed something, though :-|

<comment><USER15> That doesn't sound like it at all. Medium's document model is a list of paragraphs, and that (according to your link) is it.

</comment></comment><comment><USER16> The context of the proposed data structure is more important for evaluating how effective it is at maximizing performance.

This context includes not only the characteristics of the (typical) systems using the data layout, but also the typical use of that structure (read heavy, write heavy, some mix). The cost of memory is also an issue. For a typical end user program the bottleneck is almost always going to be the user. For larger scale programs or more performance intensive areas of a program (E.G. graphics languages or other large data operations) different tradeoffs should be evaluated.

</comment><comment><USER17> Even just that question: "Why?" and the corresponding answer are worth a read.

<comment><USER18> Agreed. I love that this came from noticing a "gap" and coming up with something to fill the hole. I wish I thought like this more often!

<comment><USER19> "Find a gap and fill it, I always say! My great-grand-uncle is the one who came up with disposible ketchup packets. Me, I found a data structure with O(sqrt) search time. Sure it doesn't have all the doohickeys of a Red-Black Tree, it's not as quick on the insert as a radix - but at the end of the day it gets the job done. And to some people, that's all that matters..."

</comment></comment></comment><comment><USER20> This is a very interesting discussion, but I'd like to ask a question about this in particular:

> The short of it is, arrays are king. No two ways about it - <USER2> > pointers is a losing strategy when there's an alternative.

Why is following pointers a losing strategy? If you have a contiguous array (a vector), then the pre-fetcher can do its magic and give you a psuedo-cache level. (I may be wrong about this assumption).

<comment><USER21> The prefetcher works only if it can predict what you're going to access next. Chasing pointers means essentially jumping to random addresses in a given memory region. That's pretty much the worst situation from a caching point of view, what the prefetcher loves is linear traversal.

Of course things become more complicated when you start having larger amounts of data, and you want to skip over most of it, but still keep the cache happy.

<comment><USER22> In theory, an advanced prefetcher can detect that you are stepping through an array of pointers, dereferencing each of them, and start prefecting.

Even that would have its problems, though. Typically, every one of these dereferences brings in a new cache line. Unless the data that the pointers point to fills an integral number of cache lines, you are bringing data into the cache that you will not need.

<comment><USER23> There are costs to this, because you may dereference things that are not valid pointers either. The kernel used to have software prefetch code for linked list traversal. On each access it would prefetch the subsequent access. Which sounds like a huge win. However, in practice the most common list size was just a few elements and there was a huge penalty for fetching the final, invalid null pointer. They ended up taking out the prefetching recently (and I think they saw a small speedup as a result!) Now maybe someone could invent a hardware prefetcher that does this in a way that's a net gain, but the fact that Intel hasn't done it yet suggests that it maybe it doesn't help much or that the situation isn't all that common.

</comment></comment></comment></comment><comment><USER24> I haven't thought about it closely but, from a cursory read, it sounds like the SquareList data structure: [http://www.drdobbs.com/database/the- squarelist-data-structur...](http://www.drdobbs.com/database/the-squarelist- data-structure/184405336)

</comment><comment><USER25> Another thing that works is a length-sqrt(n) list of length-sqrt(n) sorted lists with internal gaps, like with Python's SortedContainers[1].

Something like this with a contiguous allocation would probably require quite a lot of empty space - 100% reserve for each subarray by necessity[2] and 50% for the array as a whole, so 200% overhead at worst and probably 90% overhead on average. Alternatively you can heap allocate each subarray at the expense of slower operations, but resulting in a more typical 100% worst-case overhead.

So you'd store like this

        |</comment><comment>----HEADER</comment><comment>---| |</comment><comment></comment><comment></comment><comment>-----BUCKETS</comment><comment></comment><comment></comment><comment></comment><comment>|
         idx
        (0, 3) (2, 2) (1, 4) (_, _) [1, 3, 7, _] [14, 15, 16, 19] [9, 12, _, _] [_, _, _, _]
            length

Cache efficiency might also suggest you store the minimums of each list in the tuples.

So to search for a value, you do a binary search over the header to find the wanted bucket and then over the bucket to find the value. That's O(log n).

Insertion is O(sqrt n) since you need to find the bucket and then do a normal insertion into it. You might need to reallocate the whole thing (remember to increase bucket size!) but that's amortized out.

Deletion is even easier since you don't have to deal with overflow (although you might want to move empty buckets to the end or merge adjacent ones, maybe). O(sqrt n).

Creating the structure is trivially O(n log n), since it's sorted.

Converting to a sorted list is just compacting the buckets.

You also get access by index at O(sqrt n) speed since you just need to traverse the counts in the header. Not perfect, but close.

For a cache-efficient design it's pretty neat. Binary searches are fast, after all.

[1]: [http://www.grantjenks.com/docs/sortedcontainers/implementati...](http://www.grantjenks.com/docs/sortedcontainers/implementation.html)

[2]: When you split an overfull subarray, each new subarray will be half full.

<comment><USER25> After some thought, you can avoid so much reserve by just not having any reserve buckets (and thus no need for the header either). You can only resize once every O(sqrt n) operations and a resize costs O(n), so it's amortized O(n / sqrt n) = O(sqrt n) insertion. You can lower the constant factors a bit by doing occasional local reshuffling.

Not sure if it's a great idea, but it's tempting.

</comment></comment><comment><USER26> I don't understand this bit:

> Now each of these arrays we organize as a max heap. Moreover, we arrange > data such that the maximums of these heaps are in INCREASING order. That > means the smallest element of the entire (initial) array is at the first > position, then followed by the next 4 smallest organized in a max heap,

Just because the maximums of the heaps are increasing order doesn't mean that the minimum is at the front. It means the first element is _smaller_ than the _biggest_ element of the next four.

Consider, for example:

        1 4 3 2 0

1 < 4, certainly, but 1 > 0\. What am I missing?

<comment><USER8> I'm pretty sure there is an additional (unstated) assumption that each element of each subarray is less than all elements of subsequent subarrays. Otherwise you could just take the largest sqrt(n) elements, sort them, and then randomly assign the other elements of the collection to their heaps and it would still meet the criteria he's laid out, but the search algorithm he's proposed wouldn't work.

In fact, there's an error in the search algorithm as well:

> _Whenever the maximum element (first element in the subarray) is smaller > than the searched value, we skip over that entire heap and go to the next > one. In the worst case we 'll skip O(sqrt n) heaps._ When the max value in a > heap is less than the searched element, _we found the heap and we run a > linear search among O(sqrt n) elements._

For the unitalicized portion above, he means to say "When the max value in a heap is greater than the searched element".

</comment></comment><comment><USER27> Relevant algorithms by J. Ian Munro and Hendra Suwanda from 1979

[https://cs.uwaterloo.ca/research/tr/1979/CS-79-31.pdf](https://cs.uwaterloo.ca/research/tr/1979/CS-79-31.pdf) [http://www.sciencedirect.com/science/article/pii/00220000809...](http://www.sciencedirect.com/science/article/pii/0022000080900379)

</comment><comment><USER28> Is it immediately obvious this can be constructed in O(n) time? The author just gleans over it but I'm still not able to figure it out.

</comment><comment><USER29> Isn't O(log(n)) equivalent to O(sqrt(n))?

<comment><USER26> No.

Just as (e^n) grows _faster_ (in the limit) than any polynomial of n, such as n^2 or n^100; likewise, log(n) grows _slower_ than any polynomial of n, such as sqrt(n) = n^(1/2), or even n^(1/100).

They are both practically pretty slow-growing, though. It may well be that for practical sizes, constant factors matter more than the asymptotic difference on present computers.

<comment><USER30> In Parallel programming class the professor told us: "When I was a student, our professor told us that for practical purposes log(n) = 7"

</comment></comment></comment><comment><USER31> Some other algorithms with O(sqrt(n)) runtime: [https://www.quora.com/Are- there-any-algorithms-of-the-order-...](https://www.quora.com/Are-there-any- algorithms-of-the-order-O-sqrt-n?share=1)

<comment><USER32> Another one is an uniform-sized carry-select adder. It has O(sqrt(n)) delay considering MUX delay << full adder delay IIRC.

[https://en.wikipedia.org/wiki/Carry- select_adder](https://en.wikipedia.org/wiki/Carry-select_adder)

</comment></comment><comment><USER33> if 4 <= N <= 16, then sqrt(N) <= log2(N) else sqrt(N) > log2(N)

So, in Big-O term, this only trying to optimize only small dataset (4 <= N <= 16).

<comment><USER34> Big-O is only strictly meaningful in terms of asymptotic behavior; as soon as you start talking about specific values of N, you have to care about constant factors.

In this case, the constant factors will probably be quite different because the goal is to make better use of CPU cache.</comment></comment>