Beginner to programming. References to understand terms.

classic Classic list List threaded Threaded
71 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Paul E. Merrell, J.D.
On Tue, Apr 25, 2017 at 2:14 AM, Enrico Colombini <[hidden email]> wrote:

>... people just tend to create lots
> of global variables)

For beginners, we need a better explanation of variable scope and how
to implement that on the wiki. It took me more than a year to finally
figure that out and then only with some guidance from people on this
list.

Best regards,

Paul

--
[Notice not included in the above original message:  The U.S. National
Security Agency neither confirms nor denies that it intercepted this
message.]

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

steve donovan
On Tue, Apr 25, 2017 at 11:51 AM, Paul Merrell <[hidden email]> wrote:
> For beginners, we need a better explanation of variable scope and how
> to implement that on the wiki. It took me more than a year to finally
> figure that out and then only with some guidance from people on this
> list.

Yes, and it's too easy to forget our own difficulties. With increasing
mastery, pain points recede and a person finds it hard to inhabit the
space of the beginner.

I think some pretty diagrams can help!  I have the tutorial itch
again, so I'll start putting stuff on the wiki.

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Andrew Starks-2
In reply to this post by Enrico Colombini

On Tue, Apr 25, 2017 at 04:14 Enrico Colombini <[hidden email]> wrote:
On 25-Apr-17 08:34, Dirk Laurie wrote:
> Oops! You're right, of course. Never trust the memory of a septuagenarian.

But your memory was right on the main point: Applesoft Basic was a great
language to start with. Few instructions, a simple model (but powerful
enough for that time and hardware) and, over all, immediate visual feedback.

Having spent many years writing beginner's self-instruction courses, I
think simplicity and directness may be more important than formal
cleanliness. A disciplined mind is better than a discipline-enforcing
language.
Formal cleanliness can be taught and can be used in (almost) any
language, even if not enforced by the language itself: I used to write
structured BASIC using GOTOs (and JMP in 6502 assembly code). I was even
doing recursion without argument passing :-)

By the way, BASIC was my first encounter with the garbage collection;
its powerful, flexible strings were the main thing I missed in C.

Back to the subject: I think interactive graphics are a very effective
tool to teach programming, because they give a large amount of feedback.
Unfortunately, current-day languages (or, I should say, programming
environments) tend not to offer built-in simple graphics.
By "simple graphics" I mean no-hassle instructions that draw directly
into the output window, such as LINE. They can be used to directly
illustrate concepts, visualize data, keep attention focused and so on.

The current setup/loop graphics model is powerful but conceptually
harder to grasp for a programming beginner, especially if you are trying
to teach the first steps of procedural programming and do not want to be
distracted by concepts such as graphics frames, events, callbacks and so on.
(I know, Processing is easy to use, but not simple to master and it does
not lend itself to good programming structure... people just tend to
create lots of global variables)

--
   Enrico

Have you played with Scratch? https://scratch.mit.edu/

After hating the version of LabView that came with the Lego Mindstorm, I was ready to hate on Scratch, as well. The drag and drop interface for it works really well. My 8 year old (whom I decided does not need to start with C) loves it.  It has the neat ability to let you create and manipulate graphics (lines and pens and such). Also, it's event driven, so you can create reasonable games. It even has built in collision detection! 

Nostalgia:

The Amiga was blessed with several excellent environments for learning how to program.

AREXX was pretty terrible for teaching you how to program *well*, but wow! It was rediculously powerful, given that all programs on the Amiga that had scripting used it. This meant that tying programs together was super simple. I believe that this was enabled by the system's flat memory model and lack of memory protection. I'm just guessing, but that probably made data sharing trivial.  

I loved the power of CanDo. You could *almost* make real WIMP programs in it! 

Finally, i had a tremendous amount of fun with AmigaVision. That was a drag and drop flowchart environment where you could double-click the modules and enter details into their form (plus comments).  You could also collapse blocks of code and wrap them into modules that could be called. Debugging was really easy, too. 

At my city government TV station, I created an interactive television information system using AmigaVision and a DTMF converter. Given the web, he whole system seems silly, but in 1089 it was pretty cool for a city to have such a service.



Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Roberto Ierusalimschy
In reply to this post by Dirk Laurie-2
> BASIC on the Apple II was in many ways the ideal beginner's language.

Dijkstra famously said:

    It is practically impossible to teach good programming to students
    that have had a prior exposure to BASIC: as potential programmers
    they are mentally mutilated beyond hope of regeneration.

I am fully convinced that this citation did (and still does) a huge
disservice to the teaching of programming.

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Gé Weijers
In reply to this post by steve donovan


On Mon, Apr 24, 2017 at 6:33 AM, steve donovan <[hidden email]> wrote:
As for C, I still maintain that C++ is easier to learn - sensible
strings, nice containers to put things, etc - until you misplace some
punctuation and the compiler shares its confusion with you. Can always
drop down to C-level, but C is premature optimization, unless you
really have a dinky little micro with 4K RAM.


Writing good idiomatic modern C++ requires a lot of knowledge about templates, iterators, smart pointers, exception safety, lambda expressions, and lots more. It takes a long time before you're a proficient C++ programmer. Using it as a first teaching language may be cruel and unusual education :-)

Coding in C (and C++, probably) should be part of a CS curriculum, but I would suggest teaching the main concepts using something a bit more high-level.

Re: "dinky little micro": I've programmed in C++ on a MSP430G2452 (8K flash, 512 bytes of RAM). In my opinion coding a useful program for a very small micro like this 50 cent chip is an educational experience, it challenges the assumptions of people who have never used a machine with less than a couple of gigabytes of RAM :-)



--

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

nobody
In reply to this post by Enrico Colombini
On 2017-04-25 11:14, Enrico Colombini wrote:
> Back to the subject: I think interactive graphics are a very
> effective tool to teach programming, because they give a large
> amount of feedback. Unfortunately, current-day languages (or, I
> should say, programming environments) tend not to offer built-in
> simple graphics. By "simple graphics" I mean no-hassle instructions
> that draw directly into the output window, such as LINE. They can be
> used to directly illustrate concepts, visualize data, keep attention
> focused and so on.

LÖVE (love2d.org) comes close to that.

   function love.draw( )
     love.graphics.circle( "fill", 100, 100, 50 )
   end

is all it takes to get a (white, filled, usually(?) un-antialiased)
circle (on a black background) onto the screen (a window of 640x480?
800x600? something like that).

It includes pretty complex libraries (physics (box2d) & particle systems
are probably the worst) but luckily you don't need them and don't need
to mention that they exists.  There's some unfortunate design choices,
but it being Lua, most of these can easily be papered over.  (E.g.
drawables (polygons, splines, …) are drawn with love.graphics.draw and
have no (e.g.) :draw method, but love.graphics.draw has no protocol for
handling user-defined drawables (e.g. fall back to :draw if unknown).
So if you do not want to care what thing you get & just get it drawn,
you have to fiddle with the methods of all internal drawables (add draw
= love.graphics.draw) or wrap love.graphics.draw to check for :draw.
There are a few more of those silly kinks, but overall it's quite usable.)

> The current setup/loop graphics model is powerful but conceptually
> harder to grasp for a programming beginner […]

While Love2D follows this model by default, (again) this being Lua, it
can be easily adjusted.  You can replace love.run (the startup code
which eventually calls love.main), love.main (the main loop which
repeatedly calls love.update and love.draw) or provide a different
drawing library which wraps the low-level stuff & repaints after every
draw call and then just step through (coroutine!) a user-defined script
that you run (resume) inside the default update/draw loop.  (Beware of
double buffering if you do the latter – so maybe first paint to a canvas
/ frame buffer from the user script & then draw that one to the screen.)

(There are both love.keypressed/mousepressed/… event handlers and
love.keyboard.isDown/love.mouse.getPosition/… query functions, so you
can use whatever style you prefer.)


I'd say that if you have a good idea of what you want & have looked at
how love2d is structured, it's feasible to get a runnable prototype of a
beginner-friendly environment in about 1-2 hours.  (Yes, it really is
very hackable & close to usable.)  After a few more hours of polishing
it should be in acceptable shape to try it on real beginners.  (And then
you improve it over the next weeks/months – better error messages, …)

-- nobody

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Enrico Colombini
In reply to this post by Andrew Starks-2
On 25-Apr-17 14:15, Andrew Starks wrote:
> Have you played with Scratch?https://scratch.mit.edu/

Actually, I co-wrote a couple of Scratch-centered school books for
primary school :-)

