Re: Resistance to switching software
 

* Laurie Fineman:
>
> As old timers will recall, back in the '80s and somewhat into the
> '90s there was a long-running, heated debate over which language
> was best among the two most popular: Basic or Pascal.

Ah, multiply cross-posted trolling! That's good -- good, good, good! --
if it can increase the traffic in the [comp.human-factors] group!

But the debate wasn't about Basic versus Pascal, it was about Pascal versus C,
e.g. <url: http://www.lysator.liu.se/c/bwk-on-pascal.html> (Brian Kernighan on
why Pascal certainly isn't his favorite language), and in addition there was a
non-debate over the issue over whether Basic was a programming language or
not, at all, e.g. Edsger Dijkstra "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.", <url:
http://www.cs.virginia.edu/~evans/cs655/readings/ewd498.html>.

Btw., "human factors" refers to how humans interact with computers and
possibly other things, it doesn't refer to the human condition. ;-)


> ...
> As a software developer, the same seems true of app software. My
> #1 marketing problem is getting people to try something new once
> they have learned to use their existing software. Nobody wants to
> learn to do most of the same things differently, but most
> operators don't seem to want to admit that. Some do, and some
> have good arguments due to their superior "at application"
> perspective, but I also get arguments that seem rather trivial or
> don't make much sense.
>
> In both cases, I think it is obvious that this is one reason
> software marketers give students, etc. incentives to use a
> product - the developers know that once they learn a certain
> language or application, it tends to become "the best."
>
> Has anyone else experienced this? I wonder what legitimate
> techniques work to get people to switch software? Also, when is
> this justified? Of course there is a productivity loss while
> learning a new product, and a developer can hardly be objective
> in thinking their own product is better.

CP/M, MS-DOS and Windows spring to mind as examples, although not of
application software.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[OT] Re: Resistance to switching software
 

Alf P. Steinbach wrote:
> * Laurie Fineman:
> >
> > As old timers will recall, back in the '80s and somewhat into the
> > '90s there was a long-running, heated debate over which language
> > was best among the two most popular: Basic or Pascal.
>
> Ah, multiply cross-posted trolling! That's good -- good, good, good! --
> if it can increase the traffic in the [comp.human-factors] group!


<snip>

I thought from the title ("Resistance to switching software") this was
going to be a telecommunications post!


--
Nick Keighley

A coding theorist is someone who doesn't think Alice is crazy.

Re: Resistance to switching software
 

Alf P. Steinbach wrote:
> But the debate wasn't about Basic versus Pascal,
> it was about Pascal versus C,

Depends on which debate about which point in computer history.

Before "teaching languages" there were debates between teaching
Fortran, Cobol or assembly. Then, when the first teaching
languages appeared, I remember some schools trying to choose
between either Basic or Pascal. C didn't really join the mix
until after Unix started to become deployed widely outside of
AT&T and UC Berkeley. Some colleges also offered APL as an
introductory programming language.

As for a preference for using a known language, some cognitive
illusion seems to cause programmers to underestimate how long
it would take to accomplish a task using a known language or
development system, and overestimate how long it would take to
become equally competent in a new language or system. However,
it seems that the converse error in estimation, usually
attributed to a management decision, can occasionally result
in even larger engineering disasters.

I learned Fortran first, then C; but have a preference for Basic
as a teaching language because it doesn't hide the dirty details
of the actual compute engine behind too much abstraction. In my
opinion, structure and other good programming practices should be
taught separately from the introductory programming language, and
not just "hidden" within a language definition or implementation.


IMHO. YMMV.
--
Ron
http://www.nicholson.com/rhn/basic

Re: Resistance to switching software
 

Followups to comp.lang.basic.misc.

rhnlogic wrote:
<snip>
> I learned Fortran first, then C; but have a preference for Basic
> as a teaching language because it doesn't hide the dirty details
> of the actual compute engine behind too much abstraction.

What? That's the world turned upside down. Just because the most
primitive versions of Basic only offer GOTO and maybe FOR-NEXT as a
means of changing control flow doesn't mean it's not hiding anything,
let alone not offering tons of abstraction.

