Author Topic: The next generation of programmers  (Read 8075 times)

0 Members and 1 Guest are viewing this topic.

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: The next generation of programmers
« Reply #25 on: September 23, 2022, 11:20:30 am »
Over a quarter of a century ago, a company called MacroMind created Director.

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.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: The next generation of programmers
« Reply #26 on: September 23, 2022, 01:49:25 pm »
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!
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: The next generation of programmers
« Reply #27 on: September 23, 2022, 04:48:41 pm »
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.
 
The following users thanked this post: edavid, tooki

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26761
  • Country: nl
    • NCT Developments
Re: The next generation of programmers
« Reply #28 on: September 23, 2022, 05:47:54 pm »
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
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: tooki, cfbsoftware

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14317
  • Country: fr
Re: The next generation of programmers
« Reply #29 on: September 23, 2022, 06:21:45 pm »
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.
 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3637
  • Country: nl
Re: The next generation of programmers
« Reply #30 on: September 23, 2022, 06:29:14 pm »
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.

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: The next generation of programmers
« Reply #31 on: September 23, 2022, 08:07:56 pm »
Quote
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.
 
The following users thanked this post: nctnico, tooki, bpiphany, cfbsoftware

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: The next generation of programmers
« Reply #32 on: September 24, 2022, 12:50:08 am »
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.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: The next generation of programmers
« Reply #33 on: September 24, 2022, 03:55:54 am »
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.

Quote
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.
 

Online pcprogrammer

  • Super Contributor
  • ***
  • Posts: 3637
  • Country: nl
Re: The next generation of programmers
« Reply #34 on: September 24, 2022, 06:50:50 am »
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.

Offline tooki

  • Super Contributor
  • ***
  • Posts: 11343
  • Country: ch
Re: The next generation of programmers
« Reply #35 on: September 24, 2022, 12:52:46 pm »
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.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: The next generation of programmers
« Reply #36 on: September 24, 2022, 12:58:57 pm »
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.
 
The following users thanked this post: Ed.Kloonk, tooki, pcprogrammer

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: The next generation of programmers
« Reply #37 on: September 24, 2022, 01:55:27 pm »
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.
 

Offline Nominal Animal

  • Super Contributor
  • ***
  • Posts: 6177
  • Country: fi
    • My home page and email address
Re: The next generation of programmers
« Reply #38 on: September 24, 2022, 02:33:54 pm »
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.
 

Offline PlainName

  • Super Contributor
  • ***
  • Posts: 6796
  • Country: va
Re: The next generation of programmers
« Reply #39 on: September 24, 2022, 04:58:10 pm »
Quote
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.

 
The following users thanked this post: tooki

Offline Picuino

  • Frequent Contributor
  • **
  • Posts: 714
  • Country: 00
    • Picuino web
Re: The next generation of programmers
« Reply #40 on: September 24, 2022, 05:24:55 pm »
In this "review" I miss the Scratch programming language.
https://scratch.mit.edu/projects/editor/

It is currently ranked 22nd most popular language in the Tiobe index.

It is developed for educational purposes by the MIT Media Lab's Kindergarten Group (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

There are thousands of projects that you can look at and experiment with by modifying them:
https://scratch.mit.edu/explore/projects/all/popular

Golf example: https://scratch.mit.edu/projects/690300423/editor/
« Last Edit: September 24, 2022, 05:56:55 pm by Picuino »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: The next generation of programmers
« Reply #41 on: September 24, 2022, 08:09:03 pm »
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.

« Last Edit: September 24, 2022, 08:46:00 pm by rstofer »
 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14317
  • Country: fr
Re: The next generation of programmers
« Reply #42 on: September 24, 2022, 09:15:21 pm »
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.
 
The following users thanked this post: cfbsoftware, pcprogrammer

Offline cfbsoftwareTopic starter

  • Regular Contributor
  • *
  • Posts: 112
  • Country: au
    • Astrobe: Oberon IDE for Cortex-M and FPGA Development
Re: The next generation of programmers
« Reply #43 on: September 24, 2022, 10:41:00 pm »
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
 
« Last Edit: September 24, 2022, 10:47:34 pm by cfbsoftware »
Chris Burrows
CFB Software
https://www.astrobe.com
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: The next generation of programmers
« Reply #44 on: September 25, 2022, 12:19:06 am »
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.
« Last Edit: September 25, 2022, 01:44:54 am by brucehoult »
 

Offline cfbsoftwareTopic starter

  • Regular Contributor
  • *
  • Posts: 112
  • Country: au
    • Astrobe: Oberon IDE for Cortex-M and FPGA Development
Re: The next generation of programmers
« Reply #45 on: September 25, 2022, 01:27:27 am »
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:

Quote
Because Fortran did not feature pointers and records, we had to squeeze symbol tables into the unnatural form of arrays.
Chris Burrows
CFB Software
https://www.astrobe.com
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4003
  • Country: nz
Re: The next generation of programmers
« Reply #46 on: September 25, 2022, 01:53:06 am »
It's not about GOTO. As I said, it was due to FORTRAN 66's inadequacy to express complex data structures:

Quote
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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: The next generation of programmers
« Reply #47 on: September 25, 2022, 03:37:42 pm »
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


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.
« Last Edit: September 25, 2022, 03:56:04 pm by rstofer »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: The next generation of programmers
« Reply #48 on: September 25, 2022, 03:55:06 pm »
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.

 

Online SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14317
  • Country: fr
Re: The next generation of programmers
« Reply #49 on: September 25, 2022, 05:53:25 pm »
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
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf