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.

Coda Highland
On Wed, Apr 26, 2017 at 3:56 PM, Jay Carlson <[hidden email]> wrote:
> 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.

I disagree. It's convenient to make linear containers, associative
containers, and fixed structures all use the same implementation in
terms of language design; there's definitely a certain elegance to
that. But those ARE in fact three distinct concepts, and blurring the
distinction between them seems unwise to me.

>> 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?

Then you agree with me! Beginner C++ should be passing things by value
or by reference instead of by pointer as much as possible, and
idiomatic C++ reflects this. (There's a reason that move semantics
were such a big deal in the discussions leading up to C++11; that's
what allows pass-by-value to operate efficiently.)

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

As mentioned upthread, there's no point in teaching C when you could
be teaching C++. C++ can do literally everything C can, and it can do
it with syntax that's much friendlier and much less error-prone. Even
the argument about being better in restricted environments is proven
to not hold water, because Arduino's primary language is C++. (That's
not to say that the C++ STL is suitable for restricted environments.
That's a separate argument.) In fact, learning C before learning C++
I've found tends to HURT your ability to write good C++ until you've
unlearned some habits.

High level language -> C -> assembly is really a pretty bad path
nowadays. The demand for assembly skill is ridiculously small. I'm a
CS major myself, and I've only ever written assembly for the fun of it
on retro systems (and an attempt to write a C++ compiler, which got
aborted due to the instructor vanishing). I've never had demand to
write so much as a single line of assembly code in a professional
context. If you're going to teach assembler in school, you should be
teaching it on a toy model as a didactic tool for understanding the
low-level functioning of the CPU instead of teaching it as an actual
programming language.

Meanwhile, modern C++ is a sufficiently high-level language that if
you come at it with an open mind (instead of with prejudices derived
from the disaster that was pre-C++11 in a world that had to support
Visual Studio 6 long past its obsolescence) you'll find a much more
modern and comfortable experience than you might have expected.
There's nothing wrong with Python, and Scheme is a FANTASTIC teaching
language -- but as a SECOND language, where the significance of its
paradigm can be fully appreciated -- but it's not a necessary step in
the process.

That said, I already said upthread that I think that there are
possibly better choices than C++. C# is closer, even though I'd rather
use C++ for real work.

Lua is a good lightweight general-purpose language, don't get me
wrong, and there's probably nothing wrong with exposing fledgling
programmers to it. But in terms of actually building engineering
skill, I think starting off with a statically-typed object-oriented
language is a better choice.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Sean Conner
It was thus said that the Great Coda Highland once stated:
>
> Beginner C++ should be passing things by value
> or by reference instead of by pointer as much as possible, and
> idiomatic C++ reflects this. (There's a reason that move semantics
> were such a big deal in the discussions leading up to C++11; that's
> what allows pass-by-value to operate efficiently.)

  Perhaps it's because of my extensive background in Assembly and C, but
what exactly *is* the difference between a pointer and a reference, other
than hiding the pointer behind some syntactic surgar?

> >> 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.
>
> As mentioned upthread, there's no point in teaching C when you could
> be teaching C++. C++ can do literally everything C can, and it can do
> it with syntax that's much friendlier and much less error-prone.

  Even coroutines?  Such as https://github.com/spc476/C-Coroutines