http://deagostiniscuola.deascuola.it/home?layout=search&idmarchio=4&idt=coding&idl=0

They even include a couple of small graphics adventures (my specialty,
sort of). Here is a mini-orrery without trigonometry:

https://scratch.mit.edu/projects/62467626/

> After hating the version of LabView that came with the Lego Mindstorm, I
> was ready to hate on Scratch, as well.

Eh eh... looks like I was not alone :-)

> The drag and drop interface for it
> works really well. My 8 year old (whom I decided does not need to start
> with C) loves it.  It has the neat ability to let you create and manipulate
> graphics (lines and pens and such). Also, it's event driven, so you can
> create reasonable games. It even has built in collision detection!

Scratch is very easy and captivating to start with, but is not without
flaws: a broken object model and more than a few residuals from a 1980's
mindframe. On the other hand it offers a powerful message-passing
mechanism between independent tasks (I usually explain it as "You shout
and all the other children listen").

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Enrico Colombini
In reply to this post by Roberto Ierusalimschy
On 25-Apr-17 15:48, Roberto Ierusalimschy wrote:
> Dijkstra famously said:
>
>      It is practically impossible to teach good programming to students
>      that have had a prior exposure to BASIC: as potential programmers
>      they are mentally mutilated beyond hope of regeneration.
>
> I am fully convinced that this citation did (and still does) a huge
> disservice to the teaching of programming.

I often thought the same thing. Apart from myself (but I actually
started with HP's RPN calculators and then 6502 assembly) I still
encounter old readers of my BASIC courses that went forward to a
rewarding programming career.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Enrico Colombini
In reply to this post by Gé Weijers
On 25-Apr-17 19:38, Gé Weijers wrote:
> Re: "dinky little micro": I've programmed in C++ on a MSP430G2452 (8K
> flash, 512 bytes of RAM). In my opinion coding a useful program for a very
> small micro like this 50 cent chip is an educational experience, it
> challenges the assumptions of people who have never used a machine with
> less than a couple of gigabytes of RAM :-)

Definitely. I would replace C++ with C, to keep all underlying concepts
in plain view with no behind-the-scene magic.

The simpler the model, the easier it is to concentrate on the
essentials: HP calculators with (if I remember correctly) 49 'program
steps' helped a lot in teaching me resource management.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Enrico Colombini
In reply to this post by nobody
On 26-Apr-17 05:18, nobody wrote:
> LÖVE (love2d.org) comes close to that.

Yes, I proposed it for a secondary-school course but they insisted on a
'mainstream' language :-/

Thanks for the useful notes about LÖVE customization.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Scott Morgan
In reply to this post by Gé Weijers
On 04/25/2017 06:38 PM, Gé Weijers wrote:
> Re: "dinky little micro": I've programmed in C++ on a MSP430G2452 (8K
> flash, 512 bytes of RAM). In my opinion coding a useful program for a
> very small micro like this 50 cent chip is an educational experience, it
> challenges the assumptions of people who have never used a machine with
> less than a couple of gigabytes of RAM :-)

Saw this demo of some guy coding C++17 and getting it to run on the 6502
based Commodore 64 (compiled to x86-64, then transpiled over to 6502, so
no as optimized at it could be, maybe)

https://www.youtube.com/watch?v=zBkNBP00wJE

Scott


Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

steve donovan
In reply to this post by Roberto Ierusalimschy
On Tue, Apr 25, 2017 at 3:48 PM, Roberto Ierusalimschy
<[hidden email]> wrote:
> I am fully convinced that this citation did (and still does) a huge
> disservice to the teaching of programming.

Absolutely! And there's little evidence of its truth, except in the
minds of unusually grumpy computer science professors.

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

