Re: Great SWT Program

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? 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, 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. ;)

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

None of this is a good reason to expose them to the horrors of unix
text editors. ;) But as long as you don't require them to manage to
use them effectively or lose marks, I don't see a serious problem
there.

Perhaps I'm coming across as more partisan than I really am --
I *am* biased, but I know that, and .... Well, whatever. I think
I'm repeating myself here.

Indeed.

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? This is a particularly steep and tall
flight of stairs whose lights are on one of those oh-so-helpful energy
saving timers so they are never on when you go to use the steps. Of
course there's a switch somewhere, but you're liable to trip over
something and fall down the stairs while feeling around for the light
switch. And in this case it isn't even actually energy saving. :P

And sometimes elevators get stuck, trapping the occupants in a
state from which they can't recover without outside help, or --
well, there may be a way to get out of an elevator unassisted,
but I'm not sure most people would know how?

Usually there's a ceiling hatch and ladders in the shaft. There should
be an easy way to force the doors open -- with a hand crank, say.
Likely you could then crawl out onto one floor or another through
either the top or the bottom of the door space.

The more I think about it, the more I like this analogy. I'm not
a big fan of elevators either. Just a touch of claustrophobia ....

Well-lit stairwells AND elevators together in one place, maybe? ;)

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.

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.

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

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.

I'm all for using open and widely supported formats for everything --
text as ASCII, UTF-8, etc. and images in formats like JPEG and PNG,
with ogg video and audio say. Reducing this set to just "text as
ASCII" on the other hand is hugely limiting.

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.


.

Relevant Pages