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.
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.
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
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.
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.
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.
I believe that Scheme's DO is looping.
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.
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.
Oh, and the 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.
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).
I did. Actually, when I found Python (some 20 years ago), I thought - "Here's it - Lisp for real world".