Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Resistance to switching software

Reply
Thread Tools

Re: Resistance to switching software

 
 
Michael Wojcik
Guest
Posts: n/a
 
      10-04-2005

Followups restricted to comp.human-factors. This is probably OT there,
but it's wildly OT in all the other groups to which it's been posted.
The OP needs to attend remedial Usenet classes.

In article <(E-Mail Removed) .com>, "swansnow" <(E-Mail Removed)> writes:
>
> 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.


Indeed, what could be more intuitive than:

#! /usr/bin/perl
open (OUT, ">outfile") || die "can't open outfile\n";
while (<>)
{
@lexitems = split /([<>])/;
foreach $lexitem (@lexitems)
{
if (! $list{$lexitem})
{
print OUT $lexitem;
$list{$lexitem} = 1;
}
}
}

And that's a very simple (and not very useful) Perl program; and
while I rarely use Perl, I don't see any particularly non-idiomatic
constructions there.

Perl may be easy for beginners. It may serve well as a teaching
language. But I don't see any evidence that it's in any way
"intuitive" for beginning programmers. "Intuitive" is generally
shorthand for "corresponding in a relatively apparent manner to
something familiar", and I doubt many non-programmers are familiar
with Perl's freewheeling and idiosyncratic use of punctuation marks,
for example.

In any event, I suspect "intuitive" is a false benefit in a
programming language. COBOL was designed to be intuitive by
mimicking English syntax (and to a much lesser extent semantics) and
by attempting to model what was then considered good programming
practice (eg by requiring a definition of data structures up front).
While there are still defenders of COBOL, and it's still widely used
(which is nice, since it butters my bread), few people are prepared
to advocate for it as a teaching language. More tellingly, if you
read comp.lang.cobol or similar forums, you'll see that COBOL
professionals rarely put much effort into making their code
"intuitive" or striving to imitate natural language with it. They
use constructions that are comfortable and efficient in COBOL - in
other words, idiomatic ones.

Programming is not a matter of mimicking writing instructions for
people, or mathematics, or other human activities, any more than
carpentry or litigation are. It's a problem domain in its own
right, and while there are certainly deep and important connections
to other problem domains, I don't believe that the way to learn to
program is by pretending it's something else.

Thus programming languages should seek to be useful as programming
languages first, and not to appeal to some other need. A hammer
may serve the purpose of a stone; that doesn't mean it should be
designed to be used as in the same manner as a stone.

(Frankly, I'm not particularly persuaded by arguments that software
in general should be "intuitive", either. But that's another
matter.)

--
Michael Wojcik http://www.velocityreviews.com/forums/(E-Mail Removed)

Unlikely prediction o' the day:
Eventually, every programmer will have to write a Java or distributed
object program.
-- Orfali and Harkey, _Client / Server Programming with Java and CORBA_
 
Reply With Quote
 
 
 
 
Nameless
Guest
Posts: n/a
 
      10-04-2005
"Reinder Verlinde" wrote in message
news:(E-Mail Removed)...
> In article <u_q0f.779$as3.399@amstwist00>,
> "Nameless" <(E-Mail Removed)> 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:(E-Mail Removed)>:
>
> 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"
> <(E-Mail Removed)> 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?


No, that would require a presentation far beyond that which
would be desirable or possible in a newsgroup message. Hmmm,
this might be a good theme for a website; I'll notify the
newsgroup(s) when it is up and running.

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


Well, you certainly shouldn't avoid concretizing the subject
matter under way, preferably with examples from different
paradigms and methodologies. But the onus should remain on
problem solving techniques, in particular the breakdown of
a proposed (small) system into its constituent parts and
*why* it should be so constructed.

That said, if you are running a course on, say, Pascal, then
it would be rather pointless rambling on about Haskel or ML.

> And yes, UML is complex, but so is English. You do
> not need to learn all of UML in order to 'talk' it.


The difference is that young potential programmers already
have a number of years behind them with their mother tongue.
Therefore, no distractions from the matter at hand. Students
may well learn industrial system modelling techniques at a
later time; they will feel more comfortable and be better
prepared by first learning how to write conceptual outlines.

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


Indeed, the Wiki article you mentioned explicity states that
it is related to OO-software development. UML emerged and
grew out of such development needs. But yes, UML does claim
to be a lot of things, often too much, which easily leads to
disorientation within the system.

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


 
Reply With Quote
 
 
 
 
Laurie Fineman
Guest
Posts: n/a
 
      10-05-2005

Then Michael Wojcik says:
>
>Followups restricted to comp.human-factors. This is probably OT there,


Nope. Read thread title - group title.

>but it's wildly OT in all the other groups to which it's been posted.
>The OP needs to attend remedial Usenet classes.


The OP, me, posted a question about the difficulty of getting
people to switch software with the prime example the old Basic v.
Pascal debate. No mention of C. The groups were:

comp.human-factors
comp.lang.basic.misc
comp.lang.pascal.delphi.misc

