The Origins of Python
inference-review.com
inference-review.com
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.
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.
All the examples are about Smalltalk and C++.
https://podcasts.apple.com/de/podcast/lex-fridman-podcast/id...
Yes, for example if I see this:
blah () {
whatever
whatever
}
def blah(x):
foo
bar
The } is occluded, so you don't know if it's the whole thing or 3 lines of 5000. Similarly whatever outdented thing comes next is occluded.
Is there a perceivable difference between these?
Reminds me of the discussion that surrounds Objective-S http://objective.st/About
Learn C if you want to do low-level programming.
Learn Java if you want to torture yours...I mean, write and maintain enterprise applications. Yes, that.
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.
After that, IMHO, it’s way more about community vibe and approach, since informs how libraries get written, etc etc
But those require a vastly different approach to learning than C like languages.
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.
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.
I think a HtDP based course with a scheme is still the best to learn to "program"
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.
Or should I go straight to SICP?
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).
There's also Brown University CS173 (related to Grossman) https://cs.brown.edu/courses/cs173/
Hope you'll find something fun in this
[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).
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!
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.
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.
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 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.
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.
go, but that brings along its own set of bug bear problems
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...
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.
2.x and 3.x seem to be diverging philosophically, and I'm not convinced that's a good thing.
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?
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.
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.
A go-kart is easier to learn and to drive than a Formula 1 car.
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.
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.
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.
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...)
10 LET I = 1
20 PRINT I
30 LET I = I + 1
40 IF I <= 10 THEN 20
50 PRINT "DONE"
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.
40 IF I <= 10 THEN 20
i = 1
print(i)
while i <= 10:
i = i + 1
print("DONE")
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.
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.
> 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 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.
You could choose a subset of C++ or just teach C (which would be my preference)
That's what my friend's experience when he tried to switch to programming years ago.
A beginner with Javascript spent 6 months to make backend API, desktop , mobile, web applications with SQL in no time.
The reason i think lies in something more deeply cultural: He think Python is the only thing he should know, nothing else is needed.
> 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.