steve donovan
In reply to this post by Enrico Colombini
On Wed, Apr 26, 2017 at 9:54 AM, Enrico Colombini <[hidden email]> wrote:
> Definitely. I would replace C++ with C, to keep all underlying concepts in
> plain view with no behind-the-scene magic.

Andrei Alexandrescu made this classic comment on Reddit

"In my opinion C++ is a language for experts and experts only [...] It
has enough pitfalls in virtually all of its core constructs to make
its use by benevolent amateurs virtually impossible except for the
most trivial applications."

(I like that word 'benevolent' ;))

I _used_ to think otherwise, even did a C++ interpreter (UnderC)
because I wanted to teach C++ "conversationally". That came out as the
Que book "C++ by Example" - unfortunately it was a series so they
couldn't use my original "Conversational C++" title.
The basic idea is that people learn languages best in an immersive
conversational context, stretching the artificial/natural language
correspondence a little. Well, it turns out that _some_ people learn
programming better than way.

With C, what you see is what you get; your foot is always clearly in
your gun sights.

And a very suitable partner for Lua, of course!

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

François Perrad
Tutorials (or others ressources) targeting real beginners are really uncommon.

I know:
1) Arduino where C++ (in fact, a small part of C++) is explained
see https://www.arduino.cc/en/Reference/HomePage

2) RaspberryPi promotes 2 languages Python & Scratch
see https://www.raspberrypi.org/documentation/usage/python/
and https://www.raspberrypi.org/documentation/usage/scratch/

Both are project (hardware here) specific and the effort doesn't come
from seasoned programmers.
Both projects (Arduino & Raspberry Pi) were created for education purpose.

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Coda Highland
In reply to this post by Dirk Laurie-2
On Mon, Apr 24, 2017 at 11:34 PM, Dirk Laurie <[hidden email]> wrote:

> 2017-04-25 8:30 GMT+02:00 Paige DePol <[hidden email]>:
>> Dirk Laurie <[hidden email]> wrote:
>>
>>> BASIC had just a few keywords and automatically numbered your lines.
>>> The system, such as it was, was integrated with it,  And it had graphics.
>>> MOVE 10, TURN 30, PEN DOWN, MOVE 20. It gave a wow factor.
>>
>> I think you may be conflating BASIC and LOGO with one another.
>
> Oops! You're right, of course. Never trust the memory of a septuagenarian.
>

LOGO _is_ a fantastic beginner's language, for the reasons you
describe and more. It's a functional language, so while it's
dynamically typed it does encourage the kinds of structures that are
worth learning early on.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Coda Highland
In reply to this post by Gé Weijers
On Tue, Apr 25, 2017 at 10:38 AM, Gé Weijers <[hidden email]> wrote:

>
>
> On Mon, Apr 24, 2017 at 6:33 AM, steve donovan <[hidden email]>
> wrote:
>>
>> As for C, I still maintain that C++ is easier to learn - sensible
>> strings, nice containers to put things, etc - until you misplace some
>> punctuation and the compiler shares its confusion with you. Can always
>> drop down to C-level, but C is premature optimization, unless you
>> really have a dinky little micro with 4K RAM.
>>
>
> Writing good idiomatic modern C++ requires a lot of knowledge about
> templates, iterators, smart pointers, exception safety, lambda expressions,
> and lots more. It takes a long time before you're a proficient C++
> programmer. Using it as a first teaching language may be cruel and unusual
> education :-)
>
> Coding in C (and C++, probably) should be part of a CS curriculum, but I
> would suggest teaching the main concepts using something a bit more
> high-level.

"Good idiomatic modern C++" != "good didactic C++". The stuff you're
talking about is a complete non-issue for a beginning programmer.

Templates: You don't need to know how to WRITE templates in order to
USE them. Beginners should be getting vector<> instead of arrays.

Iterators: Beginners will be using integer-indexed loops. Iterators
can be introduced later when non-random-access containers show up.

Smart pointers: Smart pointers are beautiful things, but
beginner-level C++ won't be doing the kinds of memory management that
needs it. This is going to come AFTER iterators, probably.

Exception safety: Beginner C++ programmers are going to want to let
exceptions crash the program. Writing exception-safe code can be
introduced when it becomes necessary, which isn't going to happen
until you get to file I/O.

