I learned Python as my first TRUE(explain later) language and I will be forever grateful for it.

Now I am a polyglot, jumping through multiple languages all the time, be it Python/Java/Javascript, or occasionally flirtation with some languages that are foreign to my daily routine but necessary to get my job done.

I am not quite on board with you claim that Python is chosen for monetary benefits. To be a qualified programmer, there is so much more need to be learnt beyond Python. Python however, is a GREAT choice to overcome the initial fear of writing code in general, because it is more tolerant.

My actual first language is C, and before my college I have never done programming before. I have to say, looking back, learning C as my first language without fully understanding the modern computer architecture is a horrible experience: so many questions as to why things is what it is now, so many traps, crazy pointers, cryptic errors, nightmare segmentfault. Programming is just very frustrating experience to me that the time. Of course, later on, it all makes sense, even pointer seems like a great idea(you can't have more freedom than that), just that we need to put great efforts regulating the use of it to prevent irregular behaviors.

On the other hand, Python is a tolerant language, yet providing a pretty comprehensive sets of primitives to play and experiment with. Had I started with Python, I might not waste the initial year struggling and questioning myself whether I could program at all.

Compared to C, Python is the better choice. However, it seems like you haven't learned a Lisp dialect. I would love to know if you would still prefer Python once you know Scheme.

I have to agree. Scheme is so much more elegant and so much simpler than Python.

People often talk about how simple Python is, but many of them have either no experience with or no appreciation for Scheme. When they do have exposure to Scheme, it tends to be some ancient, primitive dialect like MIT Scheme rather than modern, full-featured scheme like Chicken, or Racket, or Guile -- so they look at Scheme as a toy language. I don't know how often I've heard comments along the lines of Scheme being a fine academic language but impractical for real work.

Python does have a little nice lispyness to it, but it's deliberately limited by the language designers, the syntax is lacking and it has many frustrating inconsistencies and gotchas. Programming in Scheme is just so much easier.

> Compared to C, Python is the better choice. However, it seems like you haven't learned a Lisp dialect. I would love to know if you would still prefer Python once you know Scheme.

the school I went used to teach C, Python and Scheme in the first year (nowadays it's C, Python and Racket). I don't think I remember more than one or two people actually liking the LISP experience, how bad it was when comparing to other languages is actually a common joke subject amongst alumni.

I also went to a school where racket was the intro programming language, and during that class, most of the student also hated it (myself included). However, over time, I found that those who stuck with CS and had to learn C(++), JS, etc, came to appreciate racket.

The issue with the line of reasoning that “X language is bad because it was bad during an intro programming class” is that your experiences in that class do not generalize well. Sure, python might be better for writing some basic algorithm that you fully understand before writing a single line of code, and for fairly small codebases. However, try writing a large codebase and you’ll realize that, for example, managing state is really hard.

Sure, racket and other functional languages might require a greater learning curve than other languages, and of course they’re not the language of choice for performance critical applications (nor will Matthias Felleisen claim it is). However, as a systems developer who uses almost exclusively C++, I would argue that starting out with a language that forces you to think about your contracts, mutability, scope, etc, invariable create a better programmer down the line

The language known as Scheme has done a lot of damage to Lisp's image. When undergrads are exposed to Scheme, they tend to forever carry a negative image of Lisp by association.

A lot of the time when you meet someone who had a bad experience with Lisp, if you interview them a bit, you soon discover it was actually Scheme.

Scheme twenty years ago, R5RS was even worse than now. It had nothing practical in the spec. No way to write a program consisting of multiple files. No error handling. R5RS talks about situations that trigger an "error", but nothing about how such a thing can be handled and recovered. Or how an error can be generated on purpose and then caught.

Anyone who studied R5RS in school was learning an utter piece of academic garbage; a serious regression from real Lisp.

I agree that there's a problem of people (even the people who rave about how enlightening it is) misunderstanding that a toy Scheme interpreter is what Lisp is, but I don't think that's an issue with Scheme. Introductory FP classes that use Common Lisp don't leave any better a taste in students' mouths, and real world Scheme is a lot more capable than a toy implementation designed for pedagogical purposes. I don't think the standard's conservatism is very much a factor.

They tried many LISP dialects over the years: Scheme, CommonLisp and Racket - and I don't remember student reactions ever changing about it.

I'd be interested in what aspects strike people as bad. (Honest question. If you reply, I promise not to come back with "But, but, but ...")

I will answer your question through its dual : the people who love LISP and functional programming are in my experience people who love maths - as in, algebra, etc. . You can easily recognize them, because they say weird things such as "this demonstration is so elegant !".

Functional programming of course maps (heh) very cleanly to this line of thought.

But most people hate maths and this way of thinking. In contrast, you get first year students "re-discovering" OOP ever year - for instance a common trick to make them learn design patterns is just to put a problem that calls for it in front of them, and three times out of four in my experience they will even come up with a pattern name close to the original ones.

Thank you.

One thing that comes to mind is that looping is limited to recursion in scheme. This becomes quite coumbersome IMO since it is a pretty important thing. Writing named lets for simple things is not anyone's preferred way.

It is however pretty easy to implement something like racket's for loops on scheme using lower level macros, and there are some available.

Implementing something like common lisps iter is actually not very hard, and even improving upon racket's for loops is far from complex.

> looping is limited to recursion in scheme

I believe that Scheme's DO is looping.

Which is still painful to use compared to python's for loops or comprehensions

Regarding C, my first language was C and I've always been thankful for that. It helped me understand low-level programming, memory management, pointers, registers, etc. It also helped me better understand how my computer's hardware works. Having C as my first language also gave me a greater appreciation for languages that handle all that complexity for me.

Regarding Python vs. Scheme, I like both languages. I tend to prefer Python for certain types of programming, like NLP, machine learning, and math, just because the available libraries are so good. Having said that, I feel that the functional paradigm is superior to procedural programming and definitely (for me anyway) better than OOP, so for everything else I'd choose Scheme or some other functional language, like Elixir, Elm, Haskell, or Erlang, depending on my mood and what I'm doing.

I think both C, Python and Scheme are all perfectly fine choices for a first language. It really depends on what you want to do.

Want to learn how a computer works? Learn C.

Want to study abstract comp-sci concepts? Learn Scheme.

Want to wire together libraries to get something running in the messy real world? Learn Python (or something similiar).

A well-rounded CS education really ought to include all of these to at least some degree.

I have working knowledge of C, C++, Scheme, and a little bit of Python, but I really don't think Scheme is true to all its hype. I'm not even sure if everyone praising it here is using it in real life projects or not or only academically. We do, and man, the tough life is with it. The only debugging we have here is numerous "format (print)" statements, it is terribly slow, and may be not everyone's using it as intended, but the way it promotes "lists" for everything is just plain wrong IMHO. End result, a lot of wrongful uses of searching in lists where a proper C/C++ data structure would prove much faster.

Oh, and the deluge of useless parenthesis that it is, it hurts my eyes to read that code.

> deluge of useless parenthesis that it is, it hurts my eyes to read that code.

Oh, how I wish I could share the joy I experience using Paredit with those parentheses. Paredit turns parentheses from an inconvenience into a turbo button for modifying code at an entirely new level of abstraction.

When you started coding, you probably used an editor that worked on units that were single characters. Think Notepad. Then maybe you learned a programmers editor like Emacs, Vim, or Atom or Sublime. There you learned to cut, copy, fold, spindle, and mutilate code in lines or paragraphs.

But Paredit... oh Paredit... now you have the tools to work with your code not in characters, lines, or paragraphs, but in code forms—the same stuff your code is made from.

And the best part is that Paredit doesn’t have to have a deep knowledge of your code, groping imperfectly like Intellisense. Paredit is deterministic and easy to implement.

If I could have an S-expression based version of every other language simply for paredit, I'd take it.

Now a story for a different day is how much I hate typing commas in non-lisps.

Which scheme are you using? Chez, chicken, guile and gambit all have pretty good debugging facilities, and a macro like chez's trace-lambda is a lot better than misusing print-debugging in most cases.

Nobody ever said most list operations is anything else than o(n), and if you are using lists you are probably using the wrong data structure. Vectors or hash tables would probably be a better choice (which are provided by all serious schemes).

Ours is probably some 20 years old initial MIT Scheme implementation added with homegrown features like "Object Oriented Scheme" etc., but a debugger was never implemented for the same. Talks have been going on to move to an implementation that has a debugger, but at such a scale changing that would be difficult.

By MIT scheme, do you mean MIT/GNU scheme? A few schemes implement their debuggers in terms of call/cc (or delimited counterparts) and exceptional conditions like errors or breaks hand control to a new 'depth' of REPL where anything in the environment can be inspected (or redefined) in-context before possibly trying to continue or doing any unwinding. If your scheme has no debugging apparatus, it shouldn't be too hard to implement something a little more useful than sprinkling in print statements. Even without wading into continuations, implementing a macro that does tracing should be possible.

Ouch... That seems painful and really like someone made a wrong decision 20 years ago. Back then scheme was a pretty inane choice compared to CL. That is not as much the case today, regardless of what the CLers say :)

> I would love to know if you would still prefer Python once you know Scheme.

I did. Actually, when I found Python (some 20 years ago), I thought - "Here's it - Lisp for real world".

> I am not quite on board with you [sic] claim that Python is chosen for monetary benefits.

I can see it. I used to make a lot of money doing Python programming. About $40k a year more than I ever made doing C, Java, C# or C++. Of course, I did Python more recently, so there is the wage inflation between 1992 and today to consider. Still, you can make a lot writing Python code.

I find this affirmation, while perfectly legit and natural, a really sad indicator of today's state of IT: normally I expect a programmer to be payed because of it knowledge and time, used to solve problems. In that sense languages, libraries etc are simple tools so a metric like "$tool make me earn $amount of money" is a nonsense, something like a carpenter saying "drill make me more money than saw"...

Of course, some tools maybe more effective than others, but I still find sad measure in money terms any of them...

~70k today. Programming python in 92 - nice :)

