Or, clearly, any appreciation of irony.
365 karma · joined November 18, 2016
Everything in Python is late-bound, untyped, and mutable by default. Straight off the bat that’s three key design decisions that make for a slow interpreter. Defining numbers as heap objects, implementing structures as hash tables, and poor parallelization (<koff>GIL, dumb POSIX threading) are three more.
Sure, you can throw huge amounts of brains and resources at code analysis, opportunistic JIT, and the rest a-la V8, but at some point you have to say “Is this an effective use of those valuable resources?” Especially when every such optimization could potentially break existing, stable user code running in production.
..
But, let’s get back to larger perspective:
Faster overall takes into account not just the time it takes to run a user program, but also the time it takes to learn, implement, debug, and deploy. Only one of these is machine time, which these days is cheap as chips and nearly inexhaustable; all the rest are human labor, which is both expensive and limited.
Which is not to say that Python is faster at all those human tasks than other languages. To determine that would require real-world practical testing, plus a willingness to accept what those tests tell you (which might not be what you wanted to hear). But I’m willing to bet that the time spent on all those manual tasks vastly outweighs the time saved by 20% faster runtime for the vast majority of use cases.
So at some point you have to stop and ask: Are these fundamental changes adding genuine, measurable value for real-world users solving real-world problems? Or is it just code masturbation basement nerds whose idea of productivity is playing with internal guts in pursuit of some trivial abstract benchmarks?
Because, honestly, “20% faster” is an absolute joke. If I can’t make my program 200% faster just by adding a second hardware box, then I’ll want to know why. And if the answer is no more complex than “because the language isn’t very good at parallelism”, then all other arguments are completely moot.
..
Look, I’ve written slow interpreters. Implemented in Python, no less. A not-very-complex program might take 2 minutes to run. But then, 80% of that painfully long run-time is actually IO-bound operations, and even that is totally irrelevant when those 2 minutes of machine time have replaced 20 minutes of manual work.
That’s 20 minutes of paid human labor, eliminated by a really-slow custom interpreter written in pretty-slow CPython. You can easily put a dollar cost on that human time (salary, etc) and multiply it by the number of work units in a year, and you’ve calculated its real-world benefit.
Let us know when you can calculate the real-world benefit of a 20% quicker proprietary Python-like interpreter that may or may not execute user programs exactly the same as CPython. Otherwise, as I say, anything less than a magnitude’s improvement isn’t even worth getting out of bed for.
Doesn’t bother me; I’ve got points to spare.
What downvoters haven’t got, it seems, is any arguments.
Which is an admirable sentiment… but the title of this thread is not “Python: still doing useful work” but “Python: now 20% faster”, and being ridiculously self-congratulatory about this when the correct response is to laugh at the silly pointless frivolity of it.
Trying to make Python fast is a fool’s errand, because Python is slow by design.
A useful argument would be that Python is faster overall at solving various real-world problems than current alternatives; but that’s not the popular argument being made, because the population fixates on minutiae instead of overall perspective.
And I say this as a 20-year Python user myself, ’cos while it has scratched many itches and continues to do so, I am not the least bit sentimental about it. The best compliment would be to kill it with something far better, that steals all its good parts and replaces the rest.
The Python language is already 30 years old, and it wasn’t even the cutting-edge in imperative language design (<koff>Smalltalk, Lisp</koff>) back then. It’s positively antiquated now.
I’ve never understood this tunnel-vision obsession with endlessly chasing ever-diminishing returns. It’s Zawinski's Law of Software by way of Greenspun’s Tenth Rule, and a fundamental failure of courage.
Learn the lessons from both the good and bad of what’s been done before, and move on. A better long-term answer would be to design a much faster, more efficient language for running Numpy, Scikit, and Tensorflow, then port those libraries over to that. If that language turns out to be good for other things too, then great. If not, let a thousand flowers bloom.
There is a much larger learning opportunity here, to get a whole lot better at migrating extant code bases from an old, popular, dead-ended language to a new, upcoming one. But it’s like finding your way to Carnegie Hall: it takes practise, practise, practise.
Alas (for me), scaling that success to a $1Tn global packaging industry has proved way harder, in significant part due to the penny-pinching bean counters and talentless middle-management hacks: useless people who won’t spend a penny or commit to change when they can pay themselves the same salary for never taking a single risk or decision at all.
So what are the chances that Cook’s Apple filled a room with highly-educated experts and told them to invent a grand impressive automation solution without ever sitting with all those “little people” who make the stuff by hand in order to learn their jobs from them? From what I’ve seen of “real” applications development, and the gall of major industry vendors who rake in millions selling big-iron “solutions” that simply don’t work out on the shop floor beyond their glossy canned C-suite demos, I’d wager that’s the norm.
Ah well, now I know how Papert must’ve felt. Back t’drawing board…
Personally I see successful high-level automation as much more meritocratic, in that it both serves and is directed by the same individuals: the users themselves. The worst that can happen there is that you automate yourself out of your existing job; but if you can’t think of how to parlay that win into your next then your imagination picked a funny time to fail on you now.
For instance, how often do you declare a variable as `int`, when what you really want to say is “an integer in the range 0...100”? A few languages (e.g. Eiffel) provide a formal mechanism for declaring these sorts of constraints, but most don’t, and you end up putting what should be declarative type-level information into the body of your code instead.
And then there’s “cutting-edge” stuff like dependent types, where you really want to express one argument’s type in terms of another argument’s, a classic example being an array indexing method, where you really want to declare the index at compile time as an integer in the range `0..<array.length`, and let the type system propagate that rule and its implications throughout the code that uses it. Whereas most “modern” languages chuck a run-time error if you’re lucky; or just ralph and dump stack like some antiquated 1970s throwback (yeah, looking at you, Apple’s Swift).
3/10 Could do much better.
Also, TBH, types are kind of the wrong answer to the question. The question should be: How do we make the language efficiently expressive? For my money, that means defining constraints primarily on the code’s main interfaces, which a given constraint may be a combination of traditional generics, dependent types, and/or declarative run-time checks on input/output values. (e.g. Eiffel comes to mind.)
For instance, in my kiwi language I can define an argument as:
list (whole number (0, 100), 4, 4)
define type (CMYK color, list (whole number (0, 100), 4, 4))
Kiwi’s very late-bound and interpreted, so its constraints are implemented solely as run-time coercions with optional bounds checks; nothing fancy. But the semantics are quite well formalized so a linter could be implemented as an assistant authoring tool for users, and if you can implement a linter then you can implement a type checker; and so on.
What matters is that the language has a formal mechanism by which it can guarantee that a given value will always satisfy one or more user-defined requirements; and whether those requirements are checked at compilation, execution, or some combination is secondary to that. How rigorous the user makes these declarations, and if/where she makes them, is entirely up to her.
Remember, the goal of any language is to please its users. Not the machines it runs on, nor the designers who created it. And users’ needs are not constant, not even across the development cycle of a single program, so a language that cannot adapt to those users’ changing requirements as it goes has already failed its first hurdle.
..
Perhaps if authors of existing languages like Python and C put less effort into chasing the constantly-diminishing returns of post-hoc micro-optimizations, and more into thinking how to design the next generation of languages so as to carry forward the good characteristics of their predecessors minus their original already-painted-themselves-into-a-corner limitations, we might actually have languages that tick all the boxes by now.
Steve Jobs would’ve flayed the lot of them till he got exactly what he wanted. Cook’s mediocrity simply shrugs and rolls on, with nothing learned at all. #PerfectlyOiledCuckooClock
Complex automation works best when placed in the hands of skilled humans, as an amplifier of human ability. Let them use the machines to accelerate all their mundane repetitive crap, while retaining the human ability to make reasoned decisions and handle corner cases and errors intelligently.
But perhaps a more logical place to start is by automating away the penny-pinching bean counters’ and talentless middle-management chair warmers’ jobs? Dog knows they’re reliably useless at it themselves.
and:
“TODO: Tutorial goes here”
Says it all, really.
..
Pascal is [thataway](https://www.freepascal.org/) for those that care.
https://sciencebasedmedicine.org/great-barrington-declaratio...
Iran had a secular, democratic government. It was overthrown by the UK and US who installed a brutal dictatorship just so they could get their oil cheap, so you can kind of see how Iranians might conclude that “democracy” isn’t worth the paper it’s written on and the only defense is a bigger bunch of bastards than the other guys’.
https://en.wikipedia.org/wiki/1953_Iranian_coup_d%27%C3%A9ta...
See also: Post hoc ergo propter hoc and Texas sharpshooter fallacies.
Her first instinct was not wrong. I’ve been coding 20 years now (self-taught automator who turned pro after the first 10), and though I absolutely love what programming enables me to do I still despise the amount of hostility and crapwork that “popular” modern programming platforms put me through in order to do it.
I hope your daughter goes on to achieve whatever she wants to achieve, and if that should be programming I hope she never forgets that early distaste, because that is the only thing that will drive substantive improvement in a culture and industry grown fat and complacent on the sorry status quo.
--
“The reasonable woman adapts herself to the world: the unreasonable one persists in trying to adapt the world to herself. Therefore all progress depends on the unreasonable woman.” ― George Bernard Shaw (paraphrased)
That’s not Logo, that’s the teaching. The whole point of Logo is that it should be 99% self-taught. The teacher’s job is to teach the bits that aren’t naturally discoverable (see my three steps above), and to offer hints and nudges towards rich new areas for exploration should they bog themselves down in old, crude inefficiencies and repetitions.
Bad Logo teaching is making kids memorize what all the buttons are called and what each one does when you push it, of setting “problems” that have one right answer which the student must return or is penalized for being wrong.
Yes the “turtle” was limited, and if all you ever did was draw “turtle graphics” with it then, yeah, you’d quickly grow bored.
But being limited to turtle drawing only was a limitation of the hardware and software of Papert’s time, plus the inability of most adults—particularly those in charge of the purse strings—to see the need to expand that platform to provide other opportunities as well. That damned turtle should’ve been just the first of a myriad of Logo “expansion packs”, but those damned grown-ups couldn’t see that because they lacked the imagination to do so. (Though if they had, they’d have been terrified by the thought: creating kids who think for themselves and can run circles around them—inconceivable!)
Because all those adults saw Logo as was just another hoop to teach students to mechanistically jump through in rote-taught lessons before putting it away and moving onto teaching the next hoop, not as an open-ended user-led tool to be put in the hands of the kids so that they can explore and experiment and teach themselves while pursuing whatever it is that is of interest to them.
That’s the worst thing about authoritarians: all they ever want to do is to make more of the same.
Don’t. Instead imagine a computing environment that facilitates the basic reading and math skills he’s now attempting to practise.
Age 6 is a bit young, but by age 8 a child starts developing the capacity for abstract thought, which enables them to turn those rote-taught skills into useful practical tools which they can apply to the problems that they themselves want to solve.
Again, go read Papert’s Mindstorms. It is worth their weight in gold, if/once you can understand it yourself.
The foundational mistake is “teaching programming”. The goal should be to instill (“teach”) critical thinking and analytical problem solving skills, and a “programming environment” just another tool, like pencil and paper, which the student can use when exercising those skills on real-world problems.
Whereas “teaching programming” is teaching language features: what all the buttons are and what they do when you push them. Thus mastery of button-pushing becomes feted as the end-goal of itself, instead of being just some tiresome but necessary tool-practising crapwork (like memorizing the ten-times tables and drawing all the letters from A to Z) that you have to go through on the way to achieving your true goals (which can be anything).
Once again, I point to Papert’s Logo[1] as a good demonstration of just how simple that PE can—and should—be to serve that purpose. Logo’s core concepts can be communicated in just three steps:
1. This is a Word.
2. This is how you Perform words.
3. This is how you Add your own words.
Anything else that the platform provides, such as its dictionary of pre-defined words, can and should be explorable and discoverable; something today’s hardware and software can support and encourage without blinking. Let the students teach that crap to themselves if/as/when they need it, and keep the adults on hand just to observe when students start running themselves down a dead-end and prompt them to other possibilities they had not realized/considered.
Oh, and it really should go without saying that the PE’s error messaging must be the top of their class. Because errors aren’t the “wrong answers” of which a student should feel embarrassed and ashamed, but fresh questions in their own right which spark awareness, exploration, self-correction, and insight.
--
[1] https://www.amazon.com/Mindstorms-Children-Computers-Powerfu...
It’s not just me either, but I say it because it needs to be said, because unless you identify the failure there’s no hope in hell of finding a fix. Mac Automation isn’t on its ass because it’s old or bad technology; it’s on its ass because it was horribly mismanaged by a clueless incompetent of a project manager.
The tech could still be fixed; the problem now is politics. That’s why I think it’s borked, but until the last ax drops I’ll keep on trying to salvage it anyway because I care that much about the fundamental principle: putting power and control back in the hands of the users.
Heh, I still have mine.
https://www.dataserve-retro.co.uk/contents/en-uk/p92.html
Yeah, assembler killed my early interest too. If only the Beeb’d shipped with Logo instead of BASIC. That I (now) get.
Though for epic covers this one still can’t be beat:
https://www.amazon.co.uk/Zx81-Basic-Programming-Sinclair/dp/...
Elite… ahh, memories of misspent 6th-year biology. (Beebs were standard fixtures in 80s UK schools.)
Voltmace joysticks FTW, amirite
Thus Logo got placed into the box labeled “How to Teach Programming”, when that was never its goal: its purpose was to provide children a tool to explore and play with math and numbers and how to think for themselves.
It reminds me of Feynman’s excoriation of “New Math” textbooks (https://rangevoting.org/FeynTexts.html):
“Finally I come to a book that says, "Mathematics is used in science in many ways. We will give you an example from astronomy, which is the science of stars." I turn the page, and it says, "Red stars have a temperature of four thousand degrees, yellow stars have a temperature of five thousand degrees . . ." – so far, so good. It continues: "Green stars have a temperature of seven thousand degrees, blue stars have a temperature of ten thousand degrees, and violet stars have a temperature of . . . (some big number)." There are no green or violet stars, but the figures for the others are roughly correct. It's vaguely right – but already, trouble! That's the way everything was: Everything was written by somebody who didn't know what the hell he was talking about, so it was a little bit wrong, always! And how we are going to teach well by using books written by people who don't quite understand what they're talking about, I cannot understand. I don't know why, but the books are lousy; UNIVERSALLY LOUSY!”
..
Yet the problem wasn’t New Math itself, which was about giving kids the confidence to play with numbers, teaching them to explore and experiment for themselves, not obediently jump through rote hoops like some circus dog mindlessly converting canned inputs into “right answers” till utterly bored by the whole process and turned off all math for life.
The problem was these “New Math” textbooks were clarly written by Old Math teachers—and those teachers had no interest in learning or doing anything different, so they just wrote old math lessons as before, skimmed over with a shallow mimicry of “new math” language; a zombie draped in the flayed skin of its erstwhile successor, and an atrocity to all math, both old and new. A threat of change, successfully defused; the status quo ensured. Old Math teachers could safely go on teaching their old math to their millions of students who would safely go on failing it.
..
Papert himself was a mathematician, a lover of math so frustrated by maths’ inaccessibility to millions of kids that he devised a tool to make math friendly and accessible, even fun.
Papert’s mistake was not in teaching kids how to use Logo to learn for themselves, because kids can learn anything, including how not to learn and to hate learning itself. The kids got it, and the teachers who got kids got it too. All that part worked great.
No, Papert’s mistake——and it seems obvious in hindsight—was in not teaching Logo to the people in charge. Why should they want to change anything, when their current practices clearly work well—after all, why else would they have been promoted to be in charge of it all?
But without all the decision-makers (head teachers, school boards, education departments, government, and parents) on-side, no greater change could be effected, and the entire project doomed to fail. Because, in all those Responsible Grown-Up eyes, Logo is “Programming”—and they already had a box for teaching that. And so in it went, and—yay!—for there was no more unwanted disruption in class.
..
Which is ironic, when you consider that any old foul-tempered Master of Ancient Greek could have taught them just how grossly wrong they were in their perception of Logo, no doubt with a sound thrashing to accompany the lesson too.
Logos - Longer definition: The Greek word logos (traditionally meaning word, thought, principle, or speech) has been used among both philosophers and theologians. In most of its usages, logos is marked by two main distinctions - the first dealing with human reason (the rationality in the human mind which seeks to attain universal understanding and harmony), the second with universal intelligence (the universal ruling force governing and revealing through the cosmos to humankind, i.e., the Divine).
Sal Soghoian isn’t a programmer—I’ve seen his code, it’s embarrassingly amateur.
Sal was not responsible for AppleScript of Apple event IPC; that was Cook and Harris, and that credit is theirs[1]. They walked out of Apple shortly after AppleScript 1.1 was released when Apple abruptly slashed their team. Sal had no part in its creation.
Sal was an enthusiastic end-user and early adopter, who talked himself into taking over what was left of that department some time later. Unfortunately, his gift for the gab was not matched by skills in product development and marketing. Classic case of Peter Principle in action.
Automator was Sal’s, and while it wasn’t a bad idea it failed as a popular product. It was badly positioned as a standalone app, which the standalone Script Editor already demonstrated doesn’t create interest or adoption. To sell it as an end-user solution it needed to be positioned where the end-users’ problems are: within the end-users’ apps. Automator should’ve been a self-contained GUI control for App developers to embed directly into apps, alongside the existing AppKit NSRuleControl and a standard menubar “Tasks” menu to provide high-profile visibility and instant access.
Soghoian’s team was also responsible for Scripting Bridge (10.5) and JavaScript for Automation (10.10), which should have won Mac Automation millions of enthusiastic new users amongst Python, Ruby, ObjC and JavaScript geeks, but were so technically dreadful that they even made AppleScript look good in comparison.
Worse, once released, Sal made zero effort to promote or support them, never mind fix their flaws; even today, a decade on, 99% of Mac programmers have no clue that these “programmer-friendly” alternatives to AppleScript exist.
..
Ironically, there was a true programmer-friendly alternative to AppleScript already available back in 2006: appscript[2]. I wrote appscript precisely because I was an AppleScript user who loved the automation but hated the language, and found all the other 3rd-party Apple event bridges painfully flawed. While my promotion of it was crap, programmers who used it adored it, because it worked for them and, unlike AppleScript and SB, didn’t lie or obfuscate how Apple event automation really worked. (Hint: it’s not OOP, it’s RPC + queries.)
Appscript was good enough that Apple even considered including it in Mac OS X… till Sal Sherlocked it with his crappy broken Scripting Bridge framework, wrecking them both.
..
As for 2014’s surprise announcement of JavaScript for Automation, that should’ve been Mac Automation’s instant salvation, launching just as interest in desktop JavaScript was taking off thanks to Node.js. Knowing its success was critical to Mac Automation’s survival, I even gave that jerk six weeks of my unpaid time to test and critique the tar out of it; even writing a JavaScript OSA reference implementation[3] for them to copy and/or steal.
Halfway through Sal went radio-silent on me, which I should’ve recognized as a warning sign; but I’m a dope. Sal ignored my feedback, JXA shipped half-baked and broken, I scrapped all my plans to write the book and support its community, and Sal did bugger all to promote and support it himself. JXA sunk without trace, and Sal was still utterly clueless that he’d just killed Mac Automation and his own department as well.
Even then, Sal had one last chance to salvage the situation: by 2015 Swift was just about ready for production use and interest in using Swift was exploding. All Sal needed to do was hook Mac Automation onto Swift’s coattails and let Swift lift it upward for free. Seeing this opportunity coming I had already created SwiftAutomation[4] as a free, ready-made solution.
Alas, I made the mistake of offering SwiftAutomation to Sal—and the patronizing fool threw the offer back in my face. At which point I told him he was a arrogant incompetent unfit for the job who’d run Mac Automation into the ground. I got some bitter satisfaction when Apple sacked his useless ass not long thereafter; unfortunately, he took the whole team down with him, leaving the entire AppleScript stack parked in minimal maintenance mode and unloved disgrace.
..
And that’s Sal Soghoian’s TRUE legacy: not as the inventor of Mac Automation, but the incompetent who killed it.
--
[1] http://www.cs.utexas.edu/~wcook/Drafts/2006/ashopl.pdf
[2] http://appscript.sourceforge.net/
[3] https://sourceforge.net/projects/appscript/files/
[4] https://hhas.bitbucket.io/welcome.html
--
Postscript:
For a time I did wonder if it was just me (I am am extremely prickly arse), but then I saw him pull the same arrogant condescending ungrateful crap on another experienced developer who was kindly pointing out some problems in Sal’s (JavaScript) code and offering constructive improvements. Textbook Dunning-Kruger syndrome combined with old-school Not Invented Here, and perfectly described in a great series of articles by Erik Dietrich: the “Expert Beginner”.
https://daedtech.com/how-developers-stop-learning-rise-of-th...
https://daedtech.com/how-software-groups-rot-legacy-of-the-e...
With Logo you would do exactly the same. In fact, growing the language’s base vocabulary with your own words is the whole point of Logo and Forth. Why waste your entire lifetime speaking the machine’s primitive, low-level language when you can teach it how to speak your own powerful, high-level ones?
+1 for using the amazing horseshoe crab† as cursor, but -1,000,000 for so utterly missing the point.
--
† Not actual crabs, they’re more closely related to spiders and have lived on Earth virtually unchanged for almost half a billion years. https://oceantoday.noaa.gov/fullmoon-remarkablehorseshoecrab...
/s #APillForEveryIll
--
“For every complex problem there is an answer that is clear, simple, and wrong.” H. L. Mencken
Obvious red flag is obvious, because once you start looking for something in particular you do start finding it everywhere you look.
https://en.wikipedia.org/wiki/Confirmation_bias
This is why we developed the scientific method, to act as a filter for such human follies. That the author is still hypothesizing instead of rolling up his sleeves and doing the actual work to DISprove his own ideas speaks volumes.
Or, to put it another way: it is not sufficient merely to gird oneself in the mantle of Marshall and Warren; one must also swallow the H Pylori and serve their hard time on the shitter.