worse is worse (how to win, at last)
Tom Lord
Perhaps part of the reason lisp, scheme, and the ml-family fail to get
much support in the industry can be traced back to some famous
failures.
For a long time (as nearly as I can reconstruct), there was a
horse-race between lisp machines and "stock hardware". Lisp hardware
was more expensive, some systems had notorious bugs ("it's cheaper to
reboot than garbage collect"), lisp implementations on stock hw
languished for a long time, minis and then micros and workstations
were more cost effective. Boom -- the bottom dropped out of
commercial support for lisp work. Of course, this failure has no
rational relevence when comparing, say, scheme and tcl or python in
1995 -- but that doesn't stop it from having effect.
Then there was Lucent Inc. You can read Gabriel's account of what
happened there -- it doesn't seem to have been a problem with lisp per
se (more with bad mgt / bad investing policy). Again: no rational
reason to pin it on lisp, but that's a fairly predictable outcome.
And then there's 1980's commercial AI. And then there's all the
"funny" jokes in emacs vs. vi flames. No rational connection, sure,
but to shallow eyes: they guys with all the parentheses are reliably
the butt of the joke. Nobody ever got fired for firing a lisp hacker.
When I tried doing Scheme work in a commercial context, one big
obstacle was the set of prejudices people had against everything
lispish. It was an irrational prejudice, and never explicitly stated
enough to answer -- but it was there.
It's not just lisp failures, either. There's also a prejudice against
trying to do things carefully and well. There's a high premium on
doing rush jobs, by any means necessary, regardless of the
consequences.
Contrasting "carefully and well" with the claim that what's actually
going on is "rush jobs, by any means necessary" amounts to issuing
fighting words. It's confrontational. It flies against the accepted
wisdom to say "harsh" things like that -- but I don't think the
accepted wisdom is really helping us. So let's look deeper into this
contrast.
I really like Olin's introduction to structured regexps (the "100%
solutions" essay). That work comes from the perspective that you
invest a bit more up front, building foundations, and then you enjoy
many years of payoff putting up structures on those foundations. As
Olin put it:
There's a problem with tool design in the free software
and academic community. The tool designers are usually
people who are building tools for some larger goal. For
example, let's take the case of someone who wants to do
web hacking in Scheme. His Scheme system doesn't have a
sockets interface, so he sits down and hacks one up for
his particular Scheme implementation. Now, socket API's
are not what this programmer is interested in; he wants
to get on with things and hack the exciting stuff -- his
real interest is Web services. So he does a quick 80%
job, which is adequate to get him up and running, and
then he's on to his orignal goal.
Unfortunately, his quickly-built socket interface isn't
general. It just covers the bits this particular hacker
needed for his applications. So the next guy that comes
along and needs a socket interface can't use this one.
Not only does it lack coverage, but the deep structure
wasn't thought out well enough to allow for quality
extension. So *he* does his *own* 80%
implementation. Five hackers later, five different,
incompatible, ungeneral implementations had been
built. No one can use each others code. [I would add
that often they reuse each others code anyway -- and
the impact of the problems with that code is thereby
multiplied -tl]
The alternate way systems like this end up going over a
cliff is that they get patched over and over again, and
what one ends up with is more 80% bandaids and 20%
structured code. When systems like DOS evolve
organically into systems like Win95, it's unsuprising
and unavoidable that what one ends up with is a horrible
design. [I would add a more modern example. I think
that once-simple web applications have gone down this
route in the past half decade. -tl]
As an alternative to five hackers doing five 80%
solutions of the same problem, we would be much better
off if each programmer picked a different task, and
really crushed it -- a 100% solution. Then each time a
programmer solved a problem, no one else would have to
redo the effort. Of course, it's true that 100%
solutions are significantly harder to design and build
than 80% solutions. But they have one tremendous
labor-savings advantage: you don't have to constantly
reinvent the wheel. The up-front investment buys you
forward progress; you aren't trapped endlessly
reinventing the same awkward wheel.
Now, I claim that the 100% solution approach has two properties:
1) That approach is The Right Thing. It's right for programmers,
because it allows them to focus on craft, develop as programmers
and people, and feel good about themselves for good reasons. It's
right for customers and society generally, because it results in
better, more tractable, more trustworthy computing systems. It's
right for companies doing development, because it means they are
clearly in the business of creating lasting value and solving
problems rather than providing immediate utility while creating new
problems.
2) The 100% solution approach has no survival characteristics in
business. At this point in history, proposing a 100% solution
to your boss is like saying "Please turn me down."
So far I sound like I'm going to say "worse is better" and propose a
workaround for problem (2) so we can all "win big", right? No. I'm
not. Gabriel's "How to Win Big" essay has been on the table for years
now, and while it contains some neat ideas about how to evolve lisp,
it hasn't worked (unless you think Java, which is fiscally "winning"
in some markets, is converging on "better" rather than "worse").
So instead of trying to come up with some stealth strategy for winning
big by ramping up from worse to better, I think we should look at
_why_ 100% solutions are unwelcome in commercial development, and see
if we can't fix those problems directly.
Again, I think it has to do with ambitious failures of the past --
attempts at 100% solutions that turned into boondoggles.
Multics was supposed to be a 100% solution and its fans still swear
that, in some ways, it was! But it was a huge project that cost too
much and needed too much hardware. It was hopelessly impractical. It
was a money sink. Unix (Gabriel's canonical "worse" solution) was
lighter and tighter, and spread like wildfire. So ambitious design
got a bad rap.
It's not rational to apply that bad rap to someone who wants to do
Scheme R&D today: the multics guys failed to take minicomputers into
account and didn't think twice about producing a monolithic design --
very fundamental mistakes that have nothing to do with ambition per
se. Unix _could_ have been an early byproduct on the path to multics
(and these days, some say, unix is evolving into multics).
Nevertheless, given the multics legacy, if you say in a meeting "I
think we should step back and make sure we do this right", a lot of
people hear "I think we should waste a lot of money and not produce
anything," and if they want to try to be kind, they'll hand you a copy
of "The Mythical Man-Month".
I think there are lots of less famous ambitious projects that have
failed for a sales-driven reason. Here's how it goes:
Let's say you are at some fictional workstation vendor, Unixcorp: a
big company with lots of separately-acting groups of hackers. Sales
identifies a strategic technology need (say, a UI toolkit). Multiple
groups go off to compete to fill that need.
Group A estimates that it's a serious, long-term need, that deserves a
100% solution. They do lots of research about what's been tried.
They start to map out the design space. They apply reasonable
techniques to avoid the kinds of pitfalls that killed Multics.
Because budgets are hard to obtain at all, they are inclined to fib,
Pentagon-papers style, to the higher ups about how long it will take
and how much it will cost. At about the time they first estimated
they'd be done -- they have the beginnings of a really great solution
and the beginnings of the desired functionality -- but they aren't
done. Group A is betting that the customers and higher ups will sit
down and evaluate this new design in depth, and support its
completion.
Group B is a bunch of tactical hot-shots. They go fast, take
short-cuts, create future problems -- they don't care about what
happens down the road: but on the due-date, they have a
product that's "good enough to ship". The sales team is ecstatic and
group B gets bonuses.
So far, that's not a bad thing. The rational thing to do is: yes,
ship Group B's product, but then also evaluate Group A's work in
depth. If group A really is converging on a 100% solution, then take
the revenue from group B's product and apply it to finish group A's
work. It's that simple -- the competition had a rational effect.
But no -- that's not what happens. What happens is that group A's
work _isn't_ evaluated in any greater depth than "Group B won the
race!". Group A's project is canceled, and the people that work on it
are discredited and scattered. Revenue is used to continue group B's
solution without much thought of where it's going. The programmers
lose, because the work that went into the careful solution is thrown
away. Customers lose, because now they're stuck forever with the
inferior architecture and the new problems it creates. The company
loses because the best hackers stay in touch via "bad attitude"
mailing lists, take their first exit opportunity, and eventually leave
the industry entirely. Everybody loses because the rush-job
architecture becomes mandatory, while the careful architecture _never
happens_.
I don't have any pithy solution. I don't know on which donkeys to pin
these tails. I have some suggestions, to nobody in particular, but to
a lot of people in general:
1) Don't cancel competing projects for the wrong reasons.
When projects compete, taking wildly different approaches, often
that's important and rational. The slower-moving projects aren't
necessarily wrong: on the contrary, they may be the best long-term
path. Take advantage of the short-cut projects to fund long-term
projects that are good.
2) Don't fib to the higher ups.
If you want to do ambitious design, admit it. You don't need to
obtain a commitment of funding-til-completion -- and that kind of
commitment would probably be a bad idea anyway. The "higher ups"
need to learn to invest in ambition, but they can't do that if you
always hide it from them.
3) Don't manage by analogy.
So, multics and lisp machines failed. Big deal. What does this
have to do with the project in front of you? Nail the details,
learn the craft. If you are an exec or high-level manager, make
sure you can set aside 30% of your time to continue being a hacker
and concentrate on improving your skills, breadth of understanding,
and depth of insight. Understand the business you are in.
Managing programming is not like managing a baseball team. Famous
or notorious projects in history may or may not have any meaningful
relation to the problems in front of you. How can you know unless
you dig in and study the details.
4) Start dialogs.
If you are regularly frustrated in your attempts to do ambitious
work, make that an issue, and put it on the table.
5) Don't trash your peers.
So, you're on team B. You got the bonus -- do you really have to
shore up your position by defaming team A?
Or you're on team A. Team B is not the enemy. They're your
funding source. They've also explored some parts of the design
space and obtained early customer feedback -- so you can learn from
them.
6) It's not rude to point out problems or devastating to have them
pointed out to you.
So, team A has a lot of pointed criticisms of the work team B has
done. That isn't "confrontational" or "anti-collegial" -- that's
engineering process. Sweeping problems under the rug or labeling
the debate an instance of "that guy's got bad attitude, coach" is
irresponsible engineering.
7) Don't manage by "consensus".
Some managers manage, implicitly or explicitly, by votes.
Simultaneously, they create an atmosphere of office politics where
job security and compensation levels hinges on the short-term
outcome of those votes. This is a recipe for disaster because
it misaligns the motivations of the people whose votes you collect:
they're voting on their pay, not on the engineering issues.
Barry Margolin
Tom Lord <lo...@emf.emf.net> wrote:
>Then there was Lucent Inc. You can read Gabriel's account of what
>happened there -- it doesn't seem to have been a problem with lisp per
>se (more with bad mgt / bad investing policy). Again: no rational
>reason to pin it on lisp, but that's a fairly predictable outcome.
You mean Lucid, Inc. Lucent was what Bell Laboratories turned into.
--
Barry Margolin, bar...@genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Adrian Kubala
> I think we should look at _why_ 100% solutions are unwelcome in
> commercial development, and see if we can't fix those problems
> directly.
This is a tangent, but two things occur to me.
1. 100% solutions are a product of serendipity and inspiration more
than hard work. So even if you set out for one, you might not get
there. Examples: obvious one, computers in general are turning out
to be the 100% solution for lots of things that Turing never
dreamed of. Something like monads, which I consider a 100% solution
to imperative programming in a functional substrate, were never
designed by category theorists for that purpose. Etc.
2. Serendipity also means that today's 100% will be blown away by
tomorrow's... so one wonders whether the investment is worthwhile.
It depends on how long you think it'll take for the next paradigm
shift, but they seem to be coming faster and faster.
adrian
Tom Lord
Oops.. that one always gets me.
-t
Tom Lord
1. 100% solutions are a product of serendipity and inspiration more
than hard work. So even if you set out for one, you might not get
there. Examples: obvious one, computers in general are turning out
to be the 100% solution for lots of things that Turing never
dreamed of. Something like monads, which I consider a 100% solution
to imperative programming in a functional substrate, were never
designed by category theorists for that purpose. Etc.
Olin's (and my) essay are about system design. Olin's is especially
about library design. Both are about systems with multiple
components, where the collection of components either work well
together and cover the problem space or don't.
Mondads are not a system -- they're an isolated language feature.
Serendipity and inspiration are important: but they aren't accidents.
I think there are examples of serendipity and inspiration in SCSH and
the structured regexps library -- but they wound up there because Olin
set out to make a 100% solution. He didn't get conked on the head by
a falling apple then rush off to write down SCSH: he studied the
problem domain (deeply), brought in his accumulated experience, and
(reliably, unsurprisingly) made serendipitous discoveries. Why?
Because he wasn't rushing to knock up a quick library for some other
work -- he was deliberately taking the time necessary to make
libraries that _solved_ their problem domains. His designs aren't
lucky coincidences -- they're the result of his having had the
opportunity to make some ambitious designs.
(Of course, SCSH and the regexp library were _not_ commercial
projects. These days, they could not be.)
2. Serendipity also means that today's 100% will be blown away by
tomorrow's... so one wonders whether the investment is worthwhile.
It depends on how long you think it'll take for the next paradigm
shift, but they seem to be coming faster and faster.
I don't think so. SCSH, for example, is hardly new -- but good luck
finding a subsequent design that does a better (or even as good a) job
providing a nice interface for subprocess mgt. SCSH has
(demonstrated) lasting value. Incremental expansions/variations are
possible -- but the design is _still_ the most solid in the field
after all these years.
-t
Anton van Straaten
> head by a falling apple then rush off to write down SCSH: he studied
> the problem domain (deeply), brought in his accumulated experience,
> and (reliably, unsurprisingly) made serendipitous discoveries. Why?
> Because he wasn't rushing to knock up a quick library for some other
> work -- he was deliberately taking the time necessary to make
> libraries that _solved_ their problem domains. His designs aren't
> lucky coincidences -- they're the result of his having had the
> opportunity to make some ambitious designs.
The above paragraph encapsulates why this sort of thing is so rare. "Taking
the time necessary" is a luxury that most businesses don't have - and this
is frequently not much more of a choice for them, than it is for the
programmer who ends up implementing the hacked throwaway shortcut solutions.
The only businesses that can obviously afford to work on 100% solutions are
those that have their own research divisions, divorced from the pressures of
producing end products to satisfy their partners and customers.
To take one of the examples you mentioned, cancelling competing projects
when another "worse" project works first - I've had to make those exact
decisions. In one case, the cancelled project was my own, and I was the one
who decided to cancel it - but this was done because of resource constraints
(specifically people, money & time). Even if the business ends up paying
for that decision for years afterwards, the bottom line is that they got
something they needed, when they needed it.
We don't have time machines or good enough predictive capabilities to be
able to run a simulation and say "hey, look how much better the business
would be doing in five years time, if we just turn down this multi-million
dollar contract because we can't handle it, and focus on systems building
instead!" In any case, that simulation might in fact show that the business
would flounder as a result of avoiding growth opportunities, more aggressive
competitors would eat its lunch, and those competitors would be the ones to
develop the cool systems that we wish we could have developed if we'd only
had the time & money.
So much of this is just the natural consequences of businesses being
specialized, and competing with each other. Hey, I have an idea - we could
set up a system in which the allocation of resources and development effort
is centrally controlled, maybe by the government, so that everything
operates much more efficiently - wait, this is ringing a bell...
I'm not being critical, I just work in some of the trenches you talk about.
It's extremely difficult for individual people or companies to buck systemic
trends. The day Wall Street stops focusing on results on a quarterly basis,
will be the day you start seeing some of these things change.
I'm not saying to throw up hands and give up - there are things that can be
done, and you covered some of them in your first message. One thing that I
think could help is the increasing awareness and more proactive use of open
source and/or free software in business - if we pool our efforts on all
those 80% solutions, especially when it's for software that isn't directly
related to a profit center for a company, quite a few more 100% solutions
could arise. Right now, businesses mostly look askance at open source, even
when they're actually depending on it - but that looks to me as though it'll
change, it's just that there's an education and assimilation process that
has to take place.
Anton
Sander Vesik
>
[snip]
> Group B is a bunch of tactical hot-shots. They go fast, take
> short-cuts, create future problems -- they don't care about what
> happens down the road: but on the due-date, they have a
> product that's "good enough to ship". The sales team is ecstatic and
> group B gets bonuses.
>
> So far, that's not a bad thing. The rational thing to do is: yes,
> ship Group B's product, but then also evaluate Group A's work in
> depth. If group A really is converging on a 100% solution, then take
> the revenue from group B's product and apply it to finish group A's
> work. It's that simple -- the competition had a rational effect.
See, the problem is that this (fundametaly) can not happen - once you shipped
that toolkit, your customers will have been using it and built their own
infrastructure on top of it. If they now go away from it, customers are
likely to enmasse move to somewhere else - and unixcorp will go bankrupt.
>
> But no -- that's not what happens. What happens is that group A's
> work _isn't_ evaluated in any greater depth than "Group B won the
> race!". Group A's project is canceled, and the people that work on it
> are discredited and scattered. Revenue is used to continue group B's
> solution without much thought of where it's going. The programmers
> lose, because the work that went into the careful solution is thrown
> away. Customers lose, because now they're stuck forever with the
> inferior architecture and the new problems it creates. The company
Once they deployed solution B the customers are stuck with B anyways.
> loses because the best hackers stay in touch via "bad attitude"
> mailing lists, take their first exit opportunity, and eventually leave
> the industry entirely. Everybody loses because the rush-job
> architecture becomes mandatory, while the careful architecture _never
> happens_.
>
> I don't have any pithy solution. I don't know on which donkeys to pin
> these tails. I have some suggestions, to nobody in particular, but to
> a lot of people in general:
>
>
> 1) Don't cancel competing projects for the wrong reasons.
>
> When projects compete, taking wildly different approaches, often
> that's important and rational. The slower-moving projects aren't
> necessarily wrong: on the contrary, they may be the best long-term
> path. Take advantage of the short-cut projects to fund long-term
> projects that are good.
Its much better not to create competing projects. Decide on a strategy and
execute on it.
>
> 5) Don't trash your peers.
>
> So, you're on team B. You got the bonus -- do you really have to
> shore up your position by defaming team A?
>
> Or you're on team A. Team B is not the enemy. They're your
> funding source. They've also explored some parts of the design
> space and obtained early customer feedback -- so you can learn from
> them.
Right, this is really true.
---
Sander
+++ Out of cheese error +++
Jeffrey Siegal
> In article ,
> Tom Lord wrote:
>
> >Then there was Lucent Inc. You can read Gabriel's account of what
> >happened there -- it doesn't seem to have been a problem with lisp per
> >se (more with bad mgt / bad investing policy). Again: no rational
> >reason to pin it on lisp, but that's a fairly predictable outcome.
>
>
> You mean Lucid, Inc. Lucent was what Bell Laboratories turned into.
Western Electric turned into Lucent (with about ten years in between as AT&T
Technologies). Bell Laboratories was just one part of the deal.
Eli Barzilay
> See, the problem is that this (fundametaly) can not happen - once
> you shipped that toolkit, your customers will have been using it and
> built their own infrastructure on top of it. If they now go away
> from it, customers are likely to enmasse move to somewhere else -
> and unixcorp will go bankrupt.
Uh, interfaces? (Even if the interface sucks, you can usually finish
your 100% solution, and then hack a quick compatible interface, while
encouraging users to switch... (Obviously depends on the product and
the users, but it shouldn't be that hard if you pass the initial
convince-the-management--to-go-for-a-100%-solution test.))
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Anton van Straaten
> execute on it.
Sometimes "competing" projects don't start out that way. For example, you
start on a short-term solution, and at the same time start on a longer-term
solution, which will take longer to delivery but have better characteristics
for long-term evolution. I've seen this kind of thing go in multiple
directions - in practice, competition happens. Managed properly, it can be
a good thing and produce a good result - but, you actually have to be
willing to allow things to fail when it makes sense to do so. The original
vision isn't necessarily what drives the end result.
Anton
Jeffrey Siegal
Siegfried Gonzi
> The above paragraph encapsulates why this sort of thing is so rare. "Taking
> the time necessary" is a luxury that most businesses don't have - and this
> is frequently not much more of a choice for them, than it is for the
> programmer who ends up implementing the hacked throwaway shortcut solutions.
> The only businesses that can obviously afford to work on 100% solutions are
> those that have their own research divisions, divorced from the pressures of
> producing end products to satisfy their partners and customers.
I very much doubt that programs become better provided they can be
written in a luxury long time. I can speak just for myself: Nobody ever
imposed any time constraints on my programming, however, I am quite
sure I do not write better programs. I think there is a limit what
people are ready to invest in programming, because writing programs as
demonstrated in books is hard in the long run.
I think people should abandon the idea that functional languages or the
like lead to better code. There does not exist any programmer on this
earth who does not write bad code, independent of his pet language.
S. Gonzi
Anton van Straaten
> like lead to better code.
For me, the point is that advanced languages provide more leverage, fewer
restrictions, and allow me to express what I want to express, and end up
with a usable, understandable result.
> There does not exist any programmer on this
> earth who does not write bad code, independent of his pet language.
Well, it's possible to learn to consistently write very good code, but one
doesn't always have the luxury of doing so. So I really disagree with this:
> I very much doubt that programs become better provided they can be
> written in a luxury long time.
My experience is that they definitely can be better, given more time, but it
obviously requires careful work by the developers, and attention to all the
usual factors that make a program successful.
> I can speak just for myself: Nobody ever
> imposed any time constraints on my programming, however,
> I am quite sure I do not write better programs.
Sorry, but I don't think that's true of everyone.
Anton
Anton van Straaten
> associate historical lisp failures with ML.
I don't believe people (managers/programmers) have *heard* of ML. In my
experience. That constitutes a bit of an acceptance problem...
Siegfried Gonzi
> My experience is that they definitely can be better, given more time, but it
> obviously requires careful work by the developers, and attention to all the
> usual factors that make a program successful.
I think this could be feasible but only then when a senior programmer is
standing behind you.
Maybe working in a team leads to better code were the collegue next to
you in his cube is waiting for your programm.
S. Gonzi
Tom Lord
I very much doubt that programs become better provided they can be
written in a luxury long time. [....]
I think people should abandon the idea that functional
languages or the like lead to better code.
Here's my view (and, this isn't intended to be persuasive -- it's just
a "mystical" report):
Coming up through the years as a programmer, a lot of bright people
gave me good ideas from all over the map. I was kind of a mascot in
some programming communities (e.g. non-PhD-track cs dept resident with
perspective enough and bright enough to be interesting to bounce ideas
around with) - it was interesting for people to filter through what
they were reading and hand me the best [*]. Lot's of conversations.
Lot's of thought experiments. Lucky me.
Language does make a difference. Scheme-ish[**] is good because it
captures many essences in the most concise form yet reduced to
practice -- few extraneous details -- programming is an exercise in
compression [***]. For example, scheme-ish hits a lot of elements that
resonate well with hw fundamentals. This is hard to explain and maybe
someday I can formalize it -- for now, all I want to say is "space
aliens program in Scheme".
Moreover, there's a bunch of systems design elements out there that
collectively cohere, and basically, just a ton of straightforward work
to do (wait till you see where Emacs winds up!). Obvious things that
could have been doing for the past 10 or 15 years, but that for
various political reasons, we haven't had the chance ("luxury long
time") to work on in any sustained way.
No, I don't expect you to believe on the basis of just this report.
You had to be there. (Or be willing to chat seriously, in person, for
more than just a few minutes or hours - maybe I'll HYPNOTIZE you).
Wow, the view's great here -- wish I had brought a camera.
Some of Anton's less "mystic" replies are worth chasing up in
net-threads, if you insist. Leave me alone.
I think people should abandon the idea that functional
languages or the like lead to better code.
You're full of crap.
"Who cares",
-t
p.s.: all my friends are dead.
[*] "hand me the best"
One ambition I have is to get rights to reprint a lot of
photocopied materials and book excerpts -- and edit a book.
[**] "Scheme-ish"
These days I have to say "scheme-ish" where formerly I would have
said Scheme because there's a silly rhetorical trend on this list
to conflate Scheme with R5RS or RnRS. Man, that's annoying.
[***] "captures many essenses"
Awk is good, too. But for different reasons.
Siegfried Gonzi
> Some of Anton's less "mystic" replies are worth chasing up in
> net-threads, if you insist. Leave me alone.
>
> I think people should abandon the idea that functional
> languages or the like lead to better code.
>
> You're full of crap.
I am over the state were I believe functional programming leads to world
peace. If I were to dispense funds for research I would not hesitate to
support the functional programming community (the intellectual
challenge), but in turn if I were the hatred manager and would decide
over the next big project I would really not mind wheter people use C++
or OCaml or Scheme.
I give you a good advice: thank God (at least once a day) for Fortran.
That is not because I believe Fortran is on the cutting edge it is
because Fortran has and still delivers numerical capablities what the
numerical computing front is greedy for. Before you whine again you
should first have a look at the manifold Fortran 90 capablities when it
comes to precision and the like. And then do not wonder when the Fortran
programmer laugh at you.
Personally, I program with pleasure in Scheme (the last few month nearly
every day) but I have never tried to convince my colleagues to use
Scheme or to have a look at functional programming languages. Though, I
sometimes mention functional programming but nothing more. There was the
situation were a colleague asked me whether he should use Perl for a web
based application (something of an remote control). I gave him the
advice he should have a deeper look at Perl and if he does not fall in
love with Perl he should have a look at Python. But I would never have
given him the advice not to use Perl. Why? People should use what they want.
S. Gonzi
Anton van Straaten
Regular code reviews are standard practice in commercial programming. The
reviewer often learns a lot too. The "Extreme Programming" approach takes
this to an extreme (naturally), by recommending programming in pairs.
All you really have to do is remember the saying: "Code as if whoever
maintains your code is a violent psychopath who knows where you live."
Anton van Straaten
> For example, scheme-ish hits a lot of elements that
> resonate well with hw fundamentals. This is hard to explain and maybe
> someday I can formalize it -- for now, all I want to say is "space
> aliens program in Scheme".
Scheme is God's assembly language...
Sander Vesik
> Sander Vesik <san...@haldjas.folklore.ee> writes:
>
>> See, the problem is that this (fundametaly) can not happen - once
>> you shipped that toolkit, your customers will have been using it and
>> built their own infrastructure on top of it. If they now go away
>> from it, customers are likely to enmasse move to somewhere else -
>> and unixcorp will go bankrupt.
>
> Uh, interfaces? (Even if the interface sucks, you can usually finish
> your 100% solution, and then hack a quick compatible interface, while
> encouraging users to switch... (Obviously depends on the product and
> the users, but it shouldn't be that hard if you pass the initial
> convince-the-management--to-go-for-a-100%-solution test.))
>
yeah, but if you had a 90% solution that clients were happy with
putting the same imperative C interface over the functional style
higher order functions and macros scheme code...
Remember - business is all about giving customers that which they
percieve as their needs.
--
David Rush
> I think there are lots of less famous ambitious projects that have
> failed for a sales-driven reason. Here's how it goes:
>
> Let's say you are at some fictional workstation vendor, Unixcorp: a
> big company with lots of separately-acting groups of hackers. Sales
> identifies a strategic technology need (say, a UI toolkit). Multiple
> groups go off to compete to fill that need.
>
> Group A estimates that it's a serious, long-term need, that deserves a
> they'd be done -- they have the beginnings of a really great solution
> and the beginnings of the desired functionality -- but they aren't
> done. Group A is betting that the customers and higher ups will sit
> down and evaluate this new design in depth, and support its
> completion.
>
> Group B is a bunch of tactical hot-shots. They go fast, take
> short-cuts, create future problems -- they don't care about what
> happens down the road: but on the due-date, they have a
> product that's "good enough to ship". The sales team is ecstatic and
> group B gets bonuses.
>
> So far, that's not a bad thing. The rational thing to do is: yes,
> ship Group B's product, but then also evaluate Group A's work in
> depth. If group A really is converging on a 100% solution, then take
> the revenue from group B's product and apply it to finish group A's
> work. It's that simple -- the competition had a rational effect.
>
> But no -- that's not what happens. What happens is that group A's
> work _isn't_ evaluated in any greater depth than "Group B won the
> race!".
If it makes you feel any better (which I doubt), this is a basic
problem with winner-takes-all games which leads to economic
inefficiency in many ways. I first encountered it as part of an
economic argument *against* patents (the point being that patents
encourage economic efficiency in a different research environment than
currently exists in many domains).
Unfortunately, the article is published only as a multi-page web
site. You can start reading it at:
<http://william-king.www.drexel.edu/top/eco/game/patent.html>
> I don't have any pithy solution. I don't know on which donkeys to pin
> these tails. I have some suggestions, to nobody in particular, but to
> a lot of people in general:
No offense intended, but your suggestions boil down to "Don't make
software development a winner-takes-all game!" I think that this is a
good idea, but the desktop-software buying market doesn't behave
compatibly with that idea. This is why I work for an information
service provider: the code is *not* the product. It is the means of
product delivery, and we can change it when needed.
david rush
--
You is what you done. Dynamic (mis)behaviorism, that's my creed.
-- Sprant Flere-Imsaho Wu-Handrahen Xato Trabiti
in _The Player of Games_
David Rush
> [*] "hand me the best"
>
> One ambition I have is to get rights to reprint a lot of
> photocopied materials and book excerpts -- and edit a book.
I'd love to see it.
You should see my pile of papers ;)
david rush
--
MERE ACCUMULATION OF OBSERVATIONAL EVIDENCE IS NOT PROOF
-- Death, in _Hogfather_
Daniel Klein
wrote:
>I don't believe people (managers/programmers) have *heard* of ML.
You're right, could someone please enlighten those of us who are uninformed.
What is 'ML'?
Dan
Charlton Wilbur
AvS> I don't believe people (managers/programmers) have *heard* of
AvS> ML. In my experience. That constitutes a bit of an
AvS> acceptance problem...
Perhaps ML needs a glossy magazine?
Charlton
Thomas Bushnell, BSG
> Remember - business is all about giving customers that which they
> percieve as their needs.
If true (which I don't believe it is; see the first two books of the
Republic for why), then this would be an excellent reason not to be in
business.
Anton van Straaten
> >I don't believe people (managers/programmers) have *heard* of ML.
>
> You're right, could someone please enlighten those of us who are
uninformed.
> What is 'ML'?
It's a functional language (or actually a family of languages). It's
actually a lot like Scheme would be if you added static type declarations,
type inference (so you don't have to explicitly declare all types - the
compiler figures them out), and a more algebraic/rule-based syntax. If you
want to learn more about functional languages, either ML or Haskell are good
choices to start with.
From the comp.lang.ML FAQ (http://www.faqs.org/faqs/meta-lang-faq/):
"ML (which stands for Meta-Language) is a family of advanced programming
languages with [usually] functional control structures, strict semantics, a
strict polymorphic type system, and parametrized modules. It includes
Standard ML, Lazy ML, CAML, CAML Light, and various research languages."
Here's a nice intro tutorial that can be worked through pretty casually: "A
Gentle Introduction to ML":
http://www.dcs.napier.ac.uk/course-notes/sml/manual.html
As for implementations, as a starting point I highly recommend Standard ML
of New Jersey, a.k.a. SML/NJ:
http://cm.bell-labs.com/cm/cs/what/smlnj/
SML/NJ is one of the few languages besides Scheme that supports first-class
continuations.
ML implementations tend to be fast - see
http://www.bagley.org/~doug/shootout/craps.shtml for example, where ML
derivatives make up 3 of the top 5 entries, alongside C and C++
(benchmarks - add salt to taste).
Anton
Sander Vesik
ultimately its business that pays for it, no matter what your indirect
source of income is. This is true even if you live in North Korea. I
don't think this is changable.
Anton van Straaten
> over the next big project I would really not mind wheter people use C++
> or OCaml or Scheme.
I doubt that you know what you're talking about when it comes to C++.
Comparing the above languages as though they're on equal footing is simply
wrong - C++ is much more dangerous, systems built with it are less reliable
in practice, it's harder to debug, and actually takes more expertise (of a
certain perverse twisted sort) to write and debug.
I say that as someone who learned C++ when the first compilers became
available for DOS, in the early '80s, and has regularly used it
professionally since then, to implement language products, server products,
and utilities. However, I can tell you categorically that anyone using C++
to implement things like corporate application-level products, or web
applications, is out of his by-definition tiny little mind.
You may already be familiar with this, but for a good example of the case
for the use of advanced languages to provide a competitive edge, see
http://www.paulgraham.com/paulgraham/avg.html
The idea that all languages are more or less equal is demonstrably wrong.
*Good* languages tend to be somewhat equal. However, the short history of
computing so far has saddled us with a number of languages that have some
particularly bad features and characteristics, and C++ is one of those.
> But I would never have given him the advice not to use Perl.
> People should use what they want.
Perl would be another language that has enough unfortunate characteristics
as to be worth avoiding. You give advice to other people to help them avoid
traps and to find optimal solutions. If you didn't advise against Perl, you
were doing your colleague a disservice.
In general, sure, people will use what they want. But over time, you find
that languages fall out of favor, because they're replaced by better ones.
These aren't just fads - if you compare the current crop of popular
languages to the languages in common use 10 or 15 years ago, the
improvements are drastic. If you look at current languages, some are
certainly better than others, in all sorts of ways. Given that, it makes
sense to choose a language that provides not only the features that appeal
to you, but also takes advantage of current language knowledge to avoid
known problems. By that criteria, choosing languages like C++ or Perl makes
no sense.
Anton
Anton van Straaten
> percieve as their needs.
Except that successful businesses are good at (a) convincing customers that
what they offer meets their needs and (b) manipulating their customer's
perceived needs.
In this example, the 100% solution would simply be sold to the customer as
an upgrade that was faster, more reliable, more featureful etc. Underlying
technology improvements can often be a good sales hook. E.g. people buying
some Audi cars are told about the all-aluminum chassis. Why does that
really matter to anyone? It doesn't, but it sounds cool. Ditto for a
product core with "functional style higher order functions and macros scheme
code"...
Perhaps we need to jazz up the terminology a little. Instead of
higher-order functions, from now on, we should talk about "titanium
functions". Next time anyone tells you about how cool they think Java is,
just say "Yeah, but does it have titanium functions? No? Didn't think so -
that must suck, huh?"
Anton
Anton van Straaten
> Perhaps part of the reason lisp, scheme, and the ml-family fail to get
> much support in the industry can be traced back to some famous
> failures.
Following on from my claim about people not having heard of ML, I'd also say
that the people familiar with these arcana of Lisp history are also
incredibly few and far between, in the general software development
population.
Eli Barzilay
> yeah, but if you had a 90% solution that clients were happy with
> putting the same imperative C interface over the functional style
> higher order functions and macros scheme code...
Designing a good interface so you can substitute components by better
ones in the future has nothing to do with Scheme (besides, interfacing
C and Scheme is not that hard).
> Remember - business is all about giving customers that which they
> percieve as their needs.
Right, and when a place begins with a sane application, and ends up
having three teams working on three versions of the same product --
not for competition but for different versions of the same thing, and
when all this is done in different languages, then you know that
something went wrong in the design path. Even managers that push a
50% solution as fast as they can and don't ever want to see a 100%
solution will admit that a lot of effort could have been saved if
there was a single version of the product with a lot of the
flexibility implemented in Scheme or whatever. (BTW, the above
situation is not a product of my imagination, and the managers
involved were in full support of good solutions, but gave up for time
constraints.)
Thomas Bushnell, BSG
Nope. Maybe if you're fixated on money, but I'm not.
Thomas Bushnell, BSG
I should add to my previous reply. You are saying, given your
original statement and this one, by implication, is that we should
all, at every moment, be spending our energies on giving other
people--specifically, those who give us things like food--whatever
they think they want.
I refer again to the Republic (I and II) for the proposition that the
right thing is to give people what they actually need rather than what
they think they need.
And I add, again, that I disagree about the substance of what you are
saying as well. You suggest that I should first figure out what my
"business" is, and then who my "customers" are, and then I should give
my customers what they think they need (or, taking Plato's correction,
what they actually need).
I disagree. The important figures in my life are not customers, and
my life is not "business".
Eli Barzilay
> Perhaps we need to jazz up the terminology a little. Instead of
> higher-order functions, from now on, we should talk about "titanium
> functions". Next time anyone tells you about how cool they think
> Java is, just say "Yeah, but does it have titanium functions? No?
> Didn't think so - that must suck, huh?"
That's a wonderful idea... It should go well with using years in
language standard names (R6RS sounds like a kind of tire, but
Scheme2003 sounds like it comes in one of fancy boxes with
scientific-looking covers). Also, titanium sounds fine for first
class functions, but continuations definitely require some thought...
Christopher Richards
[...]
> Scheme2003 sounds like it comes in one of fancy boxes with
> scientific-looking covers). Also, titanium sounds fine for first
> class functions, but continuations definitely require some thought...
Yttrium. Exotic, no?
--
Chris
Erann Gat
(Thomas Bushnell, BSG) wrote:
> I refer again to the Republic (I and II) for the proposition that the
> right thing is to give people what they actually need rather than what
> they think they need.
The problem is that there is no way to determine objectively what people
actually need. So only two options are open to us: either we take people
at their word about what they think they need, or we decide for them based
on what we think they need. The former decision leads to capitalism, the
latter to communism. An experiment comparing the two approaches was
conducted during the latter half of the twentieth century. The results
were conclusive: communism doesn't work. (The jury is still out on
capitalism.)
E.
Tom Lord
The problem is that there is no way to determine objectively
what people actually need. So only two options are open to
us: either we take people at their word about what they think
they need, or we decide for them based on what we think they
need. The former decision leads to capitalism, the latter to
communism. An experiment comparing the two approaches was
conducted during the latter half of the twentieth century.
The results were conclusive: communism doesn't work. (The
jury is still out on capitalism.)
What a sadly oversimplified -- heck, just plain delusional -- world
view you have. 3:2 you label yourself an objectivist libertarian, but
even if not.....
Would you benefit by having some of us rip up your quoted paragraph
into individual logic-errors? Or were you just bullshitting for
bullshitting's sake?
(Of course, it's stupid for me to respond purely rhetorically this way --
cause some numbsckull will just turn around and apply the same rhetoric
inappropriately.)
-t
Michael J. Fromberger
g...@jpl.nasa.gov (Erann Gat) wrote:
> In article <877kf5x...@becket.becket.net>, tb+u...@becket.net
> (Thomas Bushnell, BSG) wrote:
>
> > I refer again to the Republic (I and II) for the proposition that
> > the right thing is to give people what they actually need rather
> > than what they think they need.
>
> The problem is that there is no way to determine objectively what
> people actually need. So only two options are open to us: either we
> take people at their word about what they think they need, or we
> decide for them based on what we think they need.
I must say, I disagree that these are the only choices. I think, in
fact, that the alternative used in practise is to give people a bunch of
tools, and see what they actually DO use, and for what. That gives you
a much clearer understanding of the balance between desire and need.
-M
--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA
Bruce Hoult
No, Erann, those are not the only options.
May I point you to the example of ... oh ... say, John Scully vs Steve
Jobs.
Scully was big on finding out what people thought they needed. He was a
focus group guy. Remember the _Pepsi Challenge_? That was his.
In the early days of the Macintosh, Apple decided to make a portable.
Focus groups told them that the #1 feature everyone wanted was enough
battery life to run for an entire work day or a trans-continental
flight. So Apple built that machine (the Mac Portable) and it sank
without trace while other computers with much less battry life outsold
it. When it was repackaged with a much smaller and lighter battery (as
the PowerBook 100) it became a best seller.
The Newton was Sully's baby and suffered from the same problem, only
worse.
Jobs is the opposite. He doesn't care about what people say they want.
Instead he backs his own judgement of what they *need*, regardless of
what critics and the press say. And more often than not he's right.
Apple has had hit product after hit product since his return five years
ago. People were laughing at the iMac between its announcement and its
launch, and look at how well it did.
So is Jobs a communist?
-- Bruce
Sean Case
Bruce Hoult <br...@hoult.org> wrote:
> Jobs is the opposite. He doesn't care about what people say they want.
> Instead he backs his own judgement of what they *need*, regardless of
> what critics and the press say. And more often than not he's right.
> Apple has had hit product after hit product since his return five years
> ago. People were laughing at the iMac between its announcement and its
> launch, and look at how well it did.
> So is Jobs a communist?
http://www.turnleft.com/apple/
(Hasn't been updated in years, though. Pity.)
Sean Case
--
Sean Case g...@zip.com.au
Code is an illusion. Only assertions are real.
Siegfried Gonzi
> "ML (which stands for Meta-Language) is a family of advanced programming
> languages with [usually] functional control structures, strict semantics, a
> strict polymorphic type system, and parametrized modules. It includes
> Standard ML, Lazy ML, CAML, CAML Light, and various research languages."
I have to churn in:
One should not forget to mention that OCaml is light years easier when
you will have to use OCaml for reading files. The difference to Clean is
tremendous.
I think this is important for the usefulness of the language. Clean is
nice but you shouldn't do anything beyond Fibonacci with it.
S. Gonzi
Jeffrey Siegal
> >Interesting article, however I don't believe people (managers/programmers)
> >associate historical lisp failures with ML.
>
> I don't believe people (managers/programmers) have *heard* of ML.
If they had, they wouldn't like it. Although slightly closer than Lisp, It
doesn't look enough like C.
Bruce Hoult
Sean Case <g...@zip.com.au> wrote:
> In article <bruce-D2B6C2....@copper.ipg.tsnz.net>,
> Bruce Hoult <br...@hoult.org> wrote:
>
> > Jobs is the opposite. He doesn't care about what people say they want.
> > Instead he backs his own judgement of what they *need*, regardless of
> > what critics and the press say. And more often than not he's right.
> > Apple has had hit product after hit product since his return five years
> > ago. People were laughing at the iMac between its announcement and its
> > launch, and look at how well it did.
>
> > So is Jobs a communist?
>
> http://www.turnleft.com/apple/
>
> (Hasn't been updated in years, though. Pity.)
That's actually pretty funny. And I miss the Newton as much as anyone.
But I miss Apple Dylan [1] much more, which is another thing that got
killed at about the same time.
-- Bruce
[1] but fortunately we still have http://www.gwydiondylan.org
Erann Gat
> In article <gat-221102...@k-137-79-50-101.jpl.nasa.gov>,
> g...@jpl.nasa.gov (Erann Gat) wrote:
>
> > In article <877kf5x...@becket.becket.net>, tb+u...@becket.net
> > (Thomas Bushnell, BSG) wrote:
> >
> > > I refer again to the Republic (I and II) for the proposition that the
> > > right thing is to give people what they actually need rather than what
> > > they think they need.
> >
> > The problem is that there is no way to determine objectively what people
> > actually need. So only two options are open to us: either we take people
> > at their word about what they think they need, or we decide for them based
> > on what we think they need. The former decision leads to capitalism, the
> > latter to communism. An experiment comparing the two approaches was
> > conducted during the latter half of the twentieth century. The results
> > were conclusive: communism doesn't work. (The jury is still out on
> > capitalism.)
>
> No, Erann, those are not the only options.
Of course they are. We either accept other people's judgements, or we
impose our own. (Well, I suppose that there is a third option of burying
our heads in the sand and doing nothing.) It's a continuum, not a
dichotomy: we can make a decision based on a blend of our own judgements
and those of others. Logically there is one other possibility: we can try
to determine people's needs without resorting to anyone's judgement, but
that simply doesn't work as you yourself point out:
> May I point you to the example of ... oh ... say, John Scully vs Steve
> Jobs.
>
> Scully was big on finding out what people thought they needed. He was a
> focus group guy. Remember the _Pepsi Challenge_? That was his.
>
> In the early days of the Macintosh, Apple decided to make a portable.
> Focus groups told them that the #1 feature everyone wanted was enough
> battery life to run for an entire work day or a trans-continental
> flight. So Apple built that machine (the Mac Portable) and it sank
> without trace while other computers with much less battry life outsold
> it. When it was repackaged with a much smaller and lighter battery (as
> the PowerBook 100) it became a best seller.
This example actually supports my position. What Scully was trying to do
was to try to establish people's needs objectively. His methodology was
to ask people what they wanted and take their word for it. It failed
miserably, which is exactly what you would expect if you believe that
objective assessment of people's needs is not possible. The obvious
technique -- just ask them and take them at their word -- obviously
doesn't work.
This is something that Utopian thinkers throughout the centuries have
missed: figuring out what people want or need is *hard*! Focus groups
fail not because people lie about what they want, but because they simply
don't know. Very often what you think you want is not what you really
want, but you don't find that out until you get the thing you think you
wanted and then discover that the reality of having it is not what you
imagined it to be, and that you didn't really want it after all. That's
why the hardest part of getting what you want out of life is simply
figuring out what that is. Once you know what you want, getting it is
usually pretty easy. (For one thing, if you really know what you want you
will find a mob of capitalists beating a path to your door to try to sell
it to you.)
One of the reasons capitalism succeeds and communism fails is that
capitalism forces people to back up their claims about what they think
they want with their pocketbooks. The net effect is that under capitalism
people are encouraged to think about what they want, whereas under
communism they are discouraged from thinking about it (since the politburo
does that thinking for you). The net effect is that under capitalism more
people get what they want simply because more thought went into deciding
what that is.
> So is Jobs a communist?
Absolutely not. Scully and Jobs are both capitalists because at the end
of the day both accepted the judgement of people voting with their
pocketbooks. Jobs succeeded where Scully failed not because one was a
communist and the other a capitalist, but because Jobs has an uncanny
knack for divining what people really want, and Scully doesn't (at least
not outside the realm of carbonated beverages).
(Bill Gates is much more of a communist than either Jobs or Scully. He is
adamantly opposed to accepting the judgements of others, preferring
instead to impose his own judgement by force. The force he employs is
monopolistic and not military, but it is force nonetheless. That he wraps
himself in the trappings of capitalism makes him no less a communist.)
E.
Erann Gat
Lord) wrote:
> What a sadly oversimplified -- heck, just plain delusional -- world
> view you have. 3:2 you label yourself an objectivist libertarian, but
> even if not.....
I'm a Popperian Epistemologist. Pay up.
> Would you benefit by having some of us rip up your quoted paragraph
> into individual logic-errors? Or were you just bullshitting for
> bullshitting's sake?
I stand behind everything I wrote.
> (Of course, it's stupid for me to respond purely rhetorically this way --
> cause some numbsckull will just turn around and apply the same rhetoric
> inappropriately.)
Indeed. Given that you realize it was stupid, why did you do it?
E.
Erann Gat
<Michael.J.Fromberger-...@merrimack.dartmouth.edu>,
"Michael J. Fromberger" <Michael.J....@Clothing.Dartmouth.EDU>
wrote:
> In article <gat-221102...@k-137-79-50-101.jpl.nasa.gov>,
> g...@jpl.nasa.gov (Erann Gat) wrote:
>
> > In article <877kf5x...@becket.becket.net>, tb+u...@becket.net
> > (Thomas Bushnell, BSG) wrote:
> >
> > > I refer again to the Republic (I and II) for the proposition that
> > > the right thing is to give people what they actually need rather
> > > than what they think they need.
> >
> > The problem is that there is no way to determine objectively what
> > people actually need. So only two options are open to us: either we
> > take people at their word about what they think they need, or we
> > decide for them based on what we think they need.
>
> I must say, I disagree that these are the only choices. I think, in
> fact, that the alternative used in practise is to give people a bunch of
> tools, and see what they actually DO use, and for what. That gives you
> a much clearer understanding of the balance between desire and need.
Ah, I guess I did misspeak. When I said "take people at their word" I did
not mean that literally. What I meant was that we accept people's own
assessments of their needs and desires, though not necessarily as
expressed by what they literally say, but rather as expressed by what they
are willing to pay for.
E.
Craig Brozefsky
> One of the reasons capitalism succeeds and communism fails is that
> capitalism forces people to back up their claims about what they think
> they want with their pocketbooks. The net effect is that under capitalism
> people are encouraged to think about what they want, whereas under
> communism they are discouraged from thinking about it (since the politburo
> does that thinking for you). The net effect is that under capitalism more
> people get what they want simply because more thought went into deciding
> what that is.
You evacuated the terms "capitalist" and "communist" of their
political-economic origins and then you substituted the most hackneyed
version of free-market ideology as espoused by American neo-liberals
since the 1920s for an analysis of the operation of capital and
markets. Neither a socialist or a Chicago School economist would buy
it. In the process you fail to consider the operation of advertising,
the effects of monopoly capital on the "freedom of choice menu", and
turn purchase decision into a simplistic measure of "need" that
entirely ignores the supply side of the supply/demand dialectic.
Now, it's c.l.s so we can forgive people their indulgences in
arm-chair political-economic theorizing, but may I respectfully
suggest that you get back on topic.
I used to write alot of Scheme, tho I write mostly CL now, and I
really appreciated the blank slate Scheme provided, because it let me
figure out what my own needs were. After a couple years of that I
recognized that those needs were shared by others, which prompted my
move to CL. However, without that exposure to Scheme and its
emptiness, simplicity, and openness to experimentation, I would not
have an adequate understanding of my own needs and the solutions
available to me thru existing languages and tools.
It is this direct hands on experience that I treasure and I think
should be accentuated as a force guiding social production. Within my
commercial work, this manifests as an emphasis on direct needs
analysis of the intended user of the software, adding to it the
experience of previous users and of the people who have been dealing
with the problem at hand for a long time. There is often a mismatch
between this and what any one user is willing to pay for. Since the
new feature, or subsystem, is being incorporated into a larger
framework and will be shared with other users, we must attempt to
educate the user as to why the solution we see satisfies their need,
and thus secure funding from them. In this way the understanding of
"what is to be done" is a negotiation that has it's base in the
experience of both users (and that included users who are not paying
for the new feature) and designers.
--
Sincerely,
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
Erann Gat
<cr...@red-bean.com> wrote:
> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > One of the reasons capitalism succeeds and communism fails is that
> > capitalism forces people to back up their claims about what they think
> > they want with their pocketbooks. The net effect is that under capitalism
> > people are encouraged to think about what they want, whereas under
> > communism they are discouraged from thinking about it (since the politburo
> > does that thinking for you). The net effect is that under capitalism more
> > people get what they want simply because more thought went into deciding
> > what that is.
>
> You evacuated the terms "capitalist" and "communist" of their
> political-economic origins and then you substituted the most hackneyed
> version of free-market ideology as espoused by American neo-liberals
> since the 1920s for an analysis of the operation of capital and
> markets.
First, what did you expect in one paragraph? There's only so much you can
say in five sentences. But second, I didn't define capitalism, I just
made an observation about it. I didn't mean to imply that that
observation is either capitalism's or communism's central defining
characteristic.
> In the process you fail to consider the operation of advertising,
> the effects of monopoly capital on the "freedom of choice menu", and
> turn purchase decision into a simplistic measure of "need" that
> entirely ignores the supply side of the supply/demand dialectic.
I didn't mean to imply that the consumer's purchasing decision is all
there is to it. Of course it's more complicated than that. (You will
note that I consider Bill Gates a communist.)
> Now, it's c.l.s so we can forgive people their indulgences in
> arm-chair political-economic theorizing, but may I respectfully
> suggest that you get back on topic.
I think I am on topic. This thread started with Tom Lord talking about:
> Perhaps part of the reason lisp, scheme, and the ml-family fail to get
> much support in the industry...
A few posts downstream Sander Vesik observed:
> Remember - business is all about giving customers that which they
> percieve as their needs.
To which Thomas Bushnell replied:
> If true (which I don't believe it is; see the first two books of the
> Republic for why), then this would be an excellent reason not to be in
> business.
and:
> I refer again to the Republic (I and II) for the proposition that the
> right thing is to give people what they actually need rather than what
> they think they need.
Given the virtually endless handwringing that goes on in the
Lisp/Scheme/ML community about why these languages aren't more popular, I
think this disucussion is quite relevant, and I am doing nothing more than
casting my lot with Sander's position and against Thomas's. It's a very
simple argument, and it's got nothing to do with the fine points of
socioeconomic theory or anything remotely connected with Chicago or any
other city for that matter ;-) To recap:
Thomas says we should give people what they actually need. I say that's
impossible because we can't determine objectively what people's actual
needs are. The best we can do is to rely on people's judgements, and the
best way to do that is to allow people to make their own judgements and
back those judgements up with money. That is not the whole story of
capitalism or communism by any stretch of the imagination, but it is one
notable feature that distinguishes these systems from each other. Insofar
as capitalism seems empirically to produce better results than communism,
I say (in contrast to Thomas's position) that it is better to embrace
capitalism than to lament its myriad shortcomings. (If you don't like my
use of the word "capitalism" then substitute "business" instead.)
E.
Craig Brozefsky
> First, what did you expect in one paragraph? There's only so much you can
> say in five sentences. But second, I didn't define capitalism, I just
> made an observation about it. I didn't mean to imply that that
> observation is either capitalism's or communism's central defining
> characteristic.
I was speaking specifically to the distinction between capitalism and
communism you were using to define Bill Gates as a communist, his use
of monopoly force and determing for himself what people need (which of
course is going to be what he sells). Normally when you use a
characteristic to define someone as X or Y, it is called a defining
characteristic.
I find it amusing that by this logic Bill Gates' position as a
monopoly capitalists qualifies him as a communist. I suppose the
board of ADM, GE, Boeing, MD, GM and other monopolists are not
capitalists at all, but communists since they routinely apply monopoly
force to the market.
> Given the virtually endless handwringing that goes on in the
> Lisp/Scheme/ML community about why these languages aren't more
> popular, I think this disucussion is quite relevant, and I am doing
> nothing more than casting my lot with Sander's position and against
> Thomas's.
And as someone who is currently in the business of writing software in
Lisp, and uses Scheme tools in that pursuit as well, I think that's a
gross simplification and should be expanded. To paraphrase Sander
with his own words:
"Remember - business is all about giving customers that which they
percieve as their needs."
There are are several other aspects of "business", particularly custom
software development:
1. Helping customers refine their perception. For instance, they
think they need ODBC access to the database tables on the
applications backend. However, what they really need is access to
their data, and that can be provided thru mechanisms that fit
better with the architecture of the app. This is a critical issue
if you are dealing with non-standard" solutions like CL -- you need
to translate.
2. Integrating the needs of the customer paying for a particular
feature with the unspoken needs of the rest of the users, as well
as the application framework itself. Any particular purchase
decision does not exist in a vacuum, and in practice we have had to
turn down offers to pay for a perceived need when it would not fit.
3. Marketing and sales is about creating in customers a perceived
need. If you don't have a plan for this, you will not last. This
is an aspect of "business" few programmers comprehend.
Considering these, the distinction you made between "capital" and
"communism" is useless (regardless of its relation to the
political-economic meaning of those words).
> people's actual needs are. The best we can do is to rely on
> people's judgements, and the best way to do that is to allow people
> to make their own judgements and back those judgements up with
> money.
You can also discuss the problem with them, and collaborate on the
solution, devoid of any exchange of money. Just because someone is
willing to write a check doesn't mean you can ever satisfy them, and
just because someone can't write a check doesn't mean they have not
fully developed their understanding of the problem and their need. An
over-reliance on the "design by checkbook" principle must be resisted.
Witness Java.
Robert Uhl <ruhl@4dv.net>
>
> Sander Vesik <san...@haldjas.folklore.ee> writes:
> >
> > ultimately it's business that pays for it, no matter what your
> > indirect source of income is. This is true even if you live in
> > North Korea. I don't think this is changable.
>
> Nope. Maybe if you're fixated on money, but I'm not.
What a load of bollocks. Money is what feeds one, what puts clothes
on one's back and a roof over one's head. Money is nothing more than
a placeholder for value--and value is created by business, when two
parties come together and arrange a mutually beneficial exchange.
It's business which pays for art, business which pays for roads and
business which pays for software.
There's no fixation about it--without business, there is nothing in
this world.
--
Robert Uhl <ru...@4dv.net>
`Genetically' we are nearly identical to fruit flies. On the
other hand, as a species we write better string quartets.
--Rich Clancey
Erann Gat
<cr...@red-bean.com> wrote:
> I find it amusing that by this logic Bill Gates' position as a
> monopoly capitalists qualifies him as a communist. I suppose the
> board of ADM, GE, Boeing, MD, GM and other monopolists are not
> capitalists at all, but communists since they routinely apply monopoly
> force to the market.
I once had a history teacher who explained the words "liberal",
"conservative", "reactionary", and "radical" by drawing a line to
illustrate the spectrum of political viewpoints. Then he observed that
the spectrum might not be a line at all, but a circle, and that if you
went too far towards one extreme you found yourself at a political
ideology that was indistinguishable from what you found at the "opposite"
extreme. This is how I believe it works with economic philosophies as
well. Push capitalism to an extreme and you get something that but for
the rhetoric is virtually indistiguishable from communism. In both cases
the consumer has no choice but to buy/do what the company/poltiburo says.
(The opposite holds true as well: lean hard enough on communism and it
morphs into capitalism. I work in the space industry in the supposedly
capitalist U.S. But if I wanted to pay for a trip into space the only
place I could do that today is Russia.)
> An over-reliance on the "design by checkbook" principle must be resisted.
> Witness Java.
The strength of this argument depends entirely on whether you are looking
at it from the point of view of someone who writes code or someone who
*hires* people to write code. From the former point of view (which has
been my point of view for most of my life) I think you're right. But from
the latter point of view Java is a great success story. It has made huge
strides in transforming programming from a craft into merely skilled
labor, which reduces costs (not to mention the headaches caused by uppity
programmers who think they know more than their employers). All this is,
of course, very bad from the programmer's point of view. Unfortunately,
the people who do the hiring are the ones who run the world.
E.
Lauri Alanko
that C++, _when used The Right Way_, is unambiguously superior to C in
certain respects: it can be used for all the things that C can be used
for, but with better type-safety and better facilities for abstraction.
(Note: "better" still doesn't imply "good".)
Admittedly C++ has many ways to shoot yourself in the foot. So many, in
fact, that it is so hard to find The Right Way that it may well not be
worth the advantage you'd get over C.
But still. If portability, foreign interfacing and compiler support
weren't an issue, I myself might well implement the runtime of a
high-level language in C++.
(What is The Right Way? I have no exact definition, but the general
principle is "use only those features which are unambiguously better and
type-safer than the corresponding way to do it in C". Eg. use inline
functions instead of macros, subclasses instead of extended structs,
classes with virtual methods instead of tables of function pointers,
etc. But no C++ standard library (bloatimus maximus) or non-inline
templates, or non-const references or any of the other horrors which C++
is so full of...)
Lauri Alanko
l...@iki.fi
Anton van Straaten
I had stopped, myself. But since you responded to my point...
> I'd just like to note
> that C++, _when used The Right Way_, is unambiguously superior to C in
> certain respects: it can be used for all the things that C can be used
> for, but with better type-safety and better facilities for abstraction.
> (Note: "better" still doesn't imply "good".)
I agree with this.
> Admittedly C++ has many ways to shoot yourself in the foot. So many, in
> fact, that it is so hard to find The Right Way that it may well not be
> worth the advantage you'd get over C.
I definitely wasn't comparing C++ to C - Siegfried used the example of a
choice between C++, OCaml, or Scheme. If I were restricted to a choice
between C++ and C, I would pick C++ if I could. (Or, I'd look for a project
where I had better choices!)
> But still. If portability, foreign interfacing and compiler support
> weren't an issue, I myself might well implement the runtime of a
> high-level language in C++.
I've done work along these lines, and sold products based on it. I might
use C++ again in such a case, especially if it were only for the limited
core of a system. There is still a dearth of good system-level programming
languages. In my earlier post, I was assuming that the comparison to OCaml
& Scheme meant that we were probably talking about slightly higher-level
applications. If so, then I still maintain that C++ is a poor choice, for
measurable reasons related to productivity, reliability, etc.
Anton
Craig Brozefsky
> I once had a history teacher who explained the words "liberal",
> "conservative", "reactionary", and "radical" by drawing a line to
> illustrate the spectrum of political viewpoints. Then he observed
> that the spectrum might not be a line at all, but a circle, and that
> if you went too far towards one extreme you found yourself at a
> political ideology that was indistinguishable from what you found at
> the "opposite" extreme. This is how I believe it works with
> economic philosophies as well. Push capitalism to an extreme and
> you get something that but for the rhetoric is virtually
> indistiguishable from communism. In both cases the consumer has no
> choice but to buy/do what the company/poltiburo says.
This "screen wrap" effect is due to a mis-identification of the
characteristics, and subsequent erasure of difference. You are
confusing the degree of central planning and control over what is
produced, as it is experienced by the consumer, with the real
distinguishing factor between capitalism and communism, the experience
of the worker and their relation to the owners of the means of
production. Why am I harping on this point? Because I think that
erasing that difference blinds us to some important issues. Since you
hit upon that relation between the worker and hirer below, I don't see
a reason for us to continue this part of the thread.
> The strength of this argument depends entirely on whether you are
> looking at it from the point of view of someone who writes code or
> someone who *hires* people to write code.
My post was not an argument, it was a description of my experience as
both someone who writes code, and as someone who hires people to write
code. I play both roles presently.
From the former point of
> view (which has been my point of view for most of my life) I think
> you're right. But from the latter point of view Java is a great
> success story. It has made huge strides in transforming programming
> from a craft into merely skilled labor, which reduces costs (not to
> mention the headaches caused by uppity programmers who think they
> know more than their employers). All this is, of course, very bad
> from the programmer's point of view. Unfortunately, the people who
> do the hiring are the ones who run the world.
Ah, see now you are recognizing the defining characteristic of
capitalism and the problem of workers who have to work to maintain
their existence (pay mortgage, eat), but are dependent upon the
"hirers" aka the capitalists.
This relation certainly isn't satisfying our needs as programmers.
The concern of the capitalist is their rate of profit, and having us
be disposable and our tools standardized on the lowest common
denominator, and the skills we deploy simplified so as to expand the
pool of available labor and put downward pressure on our wages.
Suggesting that we mutate our tools and skills into something which
satifies the hirers does nothing for us. It ruins our tools, and it
solidifies the control they have over us. When we don't have our
efficient tools it requires more labor to solve a problem, and we find
it impossible to meet the needs of the public without having a pool of
capital big enough to support dozens of programmers.
I understand that for many of us the weight of mortgages, car
payments, credit card debt and other things leave us little room for a
reduction in our income, and so we are very dependent upon the hirers.
But what happens when the labor market contracts for us, as it is
doing now? Having "acceptable" tools and skills will not help us
then. Fewer and fewer of us our able to service our debt and make a
living from the hirers. I'm sure you've seen the posts from those of
us who have succumbed to the stress of this situation, publically
breaking down and losing all hope.
I think we need to look at freeing ourselves from that dependence upon
the hirers. To do that we need to develop our tools as *WE* need
them, so that *WE* can get the job done. We also need to share our
tools with each other, so that we can solve problems without having to
have a big pool of money to license our tools from the hirers. This
doesn't apply to just us Scheme and Lisp users either, it applies to
programmers at all levels of skill. Unless this happens I don't see
software development as an art or discipline ever maturing. It will
always be retarded by the need to oversimplify it, to homogenize it,
and to carve it up with patents and copyrights so that capitalists can
extract rent for the work we do for them and their interests.
I would like to talk about how we as Schemers and Lispers can do this,
and my previous comments about my experience in a small lisp shop were
in that spirit.
Thomas Bushnell, BSG
> The problem is that there is no way to determine objectively what people
> actually need. So only two options are open to us: either we take people
> at their word about what they think they need, or we decide for them based
> on what we think they need. The former decision leads to capitalism, the
> latter to communism. An experiment comparing the two approaches was
> conducted during the latter half of the twentieth century. The results
> were conclusive: communism doesn't work. (The jury is still out on
> capitalism.)
I think you have carefully eliminated a rather vast category of
options which involve admitting one's own capacity for error--and thus
I should be properly hesitant about deciding that my idea of what you
need is better than your idea. And yet, when push comes to shove,
ultimately, I can base my decisions on nothing other than my own
beliefs.
Indeed, it would seem that you are saying that it's better to let
people get what they think they need--because, if we think rightly,
we'll see that this is better for them and everyone else.
And, to sign off--do you really think that the leaders of the USSR
were actually trying to give the people what the leaders really
thought they needed?
Thomas Bushnell, BSG
> Thomas says we should give people what they actually need. I say that's
> impossible because we can't determine objectively what people's actual
> needs are. The best we can do is to rely on people's judgements, and the
> best way to do that is to allow people to make their own judgements and
> back those judgements up with money. That is not the whole story of
> capitalism or communism by any stretch of the imagination, but it is one
> notable feature that distinguishes these systems from each other. Insofar
> as capitalism seems empirically to produce better results than communism,
> I say (in contrast to Thomas's position) that it is better to embrace
> capitalism than to lament its myriad shortcomings. (If you don't like my
> use of the word "capitalism" then substitute "business" instead.)
What Thomas is *really* saying is that he doesn't really give a fig
for what "industry" thinks is important. I do not base my estimations
of value by looking at what management books tell managers to like,
nor on what managers actually happen to like.
I can think that Scheme is the bee's knees, no matter if "industry"
likes it or not.
Thomas Bushnell, BSG
> I understand that for many of us the weight of mortgages, car
> payments, credit card debt and other things leave us little room for a
> reduction in our income, and so we are very dependent upon the hirers.
My strategy is to avoid making myself dependent on such things.
I also have this weird habit of looking around me, and seeing people
who lead happy lives (often happier than mine) with much less material
prosperity, and I think "wow, I've got it pretty good". I then get
motivated to do what I can to even out the injustices in our current
economic world, and I also start training myself to depend less on the
things that credit card debt and car payments obtain, so that if I
need to, I can wave them goodbye without losing a beat.
ozan s yigit
> I really like Olin's introduction to structured regexps [...]
does this mean you really think his "structured regexps" are the
100% solution to doing regular expressions?
oz
---
music is the space between the notes. -- claude debussy
Erann Gat
<cr...@red-bean.com> wrote:
> the real
> distinguishing factor between capitalism and communism, the experience
> of the worker and their relation to the owners of the means of
> production.
That's the rhetoric. I don't believe it's the reality. The experience of
the worker in a communist country seems to me pretty much
indistinguishable from that of a worker in a capitalist country without
strong trade unions.
> > Unfortunately, the people who
> > do the hiring are the ones who run the world.
>
> Ah, see now you are recognizing the defining characteristic of
> capitalism and the problem of workers who have to work to maintain
> their existence (pay mortgage, eat), but are dependent upon the
> "hirers" aka the capitalists.
Right, except that the same situation also occurs in communist countries,
except that the hirer there is called "the government" instead of "the
capitalists".
> I think we need to look at freeing ourselves from that dependence upon
> the hirers. To do that we need to develop our tools as *WE* need
> them, so that *WE* can get the job done. We also need to share our
> tools with each other, so that we can solve problems without having to
> have a big pool of money to license our tools from the hirers. This
> doesn't apply to just us Scheme and Lisp users either, it applies to
> programmers at all levels of skill. Unless this happens I don't see
> software development as an art or discipline ever maturing. It will
> always be retarded by the need to oversimplify it, to homogenize it,
> and to carve it up with patents and copyrights so that capitalists can
> extract rent for the work we do for them and their interests.
I heartily agree with this, but I think this is a necessasry but far from
sufficient step. Freeing yourself from the tyranny of capitalism can only
be done by becoming a capitalist (I prefer the term "businessman")
yourself. To do that you need more than just mastery of the tools of your
trade, you also need mastery of the tools of the capitalist/business
trade: marketing, sales, finance, management. Lisp by itself is not
enough.
> I would like to talk about how we as Schemers and Lispers can do this,
> and my previous comments about my experience in a small lisp shop were
> in that spirit.
Me too.
E.
Erann Gat
(Thomas Bushnell, BSG) wrote:
> Craig Brozefsky <cr...@red-bean.com> writes:
>
> > I understand that for many of us the weight of mortgages, car
> > payments, credit card debt and other things leave us little room for a
> > reduction in our income, and so we are very dependent upon the hirers.
>
> My strategy is to avoid making myself dependent on such things.
Yes, there are two strategies to get what you want: get more, or want
less. However...
> I then get
> motivated to do what I can to even out the injustices in our current
> economic world,
It is a lot easier to accomplish things, including helping other people
get what they want, if you have money, because then you can hire people to
help you. Without money you either have to persuade people to help you
without being paid, or do it on your own. Either way it's a serious
handicap.
E.
Erann Gat
(Thomas Bushnell, BSG) wrote:
> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > The problem is that there is no way to determine objectively what people
> > actually need. So only two options are open to us: either we take people
> > at their word about what they think they need, or we decide for them based
> > on what we think they need. The former decision leads to capitalism, the
> > latter to communism. An experiment comparing the two approaches was
> > conducted during the latter half of the twentieth century. The results
> > were conclusive: communism doesn't work. (The jury is still out on
> > capitalism.)
>
> I think you have carefully eliminated a rather vast category of
> options which involve admitting one's own capacity for error--and thus
> I should be properly hesitant about deciding that my idea of what you
> need is better than your idea. And yet, when push comes to shove,
> ultimately, I can base my decisions on nothing other than my own
> beliefs.
<shrug> I don't think it makes a difference whether you admit your
capacity for error or not. At the end of the day you must choose to base
your actions on your judgement or someone else's (or flip a coin, or bury
your head in the sand). Whatever you choose I don't see how the process
you use to arrive at that decision matters.
> Indeed, it would seem that you are saying that it's better to let
> people get what they think they need--because, if we think rightly,
> we'll see that this is better for them and everyone else.
This is indeed what I think. However, like all Utopian ideals it comes
with a lot of caveats. In this case we need to be careful about the
mechanism we use to let people say what they think they need because, as
we have seen, just asking them doesn't work.
> And, to sign off--do you really think that the leaders of the USSR
> were actually trying to give the people what the leaders really
> thought they needed?
I have no idea. It's hard enough figuring out what *I* want for myself.
How would I even begin to divine what someone else thinks someone else
again wants? That's not the point. The point is the leaders of the USSR
decided to impose their judgement on other people. Whether they did this
in good faith or with humility about their capacity for error I neither
know nor care.
(N.B. I do not consider it outside the realm of possibility that the
leaders of the USSR were acting in good faith. People make what seem to
me to be bizarre choices on other people's behalf all the time, and I
think they do it in good faith, e.g. a Christian Scientist who prays for a
sick child rather than taking them to a hospital, or a rich parent who
buys their teenage child a new BMW.)
E.
Erann Gat
(Thomas Bushnell, BSG) wrote:
> I can think that Scheme is the bee's knees, no matter if "industry"
> likes it or not.
Sure, but if there weren't an industry out there you wouldn't have a
computer to turn your abstract admiration of Scheme into any kind of
reality. It's one thing to admire the lambda calculus in the abstract.
It's quite another to actually write a Scheme program and watch it run on
a 1 gigahertz pentium with 512 MB of RAM that cost less than a month's
rent.
Now, perhaps you don't really enjoy writing Scheme programs and watching
them run and prefer just to revel in the Platonic beauty of it all, but
*some* people prefer the former. And those people ought to realize that
their Pentiums didn't appear on their desks by magic. They are there
because a boatload of people worked like dogs for years, and some (not
all) of those people were motivated by money. That sounds crass, so let
me put it in another, more verbose way: some of those people were
motivated by the possibility that other people would come to them and say,
"We like what you have worked hard to produce. It meets our needs. And
we're willing to back up this assertion with these tokens of the work *we*
have done to meet *other* people's needs, which tokens you can then use to
influence other people to meet what you perceive to be *your* needs as a
reward for the work you have done and the risks you have taken."
Money is far from a perfect barometer of how well people's needs a being
met, but IMO it's a damn sight better than anything else anyone has been
able to come up with. It's kind of like what Churchill said about
Democracy: it's the worst system we have, except for all the others.
E.
ozan s yigit
> I'm a Popperian Epistemologist. Pay up.
chuckle.
for those interested, the best introduction to popperian epistemology
may be the following collection of essays still in print but i have
not seen on a bookstore shelve in years:
karl r. popper
objective knowledge: an evolutionary approach
oxford/clerendon, 1972 [isbn 19 875024 2]
recommended.
oz
---
music is the space between the notes. | www.cs.yorku.ca/~oz
-- claude debussy | york u. dept of computer science
Erann Gat
<o...@blue.cs.yorku.ca> wrote:
> Erann Gat:
>
> > I'm a Popperian Epistemologist. Pay up.
>
> chuckle.
>
> for those interested, the best introduction to popperian epistemology
> may be the following collection of essays still in print but i have
> not seen on a bookstore shelve in years:
>
> karl r. popper
> objective knowledge: an evolutionary approach
> oxford/clerendon, 1972 [isbn 19 875024 2]
>
> recommended.
A gentle introduction can also be found in Chapter 7 of David Deutch's
"The Fabric of Reality." Also recommended (but if you read the rest of
the book, the parallel-universes stuff should be taken with a big grain of
salt.)
E.
Thomas Bushnell, BSG
> In article <87ptsuv...@becket.becket.net>, tb+u...@becket.net
> (Thomas Bushnell, BSG) wrote:
>
> > I can think that Scheme is the bee's knees, no matter if "industry"
> > likes it or not.
>
> Sure, but if there weren't an industry out there you wouldn't have a
> computer to turn your abstract admiration of Scheme into any kind of
> reality. It's one thing to admire the lambda calculus in the abstract.
> It's quite another to actually write a Scheme program and watch it run on
> a 1 gigahertz pentium with 512 MB of RAM that cost less than a month's
> rent.
Sure. But I do that on a Pentium that was designed with running
Micro$loth software. I don't think that Scheme's brilliance had
anything to do with the availibility of my nifty PC, and yet, I get to
run it on that PC!
> Money is far from a perfect barometer of how well people's needs a being
> met, but IMO it's a damn sight better than anything else anyone has been
> able to come up with. It's kind of like what Churchill said about
> Democracy: it's the worst system we have, except for all the others.
I'm not complaining about money or commercialism. I'm saying that
they are not all there is, and that, indeed, the best things in life
are not purchasable at all.
The attitude of some seems to be "if Scheme isn't loved by industry,
it must suck". This is wrong on about a thousand different levels at
the same time, but it's really weird to see people who *like* Scheme
say it.
Thomas Bushnell, BSG
> I heartily agree with this, but I think this is a necessasry but far from
> sufficient step. Freeing yourself from the tyranny of capitalism can only
> be done by becoming a capitalist (I prefer the term "businessman")
> yourself.
Hogwash. If you buy into the list of goods that the businessmen tell
you that you should organize your life around, then you are indeed in
thrall to them. Becoming your own businessman doesn't actually help,
the thralldom remains. As long as you value your life by how many
widgets you own or can buy, you are in bondage.
Most of us know this at a deeply instinctual level, and have plenty of
acquaintance with the most wonderful things of life, none of which can
be purchased or sold. But we let ourselves be talked into taking the
business world as being the only "real world", and let people argue
that we should approach every question from a "business perspective".
An excellent way to free yourself from capitalism is to stop judging
your life by an economic metric. I don't argue for communism; if you
are debating *public policy*, sure, I'm quite content with liberal
capitalism. But that's just this little corner of my life, hardly the
center.
I am (mostly) free from capitalism because I am (mostly) not in
bondage to *things*. I have been blessed with the good luck to have
rather more things than most of the worlds people; while I'm a poor
graduate student in local context, a more global context would
describe me as fabulously rich.
And this is, I think, still relevant to the original point, which was
whether Scheme systems should give the user "what they want" or "what
they think they want" (either one). My answer is "sure, if *you* want
to do that, go ahead, but don't think you *must* do it. You are free;
you are not in bondage."
Thomas
Erann Gat
(Thomas Bushnell, BSG) wrote:
Actually, the attitude seems to be more, "If Scheme isn't loved by
industry then industry sucks."
My attitude is: if Scheme isn't loved by industry then Scheme is not
*effective*. Maybe you don't care about being effective, but I do. Where
I work I see countless millions of taxpayer dollars that are being wasted
solving non-existent "problems" that would simply evaporate if people used
Lisp more. I want to do something about that. Freeing myself from the
clutches of my employer does nothing to address that problem; quite the
opposite.
> I am (mostly) free from capitalism because I am (mostly) not in
> bondage to *things*.
You imply that freeing yourself from crass materialistic desires
necessarily frees you from capitalism. It doesn't. I work with people
whose dream is to send a spacecraft to a distant planet. That's a
materialistic desire too: a spacecraft is a very, very expensive toy.
Would you recommend to my colleagues that the best way to fulfillment is
to give up on their vision just because it's expensive?
Look, this isn't really about money, it's about *teamwork*. If you make a
plot of productivity versus the number of people working together towards
a common goal it's a sort of bell-shaped curve. At one extreme,
individuals have a certain range of productivity. But if you gather
people together into a team then individual productivity within the
context of the team can rise dramatically over what individuals can
accomplish working alone. At some point the trend reverses, and
organizations become too big and productivity goes down again. The reason
C++ and Java are effective and Scheme is not has nothing to do with C++,
Java, and Scheme. It has to do with the fact that for whatever reason C++
and Java users are better at organizing themselves into teams (a.k.a.
companies) than Scheme prorgammers are. (Ironically, one of the reasons
for this might be precisely that C++ and Java make it so hard to get
anything done that C++ and Java programmers have no choice but to band
together with other people in order to accomplish anything at all.)
Capitalism, money, and materialism are mechanisms for motivating people to
work together as a team. (They are, of course, much more than just that,
but they are that.) They are not the only mechanisms for doing so, but
they are by far the most effective. That's why I embrace capitalism.
It's not because I want a new SUV. It's because I want much more than
that. I want to go to Mars.
E.
Michael J. Fromberger
g...@jpl.nasa.gov (Erann Gat) wrote:
> My attitude is: if Scheme isn't loved by industry then Scheme is not
> *effective*. Maybe you don't care about being effective, but I do.
> Where I work I see countless millions of taxpayer dollars that are
> being wasted solving non-existent "problems" that would simply
> evaporate if people used Lisp more. I want to do something about
> that. Freeing myself from the clutches of my employer does nothing
> to address that problem; quite the opposite.
I disagree with the first sentence, but I think the rest is on the mark.
I think, however, that the reason Scheme isn't "loved by industry" (for
whatever that means), is primarily a problem of ignorance, rather than
the language's effectiveness.
I'm not claiming Scheme (or, more generally, Lisp) is a panacea for all
problems -- we're all aware it has some shortcomings, which the
community is working hard to address. However, even as it is, there are
lots of places where Scheme and Lisp could have a powerful influence for
the good, and I _think_ the reason this doesn't happen as often as it
should boils down to: People in industry don't generally know about
them.
-M
--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA
Anton van Straaten
> wasted solving non-existent "problems" that would simply evaporate if
> people used Lisp more. I want to do something about that.
Hear, hear. You can also substitute "customer dollars" or "shareholder
dollars" there.
> The reason C++ and Java are effective and Scheme is not has nothing
> to do with C++, Java, and Scheme. It has to do with the fact that for
> whatever reason C++ and Java users are better at organizing themselves
> into teams (a.k.a. companies) than Scheme prorgammers are. (Ironically,
> one of the reasons for this might be precisely that C++ and Java make it
> so hard to get anything done that C++ and Java programmers have no
> choice but to band together with other people in order to accomplish
> anything at all.)
I would turn that around and say that C++ and Java provide *built-in*
features that better support team programming. There's no irony or accident
there, it's one aspect of a causal relationship.
Anton
Anton van Straaten
> I think, however, that the reason Scheme isn't "loved by industry" (for
> whatever that means), is primarily a problem of ignorance, rather than
> the language's effectiveness.
>
> I'm not claiming Scheme (or, more generally, Lisp) is a panacea for all
> problems -- we're all aware it has some shortcomings, which the
> community is working hard to address. However, even as it is, there are
> lots of places where Scheme and Lisp could have a powerful influence for
> the good, and I _think_ the reason this doesn't happen as often as it
> should boils down to: People in industry don't generally know about
> them.
Also, "knowing about them" requires more than simply being aware of their
existence: it requires some real understanding of the kinds of benefits they
might offer.
That's extraordinarily difficult, because it tends to require traversing a
large language, knowledge, and culture gap, while dealing with things like
infrastructure constraints; pressure and resistance from managers,
customers, and peers; limited time for experimentation; often severe
consequences for failures, especially when they involve unfamiliar factors;
etc...
Anton
Jeffrey Siegal
> Capitalism, money, and materialism are mechanisms for motivating people to
> work together as a team. (They are, of course, much more than just that,
> but they are that.) They are not the only mechanisms for doing so, but
> they are by far the most effective.
It isn't clear that's true at all in the case of software, and certainly
not "by far." The free software model shown a lot of success as a model
for encouraging and organizing effective teamwork. However, I don't see
much of that using Scheme.
Thomas Bushnell, BSG
In article <gat-251102...@k-137-79-50-101.jpl.nasa.gov>,
g...@jpl.nasa.gov (Erann Gat) wrote:
> My attitude is: if Scheme isn't loved by industry then Scheme is not
> *effective*. Maybe you don't care about being effective, but I do.
Of course I care about being effective. But effective for *what*?
Erann Gat
<j...@quiotix.com> wrote:
Yeah, I thought about the free software model while I was writing that,
but I decided to stick with my claim. Free software has had success only
in one very narrow market niche: software whose market is the people who
write software for the people who write software for people who write...
Because of the ciruclar\ dynamics of this market it is a self-sustaining
mini-economy. But (1) it is heavily subsidised by the "real" economy and
(2) it has not yet been successful in breaking out of its circular niche.
So I think money can still safely lay claim to being more effective than
whatever it is that motivates people to work on free software. But
reasonable people could disagree.
E.
Erann Gat
<Michael.J.Fromberger-...@merrimack.dartmouth.edu>,
"Michael J. Fromberger" <Michael.J....@Clothing.Dartmouth.EDU>
wrote:
> I think, however, that the reason Scheme isn't "loved by industry" (for
> whatever that means), is primarily a problem of ignorance, rather than
> the language's effectiveness.
Yes, it's a problem of ignorance. But it's not necessarily ignorance of
Scheme in the business community. It could be ignorance of business in
the Scheme community.
E.
Jeffrey Siegal
> Yeah, I thought about the free software model while I was writing that,
> but I decided to stick with my claim. Free software has had success only
> in one very narrow market niche: software whose market is the people who
> write software for the people who write software for people who write...
I'm afraid I must disagree. The market for internet infrastructure
software, which is almost entirely dominated by free software is not
people who write software. And the bulk of the market for Linux at this
point is not people who write software either, it is people who run servers.
> Because of the ciruclar\ dynamics of this market it is a self-sustaining
> mini-economy. But (1) it is heavily subsidised by the "real" economy and
> (2) it has not yet been successful in breaking out of its circular niche.
Even to the extent tha the market is people who write software, it isn't
clear that it is "subsidized" to any greater degree than any other piece
of software that supports the software writing process. Certainly all
such software (except perhaps games) is a means to an end that is
ultimately paid for by consumer of something else, but that's not a
subsidy, it is just a production chain.
> So I think money can still safely lay claim to being more effective than
> whatever it is that motivates people to work on free software. But
> reasonable people could disagree.
Without a doubt.
Michael J. Fromberger
> Michael J. Fromberger wrote:
> > I think, however, that the reason Scheme isn't "loved by industry" (for
> > whatever that means), is primarily a problem of ignorance, rather than
> > the language's effectiveness.
>
> Yes, it's a problem of ignorance. But it's not necessarily ignorance
> of Scheme in the business community. It could be ignorance of
> business in the Scheme community.
Yes, that's probably also a factor.
Thomas Bushnell, BSG
> Yeah, I thought about the free software model while I was writing that,
> but I decided to stick with my claim. Free software has had success only
> in one very narrow market niche: software whose market is the people who
> write software for the people who write software for people who write...
This is simply not true. Way back in the mid nineties, my new
optometrist in Cambridge, MA, was thrilled when he learned I worked
for the FSF, and spent a long time (annoyingly long, really) talking
all about his accounting and billing and patient management system,
all using a Linux-based system.
Thomas Bushnell, BSG
> Yes, it's a problem of ignorance. But it's not necessarily ignorance of
> Scheme in the business community. It could be ignorance of business in
> the Scheme community.
Or, it could be that some Scheme hackers have more important things on
their minds than business.
Jeffrey Siegal
> Or, it could be that some Scheme hackers have more important things on
> their minds than business.
I'd believe that if I saw a thriving community producing lots of high
quality software using Scheme. As hard as I might try to see that, I
really don't.
Thomas Bushnell, BSG
Really? I think there are people making high quality software using
Scheme. I suspect they just aren't making anything you happen to be
interested in. It seems churlish to take that as a sign that they
aren't doing anything at all.
Jeffrey Siegal
I think you deliberately misread my post. I do see people making high
quality software using Scheme, but only to a very small extent compared
with other languages.
Craig Brozefsky
> > Ah, see now you are recognizing the defining characteristic of
> > capitalism and the problem of workers who have to work to maintain
> > their existence (pay mortgage, eat), but are dependent upon the
> > "hirers" aka the capitalists.
>
> Right, except that the same situation also occurs in communist countries,
> except that the hirer there is called "the government" instead of "the
> capitalists".
I assume we're talking about the USSR when you say "communist"
countries, and for the most part I agree with you because the USSR
never did away with that, it mutated into a form of state capitalism.
Closer examples of communism (meaning worker owned and managed
service/production) might be the short-lived worker-run factories of
the during the Spanish civil war (before the fascists backed by
capitalists killed them), or kibbutzes. Specific examples in the
technology sector would be Red Bean or other server/software coops.
> > I think we need to look at freeing ourselves from that dependence upon
> > the hirers. To do that we need to develop our tools as *WE* need
> > them, so that *WE* can get the job done. We also need to share our
> > tools with each other, so that we can solve problems without having to
> > have a big pool of money to license our tools from the hirers. This
> > doesn't apply to just us Scheme and Lisp users either, it applies to
> > programmers at all levels of skill. Unless this happens I don't see
> > software development as an art or discipline ever maturing. It will
> > always be retarded by the need to oversimplify it, to homogenize it,
> > and to carve it up with patents and copyrights so that capitalists can
> > extract rent for the work we do for them and their interests.
>
> I heartily agree with this, but I think this is a necessasry but far
> from sufficient step. Freeing yourself from the tyranny of
> capitalism can only be done by becoming a capitalist (I prefer the
> term "businessman") yourself. To do that you need more than just
> mastery of the tools of your trade, you also need mastery of the
> tools of the capitalist/business trade: marketing, sales, finance,
> management. Lisp by itself is not enough.
This is a very common sentiment in the U.S. which has a long history
of the "small landowner" or "entrepreneur". As someone who is living
this, I can see some shortcomings with it which make me think that
just being another capitalist is not going to solve the problem we
face:
* Only so many of us can become "hirers" while the rest of us remain
the hired. There are alternatives to being a business where this is
not the case -- coops, and worker owned businesses (participatory
economics), but they still suffer from the other limitations in this
list.
* Requires either a minor miracle, or a sufficient pool of capital
from an existing capitalist to take the first steps of develoment,
and to make it from the time of conception, thru development, and
into the first saleable version. This investment capital is very
hard to come by now, and even in the recent past it was only
attracted to outrageous claims wrt ROI. My experience with the
minor miracle route leads me to believe that it cannot be
generalized into a strategy.
* Small capitalists are an endangered species in our current economy
with its incredibly strong monopolist tendencies. Often their
markets are invaded, or they are shut out due to copright/patent
costs. They have been squeezed from standards bodies as well.
* It makes us competitors with one another along many lines, which
means the tendency towards hoarding tools and attempting to collect
rent from one another for them will continue.
Erann, I'm inclined to take your insistence upon the idea that money
is an expression of need and that we can free ourselves thru business,
being driven entirely by money, is based on theory and not practice.
My experience in a small software development business tells me that
this your view is an oversimplification. You say your experience is
in the aerospace industry, a sector funded almost entirely with
tax-payer money and government funding which is dominated by some very
large aerospace companies and is anything but a shining example of
competition and leanness. Have you ever run or even been the employee
of a small business? I think that we are coming from very different
worlds. I have been pointing out problems I've experienced directly,
and you throw up an assertion about the magical powers of money in
reply. For an objectivist of any strain you have an awful lot of
unsubstantiated claims and assertions about money and capital (some of
which have been pointed out by others already) and I have not the time
or the energy to address them all.
--
Sincerely,
Craig Brozefsky <cr...@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
Erann Gat
(Thomas Bushnell, BSG) wrote:
I thought I explained that in the rest of my post. Effective for getting
things done. Big things. Like sending a spacecraft to Mars, or building
a search engine like Google, or an operating system like Linux. (Note
that I'm not saying that Scheme *can't* be effective for those things -- I
believe it can. I'm just saying that in the current world, it isn't.)
> Or, it could be that some Scheme hackers have more important things on
> their minds than business.
Like what? (That's a serious question, not a roundabout way of denying
that there are things more important than business. I'm just curious what
you think those things are.)
E.
Erann Gat
> Erann Gat wrote:
> > Yeah, I thought about the free software model while I was writing that,
> > but I decided to stick with my claim. Free software has had success only
> > in one very narrow market niche: software whose market is the people who
> > write software for the people who write software for people who write...
>
> I'm afraid I must disagree. The market for internet infrastructure
> software, which is almost entirely dominated by free software is not
> people who write software. And the bulk of the market for Linux at this
> point is not people who write software either, it is people who run servers.
OK, I concede the point.
E.
Erann Gat
<cr...@red-bean.com> wrote:
> g...@jpl.nasa.gov (Erann Gat) writes:
>
> > > Ah, see now you are recognizing the defining characteristic of
> > > capitalism and the problem of workers who have to work to maintain
> > > their existence (pay mortgage, eat), but are dependent upon the
> > > "hirers" aka the capitalists.
> >
> > Right, except that the same situation also occurs in communist countries,
> > except that the hirer there is called "the government" instead of "the
> > capitalists".
>
> I assume we're talking about the USSR when you say "communist"
> countries, and for the most part I agree with you because the USSR
> never did away with that, it mutated into a form of state capitalism.
Yes.
> Closer examples of communism (meaning worker owned and managed
> service/production) might be the short-lived worker-run factories of
> the during the Spanish civil war (before the fascists backed by
> capitalists killed them), or kibbutzes.
Yes.
> * Requires either a minor miracle, or a sufficient pool of capital
> from an existing capitalist to take the first steps of develoment,
> and to make it from the time of conception, thru development, and
> into the first saleable version.
No. Sufficient pools of capital are neither necessary (Oracle was started
on $2,000) nor sufficient (E-toys) and sometimes can actually be harmful
(Webvan).
> Erann, I'm inclined to take your insistence upon the idea that money
> is an expression of need and that we can free ourselves thru business,
> being driven entirely by money, is based on theory and not practice.
Why?
> My experience in a small software development business tells me that
> this your view is an oversimplification.
Of course it's an oversimplification. Anything that's short enough for a
usenet posting is going to be an oversimplification. Why do you assume
that what I write here is the sum total of my beliefs?
> Have you ever run or even been the employee of a small business?
That depends on what you consider small, and what you consider a
business. I tried unsuccessfully to start a business with one partner.
I've worked at several places (some were businesses, some not) with a few
dozen to a few hundred employees. I've also worked as an independent
contractor. And my father was raised on a kibbutz, so a lot of my views
are informed by his experiences and opinions.
> I think that we are coming from very different
> worlds. I have been pointing out problems I've experienced directly,
> and you throw up an assertion about the magical powers of money in
> reply.
I have done no such thing. Magical powers? Where on earth did you get
that idea?
> For an objectivist of any strain you have an awful lot of
> unsubstantiated claims and assertions about money and capital (some of
> which have been pointed out by others already) and I have not the time
> or the energy to address them all.
Oh, woe is me! Because I have failed to substantiate all my assertions I
shall now be deprived of the full measure of your wisdom. Oh whatever
shall I do?
E.
ozan s yigit
i don't either, but it is also worth noting that companies that produce
such software for internal use are not known to chat about it on usenet.
there may be (just maybe) such work in the background.
the attribution of "important things" to scheme hackers brings back
fond memories. how long does it take for important things to surface?
a decade? more? patience is a virtue so long as the patient is alive.
Thant Tessman
Oh man, I go into heads-down mode for a month and miss a big ol' thread
about captialism and communism. Damn.
-thant
Sander Vesik
>
>> Thomas Bushnell, BSG wrote:
>> > Or, it could be that some Scheme hackers have more important things on
>> > their minds than business.
>>
>> I'd believe that if I saw a thriving community producing lots of high
>> quality software using Scheme. As hard as I might try to see that, I
>> really don't.
>
> i don't either, but it is also worth noting that companies that produce
> such software for internal use are not known to chat about it on usenet.
> there may be (just maybe) such work in the background.
>
> the attribution of "important things" to scheme hackers brings back
> fond memories. how long does it take for important things to surface?
> a decade? more? patience is a virtue so long as the patient is alive.
True - but one would then see large amounts of ads for scheme programmers
to write and maintain those - and from time to time such would appear
on the marketplace after having been productized - such does happen from
time to time.
The decision / hurdle process for using scheme goes something like this:
[1] you need to have a compiler and be sure that it is sufficently
bugfree and that you can be sure of this over the lifetime
of the product including the support only phaseout (which
can last many-many-many years). Think COBOL (no, its not dead).
[2] if you can't buy [1] from somebody or be certain beyond doubt
that [1] will happen you need to hire somebody to do this
and be certain you can hire a next person should the first one
get hit by a truck / move to Himalays to herd yakks
[3] the same really applies to having a debugger, a way to create
patches you ship to customers, etc.
[4] you need to be certain that you can get a team with similar
experience in system design, programming and testing scheme
programs as you would get for language x. This is presently
slightly hard, as people with 3-5 years of experience in
commercial scheme software development in the area your
project is going to tackle are not likely to abound (for
almost any area, really).
[1] and [2] are things that add cost - very real cost - over say using C.
[4] is probably just a killer - if you can't find people you are stuck
and re-training is most likely going to be too expensive.
>
> oz
> ---
> music is the space between the notes. | www.cs.yorku.ca/~oz
> -- claude debussy | york u. dept of computer science
--
Sander
+++ Out of cheese error +++
Thomas Bushnell, BSG
Erann Gat wrote:
> Capitalism, money, and materialism are mechanisms for motivating people to
> work together as a team. (They are, of course, much more than just that,
> but they are that.) They are not the only mechanisms for doing so, but
> they are by far the most effective.
The question is not, however, what is the most effective way to get
other people to do things--it's about whether we should allow
ourselves (and our development efforts related to Scheme) to be
controlled by those things. I do not want to be controlled by such
things.
Moreover, if it is destructive to be controlled by such things, then
it seems to me that it would be unethical to try and use them as
levers to control other people, regardless of whether that would be
effective.
Thomas
Erann Gat
(Thomas Bushnell, BSG) wrote:
> Erann Gat wrote:
> > Capitalism, money, and materialism are mechanisms for motivating people to
> > work together as a team. (They are, of course, much more than just that,
> > but they are that.) They are not the only mechanisms for doing so, but
> > they are by far the most effective.
>
> The question is not, however, what is the most effective way to get
> other people to do things--
It is if you have goals that are more than you can accomplish working alone.
> it's about whether we should allow
> ourselves (and our development efforts related to Scheme) to be
> controlled by those things.
Notice that I said that money etc. are mechanisms for *motivating* people,
not for controlling them (though they certainly can be that too). I
believe that money is just a tool. Like all tools it can be used for good
and ill. But I think that focusing on the evils that money can lead too
tends to blind some to the good that it can do.
E.