@xte - I agree with you for the most part; however, I think there are some supply-and-demand considerations to be made. For example, companies who use esoteric or obsolete languages, where the workforce who knows that language inside and out is particularly small (a la Cobol programmers circa late 1990s), should expect to pay more. Where I live, because of the area being inundated with technology boot camps, there is an exorbitant number of JavaScript programmers. Since you can't breathe without huffing a JavaScript programmer, they tend to be paid less.

Also, some languages and applications require a higher degree of knowledge, training, and expertise than others. For example, I would expect to pay a programmer working in robotics more than I'd expect to pay a React or Angular developer.

Having grown up working in construction, I completely agree with your tool analogy though (and used the same analogy in another comment).

@gronne - About three times that, but close. ;)

If you adjust only for inflation then its about 82% cumulative 1992-2018.

Congratulations on being a polyglot! In my opinion, all programmers should be polyglots, since some languages are better than others at various tasks. A programmer who only knows one language seems a lot like a carpenter who is only skilled with measuring tapes to me.

I would go further than that and say that it's also important for programmer to know different paradigms. Knowing C, Java, and Python is surely better than just knowing Java, but they're still quite similar. Ideally people would also learn some functional programming, even if they don't use it, and a Lisp dialect (to appreciate the value of good metaprogramming facilities and get over parenthesis-phobia).

