Just came across this one by chance:
<http://www.approximity.com/produktiver_programmieren/index.html>
Looks like it has already been published in 2002 and it's only
available in German. The title could probably be translated as
"Programming more productively" and according to the German
description it's a "pragmatic" book which aims to show how using
"alternative higher level languages" like Ruby, Lisp, Smalltalk,
Dylan, and Erlang can help you to reach your goals faster than
programming in "mainstream languages loved by management" like Java
and C++. Apparently it's a collection of interviews and case studies.
The book includes an interview with KMP ("On the side of budget, I
have to say that the open source marketplace is I think the single
greatest threat to forward advance in computer science.") which is
available online:
<http://www.approximity.com/produktiver_programmieren/pitman_en.html>
<http://www.approximity.com/produktiver_programmieren/pitman_de.html>
(The second link is the German translation.)
Edi.
Edi Weitz wrote:
> The book includes an interview with KMP ("On the side of budget, I
> have to say that the open source marketplace is I think the single
> greatest threat to forward advance in computer science.") which is
> available online:
>
> <http://www.approximity.com/produktiver_programmieren/pitman_en.html>
> <http://www.approximity.com/produktiver_programmieren/pitman_de.html>
In fact I also found the part of the interview most interesting where
Kent started to talk about "open source".
Although he really meant "free software" (like free beer) and not
software which sources are open, I can agree to it to some part.
Although some pieces of free software can also have some positive
effects for the market.
Andr�
--
Andr� Thieme <······································@justmail.de> wrote in message news:<············@ulric.tng.de>...
> In fact I also found the part of the interview most interesting where
> Kent started to talk about "open source".
> Although he really meant "free software" (like free beer) and not
> software which sources are open, I can agree to it to some part.
> Although some pieces of free software can also have some positive
> effects for the market.
Do people normally worry about the End of Programming, or is this a
recent phenomenon because of unusual threats? Commonly perceived
threats:
- Microsoft
- Free Software/Opensource
- visual languages
- shrinkwrap
- patents
- India
I would guess in the past, people concerned themselves about the
following:
- IBM
- programming languages
- smarter children
- code factories
- the GUI
- Japan
- AI
The problem seems that if indeed one of the above listed is a major
threat, programmers are so desensitized that they will fail to
perceive it as such.
Not so much the end of programming.
But outsourcing of programming to India and other eastern nations
with low salary rates.
I belive this is a real threat.
On 1 Apr 2004 01:25:28 -0800, Tayssir John Gabbour <···········@yahoo.com>
wrote:
> Andr� Thieme <······································@justmail.de> wrote
> in message news:<············@ulric.tng.de>...
>> In fact I also found the part of the interview most interesting where
>> Kent started to talk about "open source".
>> Although he really meant "free software" (like free beer) and not
>> software which sources are open, I can agree to it to some part.
>> Although some pieces of free software can also have some positive
>> effects for the market.
>
> Do people normally worry about the End of Programming, or is this a
> recent phenomenon because of unusual threats? Commonly perceived
> threats:
> - Microsoft
> - Free Software/Opensource
> - visual languages
> - shrinkwrap
> - patents
> - India
>
>
> I would guess in the past, people concerned themselves about the
> following:
> - IBM
> - programming languages
> - smarter children
> - code factories
> - the GUI
> - Japan
> - AI
>
> The problem seems that if indeed one of the above listed is a major
> threat, programmers are so desensitized that they will fail to
> perceive it as such.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad <··············@chello.no> wrote:
> Not so much the end of programming.
> But outsourcing of programming to India and other eastern nations
> with low salary rates.
> I belive this is a real threat.
IMO, this is a serious threat to dramatically change the landscape, and
make a lot of people change jobs or learn new things to stay employable.
As a harbinger of the "death of programming" it leaves much to be
desired. The most lucrative programming is too business specific and
requires too much domain knowledge to be easily outsourced. Yes, there
are a lot of folks out there who "code to recipe", having only some
specific skill and little domain knowledge. These folks are going to
get lower and lower paid as jobs like that are outsourced to India and
other lower-wage countries. But consultants with these skills will
still find bit/piece work available. In some cases, consultants may
start writing the recipes and sending off a PO to an Indian firm instead
of writing the code themselves. Or a programming-savvy domain expert
may do this, avoiding the consultant. But the architecture work (which
is the most interesting and most lucrative) is still going to be done by
people with domain knowledge, and that's much harder to outsource to
another country.
Will a lot of people have to change what they do dramatically in order
to stay competitive? Absolutely. Those who cannot, or refuse to change
and learn will be hit hard. But this is the same thing that happened in
the blue collar world in the 1970s and 80s. Most of those jobs didn't
die, they just got done by fewer people -- after enough folks got laid
off or retrained and found other work, pretty soon the very skills that
were undervalued in the 70s/80s came into high demand. Electricians,
plumbers, press operators, all did pretty well in the 90s, and many of
them are still doing well now because of the labor shortages in those
industries.
The same kind of thing is going to happen in programming. Certain very
repetitive parts are going to be undervalued dramatically. The
interesting parts (really high level, high-CS tool design, and domain
based modeling) are not. People who have never been good enough to do
the interesting parts are going to find themselves unable to find work
as programmers by the end of the coming shakeout. Others will have hard
times as the winds change and they cannot read them perfectly, but will
almost certainly land on their feet eventually, even if the jobs they
end up in look very different from what they are doing now.
Programmers have gotten used to a market where their skills were in such
high demand that people would pay high-level money for essentially
menial tasks, just because so few people knew how to do those menial
tasks. That's no longer true. Writing HTML pages is no harder than
typesetting. As the number of people who know how to write HTML pages
got big enough, eventually that job didn't command any more money than a
typesetting job. HTML jockeys get $15-25/hour instead of $40-60/hour.
Well, now the same thing is starting to happen with jobs a bit further
up the scale. We are no longer going to be paid like scientists,
engineers and executives for those jobs which aren't much harder than a
secretarial position. Suck it up! Where programmers can put dollars to
the bottom line in ways that some random intelligent person off the
street cannot, they will continue to be in demand and be paid handsomely
(modulo short-term economic effects).
Michael
Imminent death of programming predicted -- film at 11
On Thu, 01 Apr 2004 09:22:14 -0500, Michael Sullivan wrote:
> We are no longer going to be paid like scientists,
> engineers and executives for those jobs which aren't much harder than a
> secretarial position. Suck it up!
Well, I would, but I believe that if enough of your "Suck it up" idea is
needed, our economy is going to go through a period of bankruptcy,
deflation, and national despair that makes the Great Depression look like
a cakewalk. It's not the fact of outsourcing, but the suddeness that's
going to kill the economy.
In addition, I have a fundamental belief that economies, as human created
(and regulated) things, have some responsibility to bring benefit to their
participants (and if they don't, enough of the participants leave the
formal economy as to make it irrelevant). As such, I view the rising
economic disparities inherent in your "Suck it up" philosophy as
ultimately destructive to both the economy and social order.
Finally, I've seen many older engineers and software architects who have
kept their skills up to date and who can't buy a job. I don't know if
you've noticed, but the unemployment rate among electrical engineers (yes,
real "engineers") is still above the unemployment rate for the last
recession in the '85 time frame). That tells me that there is more going
on in this situation than people "paid like engineers for those jobs which
aren't much harder than a secretarial position". I'd like to believe
differently, but until you can "show me the jobs", I'll have to politely
dismiss your "Suck it up" philopsophy as just one of "I got mine, Jack,
so shut up and go away", an attitude that I'm sure I must be misreading.
faa
"Frank A. Adrian" <·······@ancar.org> writes:
> Well, I would, but I believe that if enough of your "Suck it up" idea is
> needed, our economy is going to go through a period of bankruptcy,
> deflation, and national despair that makes the Great Depression look like
> a cakewalk. It's not the fact of outsourcing, but the suddeness that's
> going to kill the economy.
>
> In addition, I have a fundamental belief that economies, as human created
> (and regulated) things, have some responsibility to bring benefit to their
> participants (and if they don't, enough of the participants leave the
> formal economy as to make it irrelevant). As such, I view the rising
> economic disparities inherent in your "Suck it up" philosophy as
> ultimately destructive to both the economy and social order.
>
> Finally, I've seen many older engineers and software architects who have
> kept their skills up to date and who can't buy a job. I don't know if
> you've noticed, but the unemployment rate among electrical engineers (yes,
> real "engineers") is still above the unemployment rate for the last
> recession in the '85 time frame). That tells me that there is more going
> on in this situation than people "paid like engineers for those jobs which
> aren't much harder than a secretarial position". I'd like to believe
> differently, but until you can "show me the jobs", I'll have to politely
> dismiss your "Suck it up" philopsophy as just one of "I got mine, Jack,
> so shut up and go away", an attitude that I'm sure I must be misreading.
So you seem to say that there's a limit to the number of jobs or work
a closed economy (Earth's a closed economy, we don't import or export
with the rest of the galaxy) can do.
That should be true if you consider the physical system and its energy
resources. If there's unemployment it's a direct consequence of:
- the closing of Irakian Oil exploitation by Bush's Army,
- the peak of oil (http://www.dieoff.org),
- the ecologists who fight nuclear energy.
The only offcially known solution mid term (100 - 150 years) is
nuclear energy. Let's all these unemployed engineers be hired to
build and run nuclear power plants! And let all the unemployed
scientists search for powerful alternate energy sources.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
"Frank A. Adrian" <·······@ancar.org> wrote in message news:<······························@ancar.org>...
> In addition, I have a fundamental belief that economies, as human created
> (and regulated) things, have some responsibility to bring benefit to their
> participants (and if they don't, enough of the participants leave the
> formal economy as to make it irrelevant). As such, I view the rising
> economic disparities inherent in your "Suck it up" philosophy as
> ultimately destructive to both the economy and social order.
The cost of reeducation needs to drop. America needs to convert some
of our wealth into flexibility.
> Finally, I've seen many older engineers and software architects who have
> kept their skills up to date and who can't buy a job. I don't know if
> you've noticed, but the unemployment rate among electrical engineers (yes,
> real "engineers") is still above the unemployment rate for the last
> recession in the '85 time frame). That tells me that there is more going
> on in this situation than people "paid like engineers for those jobs which
> aren't much harder than a secretarial position". I'd like to believe
> differently, but until you can "show me the jobs", I'll have to politely
> dismiss your "Suck it up" philopsophy as just one of "I got mine, Jack,
> so shut up and go away", an attitude that I'm sure I must be misreading.
Is there an intelligent source out there with graphs about employment?
It would be nice to see if the unemployment rate is correlated with
the dotcom employment explosion + CS grad factories.
From what I hear, salaries are pretty "normal," which implies
employment has to give.
On Fri, 02 Apr 2004 00:59:13 -0800, Tayssir John Gabbour wrote:
> It would be nice to see if the unemployment rate is correlated with
> the dotcom employment explosion + CS grad factories.
Well, of course it was. Yes, the high UR is partially due to an
temporary boost in employment during the dot com boom. This causality,
though, does not provide a ready solution to the problem of unemployment.
If anything, it simply tells you that there are a lot more people out
there who need employment. Duh...
> From what I hear, salaries are pretty "normal," which implies
> employment has to give.
And that's a beautiful thing? Again, look at the bigger picture.
faa
"Frank A. Adrian" <·······@ancar.org> wrote in message news:<······························@ancar.org>...
> If anything, it simply tells you that there are a lot more people out
> there who need employment. Duh...
[...]
> And that's a beautiful thing? Again, look at the bigger picture.
>
> faa
When someone doesn't get the impression you're agreeing loud enough,
they paint a big target on you. And all you can do is a) wish you
knew a smart economist who knows history and b) wonder why they want
you to "feel" rather than think.
Before your post, I thought it was important to offer a comfortable
middle class existence to anyone who worked hard enough. However,
perhaps we have a sense of entitlement, and maybe the Cold War has
made our society so paranoid that we attack anything that might
resemble a threat. I occasionally hear from Europeans who sneer at
our intelligence, but the US did after all help save the world from
Eurasia, and we're bound to be a little jittery from the experience.
So who is it, faa? You claim I don't see the big picture, but you
haven't said anything about it yet. Who's the threat: India,
Microsoft, or Free Software? All of them?
On Fri, 02 Apr 2004 18:15:17 -0800, Tayssir John Gabbour wrote:
> Who's the threat: India, Microsoft, or Free Software? All of them?
Yes. And all of them are also opportunities. The questions, as always,
are "How big a threat vs. how big an opportunity?", "Who wins, who
loses, and to what extent?, and "How does this play out short term vs.
long term?". Most people who promote globalization (I'm not going into
the proprietary vs. free software debate - each side there has been
relatively honest in their debates) have a relatively good answer to
question 1, like to oversimplify the answer to question 2, and are
religious believers in globalization being a good thing in both the short
and long term. They also have most of the economic pulpit today. The
cautionary voices against unfettered, rapid globalization are drowned out.
faa
"Frank A. Adrian" <·······@ancar.org> wrote in message news:<······························@ancar.org>...
> On Fri, 02 Apr 2004 18:15:17 -0800, Tayssir John Gabbour wrote:
> > Who's the threat: India, Microsoft, or Free Software? All of them?
>
> Yes. And all of them are also opportunities. The questions, as always,
> are "How big a threat vs. how big an opportunity?", "Who wins, who
> loses, and to what extent?, and "How does this play out short term vs.
> long term?". Most people who promote globalization (I'm not going into
> the proprietary vs. free software debate - each side there has been
> relatively honest in their debates) have a relatively good answer to
> question 1, like to oversimplify the answer to question 2, and are
> religious believers in globalization being a good thing in both the short
> and long term. They also have most of the economic pulpit today. The
> cautionary voices against unfettered, rapid globalization are drowned out.
If onshore programmers agitate for legislation against buggy/insecure
programs, I would think offshorers would be penalized
disproportionately. Because every need for tighter communication
attacks their main weakness -- worse communication channels. It
should noticeably affect their cost advantage.
Increased sensitivity to software quality would be a good thing for
onshorers to cultivate in their markets. This assumes offshorers are
generally lower quality due to communication issues.
Tayssir John Gabbour wrote:
> If onshore programmers agitate for legislation against buggy/insecure
> programs, I would think offshorers would be penalized
> disproportionately. Because every need for tighter communication
> attacks their main weakness -- worse communication channels. It
> should noticeably affect their cost advantage.
??
First, you're referring to two VERY different kinds of bugs: Doesn't do
what customer wants, versus can be tricked into doing things customer
didn't ask for and (ignorant) programmer didn't forsee.
Assuming that quality, verified software takes more labour to write and
document than the other kind, I'd say that the vendor with the labour
cost advantage wins even more. If you think Indian programmers are
inexpensive, their technical writers are likely paid even less. "Get a
verified, documented, ISO-9000 certified system for the same low price!"
> Increased sensitivity to software quality would be a good thing for
> onshorers to cultivate in their markets. This assumes offshorers are
> generally lower quality due to communication issues.
You phrase it well, but it all sounds suspiciously like telling the
customer what he wants. Verification processes are known. Most customers
forgo the cost. I don't think educating them will change their minds.
Your post reminds me of the Usenet political spam encouraging people to
hang up the telephone if they hear a heavily accented voice and a poor
connection, on the theory that it's an offshore call center. I'd bet
that, if a study were done, a heavier accent and a worse connection
would indicate the opposite.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Your post reminds me of the Usenet political spam encouraging people to
> hang up the telephone if they hear a heavily accented voice and a poor
> connection, on the theory that it's an offshore call center. I'd bet
> that, if a study were done, a heavier accent and a worse connection
> would indicate the opposite.
You are feeling emotion because you think I believe something. You
analogize my post to spam, and the subtext of your message is that I
wish to do terrible dishonest xenophobic things. From my perspective,
I'm just trying to imagine what rational people might do.
Look at the post you replied to; did I say I desired this hypothetical
future? My desires are irrelevant.
But maybe internet forums are lossy channels of communication too, and
I'll save the political-charged discussion for real life people. I'll
just defend my points and be done with it.
Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
> Tayssir John Gabbour wrote:
> > If onshore programmers agitate for legislation against buggy/insecure
> > programs, I would think offshorers would be penalized
> > disproportionately. Because every need for tighter communication
> > attacks their main weakness -- worse communication channels. It
> > should noticeably affect their cost advantage.
>
> ??
>
> First, you're referring to two VERY different kinds of bugs: Doesn't do
> what customer wants, versus can be tricked into doing things customer
> didn't ask for and (ignorant) programmer didn't forsee.
>
> Assuming that quality, verified software takes more labour to write and
> document than the other kind, I'd say that the vendor with the labour
> cost advantage wins even more. If you think Indian programmers are
> inexpensive, their technical writers are likely paid even less. "Get a
> verified, documented, ISO-9000 certified system for the same low price!"
- Is the bottleneck communication or labor costs?
- When I say "legislation against buggy/insecure programs," I mean
software producers may be liable for damages. Adherence to a process
does not mitigate personal negligence. In fact, Big Process may make
it more difficult for offshorers to deliver real features, which is a
trap.
- The main argument I hear is that purchasers are buying on pure cost,
not value. In many markets, people eventually learn to buy value.
> > Increased sensitivity to software quality would be a good thing for
> > onshorers to cultivate in their markets. This assumes offshorers are
> > generally lower quality due to communication issues.
>
> You phrase it well, but it all sounds suspiciously like telling the
> customer what he wants. Verification processes are known. Most customers
> forgo the cost. I don't think educating them will change their minds.
[Yes, my post is completely about being heavy-handed. I'm just
entertaining what I would do if I were a) manipulative and b) cared.
Personally I am not convinced a problem exists.]
What is education? Branding, and all the other tools of advertising
agencies. Customers can come to appreciate quality, even if some
won't pay a premium for it. There is already a backlash against
certain insecure Microsoft products.
Tayssir John Gabbour wrote:
> Cameron MacKinnon <··········@clearspot.net> wrote in message news:<······················@golden.net>...
>
>>Your post reminds me of the Usenet political spam encouraging people to
>>hang up the telephone if they hear a heavily accented voice and a poor
>>connection, on the theory that it's an offshore call center. I'd bet
>>that, if a study were done, a heavier accent and a worse connection
>>would indicate the opposite.
>
>
> You are feeling emotion because you think I believe something. You
> analogize my post to spam...
Sorry, it just reminded me of that spam, which I found humourously,
unintentionally ironic. I perhaps should have been more clear, and
certainly didn't mean to cause offense.
I'm all for more secure software, but I'm not convinced customers will
pay for it. For all Microsoft's flaws, I believe they're extremely
customer driven. So when I hear them talking about better security, yet
see that huge pile of cash they're sitting on, I think they're paying
exactly as much attention to secure software as they think the market
demands. Some, but not a lot.
As for liability for software bugs, I'm as frustrated as you are that
the vast majority of software companies shrinkwrap-contract out of it.
But a "million coder march" on Washington? Unlikely. You're better off
to convince the Fortune 500 companies to refuse, from year x on, (2007?)
to waive Microsoft's liability. I think it's more likely, and would set
a solid precedent.
The frustrating part about Lisping is reading about exploit after
exploit and thinking "couldn't have happened with Lisp." Mostly that's
true of Java as well, though.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> The frustrating part about Lisping is reading about exploit after
> exploit and thinking "couldn't have happened with Lisp." Mostly that's
> true of Java as well, though.
In fact I think that was Java's primary reason for existing.
Remember, its big selling point early on was its security
model; The only reason they added GC was because they couldn't
make all the C-memory-management error exploits impossible
without adding it. They introduced it as a "sandbox" language
and they pushed it hard for web applications. And they made it
as much like C++ as they really could make a sandbox language
to give it market appeal.
The plus side is that programmers noticed, finally, that GC
doesn't have to be a huge performance hit and got used to how
nice it makes a lot of things. And the mainstream programming
language world got one step closer to Lisp.
Bear
> Cameron MacKinnon wrote:
> > The frustrating part about Lisping is reading about exploit after
> > exploit and thinking "couldn't have happened with Lisp." Mostly that's
> > true of Java as well, though.
read()/*read-eval* is lisp's hole for the unwary programmer. This
violates a nice principle that it should take skill to write insecure
software. Vaguely pisses me off because I'd like to get arrogant
about lisp's security.
Ray Dillinger <····@sonic.net> wrote in message news:<·················@sonic.net>...
> In fact I think that was Java's primary reason for existing.
> Remember, its big selling point early on was its security
> model; The only reason they added GC was because they couldn't
> make all the C-memory-management error exploits impossible
> without adding it. They introduced it as a "sandbox" language
> and they pushed it hard for web applications. And they made it
> as much like C++ as they really could make a sandbox language
> to give it market appeal.
Good to know that history.
> From: ···········@yahoo.com (Tayssir John Gabbour)
> read()/*read-eval* is lisp's hole for the unwary programmer. This
> violates a nice principle that it should take skill to write insecure
> software.
I think you're confusing programmers with users. When an application
program of general use, such as a Web browser, or an E-mail client,
etc. is mass-marketed to naive users, it damn well should be devoid of
security problems. MicroSoft has failed miserably in pushing their
cruddy trojan-enabled software on naive users and then trying to patch
the mess *after* millions of customers' machines have been compromised.
But a programmer writing software is supposed to be somewhat more
knowledgeable about the programming language he/she is using, at least
aware of the consequences of various processing he/she might program,
such as calling EVAL on some random s-expression, or calling READ or
READ-FROM-STRING on untrusted data with *READ-EVAL* being T, or
something even dumber such as evaluating the form (MAPC #'DELETE-FILE
(DIRECTORY "*.*")). We should of course make a list of non-obvious
security problems, such as *READ-EVAL*, and advertise simple ways to
avoid the problems, such as (SETQ *READ-EVAL* NIL), but then we have to
leave it to the programmer to have a little brains when writing
software, and make a big fuss whenever any programmer goes the
MicroSoft route of mass-marketing really crappy security-holefull
software.
It's obvious, from the principle, that EVAL is dangerous when given
untrusted input, right? It's obvious from the interactive environment
that an error can throw the user/programmer into a BREAK loop, right?
But READ, at its essence, is supposed to read, not evaluate, so it
might be a surprise that #.(expr) and #,(expr) can actually call EVAL
in the midst of READing, so beginning LISP programmers need to be
alerted to that one item. And of course it's obvious to anyone
programming MAPC and DELETE-FILE and DIRECTORY what that combination
would do, so it needn't even be mentionned. (It's not quite like
in the Unix shell where if you try to say
rm *.tmp
but you mis-type it as
rm * .tmp
it'll delete all your files just from one character mistake.)
So is *READ-EVAL* the only security problem with CL processing data
from untrusted sources that isn't obvious to any beginning programmer?
If so, let's just work out the best ways to do read-safely-from-string
or whatever we choose to call it, publish them here and eventually in
the FAQ, and be done with this "problem", OK?
··········@YahooGroups.Com wrote in message news:<·················@Yahoo.Com>...
> > From: ···········@yahoo.com (Tayssir John Gabbour)
> > read()/*read-eval* is lisp's hole for the unwary programmer. This
> > violates a nice principle that it should take skill to write insecure
> > software.
>
> MicroSoft has failed miserably in pushing their cruddy trojan-enabled
[..]
> in the Unix shell where if you try to say
I don't want to focus on other systems; I can live a good life without
knowing the hells people subject themselves to. ;)
> So is *READ-EVAL* the only security problem with CL processing data
> from untrusted sources that isn't obvious to any beginning programmer?
> If so, let's just work out the best ways to do read-safely-from-string
> or whatever we choose to call it, publish them here and eventually in
> the FAQ, and be done with this "problem", OK?
Why do you care about my agreement? If you think everything's fine in
Common Lisp, great. When I go around blabbing that lisp is "all dat,"
READ is far from my mind. However I think it's a blemish, and you are
free to weigh whether it deserves some fixing.
As I said, a nice property is it should take skill to write insecure
code. There are multiple solutions; READ can be made harder to use,
which I think is a bad solution. "Education" I think is a band-aid.
Making an easier alternative sounds about right to me.
But you're free to believe no solution is needed. I'm not in the way
of you and some universe with a builtin lisp listener.
> From: ···········@yahoo.com (Tayssir John Gabbour)
RM> So is *READ-EVAL* the only security problem with CL ...
RM> publish them here and eventually in
RM> the FAQ, and be done with this "problem", OK?
> If you think everything's fine in Common Lisp, great. ...
> I think it's a blemish, and you are free to weigh whether it deserves
> some fixing.
> it should take skill to write insecure code.
I disagree: Programmer should be free to write software for any user,
from the admin of a computer who should be free to do dangerous things
such as dismount devices and reformat a disk etc., to an unknown
untraceable untrustworthy and presumed malicious remote user who really
needs to be prohibited from doing what he wants to do. The programming
language shouldn't tie the arms of the programmer behind his back to
where he cannot write anything usable by an admin, or to where he must
constantly defeat the programming language just to get the daily job
done.
> There are multiple solutions; READ can be made harder to use, which I
> think is a bad solution.
I agree. The normal use of READ is either in the read-eval-print loop
during debugging, where we surely don't want to make it more difficult
for the programer to get his/her job done, and when loading or
compiling source files, where again the ability should match what R-E-P
enjoyed rather than be hamstrung compared to it. An ususual use for
READ or READ-FROM-STRING would be parsing s-expressions that come in
from the net, and for that specific purpose a SAFELY-READ and/or
SAFELY-READ-FROM-STRING should be available.
> "Education" I think is a band-aid.
I disagree. If the FAQ mentions that CL is a great language for writing
CGI applications, but beware if you plan to read s-expressions from
user's input be sure to use SAFELY-... instead of the usual version to
avoid read-time evaluation whereby the damage is already done before
your program gets control, and if there's a link to where SAFELY-...
can be found for free, and SAFELY-... is mentionned whenever this topic
comes up in the newsgroup, I think that should suffice to get word
around.
> Making an easier alternative sounds about right to me.
But unless you educate people to use the alternative, it does no good
to have it available. Witness how very many people don't know that CL
exists as a better alternative than what they're presently using. :-)
(Caveat: For some applications, something other than CL is best, and
people using that something else are doing just fine. But a very large
number of people could do better at their present task if they switched
to using CL, but don't realiaze that. It's those people I'm referring
to here.)
··········@YahooGroups.Com writes:
> > "Education" I think is a band-aid.
>
> I disagree. If the FAQ mentions that CL is a great language for writing
> CGI applications, but beware if you plan to read s-expressions from
> user's input be sure to use SAFELY-... instead of the usual version to
> avoid read-time evaluation whereby the damage is already done before
> your program gets control, and if there's a link to where SAFELY-...
> can be found for free, and SAFELY-... is mentionned whenever this topic
> comes up in the newsgroup, I think that should suffice to get word
> around.
It should. But it doesn't. In the C world everybody knows how to
protect CGI code against buffer overflows. It's still a problem.
Because programmers make errors. Frequently.
Matthias wrote:
> ··········@YahooGroups.Com writes:
>> > "Education" I think is a band-aid.
>>
>> I disagree. If the FAQ mentions that CL is a great language for writing
>> CGI applications, but beware if you plan to read s-expressions from
>> user's input be sure to use SAFELY-... instead of the usual version to
>> avoid read-time evaluation whereby the damage is already done before
>> your program gets control, and if there's a link to where SAFELY-...
>> can be found for free, and SAFELY-... is mentionned whenever this topic
>> comes up in the newsgroup, I think that should suffice to get word
>> around.
>
> It should. But it doesn't. In the C world everybody knows how to
> protect CGI code against buffer overflows. It's still a problem.
> Because programmers make errors. Frequently.
There's no need to make it easier than we have to, though.
As one of the likely users of safely-*, I have to ask: Is a combination of
unwind-protect and read-eval enough? Do I need to throw in handler-bind?
Exactly how would you write it anyhow?
Someone help!
Svein Ove Aas wrote:
> Matthias wrote:
>
>> ··········@YahooGroups.Com writes:
>>> > "Education" I think is a band-aid.
>>>
>>> I disagree. If the FAQ mentions that CL is a great language for
>>> writing CGI applications, but beware if you plan to read s-expressions
>>> from user's input be sure to use SAFELY-... instead of the usual
>>> version to avoid read-time evaluation whereby the damage is already
>>> done before your program gets control, and if there's a link to where
>>> SAFELY-... can be found for free, and SAFELY-... is mentionned
>>> whenever this topic comes up in the newsgroup, I think that should
>>> suffice to get word around.
>>
>> It should. But it doesn't. In the C world everybody knows how to
>> protect CGI code against buffer overflows. It's still a problem.
>> Because programmers make errors. Frequently.
>
> There's no need to make it easier than we have to, though.
>
> As one of the likely users of safely-*, I have to ask: Is a combination
> of unwind-protect and read-eval enough? Do I need to throw in
> handler-bind? Exactly how would you write it anyhow?
>
> Someone help!
I just found ignore-errors, and it seems to do what I want. Never mind.
Responding to two of your messages (articles, actually) together:
http://www.google.com/groups?selm=m%255pc.1508%24RL3.33500%40news2.e.nsc.no
> From: Svein Ove Aas <··············@brage.info>
> There's no need to make it easier than we have to, though.
Why not? If making it easy to write safe code means fewer worms
invading people's software and less worm-spam flooding our mailboxes,
wouldn't that make it worth a bit of effort?
> As one of the likely users of safely-*, I have to ask: Is a
> combination of unwind-protect and read-eval enough? Do I need to
> throw in handler-bind?
Either handler-bind or ignore-errors, I'm not sure whether handler-bind
is worth the extra effort for this particular use. ignore-errors may be
entirely enough here. I'm also not sure why you need to directly call
unwind-protect here.
> Exactly how would you write it anyhow?
Some proposed definitions of the safely-* functions have been posted
recently. I haven't had time to seriously try them to see which version
is best for my purposes of CGI applications, such as teaching how to
program in CL, and remote procedure call.
http://www.google.com/groups?selm=o56pc.1511%24RL3.33500%40news2.e.nsc.no
> From: Svein Ove Aas <··············@brage.info>
> I just found ignore-errors, and it seems to do what I want. Never mind.
Well half of what you want. Don't forget to disable read-eval also!
··········@YahooGroups.Com wrote:
> Responding to two of your messages (articles, actually) together:
>
http://www.google.com/groups?selm=m%255pc.1508%24RL3.33500%40news2.e.nsc.no
>> From: Svein Ove Aas <··············@brage.info>
>> There's no need to make it easier than we have to, though.
>
> Why not? If making it easy to write safe code means fewer worms
> invading people's software and less worm-spam flooding our mailboxes,
> wouldn't that make it worth a bit of effort?
Um, yes. I *meant* harder.
> From: Matthias <··@spam.pls>
>> If the FAQ mentions that CL is a great language for writing
>> CGI applications, but beware if you plan to read s-expressions from
>> user's input be sure to use SAFELY-... instead of the usual version to
>> avoid read-time evaluation whereby the damage is already done before
>> your program gets control, and if there's a link to where SAFELY-...
>> can be found for free, and SAFELY-... is mentionned whenever this topic
>> comes up in the newsgroup, I think that should suffice to get word
>> around.
> It should. But it doesn't. In the C world everybody knows how to
> protect CGI code against buffer overflows. It's still a problem.
I think there are two causes for that: First, C is such a painful
language to program in, constantly trying to keep track of who is
responsible for de-allocating any tiny bit of memory that was
previously allocated, that the programmer is totally busy with such
pain and simply forgets to apply best practices regarding array access.
Second, the C culture virtually forbids best practice.
The naive approach is to use explicit array indexing:
x = ar[++i];
ar[i] = y;
But programmers are urged by the C culture to bum their code to use
pointer arithmetic instead to avoid having to do a multiplication to
compute the index, because multiplication is "too slow", and doing the
same exact multiplication twice in a row is really too slow, so they
just add a fixed offset to the previous index:
x = *(++p);
*p = y;
One little mistake and it's off to buffer-overrun land.
The way to avoid buffer overrun is to go the opposite direction, away
from ultimate speed, toward ultimate safety. Define accessor and
mutator functions for the array which *always* check index bounds and
re-compute the new location that guaranteed-within-bounds index:
x = getAr(++i);
setAr(i,y);
That's essentially how CL and java do it (except if CL is compiled with
safety set to zero and speed at the maximum, a bad idea in network
must-be-secure applications). If you have lots of arrays you need to
define, set up a whole class with a struct to keep track of starting
location and data type and bounds, and accessor&mutator, making it
*really* like how CL and java do it.
x = getArrElem(arHead, ++i);
setArrElem(arHead, i, y);
CL of course has the setf macro as a big win, translated into (illegal)
C that second line would be:
getArrElem(arHead, i) = y;
If all C programmers doing serious network applications would go that
slow but safe route, maybe they could put a stop to buffer overruns?
(But if they are willing to write applications that are 1% slower than
bummed unsafe C, they might as well program in CL in the first place.)
Naw! Most programmers who have experience in in C know enough to avoid
allocation errors.
Altso they use bounds checkers just in case. (At least I did.)
The real problem is thet all library routines don't so bounds checking
and it is difficult to know which to trust.
On Mon, 17 May 2004 19:50:47 -0700, <··········@YahooGroups.Com> wrote:
> I think there are two causes for that: First, C is such a painful
> language to program in, constantly trying to keep track of who is
> responsible for de-allocating any tiny bit of memory that was
> previously allocated, that the programmer is totally busy with such
> pain and simply forgets to apply best practices regarding array access.
> Second, the C culture virtually forbids best practice.
>
> The naive approach is to use explicit array indexing:
> x = ar[++i];
> ar[i] = y;
> But programmers are urged by the C culture to bum their code to use
> pointer arithmetic instead to avoid having to do a multiplication to
> compute the index, because multiplication is "too slow", and doing the
> same exact multiplication twice in a row is really too slow, so they
> just add a fixed offset to the previous index:
> x = *(++p);
> *p = y;
> One little mistake and it's off to buffer-overrun land.
> The way to avoid buffer overrun is to go the opposite direction, away
> from ultimate speed, toward ultimate safety. Define accessor and
> mutator functions for the array which *always* check index bounds and
> re-compute the new location that guaranteed-within-bounds index:
> x = getAr(++i);
> setAr(i,y);
> That's essentially how CL and java do it (except if CL is compiled with
> safety set to zero and speed at the maximum, a bad idea in network
> must-be-secure applications). If you have lots of arrays you need to
> define, set up a whole class with a struct to keep track of starting
> location and data type and bounds, and accessor&mutator, making it
> *really* like how CL and java do it.
> x = getArrElem(arHead, ++i);
> setArrElem(arHead, i, y);
> CL of course has the setf macro as a big win, translated into (illegal)
> C that second line would be:
> getArrElem(arHead, i) = y;
> If all C programmers doing serious network applications would go that
> slow but safe route, maybe they could put a stop to buffer overruns?
> (But if they are willing to write applications that are 1% slower than
> bummed unsafe C, they might as well program in CL in the first place.)
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> Naw! Most programmers who have experience in in C know enough to avoid
> allocation errors.
> Altso they use bounds checkers just in case. (At least I did.)
> The real problem is thet all library routines don't so bounds checking
> and it is difficult to know which to trust.
So, most programmers know enough to avoid allocation errors, but the
privilege of library writing is reserved for the few who _don't_?
Sounds cockeyed to me.
-dan
--
"please make sure that the person is your friend before you confirm"
The concern with "safe" functions postdates web programming.
On Tue, 18 May 2004 12:49:30 +0100, Daniel Barlow <···@telent.net> wrote:
> "John Thingstad" <··············@chello.no> writes:
>
>> Naw! Most programmers who have experience in in C know enough to avoid
>> allocation errors.
>> Altso they use bounds checkers just in case. (At least I did.)
>> The real problem is thet all library routines don't so bounds checking
>> and it is difficult to know which to trust.
>
> So, most programmers know enough to avoid allocation errors, but the
> privilege of library writing is reserved for the few who _don't_?
> Sounds cockeyed to me.
>
>
> -dan
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
"John Thingstad" <··············@chello.no> writes:
> Naw! Most programmers who have experience in in C know enough to avoid
> allocation errors.
> Altso they use bounds checkers just in case. (At least I did.)
> The real problem is thet all library routines don't so bounds checking
> and it is difficult to know which to trust.
The main problem is when you're using third-party libraries...
in some cases you have to resort to the source code or a heap debug
library just to find out what conventions the library uses.
Hello!
<··········@YahooGroups.Com> wrote:
>[...]
> x = getArrElem(arHead, ++i);
> setArrElem(arHead, i, y);
>CL of course has the setf macro as a big win, translated into (illegal)
>C that second line would be:
> getArrElem(arHead, i) = y;
What about *getArrElem(...) = y? Or even using C++ like
foo[i] = y; (where operator[] is overloaded with a bounds-checking
version)?
C++ would still suck, but at other ends...
>[...]
Kind regards,
Hannah.
> From: ······@schlund.de (Hannah Schroeter)
> What about *getArrElem(...) = y?
No, that already has *different* semantics, namely get an element which
happens to be a pointer, and then blindly store whereever that points
to. This doesn't store inside the array at all, as was the intention of
the original question.
> Or even using C++ like foo[i] = y; (where operator[] is overloaded
> with a bounds-checking version)?
Can you do that in C++?? In C, foo doesn't have to be an array name, it
can be just a simple pointer variable, and that syntax will still do
the (unchecked) same thing, namely multiply i times the size of one
element pointed at and add to value of foo to get memory address of
desired element, then indirect (dereference) through that address to
get or overwrite that particular element. Given how an array can be
passed as a pointer and vice versa as argument (parameter) to function,
and calloc can allocate a block of element-sized units of memory and
then a simple pointer to it works as if an array name, I don't see how
the compiler can possibly know whether such a pointer is really an
array (on stack, or via calloc) whose bounds can be checked or not,
hence know whether bounds-checking code is possible and if so what
exact bounds it should enforce.
··········@YahooGroups.Com writes:
>> From: ······@schlund.de (Hannah Schroeter)
>
>> Or even using C++ like foo[i] = y; (where operator[] is overloaded
>> with a bounds-checking version)?
>
> Can you do that in C++??
Yes, but you wouldn't declare foo as `normal' array.
Hello!
<··········@YahooGroups.Com> wrote:
>> From: ······@schlund.de (Hannah Schroeter)
>> What about *getArrElem(...) = y?
>No, that already has *different* semantics, namely get an element which
>happens to be a pointer, and then blindly store whereever that points
>to. This doesn't store inside the array at all, as was the intention of
>the original question.
getArrElem(some_kind_of_array, index) can check bounds and throw
an exception if something's wrong. Then, using the pointer (without
pointer arithmetic) is safe.
Of course, it can also return a SpecialKindOfPointer, which
has operator* defined to access the element (using an element proxy
that defines operator& to return a SpecialKindOfPointer again instead
of a raw pointer, if you're paranoid) and forbids operator+ etc. (i.e.
pointer arithmetics). Or replaces them with bounds checked variants,
again.
>> Or even using C++ like foo[i] = y; (where operator[] is overloaded
>> with a bounds-checking version)?
>Can you do that in C++?? In C, foo doesn't have to be an array name, it
>can be just a simple pointer variable, and that syntax will still do
>the (unchecked) same thing, namely multiply i times the size of one
>element pointed at and add to value of foo to get memory address of
>desired element, then indirect (dereference) through that address to
>get or overwrite that particular element. Given how an array can be
>passed as a pointer and vice versa as argument (parameter) to function,
>and calloc can allocate a block of element-sized units of memory and
>then a simple pointer to it works as if an array name, I don't see how
>the compiler can possibly know whether such a pointer is really an
>array (on stack, or via calloc) whose bounds can be checked or not,
>hence know whether bounds-checking code is possible and if so what
>exact bounds it should enforce.
No, you can't hinder the client programmer to use operator[] with
pointers or "raw" arrays. But you can choose an idiom to not do so,
but use a bounds checked implementation of std::vector instead.
Just like you can rip holes into Common Lisp by bad style, like
(proclaim (optimized (speed 3) (safety 0))) and then accessing
array elements out of bounds or calling car on vectors or whatever.
There, too, you should establish a convention that safety is set to
at least 1 globally, and only set to 0 locally for performance critical
well-checked code.
Kind regards,
Hannah.
···········@yahoo.com (Tayssir John Gabbour) writes:
> "Frank A. Adrian" <·······@ancar.org> wrote in message news:<······························@ancar.org>...
> > On Fri, 02 Apr 2004 18:15:17 -0800, Tayssir John Gabbour wrote:
> > > Who's the threat: India, Microsoft, or Free Software? All of them?
> >
> > Yes. And all of them are also opportunities. The questions, as always,
> > are "How big a threat vs. how big an opportunity?", "Who wins, who
> > loses, and to what extent?, and "How does this play out short term vs.
> > long term?". Most people who promote globalization (I'm not going into
> > the proprietary vs. free software debate - each side there has been
> > relatively honest in their debates) have a relatively good answer to
> > question 1, like to oversimplify the answer to question 2, and are
> > religious believers in globalization being a good thing in both the short
> > and long term. They also have most of the economic pulpit today. The
> > cautionary voices against unfettered, rapid globalization are drowned out.
>
> If onshore programmers agitate for legislation against buggy/insecure
> programs, I would think offshorers would be penalized
> disproportionately. Because every need for tighter communication
> attacks their main weakness -- worse communication channels. It
> should noticeably affect their cost advantage.
>
> Increased sensitivity to software quality would be a good thing for
> onshorers to cultivate in their markets. This assumes offshorers are
> generally lower quality due to communication issues.
First, I personally intend to fight any such legislation tooth and
nail. If such a monstrosity comes into being, based on past behavior
companies will very quickly find ways to shunt risk off onto the
individual programmers, wherever they are located, even if the company
sets the budget/deadline without any regard to reality - which happens
far too often, in my experience.
Next, the communication issue has been one of my biggest 'don't get
it's on the whole software development outsourcing issue: I don't seem
to hear people mention project risk as a factor in cost, only the
putative savings in labor costs.
Then there is the issue of communication/transfer of business
practices and/or domain knowledge - information quite often zealously
guarded by a business. NDAs may go a certain way torwards mitigating
this particular risk, but I think are very far from entirely
sufficent, esp. over the long term. (I.e., enforcement in foreign
courts?)
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
Tayssir John Gabbour wrote:
>
> If onshore programmers agitate for legislation against buggy/insecure
> programs, I would think offshorers would be penalized
> disproportionately. Because every need for tighter communication
> attacks their main weakness -- worse communication channels. It
> should noticeably affect their cost advantage.
Oh, please. This market-protection crap doesn't work, any more than
it worked for detroit when they were asking for safety regs to keep
foreign carmakers out of the US markets. They got their safety regs
(with a little shove from Ralph Nader's consumer advocacy crew, which
they largely funded), the foreign carmakers were better at meeting
them than detroit was, and they got saddled with strict liability
into the bargain.
This sort of thing inevitably leads to licensing of programmers, or a
"guild" or something like that - and I don't think that's the best of
ideas. As a creative art, programming benefits from radical weirdos
with new ideas, and those are exactly the sort of people who won't be
licensed or admitted to the guild.
Also, code is speech. I don't think that a prior restraint on speech
is a good thing from a civil-liberties point of view.
Bear
Ray Dillinger <····@sonic.net> wrote in message news:<·················@sonic.net>...
> Also, code is speech. I don't think that a prior restraint on speech
> is a good thing from a civil-liberties point of view.
If we are talking about commercial speech, it has fewer protections
IIRC. There are precedents for virus writers being jailed -- if we
strip out the polarizing word "virus" and call it code, we'll see that
certain classes of code are not protected.
http://www.cbsnews.com/stories/2002/05/01/tech/main507751.shtml
Ray Dillinger <····@sonic.net> wrote in message news:<·················@sonic.net>...
> Tayssir John Gabbour wrote:
> > If onshore programmers agitate for legislation against buggy/insecure
> > programs, I would think offshorers would be penalized
> > disproportionately. Because every need for tighter communication
> > attacks their main weakness -- worse communication channels. It
> > should noticeably affect their cost advantage.
>
> Oh, please. This market-protection crap doesn't work, any more than
> it worked for detroit when they were asking for safety regs to keep
> foreign carmakers out of the US markets. They got their safety regs
> (with a little shove from Ralph Nader's consumer advocacy crew, which
> they largely funded), the foreign carmakers were better at meeting
> them than detroit was, and they got saddled with strict liability
> into the bargain.
Do you have a cite? A cursory research leads me to think
protectionism helped Detroit; their main liability was their low
quality during the 70s, opening their market to attack.
http://eightiesclub.tripod.com/id291.htm
> This sort of thing inevitably leads to licensing of programmers, or a
> "guild" or something like that - and I don't think that's the best of
> ideas. As a creative art, programming benefits from radical weirdos
> with new ideas, and those are exactly the sort of people who won't be
> licensed or admitted to the guild.
Just looking at this newsgroup, we can see that highly competent,
"radical weirdos" are no longer accepted. Compared to the more
polite, numerous coders we have today. I think those easily
romanticizable days are over. The closest we have is this tepid
"Angry Coder" fellow, the Limp Bizkit of the computer industry.
Of course, the position I am defending does disturb the snot out of
me, but there are increasing calls for legislation to achieve levels
of security that the market is failing to spur. The Opensource
movement is already using security as a cudgel against Microsoft's
monoculture, and certain companies successfully opened the door to
gov't intervention against MSFT. The scorched earth policy of
increasing legislation may continue depending on the threats people
perceive.
Tayssir John Gabbour wrote:
> The cost of reeducation needs to drop. America needs to convert some
> of our wealth into flexibility.
If you want retraining via books or the 'net, costs are already pretty
low, IMO. Classroom instruction has a few issues, though:
It is labour intensive, and labour is expensive in the US.
In any other industry, "small class size" would be seen to be synonymous
with "low productivity", but educators have convinced us that it's a virtue.
The US labour market is already said to be among the most flexible among
industrialized countries. Personally, I think if Americans want any more
labour flexibility, they're going to have to come up with portable
health care plans. Worries about losing coverage for existing
conditions, or of the costs and risks associated with bridging the
coverage gap between old and new jobs are the only issues I can see
preventing more people from changing jobs more often.
> Is there an intelligent source out there with graphs about employment?
> It would be nice to see if the unemployment rate is correlated with
> the dotcom employment explosion + CS grad factories.
A nonfarm payroll chart:
http://graphics7.nytimes.com/images/2004/03/08/opinion/09KRUG.583.gif
If you want more, I'd check the Federal Reserve.
Don't confuse unemployment and employment. :-) Unemployment is measured
as those actively seeking work, so people who've become discouraged and
given up aren't counted.
> From what I hear, salaries are pretty "normal," which implies
> employment has to give.
Salaries are sticky: In very few places is it acceptable to say
"business is down, everybody takes a 10% pay cut" so, as you point out,
it's employment that gives.
--
Cameron MacKinnon
Toronto, Canada
On Thu, 01 Apr 2004 07:29:29 -0800, Frank A Adrian wrote:
> In addition, I have a fundamental belief that economies, as human created
> (and regulated) things, have some responsibility to bring benefit to their
> participants
The natural economy ("free market") always benefits its participants,
by definition (nobody would trade if he didn't benefit by it!); the
logical corollary is that any coercive interference in the economy
necessarily disadvantages at least some of the participants (otherwise
no coercion would be necessary). Thus the combination of your
professed "fundamental belief" and your implied advocacy of
protectionism is hard to fathom.
> (and if they don't, enough of the participants leave the
> formal economy as to make it irrelevant).
What does "leave the formal economy" mean? Entering the "black"
(i.e., free) market? Or hiring the Mafia to keep other people in
line? :-) Either way has higher costs, and in the former case jobs
are /still/ going to go to India (or Western programmers are going to
take a pay cut, for the same jobs -- which they can do today, without
"leaving the formal economy", if they want)
> As such, I view the rising
> economic disparities inherent in your "Suck it up" philosophy as
> ultimately destructive to both the economy and social order.
/Rising/ economic disparities?? You're not taking those Indian
programmers into account?
> Finally, I've seen many older engineers and software architects who have
> kept their skills up to date and who can't buy a job. I don't know if
> you've noticed, but the unemployment rate among electrical engineers (yes,
> real "engineers") is still above the unemployment rate for the last
> recession in the '85 time frame). That tells me that there is more going
> on in this situation than people "paid like engineers for those jobs which
> aren't much harder than a secretarial position". I'd like to believe
> differently, but until you can "show me the jobs", I'll have to politely
> dismiss your "Suck it up" philopsophy as just one of "I got mine, Jack,
> so shut up and go away", an attitude that I'm sure I must be misreading.
Show me the customers, and I'll show you the jobs :-)
--
Oh dear god. In case you weren't aware, "ad hominem" is not latin for
"the user of this technique is a fine debater."
-- Thomas F. Burdick
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley wrote:
> On Thu, 01 Apr 2004 07:29:29 -0800, Frank A Adrian wrote:
>
>
>>In addition, I have a fundamental belief that economies, as human created
>>(and regulated) things, have some responsibility to bring benefit to their
>>participants
>
>
> The natural economy ("free market") always benefits its participants,
> by definition (nobody would trade if he didn't benefit by it!); the
> logical corollary is that any coercive interference in the economy
> necessarily disadvantages at least some of the participants (otherwise
> no coercion would be necessary). Thus the combination of your
> professed "fundamental belief" and your implied advocacy of
> protectionism is hard to fathom.
This is all very well in an Adam Smith world where all goods are
tangible, temporary intellectual property monopolies aren't addressed
and large organizations haven't yet figured out how to use market and/or
political power to stifle or absorb smaller competitors.
But since this is c.l.l, arguments suitable for widget factories which
take no account of the above mentioned factors are unlikely to appeal.
The audience is rather more concerned with the market in intellectual
property.
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon wrote:
> Paul Foley wrote:
>
>> On Thu, 01 Apr 2004 07:29:29 -0800, Frank A Adrian wrote:
>>
>>
>>> In addition, I have a fundamental belief that economies, as human
>>> created
>>> (and regulated) things, have some responsibility to bring benefit to
>>> their
>>> participants
>>
>>
>>
>> The natural economy ("free market") always benefits its participants,
>> by definition (nobody would trade if he didn't benefit by it!); the
>> logical corollary is that any coercive interference in the economy
>> necessarily disadvantages at least some of the participants (otherwise
>> no coercion would be necessary). Thus the combination of your
>> professed "fundamental belief" and your implied advocacy of
>> protectionism is hard to fathom.
>
>
> This is all very well in an Adam Smith world where all goods are
> tangible, temporary intellectual property monopolies aren't addressed
> and large organizations haven't yet figured out how to use market and/or
> political power to stifle or absorb smaller competitors.
Nope, even in an Adam Smith world the quoted paragraph is remarkable for
compression so many wrong statements into a short space. First, of
course, is the fact that people don't trade because they _will_ benefit,
but rather because they believe they will benefit, and their beliefs may
be wrong (this was one of the bases of Smith's "invisible hand" idea).
Second, the definition of "benefit" is purely local: a) per axelrod even
rational actors may make decisions that lead to a longterm loss of
utility for all participants and b) externalities and other effects may
lead to small gains for some participants being associated with enormous
losses for others, some of whome may not even be participating in the
transaction. Third, the existence of markets, whether in wheat or code,
requires an ultimately coercive assignment of property rights (and it's
really no good calling assignment choices you like "natural" and ones
you don't like "coercive").
The whole idea of a "natural economy" is hogwash, so anything built on
top of it, even in the most ostensibly rational fashion, is pretty much
doomed.
paul
On Sun, 04 Apr 2004 10:49:05 -0400, Paul Wallich wrote:
> Nope, even in an Adam Smith world the quoted paragraph is remarkable
> for compression so many wrong statements into a short space. First, of
> course, is the fact that people don't trade because they _will_
> benefit, but rather because they believe they will benefit, and their
> beliefs may be wrong
True, but irrelevant. They make an immediate psychic gain in
believing that they've made a good trade, and there's no better
process by which they might evaluate future benefit -- unless they
have a direct line to some omniscient diety, any other process will be
equally flawed. In particular, letting other people violently
interfere in the market can't possibly improve anything -- at best, it
can leave things no worse in the long term, while merely denying any
immediate benefit (which is an actual loss -- as is the loss of
freedom, of course; and it's pretty obvious that it usually will/does
make things worse in the long term as well)
> per axelrod even rational actors may make decisions that lead to a
> longterm loss of utility for all participants
See above. If there was a better way of making decisions, all that
would be necessary is to make that information available -- no
coercion would be required to make people use it, if it did an
objectively better job!
> and b) externalities and
> other effects may lead to small gains for some participants being
> associated with enormous losses for others,
"Externalities" are a failure to recognise/enforce property rights
(and/or a failure to recognise the subjectivity of value)
> Third, the existence of markets, whether in wheat or code, requires
> an ultimately coercive assignment of property rights
Property rights (real ones, not "intellectual property") are not at
all coercive. Reductio ad absurdum: denial of property rights denies
self-ownership, which implies that either
(a) nobody (including me!) has the right to make me interact with
the physical universe in any way (breathe, post to Usenet, ...)
i.e., nobody would be born, and anyone who was would die immediately;
or else
(b) somebody (possibly a group) /other than me/ has such a right,
but I don't get a say (that would be impossible: if it was a group
of which I was a member, I couldn't announce my vote without first
getting permission from the group, which I couldn't give without
first getting permission from the group, which I couldn't give
without ...)
but then there must be at least one person who owns himself, or
everyone is in the same catch-22 situation, which is equivalent to
case (a) -- and how do the members of the (necessarily non-empty) set
of self-owning people differ from the members of the (possibly empty)
set of non-self-owning people? The latter set must be empty, no?
But if some person owns himself, and nothing else is owned, and he
finds some wheat growing somewhere, and harvests it, he clearly (a)
don't harm anybody else (self-owners or not), and (b) owns the
harvesting-of-the-wheat (by virtue of that self-ownership), and since
that "good" is indivisible from the harvested wheat itself, you might
say he owns that wheat (as for Cameron MacKinnon's "tangible goods"
idea: in reality, /no/ economic good is ultimately a tangible good --
the part that can be owned and (thus) has value is essentially the
saving, on the part of the owner, of having to do the work of
producing a similar good, and that's not a tangible good! Cue
Bastiat)
The same argument applies to ownership of land, etc., of course.
The only "coercion" involved is when someone comes along and claims to
own everything in the world (or in some geographical area) -- without
having either non-coercively received it from legitimate owners (by
means of sale or gift) or "homesteaded" previously-unowned resources
himself -- and then proceeds to enforce that claim through violence;
that is, engages in politics.
--
Oh dear god. In case you weren't aware, "ad hominem" is not latin for
"the user of this technique is a fine debater."
-- Thomas F. Burdick
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley wrote:
> True, but irrelevant. They make an immediate psychic gain in
> believing that they've made a good trade, and there's no better
> process by which they might evaluate future benefit -- unless they
> have a direct line to some omniscient diety, any other process will be
> equally flawed. In particular, letting other people violently
> interfere in the market can't possibly improve anything -- at best, it
> can leave things no worse in the long term, while merely denying any
> immediate benefit (which is an actual loss -- as is the loss of
> freedom, of course; and it's pretty obvious that it usually will/does
> make things worse in the long term as well)
...
> See above. If there was a better way of making decisions, all that
> would be necessary is to make that information available -- no
> coercion would be required to make people use it, if it did an
> objectively better job!
Let's look at pharmaceutical drugs, shall we? Drug companies, unless
coerced, don't reveal information about side effects. The coercion which
you recoil from is the insistence that market participants reveal
information which they otherwise wouldn't. How would you address this,
in a coercion free way?
>> and b) externalities and
>>other effects may lead to small gains for some participants being
>>associated with enormous losses for others,
>
> "Externalities" are a failure to recognise/enforce property rights
> (and/or a failure to recognise the subjectivity of value)
Again, what's the difference between "enforce" and "coerce"? How are
property rights enforced in the society you envision? Who, in your
system, ensures that the river isn't used for toxic waste disposal at
midnight?
> Property rights (real ones, not "intellectual property") are not at
> all coercive. Reductio ad absurdum: denial of property rights denies
> self-ownership, which implies that either
[totally absurd argument deleted]
> The same argument applies to ownership of land, etc., of course.
How about applying your argument to ownership of land for us directly?
Also, please differentiate between "real" and "intellectual" property
rights for us. Both are creatures of statute, but only one protects the
creation of genuinely novel value, rather than the shuffling between
accounts of various resources.
> The only "coercion" involved is when someone comes along and claims to
> own everything in the world (or in some geographical area) -- without
> having either non-coercively received it from legitimate owners (by
> means of sale or gift) or "homesteaded" previously-unowned resources
> himself -- and then proceeds to enforce that claim through violence;
> that is, engages in politics.
I'll have to ask you to define "legitimate owners", as it seems they
could only be people whose coercion occurred before day one of the new
system.
I know of no legal system (broadly defined to include primitive
cultures') in history where some land was owned and some was unowned.
Per your suggestion, I've read 'The Non Sequitur of the Dependence
Effect'. Please explain what your economic theories have to say about
the marketing of cigarettes. Are smokers rational economic actors? [I'm
an ex-smoker. Are you, or have you been a smoker?]
Don't think we didn't notice your removing the ad hominem sig and making
an ad hominem attack.
--
Cameron MacKinnon
Toronto, Canada
On Sun, 04 Apr 2004 05:54:49 -0400, Cameron MacKinnon wrote:
> Paul Foley wrote:
>> On Thu, 01 Apr 2004 07:29:29 -0800, Frank A Adrian wrote:
>>
>>> In addition, I have a fundamental belief that economies, as human created
>>> (and regulated) things, have some responsibility to bring benefit to their
>>> participants
>> The natural economy ("free market") always benefits its participants,
>> by definition (nobody would trade if he didn't benefit by it!); the
>> logical corollary is that any coercive interference in the economy
>> necessarily disadvantages at least some of the participants (otherwise
>> no coercion would be necessary). Thus the combination of your
>> professed "fundamental belief" and your implied advocacy of
>> protectionism is hard to fathom.
> This is all very well in an Adam Smith world where all goods are
> tangible,
What makes you think being tangible has any relevance?
> temporary intellectual property monopolies aren't addressed
"intellectual property" and "monopolies" are both aspects of politics
(coercion). Insurance companies (the natural providers of most of the
legitimate functions of government -- i.e., security) would/could
enforce neither.
> and large organizations haven't yet figured out how to use market
> and/or political power to stifle or absorb smaller competitors.
Because there isn't any way to use "market power" to do that (except
by doing a better job, or buying them -- a win for all concerned!)
Political power, yes, but surely you're not seriously suggesting that
the answer to politics is even more politics? [And if you're drowning,
adding more water might help?]
--
Oh dear god. In case you weren't aware, "ad hominem" is not latin for
"the user of this technique is a fine debater."
-- Thomas F. Burdick
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
Paul Foley wrote:
>>This is all very well in an Adam Smith world where all goods are
>>tangible,
>
> What makes you think being tangible has any relevance?
>
>> temporary intellectual property monopolies aren't addressed
>
> "intellectual property" and "monopolies" are both aspects of politics
> (coercion). Insurance companies (the natural providers of most of the
> legitimate functions of government -- i.e., security) would/could
> enforce neither.
>
>>and large organizations haven't yet figured out how to use market
>>and/or political power to stifle or absorb smaller competitors.
>
> Because there isn't any way to use "market power" to do that (except
> by doing a better job, or buying them -- a win for all concerned!)
> Political power, yes, but surely you're not seriously suggesting that
> the answer to politics is even more politics? [And if you're drowning,
> adding more water might help?]
Normally I'd just ignore this, but your economic idealism rather reminds
me of myself as a young man, so I'll give you some pointers which may
allow you to be cynical beyond your years.
First, insurance companies: Your earlier post stated that bargains are
not struck in a free market unless both sides see a gain. All fine for
cash & carry, but an insurance premium is paid now against possible
benefits far in the future. Insurance is one of the most heavily
regulated industries in the world, for reasons which should be obvious.
Don't bore me with fanciful tales of free market solutions; fraud
artists are attracted to large piles of cash, some of them get MBAs
first, and some of them manage to fool, browbeat or buy the accountants.
This illustrates a tendency with financial markets in general -
sophisticated players will fleece unsophisticated ones, absent stringent
controls and the credible threat of incarceration. The free marketer's
solution tends towards removing regulation and allowing the fleeced to
serve as bad examples for the rest of us, without any clues as to how we
can avoid a similar fate. Further, the problem of how those separated
from their savings are to obtain food and shelter is often elided.
Another poster mentioned externalities. You obviously have a grasp of
the problem, as your association with hashcash as a possible solution to
spam attests. Why so silent on free market solutions to the problems of
externalities, the tragedy of the commons, etcetera?
Market power: Your "win for all concerned!" leaves out consumers. High
barriers to entry combined with predatory pricing create effective
monopolies in many areas, transportation and utilities in particular.
Rent-Seeking Behaviour (don't be fooled by narrow, public policy only
definitions) results.
If you spend the next decade or two reading the financial news, I'm
confident you'll begin to see patterns of abuse which the free market
cannot solve.
An alternative, one I'd highly recommend, is reading some of the works
of the economist John Kenneth Galbraith. He's a terrific writer,
something truly rare in the field. Start with The Affluent Society and
The New Industrial State.
Your economic theories were progressive 200 years ago, but the Dismal
Science has moved on, and your failure to address problems which have
become evident since marks you as, charitably, not well read in the
subject (but hey, I feel the same way about Milton Friedman and Robert
Heinlein).
--
Cameron MacKinnon
Toronto, Canada
On Sun, 04 Apr 2004 16:52:09 -0400, Cameron MacKinnon wrote:
> If you spend the next decade or two reading the financial news, I'm
> confident you'll begin to see patterns of abuse which the free market
> cannot solve.
If you read some real economists[1], and then spend the next decade or
two reading the financial news, I'm confident you'll begin to see that
all these "patterns of abuse" are caused entirely by coercive
interference and wouldn't be possible in a free market.
[1] as opposed to a certain Nazi-sympathiser mathematician who only
took economics for a single term and remained "abysmally read on
economic literature", and whose economic magnum opus contradicts
itself constantly... (that would be John Maynard Keynes)
> An alternative, one I'd highly recommend, is reading some of the works
> of the economist John Kenneth Galbraith. He's a terrific writer,
> something truly rare in the field. Start with The Affluent Society and
Then read Hayek taking it apart in "The Non-Sequitur of the
`Dependence Effect'" :-)
And then go and read Ludwig von Mises's _Human Action_ (also a
terrific writer...but a terrific economist, too!)
Anyway, followups to me, pending creation of comp.lang.lisp.economics :-)
--
It is a far, far better thing to have a firm anchor in nonsense than to
put out on the troubled sea of thought.
-- J. K. Galbraith
(setq reply-to
(concatenate 'string "Paul Foley " "<mycroft" '(··@) "actrix.gen.nz>"))
John Thingstad <··············@chello.no> writes:
> Not so much the end of programming.
> But outsourcing of programming to India and other eastern nations
> with low salary rates.
> I belive this is a real threat.
Don't worry. The real thread is not to the people. It's to the taxman
and his subsidiaries. From one country to the other, the difference of
prices is mostly due to the tax structure applied in each contries.
If all countries had the same taxes (preferably none), the prices
would be the same everywhere (corrected for the physical costs of
producing and delivering goods).
--
__Pascal_Bourguignon__ http://www.informatimago.com/
There is no worse tyranny than to force a man to pay for what he doesn't
want merely because you think it would be good for him.--Robert Heinlein
http://www.theadvocates.org/
> Edi Weitz wrote:
>
> > The book includes an interview with KMP ("On the side of budget, I
> > have to say that the open source marketplace is I think the single
> > greatest threat to forward advance in computer science.") which is
> > available online:
(I agree with Andr� that here he seems to mean "free as in beer".)
From the interview:
"On the side of budget, I have to say that the open source
marketplace is I think the single greatest threat to forward
advance in computer science. By giving technology away,
programmers drive down the price of things. A consequence of
this is that it's hard to command a decent price for
programming products, and that means fewer dollars to pay for
jobs for programmers, if indeed programming can be done as a
job at all. Free market business will squeeze every dollar out
of something that it can, and if it finds that people will
program for free, it will make sure that no one ever gets paid
for programming."
<http://www.approximity.com/produktiver_programmieren/pitman_en.html>
It seems to me he is really saying "academic funding comes from
businesses seeking marketplace advantage, what do these wackos think
they are doing?"
I think academic funding (in the US at least, I don't know about
elsewhere) has been waaaay too tied into the short-term,
shareholder-pleasing machinations of corporate America for waaaaay to
long now anyway. College/University education should *not* be
primarily about getting a job - isn't that what technical/trade
schools are for? I think that we in the US have made a grave error in
that respect, one we - rather, our children - are only beginning to
feel the misery of.
I have been employed developing software for 25+ years, and free as in
libr� software first 'ping'ed on my radar 10 years ago.
Over the years I've gradually come to the realization that RMS
(Richard M. Stallman) might just be a personage on par with the
Founding Fathers of the United States. He is presently about as
(un)popular, and in the same ways with same sorts of people, FWIW -
e.g., vested interests are becoming alarmed at what had been an
somewhat amusing, if misguided, nuisance.
I, too, at first thought developing "free as in beer" software was at
best self-defeating. But actually the fundamental property that
Richard Stallman insists on is "free as in speech", and that alters
the entire resulting computation - "free as in beer" is not at all
*required* by the GNU Public License, but it does seem to be
encouraged.
Consider also Lawrence Lessig's "Code and Other Laws of Cyberspace".
<http://cyberlaw.stanford.edu/code/>
I have the book, and the part pertinent here may be summarized as:
* Computers act according to how they are programmed - the code they
run. Programs decide not only *what* you can do on a computer, but
also *how* you do it, what is recorded about what you did, who is
notified of what you did, etc.
* Just as a particular government consists of its legal code, i.e.,
laws, cyberspace consists of its legal code, i.e., software, so we
had better choose how we architect and maintain cyberspace no less
carefully and thoughtfully than did the 'programmers' of the US
Constitution if we as individuals wish to continue having 'rights'
in cyberspace.
* As the functioning of society becomes dependent on the procedures
encoded into software (if it isn't already), shouldn't we carefully
consider how those 'codes' get written?
In a sense, Lessig asks "Do we want for-profit corporations writing
our laws?" and Stallman states "We must fight for and retain our
rights in understanding and shaping our laws!". (Though for Stallman
it is also concerns a fundamental right to sharing and the fruits of
one's creativity, however contradictory that last might sound.)
Long Live the FSF!
--
If we had less statemanship we could get along with fewer battleships.
-- Mark Twain (1835 - 1910)
Chris Hall wrote:
>
> From the interview:
>
> "On the side of budget, I have to say that the open source
> marketplace is I think the single greatest threat to forward
> advance in computer science. By giving technology away,
> programmers drive down the price of things. A consequence of
> this is that it's hard to command a decent price for
> programming products, and that means fewer dollars to pay for
> jobs for programmers, if indeed programming can be done as a
> job at all. Free market business will squeeze every dollar out
> of something that it can, and if it finds that people will
> program for free, it will make sure that no one ever gets paid
> for programming."
Well, I'm going to draw an analogy; the market for programming
is a lot like the market for sex.
Because some people will provide sex without getting paid, market
forces and the free market (here expressed as conventional morality,
laws about fornication and prostitution, and religious beliefs)
squeeze every dollar out of the market in an attempt to make sure
that no one ever gets paid for having sex.
Nevertheless, a lucrative market for sex still exists, and people
who make a living by providing sex for pay exist in every city.
The sex they provide isn't the highest-quality sex available by
any means, and costs more than the "free" alternatives - so how
can this be?
The fact is that the people who make up the market for professional
providers of sex (or software) often are those who require some sort
of specialty product that's not freely available or for which they
haven't been able to successfully negotiate with cost-free providers.
Frequently they are forced to pay for sex (or software) because
providing what they want offers no satisfaction, pride in a job well
done, stability, or sense of purpose to the provider.
Now, I think that everybody should have both software and sex;
these things are unambiguously good, as opposed to their absence.
Blessed are those for whom the free stuff is satisfying to produce
and use; generally the sex (or software) is better in quality, less
risky to use, and more stable in its supply. It is satisfying both
to produce and use, and frequently the very best providers are also
the most appreciative consumers.
But let's not repeat the mistakes we made with sex and denigrate
those who require or provide the specialty markets as well; the
universe is broad, and not everything (or everyone) will be
catered by those who provide for free.
Bear
Andr� Thieme <······································@justmail.de> writes:
> Edi Weitz wrote:
>
> > The book includes an interview with KMP ("On the side of budget, I
> > have to say that the open source marketplace is I think the single
> > greatest threat to forward advance in computer science.") which is
> > available online:
>
> software which sources are open, I can agree to it to some part.
> Although some pieces of free software can also have some positive
> effects for the market.
>
> Andr�
> --
I forgot to mention: in my experience, by *far* the bulk of money made
in actual programming is made either a) customizing existing packages
to meet the specific needs of a specific business or b) developing
custom software to meet the (constantly changing) business needs of a
specific business.
Most free software consists of tools - software to develop or deploy
software - accounting packages, etc., simply aren't there yet.
I don't see how having high quality free tools will harm the bulk of
programmers, since the real 'bread and butter' stuff is in
customizations. And the data available on say, Sourceforge, mailing
lists, bug trackers, etc., for furthering the science in relation to
programming and development is surely a goldmine?
And (no disrespect to the many extremely bright and hardworking people
there) I fail to see how Microsoft (the most successful software
vendor ever) products have advanced the state of programming in any
fundamental way. Visual Basic? Excel macros? 'Refined' Java? (Oops!
I meant .Net?) They use software to create products that shareholders
can make money off of - not to further the art and science.
And in practice, I've found Microsoft products likely to be more of a
hindrance than otherwise - they are generally usable, but usually
frustrating at best if one is trying to do anything other than
straightforward, basic tasks. (Which are, in my experience, a smaller
subset of business computing than I would have ever imagined.) Not
infrequently, free software has been of some help in working around
the limitations of a commercial package - such things can be very
important to consultants, especially.
--
If we had less statemanship we could get along with fewer battleships.
-- Mark Twain (1835 - 1910)
Chris Hall wrote:
> And (no disrespect to the many extremely bright and hardworking people
> there) I fail to see how Microsoft (the most successful software
> vendor ever) products have advanced the state of programming in any
> fundamental way. Visual Basic? Excel macros? 'Refined' Java? (Oops!
> I meant .Net?) They use software to create products that shareholders
> can make money off of - not to further the art and science.
What do you think about Oracle?
P.S. Please fix the typo in your .sig
--
Cameron MacKinnon
Toronto, Canada
Cameron MacKinnon <··········@clearspot.net> writes:
> Chris Hall wrote:
>
> > And (no disrespect to the many extremely bright and hardworking people
> > there) I fail to see how Microsoft (the most successful software
> > vendor ever) products have advanced the state of programming in any
> > fundamental way. Visual Basic? Excel macros? 'Refined' Java? (Oops!
> > I meant .Net?) They use software to create products that shareholders
> > can make money off of - not to further the art and science.
>
>
> What do you think about Oracle?
>
I've used for Oracle database for several projects, and I've found it
robust, predictable and gratifyingly tunable.
I've used Oracle Forms and Oracle Reports a couple of times - so so.
P.S. I changed the .sig instead - I didn't notice a typo? 8*/
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
Cameron MacKinnon <··········@clearspot.net> writes:
>
> What do you think about Oracle?
>
Too, I have no idea what sort of work they have put into their query
optimizer, space allocation strategies, etc., but from what I've seen
and read leads to me to think may have made real contributions - and I
haven't checked to see if they've published anything - i.e., shared.
Why do you ask?
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
"Chris Hall" <·······@verizon.net> wrote in message
······················@naia.homelinux.net...
> And (no disrespect to the many extremely bright and hardworking people
> there) I fail to see how Microsoft (the most successful software
> vendor ever) products have advanced the state of programming in any
> fundamental way. Visual Basic? Excel macros? 'Refined' Java? (Oops!
> I meant .Net?) They use software to create products that shareholders
> can make money off of - not to further the art and science.
How have these products advanced the state of programming?
Simple, they've lowered the barrier of entry.
Excel macros, particularly its "watch me" function, gives "non-computer"
business folks a door through which they can make their daily tasks more
productive for themselves. It lets them mold their environment.
If an Excel person starts with "watch me", they can learn by example how the
computer does certain things, and how those tasks are communicated to the
computer for later automation. The fact that this knowledge is captured in
VBA actually gives this person a leg up if they every want to move on to
more generic VB.
Since there is a commonality between VB and VBA, the user can employ that
powerful carbon based pattern recognition system in their skull to adapt the
patterns that they saw created for them in VBA in new ways in VB.
Anything that lets users leverage these machines in front of them better is
a good thing. Many a vertical package has been hacked together by
underqualified programmers that happen to know their real area of expertise
very well, and these packages then end up helping others as well.
They may not advance the Art Of Programming but they enable more people to
become programmers, even rudimentary ones. And that advance other aspects of
society in their own way, and that can't necessarily be a bad thing.
Let the Little People program I say. Just don't make me maintain it :-).
Regards,
Will Hartung
(·····@msoft.com)
"Will Hartung" <·····@msoft.com> writes:
> "Chris Hall" <·······@verizon.net> wrote in message
> ······················@naia.homelinux.net...
>
> > And (no disrespect to the many extremely bright and hardworking people
> > there) I fail to see how Microsoft (the most successful software
> > vendor ever) products have advanced the state of programming in any
> > fundamental way. Visual Basic? Excel macros? 'Refined' Java? (Oops!
> > I meant .Net?) They use software to create products that shareholders
> > can make money off of - not to further the art and science.
>
> How have these products advanced the state of programming?
>
> Simple, they've lowered the barrier of entry.
Granted - and that is no small thing.
> Excel macros, particularly its "watch me" function, gives "non-computer"
> business folks a door through which they can make their daily tasks more
> productive for themselves. It lets them mold their environment.
I've done some surprising things with Excel - stuff I was asked to
look at and improve. I was intrigued by what I was able to coax out
of Excel. To this day, it is the one product of theirs that I feel
good about, and will unreservedly recommend - to people running
Windows. ;-)
> If an Excel person starts with "watch me", they can learn by example how the
> computer does certain things, and how those tasks are communicated to the
> computer for later automation. The fact that this knowledge is captured in
> VBA actually gives this person a leg up if they every want to move on to
> more generic VB.
Ayup. And I saw a posting somewhere (I think in a Python group) how
one person learned the essentials of functional programming in Excel -
claims he still uses it to model things quickly - though I think most
modern spreadsheets would serve as well.
> Anything that lets users leverage these machines in front of them better is
> a good thing. Many a vertical package has been hacked together by
> underqualified programmers that happen to know their real area of expertise
> very well, and these packages then end up helping others as well.
>
> They may not advance the Art Of Programming but they enable more people to
> become programmers, even rudimentary ones. And that advance other aspects of
> society in their own way, and that can't necessarily be a bad thing.
>
I agree wholeheartedly - have for years - but on the downside, these
same people also seem to be 'learning' that software is essentially
unreliable - since the Microsoft world is all they know. But at least
they *are* seeing for themselves how pliable software can be, even if
they have to accept the limitations that Microsoft enforce/build in.
> Let the Little People program I say. Just don't make me maintain it :-).
>
LOL! And as for the 'Little People' - I can remember when 'end-user
computing' was all the rage here in the US, when people thought
programming would be an essential skill learned early in school,
something akin to basic addition and multiplication. *sigh*
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
Chris Hall <·······@verizon.net> writes:
> Ayup. And I saw a posting somewhere (I think in a Python group) how
> one person learned the essentials of functional programming in Excel -
> claims he still uses it to model things quickly - though I think most
> modern spreadsheets would serve as well.
Simon Peyton Jones et al have a paper on FP for Excel, if you're
interested. Matlab might be an in-between fit (matrices, kind-of
higher-order functions, Excel interface, ...).
Best,
Thomas
--
Thomas Lindgren
"It's becoming popular? It must be in decline." -- Isaiah Berlin