Lambda expressions: Beginners will learn them idiomatically in the
context of sorting a container. They won't get complicated until they
start closing over references.

You're right that learning C++ to a level that you can write
enterprise-grade software is a long and arduous education, but that
doesn't mean that you have to jump in with both feet.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Dirk Laurie-2
In reply to this post by nobody
2017-04-26 5:18 GMT+02:00 nobody <[hidden email]>:

> I'd say that if you have a good idea of what you want & have looked at
> how love2d is structured, it's feasible to get a runnable prototype of a
> beginner-friendly environment in about 1-2 hours.  (Yes, it really is
> very hackable & close to usable.)  After a few more hours of polishing
> it should be in acceptable shape to try it on real beginners.  (And then
> you improve it over the next weeks/months – better error messages, …)

Is this a description of something you are actually working on?

Some time ago [1] tried to produce something of the kind, presumptuously
called it viLua (visual Lua), got shot down because the prefix 'vi' makes
Unix old-timers long for the days of terminal-based text editors.

When I tried running it now, it wouldn't (Love has made some breaking
changes since 2011). But I can distinctly remember that it took me
more than two hours ...

[1] http://lua-users.org/lists/lua-l/2011-11/msg00727.html

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Hisham
In reply to this post by Roberto Ierusalimschy
On 25 April 2017 at 10:48, Roberto Ierusalimschy <[hidden email]> wrote:

>> BASIC on the Apple II was in many ways the ideal beginner's language.
>
> Dijkstra famously said:
>
>     It is practically impossible to teach good programming to students
>     that have had a prior exposure to BASIC: as potential programmers
>     they are mentally mutilated beyond hope of regeneration.
>
> I am fully convinced that this citation did (and still does) a huge
> disservice to the teaching of programming.

I don't dispute that, but as someone who started programming with
BASIC myself (on the Apple II, no less!) I can attest that this
citation has at least some grain of truth. To this day I think very
concretely — but take into consideration that I learned that x=2 is a
stateful variable assignment _years_ before I learned that x=2 is a
mathematical equation (yes, I learned programming before elementary
school algebra). In general I was able to overcome it — I was still an
A-student in math in elementary school and I don't recall getting
confused, but to this day I have a major problem with the shortcuts of
more advanced mathematical notation. I realized that I parse math like
a computer, so to me a lot of the stuff that math teachers write in
their blackboards are full of (what today I know how to call) type
errors. In fact, my mind thinks so mechanically that I remember one
instance where I turned in an assignment to you in Semantics class and
you asked me if it was done using proof-assistant software, because
every single step was spelled out no matter how trivial it was. :)

I do remember one occasion in which this
mechanical-imperative-interpretation kind of thinking caused me
trouble, though. The first database I learned was dBASE during high
school, in which you always had to iterate tables using WHILE loops.
When I got to the Databases class in college I had the _hardest_ time
learning SQL, because my brain simply could not accept the magic that
was going on in queries. Since I couldn't produce a mental model for
executing those queries efficiently myself, my brain couldn't produce
solutions that involved nested projections, selections and joins
without being mind-boggled by all the gigantic intermediate tables
that conceptually exist in the naive explanation of the model. I kept
approaching problems in that class as "which table should I loop over
first and where do I store this data". Since then, I got better at
abstraction, but I think imperative interpretation will always be my
most natural way of thinking.

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Coda Highland
On Wed, Apr 26, 2017 at 2:08 PM, Hisham <[hidden email]> wrote:

