"... because common people think like so-and-so..."
Albert Lai
often the way ordinary humans think is cited. For example, some
opinions dismiss non-imperative programming "because people think in
terms of states", or non-object-oriented programming "because people
think in terms of manipulating objects".
I think this is all very well. Ordinary people also fear blood and
gore. Can you imagine an "opinion leader" in medical science saying
"never cut open the body of appendicitis patients because it would be
tough to doctors"? Medical treatments are assessed based on benefit
and harm to patients, not comfort of doctors. Medical students are
required to learn to face blood and gore, or quit.
The "natural" or "common" argument is never brought up in professions
such as medicine and surgery, law, accounting, and engineering
whenever there are debates over methodologies and training. It is not
ordinary people's nature to be rigorous, analytic, quantitative,
formal, rational, calm, objective, impartial, ... The professions do
not give in to human nature; quite on the contrary, apprentices are
trained for years against human nature, and those who fail to change
are weeded out.
There are professions and professional training because the way of
common people is deficient.
If common people can think of nothing other than states and objects,
perhaps programmers should grow out of it.
(Also posted at http://slashdot.org/~Albert%20Y.C.%20Lai/journal/83868
)
Dave Benjamin
> In debates over merits of programming paradigms, languages, and tools,
> often the way ordinary humans think is cited. For example, some
> opinions dismiss non-imperative programming "because people think in
> terms of states", or non-object-oriented programming "because people
> think in terms of manipulating objects".
>
>
> If common people can think of nothing other than states and objects,
> perhaps programmers should grow out of it.
I agree with your basic premise, but I also see programming as a form of
literacy, and in an ideal world, everyone should know how to program. So,
we need to distinguish between what's important to professional programmers
and what's important to non-professional programmers (or professional
non-programmers).
Also, to quote Alan Perlis, "A language that doesn't affect the way you
think about programming, is not worth knowing.". Languages, paradigms, and
tools all have the potential to teach us new ways of thinking. People may
*currently* only think in terms of manipulating state or objects (though I
think this is an overgeneralization), but they are *capable* of thinking
in lots of different ways, and I think this should be encouraged.
--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
"talking about music is like dancing about architecture."
cr88192
"Albert Lai" <tre...@shell.vex.net> wrote in message
news:4uhdpz9...@shell.vex.net...
> In debates over merits of programming paradigms, languages, and tools,
> often the way ordinary humans think is cited. For example, some
> opinions dismiss non-imperative programming "because people think in
> terms of states", or non-object-oriented programming "because people
> think in terms of manipulating objects".
>
radial distance type thing, you can pull some direction, and pull a little
more and eventually get somewhere, but if it is too weird people will
resist.
> I think this is all very well. Ordinary people also fear blood and
> gore. Can you imagine an "opinion leader" in medical science saying
> "never cut open the body of appendicitis patients because it would be
> tough to doctors"? Medical treatments are assessed based on benefit
> and harm to patients, not comfort of doctors. Medical students are
> required to learn to face blood and gore, or quit.
>
> The "natural" or "common" argument is never brought up in professions
> such as medicine and surgery, law, accounting, and engineering
> whenever there are debates over methodologies and training. It is not
> ordinary people's nature to be rigorous, analytic, quantitative,
> formal, rational, calm, objective, impartial, ... The professions do
> not give in to human nature; quite on the contrary, apprentices are
> trained for years against human nature, and those who fail to change
> are weeded out.
>
yes. in those jobs it makes more sense.
imo, programming is less one of those kind of fields, programming is about
as close as being an artist or writer as it is to being like law or
medicine, a lot is about who is using it, and for what purpose.
> There are professions and professional training because the way of
> common people is deficient.
>
yes, and the "common man" can't really motivate themselves to learn
programming. those that do usually have either a natural bias twards it or
some belief that it can be profitable for them.
> If common people can think of nothing other than states and objects,
> perhaps programmers should grow out of it.
>
> (Also posted at http://slashdot.org/~Albert%20Y.C.%20Lai/journal/83868
> )
this, however, is where I disagree. one needs more, not less, and what they
give up needs to be paid for in slightly more than full for what they lose.
eventually the cost of change becomes to great and things become set, but at
present things are far from this stage.
now, what really can giving them up pay them for their loss? not that much
at present, more pure forms of languages are often weak when it comes to
"general" problems, and some things are a little awkward if they don't fit
well.
that doesn't mean existing languages fit well either, but they fit
differently, thus a language that is different seems painfully awkward.
imo a fairly signifigant factor is "look and feel", if it is similar in this
respect one is more apt to change. a person is more willing to jump between
windows and mac than windows and linux, partly because windows and mac look
and feel more similar, though windows and linux work more similar.
much of computing and programming practice has been going from something
that has a look and feel to something else with a similar look and feel (or
failing that using metaphores), even if it doesn't make that much sense and
the system is completely different.
destructive operations may eventually go away, but not now. they are fairly
deeply entrenched in common languages, and will likely lift up to a point
where if and when they disappear it wont really be noticed that much.
imo "human nature" is as much a product of living as humans as it is a part
of humans themselves, likely a human living as a computer would have a very
different "nature", but it would be quite difficult for someone like us to
live like them or for them to live like us, the world would feel awkward and
alien in both cases.
however, "states and objects" is at present common to both.
now, math does not have these, but programming is about as close to math as
it is to operating a piece of industrial equitment...
or do I not have a point here?...
"look and feel" is quite often regarded as irrelevant. the relevance may not
exist practically, but it is fairly important to humans.
now, doctors have to learn to cut people open like programmers have to learn
to code, and mathematicians have to learn to solve equations. these are
themselves not in human nature, but are a "required" part of the skillset.
but all this may well be irrelevant.
Donn Cave
Albert Lai <tre...@shell.vex.net> wrote:
To follow up your example of the medical profession -- I'm not
close to anyone in that field, but from what I read -- only in
recent years has that profession started to question the value
of a grueling schedule for interns and other personnel who are
on call. My point is that it's possible that if we do things
differently than they do, we could be right in a few cases.
They've been saying "when you stagger into the examining room
after a week of inadequate sleep and little if any time away from
work, since you're a professional, you'll suck it up and be
rigorous, analytical and everything you've been trained to be."
We've been saying "when you have to write programs in a language
that seems to stand in the way of any straightforward solution
to normal computing problems (other than fibonacci series), since
you're a professional ..."
Or we've been saying "when you have to write programs in a language
like C where you have to keep track of allocated memory, since
you're a professional ..."
I'm really somewhat sympathetic to your point, but I also see
this as a convenient way to dismiss just about any problem --
both the problems FP has and the problems it solves.
As a programmer, I'm put at a disadvantage by a language that
is intractably alien the way I naturally conceive solutions to
normal problems, and that's just a bad direction.
I don't want to declare that pure functional programming actually
falls in that category, I'd like to think that its advocates are
right and it just takes some relearning. But either it works or
it doesn't. There's already a too much of a temptation to dismiss
problems related to programming domains --
FP advocate: FP is great for everything!
FP beginner: Not just mathematics, you can do graphics and everything?
FP advocate: Haskell is my favorite imperative language too!
FP beginner: OK, so I was thinking about how to write a simple
sshd in Haskell, and here're some problems I'm having ...
FP advocate: Well, you know, you have to pick the right tool for
the job, Haskell isn't intended to be the solution for
everything!
I'm a professional programmer. I can't use Haskell in my job for
professional reasons even if I were totally convinced for myself
that it would be a superior choice, and even in the same job where
I was deploying Python software in 1997 when it was pretty obscure.
I would like to see that change, but I'm not sure it's within the
realm of possibility for Haskell itself as it exists today, and it
will sure take an FP language development community that will
take on problems where they really exist and not laugh them off.
Donn Cave, do...@u.washington.edu
Tomasz Zielonka
> FP beginner: OK, so I was thinking about how to write a simple
> sshd in Haskell, and here're some problems I'm having ...
> FP advocate: Well, you know, you have to pick the right tool for
> the job, Haskell isn't intended to be the solution for
> everything!
I think Haskell would be an ideal implementation language for ssh. It
allows to program very close to mathematical specification, it has
built-in unbounded integers, and its implementations offers good Posix
interface and FFI mechanisms. Any particular reason you chose this
example?
Best regards,
Tom
--
.signature: Too many levels of symbolic links
Jonathan Bartlett
> In debates over merits of programming paradigms, languages, and tools,
> often the way ordinary humans think is cited. For example, some
> opinions dismiss non-imperative programming "because people think in
> terms of states", or non-object-oriented programming "because people
> think in terms of manipulating objects".
I don't disagree with you entirely, but one of the goals of a lot of
modern programming language design is to make thinking and programming
relatively equivalent.
Computer science is pretty unique because our instructions are both for
the computer and others. For example, a medical doctor's stitching
won't have to later be "interpretted" by someone else to figure out what
he was trying to do, in order to reverse engineer it for whatever
purpose. Most of that is relegated to the patient's chart. Thus, you
have two entities -- the patient (what is operated on) and the chart
(used for communication to other doctors).
In programming the patient and the chart are one and the same -- the
program. Therefore, what we do w/ our patient has to be readable for
other doctors to follow up behind us. Other professionals have to be
able to look at our unique creation and understand how it is put
together, how to modify it, and how it works with the outside world.
Therefore, choosing a language needs to fit into regular patterns of how
people think and learn.
That shouldn't be the only criterion, but it certainly shouldn't be
dismissed, either.
Jon
----
Learn to program using Linux assembly language
http://www.cafeshops.com/bartlettpublish.8640017
Boris Borcic
> In debates over merits of programming paradigms, languages, and tools,
> often the way ordinary humans think is cited. For example, some
> opinions dismiss non-imperative programming "because people think in
> terms of states", or non-object-oriented programming "because people
> think in terms of manipulating objects".
>
> I think this is all very well. Ordinary people also fear blood and
> gore. Can you imagine an "opinion leader" in medical science saying
> "never cut open the body of appendicitis patients because it would be
> tough to doctors"? Medical treatments are assessed based on benefit
> and harm to patients, not comfort of doctors. Medical students are
> required to learn to face blood and gore, or quit.
Well, the later argument kind of denies eg Turing equivalence by
analogy. I'd rather fight the issue on other grounds. If indeed
imperative oo programming reflects a spontaneous majority cognitive style
and stateless functional or logical programming a minority cognitive
style, then maybe it's possible to relate the majority cognitive
style to widespread political pathologies that government by the
minority cognitive style would avert, for instance.
Maybe the programming paradigm issues are just the tip of an
unexpected iceberg...
Donn Cave
Tomasz Zielonka <t.zie...@zodiac.mimuw.edu.pl> wrote:
> Donn Cave wrote:
> > FP beginner: OK, so I was thinking about how to write a simple
> > sshd in Haskell, and here're some problems I'm having ...
> > FP advocate: Well, you know, you have to pick the right tool for
> > the job, Haskell isn't intended to be the solution for
> > everything!
>
> I think Haskell would be an ideal implementation language for ssh. It
> allows to program very close to mathematical specification, it has
> built-in unbounded integers, and its implementations offers good Posix
> interface and FFI mechanisms. Any particular reason you chose this
> example?
A couple. To start with, I think think there's a chance you
could be right about that, and it would be a killer demonstration.
The openssh implementation, I believe currently the prevailing
one, goes to what seems to me to be a kind of ridiculous extreme
for fear of buffer over-run type attacks that might compromise
the server, it forks off a separate process and uses that for
some functions. The C programmer concedes defeat - we can't
deal with the memory allocation problems, so we have to minimize
exposure with gimmicks like this that can't be good for latency.
So we can't keep living like this, we need to get away from C
and learn how to write server software in languages that support
a safer, saner style of programming.
But I think it follows that a thin Haskell wrapper around some
OpenSSL cryptography and a bunch of other C modules isn't the
answer (though it would have to be a temporary expedient, because
there's an enormous amount of code there.) We'll have to be
rebuilding the OpenSSH sshd with the latest version of MIT Kerberos
(1.3.5) because of a memory allocation vulnerability, and Haskell
alternative that still calls MIT's krb5_rd_cred() function will
be no better off. This seems to be Java's approach - I believe
there's a Kerberos implemented in Java. Maybe in a few years
I'm going to be a Java programmer whether I like it or not.
I haven't written a line of code for an sshd, but I did once
sit down with a blowfish C implementation with the thought of
porting it to Haskell. I was looking at the MIT GSSAPI krb5
code yesterday to see if and when it would call krb5_rd_cred(),
and pondering what this code would look like in Haskell.
I have tried to use unbounded integers to replace OpenSSL
bignum arithmetic. Nothing here in the way of a serious
effort, at most casual attempts to plug the algorithms into
Haskell without the serious re-engineering that would really
be called for. (After all, I can't use it at work, and at home
I have only Hugs.) But enough to make me wonder. Is Haskell
intended to be the solution for any and all programming
problems, do you think? If not, could we move on to an FP
language that is?
Donn Cave, do...@u.washington.edu
Jerzy Karczmarczuk
> FP advocate: Haskell is my favorite imperative language too!
> FP beginner: OK, so I was thinking about how to write a simple
> sshd in Haskell, and here're some problems I'm having ...
> FP advocate: Well, you know, you have to pick the right tool for
> the job, Haskell isn't intended to be the solution for
> everything!
>
> I'm a professional programmer. ...
Mhm.
And that's why you consider that the first thing which a beginner will
try to do is to write a sshd.
Very inspiring vision.
OK, you would answer "not a beginner, just a FP beginner!"
So, I tell you: a professional *conditioned* programmer will have
problems similar to a sportsman who more or less suddenly, having
already an experience (physical and mental) say, in tennis,
decide to become a high-level swimmer. My best wishes.
The example is silly, such a person won't complain that swimming is
not suitable in general.
... Later:
> Is Haskell
> intended to be the solution for any and all programming
> problems, do you think? If not, could we move on to an FP
> language that is?
Before I suspected that you were slightly joking. Now I am sure.
Jerzy Karczmarczuk
Torben Ægidius Mogensen
> In debates over merits of programming paradigms, languages, and tools,
> often the way ordinary humans think is cited. For example, some
> opinions dismiss non-imperative programming "because people think in
> terms of states", or non-object-oriented programming "because people
> think in terms of manipulating objects".
Well, you can argue that the world is stateful, and the concept of an
action altering state is natural, but people are used to manipulate
state themselves, not telling in unambiguos terms someone else to do
it while on their own. Just ask someone to describe in words how to
do an everyday task, and you will see how badly people do at this.
Hence, I don't think people's experience in manipulating state carries
over to programming in stateful languages.
And I don't buy the "use OO because people are used to handling
objects" at all, as the main thing objects in OO programming shares
with "real life" objects is the name. Real life objects do not come
equipped with built-in methods that are the only means of interacting
with them.
There is an unfortunate tendency in CS that when someone names a
concept after something that is vaguely similar, people put too much
significance into the name and carries the analogy too far. See [1]
for a treaty on this (in AI, but the idea carries over to programming
paradigms).
There is an, unrelated, trend these says to use "oriented" about
programming styles, i.e., "object oriented", "aspect oriented", etc.
When I recently gave a talk in a software company about
domain-specific languages, the presenter introduced it as being about
"domain-oriented languages". Fritz Henglein has recently begun using
the term "value oriented" about functional programming, partly to get
away from the reputation for mathematical nerdiness and partly to
emphasize the statelessness over the use of higher-order functions.
This may be a good way of selling FP, as it sounds more familiar to
managers and "value" certainly has a positive connotation.
Torben
[1] McDermott, D. Artificial Intelligence Meets Natural Stupidity. In
Mind Design: Philosophy, Psychology, Artificial Intelligence
(ed. J. Haugeland). Cambridge, MA: MIT Press, 1981.
Peter G. Hancock
>>>>> Torben wrote (on Fri, 17 Sep 2004 at 09:26):
> There is an, unrelated, trend these says to use "oriented" about
> programming styles, i.e., "object oriented", "aspect oriented", etc.
Right! I have noticed the trio:
-oriented
-based
-structured
Sometimes people make subtle and sophistical distinctions between
these suffices. (Sheer woffle, usually.)
> Fritz Henglein has recently begun using the term "value
> oriented" about functional programming, partly to get away from
> the reputation for mathematical nerdiness and partly to
> emphasize the statelessness over the use of higher-order
> functions.
That's brilliant! It manages to carry the connotation "business
oriented" as in "value for money" etc.
It's interesting we use the same word "value" for mathematical and
monetary (and ethical) values.
Peter Hancock
Matthias Blume
> [...] Fritz Henglein has recently begun using
> the term "value oriented" about functional programming, partly to get
> away from the reputation for mathematical nerdiness and partly to
> emphasize the statelessness over the use of higher-order functions.
> [...]
I wonder who actually "invented" this phrase. I heard Andrew Appel
use it more than 10 years ago...
Matthias
Donn Cave
Jerzy Karczmarczuk <kar...@info.unicaen.fr> wrote:
> Donn Cave wrote:
>
> > FP advocate: Haskell is my favorite imperative language too!
> > FP beginner: OK, so I was thinking about how to write a simple
> > sshd in Haskell, and here're some problems I'm having ...
> > FP advocate: Well, you know, you have to pick the right tool for
> > the job, Haskell isn't intended to be the solution for
> > everything!
> >
> > I'm a professional programmer. ...
>
> Mhm.
> And that's why you consider that the first thing which a beginner will
> try to do is to write a sshd.
> Very inspiring vision.
>
> OK, you would answer "not a beginner, just a FP beginner!"
>
> So, I tell you: a professional *conditioned* programmer will have
> problems similar to a sportsman who more or less suddenly, having
> already an experience (physical and mental) say, in tennis,
> decide to become a high-level swimmer. My best wishes.
> The example is silly, such a person won't complain that swimming is
> not suitable in general.
I don't know if I would actually try to write sshd, but
I would be deterred less by my ignorance of Haskell than
by my ignorance of the cryptography, because I'm more
interested in the former than the latter. If sshd is a
project that requires Haskell sophistication, then what
better way to acquire it? Recall that I am constrained
to use Haskell only for personal off hours projects.
But more realistically, I do see programming languages as a
way for me to make programs that are in some respects like
sshd, so that's the context in which I look at a language.
If the language is awkward and frustrating in the beginning,
that's no great problem. What is indeed a problem, is if
people who are evidently experts in the language see it as
really suited to a narrow range of problems that excludes
the large range of applications where C and C++ are currently
so prevalent and so problematic. Take a word processor for
another example, or a web browser. I don't expect anyone
to give me credit for sanity if I announced that I was starting
to write a word processor in Haskell, but I would hope not
to hear that any sane person would choose another language
for that attempt, if you see the difference.
> ... Later:
>
> > Is Haskell
> > intended to be the solution for any and all programming
> > problems, do you think? If not, could we move on to an FP
> > language that is?
>
> Before I suspected that you were slightly joking. Now I am sure.
Not at all, but I have to apologize for some hastily conceived
wording there. I really meant the domain of problems that, say,
a Java programmer might entertain, which is of course really a
lot smaller than `all programming problems.'
I find the programming principles represented by Haskell attractive,
maybe promising, but I can't really use it today, and will never
be able to use it unless something changes, and I don't think that
something is people's willingness to learn an ostensibly unnatural
paradigm.
Donn Cave, do...@u.washington.edu
Daniel C. Wang
I suspect the origins are quite old.. and perhaps related to the epigram by
Perlis..
A LISP programmer knows the value of everything, but the cost of nothing
-- Allan J. Perlis
Christian Szegedy
> I find the programming principles represented by Haskell attractive,
> maybe promising, but I can't really use it today, and will never
> be able to use it unless something changes, and I don't think that
> something is people's willingness to learn an ostensibly unnatural
> paradigm.
I think you are right. Naturalness is a very relative thing.
What's natural to me now, could have been extremely unnatural
to me three years ago and could have been natural 15 years
ago.
Although, I hope to believe that I am open minded, I thought
three years ago, that functional programming is some kind
of masturbation for bored language designers.
Now, my most productive programming environment is OCaml,
and find Haskell the most elegant language I have ever seen.
(Although I use Haskell fairly rarely)
So I think that the original poster completely misses the
point: there is nothing more natural about mutable state
than referential transparency, and it does not take an expert
to learn that. We should not pretend that functional programming
is something great, efficient and *unnatural*, but worth learning.
For me, it is moderately great, and fits my thinking very
naturally and worth leaning *because* it helps coding more
naturally, not vica-versa.
In fact, programming at all is not *natural* for most people
apriori. I remember a friend of my from highschool to whom I
tried to teach C64 BASIC and started with variable assignment.
It was a great confusion: how does it come that A is sometime
1, next time 2. Why is it called A, if it always different?
Once you get the idea, it becomes natural. Assigning different
states to variables becomes so obvious that 10 years later
you have completely forgot, that it is not natural at all.
Or at least, it is not *more* natural than the other way round.
It is all habit, that's it.
Michael J. Fromberger
Tomasz Zielonka <t.zie...@zodiac.mimuw.edu.pl> wrote:
> Donn Cave wrote:
> > FP beginner: OK, so I was thinking about how to write a simple
> > sshd in Haskell, and here're some problems I'm having ...
> > FP advocate: Well, you know, you have to pick the right tool for
> > the job, Haskell isn't intended to be the solution for
> > everything!
>
> I think Haskell would be an ideal implementation language for ssh. It
> allows to program very close to mathematical specification, it has
> built-in unbounded integers, and its implementations offers good Posix
> interface and FFI mechanisms. Any particular reason you chose this
> example?
I should think the hard part of implementing the OpenSSH protocol in
Haskell would not be the large-integer arithmetic, but rather the
complex I/O and binary data manipulations that need to be performed
efficiently: dealing with compression and symmetric encryption,
handling user input for passphrases, loading keys, etc.
On the other hand, I am not a very experienced Haskell programmer, so
perhaps these are not as troublesome in Haskell as they seem to be from
my perspective.
-M
--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA
Tomasz Zielonka
>
> I should think the hard part of implementing the OpenSSH protocol in
> Haskell would not be the large-integer arithmetic, but rather the
> complex I/O and binary data manipulations that need to be performed
> efficiently: dealing with compression and symmetric encryption,
> handling user input for passphrases, loading keys, etc.
Doing I/O in Haskell is quite easy. I have good experience in making
programs that read / write (and interpret) binary data, or that do
massive network IO (eg. I have written a prototype DNS resolver library
in Haskell). Most compilers support unboxed arrays which can be used for
reading and writing (efficiently) from Handles.
One could use C routines via FFI for compression and encryption, but
that could be considered cheating and it would reduce safety guarantees
coming from implementing the whole thing in a safe language. I guess
that if you reimplemented everything in Haskell, you would have trouble
to get the same performance as in C. But you should first ask yourself,
what is your primary goal: security or speed? Anyway, I don't think
that speed of HaskellSSH must be that bad.
BTW, I don't believe that Haskell's safety would automatically solve all
security problems. AFAICS, many of security problems with ssh did't
originate from buffer overruns but from subtle errors in program logic.
I think that high-level language like Haskell could help in preventing
such errors by taking care of low-level aspects, allowing to concentrate
on high-level ones, providing better abstraction facilities and allowing
to program close to specification.
Besides, we can't claim that Haskell's safety gives any security
guarantees until we have verified implementations.
Torben Ægidius Mogensen
> But more realistically, I do see programming languages as a
> way for me to make programs that are in some respects like
> sshd, so that's the context in which I look at a language.
> If the language is awkward and frustrating in the beginning,
> that's no great problem. What is indeed a problem, is if
> people who are evidently experts in the language see it as
> really suited to a narrow range of problems that excludes
> the large range of applications where C and C++ are currently
> so prevalent and so problematic. Take a word processor for
> another example, or a web browser. I don't expect anyone
> to give me credit for sanity if I announced that I was starting
> to write a word processor in Haskell, but I would hope not
> to hear that any sane person would choose another language
> for that attempt, if you see the difference.
I don't see why you wouldn't do tis in Haskell. Using a pure
functional language for a word processor will give you unlimited undo
facility nearly for free, as the data structures you use are almost
inherently persistent. I'm more worried about space leaks caused by
excessive laziness, but the need to display the text may force
sufficient evaluation that this isn't a problem.
As for web browsers, at least one has been written in Haskell. AFAIK,
it has not been maintained for a decade, though, so it would seem very
primitive by today's standards.
Torben
Joachim Durchholz
>
> I agree with your basic premise, but I also see programming as a form
> of literacy,
It is... but that's beside the point.
> and in an ideal world, everyone should know how to program.
In an ideal world, everybody whould be able to build a house, repair a
car, or do a painting.
This world isn't ideal. And I don't think that striving for ideals is
necessarily a Good Thing (in fact some of the more forceful attempts of
attaining an ideal have cause havoc and grief without an end, just take
a look at the history of Communism or Christianism - both
well-intentioned, and both soon diverted from their original intents and
badly abused).
> So, we need to distinguish between what's important to professional
> programmers and what's important to non-professional programmers (or
> professional non-programmers).
You have a point here.
There are lots of "home carpenters" and other hobby tinkerers out there.
(They also get sold a lot of crappy tools... that isn't very different
from the programming world, I realize now...)
> Also, to quote Alan Perlis, "A language that doesn't affect the way
> you think about programming, is not worth knowing.".
That's from the professional camp.
I'm unconvinced that professional and semiprofessional approaches need
to have that much in common. Semiprofessional programmers don't want to
learn thinking, or thinking in a new way, nor is there any need for them
- they want some job done quickly (and getting it done "quickly"
precisely excludes paradigm shifts).
> People may *currently* only think in terms of manipulating state or
> objects (though I think this is an overgeneralization), but they are
> *capable* of thinking in lots of different ways, and I think this
> should be encouraged.
I agree with that.
However, the "pure" FPLs don't just "encourage" one to think
differently. They *force* the programmer to do so.
Which is OK for those who plan to really, really learn the new paradigm.
It's not OK for semiprofessionals. They are less than interested in new
paradigms, or new ways of solving problems (actually they already know
how to solve it, or they'd hand the problem over to a professional);
they just want the d**n thing up and running within the day.
Regards,
Jo
Joachim Durchholz
> But you should first ask yourself, what is your primary goal:
> security or speed? Anyway, I don't think that speed of HaskellSSH
> must be that bad.
Actually an SSH implementation need not be overly fast. Any limits are
usually in the network bandwidth and latency.
(Things are a bit different for HTTP servers, particularly if they are
loaded with interpreters like PHP. In that case, CPU and memory load
become a real concern. SSH in itself just isn't an important part of
today's workload mix.)
> BTW, I don't believe that Haskell's safety would automatically solve
> all security problems. AFAICS, many of security problems with ssh
> did't originate from buffer overruns but from subtle errors in
> program logic.
Which, on the other hand, would be something in which a functional
language would excel.
Not so much because it would avoid all the errors, but because it's
easier to track down the problem, easier to fix it, and easier to be
confident that the fix doesn't introduce new problems.
> Besides, we can't claim that Haskell's safety gives any security
> guarantees until we have verified implementations.
Neither can the imperative people - their compilers are just as
unverified as the Haskell compilers.
It's not a game of guarantees, it's a game of having a good incidence
statistics.
Regards,
Jo
Donn Cave
Tomasz Zielonka <t.zie...@zodiac.mimuw.edu.pl> wrote:
> Doing I/O in Haskell is quite easy. I have good experience in making
> programs that read / write (and interpret) binary data, or that do
> massive network IO (eg. I have written a prototype DNS resolver library
> in Haskell). Most compilers support unboxed arrays which can be used for
> reading and writing (efficiently) from Handles.
That sounds good. Any support for dispatching off multiple
I/O streams? sshd creates a pseudotty device, a two way
pipe that responds to tty ioctls on one end, and has to be
responsive to both that and the network socket to the client,
byte by byte. I don't right off find any mention of a select()
function binding. Of course that could be added. But you
wouldn't want to deal with Handles there, rather the unbuffered
raw UNIX file descriptors, I think.
> One could use C routines via FFI for compression and encryption, but
> that could be considered cheating and it would reduce safety guarantees
> coming from implementing the whole thing in a safe language. I guess
> that if you reimplemented everything in Haskell, you would have trouble
> to get the same performance as in C. But you should first ask yourself,
> what is your primary goal: security or speed? Anyway, I don't think
> that speed of HaskellSSH must be that bad.
That's part of the appeal of FP, I think, a "have your cake and
eat it too" potential - it can be efficient. Even when what we
really need is a more efficient development process that turns
out more reliable software, when the software also turns out to
be fast it's ever so much better.
> BTW, I don't believe that Haskell's safety would automatically solve all
> security problems. AFAICS, many of security problems with ssh did't
> originate from buffer overruns but from subtle errors in program logic.
> I think that high-level language like Haskell could help in preventing
> such errors by taking care of low-level aspects, allowing to concentrate
> on high-level ones, providing better abstraction facilities and allowing
> to program close to specification.
>
> Besides, we can't claim that Haskell's safety gives any security
> guarantees until we have verified implementations.
I'm sure you're right, but problems with memory allocation are
certainly a significant issue. I'm more familiar with Kerberos,
where buffer overruns really have been most of the problem. I
didn't mean to propose that Haskell would be a solution because
of the type of correctness I think you're referring to, rather
buffer overruns are just so much less likely when storage is
managed as it is in Haskell - or any one of a number of other
modern languages.
Donn Cave, do...@u.washington.edu
Marcin 'Qrczak' Kowalczyk
>> Doing I/O in Haskell is quite easy. I have good experience in making
>> programs that read / write (and interpret) binary data, or that do
>> massive network IO (eg. I have written a prototype DNS resolver library
>> in Haskell). Most compilers support unboxed arrays which can be used for
>> reading and writing (efficiently) from Handles.
>
> That sounds good. Any support for dispatching off multiple
> I/O streams?
Threads. In GHC they are quite lightweight.
If events from multiple I/O streams are to be merged, they may be
communicated to another thread via Chan type (thread-aware queue).
> But you wouldn't want to deal with Handles there, rather the
> unbuffered raw UNIX file descriptors, I think.
Why? Handles may be unbuffered too.
Binary I/O interface is not nice though, uses C pointers and it's
non-standard.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Tomasz Zielonka
> In article <slrncknrlr.v...@zodiac.mimuw.edu.pl>,
> Tomasz Zielonka <t.zie...@zodiac.mimuw.edu.pl> wrote:
>
> That sounds good. Any support for dispatching off multiple
> I/O streams?
That's outside of standard Haskell 98 scope, so I will comment only for
GHC compiler, which is what I use. The standard way to deal with this in
GHC is to use Concurrent Haskell facilities. GHC implements concurrency
on user level, that is, all Haskell threads are run in one OS process.
GHC's runtime handles simultaneous IO requests using select() (or a
similar system call). This is done transparently behind the scenes. I
think it is very clear and elegant, and also quite efficient.
> sshd creates a pseudotty device, a two way
> pipe that responds to tty ioctls on one end, and has to be
> responsive to both that and the network socket to the client,
> byte by byte.
I am not sure about those ioctls, but if you can integrate them in
select() multiplexing, then you should be able to integrate them with
GHC's concurrency.
In this case you would have to create four threads:
- writing to a tty
- reading from a tty
- writing to a socket
- reading from a socket
and probably at least one thread managing the whole business.
> I don't right off find any mention of a select()
> function binding. Of course that could be added.
Yes, but this could clash with Concurrent Haskell. But as you can see,
there is no need for that, at least in this simple case.
> But you wouldn't want to deal with Handles there, rather the
> unbuffered raw UNIX file descriptors, I think.
No problem. The Network.Socket module offers send and recv functions
with concurrency support.
> That's part of the appeal of FP, I think, a "have your cake and
> eat it too" potential - it can be efficient. Even when what we
> really need is a more efficient development process that turns
> out more reliable software, when the software also turns out to
> be fast it's ever so much better.
Yes, at least it proved so for me a couple of times.
>> BTW, I don't believe that Haskell's safety would automatically solve all
>> security problems. AFAICS, many of security problems with ssh did't
>> originate from buffer overruns but from subtle errors in program logic.
>
> I'm sure you're right, but problems with memory allocation are
> certainly a significant issue. I'm more familiar with Kerberos,
> where buffer overruns really have been most of the problem.
I must admit that I know almost nothing about ssh, ssl and kerberos
internals, so this was just a guess based on a quick glance on openssh
bug report list.
Donn Cave
Marcin 'Qrczak' Kowalczyk <qrc...@knm.org.pl> wrote:
> Donn Cave <do...@u.washington.edu> writes:
>
> >> Doing I/O in Haskell is quite easy. I have good experience in making
> >> programs that read / write (and interpret) binary data, or that do
> >> massive network IO (eg. I have written a prototype DNS resolver library
> >> in Haskell). Most compilers support unboxed arrays which can be used for
> >> reading and writing (efficiently) from Handles.
> >
> > That sounds good. Any support for dispatching off multiple
> > I/O streams?
>
> Threads. In GHC they are quite lightweight.
>
> If events from multiple I/O streams are to be merged, they may be
> communicated to another thread via Chan type (thread-aware queue).
Then don't you get into a situation where a thread has to
respond to either an I/O event, or a message queued from
another thread? Does GHC's thread model support these
Chan messages at a low enough level that the thread can
unblock and handle the message?
Of course if I could choose, I am more interested in the
O'Haskell reactive object system, which is somewhat like
lightweight threads - but it's based on select().
> > But you wouldn't want to deal with Handles there, rather the
> > unbuffered raw UNIX file descriptors, I think.
>
> Why? Handles may be unbuffered too.
>
> Binary I/O interface is not nice though, uses C pointers and it's
> non-standard.
Well, I guess it depends on the API. If an unbuffered Handle
acts like a UNIX file descriptor, then of course there's no
problem. I have struggled a little with Haskell I/O and can't
say for sure what the case may be here, but the C library's
stdio buffered I/O is not entirely able to act like a file
descriptor, because for example its API says fgets() shall
return a line. When unbuffered, and reading from a "slow device"
like a socket or pty, fgets() must read one byte at a time to
avoid reading past the line boundary, which is not something
I would like to do as a routine practice because it's terribly
inefficient (too many system I/Os.) And in the end, the point
of the stdio functions is entirely defeated if there's no
buffering. Maybe this isn't true of Handles.
I don't understand what you mean by binary I/O. I only know
this term in the context of Microsoft platforms, where I understand
"text" input is converted between CRLF and LF formats, and "binary"
isn't converted. On UNIX there is no difference.
Donn Cave, do...@u.washington.edu
Marcin 'Qrczak' Kowalczyk
>> If events from multiple I/O streams are to be merged, they may be
>> communicated to another thread via Chan type (thread-aware queue).
>
> Then don't you get into a situation where a thread has to
> respond to either an I/O event, or a message queued from
> another thread? Does GHC's thread model support these
> Chan messages at a low enough level that the thread can
> unblock and handle the message?
In general you can multiplex anything by creating a suitable channel,
for each data source creating a thread which puts suitably tagged
messages in the channel, and one thread which reads the channel.
Or if one of the sources is another channel you designed, just encode
the I/O events as another kind of message in the channel.
> Of course if I could choose, I am more interested in the
> O'Haskell reactive object system, which is somewhat like
> lightweight threads - but it's based on select().
GHC's implementation *is* based on select() (or poll(), or
WaitForMultipleObjects on Windows I guess). But it looks like
threads for the programmer.
> I don't understand what you mean by binary I/O.
Reading/writing blocks of bytes in a portable way, without line ending
conversion for any platform, without character recoding when it's
implemented for text files (it's not done yet), and preferably
representing data in some more compact format than a list of bytes so
it can be passed in bulk to another file without the overhead.
Adrian Hey
> Then don't you get into a situation where a thread has to
> respond to either an I/O event, or a message queued from
> another thread? Does GHC's thread model support these
> Chan messages at a low enough level that the thread can
> unblock and handle the message?
>
> Of course if I could choose, I am more interested in the
> O'Haskell reactive object system, which is somewhat like
> lightweight threads - but it's based on select().
I think you should look another at concurrent Haskell.
It provides a very useful set of primitives.
By "primitive" I mean it's agnostic about higher level concurrency
abstractions (such as O'Haskell). The idea is you write your own to
suit your needs in Haskell (e.g. HTk event handling). I don't mean
it's "primitive" in the sense that it limits what you can do.
IIRC Johan Nordlander showed how to implement O'Haskell in concurrent
Haskell and vice-versa. So it would seem they're essentially equivalent
in power, though O'Haskells language extensions probably make using the
reactive object abstraction a little simpler to use in practice.
Regards
--
Adrian Hey
Donn Cave
Adrian Hey <ah...@NoSpicedHam.iee.org> wrote:
It's interesting, will have to look into it if I ever get
some spare time and GHC in the same place. The kicker is
that real OS threads are supported, which to me is where
you start getting concurrency - though I gather this isn't
at all central to Concurrent Haskell, but rather a sort of
tangent development.
It does seem like there would have to be something like
ohugs' select() dispatcher inside the GHC system, to keep
track of the blocking I/O calls that are waiting to be
scheduled when ready. I'm guessing that HTk support is
easy in that system because the I/Os happen on an X11 socket.
Don't spend a lot of time tracking this down, but do you
happen to know, whether the (I guess hypothetical) dispatcher
supports any other, non-select()able types of I/O events?
Anyway, the key issue for me is how much harder it is to
reason about a program when it has multiple threads, and
it seems at least plausible that Concurrent Haskell would
be worth a look despite experience with other languages.
But I think that's also the point of O'Haskell - a way to
reason about that kind of event-driven serial concurrency.
Donn Cave, do...@u.washington.edu
Adrian Hey
> It's interesting, will have to look into it if I ever get
> some spare time and GHC in the same place. The kicker is
> that real OS threads are supported, which to me is where
> you start getting concurrency - though I gather this isn't
> at all central to Concurrent Haskell, but rather a sort of
> tangent development.
ghc has had support for forking new OS threads added fairly
recently (forkOS), though I've never had cause to use this.
I believe the main reason for this is compatibility with
some libraries that make use of (OS) "thread local state".
> It does seem like there would have to be something like
> ohugs' select() dispatcher inside the GHC system, to keep
> track of the blocking I/O calls that are waiting to be
> scheduled when ready. I'm guessing that HTk support is
> easy in that system because the I/Os happen on an X11 socket.
> Don't spend a lot of time tracking this down, but do you
> happen to know, whether the (I guess hypothetical) dispatcher
> supports any other, non-select()able types of I/O events?
Nope, 'fraid not. (In fact, to be honest, I don't understand
the question:-).
Also, I'm not sure why you regard supporting OS threads as where you
start getting concurrency. What's so special about OS threads?
AFAICS the only special thing OS threads provide is an expensive
means to achieve a limited form concurrency for progs written in
languages which have no concurrency support built in to their
rts (such as C).
Regards
--
Adrian Hey
Aaron Denney
> Also, I'm not sure why you regard supporting OS threads as where you
> start getting concurrency. What's so special about OS threads?
> AFAICS the only special thing OS threads provide is an expensive
> means to achieve a limited form concurrency for progs written in
> languages which have no concurrency support built in to their
> rts (such as C).
They also let one program be run on multiple processors simultaneously
on SMP machines.
--
Aaron Denney
-><-
Dave Benjamin
> Dave Benjamin wrote:
>>
>> I agree with your basic premise, but I also see programming as a form
>> of literacy,
>
> It is... but that's beside the point.
I should have said, "... a form of literacy of similar importance to
reading, writing, arithmetic." I think that programming in some form will be
a basic, essential life skill. I could be wrong, but I think that the point
is still relevant.
>> and in an ideal world, everyone should know how to program.
>
> In an ideal world, everybody whould be able to build a house, repair a
> car, or do a painting.
In an ideal world, everybody should be able to read and write.
> This world isn't ideal. And I don't think that striving for ideals is
> necessarily a Good Thing (in fact some of the more forceful attempts of
> attaining an ideal have cause havoc and grief without an end, just take
> a look at the history of Communism or Christianism - both
> well-intentioned, and both soon diverted from their original intents and
> badly abused).
Well, I wouldn't worry about it too much. I'm quite convinced of your
high level of programming literacy, so you will surely be spared in the
first round of killings. ;)
>> So, we need to distinguish between what's important to professional
>> programmers and what's important to non-professional programmers (or
>> professional non-programmers).
>
> You have a point here.
> There are lots of "home carpenters" and other hobby tinkerers out there.
> (They also get sold a lot of crappy tools... that isn't very different
> from the programming world, I realize now...)
And just as professional writers need higher standards, more sophisticated
language, and more theoretical foundation, we all have to write from time to
time, and we all ought to be able to learn that skill. I believe that
functional programming is in many cases a superior method, but if it is
difficult to reach younger programmers (for instance), I'd certainly be open
to other approaches that might accelerate their learning. I guess it's sort
of like the "phonics" controversy.
>> Also, to quote Alan Perlis, "A language that doesn't affect the way
>> you think about programming, is not worth knowing.".
>
> That's from the professional camp.
> I'm unconvinced that professional and semiprofessional approaches need
> to have that much in common. Semiprofessional programmers don't want to
> learn thinking, or thinking in a new way, nor is there any need for them
> - they want some job done quickly (and getting it done "quickly"
> precisely excludes paradigm shifts).
That's probably true. I see this as partially symptomatic of a more general
problem: a lack of interest in learning. But I think we're basically in
agreement here.
>> People may *currently* only think in terms of manipulating state or
>> objects (though I think this is an overgeneralization), but they are
>> *capable* of thinking in lots of different ways, and I think this
>> should be encouraged.
>
> I agree with that.
> However, the "pure" FPLs don't just "encourage" one to think
> differently. They *force* the programmer to do so.
> Which is OK for those who plan to really, really learn the new paradigm.
> It's not OK for semiprofessionals. They are less than interested in new
> paradigms, or new ways of solving problems (actually they already know
> how to solve it, or they'd hand the problem over to a professional);
> they just want the d**n thing up and running within the day.
Yes indeed. =)
--
.:[ dave benjamin: ramen/[sp00] -:- spoomusic.com -:- ramenfest.com ]:.
"talking about music is like dancing about architecture."
Donn Cave
Yes. I may be a little weak on the terminology, but to
me "concurrent" suggests "simultaneous", and inherently
serialized concurrency is sort of an oxymoron.
I know higher level languages that support OS threads
don't necessarily always fully support SMP, due to
internal data structures that are shared between threads
and have to be protected by a big lock. Python is that
way, I believe ocaml is that way. But foreign functions
run free of that lock, so computation can proceed in
multiple threads, including at most one HLL thread.
The OS thread scheduler manages all these threads
irrespective of where the code came from. (That seems
like it would be a problem with RTS thread implementations,
which I think would kind of lose control to a foreign
function.)
I'm actually interested in OS threads mostly because
of external environments where they play an integral
role and there isn't any choice but to use them.
Personally I think concurrency brings along enough
problems that it's kind of a scary solution -- so
the example of an sshd implemented with threads was
a little horrifying. But that's from the perspective
of OS threads, in an imperative language. I sometimes
get the impression that enough people have come to
have that same horror of threads that we aren't going
to see lots more of these OS thread based application
environments.
Donn Cave, do...@u.washington.edu
Tomasz Zielonka
>> They also let one program be run on multiple processors simultaneously
>> on SMP machines.
>
> Yes. I may be a little weak on the terminology, but to
> me "concurrent" suggests "simultaneous", and inherently
> serialized concurrency is sort of an oxymoron.
You are talking about parallel computing. Concurrency doesn't need
multiple processors.
> I'm actually interested in OS threads mostly because
> of external environments where they play an integral
> role and there isn't any choice but to use them.
> Personally I think concurrency brings along enough
> problems that it's kind of a scary solution -- so
> the example of an sshd implemented with threads was
> a little horrifying.
Concurrent Haskell is quite different than, say, C pthreads. Haskell
threads are more like processes - sharing of mutable variables is
explicit, sharing of immutable data doesn't hurt. Also, the concurrency
primitives are much simpler and safer.
Glynn Clements
Donn Cave <do...@u.washington.edu> writes:
> Well, I guess it depends on the API. If an unbuffered Handle
> acts like a UNIX file descriptor, then of course there's no
> problem. I have struggled a little with Haskell I/O and can't
> say for sure what the case may be here, but the C library's
> stdio buffered I/O is not entirely able to act like a file
> descriptor, because for example its API says fgets() shall
> return a line. When unbuffered, and reading from a "slow device"
> like a socket or pty, fgets() must read one byte at a time to
> avoid reading past the line boundary,
In that situation, the stdio functions take whatever data is available
from the descriptor. Anything which isn't returned by the function
call (e.g. in the case of fgets, anything after the first newline)
stays in the buffer for later use.
This is why mixing stdio and Posix I/O is problematic.
> I don't understand what you mean by binary I/O. I only know
> this term in the context of Microsoft platforms, where I understand
> "text" input is converted between CRLF and LF formats, and "binary"
> isn't converted. On UNIX there is no difference.
The Haskell98 I/O functions deal in "Char"s (wide characters). Exactly
how the bytes get converted to/from Chars is unspecified. To read or
write *bytes* requires one of:
1. Relying upon the fact that GHC is hardwired to ISO-8859-1 (so you
can use ord/chr and fromIntegral to convert Word8<->Char).
2. Using the GHC-specific functions:
hPutBuf, -- :: Handle -> Ptr a -> Int -> IO ()
hGetBuf, -- :: Handle -> Ptr a -> Int -> IO Int
hPutBufNonBlocking, -- :: Handle -> Ptr a -> Int -> IO Int
hGetBufNonBlocking, -- :: Handle -> Ptr a -> Int -> IO Int
3. Using the FFI to create your own low-level bindings to the OS API.
For more details, refer to the recent "discussion" on the haskell-cafe
mailing list.
--
Glynn Clements <glynn.c...@virgin.net>
Aaron Denney
> Donn Cave wrote:
>>> They also let one program be run on multiple processors simultaneously
>>> on SMP machines.
>>
>> Yes. I may be a little weak on the terminology, but to
>> me "concurrent" suggests "simultaneous", and inherently
>> serialized concurrency is sort of an oxymoron.
>
> You are talking about parallel computing. Concurrency doesn't need
> multiple processors.
No, it's a valuable technique for structuring programs. Yet it is nice
when it can take advantage of parallelism, which either requires support
for OS threads, or multiple interacting processes. I actually prefer
the latter when writing in something like C, as one has to be more
explicit about what is shared.
Adrian Hey
> On 2004-09-22, Tomasz Zielonka <t.zie...@zodiac.mimuw.edu.pl> wrote:
>> Donn Cave wrote:
>>>> They also let one program be run on multiple processors simultaneously
>>>> on SMP machines.
>>>
>>> Yes. I may be a little weak on the terminology, but to
>>> me "concurrent" suggests "simultaneous", and inherently
>>> serialized concurrency is sort of an oxymoron.
>>
>> You are talking about parallel computing. Concurrency doesn't need
>> multiple processors.
>
> No, it's a valuable technique for structuring programs.
I would say the main purpose of concurrency is to allow programs to stay
live by giving them the flexibility to behave non-deterministically,
instead of demanding that the whole outside world to grinds to a complete
halt just because some computation can't be completed immediately.
Conventional (asynchronous, preemptively sceduled) multiple threading
(as with typical OS threads) is one way to achieve this, and has other
attractions too (the separation of concerns and improvement of program
structure which I think you're refering to). But this benefit could be
provided by other techniques like synchronous multithreading and co-routines
without intoducing preemption and non-determinism and all the associated
costs and hazards.
Of course with a non-strict FPL you already get this separation of concerns
for free as far as computation is concerned, but I still find it a useful
alternative to full blown concurrency with the Haskell IO monad,
occasionally.
My 2p..
Regards
--
Adrian Hey
Joachim Durchholz
> In article <2r880bF...@uni-berlin.de>, Joachim Durchholz wrote:
>
>> Dave Benjamin wrote:
>>
>>> I agree with your basic premise, but I also see programming as a
>>> form of literacy,
>>
>> It is... but that's beside the point.
>
> I should have said, "... a form of literacy of similar importance to
> reading, writing, arithmetic." I think that programming in some form
> will be a basic, essential life skill. I could be wrong, but I think
> that the point is still relevant.
Programming _as it is done today_ is not and will not be relevant to the
average citizen. It requires special skills, special training, and a
special rigorous mode of thinking - these aren't available for
everybody, nor is it desirable that they be.
Actually I observe that people get "computer literate" in exactly the
degress to which programming is taken out of the business. Instead of
programming a specific behaviour, all behaviours that make sense are
programmed by experts, leaving a drop-down list (or something similarly
restricted) for the end user to select the desired behaviour from.
>>> and in an ideal world, everyone should know how to program.
>>
>> In an ideal world, everybody whould be able to build a house,
>> repair a car, or do a painting.
>
> In an ideal world, everybody should be able to read and write.
Programming requires a lot of extra skill and training beyond reading
and writing. It's a different mode of thinking: rigorous, with strong
emphasis on exceptional and fringe cases, plus some degree of efficiency
concerns. Everyday thinking is less than rigorous, defers consideration
of exceptional and fringe cases until they actually occur, and doesn't
waste a single thought on efficiency since there's no need to implement
it on silicon.
I'd *highly* sceptical that computer programming skills will ever become
a commodity for everybody. (Despite it being desirable that everybody be
able to program - but, as I said, the same goes for a lot of other
activities. When judging from practical relevance, other things than
programming are the most important ones: namely, that people be able to
interpret statistics, to judge the validity of public claims by doing
their own research, and to judge their medicinal needs. Computers can be
tools for all of this, but people don't need to program to make
computers so.)
>> This world isn't ideal. And I don't think that striving for ideals
>> is necessarily a Good Thing (in fact some of the more forceful
>> attempts of attaining an ideal have cause havoc and grief without
>> an end, just take a look at the history of Communism or
>> Christianism - both well-intentioned, and both soon diverted from
>> their original intents and badly abused).
>
> Well, I wouldn't worry about it too much. I'm quite convinced of your
> high level of programming literacy, so you will surely be spared in
> the first round of killings. ;)
Um... or probably the other way round ;-)
> [There's] a more general problem: a lack of interest in learning. But
> I think we're basically in agreement here.
Yup.
I just learned a lot from the books on "brain-friendly" thinking, by
Vera F. Birkenbihl (some of her books are available in English, or so
I've been told). One of her main points is that most people are
discouraged from learning by their superiors; e.g. child exploring the
physical properties of a piece of bread, naturally dissecting it into
crumbs, its parents scold: "don't play with your food, dear!" - similar
things happen at school. Her books are about regaining some this
playfulness, about employing both sides of the brain, with refreshingly
little theory and a lot of practical exercises (actually who cares about
theory if the practice works *g*).
Regards,
Jo
Joachim Durchholz
>
> I'm actually interested in OS threads mostly because of external
> environments where they play an integral role and there isn't any
> choice but to use them. Personally I think concurrency brings along
> enough problems that it's kind of a scary solution -- so the example
> of an sshd implemented with threads was a little horrifying. But
> that's from the perspective of OS threads, in an imperative language.
> I sometimes get the impression that enough people have come to have
> that same horror of threads that we aren't going to see lots more of
> these OS thread based application environments.
Most people shy from OS threads because the implementations aren't good
enough. If the scheduler is so dumb that a task switch takes O(N) time
for N runnablel tasks, the thing simply doesn't scale. If the kernel is
neither multitaskable nor preemptive, parallelization becomes pointless
if you're doing OS-heavy stuff. Etc. etc.
(Fortunately, that O(N) horror was removed on the 2.6 Linux kernel; this
might make OS threads actually useful. I sincerely hope that the other
Un*x vendors pick that solution up.)
Regards,
Jo
Donn Cave
Joachim Durchholz <j...@durchholz.org> wrote:
...
> I'd *highly* sceptical that computer programming skills will ever become
> a commodity for everybody. (Despite it being desirable that everybody be
> able to program - but, as I said, the same goes for a lot of other
> activities. When judging from practical relevance, other things than
> programming are the most important ones: namely, that people be able to
> interpret statistics, to judge the validity of public claims by doing
> their own research, and to judge their medicinal needs. Computers can be
> tools for all of this, but people don't need to program to make
> computers so.)
I personally agree, but in case anyone's interested in
a fairly lengthy treatise wherein Guido Van Rossum
proposes to advance this cause using Python,
http://www.python.org/doc/essays/cp4e.html
The proposal was funded but not very generously, they
say, and wasn't completed. Subsequent influence of
CP4E priorities in Python hasn't been real obvious,
past a change to integer division.
For a more entertaining read that tries (and for me
fails) to make the point that it's an essential literacy -
http://www.oreillynet.com/pub/a/network/2000/01/31/hacktrack/
Donn Cave, do...@u.washington.edu
George Russell
> It requires special skills, special training, and a
> special rigorous mode of thinking - these aren't available for
> everybody, nor is it desirable that they be.
On the other hand I think you can certainly make a case that it
is worthwhile for people to learn such skills to improve their powers
of reasoning, just as it is worthwhile for people to learn trigonometry
or chess. Programming requires the ability to take a large complex
problem and break it down into small pieces, something which is hard to
learn and useful in other areas.
cr88192
"Joachim Durchholz" <j...@durchholz.org> wrote in message
news:2rgmkbF...@uni-berlin.de...
> Dave Benjamin wrote:
>> In article <2r880bF...@uni-berlin.de>, Joachim Durchholz wrote:
>>
>>> Dave Benjamin wrote:
>>>
>>>> I agree with your basic premise, but I also see programming as a
>>>> form of literacy,
>>>
>>> It is... but that's beside the point.
>>
>> I should have said, "... a form of literacy of similar importance to
>> reading, writing, arithmetic." I think that programming in some form
>> will be a basic, essential life skill. I could be wrong, but I think
>> that the point is still relevant.
>
> Programming _as it is done today_ is not and will not be relevant to the
> average citizen. It requires special skills, special training, and a
> special rigorous mode of thinking - these aren't available for
> everybody, nor is it desirable that they be.
> Actually I observe that people get "computer literate" in exactly the
> degress to which programming is taken out of the business. Instead of
> programming a specific behaviour, all behaviours that make sense are
> programmed by experts, leaving a drop-down list (or something similarly
> restricted) for the end user to select the desired behaviour from.
>
have to think that different to do such. just large amounts of coding, like
large amounts of writing, will be too much of a hassle, so likely coding
would be confined to small scripts for controlling existing apps, but may
become more complicated in some cases.
a lot of users may not bother, and would be likely to share scripts for
accomplishing tasks, but some will.
one need not be rigorous, or precise, or need to be taught much, those who
will learn will learn on their own, but, like math and writing, many will
not learn unless pressure is applied.
imo, at least people should be taught how to use shells, that is a good
first step.
>>>> and in an ideal world, everyone should know how to program.
>>>
>>> In an ideal world, everybody whould be able to build a house,
>>> repair a car, or do a painting.
>>
>> In an ideal world, everybody should be able to read and write.
>
> Programming requires a lot of extra skill and training beyond reading
> and writing. It's a different mode of thinking: rigorous, with strong
> emphasis on exceptional and fringe cases, plus some degree of efficiency
> concerns. Everyday thinking is less than rigorous, defers consideration
> of exceptional and fringe cases until they actually occur, and doesn't
> waste a single thought on efficiency since there's no need to implement
> it on silicon.
>
not for me. I started, on my own, as a little kid. I didn't really know
math, and wasn't that great at reading/writing (though I did think it was
lame how bad others were at it). I didn't have access to much more than
anyone else, and my persuits were not really assisted by anyone.
I am likely unusual though.
just I think having been taught things by others doesn't seem like much of a
confidence boost though.
> I'd *highly* sceptical that computer programming skills will ever become
> a commodity for everybody. (Despite it being desirable that everybody be
> able to program - but, as I said, the same goes for a lot of other
> activities. When judging from practical relevance, other things than
> programming are the most important ones: namely, that people be able to
> interpret statistics, to judge the validity of public claims by doing
> their own research, and to judge their medicinal needs. Computers can be
> tools for all of this, but people don't need to program to make
> computers so.)
>
some will learn, many will not.
this will likely become a dividing point (watch as the masses become ever
more helpless as things change around them...). of course, this means more
whining at me about stupid crap, but oh well...
>>> This world isn't ideal. And I don't think that striving for ideals
>>> is necessarily a Good Thing (in fact some of the more forceful
>>> attempts of attaining an ideal have cause havoc and grief without
>>> an end, just take a look at the history of Communism or
>>> Christianism - both well-intentioned, and both soon diverted from
>>> their original intents and badly abused).
>>
>> Well, I wouldn't worry about it too much. I'm quite convinced of your
>> high level of programming literacy, so you will surely be spared in
>> the first round of killings. ;)
>
> Um... or probably the other way round ;-)
>
>> [There's] a more general problem: a lack of interest in learning. But
>> I think we're basically in agreement here.
>
> Yup.
>
> I just learned a lot from the books on "brain-friendly" thinking, by
> Vera F. Birkenbihl (some of her books are available in English, or so
> I've been told). One of her main points is that most people are
> discouraged from learning by their superiors; e.g. child exploring the
> physical properties of a piece of bread, naturally dissecting it into
> crumbs, its parents scold: "don't play with your food, dear!" - similar
> things happen at school. Her books are about regaining some this
> playfulness, about employing both sides of the brain, with refreshingly
> little theory and a lot of practical exercises (actually who cares about
> theory if the practice works *g*).
>
I have generally went against others wrt this...
I think I largely just folded inward or something though, those are years
where things are unclear. sometime around highschool I started restabilizing
and such, and started generally interacting with people again (sort of).
a much bigger issue is learning what is real and what is not. seperating
your mind from what you think of others, and what others think vs what you
think they think, and what happened vs what you had been thinking about, ...
learning that one person is not another, and learning to tell them apart;
learning how to say things without pissing people off or causing them to
cry, and without getting in trouble for whatever reason;
larning to understand what people are saying to you (beyond just tidbits
related to exact meaning or commands, or answering specific questions) and
to give responses that make sense to people; learning of one's own existance
and the relevance of being human, and of the great muck that is one's own
emotions.
these are far harder than learning programming. it is a long and hard
battle, but one is forced to interact with humans, just like many humans are
forced to interact with machines.
then somehow I wonder if my mind is walking on some kind of mesh made of
self-rewriting c or something, like it somehow got written into my core
functioning or such...
now, I am not logical or accurate, but more just some sort of half-broken
entity living between the world of humans and machines, and being rather
weak on both fronts...
Joachim Durchholz
Let me just recount what I experienced when learning programming. (I was
a rather introspective and self-observing kind of guy back then.)
First, fascination let me learn that stuff.
Then, I found that my thought processes had changed completely. My
previous thinking had left many more things implicit; things that had
been left foggy were now elaborated until they were crystal clear.
The change definitely made me a better programmer.
It made me a worse social interactor though (I wasn't great at that to
begin with, but some things became even more difficult).
It didn't change my school grades at all (which were quite good at that
time).
In other words, I won a new mode of thinking, with all the associated
advantages, but I completely lost my old mode of thinking, with all the
associated disadvantages.
When I let this pass before my inner eye, this reminds me of the effect
or learning to read and write. It opens up a whole new world, and it is
and interesting and gratifying world.
BUT there is no way back. You can't unlearn, or go back to your old
thinking habits. There are marked differences in the way that alphabets
and analphabets use their brain, and both sides have strong advantages.
I'm reluctant to propagate "programming for everybody" for two reasons:
1) Because I don't wish to mess with the minds of my co-citizens, unless
I *know* that it will make them happier.
2) Because I'm unsure that a society where the programmers' mentality
has changed everything (much in the way that literacy has changed
everything) is better than the current society.
Regards,
Jo
Thant Tessman
[...]
> I'm reluctant to propagate "programming for everybody" for two reasons:
> 1) Because I don't wish to mess with the minds of my co-citizens, unless
> I *know* that it will make them happier.
> 2) Because I'm unsure that a society where the programmers' mentality
> has changed everything (much in the way that literacy has changed
> everything) is better than the current society.
I remember being in elementary school with a student whom I'm now
guessing had Down syndrome. I remember the teacher explaining that she
was not stupid, it just took her longer to learn things. I believed the
teacher. Of course certain tasks are harder or easier for different
people (with programming being a particularly noteworthy example), and
we all have to decide where to put our energy and how much of it we want
to spend, but I've seen too much evidence that ultimately what
determines if something is beyond someone's understanding is really a
matter of whether they have decided to understand it or not. So while I
have patience for people who choose not to learn something because
they've simply decided to spend their efforts differently, I have no
patience for people who deliberately choose not to understand something
because they are comfortable with their prejudices.
I guess my point is that as long as the students aren't chained to their
desks, whether the knowledge you teach them will make them happier seems
to be the completely wrong thing to be worried about.
-thant