(okay, granted, it's implemented in assembly, but it works quite well for C;
I wouldn't even know how to begin to adapt that for C++)

> Even
> the argument about being better in restricted environments is proven
> to not hold water, because Arduino's primary language is C++. (That's
> not to say that the C++ STL is suitable for restricted environments.
> That's a separate argument.) In fact, learning C before learning C++
> I've found tends to HURT your ability to write good C++ until you've
> unlearned some habits.

  And C++ hurts your ability to reason about non-object oriented code I've
found.  Yes, C++ is technically a multi-paradigm programming language where
you don't *have* to use classes, but come on ... it's OOP (I am not a fan of
OOP, just so you know where my biases lie).

> High level language -> C -> assembly is really a pretty bad path
> nowadays. The demand for assembly skill is ridiculously small. I'm a
> CS major myself, and I've only ever written assembly for the fun of it
> on retro systems (and an attempt to write a C++ compiler, which got
> aborted due to the instructor vanishing).

  What did the instructor vanishing have to do with not finishing a C++
compiler?  Unless it was a (rather ridiculously large) class project.

> I've never had demand to
> write so much as a single line of assembly code in a professional
> context. If you're going to teach assembler in school, you should be
> teaching it on a toy model as a didactic tool for understanding the
> low-level functioning of the CPU instead of teaching it as an actual
> programming language.

  That, I agree with.  There are much better CPUs to learn assembly on than
the x86 beast we're stuck with today.  I'm fond of the Motorola CPUs myself
(6809 for 8-bit, 68000 series for 32-bit).

> Meanwhile, modern C++ is a sufficiently high-level language that if
> you come at it with an open mind (instead of with prejudices derived
> from the disaster that was pre-C++11 in a world that had to support
> Visual Studio 6 long past its obsolescence) you'll find a much more
> modern and comfortable experience than you might have expected.

  I still find it more verbose than Ada ever was, even today.  

  Then again, I'm old school when it comes to this stuff anyway.

> Lua is a good lightweight general-purpose language, don't get me
> wrong, and there's probably nothing wrong with exposing fledgling
> programmers to it. But in terms of actually building engineering
> skill, I think starting off with a statically-typed object-oriented
> language is a better choice.

  Remove "object oriented" and I would probably agree.  

  -spc (At the very least, come up with some better examples of OOP than
        animals, vehicles or shapes)


Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Andrew Starks-2
On Wed, Apr 26, 2017 at 7:07 PM, Sean Conner <[hidden email]> wrote:

> It was thus said that the Great Coda Highland once stated:
>> Lua is a good lightweight general-purpose language, don't get me
>> wrong, and there's probably nothing wrong with exposing fledgling
>> programmers to it. But in terms of actually building engineering
>> skill, I think starting off with a statically-typed object-oriented
>> language is a better choice.
>
>   Remove "object oriented" and I would probably agree.
>
>   -spc (At the very least, come up with some better examples of OOP than
>         animals, vehicles or shapes)

I think I'm weird or something or I'm not seeing your particular
forest for the trees that I've stared at. I think I'd pox both of your
houses.

Static types: When learning how to program, I don't know that static
typing is a net positive. To me, it tends to push problems elsewhere
and cause a whole lot of code to be generated, just to get around the
strong typing. When you're first starting out, is it necessary to
teach this or is it a concept that can be added later?

Early on, I want to learn about the basic structures of programming
and how they're composed. I want to learn about:

 - Values
 - References
 - Variables
 - Scope (and thus globals and locals and upvalues)
 - Functions
 - Branch statements
 - Loops
 - Structures
 - Using libraries
 - Breaking things into components / files
 - Testing
 - How to organize projects, comments, etc.

When I was first learning to program, the #1 word that I wanted to
avoid was "except", as in, "...works like this except sometimes, which
we'll cover 7 chapters from now, but try not to think about that right
now..." That sort of phrasing kills confidence.

To me, with the right curriculum, Lua is excellent for teaching
someone how to program. Simple is beautiful and the fact that you have
to create most of the more advanced structures and concepts is a win.

 - start by teaching structured programming
 - demonstrate C-style objects (functions with a state structure)
 - ease into object oriented programming using tables with properties
and methods and the ":" operator.
 - Maybe show some craziness with metatables and operator overloading
 - Then make them do another object model, using closures.

Make me construct my own object model in two different ways and I can
assure you that I'll understand the concept better than if you just
hand it to me.

Same thing is true with arrays: in Lua, I have to implement them with
tables. If I want to make sure that I don't have holes, then I have to
learn how to do that too.

There may be data that proves me wrong, but when I'm learning, I want
to have a feeling for what is going on and a sense that I can hold
everything in my head.

--
Andrew Starks
612 840 2939
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Hisham
On 26 April 2017 at 21:44, Andrew Starks <[hidden email]> wrote:

> On Wed, Apr 26, 2017 at 7:07 PM, Sean Conner <[hidden email]> wrote:
>> It was thus said that the Great Coda Highland once stated:
>>> Lua is a good lightweight general-purpose language, don't get me
>>> wrong, and there's probably nothing wrong with exposing fledgling
>>> programmers to it. But in terms of actually building engineering
>>> skill, I think starting off with a statically-typed object-oriented
>>> language is a better choice.
>>
>>   Remove "object oriented" and I would probably agree.
>>
>>   -spc (At the very least, come up with some better examples of OOP than
>>         animals, vehicles or shapes)
>
> I think I'm weird or something or I'm not seeing your particular
> forest for the trees that I've stared at. I think I'd pox both of your
> houses.
>
> Static types: When learning how to program, I don't know that static
> typing is a net positive. To me, it tends to push problems elsewhere
> and cause a whole lot of code to be generated, just to get around the
> strong typing. When you're first starting out, is it necessary to
> teach this or is it a concept that can be added later?
>
> Early on, I want to learn about the basic structures of programming
> and how they're composed. I want to learn about:

They are composed according to the one thing you left out of your
list: types. :)