Counter-point: Everyone is grateful for our formative experiences because those experiences shape our identity, and we're obviously heavily emotionally invested in who we are.

But we highly overvalue which formative experiences matter. If I were to get into a time machine, go into your past, remove Scheme and swap in some other language, you'd probably be grateful today for whatever that other language was. It just hit you at the right time, like whatever song was on the radio when you first fell in love.

Every step on our path is dear to us because it got us where we are today, but there are many many paths and little reason to want others to follow in our footsteps. If anything, we should discourage that because the world doesn't need another me or you. It's already got those.

This is exactly it. Nostalgia is overpowering.

Same here. When I learned programming at UC Berkeley in the 90s, Scheme was the intro language. It was perfect precisely because it was so far from being the kind of language you'd use to engineer large projects. The first day, the professor spent less than half of the period introducing the entire syntax of the language...it's so damn simple. Beyond that, all learning was abstraction, problem solving and CS concepts. It was learning how to take a very limited set of primitives and construct a larger whole.

I pity the MIT students that will waste so much of their intro course learning what is a vastly more complex language. There will be so many students that will struggle to learn python-specific topics that are irrelevant to learning the act of coding and may decide that CS and programming just aren't for them. Scheme is such a perfect language for this task because it puts so little between the student and the crucial experimentation phase that can instill a fascination/curiosity with programming. And now MIT students will miss out on that.