On the contrary, most versions of Basic I've seen hardly care what types
your variables have (but *will* use types), will gladly convert between
integers and floating-point values (and strings, in extreme cases) and
do all sorts of other high-level stuff you have to ask for in most
languages and certainly won't get for free on most real-world computers
(or theoretical ones, for that matter).

You want programming without dirty details hidden? Use some abstract
assembly language. Knuth's MIX and MMIX architectures spring to mind.
Unless you really just want to get filthy, then you can use an actual
architecture. I recommend the Intel 8086, since everybody loves
segments. :-)

> In my opinion, structure and other good programming practices should
> be taught separately from the introductory programming language, and
> not just "hidden" within a language definition or implementation.
>
>
Problem is, how can you teach good programming practices without knowing
what programming is? How can you learn what programming is without a
language, even a highly idealized one? How do you know what programming
practices transcend languages if you don't know any, or just one?

There are, for starters, tons of bad programming practices you can
acquire in Basic. But learning how to avoid them doesn't make you a
better programmer -- it just makes you a better Basic programmer. Other
languages may not even offer you the opportunity for making avoidable
mistakes, and good for them, too. They may offer you abstractions Basic
cannot even implement effectively, and won't help you understand.

There *are* general principles you can learn and subsequently apply to
whatever language you're working in. But trying to work them out in
either a void or one language, with all its idiosyncrasies, seems
hopeless to me. Basic may win out only because there never was one
Basic, so just about any pseudo-language that's sufficiently abstract
looks like Basic. Doesn't mean the ability to actually execute your
programs that comes with using a "real" language like that is a bonus.

> IMHO. YMMV.

I'll say. Don't get me wrong, I'm not knocking Basic here. I grew up on
that, and contrary to what Dijkstra would have you believe, I survived. :-)

S.

Re: Resistance to switching software
 

"rhnlogic" wrote in message
news:1128378648.622086.137290@g44g2000cwa.googlegr oups.com...
> [snipped]
> In my opinion, structure and other good programming practices
> should be taught separately from the introductory programming
> language, and not just "hidden" within a language definition
> or implementation.

There's a lot of sense in what you say here. Gone are the
days when students were instructed to write conceptual
outlines as a prerequisite to writing code in any language.
A conceptual outline will necessarily involve structure and
in many cases highlight the need for good, well-defined
programming practices, such as splitting tasks into smaller
self-contained ones.

A conceptual outline is "language-free" insomuch that it
may be used as the basis for programming in the language of
one's choice. It follows that a conceptual outline is not
pseudocode which, because of its imperative form, may
(inadvertently) bind one to a specific programming paradigm
or methodology.

--
Mail sent to this email address is deleted unread
on the server. Please send replies to the newsgroup.

Re: Resistance to switching software
 

In article <u_q0f.779$as3.399@amstwist00>,
"Nameless" <news.mail@chello.no> wrote:

> Gone are the days when students were instructed to write conceptual outlines
> as a prerequisite to writing code in any language.
> A conceptual outline will necessarily involve structure and in many cases
> highlight the need for good, well-defined programming practices, such as
> splitting tasks into smaller self-contained ones.