Even in Lua, a beginner needs to learn that a table is not a number
and that you can do different things to each. That's types. Maybe you
meant to cover this under "values", but if we make the notion of types
clear, you don't need the darned "references" in that list so early.
While we look at Lua variables through the glasses of our experience,
we tend to think as some arguments being call-by-value and some
call-by-reference because of copying and pointers in the
implementation, but really if you abstract this away, it is no
different when you pass a number or a table as an argument.

As for types being static or dynamic, there will be disagreeing
opinions here. But if advocates of functional programming say that
starting with functional programming is better because values of
variables don't change so things are less confusing, then I could make
a similar argument that starting with static typing is better because
types of variables don't change so things are less confusing. If
sometimes _we_ lose track of what's inside our Lua tables, imagine
beginners...

Most often when I see people complaining about static types, often
mentioning their verbosity, I think that the problem is that people
are not thinking of particularly good languages (similarly to the "OOP
is bad because Java is verbose" thing — in fact, Java is a common
strawman to bash static typing as well).

-- Hisham

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Coda Highland
In reply to this post by Sean Conner
On Wed, Apr 26, 2017 at 5:07 PM, Sean Conner <[hidden email]> wrote:
>   Perhaps it's because of my extensive background in Assembly and C, but
> what exactly *is* the difference between a pointer and a reference, other
> than hiding the pointer behind some syntactic surgar?

The main difference is that references can't be null or
uninitialized/invalid/pointing to a deleted object, and you can't do
pointer arithmetic on a reference. The syntax gives you no way to do
arithmetic without explicitly converting it to a pointer, and since
you can't delete or reassign a reference it's hard to get a bogus one
without explicitly doing things with pointers somewhere or taking a
reference to a temporary that goes out of scope. Admittedly the latter
one is a problem that can happen, but it's a MUCH smaller surface for
errors.

