in reply to Are languages just superficial? in thread Learning Programming
Thank you for your reply.
I think in Perl there's a lot of syntactic sugar.
Too much. As a programmer with some experience, I like
Perl policy "there's more than a way...".
In a programming course, I think this could be a bit
confusing. IMHO. First, learn common programming pattern.
Then, develop a personal taste, choose your style. Choose your favourite programming language, if you can.
Larsen
Exposure to problem solving methods need not be limited in number.
by gryng (Hermit) on Aug 12, 2000 at 05:21 UTC
|
Well, I respect your opinion on teaching style, however I respectfully
disagree.
I think that Perl drops most of the extra work you have to do in order to
have the computer accomplish your goal (that is, you don't have to do things
like (de)allocate memory). Therefore what is presented to you through Perl
are all the basic problem solving tools.
Even if there are a myriad of ways to do the same thing with Perl's
plethora of tools, they all embody the different ways of solving problems.
And that to me, is the important part when it comes to programming, not
knowing the internals to all the data structures and how pointers dereference
my memory so I know what happens when I add 10 to it.
Learning which of these tools to use and when for each problem is the real
essence of good programming (problem solving). That is what I would try to
teach. Other languages can make the "Right Thing" (tm) too difficult to do
(e.g. hashes may be the best solution, but aren't always easy to use in other
languages), especially to a new programmer.
Where other languages will force you to pick the easy way to solve your
problem, Perl will tend to allow you to do it the correct way just as easily
as the lazy way.
If you are worried about confusing new programmers, remember that those
that will get confused the easiest, probably will also not be the most
adventurous. Therefore, if you only show them the simple and straighforward
ways, they will only see those ways, and can't be lost by the other options.
(for instance you could (gasp!) not show them what a hash is until
mid-quarter).
Just because Perl supports it, doesn't mean you have to show it to them
(though I would try to show them as much as you can and also encourage (and
perhaps even subtly, such as in homework, force them) to be adventurous).
Anyway, just my two cents. I see the merit in a guided path, aided by
some other stricter language (not to suggest more strict is worse). But I
would like (as a new programmer) to be able to explorer all the aspects of my
language. And the more relavent those aspects are to problem sovling, and not
to the programming language itself, the more useful my explorations are going
to be.
Cheers,
Gryn
| [reply] |
|
My limited teaching experienced was based on these points:
- What I'm trying to teach is problem solving. Programming language
is a tool to accomplish this task.
- Fundamentals are what I call linguistic constructions
(loops, if-then-else, data structures and so on).
- Solutions are expressed in pseudo-code, which I describe as
a midpoint between natural and artificial language. So they can
solve problem even if they think they can't program.
- First, let students try to solve their problem with linguistic
constructions they learned so far. Perhaps the problem is subtly
stated to be hard to solve. Then, teach new constructions, that make
problem easier to solve. This way, in my opinion, things are better
understood and remembered.
In order to follow such points, programming language must be very
simple. Translating from pseudo-code to a programming language is
supposed to be seen as the simplest of the phases.
Perl is sintactically too complex. Pascal is a tradition,
and is close to what students will learn next years (but, of course,
has a lot of
limits). As I said, I'd like to use Python.
I think we actually agree :).
| [reply] |
|
I think we do agree, for the most part :)
You mention the use of pseudo-code as a mid-step for solving a problem.
To me, the only usefulness actually writing down pseudo-code (if it's in your
head, it's not pseudo-code) is to by-pass a restrictive syntax structure that
is merely going to inhibit you stating the problem.
Pseudo-code can be useful, therefore, as a linguistic construct in order
to explain a problem/solution to someone as a type of lingua franca. That is,
pseudo-code is a more or less universal way of talking/writing that gets the
essence of all programming languages, without being bothered by any concept of
syntax.
Other than that use, actually having the student write down pseudo code
implies (to me), a problem with either their understanding of, or the natural
over-syntaxized of a particular language. In other words, pseudo-code would
act as a scratch board where you can quick jot down the solution, because it's
too hard to actually write syntactically correct code. (to which you can then
slowly fill in the correct syntax later).
I think that this symtom of using pseudo-code is primarily from ridged,
strict, and/or non-intuitive syntaxed languages. If you have to both solve
the problem and remember to use && but not &, etc. , then it makes
sense to just drop the notion that what you are writing down first will even
be close.
However, I think a language like Perl is much less strict, fluid, and (for
the most part) intuitive, especially compared to other languages (not to start
a Holy War (tm): e.g. Lisp, Ada). And becuase of the ease of thinking outloud
in Perl, it makes more sense to skip the entire notion of pseudo-code and
write down 90% syntax-correct code the first time.
That's the reason why I'd pick Perl over Python. Becuase while they are
both great languages, in terms of easing the programmer, Perl wins (IMO)
because it does not impose as strict of syntax.
Take for instance Ada. Ada is the only widely used programming language
with true strict typing. It's also a pain in the wazoo's rear end to program
in! I went straight from programming in Pascal for several years to Ada, and
I found that I was spending most of my time fixing boot-boatloads of syntax
and typing errors. I couldn't keep up with all the typing (er, structure, not
finger), and so I pretty much gave up and resigned to letting the compiler
tell me of all my mistakes.
Granted, when (several hours later -- I program a few kilos of lines
before I try to compile a big program, normally) I finally got the program to
compile, it had relatively few bugs. But I wouldn't completely atest that
towards the strong typing. Rather, the fact that I spent so much time
correcting typing errors, I would happen to read over some code that I didn't
think was correct, and fix it.
In contrast, Perl provides a lexical structure that I can easily remember
even when I while I was first learning the language. My program would
certainly have bugs in it, the first time I ran it. But the first time I
would tried to run it, I would rarely have a syntax error! (and if I did, it
was a bug manifesting itself to the compiler as syntax)
Anyway, I just feel that the easier the language is to learn, plus the
easier it is to actually spit out, makes solving the problem a much easier
task.
Again, just because Perl does become nasty, and has ten tools that vary
subtly, it doesn't mean that a careful teacher could keep his students from
falling prey to these pitfalls. (For instance, no map, grep, regex's, etc,
and if you want, don't tell them for and foreach are actually the same.. :) ).
Ciao,
Gryn
| [reply] |
|
|
|
|