Re: Great SWT Program

In article <1192343598.286690.43710@xxxxxxxxxxxxxxxxxxxxxxxxxxx>,
<bbound@xxxxxxxxx> wrote:
On Oct 13, 1:47 pm, blm...@xxxxxxxxxxxxx <blm...@xxxxxxxxxxxxx> wrote:
I think so -- if we're talking about people enrolled in a degree
program in computer science. In my opinion, the goal of such
programs should be to turn out people who know how to learn, not
people trained in today's hot languages/technologies/whatever.

It should be to teach people how to program, should it not?

Among other things. Not everyone getting a CS degree will ever do
serious software development after he/she leaves school, and even
those who do often end up doing something else after a few years.
The goal, as Patricia says in her excellent reply to your post,
is to help the students learn how to learn. I would add that
the goal of a CS degree in particular is to understand something
about how computing technology works, what's possible with it
currently, what its limitations are, and so forth. Part of that is
learning to program, but "how to program" isn't the whole picture.
"In my opinion", I guess, but I think this is a fairly common
opinion in the academic world. Of course we're known for being
a bit idealistic and ignorant of how things are in the so-called
real world.

Language-
independence I'm all for; teach them general algorithm, data
structure, OO, and such concepts, and generally-applicable debugging,
etc. techniques. Specific tools they should not have to learn -- since
there are plenty of tools that actually provide the ability to become
proficient with them simply by using them and getting more proficient
without having to pay a tutor or pay for books or anything anyway.

I don't see any real benefit to teaching them to use obsolete tools
with poor UI; it would have been unavoidable once, but these days they
will be able to use such nice tools as Eclipse or Netbeans or whatever
else; whatever they develop in tomorrow there will be suitable IDEs or
other tools, as well as general-purpose editors with Notepad-like
interfaces. I honestly don't see them getting much from either emacs
or vi save a bunch of "what not to do" usability lessons,

Well, if you believe that GUIs are the be-all and end-all of user
interfaces, that might be true. I'm not convinced they are -- I'm
not sure what the user interface of 2057 will be like, but I have
no trouble believing it will be as foreign to what we have now as
GUIs initially seemed to me. If one believes that maybe GUIs are
not the last word, it seems to me obvious that exposure to more
than one type of interface is a good thing, in making it clear that
there *is* more than one way to do things.

plus the
aforementioned "this is what we had to put up with back in the Dark
Ages before the invention of Super VGA" bit of history grounding so
they can thank their lucky stars that they get to program after the
invention of the equivalent of the light bulb instead of having to do
so by dim torchlight in the dark. ;)

Except, of course, that some of us actually *like* vi/emacs.

Exposing students to more than one language paradigm seems to me
to contribute to that. I believe this is a fairly common view
in academic CS circles.

The commonalities in things like debugging and that may indeed become
more apparent to students asked to program in two or three languages.
Especially fairly different ones. I'd suggest at minimum Java and
Smalltalk, or C++ and Smalltalk, plus a scripting language like Python
or Ruby. Smalltalk gives them pure OO and a bunch of interesting stuff
like closures used routinely. The scripting languages I mentioned and
Java are actually of practical use in the current IT workplace, as
well as providing a serious applications-programming language and an
interpreted language good for "glue code" use.

If there's room, a bit of exposure to something functional for *real*
different stuff, plus C for low-level bits and bytes and masks,
pointer arithmetic and pointer debugging stuff.

I'd rate exposure to different paradigms as more important than
exposure to different languages in the same paradigm. Again,
it might be a moot point if one believes that the OO paradigm
will, and should, continue to be the dominant one throughout
these students' careers. But I'm not convinced that's true. Do
I know what will be next? No, but neither am I convinced that
there won't be a next thing, and I think exposure to multiple
paradigms at an early stage is helpful in not getting too locked
into a particular mindset that might or might not still be useful
twenty years down the road.

This should help with
abstraction, and functional stuff may be useful to emulate in
application internals or processing scipties where side effects are
bad and avoidable and const-correctness is good and desirable. C will
both teach them the virtues of automatic garbage collection and
referential integrity and type-safety enforcement and strike a healthy
fear of ever using it again, while also instilling some understanding
of how one does the low-level stuff needed to implement the OS kernel
and the VM or interpreter of your choice so that you can wash your
hands of those icky pointer problems once and for all. ;)

