EEVblog Electronics Community Forum
Products => Computers => Programming => Topic started by: cfbsoftware on September 20, 2022, 11:29:59 pm
-
I was intrigued to see what the next generation of Bill Gates's, Steve Jobs's, Linus Torvalds's etc. are cutting their teeth on:
https://codakid.com/coding-tools-for-teens/
-
Is this an advertisement? ::)
Oh wait, this shit is written by one of the companies being "reviewed" :-DD
They also aim to encourage participation from women and underrepresented minorities which is a worthy mission.
Say your teen starts coding an app on the school computer but can’t finish it before school lets out. When he gets home, he can easily log back in to App Inventor using to pick up where he left off.
How did this blog even pass their social justice review process? ;D
-
With these drag and drop tools I fear a flood of more and more crap programs on your tablet, phone or computer.
That is layer upon layer of possible errors, with the need for update upon update, even worse than seen today.
Sure it is nice to get some acquaintance with "programming" but should be followed up with decent learning about "real programming".
-
I don't understand the need to change "programming" to "coding".
-
I don't understand the need to change "programming" to "coding".
A "coder" is usually way cheaper than a programmer.
-
I don't understand the need to change "programming" to "coding".
A "coder" is usually way cheaper than a programmer.
There you go. Who would have thought there would be any other motive than decreasing costs and increasing profits?
-
I don't understand the need to change "programming" to "coding".
A "coder" is usually way cheaper than a programmer.
typist vs. writer ?
-
There you go. Who would have thought there would be any other motive than decreasing costs and increasing profits?
Actually, there are. Some of those "learn to code" activists are driven by little more than feminism or other forms of egalitarian fundamentalism. But any money they get comes from donors, and the donors are those who have money to throw at this particular issue, so go figure. Besides, Americans at large really want to believe all that tabula rasa stuff and insist that there are great untapped resources of cheap intellectual labor among the underrepresented/underfunded/undereducated/overlooked/overneglected/etc.
A "coder" is usually way cheaper than a programmer.
typist vs. writer ?
It's not really a serious distinction, nobody working professionally calls himself a "coder", and frankly in English "programmer" is not common either. In their pretentiousness, coders usually self identify as "software developers" or "software engineers", even in absence of any engineering degree ;)
The word "code" is exclusively used by activists trying to get the unwashed masses to program computers. Maybe they don't want to make it sound too serious or scary. And I'm glad they picked their own word instead of piggybacking on "programming" or "development", it makes them easy to spot.
-
There you go. Who would have thought there would be any other motive than decreasing costs and increasing profits?
Actually, there are. Some of those "learn to code" activists are driven by little more than feminism or other forms of egalitarian fundamentalism. But any money they get comes from donors, and the donors are those who have money to throw at this particular issue, so go figure. Besides, Americans at large really want to believe all that tabula rasa stuff and insist that there are great untapped resources of cheap intellectual labor among the underrepresented/underfunded/undereducated/overlooked/overneglected/etc.
And... the only real motive for all of this crap is IMHO to increase profits as well. The rest is just rosy bullshit to sweeten the pill.
So, in the end, there aren't.
-
In any case, drag and drop programming environments are really nothing new
-
I don't understand the need to change "programming" to "coding".
It was required when "programs" were replaced by "apps" ;)
-
I don't understand the need to change "programming" to "coding".
It was required when "programs" were replaced by "apps" ;)
FYI, in the Mac world, where executables have always been officially called “applications”, the abbreviation “app” has been common since the 80s, with no negative connotations about the program’s complexity. (In fact, rather the opposite: apps were the things you do work in. The little helper tools were “utilities”.) Photoshop, Quark Xpress,, FileMaker Pro, Word and Excel: those were your apps.
(Weird historical footnote: the original Mac system software could only run one application at a time — you had to quit to change to another app. But there was an exception: little utilities like the calculator, notepad, and scrapbook (clipboard storage) that you could open from the Apple menu. Those things had a special name, “desk accessories”, and didn’t exist as standard applications on disk, you had to install them into the central System file. In later versions of classic Mac OS, long after it became capable of running multiple regular applications simultaneously, Desk Accessories did become standalone applications instead.)
In modern usage, “app” to mean a “mini program” is really an abbreviation of “mobile app” which then got extended to the desktop, with the added connotation of “procured from a central software store”.
P.S. Steve Jobs was never a programmer. He was never an engineer of any kind.
-
And... the only real motive for all of this crap is IMHO to increase profits as well. The rest is just rosy bullshit to sweeten the pill.
Have you never met a crazy feminist? ;)
They aren't in it for the money. The whole movement might be funded by the usual suspects for the usual reasons, but all the worker bees are taking it seriously.
Also, Americans are completely insane and they take everything the TV tells them at face value. After all, it's been decades of "Russian TV bad, American TV good" for them. Here in the former commie block, if somebody announces a great campaign to change the world where everybody must participate, common people will joke about it (as if we haven't seen similar things before...) and at best see it as an opportunity to get free money for pretending to do something for the cause. I mean, just look how EUSSR grants get spent here, 'nuff said. Meanwhile in America, the drones actually believe all that SJ stuff and worry about being good little drones and meeting expectations. That's the difference and the reason why I stayed the hell away from that shithole like blueskull ::)
-
I don't understand the need to change "programming" to "coding".
It was required when "programs" were replaced by "apps" ;)
FYI, in the Mac world, where executables have always been officially called “applications”, the abbreviation “app” has been common since the 80s, with no negative connotations about the program’s complexity.
IOW, since the iPhone brought computing to people who shouldn't be doing it. It all started around 2010.
That's why if I ever get an opportunity to go back in time and kill one historic figure in his crib, I promise it won't be Alfred Hutler but Steve Jobs >:D
-
I don’t think we (or anyone) should be gatekeepers to computing technology.
-
That's why if I ever get an opportunity to go back in time and kill one historic figure in his crib, I promise it won't be Alfred Hutler but Steve Jobs >:D
Classic time travel paradox problem. Go back in time, take out the thing that annoyed you, then in the present there is not that thing to annoy you and so no reason to go back in time :-DD
-
I don’t think we (or anyone) should be gatekeepers to computing technology.
Maybe not, but it does not hurt to think about what is good and what is not, and at least stay away from the bad to prevent it from becoming main stream.
-
What on earth are you talking about?
-
I assumed that with gatekeeper you meant guardians of how things are done and in that capacity judge over how and what is produced.
And what I meant is that by not using applications that are crap you can try to avoid them from becoming so popular that everybody wants it and more of it. But as a single person you don't stand a chance in keeping crap from entering the world.
-
Over a quarter of a century ago, a company called MacroMind created Director (https://en.wikipedia.org/wiki/Adobe_Shockwave). In 1995 –– 27 years ago –– the company, now called Macromedia, created a Shockwave plug-in, so that applets created in Director could be run in a browser. There were hundreds, if not thousands, of CD-ROM games created in Director sold for children, both tie-ins and edutainment, for both Windows and Macs. I did some educational and commercial work with it for a few years.
As an environment, it looked very much like CodaKid does now: fully visually driven. You had a 'stage', representing the window (or screen, if run full-screen), with actors or sprites representing the visual elements; with a timeline for how the visual elements would move, and scriptlets written in Lingo (https://en.wikipedia.org/wiki/Lingo_(programming_language)) to control looping, events (mouse clicks), and even frame (timeline) changes; it was the first purely event-driven language I learned. Very intuitive, very easy to learn.
So... what is exactly new here?
As far as I can see, true learning is at best tertiary, with "do this and this will happen" -type copying without understanding the focus.
That's absolutely fine for a hobby and leisure time, but aside from being an interest trigger for some, it won't produce new software developers, just copy-paste types. (Which is not an exact description, but an emotive characterisation of the type of person who completes tasks by repeating actions without understanding why those actions lead, or should lead, to a successful outcome.)
In the Director era, you could tell how certain children show tie-in products were made by people who really weren't software developers, and the "games" easily locked up, glitched, et cetera... And consumed ridiculous amounts of processor resources –– this being the era before widespread 2D or 3D acceleration.
Some were nice, sure, but on average, it really just enabled cheaper productions by people who maybe should have done something completely different.
You know, cheaper crap for the masses.
-
Classic time travel paradox problem. Go back in time, take out the thing that annoyed you, then in the present there is not that thing to annoy you and so no reason to go back in time :-DD
That's the whole point.
I would gladly live in an alternate world where Apple's consumer garbage doesn't exist and I don't feel an urge to murder people ;D
I don’t think we (or anyone) should be gatekeepers to computing technology.
Tell this to all the arseholes who filter what software you are allowed to run on products which they try to sell as general purpose computing devices.
Americans are all liberal until it comes to OMG think of the children or OMG think of the malware, which usually translates to OMG think of the money.
-
../
In 1995 –– 27 years ago –– the company, now called Macromedia, created a Shockwave plug-in, so that applets created in Director could be run in a browser.
:puke:
-
Flash was the best thing to happen to the Internet because you could disable it.
Now they reinvented the wheel, called it HTML5, implemented it in every browser with no way of disabling it, and most of the webshits in the world rely on it for basic functionality and completely break if you try to browse them with Internet Explorer 5.0 to avoid all that flashy rubbish.
This is the progress Flash haters dreamed about :horse:
-
Americans are all liberal until it comes to OMG think of the children or OMG think of the malware, which usually translates to OMG think of the money.
This applies to many people, not just Americans. Liberal and concerned people live everywhere.
-
This applies to many people, not just Americans. Liberal and concerned people live everywhere.
It's a matter of concentration, enough of them being in one place to be able to do something about it.
The outcomes can be seen by everyone.
We are already witnessing first rats abandoning the sinking ship :P
-
Over a quarter of a century ago, a company called MacroMind created Director (https://en.wikipedia.org/wiki/Adobe_Shockwave).
Director was not bad. 1989, actually. 33 years ago.
Hypercard was 1987 and did a lot of the same things.
Logo and Smalltalk environments were even earlier.
In I think 1990 I was approached by a 14 year old kid who had created a "platform" game similar to Dark Castle (1986, Mac) or Prince of Persia (1989 Mac & MSDOS) in Hypercard. It worked (and looked great!) but was too slow, so he ported it to Supercard, which was an improvement, but not enough. What could he do? Rewrite it in THINK Pascal! I quickly made a library to use QuickDraw to composite sprites on top of a background and got him started on how to translate HyperTalk to Pascal.
I guess 40 years of experience has shown that it's a reasonably successful strategy to give kids an environment in which they can create animations and games.
However I'm not at ALL convinced that a dumbed down or low performance language is the way to drive it.
Swift seems like not a bad option. Javascript, for all its design faults, is also not bad. It's really astounding that on a modern PC you you create a fully accurate, faster than the original, emulation of an Apple ][ or Commodore 64 or even Amiga or early Mac (both 8 MHz 68000) using nothing but Javascript. In a web browser.
-
I guess 40 years of experience has shown that it's a reasonably successful strategy to give kids an environment in which they can create animations and games.
However I'm not at ALL convinced that a dumbed down or low performance language is the way to drive it.
Yep. As a creator tool, in the same vein as Arduino for example, they work. As an educational tool, I don't think they work too well.
The true problem (to be solved), in my opinion, is to find out how we can direct the learner towards a correct, functional intuitive understanding of software development in general.
The event based model in Director/Hypercard/etc. happens to be extremely intuitive in their respective environments, so much so that I'm tempted to suggest it as an initial prelude/hook for those who proceed into interactive web stuff using HTML and Javascript: the former 'steers' the way a complete newcomer sees how interactive development 'works' in just the right direction, in a way that no imperative programming tutorial can.
Of course, if the learners have any experience in programming already, the point is completely moot.
If the first programming language one is taught is an imperative one, the step into parallel processing (threads) and multiprocessing (processes) and distributed processing (using message-passing interfaces like MPI) is often difficult, because the mind is already settled into a specific 'box' that excludes those.
I do not know what works better, but I suspect a mixed approach might work best. The Unix environment is enticing in this sense, because the command line interface, the shell, itself is a full programming language; plus we habitually use other language-like tools like sed, awk and make, instead of a single integrated development environment. Something graphical will let the users get visual interactive results quickly, but they won't learn anything about data structures et cetera. A microcontroller environment would let one use really low-level languages, down to assembler, and at least grasp how things happen at the hardware level, and how we build abstractions out of them to let us think about higher-level problems.
I dunno. It is an interesting problem, but I do not see much pedagogical progress having happened in the last quarter century or so. Tools change, and people get visual results faster, but I think their understanding tends to be purely superficial.
As a tangent, do consider how much more useful it would be if we taught people how to report bugs and computer problems with actionable detail, instead of the very bare basics of programming!
-
I guess 40 years of experience has shown that it's a reasonably successful strategy to give kids an environment in which they can create animations and games.
However I'm not at ALL convinced that a dumbed down or low performance language is the way to drive it.
Yep. As a creator tool, in the same vein as Arduino for example, they work. As an educational tool, I don't think they work too well.
No, not at all like Arduino.
Arduino does the RIGHT thing, with an easy to use library to get you started but a full-strength C++ compiler that you can use to write your own high-performance data structures, algorithms, better replacements for all or part of the Arduino library, direct access to hardware registers etc.
-
I guess 40 years of experience has shown that it's a reasonably successful strategy to give kids an environment in which they can create animations and games.
However I'm not at ALL convinced that a dumbed down or low performance language is the way to drive it.
Yep. As a creator tool, in the same vein as Arduino for example, they work. As an educational tool, I don't think they work too well.
The true problem (to be solved), in my opinion, is to find out how we can direct the learner towards a correct, functional intuitive understanding of software development in general.
The event based model in Director/Hypercard/etc. happens to be extremely intuitive in their respective environments, so much so that I'm tempted to suggest it as an initial prelude/hook for those who proceed into interactive web stuff using HTML and Javascript: the former 'steers' the way a complete newcomer sees how interactive development 'works' in just the right direction, in a way that no imperative programming tutorial can.
Of course, if the learners have any experience in programming already, the point is completely moot.
If the first programming language one is taught is an imperative one, the step into parallel processing (threads) and multiprocessing (processes) and distributed processing (using message-passing interfaces like MPI) is often difficult, because the mind is already settled into a specific 'box' that excludes those.
I do not know what works better, but I suspect a mixed approach might work best. The Unix environment is enticing in this sense, because the command line interface, the shell, itself is a full programming language; plus we habitually use other language-like tools like sed, awk and make, instead of a single integrated development environment. Something graphical will let the users get visual interactive results quickly, but they won't learn anything about data structures et cetera. A microcontroller environment would let one use really low-level languages, down to assembler, and at least grasp how things happen at the hardware level, and how we build abstractions out of them to let us think about higher-level problems.
I dunno. It is an interesting problem, but I do not see much pedagogical progress having happened in the last quarter century or so. Tools change, and people get visual results faster, but I think their understanding tends to be purely superficial.
You have to ask yourself: do you need to know how a Lego brick is made in order to build something using Lego bricks? IMHO the answer is no.
Software development combines two skills:
1) Convert a problem into a design (flow charts, data flow, interaction, etc) => system design
2) Convert the design into a program using a programming language and the associated libraries / framework => programming
-
I agree with Nominal Animal here. I don't think those tools are good for educating people properly. (This would include Python as well, in the same vein for similar reasons.)
Are they useful? Certainly. Do they expose more people to software development? Certainly. Do they expose them to sane concepts and instill sane background knowledge? Not so much.
So in the end it's pretty much all in what you consider education. Your opinion may vary. The end result, though, in terms of education is probably not going to be influenced by anyone's opinion. Reality is a bitch.
It's a bit like exposing people to Excel and teaching them a few formula tricks (which definitely could help them achieve some stuff) and assuming they are learning mathematics. Sure.
-
Software development combines two skills:
1) Convert a problem into a design (flow charts, data flow, interaction, etc) => system design
2) Convert the design into a program using a programming language and the associated libraries / framework => programming
For me there is a third option were you wing it. Without doing step 1, just start programming on an experimental basis, just because there are so many unknowns that making a proper design is sheer impossible or to time consuming. It might require multiple iterations to get to an end result, but a lot of unknowns can be found this way.
This works for me quite well and have used it in many occasion to produce good result.
-
to find out how we can direct the learner towards a correct, functional intuitive understanding of software development in general.
I think if you're doing that to beginners you're going to have lots of spare places in your school. The trick is surely to give them something simple and easy, but capable, to get them hooked, and then you hit them with the boring stuff.
For kids, that drag'n'drop thing looks great. Fast results, actual programming, but it's not tedious until you really get stuck in. For older 'kids' something like Dephi would have been good: again it is fast to do stuff and anything complicated would likely come unstuck due to not separating logic from GUI objects (which, actually, is a great learning experience). Once someone is running that stuff off you're fairly certain they are enjoying things and you can teach them 'proper' programming, but hassle them too early and they might be scared off for good.
I'm sure that many of us got into this lark through programming home computers in BASIC, then progressing to assembler or whatever after finding out BASIC isn't actually that good for serious stuff. But if we'd been thrown into assembler to start with, many of us wouldn't be here now.
-
I'm sure that many of us got into this lark through programming home computers in BASIC, then progressing to assembler or whatever after finding out BASIC isn't actually that good for serious stuff. But if we'd been thrown into assembler to start with, many of us wouldn't be here now.
When I first got my hands on an Apple ][ as a 17/18 year old in late 1980 the length of time from starting with BASIC to saying "this sucks" and teaching myself 6502 assembly language (in fact machine code because I didn't have an assembler) by reading the monitor ROM listing in the back of the manual was ... maybe two days?
The first three useful things I did were:
- machine code to call the "RWTS" Apple DOS function to read or write a specified track and sector on the floppy disk to a memory buffer. BASIC code I wrote then displayed it on the screen in hex and let you edit it and write it back. The BASIC code also understood navigating and displaying the directory structure using the RWTS interface. This was probably only a dozen or two machine code instructions to marshal parameters. Easy win. The local Apple dealer loved this because there weren't yet any commercial sector editor programs (or at least none that had made their way to provincial New Zealand)
- a replacement for the keyboard input hook that while a key had not been pressed checked a parallel printer port to see if the printer could accept more characters, and if so sent it more from a buffer. When the buffer was empty it used RWTS to read more data from a text file on disk. i.e. a print spooler. The checking the KB&printer part was probably only 20 instructions, plus driving RWTS and translating directory navigation code (to find and step through a named file) from BASIC to machine code. My old school loved this. (I did it in the summer between school and university, on the school's first computer)
- a compaction routine for BASIC string variables that was O(N+SZ) instead of O(N^2) like the one in Applesoft (Microsoft) BASIC. If you has a BASIC array containing enough (shortish) strings to fill RAM then compacting them locked up the machine for IIRC several minutes. The better algorithm reduced it to a second or so. This was pretty complex. I think several hundred bytes of code. Unfortunately there was no way to replace the built in string compaction function, so the BASIC program just had to call the custom one often enough that the built in one was never triggered. Also heavily used at the school by teachers who were writing student/course management programs in BASIC.
I did already own a TI 57 [1] (8 memories, 50 program steps, NZ$117, lost memory contents when you turned it off) and had some hands-on exposure to TI 58/58C/59 and HP 67/97 beforehand, and also to articles with SC/MP, 2650, 6800, 8080, z80 and probably 6502 code in Electronics Australia / Electronics Today International / BYTE.
So I guess I can't say what would have happened if I'd been 5 or 10 years younger and never done any reading.
[1] when I took a night class in celestial navigation in 6th form (we had to buy actual sextants, though cheap plastic ones) I'd figured out by myself the formulas for distance and initial great circle bearing from one lat/long point to another, and also for distance from the observer to the surface point directly under the sun / moon / star (subsolar, sublunar, substellar point) given the (corrected) elevation above the horizon. This saved having a huge book (1000+ pages) full of tables, though you still needed another one giving the subsolar etc point at particular date/time, and tables for correcting the apparent elevation for atmospheric refraction.
The TI 57's capacity was sufficient to "can" formulas like that and repeatedly take inputs and give results. Or to do things such as simple numeric integration or differentiation.
-
Let me reiterate:
I guess 40 years of experience has shown that it's a reasonably successful strategy to give kids an environment in which they can create animations and games.
However I'm not at ALL convinced that a dumbed down or low performance language is the way to drive it.
Yep. As a creator tool, in the same vein as Arduino for example, they work. As an educational tool, I don't think they work too well.
You have to ask yourself: do you need to know how a Lego brick is made in order to build something using Lego bricks? IMHO the answer is no.
I know I am overly verbose, and (plural) you don't like reading my posts, but this is getting ridiculous.
Here, my point is that if you want the learners to gain an intuitive understanding of the basics of say electronic circuits (threads, abstract data structures, parallel and distributed processing, algorithm development and implementation), you wouldn't be using Lego bricks.
Lego bricks are absolutely fine –– no, wonderful! –– for structures, and Technics for mechanics, even robots! But not so much for electronic circuits (using circuits as an analog here).
I even mentioned using the Director/Hypercard -like environments as a hook into event-based programming, especially web stuff and user interfaces.
to find out how we can direct the learner towards a correct, functional intuitive understanding of software development in general.
I think if you're doing that to beginners you're going to have lots of spare places in your school. The trick is surely to give them something simple and easy, but capable, to get them hooked, and then you hit them with the boring stuff.
I used learner to indicate something that happens after you've already hooked them.
And I did explicitly say 'I dunno.' which means I do not know, and consider the best solutions undiscovered thus far, and have most issue with the fact that basically no development has been done in the pedagogical side in the last quarter century, as far as I can see. "Teachers" are just using whatever methods they believe work best, without any research or verifiable basis for that belief. It is the educational equivalent of keeping to bloodletting and humors in medicine because not too many "important" people are dying, instead of actually developing medical science. That, too, was a perfectly good business model back in the day.
While I love the idea of learning being fun, in the sense of always getting immediate visual/tactile/observable results (instead of just text on the display), I also know that engendering misconceptions always means that when getting deeper into the subject, they need to unlearn the misconceptions first. This is unnecessary effort, and is frustrating as all hell. I see it all the time, from misconceptions about address spaces ("I have the same pointer in both of my processes, but when I dereference them, I see different values?" "Why isn't my data section immediately after my code section?"), to entire programming paradigms like how memory bandwidth and caches are often the key bottleneck on desktop and server machines instead of trivial arithmetic or binary operations on the data. Not to mention when trying to teach a single-OS/environment programmer to create portable code... you know what I mean.
This is not just programming or software development problem, it is an educational problem. In physics, kids are still taught that electrons orbit atomic nuclei like planets orbit a star. They don't, and have great difficulties understanding quantum wavefunctions and delocalization later on. Yet, the true explanation (that electrons are delocalized, like a cloud, with a specific density distribution, with these distributions having physical properties that are analogous to orbits –– orbitals ––, spin direction, angular momentum, and so on) isn't that much more complex, and with a bit of help from child psychologists with lots of experience, can be taught to any schoolkid of average intelligence or better. The end result? Well, as adults, they hear all this woo-woo about quantum physics and spooky action at a distance, and decide that either they were lied to as kids, or this newfangled quantum stuff is bunk, and therefore the Earth is flat. Only the smartest understand why simplifications and approximations are useful, and how they work, and are not caught by that.
So yeah, these fast and easy development environments are very nice entertainment and making even impressive-looking stuff with little effort, but they do not work as an educational tool. There is nothing there that pushes anyone to create anything better, just more of the same, but cheaper and with less effort. I do not believe that direction is sustainable for the field of software development as a whole; we need better educational tools.
What those better tools are, I do not know. I have some ideas to start with, and some beliefs, but that's about it.
-
Education, a difficult subject and looking at some numbers from the Netherlands, about how many people have problems reading, writing or calculus, you can see it is failing. Even the teachers seem to be not on par.
But a better system would cost a lot of money, because the classroom education form of teaching where everybody is doused with the same material at the same speed does not work that well. It would yield far better result when things are taught on a somewhat individual basis.
With the current system, if it is still the same as when I was young, keeping someone back just because they fail at one or two or even more subjects, but excel in others causes problems. It would be better if one could do every subject at its own needed pace, and not judge if a couple of subjects are never fully learned, because they might have no big impact on their further life. Thinks like history or geography for example.
But I can see that implementing such a setup is near impossible and very expensive.
-
This is not just programming or software development problem, it is an educational problem. In physics, kids are still taught that electrons orbit atomic nuclei like planets orbit a star. They don't, and have great difficulties understanding quantum wavefunctions and delocalization later on. Yet, the true explanation (that electrons are delocalized, like a cloud, with a specific density distribution, with these distributions having physical properties that are analogous to orbits –– orbitals ––, spin direction, angular momentum, and so on) isn't that much more complex, and with a bit of help from child psychologists with lots of experience, can be taught to any schoolkid of average intelligence or better. The end result? Well, as adults, they hear all this woo-woo about quantum physics and spooky action at a distance, and decide that either they were lied to as kids, or this newfangled quantum stuff is bunk, and therefore the Earth is flat. Only the smartest understand why simplifications and approximations are useful, and how they work, and are not caught by that.
I don’t think that’s true at all. Simplifications and abstractions are a necessary part of learning, because it’s impossible to learn all at once every detail needed to fully understand a complex system. So you abstract away parts of it and teach the big concepts, and then later go back and little by little replace each abstraction with a more complex one until you’ve gotten to the details.
The rise of anti-intellectualism has precious little to do with that. People don’t become flat earthers because they weren’t taught quantum physics in elementary school. There are far more complex issues at play, and education is just one (small) part of it.
So yeah, these fast and easy development environments are very nice entertainment and making even impressive-looking stuff with little effort, but they do not work as an educational tool. There is nothing there that pushes anyone to create anything better, just more of the same, but cheaper and with less effort. I do not believe that direction is sustainable for the field of software development as a whole; we need better educational tools.
Fact is, most people aren’t innately gifted programmers, and I don’t really think that talent can be taught. (I remember reading how gifted programmers at a major software company were something like 5-10 times as productive as their average ones. And that was a company that was already selective in hiring, so “average” there was already well above average for the industry.) Nonetheless, many people want or need to program anyway, both because of their own motivations, but also because the software industry needs far more programming services than the small number of truly gifted ones could ever supply. So like it or not, we have to train lots of fundamentally ungifted people as programmers, in the hopes that most will learn enough to at least be competent. It doesn’t matter how good the educational tool is, it won’t make gifted programmers out of them. Going back to more difficult environments isn’t going to improve the number of skilled programmers, it’ll only reduce the number of programmers overall by causing more people to drop out. Unfortunately, I don’t think those would necessarily be the ones we want to drop out, because many people who aren’t that smart are very experienced in simply working hard to get to the goal, while some of the smarter people who got into it because of at least some inkling of curiosity in it will just get discouraged and leave.
That’s why I am so in favor of Arduino: the instant gratification “hook” that keeps you interested in learning more. They struck just the right balance of easy, reliable first steps, but leaving enough complexity and unpolished areas that you quickly have to start learning more “serious” programming, MCU, and electronics skills.
Will some hobbyists never progress behind the cut-and-paste approach? Sure. But they’re not working as programmers.
-
With the current system, if it is still the same as when I was young, keeping someone back just because they fail at one or two or even more subjects, but excel in others causes problems.
When I was 9, in 1972, I was put back a year (for all subjects) because the TEACHER did not have a clue about the math material she was supposed to be teaching us -- fractions, GCD & LCM, number bases, Venn diagrams -- and could not stand being corrected on it.
I changed schools the next year and got a great teacher who obtained assignments from the local high school for me to do. Sadly, that teacher and his wife were given a tourist flight to Antartica as a retirement gift and died when the plane crashed into Mt Erebus in November 1979.
-
This is not just programming or software development problem, it is an educational problem. In physics, kids are still taught that electrons orbit atomic nuclei like planets orbit a star. They don't, and have great difficulties understanding quantum wavefunctions and delocalization later on. Yet, the true explanation (that electrons are delocalized, like a cloud, with a specific density distribution, with these distributions having physical properties that are analogous to orbits –– orbitals ––, spin direction, angular momentum, and so on) isn't that much more complex, and with a bit of help from child psychologists with lots of experience, can be taught to any schoolkid of average intelligence or better. The end result? Well, as adults, they hear all this woo-woo about quantum physics and spooky action at a distance, and decide that either they were lied to as kids, or this newfangled quantum stuff is bunk, and therefore the Earth is flat. Only the smartest understand why simplifications and approximations are useful, and how they work, and are not caught by that.
I don’t think that’s true at all. Simplifications and abstractions are a necessary part of learning, because it’s impossible to learn all at once every detail needed to fully understand a complex system. So you abstract away parts of it and teach the big concepts, and then later go back and little by little replace each abstraction with a more complex one until you’ve gotten to the details.
I'm not talking about going into small details, I'm talking about approaches that yield an intuitively correct picture.
Simplifications and abstractions work, if the learner understands and acknowledges they are a simplification and abstraction. In the visual programming environments, there is none of that; quite the contrary, many try hard to show that everything that is possible, is possible in that environment.
In software development, you need to understand the underlying approach, before you can reliably create new things. Without understanding, people will just copy and repeat already existing stuff, without creating anything new.
The rise of anti-intellectualism has precious little to do with that. People don’t become flat earthers because they weren’t taught quantum physics in elementary school. There are far more complex issues at play, and education is just one (small) part of it.
That – teaching quantum physics in elementary school – wasn't what I suggested. The problem occurs when in elementary school the teacher states that the approximate model is fact, when it isn't. In software development, we have multiple paradigms (from imperative to event-based to functional programming) and multiple levels of complexity, and unless the learner understands that early on, they will be later locked to the unlearn-before-you-can-learn-new-stuff antipattern.
Furthermore, I do believe that anti-intellectualism –– or rather antirationalism –– is, in fact, learned in or during elementary school.
One big cause is teachers who pose themselves as the gatekeepers of facts and knowledge, instead of tutors and mentors in learning.
So yeah, these fast and easy development environments are very nice entertainment and making even impressive-looking stuff with little effort, but they do not work as an educational tool. There is nothing there that pushes anyone to create anything better, just more of the same, but cheaper and with less effort. I do not believe that direction is sustainable for the field of software development as a whole; we need better educational tools.
Fact is, most people aren’t innately gifted programmers, and I don’t really think that talent can be taught.
I agree, but that has nothing to do with what I wrote.
These environments are perfectly okay for the purpose of creating more of the same, yes. There is nothing wrong in using them, even using them to create commercial projects.
The point is, these environments generate an intuitive picture that is completely incorrect, and hampers understanding and learning when moving outside the environment. They do not help with learning anything outside that particular environment; quite contrary, they actively try to keep their users within that environment.
That’s why I am so in favor of Arduino: the instant gratification “hook” that keeps you interested in learning more. They struck just the right balance of easy, reliable first steps, but leaving enough complexity and unpolished areas that you quickly have to start learning more “serious” programming, MCU, and electronics skills.
Sure, I like Arduino too. But, consider what happens at the point when a learner wants to step from Arduino into proper freestanding C/C++ environment. (Including why I used C/C++, and not just C++? Because of avr-libc/newlibc, depending on the microcontroller. There is most of standard C library available, but only a tiny subset of C++.)
What I suggest, in practice, is to start with these environments, but explicitly describe their limitations and approaches. For example, that Arduino is a freestanding C/C++ environment (meaning only a subset of the C++ features and C standard library are available), and that it handles several things (like declarations) automatically for you. No details, but a mention, so that if they are some day ready to break out, they remember the initial mention, and have a working approach, instead of having to tear down their earlier understanding or assumptions before they can rebuild new ones in their place.
Really, it is the same with elementary physics. It is perfectly okay to use the approximation, and start with the approximations and simplified models. You do not teach quantum physics to elementary schoolkids; but you do not claim that Newtonian mechanics are "incontrovertible facts that exactly describe the universe", either. It suffices to mention that when one gets to really small scales, quantum phenomena are observed; and at very high masses, energies, and/or velocities, relativistic phenomena are observed. It suffices to list the terms without going into any details, as the important bit is to have the correct intuitive understanding: Newtonian physics describe human-scale stuff extremely precisely, but there is more when you change scales.
-
Let me give you a practical example: web-based software development.
To ensure the learner has the correct intuitive understanding, we first sketch the core concepts, including
- client or browser: The application on the local device that renders HTML, CSS, images and other media, and runs associated JavaScript, for us humans to view and enjoy
- server and service (and also daemon): A network-connected computer that provides HTML, CSS, images and other media, including JavaScript files, for clients or browsers to render
- source code, JavaScript, HTML, CSS, SVG
- JPEG/EXIF, GIF, PNG
- HTTP, HTTPS, TLS, DNS, certificates and keys
Initially, a detailed definition isn't needed; the key is the initial approach, via e.g. analogies.
Let's say the above takes a full lesson (30-45 minutes), because actual examples (and exercises) are shown to illustrate the terms.
Next lesson can then start with a simple example, showing the difference between opening the example locally or from a server, and how browser built-in and add-on developer tools are used. There is an entire tree of approaches that branches from here.
Now, consider what effect does the introduction of the terms have on the learner. It should somewhat direct their preconceptions as to what kind of modules/areas are involved, even if in only very vague terms. They know that the browser interacts with one or more servers, and the very basics of the connection security. They understand that HTML and CSS and SVG are descriptive languages, whereas JavaScript is an object-oriented programming language. Every direction they start branching from starting at the second lesson, has already been hinted about, and they have a vague idea how everything slots together.
Now, consider what happens, when that initial sketching-the-terms introduction is omitted. The learners' initial conceptions are formed willy-nilly, most likely based on their past net browsing experiences, and will vary a lot from person to person. Some may believe that what you see in the browser, is somehow completely defined by a server; and even the concept of a "server" can vary from just an address to a commercial company. For every new lesson or topic, the learners come with wildly different preconceptions, and often you need a teacher/guide/mentor to understand and deconstruct those preconceptions first before they can even help the learner understand.
Obviously, the sketching-concepts-initially only works if the definitions/descriptions are simple, and are designed to evoke the correct mental image, even if very superficial. Their purpose is not to be a dictionary lookup for the terms, but to direct the understanding of the student. (It is also important that each has interesting examples, because a secondary purpose is to evoke interest in the student too. After all, the teacher/guide/mentor is not there to provide information or knowledge, but to help guide the process of learning.)
This means that while something like Arduino makes for a very good part of a course or set of courses in software development, you need to at least show where the egresses outside that environment are; plus beforehand define the environment, so that the learners do not mistake it for the entire universe.
This also ties directly in, analogously, to why I do not believe Youtube videos alone are sufficient for learning (because interspersing the egresses outside in the video itself makes the video ineffective and annoying to watch). They can be wonderful, crucial parts, but a playlist does not a very good course make, in my opinion. (I consider tutorials similar to workshops, where someone shows how the task or part of it is actually done.)
If you permit me to circle back to my original complaint, it is that while we have these wonderful technological tools, we have made basically no progress on the pedagogical front in the last quarter century at least. There are good and bad courses out there, lots and LOTS of them, but very little additional knowledge on what content and approach is needed to achieve a specific educational goal.
Because of this, the next generation of programmers does not actually stand on our shoulders. They stand on the same shoulders we stand on. I'd like to fix this, if possible.
-
You do not teach quantum physics to elementary schoolkids; but you do not claim that Newtonian mechanics are "incontrovertible facts that exactly describe the universe", either
So far as I can recall, that's what I was taught. Also, electricity goes from positive to negative. And many other similar 'good enough' stuff.
If/when you need to know that woods aren't actually made of trees, you'll be able to reconcile that 'trees' are actually badgers stacked on end or something. But for most people that's just noise that contributes to confusion. Similarly, speed of light is 186,000 miles per second, except mumble mumble... just muddies things.
-
In this "review" I miss the Scratch programming language.
https://scratch.mit.edu/projects/editor/ (https://scratch.mit.edu/projects/editor/)
It is currently ranked 22nd most popular language in the Tiobe index (https://www.tiobe.com/tiobe-index/).
It is developed for educational purposes by the MIT Media Lab's Kindergarten Group (https://www.media.mit.edu/groups/lifelong-kindergarten/overview/) (founded by MIT professor Nicholas Negroponte).
Edit:
It is based on Blockly and JavaScript inside, like App Inventor 2 and Code.org
https://en.wikipedia.org/wiki/Blockly (https://en.wikipedia.org/wiki/Blockly)
There are thousands of projects that you can look at and experiment with by modifying them:
https://scratch.mit.edu/explore/projects/all/popular (https://scratch.mit.edu/explore/projects/all/popular)
Golf example: https://scratch.mit.edu/projects/690300423/editor/ (https://scratch.mit.edu/projects/690300423/editor/)
-
One way to sort out languages: Can a full scale OS, say like Linux, be written in the language and will it compete in terms of performance with existing OSes, again, say Linux.
You really can't compare SQL with Fortran as languages and get meaningful results. They work in entirely different problem domains. Orbital dynamics are fairly easy in Fortran, less so in SQL. I suppose Fortran could create SQL statements with a lot of kicking and screaming but it wouldn't be pretty. I have a suspicion that the Fortran rating is underrepresented. The language is still the one of choice for fast running scientific applications. You can bet that the Artemis 1 trajectory wasn't computed in SQL. I don't know what they actually used but I'll bet it's done in Fortran from code written 50 years ago during the Apollo program.
Interesting side note: Fortran natively supports parallel computing in the language itself. Not some tacked on abomination. There a reason Nvidia offers up both a C++ and Fortran compiler for CUDA programming. In addition to support for Python if you aren't in a hurry.
Historical note: The CP/M PL/I compiler was originally written in Fortran. I don't think that was the best choice but it may have been the only choice for the VAX machine in use at the time. I remember doing business applications in Fortran on an IBM 1130. Fortunately, IBM provided the Commercial Subroutine Package to give me a step up. Even bigger deal: The CDC 6400 had a 60 bit word holding 10 chars and no way to extract other than shifting them out. Later machines included a Compare/Move unit of hardware to address the problem. Running COBOL on a 6400 was slow as was running Fortran on an IBM 360. Different problem domains...
I wouldn't take the TIOBE Index too seriously. It could well turn out that a lot of Fortran coding can't be discussed.
-
Problem with TIOBE is they don't/can't sort results in categories, so you just know how much a given language appears on blogs/online discussions/etc relative to others, but you don't know what kind of topics it is.
So yes, a given language will appear in the top 10 on TIOBE if it's talked about a lot. That "probably" means that it's "popular". But the reasons why it's being talked about so much are unknown. The main reason may be because it's so crappy and ill-defined that it may require a lot of support. You will probably argue that it's still a sign that it's popular (you won't get massive talking about some language that nobody uses), but comparing languages this way is still flawed.
-
Historical note: The CP/M PL/I compiler was originally written in Fortran. I don't think that was the best choice but it may have been the only choice for the VAX machine in use at the time.
FORTRAN is very good for programming numerical algorithms but not so good for implementing compilers. An initial attempt was made in 1969 to implement the Pascal compiler in FORTRAN 66. However, Prof Wirth reported that it was unsuccessful due to FORTRAN 66's inadequacy to express complex data structures:
"Good Ideas, Through the Looking Glass", IEEE Computer, January 2006, pp. 28-39, vol. 39 (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.851.9552&rep=rep1&type=pdf)
-
Historical note: The CP/M PL/I compiler was originally written in Fortran. I don't think that was the best choice but it may have been the only choice for the VAX machine in use at the time.
FORTRAN is very good for programming numerical algorithms but not so good for implementing compilers. An initial attempt was made in 1969 to implement the Pascal compiler in FORTRAN 66. However, Prof Wirth reported that it was unsuccessful due to FORTRAN 66's inadequacy to express complex data structures:
I'm afraid that's a cop-out by Herr Wirth.
It has often been said that you can write FORTRAN IV (i.e. bad) code in any language, but you can equally write LISP in any language.
Obviously, using GOTO to implement if/then/else and while and repeat loops is a little ugly, but it's purely mechanical. And the benefit of sticking to structured control flow in your code is not in using pretty "repeat ... until ..." syntax but in making your code easier to reason about, which still works if you use GOTO purely in a structured way.
Recursion is the trickier nut to crack, especially mutually-recursive functions. It's easy enough to declare arrays of various types (INTEGER*4, REAL*4, REAL*8) that can be used as stacks to push local static variables on to at the start of the function and restore them from at the end. The return address is harder. Self-recursive functions can be turned into loops, with a case statement and gotos on "return" if the function is multiply self-recursive (e.g. quicksort, or Fibbonacci). If you have the ability to call external utility functions written in assembly language then you can use non-portable compiler-dependent tricks to save/restore return addresses.
Worst comes to worst, you can always simply allocate a large array as "memory" and write a loop with a case statement (or tree of IFs) to interpret programs written in some bytecode. That's how things like Python work to this day.
Wirth of course did recognise the benefits of bytecode for initial bootstrapping and portability by 1975 and implemented a Pascal compiler using the technique, but his original 1969 Pascal compiler didn't use it.
BCPL had O-code as early as 1966, designed for either easy interpretation or further compilation to native code.
On those early computers bytecode was a lot more compact than native machine code (and this extended into the 6502 and z80 microcomputer era), but this largely disappeared with the M6809, 8086, and M68000. Modern RISC ISAs such as ARMv7 and RISC-V are actually more compact than bytecodes such as JVM or WebASM.
-
Historical note: The CP/M PL/I compiler was originally written in Fortran. I don't think that was the best choice but it may have been the only choice for the VAX machine in use at the time.
FORTRAN is very good for programming numerical algorithms but not so good for implementing compilers. An initial attempt was made in 1969 to implement the Pascal compiler in FORTRAN 66. However, Prof Wirth reported that it was unsuccessful due to FORTRAN 66's inadequacy to express complex data structures:
Obviously, using GOTO to implement if/then/else and while and repeat loops is a little ugly, but it's purely mechanical. And the benefit of sticking to structured control flow in your code is not in using pretty "repeat ... until ..." syntax but in making your code easier to reason about, which still works if you use GOTO purely in a structured way.
It's not about GOTO. As I said, it was due to FORTRAN 66's inadequacy to express complex data structures:
Because Fortran did not feature pointers and records, we had to squeeze symbol tables into the unnatural form of arrays.
-
It's not about GOTO. As I said, it was due to FORTRAN 66's inadequacy to express complex data structures:
Because Fortran did not feature pointers and records, we had to squeeze symbol tables into the unnatural form of arrays.
Except it is absolutely doable to express pointers as array indexes and arrays of records as parallel arrays, one for each field. It's not even all that inconvenient, and is a purely mechanical transformation.
If you read the article you will see that the problem was not that they had difficulty in implementing a Pascal compiler in FORTRAN -- they did it, taking about a year. The problem was that it wasn't worth trying to hand translate the compiler written in FORTRAN into Pascal for further development of the language, it was better to start a new compiler afresh in Pascal using Pascal features instead of converting the FORTRAN hacks to Pascal.
-
Historical note: The CP/M PL/I compiler was originally written in Fortran. I don't think that was the best choice but it may have been the only choice for the VAX machine in use at the time.
FORTRAN is very good for programming numerical algorithms but not so good for implementing compilers. An initial attempt was made in 1969 to implement the Pascal compiler in FORTRAN 66. However, Prof Wirth reported that it was unsuccessful due to FORTRAN 66's inadequacy to express complex data structures:
"Good Ideas, Through the Looking Glass", IEEE Computer, January 2006, pp. 28-39, vol. 39 (https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.851.9552&rep=rep1&type=pdf)
In Niklaus Wirth's "Data Structures + Algorithms = Programs" book there is a little Pascal compiler project - PL/0. Seven pages of Pascal, 54 pages of Fortran by the time I got it working (I may be off a little on remembering the page count but the ratio is about right). There's nothing simple about structures in FORTRAN.
But the code for BLAS is still in use for Machine Learning.
-
I think the big improvement for FORTRAN is when I started indenting code. I hadn't seen anything except left margin at column 7 in any examples of the time. A consistent left margin makes code darn hard to follow. Particularly for nested DO loops.
Here's the Tektronix Plot 10 library code:
https://github.com/hansake/Tektronix_Plot_10_graphics/blob/master/plot10/plot10.ftn
It gets an 'A' for consistency.
-
I don't know about modern FORTRAN (haven't looked at it in ages), but surely old FORTRAN would have been a mess to implement a compiler. Of course this was possible. Heck any Turing-complete language allows you to implement a compiler. But would it be a nice experience? Probably not. ;D
-
It is actually possible to implement an 8080 assembler in PL/I and have the code look exactly like FORTRAN. Or so sayeth my grad school advisor.
It was stilll prettier than the tiny Algol compiler I had to impement in Data General BASIC.
I don't know why I reminisce about the old days, things are so much better today!
Working remote with a 110 baud acoustic coupler wasn't all that productive either.
-
I don't know about modern FORTRAN (haven't looked at it in ages), but surely old FORTRAN would have been a mess to implement a compiler. Of course this was possible. Heck any Turing-complete language allows you to implement a compiler. But would it be a nice experience? Probably not. ;D
"Nice" is always relative to alternatives. And given that Pascal and C didn't exist at the time ... FORTRAN is better than assembly language.
I do wonder why Algol 60 wasn't available in 1969. Or, of course, Wirth's own Algol W, from 1966.
-
I don't know about modern FORTRAN (haven't looked at it in ages), but surely old FORTRAN would have been a mess to implement a compiler. Of course this was possible. Heck any Turing-complete language allows you to implement a compiler. But would it be a nice experience? Probably not. ;D
"Nice" is always relative to alternatives. And given that Pascal and C didn't exist at the time ... FORTRAN is better than assembly language.
I do wonder why Algol 60 wasn't available in 1969. Or, of course, Wirth's own Algol W, from 1966.
Alsol was an elegant language that never seemed to catch on. Google presents various reasons, I don't know if I buy them. Algol had the same deficiencies that the original Pascal P4 had in terms of limited IO capability. UCSD had to wrap a lot of code around the P4 compiler (I think that's the version that was used) to build even a rudimentary OS. But, damn, Pascal just looks good on a page. It's just pretty! I was shocked when I moved from Pascal to C and couldn't have nested functions. What kind of language doesn't support recursive nested functions?
Having the nesting allows code to be written straight from Wirth's syntax diagrams or the BNF description.
PL/I was another language that really never caught on. It was a DEBE language (Does Everything But Eat) and I could have grown to like it. I do have the Digital Research incantation for CP/M but I got it about the time I was transitioning to the PC and leaving CP/M behind (mostly, I still have several CP/M machines, the best is based on the eZ80 50 MHz chip).
-
Lately we are hearing a lot about no-code development platforms that allow many more people to program without having specific knowledge of programming languages.
https://en.wikipedia.org/wiki/No-code_development_platform
https://en.wikipedia.org/wiki/Low-code_development_platform
-
Lately we are hearing a lot about no-code development platforms that allow many more people to program without having specific knowledge of programming languages.
https://en.wikipedia.org/wiki/No-code_development_platform
https://en.wikipedia.org/wiki/Low-code_development_platform
All fun until you find you want to go beyond the examples in the tute.
-
Alsol was an elegant language that never seemed to catch on. Google presents various reasons, I don't know if I buy them. Algol had the same deficiencies that the original Pascal P4 had in terms of limited IO capability.
As opposed to languages such as C, C++, Java which have absolutely zero (0) I/O capability in the language?
They instead have sufficiently powerful general-purpose features in the language to allow ANYONE to build reasonably usable and convenient I/O capability as libraries -- and provide a standard library with some, but that's not the LANGUAGE.
I was shocked when I moved from Pascal to C and couldn't have nested functions. What kind of language doesn't support recursive nested functions?
C's position is defensible, and especially C++'s with objects.
I actually find the Pascal family languages very frustrating because while you can call pass nested functions repeatedly from different places (ugh .. stealth globals .. ugly), or pass them to functions such as sort(), you can't return the nested functions or store them in globals / data structures for later use after the enclosing function returns.
PL/I was another language that really never caught on. It was a DEBE language (Does Everything But Eat) and I could have grown to like it. I do have the Digital Research incantation for CP/M but I got it about the time I was transitioning to the PC and leaving CP/M behind (mostly, I still have several CP/M machines, the best is based on the eZ80 50 MHz chip).
In my first job after university in 1985 I was hired as an in-house programmer at a company that had a Data General MV10000 super-mini but they had been using only commercial software and didn't already have any other programmers. My first task was to decide which $50,000 compiler they should buy from DG: FORTRAN, COBOL, or PL/I. I spent a few days in DG's Wellington office trying them out -- and also how well they interacted with DG/SQL -- and decided PL/I was the obvious choice.
If you squinted at it the right way, you could pretend it was Pascal or C. It has decent arrays, structs, pointers with malloc/free kind of functionality, bitstrings with the usual boolean operators, nested recursive functions.
-
What, exactly, should the next generation of programmers be able to do?
What is the worst direction the education of new programmers can take?
-
What, exactly, should the next generation of programmers be able to do?
What is the worst direction the education of new programmers can take?
A few difficult question.
We need *someone* who can design CPUs and instruction sets, program in assembly language, write compilers and interrupt handlers. But maybe we don't need all that many.
Even today (and for the last decade or more) the vast majority of programmers are working in Javascript on web sites or Java or C# in businesses, mostly writing glue code to make one baroque API talk to another baroque API.
-
Perhaps stratification is an answer. First thing, then would be to find new names for the different types of programmers.
If we called everybody working on a construction site an engineer, it wouldn't work; so why should we call everybody working on software programmers?
-
If we called everybody working on a construction site an engineer, it wouldn't work; so why should we call everybody working on software programmers?
'Programmer' is surely equivalent to 'labourer', not 'engineer'.
-
If we called everybody working on a construction site an engineer, it wouldn't work; so why should we call everybody working on software programmers?
'Programmer' is surely equivalent to 'labourer', not 'engineer'.
Even the BLS (Bureau of Labor Statistics) defines 'programmer' as somewhat inferior to software developer.
https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm (https://www.bls.gov/ooh/computer-and-information-technology/computer-programmers.htm)
https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm (https://www.bls.gov/ooh/computer-and-information-technology/software-developers.htm)
Note that in either case, a bachelor's degree is usually required.
If you want to know where the money is, drill down by occupation.
-
If we called everybody working on a construction site an engineer, it wouldn't work; so why should we call everybody working on software programmers?
'Programmer' is surely equivalent to 'labourer', not 'engineer'.
Then what is "coder"?
-
Well, you get different labourers: brickie, chippie, sparks, etc. Coder would be the wheelbarrow pusher, I reckon.
-
I do wonder why Algol 60 wasn't available in 1969.
It was available wasn't it? A summary of the various implementations is here:
https://www.softwarepreservation.org/projects/ALGOL/algol60impl (https://www.softwarepreservation.org/projects/ALGOL/algol60impl)
I used an Elliot 803 in the 60's but AFAIR we were using the FORTRAN compiler and the assembler, SIR at that time. I used Algol 60 on an ICL 1906 but that wasn't until the early 70's.
-
I do wonder why Algol 60 wasn't available in 1969.
It was available wasn't it?
I would have thought so. And yet Wirth used Fortran not Algol to bootstrap the first Pascal.
-
What, exactly, should the next generation of programmers be able to do?
We need *someone* who can design CPUs and instruction sets, program in assembly language, write compilers and interrupt handlers. But maybe we don't need all that many.
Those programs are designed & written by Electrical Engineering graduates. Or Physiscs, like Dennis Ritchie
-
And yet Wirth used Fortran not Algol to bootstrap the first Pascal.
The reason for this is given in Wirth’s “Good Ideas” article:
…The tools available for writing programs were assembler code, Fortran, and an Algol compiler. The Algol compiler was so poorly implemented we dared not rely on it, and working with assembler code was considered dishonorable. There remained only Fortran. Hence, our naïve plan was to use Fortran…
-
What, exactly, should the next generation of programmers be able to do?
We need *someone* who can design CPUs and instruction sets, program in assembly language, write compilers and interrupt handlers. But maybe we don't need all that many.
Those programs are designed & written by Electrical Engineering graduates. Or Physiscs, like Dennis Ritchie
I do all that stuff and I have a humble BSc in Computer Science.
-
And yet Wirth used Fortran not Algol to bootstrap the first Pascal.
The reason for this is given in Wirth’s “Good Ideas” article:
…The tools available for writing programs were assembler code, Fortran, and an Algol compiler. The Algol compiler was so poorly implemented we dared not rely on it, and working with assembler code was considered dishonorable. There remained only Fortran. Hence, our naïve plan was to use Fortran…
That's only the surface reason. *Why* was the Algol compiler so poorly implemented? Why did no one fix it?
Effectively, he's saying he didn't have an Algol compiler.
-
I believe Wirth developed Pascal on a CDC 6400 and that machine had a blazing fast Fortran compiler but I'm not sure that any other languages were as well developed for the 6400. If they existed at all, they were probably university projects.
https://wiki.freepascal.org/Fortran
-
" Once he had written the initial compiler, he was able to then rewrite the compiler in Pascal and use it to compile itself in the standard practice called bootstrapping."
https://en.wikipedia.org/wiki/Bootstrapping_(compilers) (https://en.wikipedia.org/wiki/Bootstrapping_(compilers))
-
I believe Wirth developed Pascal on a CDC 6400 and that machine had a blazing fast Fortran compiler but I'm not sure that any other languages were as well developed for the 6400. If they existed at all, they were probably university projects.
https://wiki.freepascal.org/Fortran
The CDC 6400 was just a reduced cost cut down CDC 6600. It was single-issue in-order, vs the CDC 6600's superscalar Out-of-Order with 10 functional units.
So it ran all the same software, just a lot slower.
-
I don't understand the need to change "programming" to "coding".
A "coder" is usually way cheaper than a programmer.
Apparently it sounds "cool", and one can get away with not being held as accountable as much, when challenged, as they can say "I'm a coder, not a programmer" (or a brogrammer!🤣).
It's all about fashion, appearing "cool" and how quickly you can make money, show off, pretend you're Bill Gates etc, as opposed to ACTUALLY KNOWING what you're doing.
In the old days when we had WAYYYYYYY less CPU, RAM and disk space, ACTUAL programmers were forced to be clever and exceptionally creative, as they only had bytes, maybe a few kilobytes to spare, and there was no luxury of lazily assuming they had 128GB of ram, so why not slap it together, and who cares. Yes it may work, but it's VERY VERY poor programming discipline. You're only getting away with your crappy software because vast pools of RAM and CPU cycles are hiding the fact that you're clueless.
-
What an interesting thread. Many years ago I taught a few computer related classes at tech school. Conclusion, every student has a different way of learning, different motivators, different abilities. There were tricks to motivate groups, but there was still a need to zero in on different students and have a minute or two of one-to-one. So describing any coding environment as 'best' just doesn't wash.
My introduction to computers was Algol on an Elliot 803. I started an Elec. Eng. Diploma and one of the classes was 'Computer Programming for Engineers'. Hooked from day one and decided I wanted to be a programmer. My motivation was the opposite of most people, I wanted to know how it worked. Didn't care if I was writing a program to work out orbital mechanics, blowout pressure of rubber rings in concrete pipes, ball bearings suitable for applications, or payroll. How to achieve the end efficiently was more important. Working with a 64kbyte system with a 2 microsecond cycle time encourages that.
Most people want a tool to achieve an end. Learn enough about the tool to move the sprite on the screen, blink the LED, spreadsheet the stock market. Learning to do it 'properly' is not on the radar. And as long as the tool does the job, a switch to another tool is not often considered even if it is better/easier. The outcome is more important than the method.
So the process is determine what the person wants to do - this is often the hardest part. What is motivation enough to get them learning the tool? Then, with a destination in mind, decide on the tool. You don't see a plumber running around with an oscilloscope, or an electrician with gas fitting tools. After those are in place it is time to introduce logical thinking. Up to a point, any 'application' can be written in any code environment. The old saying was if it could be done, it can be done in FORTRAN. If it can't be done, do it in assembler.
Back a ways there was a mention the PL/1 compiler was written in FORTRAN. I had the task of figuring out why a FORTRAN program on a VAX was not running as well as it should. A back of the envelope calculation said it should take much less, so I was tasked to hand code the critical parts in assembler (the FORTRAN compiler would take in line assembler). To my surprise, the critical parts took only 10% longer than what I considered optimal. The compiler was very good at optimization. The problem turned out to be the programmer's I/O - they were reading/writing individual array elements to disk. I modified the program with a couple of lines of FORTRAN to read/write 1000 elements at a time, reduced run time from 40 hours to 8. So the idea of a compiler written in FORTRAN is not too far fetched.
And there is the difference between motivations - the program did what the writer wanted, and if it took 30 minutes instead of 5 there wouldn't be an issue. A similar issue occurred in another job, a program analyzed figures and took half an hour. The accounts department ran the program with four different sets of figures every week, which wasn't too much of an issue. But 7 sets at end of month was; end of month was a busy time. I offered to look at the program, restructured and reduced run time to under a minute with all 7 sets of data. My reward was the boss shouting me a beer.
So now I'm a dinosaur. I love the fact that two variables can be swapped by A xor B, B xor A, A xor B - with no other data space required. How many other people would care? A project I am working on needed more code. I had not worried how long it was taking, it hadn't crashed (yet). But would it handle the extra work? A quick benchmark showed the processor was used less than 1%. The extra code might push that to 1.5%. And I was only using half the available code space. The penalty of a frugal upbringing.
I hope you don't mind a bit of reminiscing.
When it comes to coding v programming, I look to the examples I gave. In my mind a coder has a task and achieves it. A programmer is more interested not only in the what, but also in the how. A programmer looks to other considerations such as readability, maintenance, resources, etc.
-
coding v programming
those who design and plan before implementing.
those who (try to re-) design and plan after implementing.
who care definitions? I care i have successfully implemented monads in my own C-like language, this will simplify future designs, which will simplify future projects implementations.
-
Bill Gates
umm I think comparing Bill Gates(1) with Steve Jobs(1) needs more fancy statistical theories than comparing Jean-Louis Gassée(2) with Dominic Giampaolo(3) and Cyril Meurillon(3)
Unfortunately they are not a free-running artificial intelligence string, my neural processors cannot easily find a matching pattern, except ... they are all somehow involved in computer science and contributed to the development of something.
(1) motivator, business executive
(2) motivator, planner
(3) designer, implementer
Bill Gates | Jean-Louis Gassée -> why PC manufacturers don't sell non MS products
-
I don't understand the need to change "programming" to "coding".
Well said nor should programmers be called "developers". When I was younger "developing" was what one did in a darkroom.
-
People also use 'real estate development', so if it includes planning and finding out the requirements and targets, 'software developer' fits better than 'coder'.
When done right, engineering principles are applied to 'design, develop, maintain, test, and evaluate software', but it's rarer than genuine imitation hen's teeth.
Most involved in creating software are just code monkeys, slinging poo at the wall and hoping some of it sticks and they get paid.
-
Most involved in creating software are just code monkeys, slinging poo at the wall and hoping some of it sticks and they get paid.
;D
-
I don't understand the need to change "programming" to "coding".
Well said nor should programmers be called "developers". When I was younger "developing" was what one did in a darkroom.
Uh dunno about that, not that it really matters.
Actually "developer" is a slightly fancier term, although it doesn't mean a whole lot - can cover a whole range of different skillsets.
While "programmer" is pretty much the lowest level of the scale. Historically, a programmer was mainly translating high-level statements into machine code, later on that stepped up and a programmer was the one translating analyzed specifications (so basically higher level than a programming language) into a programming language. But a "programmer" has pretty much always been at the bottom of the scale. So if terms matter to you, developer is actually fancier than programmer.
Then came the "software engineer" term, which is largely a misnomer - as has been discussed for decades now.
So all in all, "software developer" seems the most adequate to me.
-
Most involved in creating software are just code monkeys, slinging poo at the wall and hoping some of it sticks and they get paid.
;D
You have to admit, many of the choices made in the software world are the equivalent of "New and Intuitive Continuous Olfactory-based Fuel Economy Monitoring" in the automotive world. From the actual engineering report: We connected a portion of the exhaust to the cabin so that it is effortless for the driver to continuously monitor the combustion efficiency and detect abnormalities in the combustion reactions of the internal combustion engine.
Just think of the prevalence of self-modifying code in web frameworks: they are supposed to be able to update themselves, which makes them an obvious, clear security hole. Except the people involved disagree. Apparently, they like the scent of exhaust in their cabins, and find it invigorating rather than dangerous.
-
Us poop slingers are soon to be replaced.
AI solves Advent of Code 2022 (https://note89.github.io/the-advent-of-code-ai-edition/)
-
Most involved in creating software are just code monkeys, slinging poo at the wall and hoping some of it sticks and they get paid.
;D
You have to admit, many of the choices made in the software world are the equivalent of "New and Intuitive Continuous Olfactory-based Fuel Economy Monitoring" in the automotive world. From the actual engineering report: We connected a portion of the exhaust to the cabin so that it is effortless for the driver to continuously monitor the combustion efficiency and detect abnormalities in the combustion reactions of the internal combustion engine.
Just think of the prevalence of self-modifying code in web frameworks: they are supposed to be able to update themselves, which makes them an obvious, clear security hole. Except the people involved disagree. Apparently, they like the scent of exhaust in their cabins, and find it invigorating rather than dangerous.
Oh yeah. But the state of software design these days is pretty sad anyway.
As I said not long ago as a paraphrase: "Software is much too serious a thing to be left to software engineers." If "engineers" is the right term.
-
Quote by Edsger Dijkstra: "If debugging is the process of removing software bugs, then programming must be the process of putting them in...."
Coders ignore this. Programmers find out the hard way. Software Engineers have this burned into their DNA and defend as best they can.
Arbitrary delineation.
-
I can see similar lack of pride in the reliability of their work in many other areas too, here in Finland; I suspect because of the long subcontractor chains and everyone being anonymous and nobody having any pride/satisfaction in "I helped build that" anymore. It's just "I don't care, I just work here" all over.
I freely admit that my own focus on bugs and avoiding errors is twofold: one is my personality type, and the other is the dopamine kick when I see others use my tools and build something I myself could not have, letting me think "I helped make that happen" deep inside. Call it pride, or work satisfaction, or whatever, but it is an important positive factor in my work, without which I'd probably switch to potato farming or something.
<
I was not always like this. I did have the thirst for making something BIG once, but it turns out I'm not built for such stuff; I'm just an archaic Finn, not a world-changer. I just wish I had discovered the true source of happiness –– it's all the small things in life! –– earlier in my life. :-//
As to those I help, I often ask them to pass it forwards: to help others in turn, when the opportunity rises. That brings me joy. I also help new programmers see why making robust code with error checks (and especially noticing when the input data is suspect, and warning the user that something probably went wrong, so as to not silently garble their precious data) brings happiness and the right kind of success, through personal anecdotes and examples. That's enough world-changing for me, although I do wish I had more charisma so I could make videos or blog posts on this, and reach a wider potential set; but, I don't, not right now at least.
Which leads to the topic at hand.
I can see both kinds of programmers. Those who are like the subcontractors, who only care if their work product passes the cursory muster, and move on.
And then there are the ones who like to do better. They want their work product to last, be useful, and be secure. There are obviously variants on the focus of "better", but the ones to whom it is important, will be happy to describe you what they want and mean by "better". :D
Conflicts ensue when the two mix types of programmers mix.
-
This is in all areas indeed, not just with software.
Problem is that there is no external incentive much anymore. It's like almost nobody cares, so there is near to zero external reward for great and reliable designs. Actually, what you design must not be too reliable as this goes against artificial economic growth. Stability is the enemy of our current economic system, and we are starting to reap the consequences very clearly.
Which means that you essentially need to rely on internal rewards only to push you forward. You could call that a sense of ethics, and it must be pretty strong to counterbalance the lack of external motivation.