As long as one does not automatically generate code from the model, I
would think that the Unified Modeling Language (UML; see
<http://en.wikipedia.org/wiki/Unified_Modeling_Language>) takes that
outline role.

Reinder

Re: Resistance to switching software
 

Reinder Verlinde wrote:
> In article <u_q0f.779$as3.399@amstwist00>,
> "Nameless" <news.mail@chello.no> wrote:
>
>>Gone are the days when students were instructed to write conceptual outlines
>>as a prerequisite to writing code in any language.
>>A conceptual outline will necessarily involve structure and in many cases
>>highlight the need for good, well-defined programming practices, such as
>>splitting tasks into smaller self-contained ones.
>
> As long as one does not automatically generate code from the model, I
> would think that the Unified Modeling Language (UML; see
> <http://en.wikipedia.org/wiki/Unified_Modeling_Language>) takes that
> outline role.

Although this is good stuff it is *not* topical on comp.lang.c (I don't
know about the other groups. Here on comp.lang.c we deal with C language
issues, not general programming design or algorithm issues.

I'm redirecting follow ups to exclude comp.lang.c, please honour this
for further discussion of this topic.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Re: Resistance to switching software
 

"Reinder Verlinde" wrote in message
news:reinder-C79BBB.12351604102005@reader28.wxs.nl...
> In article <u_q0f.779$as3.399@amstwist00>,
> "Nameless" <news.mail@chello.no> wrote:
>
>> Gone are the days when students were instructed to write
>> conceptual outlines as a prerequisite to writing code in any
>> language. A conceptual outline will necessarily involve
>> structure and in many cases highlight the need for good,
>> well-defined programming practices, such as splitting tasks
>> into smaller self-contained ones.
>
> As long as one does not automatically generate code from the
> model, I would think that the Unified Modeling Language (UML;
> see <http://en.wikipedia.org/wiki/Unified_Modeling_Language>)
> takes that outline role.

No, the UML binds one to a specific methodology. Besides,
as a language it is known to have a steep learning curve
which may not be appropriate in the actual teaching
environment. Far better to use natural language such that
students may concentrate on the task at hand.

I urge you to reread the last paragraph of my prior message,
which you have omitted, it is implicit on this matter. ;)

--
Mail sent to this email address is deleted unread
on the server. Please send replies to the newsgroup.

Re: Resistance to switching software
 

Hmmm, If I may chime in as a programmer, and former teacher...

For teaching, it depends on the age of the learner. For little kids
(<9yo), Logo wins, hands down - minimal syntax, graphical environment,
makes numbers concrete, requires problem-solving even at the very
beginning. Logo is a real language, a variant of Lisp (which is a
functional language, not imperative like BASIC).

For Older kids, I would start with an emphasis on problem solving. As a
consequence, I'd use a very easy language like Perl or Python (some
people use Scheme, Alice, or other "teaching" languages). I would
choose Perl or Python because they are real languages, but their basic
syntax and usage is intuitive. Python in particular encourages
structure (or so I hear, I'm thinking about learning it, so I know only
a bit about it).

Only after a student understands how to solve problems, and understands
how to think algorithmically, and understands the concepts of
repitition, and abstraction, *then* would I introduce a more
complicated language like Java.

Our family homeschools, and this is the general course I think I'll do
with my kids, depending on interest and aptitude. We're just starting
on Logo now.

-Corinna

Re: Resistance to switching software
 

In article <u_q0f.779$as3.399@amstwist00>,
"Nameless" <news.mail@chello.no> wrote:

> Gone are the days when students were instructed to write
> conceptual outlines as a prerequisite to writing code in any
> language. A conceptual outline will necessarily involve
> structure and in many cases highlight the need for good,
> well-defined programming practices, such as splitting tasks
> into smaller self-contained ones.

I replied in article
<news:reinder-C79BBB.12351604102005@reader28.wxs.nl>:

RV> As long as one does not automatically generate code from the
RV> model, I would think that the Unified Modeling Language (UML;
RV> see <http://en.wikipedia.org/wiki/Unified_Modeling_Language>)
RV> takes that outline role.

In article <DPu0f.793$as3.73@amstwist00>, "Nameless"
<news.mail@chello.no> replied:

> No, the UML binds one to a specific methodology. Besides,
> as a language it is known to have a steep learning curve
> which may not be appropriate in the actual teaching
> environment. Far better to use natural language such that
> students may concentrate on the task at hand.
>
> I urge you to reread the last paragraph of my prior message,
> which you have omitted, it is implicit on this matter. ;)

That paragraph reads:

> A conceptual outline is "language-free" insomuch that it
> may be used as the basis for programming in the language of
> one's choice. It follows that a conceptual outline is not
> pseudocode which, because of its imperative form, may
> (inadvertently) bind one to a specific programming paradigm
> or methodology.

Can you give a concrete example of such a conceptual outline that would
be useful in learning people what programming is?

I have trouble visualizing anything that does not also include some
choice of programming methodology (e.g. 'object-oriented', 'functional',
'data-flow')

I think any concrete-enough introduction to programming must make some
methodology choice. And yes, UML is complex, but so is English. You do
not need to learn all of UML in order to 'talk' it.

One disadvantage of choosing UML would be that, although it claims to be
universal over all methodologies, UML is best geared towards O-O
development.

Reinder