>> As mentioned upthread, there's no point in teaching C when you could
>> be teaching C++. C++ can do literally everything C can, and it can do
>> it with syntax that's much friendlier and much less error-prone.
>
>   Even coroutines?  Such as https://github.com/spc476/C-Coroutines
>
> (okay, granted, it's implemented in assembly, but it works quite well for C;
> I wouldn't even know how to begin to adapt that for C++)

Yes: http://www.boost.org/doc/libs/1_64_0/libs/coroutine/doc/html/index.html

>   And C++ hurts your ability to reason about non-object oriented code I've
> found.  Yes, C++ is technically a multi-paradigm programming language where
> you don't *have* to use classes, but come on ... it's OOP (I am not a fan of
> OOP, just so you know where my biases lie).

This isn't really a meaningful analogy. The problem isn't a question
of changing paradigms. The problem is that C++ will let you write C
code and have it work more-or-less unchanged. When you're switching
between more distinct languages, the syntactic shift is usually enough
to defuse most of the most problematic habits, but you don't get that
benefit in the case of C -> C++, where doing C things is the fastest
way to violate all of the safety mechanisms built into C++. (C++ -> C
on the other hand works fine; your C code has structs and function
pointers where other people wouldn't use them, but you never break the
language's fundamental assumptions.)

>> High level language -> C -> assembly is really a pretty bad path
>> nowadays. The demand for assembly skill is ridiculously small. I'm a
>> CS major myself, and I've only ever written assembly for the fun of it
>> on retro systems (and an attempt to write a C++ compiler, which got
>> aborted due to the instructor vanishing).
>
>   What did the instructor vanishing have to do with not finishing a C++
> compiler?  Unless it was a (rather ridiculously large) class project.

It was the entire premise of the class -- the promise was that the
class would teach you every last nook and cranny of the C++ standard
by building a (eventually self-hosting) C++ compiler from the ground
up. But after first term ended, and my compiler could parse any
standards-compliant C++ code and generate symbol tables and ASTs from
it, and my assembler could take a mock language and generate x86_64
code for it, the second term never started. The instructors just
stopped answering e-mails and the site languishes abandoned to this
day.

>> Meanwhile, modern C++ is a sufficiently high-level language that if
>> you come at it with an open mind (instead of with prejudices derived
>> from the disaster that was pre-C++11 in a world that had to support
>> Visual Studio 6 long past its obsolescence) you'll find a much more
>> modern and comfortable experience than you might have expected.
>
>   I still find it more verbose than Ada ever was, even today.
>
>   Then again, I'm old school when it comes to this stuff anyway.

No, no, verbosity is one criticism that C++ has no answer for. I agree
with you here, and that's why I think C# would be better than C++ as a
teaching language if the standard libraries weren't so obviously
influenced by Windows APIs.

>> Lua is a good lightweight general-purpose language, don't get me
>> wrong, and there's probably nothing wrong with exposing fledgling
>> programmers to it. But in terms of actually building engineering
>> skill, I think starting off with a statically-typed object-oriented
>> language is a better choice.
>
>   Remove "object oriented" and I would probably agree.
>
>   -spc (At the very least, come up with some better examples of OOP than
>         animals, vehicles or shapes)

I definitely agree that the stereotypical OOP examples are lame and I
avoided them when building my own OO curriculum for tutoring a
student. Building a GUI is a MUCH better and much more realistic
application of object-oriented code than animals, vehicles, and
shapes.

/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 Andrew Starks-2
On Wed, Apr 26, 2017 at 5:44 PM, Andrew Starks <[hidden email]> wrote:

> On Wed, Apr 26, 2017 at 7:07 PM, Sean Conner <[hidden email]> wrote:
>> It was thus said that the Great Coda Highland once stated:
>>> Lua is a good lightweight general-purpose language, don't get me
>>> wrong, and there's probably nothing wrong with exposing fledgling
>>> programmers to it. But in terms of actually building engineering
>>> skill, I think starting off with a statically-typed object-oriented
>>> language is a better choice.
>>
>>   Remove "object oriented" and I would probably agree.
>>
>>   -spc (At the very least, come up with some better examples of OOP than
>>         animals, vehicles or shapes)
>
> I think I'm weird or something or I'm not seeing your particular
> forest for the trees that I've stared at. I think I'd pox both of your
> houses.
>
> Static types: When learning how to program, I don't know that static
> typing is a net positive. To me, it tends to push problems elsewhere
> and cause a whole lot of code to be generated, just to get around the
> strong typing. When you're first starting out, is it necessary to
> teach this or is it a concept that can be added later?
>
> Early on, I want to learn about the basic structures of programming
> and how they're composed. I want to learn about:
>
>  - Values
>  - References
>  - Variables
>  - Scope (and thus globals and locals and upvalues)
>  - Functions
>  - Branch statements
>  - Loops
>  - Structures
>  - Using libraries
>  - Breaking things into components / files
>  - Testing
>  - How to organize projects, comments, etc.
>
> When I was first learning to program, the #1 word that I wanted to
> avoid was "except", as in, "...works like this except sometimes, which
> we'll cover 7 chapters from now, but try not to think about that right
> now..." That sort of phrasing kills confidence.
>
> To me, with the right curriculum, Lua is excellent for teaching
> someone how to program. Simple is beautiful and the fact that you have
> to create most of the more advanced structures and concepts is a win.
>
>  - start by teaching structured programming
>  - demonstrate C-style objects (functions with a state structure)
>  - ease into object oriented programming using tables with properties
> and methods and the ":" operator.
>  - Maybe show some craziness with metatables and operator overloading
>  - Then make them do another object model, using closures.
>
> Make me construct my own object model in two different ways and I can
> assure you that I'll understand the concept better than if you just
> hand it to me.
>
> Same thing is true with arrays: in Lua, I have to implement them with
> tables. If I want to make sure that I don't have holes, then I have to
> learn how to do that too.
>
> There may be data that proves me wrong, but when I'm learning, I want
> to have a feeling for what is going on and a sense that I can hold
> everything in my head.
>
> --
> Andrew Starks
> 612 840 2939
> [hidden email]
>

On the whole I actually agree with you here. The content of the
curriculum and its means of presentation are far more important than
the language itself. A class presented as you give it would certainly
be successful. I'd take it, if it wouldn't bore me to tears because
I'm 20 years past that in my career. ;)

But in terms of the problems with static typing... I'm only aware of
three that come up at that level.

The first is the distinction between integers and floating-point
numbers. This is basically unavoidable, and I'd rather teach students
to be aware of it as early as possible because it's pretty fundamental
to computer programming.

The second is typecasting, and that's really more of a strong typing
issue than a static typing issue -- and Lua's typing is fairly strong.
Beginners tend to run into this more directly when it comes to wanting
to coerce strings and numbers back and forth to each other. The other
issues that come up in this regard I actually consider to be part of
the teaching process, because understanding the difference between
different kinds of object and why they're not interchangeable and what
you need to do to MAKE them interchangeable is very instructive.

The third is trying to store heterogeneous values in a container, and
the biggest lesson of that one is "don't do that."

/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 Jay Carlson
2017-04-27 0:56 GMT+02:00 Jay Carlson <[hidden email]>:

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

Is that related to C. Northcote Parkinson's description of committee
work — there is a sitting, some gassing about, a report is issued,
and after the necessary paperwork, the matter is dropped?

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Francisco Olarte
In reply to this post by Sean Conner
On Thu, Apr 27, 2017 at 2:07 AM, Sean Conner <[hidden email]> wrote:
>   Perhaps it's because of my extensive background in Assembly and C, but
> what exactly *is* the difference between a pointer and a reference, other
> than hiding the pointer behind some syntactic surgar?

You need a valid target to initialize a reference ( yeah, you may
invoke undefined behaviour somewhere and make it ref *0, but if you
are using it the easy way it makes things clearer, type* => optional,
type& => mandatory ).

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Enrico Colombini
In reply to this post by Hisham
On 26-Apr-17 23:08, Hisham wrote:
> 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.

Of course, but that could be generalized to most (if not all)
programming languages: a single model is mind-constraining ("To the man
who only has a hammer, everything he encounters begins to look like a
nail").

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

I first encountered BASIC on an Olivetti P6060; if I remember correctly,
it used the (then) mandatory LET for assignments.
I am still quite bad in advanced math and math notation, but in my case
it is definitely not BASIC's fault :-)

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Francisco Olarte
In reply to this post by Sean Conner
On Thu, Apr 27, 2017 at 2:07 AM, Sean Conner <[hidden email]> wrote:
> It was thus said that the Great Coda Highland once stated:
>> As mentioned upthread, there's no point in teaching C when you could
>> be teaching C++. C++ can do literally everything C can, and it can do
>> it with syntax that's much friendlier and much less error-prone.
>
>   Even coroutines?  Such as https://github.com/spc476/C-Coroutines
>
> (okay, granted, it's implemented in assembly, but it works quite well for C;
> I wouldn't even know how to begin to adapt that for C++)


I normally look in boost whenever I need one of these things, and
voila, it has one:

http://www.boost.org/doc/libs/1_64_0/libs/coroutine2/doc/html/index.html

Also, I would try the C-Coroutines stuff directly, they tend to work (
you cannot throw across coroutines, and this kind of stuff, but you do
not need to throw or use new in C++ )


I'd also point that in fact I currently do all my coding in C++, even
when doing some prety normal malloc/printf/strcpy things. I've found
that even not using any fancy stuff being able to use some small
features makes my task easier ( recent C compilers have all things
like inline et al, but they  got to c++ first, in fact, IIRC, let me
check my copy ... yes, K&R 2e preface "We used Bjarne Stroustroup C++
translator extensively for local testing..." )

Francisco Olarte.

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Viacheslav Usov
In reply to this post by Sean Conner
On Thu, Apr 27, 2017 at 2:07 AM, Sean Conner <[hidden email]> wrote:

>   Even coroutines?  Such as https://github.com/spc476/C-Coroutines
>
> (okay, granted, it's implemented in assembly, but it works quite well for C; I wouldn't even know how to begin to adapt that for C++)

The "for C" part is incorrect. It works quite well for certain combinations of (CPU architecture; operating system; C compiler). Those particular combinations ensure you can switch stacks and register contexts the way you do; even more fundamentally, they ensure you have stacks and register contexts to begin with. You could certainly do that same thing with certain combinations of (CPU architecture; operating system; C++ compiler). In fact, given that all the mainstream C compilers share their backends with the corresponding mainstream C++ compilers, you could easily have overlapping combinations with mostly the same code (one additional problem you would need to tackle is the C++ exception mechanism).

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Viacheslav Usov
In reply to this post by Coda Highland
On Thu, Apr 27, 2017 at 1:39 AM, Coda Highland <[hidden email]> wrote:

> That said, I already said upthread that I think that there are possibly better choices than C++. C# is closer, even though I'd rather use C++ for real work.

I see a lot of programmers who learnt their craft within the last 10-15 years struggling to understand how computers work at the fundamental level. I believe this to have been caused by the use of high-level languages like C# that shield the user from the underlying computer so perfectly that there is little incentive to understand it.

In the context of training future professional computer programmers, the above is a costly mistake. They need to be taught a language that does not have that level of isolation. In the same context, I do not buy the argument that C++ can be taught as the first language with a realistic amount of instruction available in a typical curriculum. Most of C++that-is-not-C features make sense only once somebody really understands what programming is really about, and has some experience to reflect upon; teaching that "in advance" only creates cargo cults (like the one where everything is an object derived from another object, all ultimately derived from one base object). Someone needs to have a simpler language, but not a toy language, that can be mastered within a semester or two. I am afraid that C is the only reasonable choice for such a language today.

For non-professional programmers, the situation might be different, but that is not my field, so I do not have a strong opinion there.

Cheers,
V.
Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

steve donovan
In reply to this post by Coda Highland
On Thu, Apr 27, 2017 at 1:39 AM, Coda Highland <[hidden email]> wrote:
> ... But in terms of actually building engineering
> skill, I think starting off with a statically-typed object-oriented
> language is a better choice.

A few points. The first is that many of us did not start off that way,
and 'graduated' to such languages later. (Basic seems to have damaged
very few minds, if any).  Now, I personally started off with Fortran
(very vaguely typed in those days), but the following year had a most
excellent course in Pascal with Judy Bishop for which I'm always
grateful. Structured programming was just what I needed.

The second point hinges on the word 'engineer'. There are many people
who need to script things, but won't become professional programmers.
For instance, engineers using VBA, scientists using Python, and so
forth. I suspect this group is larger.

The third point revolves around the meaning of 'object-oriented'.
Modern C++ tends to emphasize generic programming more, and has become
better at expressing functional concepts. Old-style OOP has been
regarded as problematic for a while - James Gosling was asked what he
would leave out from Java and he said "classes".  He went on to
explain that interface inheritance was fine, but implementation
inheritance leads to problems (the GoF wrote about this twenty-odd
years ago).  People learn Java (badly) and follow all the Python
examples, and get fixated on a particular kind of OOP.  There's a new
breed of statically-typed languages which sidestep this, like Go and
Rust. Very differ  ent (apart from some syntactical similarity) but
both very different from the cartoon picture of OOP that comes
illustrated with animals.

In fact, I may agree just a little with Prof Dijkstra, if he had said
instead that over-learning and over-applying a paradigm damages the
ability of students to learn new things.

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Enrico Colombini
On 27-Apr-17 16:10, steve donovan wrote:
> In fact, I may agree just a little with Prof Dijkstra, if he had said
> instead that over-learning and over-applying a paradigm damages the
> ability of students to learn new things.

My thoughts exactly.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Coda Highland
In reply to this post by steve donovan
On Thu, Apr 27, 2017 at 7:10 AM, steve donovan
<[hidden email]> wrote:

> On Thu, Apr 27, 2017 at 1:39 AM, Coda Highland <[hidden email]> wrote:
>> ... But in terms of actually building engineering
>> skill, I think starting off with a statically-typed object-oriented
>> language is a better choice.
>
> A few points. The first is that many of us did not start off that way,
> and 'graduated' to such languages later. (Basic seems to have damaged
> very few minds, if any).  Now, I personally started off with Fortran
> (very vaguely typed in those days), but the following year had a most
> excellent course in Pascal with Judy Bishop for which I'm always
> grateful. Structured programming was just what I needed.

I certainly didn't start off that way either. I started with Applesoft
BASIC in 1987. Structured programming was certainly an improvement
over my self-taught designs, but we've had 30 years of refinement
since then and I see no reason to teach the structured programming
paradigm the way it was originally designed. Better to focus on modern
best practices.

> The second point hinges on the word 'engineer'. There are many people
> who need to script things, but won't become professional programmers.
> For instance, engineers using VBA, scientists using Python, and so
> forth. I suspect this group is larger.

Certainly so, and I believe that might be a fundamental difference in
what drives our opinions. I'm coming at this from the perspective of
educating people who want to make a career out of making application
software, whereas I fully acknowledge that there is a completely
different field of people for whom programming is an incidental part
of their career instead of the focus. For the latter group,

> People learn Java (badly) and follow all the Python
> examples, and get fixated on a particular kind of OOP.

Ugh, yeah, no kidding. There's a reason I said C# and not Java. Java's
become ridiculously cargo-culty, and Python... I detached from that
community YEARS ago and just write my own code my own way so I don't
know what they're like these days.

> There's a new
> breed of statically-typed languages which sidestep this, like Go and
> Rust. Very differ  ent (apart from some syntactical similarity) but
> both very different from the cartoon picture of OOP that comes
> illustrated with animals.

I need to learn Rust one of these days. Go... does not impress me, and
I'm a Xoogler. I just don't get it.

> In fact, I may agree just a little with Prof Dijkstra, if he had said
> instead that over-learning and over-applying a paradigm damages the
> ability of students to learn new things.

Absolutely! That's why I said Scheme is a great second language --
introduce it after the students have gotten past the "this is how to
make the computer do what you want it to do" stage, bring in some new
fundamentals, really broaden horizons.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Jorge Visca
In reply to this post by Hisham
On 26/04/17 18:08, Hisham wrote:
> 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)

The way these things work are really strange. I had classmate in
high-school who was absolutely unable to solve any equation whatsoever;
he said they made no sense to him. After a rather awkward discussion we
understood what was going on: for him "x + y = z" made sense because you
operated on the left and put the result on the right. But "x = z - y"
was just gibberish, because there was nothing to do! So he had a sort of
imperative thinking (notated backwards), probably developed from
laborious number crunching in school (no computers involved).

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Coda Highland
On Thu, Apr 27, 2017 at 12:56 PM, Jorge <[hidden email]> wrote:

> On 26/04/17 18:08, Hisham wrote:
>>
>> 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)
>
>
> The way these things work are really strange. I had classmate in high-school
> who was absolutely unable to solve any equation whatsoever; he said they
> made no sense to him. After a rather awkward discussion we understood what
> was going on: for him "x + y = z" made sense because you operated on the
> left and put the result on the right. But "x = z - y" was just gibberish,
> because there was nothing to do! So he had a sort of imperative thinking
> (notated backwards), probably developed from laborious number crunching in
> school (no computers involved).

I've seen languages that put the destination of assignments on the
right, usually with a -> operator or similar.

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

Re: Beginner to programming. References to understand terms.

Jorge Visca
On 27/04/17 17:03, Coda Highland wrote:
> I've seen languages that put the destination of assignments on the
> right, usually with a -> operator or similar.

Like the Casio fx6300G calculator :)

https://www.manualslib.com/manual/358119/Casio-Fx-6300g.html?page=54#manual

Did a Mandelbrot plotter once, took like a minute for a 40x23 b&w picture.

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 steve donovan
2017-04-27 16:10 GMT+02:00 steve donovan <[hidden email]>:

> Now, I personally started off with Fortran
> (very vaguely typed in those days), but the following year had a most
> excellent course in Pascal with Judy Bishop for which I'm always
> grateful.

<reminiscence>
You dropped a name that I recognize, of a person that I knew in those
days. I was always a little sore at her for not letting me join the SA
Computer Science Lecturers' Association because I was not actually
teaching formal courses in computer science. I was merely doing
a lot of in-house retraining of students produced by SACSLA members
so that they could program in Fortran :-)
</reminiscence>

I, too, started off with Fortran but had to do a lot of work in PL/I,
which must be on the shortlist for ugliest programming language
ever invented. [1] Then I discovered Algol-W, which was Wirth's previous
attempt at designing a language to his own taste, and loved it. The
step from Algol-W to Pascal was no larger than later steps (which
I never actually took) to Modula and then to Oberon would have
been.

But Pascal would have been on the rubbish heap if it were not for
Borland. Turbo Pascal is an even better first language than the
original Pascal in the sense that it is almost as teach-it-yourself
as BASIC. My 8-year old twins acquired it by watching me.

One of the things about Lua that grabbed me was that Lua code
looked very much like Pascal code, with an even smaller set of
keywords. I still think there must be some subset of Lua that one
could use as a teaching language. Implementing it would be
easy. Only lua.c would require changes: pass code through
a verifier rather like PFORT (remember that?)

[1] Its spiritual heirs include Ada and Java.

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 Coda Highland
2017-04-27 20:27 GMT+02:00 Coda Highland <[hidden email]>:

> That's why I said Scheme is a great second language --
> introduce it after the students have gotten past the "this is how to
> make the computer do what you want it to do" stage, bring in some new
> fundamentals, really broaden horizons.

I have no experience of Scheme, but I have written some Guile,
which I'm told is litlle more than a rebranding of Scheme. The sheer
size of the vocabulary is daunting. Doesn't suit my taste at all. Its
Zen seems to "more is less".

1234