Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

RE: Exposure to problem solving methods need not be limited in number.

by larsen (Parson)
on Aug 12, 2000 at 15:47 UTC ( [id://27620]=note: print w/replies, xml ) Need Help??

in reply to Exposure to problem solving methods need not be limited in number.
in thread Learning Programming

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 :).
  • Comment on RE: Exposure to problem solving methods need not be limited in number.

Replies are listed 'Best First'.
Structure = Easier?
by gryng (Hermit) on Aug 20, 2000 at 08:53 UTC
    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.. :) ).


      I use pseudo-code fairly often in big projects, especially when I'm facing a very hairy solution. When I run up against a sticky problem, I go for a walk or read or do something else until a solution presents itself.

      Then I have to rush back and write down (or type) enough to get the shape of the answer out of my head and somewhere I can refer to it later.

      It's a little like literate programming, perhaps, where the programmer mixes his design ideas with actual code. I'm not as strict as that (running a tangler preprocessor seems like a waste of my valuable time), but I do leave in comments where I need to put flesh on bare bones. When things work, then I take most of them out.

      Pseudo-code definitely has a place in my style... comments are for communication -- with myself, with other programmers. I'll use them whenever I can.

        Oh, well for large programs (which was not what I was writing for), I will draw big boxes and put labels and arrows, or do something so that I can understand what my data will look like and where it will go. I rarely put down anything about my code though, perhaps which type of algorithm I plan on using. Or in the case of something more custom, I'll detail that in pseudo code, (C-ish), or mostly correct/abbreviated perl.

        But as I said, I mainly concern myself with the data structures. As they say: "Show me your flow charts and I will continue to be confused, but let me see your data structures, then, aha!" -- I know, and so should most every programmer, the how to access most any data structure. The most important part of my program is choosing which one I'll use.

        Gosh, we all are good at continuing a nice flowing-topic converstation, no?


        -- It may say gryng but it's spelled Gryn :) --

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://27620]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others having an uproarious good time at the Monastery: (3)
As of 2024-06-15 16:16 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.