If that ain't right then it's a charter agenda. Not my problem
to solve.

The 2nd poster in the thread:

(E-Mail Removed) (Alf P. Steinbach)

Changed groups to:

comp.human-factors
comp.lang.basic.misc
comp.lang.pascal.delphi
misc,comp.lang.c

Therein lies your problem. S/he also called *my* post a
troll.

I replied switching *back* to the originals. Other's didn't.
 
Reply With Quote
 
Jacob Sparre Andersen
Guest
Posts: n/a
 
      10-05-2005
"Nameless" <(E-Mail Removed)> writes:

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


Yes. But the structure of that conceptual outline is likely to
reflect your programming experience, and thus the programming
languages you are used to.

I can at least see that effect in my own work, where I have a strong
tendency to formulate a problem in terms of types. - Something that
definitely seems to be more typical for my "de facto language", Ada,
than of languages with more relaxed type systems or non-procedural
languages.

> A conceptual outline is "language-free" insomuch that it may be used
> as the basis for programming in the language of one's choice.


Yes. But the conceptual outline written by a Prolog programmer is
likely to be dramatically different from that written by a C or Ada
programmer.

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


Although I try not to generate pseudocode, when I sketch the outline
of a problem, but I still find that I tend to think in terms of my
programming habits.

Jacob
--
<URL: small-talk://work/hallway-meeting/...>
 
Reply With Quote
 
Flash Gordon
Guest
Posts: n/a
 
      10-05-2005
Laurie Fineman wrote:

> The OP, me, posted a question about the difficulty of getting
> people to switch software with the prime example the old Basic v.
> Pascal debate. No mention of C. The groups were:
>
> comp.human-factors
> comp.lang.basic.misc
> comp.lang.pascal.delphi.misc
>
> If that ain't right then it's a charter agenda. Not my problem
> to solve.


<snip others changing group list>

It is *still* not topical on comp.lang.c and that is not *our* problem.
Please EVERYONE take comp.lang.c off the list except for any discussion
of what is topical, topicality always being on topic. I have already
posted one polite request for people to do this.

Here on comp.lang.c we discuss programming in standard C, we don't
discus design (except peripherally), algorithms (except peripherally),
system specifics, the merits of other languages or anything else that is
being discussed in this thread.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
 
Reply With Quote
 
Michael Wojcik
Guest
Posts: n/a
 
      10-05-2005

In article <(E-Mail Removed)>, "Laurie Fineman" <(E-Mail Removed)> writes:
> Then Michael Wojcik says:
> >
> >Followups restricted to comp.human-factors. This is probably OT there,

>
> Nope. Read thread title - group title.


I think it's debatable, but perhaps "probably" was too strong.

> >but it's wildly OT in all the other groups to which it's been posted.
> >The OP needs to attend remedial Usenet classes.

>
> The OP, me, posted a question about the difficulty of getting
> people to switch software with the prime example the old Basic v.
> Pascal debate.


I'd still consider that excessive crossposting, and I'd consider it
OT for comp.lang.basic.misc (it's at best tangentially related to
BASIC as a language) and comp.lang.pascal.delphi.misc (the connection
to Delphi is extremely tenuous). The BASIC/Pascal debate would be
on-topic in, say, alt.folklore.computers.

> No mention of C. The groups were:
>
> comp.human-factors
> comp.lang.basic.misc
> comp.lang.pascal.delphi.misc
>
> If that ain't right then it's a charter agenda. Not my problem
> to solve.


It's your problem as a responsible Usenet user to post only to groups
where your message is topical, and to eschew excessive crossposting.
That certain behaviors are mandated by law or custom does not relieve
someone of responsibility for practicing them.

> The 2nd poster in the thread:
>
> (E-Mail Removed) (Alf P. Steinbach)
>
> Changed groups to:
>
> comp.human-factors
> comp.lang.basic.misc
> comp.lang.pascal.delphi
> misc,comp.lang.c
>
> Therein lies your problem.


Right you are, and my apologies for not checking the original post
to confirm which groups it was originally posted to. Alf's the
real culprit. (No surprise there; he's hardly the most courteous
Usenet denizen.)

--
Michael Wojcik (E-Mail Removed)

O sometimes, nevertheless,
The labourer at his instrument or tractor,
Bending into a state of merge with objects,
Finds the same love that, from a machine of sex,
Steps down as Venus to her invoker. -- George Barker
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
hsv and origin resistance towards acyclovir hsv and origin resistance towards acyclovir ASP .Net 0 02-19-2008 04:00 AM
Wind Resistance Caleb Java 7 04-10-2007 03:27 PM
Resistance of Standard Computer Alhilal Computer Information 2 02-27-2006 02:51 AM
DMM testing batteries under load -- what resistance? Neil Harrington Digital Photography 62 11-10-2005 04:11 PM
Smudge, Water Resistance HP cartridges Bk 20, Color 49 on Stickyback/Chartpak* news3.california.com Digital Photography 0 01-08-2004 07:19 AM



Advertisments