[ snip ]

Well, let's take an example -- a mass deletion of files using
"rm". If you *want* to be asked, for every file, "are you sure?",
this behavior is readily available. If you don't want to be asked,
that behavior is available too.

And guess which is the default?

I have used Unix systems where some "helpful" administrator had
aliased "rm" to "rm -i".

[ snip ]

Well, you could type, from the command line, "gnuplot", whereupon
you get a screenful of text telling you how to access the online
help and giving the URL of a FAQ. Following the directions for
accessing the online help brings up something that tells you more
about how to use it.

Useful, if you have the luxury of a) a working net connection and b) a
working X session, so that gnuplot can be in a terminal window and you
can tab to a Firefox window and surf the web and google stuff with.

I guess I didn't make myself clear: The "online help" is built-in
and not connected, except in the sense of being about the same tool,
with the FAQ on the Web. The built-in online help does not require
a 'Net connection.

No doubt it's novice-unusable if presented outside of an Xterm, so a
full-screen console mode session stopping you having the help open
simultaneously with the app able to glance back and forth and even
navigate in both easily without losing your place in one whenever you
switch to the other.

Well, yeah, but gnuplot being a tool for drawing graphs, um,
wouldn't most people using it be doing so from an Xterm or other
terminal emulator? Even I usually start out using the thing
interactively and letting it show results in another (graphical)
window, before setting terminal type to "encapsulated postscript"
and sending results to a file.

Automatically / in principle, no. In practice, yes, I think so.
The old-time Unix philosophy emphasizes having lots of small
limited-purposes programs that interact by means of streams
of text, store configuration information in text files whose
locations are readily discoverable, etc.

I've never seen a traditional unix app that made *anything*'s location
"readily discoverable". :P

I guess you don't read man pages, then. Most of them have a section
called "FILES" at the end.

And that philosophy greatly limits what you can do, more or less
completely excluding any kind of audiovisual media from being
manipulated. It is perhaps suited to mail, news, resume-writing, and
programming, and surely suited to very little else.

True .... though now that I think about it, the data communicated
over a (Unix) pipe doesn't have to be ASCII text.

[ snip ]

Most GUIs I know of
don't seem to work like that. They do seem to have their own
kind of interoperability, for example transferring text and
other objects via a system clipboard. A "compare and contrast"
between that and interoperation based on streams of text might
be interesting but is beyond me right now.

Didn't it already happen elsewhere in this thread? :P

And I'm all for GUI tools that can be connected up in other ways as
well, as I also described in more detail elsewhere in this thread.

As far as I can remember, you've talked only about transferring
information via a system clipboard manually. I guess I'm
speculating, in a very vague way, about other kinds of interaction.
I'm not at all sure where I'm going with that, though; possibly
nowhere!

--
B. L. Massingill
ObDisclaimer: I don't speak for my employers; they return the favor.
.

Relevant Pages

  • Re: Responding to a challenge
    ... *Of course* I had in mind your advocacy of Esperanto. ... > consensus of linguists on the matters in question, but boringly so: ... opinion, ... or at least to compare across different languages. ...
    (sci.lang)
  • Re: Case sensitivity in programming languages.
    ... 30 years of case sensitive programming languages disagree with you. ... You're a loser, Tony. ... Your opinion is most definitely NOT held by the majority. ... And people like K & R have done a LOT more for programming than one Roedy Green. ...
    (comp.lang.php)
  • Re: Shall We All Leave At Once?
    ... And it also depends on which opinion you take - views on ... the period of origin of PIE vary by 6 millennia. ... Afro-Asiatic/Semitic languages can be traced back to before PIE was ... the source word raison looks a lot more like raisin ...
    (rec.arts.drwho)
  • Re: Shall We All Leave At Once?
    ... And it also depends on which opinion you take - views on ... the period of origin of PIE vary by 6 millennia. ... by the exercise of scholarly judgement and opinion. ... Afro-Asiatic/Semitic languages can be traced back to before PIE was ...
    (rec.arts.drwho)
  • Re: Shall We All Leave At Once?
    ... And it also depends on which opinion you take - views on ... the period of origin of PIE vary by 6 millennia. ... by the exercise of scholarly judgement and opinion. ... Afro-Asiatic/Semitic languages can be traced back to before PIE was ...
    (rec.arts.drwho)
Loading