We also live in an era where it's basically impossible that kids getting into MIT's CS program haven't been exposed to programming before. I think it's a romantic idea, but the fact is college isn't where you learn to program, it's where you learn the time complexity of btrees.

This is a really significant point. I mean, I love SICP. I think Scheme is elegant as hell. But I learned to program with Basic in high school, and SICP in Scheme would have seemed like a huge step backward. I know Fortran did, which was my first college-level experience. I can appreciate Scheme now, but I don't think I would have then. And I can only imagine how "kids today," who have grown up on real languages would feel ("real" in contrast to Basic, not Scheme).

> it's where you learn the time complexity of btrees.

I’m having flashbacks... Thanks for that ;)

Time complexity was my worst CS topic. At least, for implementing the most efficient system. I’m not an algorithms guy.

> There will be so many students that will struggle to learn python-specific topics that are irrelevant to learning the act of coding

Correct me if I'm wrong - I just went to an unrespected state school - but I would think that the MIT admissions filter selects for students who wouldn't particularly struggle with something as small as language idiosyncracies, especially in an introductory course.

No, you're right. I'd go so far as to say even people at my unrespected state school wouldn't struggle with things like that.

Hm, perhaps your state school is "less unrespected" than mine, but my CS program had a very real funnel from "couldn't hack it in Programming 1" to "couldn't hack it in Calculus 2" to "couldn't hack it in Data Structures and Algorithms" to "couldn't hack it in one particular professor's mandatory upper-level courses" to "tripped on their gown."

I digressed a little. Point being: while I'm unsurprised that some % of people from a broader range of abilities couldn't get functions or iteration or inheritance or whathaveyou to stick, I'd be very surprised if ANY % of the culled-by-18 right end of the Bell curve couldn't grok both fundamental concepts and any relevant part of the standard documentation (on which we appear to be in agreement.)

If you have never been exposed to programming before chances are you will struggle no matter the name of the school. The name will, most likely, help you get a better job but don’t worry about the skill level attained (unless you went to something like Trump university).

> I pity the MIT students that will waste so much of their intro course learning what is a vastly more complex language. There will be so many students that will struggle to learn python-specific topics that are irrelevant to learning the act of coding and may decide that CS and programming just aren't for them.

As someone who has been part of running intro courses using a variety of languages: While I like the Scheme path for various reasons, I do not recognize the effect you imagine at all from the students I've seen. That there are complex areas of Python is basically irrelevant for intro courses, the few pain points are really easy to explain and remember, and Python is great for the experimentation phase (the core is easy enough, the (standard) library ecosystem helps satisfying random interests and can generally also be used without being exposed to problematic parts of the language, REPL)

> It was learning how to take a very limited set of primitives and construct a larger whole.

By this measure C should be a popular university intro language too, but it is famously unsuitable as a first language, at least according to academics.

