Ruby and Go both adopted extensively from Python, but both rejected the process described in OP of designing a language by iterative experimentation to determine how coders would experience design choices. Instead, each relied on the judgment of a handful of experienced insiders. "*I* know which parts of Python are good and which suck; no need to run my ideas by a few dozen coders before committing to them."
Perhaps not coincidentally, neither has displaced Python. Go obviously had powerful backing from Google. I believe Ruby had enormous tailwinds from the need of the Java community c. 2005 to find an interpreted language, but not one with as mature a community as Python's was at the time. Ruby was at the sweet spot of "usable, but with plenty of niches left for alpha geeks looking to write blog posts."
Finally, I hypothesize the Amber-Brown-batteries-included and walrus-operator kerfuffles demonstrate the limits of managing infrastructure such as Python with the RFC / Usenet model.
A decade or so ago there was an idea that "patterns" (Gang of Four) needed to exist because the underlying language (Java, etc) was limited in it's power or expressiveness.
Go is opinionated, and much of that has hurt the language -- with the go loop semantics coming to mind. Instead of realizing their mistake early and fixing it back in 2009ish, they doubled down on it. Here in 2022, they finally opened it back up for discussion.
I was told by the publisher in 1984 that The Gang of Four was coming out of with a Java version of their book. So I contacted one of the authors, (who remain nameless) who almost ripped my head off when I told him what the publisher told me!
Fascinating read, wasn't aware of this history of python. I thought the line about the fear of not having a copyright statement for ABC was interesting - and applies to many aspects of life in general where setting things free is the right thing to do but also scary.
There was a recent thread about the Amoeba[1] operating system for which Python was initially created. I mentioned Sprite[2], for (or from) which Tcl was initially created.
> When an object is only partially visible, the human visual system extrapolates from the shape of the visible part to form an expectation of what is occluded.
Yes, for example if I see this:
blah () {
whatever
whatever
I know that it is not complete; something is occluded. At the very least, a closing brace:
}
Here, I do not know:
def blah(x):
foo
bar
that could easily be the whole thing, or it could be the first three lines of five thousand.
Just as there is no such thing as a general-purpose transportation vehicle, a truly one-size-fits-all general-purpose programming language does not exist; for a given highly specialized application domain it will always be possible to design a language tailored to, and better suited for, the specific needs of that domain.
In case I wasn't the only one who wanted to run a few toy programs in ABC after reading the article, I've wrapped it up in a very rough asdf plugin here: https://github.com/alisaifee/asdf-abc
Just a small comment on JavaScript and web: it’s perfectly acceptable to build websites of arbitrary complexity by just using server programming, say in Python/Django/Flask and HTML5. I find HTML5 as a valid substitute for JavaScript. Not everything could be done in HTML5, but perhaps things that couldn’t be done, shouldn’t be done anyway.
It depends on the purpose of such intro. For utility programming, even Excel formulas should be a reasonable entry into programming. The formulas, the IF, the index propagation demonstrate the basic programming concepts.
Once familiar with the logic of programming, the choice of language is not that critical. Python is ok, though, personally, I dislike the need for exact indents and often forget that colon...
I find that REPL is rather a complication than a utility in the beginning. Keeping the text of the program in view yeilds better control over the intended logic. In that regard a compiled or a scripted language is not that much of a difference.
In my experience, the hardest part to teach is the approach to decomposing a problem into logical steps. Well, that's the analysis part.
Ruby :) The real question is finding a “learn to program” tutorial that you vibe with. Once you get the fundamental concepts down, it’s way easier to learn most other languages.
After that, IMHO, it’s way more about community vibe and approach, since informs how libraries get written, etc etc
C, JavaScript, any other general purpose language as long as you have a good teacher. I think the importance of which language you pick first is really overrated.
I disagree, pick an interpreted language that doesn’t need compilers or other complicated setup. Python, javascript, something where there’s little friction to getting started, and which has a REPL. Pick a language that a friend or colleague can help you with, this is probably an even bigger advantage, if possible.
My first language was C++ (a very C-like flavor of it) and I really appreciated it later on. A compiler isn't complicated setup (in fact in many cases it's easier than managing Python/JS dependencies).
I really believe in giving people who are learning more credit that they can actually learn instead of trying to dumb things down for them. And I don't mean that JavaScript or Python are dumbed down, I think they're fine first languages too; my point is about generally trusting beginners to learn things instead of unnecessarily simplifying stuff.
Learning is driven by motivation. Motivation is diminished by unnecessary difficulty. Thus, learning via languages that are easier on the uptake will lead to better results.
Memory management and type safety can easily be learned later on... the core essence of programming doesn't involve either of those. It's about defining and composing abstractions, which is language agnostic.
There was a good ‘Programming Languages’ MOOC on Coursera from University of Washington. It used 3 languages in this order: Standard ML, Racket and Ruby.
I already have over 4 years of professional software engineering experience (mostly backend web development). Before that I've been coding as a hobby for like 8 years. I'm pretty good with C, python, and PHP, though I'm familiar with plenty of other languages. I also know a little bit of Haskell.
For a person like me, is HTDP worth it? I had started with it previously but I found it a little boring. But I know the book is well regarded so I'm wondering if I should take another shot at it.
Oh no, HtDP is, in a way, for absolute beginners[0]. SICP has way more sophisticated topics, I think you'll learn more with it. One thing though, lots of exercises on real numbers (it was for Electrical Engineers at the time), some like it, some don't.
Or you may try moocs (if they're still available): EPFL functional programming in scala (by M.Odersky) is great. University of Washington Programming Languages (by D. Grossman).
[0] It's value to me is that it doesn't bind to a paradigm, but innocently make people structure data and destructure it logically in a way that leads to obvious functions. It teaches pre-think rather than write-in-$language-then-suffer. Also being based on scheme opens your eyes to a very simple language (closures and lists).
I think the best intro to computers is assembly language.
My actual intro was Fortran for a few months, then IBM 1401 assembler for the next 4 years, as the limitations of fortran were obliterated when writing assembler.
Assembler gets you to appreciate -- in your 'bones' -- what a computer really is, and how it really works.
You can then see how so-called higher-level languages work after understand their foundation.
Top assembly people generate DSLs for every problem domain, and have a hefty library of subroutines and ready macros. I still believe that, if you are good, really good, you'll do best in assembly. That is, you have the detailed machine knowledge, the proper mindset, the subroutines to do <whatever-is-commonly-needed>, and useful macros (which are a kind of specialized subroutine).
Now. This is true for small machines, and x86 or 68k; but. With the rampant complexity in amd64+ archs, with ultra-complicated instruction sets, it's harder to know every instruction with exquisite detail to produce better assembly than the best C or (probably) Rust compilers.
Still, even if you only use a subset of the instructions of amd64 or arm, you'll learn quite a bit how the machine actually 'does stuff'.
And, if you really take to this sort of thing, there is a future for you in Embedded. Good Luck!
Remember: downvoting is for showing that the comment is not following HR rules. One doesn't downvote because one disagrees to a well-presented truthful argument.
No, in that case, one replies: and begins a discussion.
As usual, I stand by my comments, as they are my lived life experience. And, I believe they are quite accurate, and otherwise a thoughtful answer to the OPs question.
Nobody asked, for example WHY was I writing assembly language for 4 years; but I'll tell anyway: I wrote a compiler for a Python-like language called "Simpletran". It pre-dates Python by several decades, but many of the original ideas in the early Pythons are there.
I feel Python changes and have changed too much to be a good introduction language anymore.
It is not possible for a from zero beginner to read ordinary Python code with decorators, generators or what not and understand it.
Way too many concepts.
It is being choose by intertia at this point and have been ruined for the original target user by former target users who are now professional programmers using it at work.
Large code bases are always going to be hard to read for beginners.
As an introduction language, I don't see why you would need to use decorators, generators or anything? You don't need to learn control flow, functions, variables, etc.
You can perfectly write python without all the fancy stuff. In fact, there are quite a lot of data scientists who are paid to write python and don't know the first thing about concepts as seemingly basic as classes.
> I don't see why you would need to use decorators, generators or anything? You don't need to learn control flow, functions, variables, etc.
I think the point here, is that when beginners start exploring what's out there in "professional" lands they'll quickly discover that they don't know Python at all, because they were using this primitive subset of a language.
But in what language is that not true? You start learning any language by pieces, and just because you know 10% of the language doesn't mean you're ready to write it professionally, this is true for any language.
> and just because you know 10% of the language doesn't mean you're ready to write it professionally
I don't see why not. Plenty of folks learn on the job, including new languages, and the way things work out you might end up implementing some things sort of by kitbashing, knowing relatively little of the concrete details that you end up learning completely more later on. I do this all the time.
To compare, let's look at C. At "only" a couple hundred pages, the C language spec is simple enough. The language doesn't have all those fancy things like decorators, pattern matching, lambdas, etc.
But after 30 years of programming, do I actually know C? Once I dig into C compilers, undefined behaviors, etc. I can also quickly convince myself I actually don't know C at all...
MicroPython or CircuitPython have become better entry points than the full language.
Python grew up and has been chosen to solve a lot of complex, important problems. This has lead to the language ballooning to become not just good but excellent for those problems (data science). Some of it might be fluff; much of it might not be relevant to your style or problem space.
Ye for the professional programmers using Python I guess the changes are welcome. It is easier to keep up with additions over time rather than getting them all at once. C++ has the same problem, but it's selling point has never been easy to use.
I'm one of those people who worry that Python - which used to be pretty accessible - is heading in the same direction as C++, and will be buried under archaeological layers of cruft and obscurity.
2.x and 3.x seem to be diverging philosophically, and I'm not convinced that's a good thing.
> It is not possible for a from zero beginner to read ordinary Python code with decorators, generators or what not and understand it.
Having taught beginners both python and other languages, I’d say it’s significantly easier to teach decorators than it is to teach higher order functions normally. Because in python the students have already seen, used and understood what the cache decorator does before we even touch the concept of a function returning another function, which they always need some time to grok, both in python and other languages.
As for generators I’ve never seen anyone struggle with them. What do you find difficult to understand about generators?
Generators have a few footguns even for seasoned developers, calling len(mygen) or mygen[4] works, but after that it's empty when trying to iterate it. Particularly problematic is when someone adds a log of the generator content, exhausting it before before it is used. All this leads to people shotgunning mygen=list(mygen) on everything, without understanding what really happens.
How one could solve this i don't really know, generators are such useful concept that you can't really remove them either, and you still want them to be compatible everywhere other lists and iterables are. Even with type hints, it's not exactly obvious when you type the code whether a certain variable is a generator or a concrete list, both of them mostly adhere to the same protocol.
A zero beginner doesn't need to read ordinary Python code with decorators etc. The beauty of Python as a teaching language is that none of those things are necessary to explain or handwave to write simple apps that just input and print strings and numbers - which is just enough to teach basic concepts like conditionals, loops, functions etc. For bonus points, it even has turtle graphics out of the box, which is an excellent visual explainer for more advanced concepts like recursion.
And when they've learned the basics on toy stuff and want to start writing real-world apps, that is when you explain decorators, generators etc. And yet they don't have to switch to a whole new language - all the basics they've learned still work exactly as they did before.
I still love the interactive interpreter. It's such a fantastic, no friction, teaching tool, especially for in person demonstration of fundamentals with immediate feedback. Its been an invaluable tool in showing my daughter (9) concepts I have difficulty describing in a way she can understand.
Some of the best drivers started out in go-karts, something about the feel of the road and getting the most out of such a limited vehicle.
I would not call python a go-kart I would call python a mini-van. Boring and looked down upon, but is the best vehicle around for doing your daily activities in.
I feel like python has never been a good introduction language. It is simply too abstract and hides too many details that are often required in other languages (Python is simply too flexible). It is good to learn if you are only scripting or calling library API, but I feel like it is a poor starting point if the goal is to transition into languages with more rigid structures such as C++.
Python is a good learning language precisely because it hides those details. This allows people to the learn the basics like variables, loops, strings, etc without getting overwhelmed with too much at once.
This absolutely provides a good foundation to learn lower level concepts later, although going bottom-up and starting with a language like C is also a valid path.
It’s also worth noting that a large proportion of developers will never learn C++, and will stick to higher level languages their entire career. And another chunk will only learn the lower level stuff much later when they have many years of experience to lean on.
If your goal is to immediately become a C++ developer, then you should learn C++, but that isn’t most people learning to program.
>>> Python is a good learning language precisely because it hides those details. This allows people to the learn the basics like variables, loops, strings, etc without getting overwhelmed with too much at once.
I wonder if whether this is a blessing or a curse depends on the person who is learning it. For instance, my first language was BASIC in 1981, and so my gut reaction to discussions about learning languages is that BASIC lets you at least imagine the workings of the machine that's running your program. The teacher can draw boxes on the blackboard to explain 10 LET X = X + 1
And we weren't far from the machine. There were not very many turtles on the way down to the level of logic gates. I also learned how a microprocessor worked, reading books as a high school kid, and articles in Byte Magazine, something that would be laughable for today's big CPU's.
That's a bottom-up approach. For others, a top-down approach might be better, e.g., seeing mathematical equations develop, in beautiful notation, without caring what the machine is doing under the hood.
Another comment in this thread mentions the ability to read code. Python has sprawled. I've been coding in Python for 10 years (as a "scientific" programmer) and recently took a Python skills quiz. I mentor beginners. Yet I scored barely at the top of "average." I can't read the code that's in a lot of the more elaborate Python packages.
A problem is motivating people to learn a learning language when they know that they'll outgrow it.
I'm not sure I understand what's missing in python compared with BASIC.
Sure, you can teach students to write `print(" ".join(str(x) for x in range(1, 11)))` to print numbers from 1 to 10... but you don't have to do that. In fact, `X = X + 1` works just fine. The old school BASIC style like `X = 1; while X <= 10: print(X); X = X + 1` still works in python. (sorry for the lack of indentation)
What am I missing? (besides the misguided social expectation that you need to teach the fancy generator stuff to a total beginner...)
That's a good question. What I'm thinking of (revealing my age) is something more like:
10 LET I = 1
20 PRINT I
30 LET I = I + 1
40 IF I <= 10 THEN 20
50 PRINT "DONE"
And because BASIC really is that primitive, you can talk about what each line of code is doing, without too much fiction. The mental virtual machine is not radically different from the real machine.
The teacher would draw the variables as boxes with numbers in them, and update the numbers in the boxes with the eraser and chalk (further revealing my age).
In contrast, Python starts with everything is an object, with properties and methods...
But I agree about the fancy generator stuff. I think you can teach Python in the same fashion by limiting yourself to a few basic (sic) features, and adopt the same virtual machine fiction while remembering that it's a few more layers of abstraction away from reality.
Do mean "GOTO 20"? Because if you don't that line either makes no sense or has a "magic" implicit goto that has to be explained. Assuming you meant that as a loop then the equivalent in Python is hardly difficult to understand:
i = 1
print(i)
while i <= 10:
i = i + 1
print("DONE")
Same number of lines of code, `while` has a clearer meaning than the magic of your goto-less line, and is still somewhat clearer (more comprehensible control flow) than the goto version of that line. The only missing thing is the explicit line labels, but that can become a presentation format when discussing the code. Every editor you'd start a student with can show line numbers (and many show line numbers by default).
You don't have to start with "everything is an object", but you will get there quickly. Teaching procedural programming centered on numbers and strings and basic control flow in Python is not a challenge for a competent teacher. And then the language can grow with the learner as they gain understanding of computing and programming.
While learning, hiding details is important, but Python overdoes the abstraction. `for` loops and iterator based loops have been merged into one thing, and I am sure people write `for i in range(10)` without a good understanding of what the `range` function does. Even strings blur the line between individual characters and actual strings. The lack of clarity at these basic concepts is precisely why Python is not suitable as a first language, since it hides concepts that are prevelant in all other mainstream languages. As a result, I have often seen students develop bad coding habits and poor mental model of why their code works. Instead of learning proper programming concepts, they just know the syntactic sugar and abstractions that Python offers.
I do agree that Python provides a very small startup cost to writing code, the details are sacrificed to acheive this. This may be useful to capture interest/generate motivation and get a quick prototype/"helloworld" out, learning Python is only good for learning Python, not for programming in general.
Frankly I think classic c-style for loops are a terrible abstraction for beginners. Iterator based loops make sense on a high level ("I don't care how it works, I only care what it does"). And while loops make sense on a low level ("I can see how each piece works"). To a beginner, c-style for loops are just an obscure, implicit syntax for while loops.
> Even strings blur the line between individual characters and actual strings
IMO that's better than what C++ does, where it pretends that a character is a single byte. Whereas most code nowadays is using unicode, which means that code will break as soon as they try to store a non-ascii character in it.
If you can understand the “for i in” part means then range should not be hard to grasp. I would argue that someone new to programming with even a modicum of logic might be able to guess what range does easily .
Range is horrific for beginners. Try explaining to a kid learning coding why his times table program needs to say ```range(1,13)```. There are excellent reasons for this construction, and to prefer half-open ranges, but providing a good on-ramp for kids ain't one of them.
I upvoted you even though this is wrong because it raises a good point.
If I was teaching beginners I’d do 1/3 python assignments and 2/3 C.
They need some easy wins at the start and to learn control flow and basic concepts. But mixed in with that we’d do C and learn what’s happening under the hood.
The easy wins are so key. I remember my intro class and we had to just copy some C++ code and compile it. Even though I felt like I copied the code exactly I got these incomprehensible error messages and just felt overwhelmed.
I actually quit the class after feeling like nothing would work and not having any fun.
Only years later doing a project in Visual Basic did I realize coding could be fun.
Those sound like two very different individuals, or like they chose very different sets of learning materials/teachers. The difference between Python and JS for that is almost nonexistent except that it can't be used (directly, or at least not easily) as the frontend for a web application (in the browser).
> The reason i think lies in something more deeply cultural: He think Python is the only thing he should know, nothing else is needed.
That's the problem, then. And it's also not part of Python "culture", it's his problem (but not just his, others fall into the same trap). I've had plenty of colleagues who swear by C, C++, Javascript, <language of their choice> and are incompetent or barely competent in any others. He made a mistake, which is unfortunate. He would have benefited from a mentor (or a better mentor if he had one). Real programmers understand that languages mostly don't matter except with regards to the libraries they have access to or the platforms they run on.
That made me think for a long time. Because when i choose a language to teach newscomers/students, it's really important for me to not make them fall into the trap due to the culture. Newscomers is different from experienced programmers who know language is just a tool.
Perhaps not coincidentally, neither has displaced Python. Go obviously had powerful backing from Google. I believe Ruby had enormous tailwinds from the need of the Java community c. 2005 to find an interpreted language, but not one with as mature a community as Python's was at the time. Ruby was at the sweet spot of "usable, but with plenty of niches left for alpha geeks looking to write blog posts."
Finally, I hypothesize the Amber-Brown-batteries-included and walrus-operator kerfuffles demonstrate the limits of managing infrastructure such as Python with the RFC / Usenet model.