> On 25 April 2017 at 10:48, Roberto Ierusalimschy <[hidden email]> wrote:
>>> BASIC on the Apple II was in many ways the ideal beginner's language.
>>
>> Dijkstra famously said:
>>
>>     It is practically impossible to teach good programming to students
>>     that have had a prior exposure to BASIC: as potential programmers
>>     they are mentally mutilated beyond hope of regeneration.
>>
>> I am fully convinced that this citation did (and still does) a huge
>> disservice to the teaching of programming.
>
> I don't dispute that, but as someone who started programming with
> BASIC myself (on the Apple II, no less!) I can attest that this
> citation has at least some grain of truth. To this day I think very
> concretely — but take into consideration that I learned that x=2 is a
> stateful variable assignment _years_ before I learned that x=2 is a
> mathematical equation (yes, I learned programming before elementary
> school algebra). In general I was able to overcome it — I was still an
> A-student in math in elementary school and I don't recall getting
> confused, but to this day I have a major problem with the shortcuts of
> more advanced mathematical notation. I realized that I parse math like
> a computer, so to me a lot of the stuff that math teachers write in
> their blackboards are full of (what today I know how to call) type
> errors. In fact, my mind thinks so mechanically that I remember one
> instance where I turned in an assignment to you in Semantics class and
> you asked me if it was done using proof-assistant software, because
> every single step was spelled out no matter how trivial it was. :)

I learned how to deal with those type errors in physics class:
dimensional analysis! Once you've annotated everything with
sufficiently descriptive typing, it DOES end up working out!

> I do remember one occasion in which this
> mechanical-imperative-interpretation kind of thinking caused me
> trouble, though. The first database I learned was dBASE during high
> school, in which you always had to iterate tables using WHILE loops.
> When I got to the Databases class in college I had the _hardest_ time
> learning SQL, because my brain simply could not accept the magic that
> was going on in queries. Since I couldn't produce a mental model for
> executing those queries efficiently myself, my brain couldn't produce
> solutions that involved nested projections, selections and joins
> without being mind-boggled by all the gigantic intermediate tables
> that conceptually exist in the naive explanation of the model. I kept
> approaching problems in that class as "which table should I loop over
> first and where do I store this data". Since then, I got better at
> abstraction, but I think imperative interpretation will always be my
> most natural way of thinking.

I had a very different experience. My dad is a database professional
so I learned SQL as a child because I was curious about what he was
doing and he was happy to teach me. I learned the theories and best
practices of database work long before I knew the formalisms that
drove them. (Learning tuple relational calculus in college was very
enlightening.)

In the end, I had to learn to do exactly what you had to teach
yourself to stop doing as my own career progressed. Thinking about
databases purely declaratively gave me trouble when I started dealing
with nontrivial datasets. I had to learn how the query compiler
transformed my declarative statements into sequential actions so that
I could make sure it did things in the most efficient order. (To wit:
exclude as much data as possible as early as possible so the joins
have less work to do.)

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Jay Carlson
In reply to this post by Coda Highland
On Apr 26, 2017, at 12:21 PM, Coda Highland <[hidden email]> wrote:
>
> "Good idiomatic modern C++" != "good didactic C++". The stuff you're
> talking about is a complete non-issue for a beginning programmer.
>
> Templates: You don't need to know how to WRITE templates in order to
> USE them. Beginners should be getting vector<> instead of arrays.

Beginners should be getting tables instead of arrays.

> Iterators: Beginners will be using integer-indexed loops. Iterators
> can be introduced later when non-random-access containers show up.

There's a good chapter on iteration in PiL. Note that cons-less iteration via next is covered...

> Smart pointers: Smart pointers are beautiful things, but
> beginner-level C++ won't be doing the kinds of memory management that
> needs it. This is going to come AFTER iterators, probably.

Smart pointers? What are pointers?

> Exception safety: Beginner C++ programmers are going to want to let
> exceptions crash the program. Writing exception-safe code can be
> introduced when it becomes necessary, which isn't going to happen
> until you get to file I/O.

Luckily for you, Lua has no story on how to handle prompt resource deallocation on non-local control flow, so I can't make the joke.

> Lambda expressions: Beginners will learn them idiomatically in the
> context of sorting a container. They won't get complicated until they
> start closing over references.

...but I can make it here!

> You're right that learning C++ to a level that you can write
> enterprise-grade software is a long and arduous education, but that
> doesn't mean that you have to jump in with both feet.

I guess I don't see the point of teaching C++ except as an elective. If you're a CS/EE major, you need to deal with the metal eventually[1], so you might as well go Python/Lua/Scheme then C then assembly. If you're not a CS/EE major, study Python/numpy and Excel, and run circles around the EEs.

Jay

[1]: OK, towards the end, SICP goes pretty far in making its runtime just as annoying as real metal.
1234