On the one hand, Scheme has an even smaller set of primitives than C. On the other hand, it's far more difficult to construct the larger whole from those primitives. Additionally, you have all the problems from the compiler when you have to manage libraries, include and object files. With some guidance when students are stuck with the compiler, C is not such a bad language to learn programming, but it doesn't hit the same sweet spot as Scheme.

At Berkeley we've switched out the SICP-based 61A for a Pythonic 61A, similar to MIT. It certainly hasn't driven away any CS students; on the contrary, the number of CS majors has exploded.

The article is 10 years old. Has MIT graduated a generation of failures?

Python was my first, but the computer science course at my university uses Scheme for one of its primary required courses. Really kicked my ass with man-handling recursion and lambdas to no end. Implementing trees (usually binary) gave me a hell of a time. I got so sick of opening DrRacket by the end of the semester.

That being said, I did respect the course and the language. I didn’t understand the science part of computer science before starting the minor and that course opened my eyes pretty wide (as did the Data Structures course). It really forces you to think and understand what you were doing, much less poking and prodding (different from trial and error) than what you could do with Python and its libraries. Plus there’s significantly less information out there on it in comparison. I wouldn’t bring parents into it, they have almost no influence on universities unless they are privately funding/donating.

But my god those parentheses...

> It really forces you to think and understand what you were doing, much less poking and prodding

This is exactly what I look back on so fondly. I already had a lifetime of fiddling with libraries and stack overflow ahead of me, exploring pure computation was a completely eye-opening experience.

I learned Python long before touching anything like a lisp, and the closest thing to functional programming that I’d done before touching a lisp was R. All self-taught, usually in the service of something else I wanted to do. I have no formal training in CS.

And so my use of Racket is simply as a dilettante. And I LOVE it. I have a lot of imposter syndrome and not really grokking data structures the way CS people can tell you the tradeoffs and implementation details of a B-tree. But, I LOVE coding in Racket when I get the chance.

For me, it’s a language where I can jank-hack things together like Python, but having more fun. Wonder if that’s because I never had the fun of Racket sullied by also having to learn data structures and CS fundamentals at the same time?

Do you think that "How to Design Programs"[1] is the best intro book? Should it be followed by SICP[2]?

[1] https://htdp.org/ [2] https://mitpress.mit.edu/sites/default/files/sicp/full-text/...

I really like htdp, it was used for a bit in my intro class as well, but that curriculum also covered concepts that weren’t from the book. I also have been forever grateful for being taught scheme as my first language.

Previous discussion on HN about the second addition:

https://news.ycombinator.com/item?id=14932552

EDIT: I feel like it is not all-encompassing but it is a good start. It is definitely unique in the concepts that it covers.

I think both are valuable: HTDP is the better intro but SICP scales further. For me an ideal CS101 course would be 3/4ths HTDP with a "best of" SICP tacked on at the end.

Scheme is not my first language and I am still greatful for it. I am self learning SICP for past 3 years (after working 15+ years in non-lisp languages). Though still in chapter 2, it has cleared up and simplified my thinking about programming. I no longer consider bottoms up approach to be sin. Understanding new functional language specs becomes a breeze and it 'just clicks'. Though I am yet to understand why Clojure could not implement tail recursion without the 'recur' keyword.

They could for all cases where recur is presently used. Recur serves to indicate and document that the function is supposed to be tail recursive and will cause an error if this is not proper rather than silently not being optimized and blowing up when fed too large an input.

This was a limitation of the JVM.

I vaguely recall one of the recent updates removed that limitation, but could be wrong about that.

If it was any other school than MIT I might agree, but since it’s MIT I doubt that is what the parents are thinking.

If the parents are really that concerned about their kids learning the wrong first programming language in college, then they're not helicoptering enough! Why didn't they teach their kids to program JavaScript or Logo when they were in middle or elementary school?

https://snap.berkeley.edu

https://bjc.berkeley.edu