lisp as a mutiple team programming language?
Jacques Wainer
I have no doubts that Lisp is a great programming language for a
SINGLE programmer, in terms of programmer productivity. (But there was
some postings some time ago of very competent Lisp programmers
declaring that they are even more productive in Python.)
But it is not clear to me whether Lisp is even a reasonable language
for a TEAM of programmers.
I think that an important component of team programming is lets call
deontinc programming, for the lack of a better name. Constructs that
forbids and forces the other programmer to do stuff. Lisp is weak in
forbiding constructs, and totally lacks forcing constucts. For example
comparing with Java, which I think is a lousy single programmer
language, but a reasonable team language :
- that package system of lisp by default does not forbids one from
meadling on another programmer name space. Java does, and by default
different programmers (directories) are in different namespaces,
which in Lisp must be explicitly done using packages
- java has constructs like abstract methods and interfaces that force
the other programmer to do stuff.
Anybody has seen or done experiments, or had some experiences with
Lisp as a multiple programmer langauge, and is there any one thinking
about a richer set of deontic constructs in Lisp?
thanks
jacques
Julian Stecklina
[...]
> - that package system of lisp by default does not forbids one from
> meadling on another programmer name space. Java does, and by default
> different programmers (directories) are in different namespaces,
> which in Lisp must be explicitly done using packages
I think that's a question of planning.
> - java has constructs like abstract methods and interfaces that force
> the other programmer to do stuff.
I know the concept of abstract methods from Pascal, but I do not think
it would be really necessary in CL. Can someone point this out?
Regards,
Julian
--
Meine Hompage: http://julian.re6.de
Ich suche eine PCMCIA v1.x type I/II/III Netzwerkkarte.
Ich biete als Tauschobjekt eine v2 100MBit Karte in OVP.
Nils Goesche
>
> I have no doubts that Lisp is a great programming language for a
> SINGLE programmer, in terms of programmer productivity. (But there was
> some postings some time ago of very competent Lisp programmers
> declaring that they are even more productive in Python.)
Did Erann Gat say that? That's not quite how I recall it, but I am
not sure.
> But it is not clear to me whether Lisp is even a reasonable language
> for a TEAM of programmers.
>
> I think that an important component of team programming is lets call
> deontinc programming, for the lack of a better name. Constructs that
> forbids and forces the other programmer to do stuff. Lisp is weak in
> forbiding constructs, and totally lacks forcing constucts. For example
> comparing with Java, which I think is a lousy single programmer
> language, but a reasonable team language :
>
> - that package system of lisp by default does not forbids one from
> meadling on another programmer name space.
I don't get it. If you don't want anybody use somebody else's
internal symbols, just tell your programmers so. If anybody
violates that requirement, fire them. They might, however, try
out if they could make good use of some internal symbol before
telling the other guy to make it external, only to find out that
they don't really need it after all and tell him to make it
internal again.
> Java does, and by default
> different programmers (directories) are in different namespaces,
> which in Lisp must be explicitly done using packages
Again, what do you fear? That some programmer is too dumb to
put his code into packages? Didn't anybody /design/ the software
before everybody starts coding?
> - java has constructs like abstract methods and interfaces that force
> the other programmer to do stuff.
Are your programmers so lazy? Do they intentionally break stuff?
Where do you hire them, I wonder? Whatever, you could still do
(defclass abstract ()
())
(defmethod interface ((self abstract))
(mail-to 'boss)
(error "You lazy bastard didn't override the interface method."))
or play with INITIALIZE-INSTANCE.
> Anybody has seen or done experiments, or had some experiences with
> Lisp as a multiple programmer langauge, and is there any one thinking
> about a richer set of deontic constructs in Lisp?
I hope not :-)
Regards,
--
Nils Goesche
"Don't ask for whom the <CTRL-G> tolls."
PGP key ID 0x42B32FC9
Erik Naggum
| I have no doubts that Lisp is a great programming language for a SINGLE
| programmer, in terms of programmer productivity. (But there was some
| postings some time ago of very competent Lisp programmers declaring that
| they are even more productive in Python.)
Are you sure they were very competent Common Lisp programmers? All of
the largely disgruntled Common Lisp programmers who have argued in favor
of Python seem to have some serious problems actually _liking_ Common
Lisp enough to become "very competent" in them.
| But it is not clear to me whether Lisp is even a reasonable language for
| a TEAM of programmers.
The surgical team model you find described in Frederick P. Brooks, jr:
The Mythical Man-month appears eminently suitable for Common Lisp, with
one chief programmer-cum-designer and a support staff who writes what
would effectively be supporting librararies. Even though it generally
takes more time to write library code than application code, writing good
specifications for them would be the chief designer's task, so he could
write code using it. I can imagine this to work in stages, where the
chief programmer quickly writes a prototype with his design, then hands
off the task of solidifying and optimizing it to an assistant, which
would then replace the prototype seamlessly upon completion.
| I think that an important component of team programming is lets call
| deontinc programming, for the lack of a better name.
I presume that you mean "deontic".
| Constructs that forbids and forces the other programmer to do stuff.
| Lisp is weak in forbiding constructs, and totally lacks forcing
| constucts.
This is a good thing. If you believe in deontic programming, it is a
mistake to believe that (Common) Lisp will ever be able to accomodate
you.
| Anybody has seen or done experiments, or had some experiences with Lisp
| as a multiple programmer langauge, and is there any one thinking about a
| richer set of deontic constructs in Lisp?
Like so many others who have come up with theoretical background for
something else and then blindly wants to force it on everything in sight,
I think you should explain why _you_ believe in deontic logic and why you
think it is so obviously suitable for programming teams that you have
effectively discarded all other means of achieving the same goals. In
other words, it looks like you have discovered a solution and are on the
search for a problem it can solve. This is generally not a good idea.
///
--
In a fight against something, the fight has value, victory has none.
In a fight for something, the fight is a loss, victory merely relief.
Post with compassion: http://home.chello.no/~xyzzy/kitten.jpg
Erann Gat
<car...@cartan.de> wrote:
> In article <hxd6wxp...@vega.ic.unicamp.br>, Jacques Wainer wrote:
> >
> > I have no doubts that Lisp is a great programming language for a
> > SINGLE programmer, in terms of programmer productivity. (But there was
> > some postings some time ago of very competent Lisp programmers
> > declaring that they are even more productive in Python.)
>
> Did Erann Gat say that?
No, I didn't. What I said was that Python is now my language of choice
for single-user Web programming. I've never done a team project in
Python.
FWIW, the Remote Agent Experiment (RAX) was an example of Lisp being used
successfully in a large-team environment.
I believe that success in team programming is a matter of proper
architecture, where architecture means "a set of constraints on a
design." Some languages enforce certain constraints, and so choosing a
language is de facto choosing (at least part of) your architecture. But
whether the constraints imposed by your language are the *right*
constraints for your project is often just a matter of luck because people
for the most part don't actually think about these issues, they just
follow the crowd. At least, that's been my experience.
Erann
Thomas Bushnell, BSG
> But it is not clear to me whether Lisp is even a reasonable language
> for a TEAM of programmers.
It's not clear to me that there are *any* reasonable languages for a
TEAM of programmers.
But it's certainly clear to me that LISP is certainly much better than
average.
Thomas
Steve Long
Erik Naggum wrote:
> * Jacques Wainer
> | I have no doubts that Lisp is a great programming language for a SINGLE
> | programmer, in terms of programmer productivity. (But there was some
> | postings some time ago of very competent Lisp programmers declaring that
> | they are even more productive in Python.)
>
> Are you sure they were very competent Common Lisp programmers? All of
> the largely disgruntled Common Lisp programmers who have argued in favor
> of Python seem to have some serious problems actually _liking_ Common
> Lisp enough to become "very competent" in them.
I agree with what you are implying and think that you are far too kind in your
summation. I have watched people lament the capabilities of Lisp for the past
5 years, jumping to Perl or Java or Python or Jython or Visual Basic or C# or
C++ for no other reason than to play with something else. A different
language will not solve the intrinsic problems: lack of experience and a
failure to engineer a solution. A good craftsman doesn't blame his tools.
sl
Software Scavenger
> It's not clear to me that there are *any* reasonable languages for a
> TEAM of programmers.
One advantage of Common Lisp is that you can use it to design and
implement the best programming language for the team project. One of
the most important features of such a team programming language is
that it has clear and simple interfaces between the work of different
programmers. The other important feature is that the abstractions of
the language are the abstractions of the project, and that there isn't
much code cluttering the expression of those abstractions. Common
Lisp is a good foundation for such a strategy.
Kent M Pitman
Indeed. It's both commonplace and useful to make macros out of existing
system facilities that enforce additional hygiene required by a particular
project but not needed for the language in general.
Thomas Bushnell, BSG
> Indeed. It's both commonplace and useful to make macros out of existing
> system facilities that enforce additional hygiene required by a particular
> project but not needed for the language in general.
Sure, this is is part of why I said Lisp was clearly (IMO) way better
than average.
I'm still unsure, however, whether it actually makes group programming
*work*--I think that this is a *very* hard problem.
Kent M Pitman
We had lots of people collaborating internal to Symbolics with a heavy
amount of new development and interdependent patching and things generally
worked quite fine.
I miss those days and those tools. But they were Lisp-based and did work.
Thomas Bushnell, BSG
Maybe it's that my standard is very high. :)
I think the problem has been solved when programming in a group is no
harder than programming as an individual. I fully grant that
technical mechanisms are not the only problems here. :)
The tools surely solved the problems they tried to solve pretty well,
and I'm confident that a Lisp-based structure will make it much easier
to have all the tools work right.
Pierre R. Mai
> Kent M Pitman <pit...@world.std.com> writes:
>
> > We had lots of people collaborating internal to Symbolics with a heavy
> > amount of new development and interdependent patching and things generally
> > worked quite fine.
> >
> > I miss those days and those tools. But they were Lisp-based and did work.
>
> Maybe it's that my standard is very high. :)
>
> I think the problem has been solved when programming in a group is no
> harder than programming as an individual. I fully grant that
> technical mechanisms are not the only problems here. :)
Why do you think that this is a reasonable standard? As far as I can
tell, few if any human activities that are doable both alone, and in
teams show such a linear scale-up.[1] Even if we only take the
communication aspect of it (and ignore such things as social dynamics,
etc.), Amdahl's law ensures that no linear scale-up can be achieved
for activities that aren't completely independent.
Regs, Pierre.
Footnotes:
[1] Do something in a team is different from n people doing
independent things.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Thomas Bushnell, BSG
> Why do you think that this is a reasonable standard? As far as I can
> tell, few if any human activities that are doable both alone, and in
> teams show such a linear scale-up.[1] Even if we only take the
> communication aspect of it (and ignore such things as social dynamics,
> etc.), Amdahl's law ensures that no linear scale-up can be achieved
> for activities that aren't completely independent.
I'm not sure what kind of "reasonability" you are wondering about.
It's the goal, just like world peace is a goal. I don't think I have
any illusions about how achievable the goal is in my lifetime.
My point is that Lisp may be very very good at attacking the problem,
but it's a mistake to say that it solves it. Maybe it's not a very
big point; I didn't intend it to be.
Thomas
Software Scavenger
> I'm still unsure, however, whether it actually makes group programming
> *work*--I think that this is a *very* hard problem.
Non-traditional group programming: The delivered software project
consists of a tree of subsystems. I.e. each subsystem has its own
subsystems, etc. Assign one programmer to each subsystem. Make sure
they have clear and simple interfaces. This is how a large software
system should be constructed, not by using traditional group
programming. The difference is that the communication between
programmers should be reduced to clear and simple interfaces, so two
programmers can make each other understand how to make their
subsystems work together, even if both programmers consider each other
to be idiots.
One key to group success is that the blame for any failure should be
easy to identify. If the subsystem written by programmer X doesn't
work, the clear and simple interfaces will make it easy for
programmers Y and Z to prove it. X will be highly motivated to make
that subsystem work, by being so clearly, easily, and fairly, blamed
for it, and by so clearly getting the credit for it when it does work.
Traditional group programming doesn't work because of the phenomenem
known as "the tragedy of the commons." Programmers are motivated to
give the appearance of doing a lot of good work. The nature of
programming is such that the work itself gets sacrificed for the sake
of that appearance. If the programmer does something to improve the
overall quality of the overall system, sacrificing the appearance of
doing good work, that programmer is one of the most likely to get laid
off when the project has cost overruns and cutbacks.
The non-traditional group programming I describe above, on the other
hand, might be the perfect solution to such problems.
Erik Naggum
| Why do you think that this is a reasonable standard?
It is clearly unreasonable as to be indistinguishable from trolling.
Kenny Tilton
Software Scavenger wrote:
>
> tb+u...@becket.net (Thomas Bushnell, BSG) wrote in message news:<87elhcz...@becket.becket.net>...
>
> > It's not clear to me that there are *any* reasonable languages for a
> > TEAM of programmers.
>
> One advantage of Common Lisp is that you can use it to design and
> implement the best programming language for the team project....the abstractions of
> the language are the abstractions of the project.... Common
> Lisp is a good foundation for such a strategy.
I used to argue in the trenches (not to anyone who mattered) at a big
bank for the creation of a bank-specific language, one in which concepts
and rules specific to the bank would be embedded.
I thought this would make the low-level programmers insanely productive
and give better programmers a career path in which they could move up in
income-power-status without abandoning coding to become a manager: they
could move to the team supporting the bank-specific language. The
downside is that average folk get crippled resumes because no one else
wants their skills.
Especially in an organization like a bank that writes a lot of code and
especially again in lots of different applications, this pipe dream
could pay off nicely, I thought.
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
Kent M Pitman
> ... As far as I can
> tell, few if any human activities that are doable both alone, and in
> teams show such a linear scale-up.[1] Even if we only take the
> communication aspect of it (and ignore such things as social dynamics,
> etc.), Amdahl's law ensures that no linear scale-up can be achieved
> for activities that aren't completely independent.
I largely agree with this.
Communication is not a programming-language based problem.
I think some key reasons CL is as good or better than other languages
for team use is:
- It allows incremental loading of individual program systems and
patch files, so that each user doesn't have to do a full recompile
in order to get recent contributions of others. In approximate terms,
the amount of work needed to accept a patch is proportional to the
size of the patch, not the size of the overall system.
- It is introspective and so allows object-oriented tools to discover
versions of loaded systems in a dynamic way, allowing changes to be
dependent on such info and bug reports to correctly record such issues.
- Program data being debugged is not usually injured by loading patches,
so the decision to receive patches does not force a break in stream of
concentration by someone doing an unrelated activity.
Probably there are others.
Erik Naggum
| The downside is that average folk get crippled resumes because no one
| else wants their skills.
If they can learn one domain-specific language in a reasonable amount of
time and become proficient in it, why would they be unable to repeat such
an endeavor? If they could not learn it, they would move on to something
else before it became a millstone around their neck, right? So I do not
understand this argument.
Paul Tarvydas
"Jacques Wainer" <wai...@ic.unicamp.br> wrote in message
news:hxd6wxp...@vega.ic.unicamp.br...
>
> I have no doubts that Lisp is a great programming language for a
> SINGLE programmer, in terms of programmer productivity. (But there was
> But it is not clear to me whether Lisp is even a reasonable language
> for a TEAM of programmers.
> Anybody has seen or done experiments, or had some experiences with
> Lisp as a multiple programmer langauge, and is there any one thinking
> about a richer set of deontic constructs in Lisp?
Let me turn the question on its ear.
Why do we think that multi-person programming is such a good thing and what
aspect of programming are we talking about?
I suggest that programming consists of at *least* two activities - one that
should be done with multiple people, and one that should be done with a
single person (or persons, in parallel).
Lisp supports the multiple-person activity better than most other textual
languages.
Java and its ancestors support the single-person activity and add baubles
that make it look as if that activity can be done by multiple persons, while
not really achieving gains on the actual mutiple-person-activity side.
Multi-person Activity: Design.
Single-person(s) Activity: Coding.
[There are more striations to this model, but I simplify to make my main
point.]
Design includes, at least:
- figuring out what the problem is
- factoring the problem
- describing a solution to the problem (in terms of its factors)
- experimentation with various solution techniques
- testing of the design
- integration [N.B.!]
- significant *reductions* in the amounts of code required to express the
final solution [N.B.!]
- communicating precisely what code needs to be written (and what must not
be written).
Coding includes, at least:
- expressing specific actions in some programming language
- profiling
- tuning
- testing for implementation defects
- engineering (trade-offs between performance and expression)
- maintenance (expression of the solution so that it is servicable by other
people).
Characteristics of a good Design Langage:
- maleability, flexibility
- non-interference (the ability to experiment with and test designs in small
amounts of time; the ability to use any applicable design paradigm (e.g.
OOP, declarative, procedural, rule-based, etc.)).
Characteristics of a good Coding Language:
- ability to express precise details that include:
-- performance issues
-- maintainability issues
-- application issues
-- target-specific issues.
Designs that are tested only once turn out to be bad designs.
The Coding languages tend to be lousy Design languages. It takes too much
work to get to a point where a design can be tested. Designs built in
Coding languages tend to be built only once and, hence, have major Design
problems that last forever. This is discovered very late in the development
cycle, at a point where "too much investment" (time, pride) has been
invested in the Code itself. Major changes to the Design tend to be
unappealing and "kludges" are authorized. Kludges, of course, lead to an
increase in the number of Function Points and an ensuing decrease in
reliability and maintainability. This can be avoided by getting the Design
right before allowing Coding to commence.
In my observation, Design needs to be done my more than one person. Design
requires the amalgamation of a number of disciplines, including:
- user interface design
- design for maintainability
- design for expressibility
- design for reduction of Code
- design for testability
- design for/with paradigm(s).
No one person possesses the talent to balance all of these requirements,
hence, design by more than one (smart) person is often better than design by
a single (smart) person. The best way to Test a Design is to produce a
working system in a short amount of time, then criticize it and rework it.
The trade-off is that the test design may be defficient in some Engineering
sense (too big, too slow, etc.). Designs can, also, be tested with more
manual methods.
Coding, on the other hand, is a single-person activity. Many people can
perform coding at the same time without interfering with each other, if and
only if, the Design has been well-tested. Coding requires concentration and
attention to minute detail. Coding is performed on pieces that are small
enough that they can be kept in one's head, that can be optimized and
engineered in a consistent way by one person for a specific application.
Coding is what the hardware people call "production engineering".
Doing "multiple-person programming" during the Coding phase(s) is not a
productive use of resources. If the units of code are too large to be
handled by a single person, this is an indication that the Design has not
been finished (alarms should go off - why are you Coding when the Design is
unfinished?). If the inter-unit interfaces are being jiggered, this is an
indication that the Design has not been finished (or is being reworked "on
the fly" and without further testing - bad news).
Recipe for disaster:
(a) Sketch on the whiteboard the "design" - a bunch of boxes and arrows
(b) Design interfaces between the boxes, design the types to be used
(c) Create a Gantt chart that contains a large block of "integration" time
near the end of the schedule.
(d) Begin Coding using a Coding language, making sure that as many people as
possible are involved.
This leads to depth-first implementation and bottom-up design. Both of
these practices lead to code-size growth, not shrinkage. People write reams
of code, constrained to fit the untested interfaces of the design. As the
programmers "flesh out" the design in an ad-hoc manner, the code base grows.
The Design also grows, but, remains untested. The tools (e.g. Java, et al)
help root out second- and third-order problems, e.g. detection of name-space
clashes, detection of type conflicts. The tools don't give any indication
(nor can they possibly enforce) whether the design is sensible, whether it
continues to meet (often-changing) requirements, whether any design issues
have fallen between the cracks. During the whole of this phase, management
and programmers are effectively "flying blind", having no clue as to whether
the goals of the project are being met. They usually get a rude surprise
once the bless-ed integration phase commences. The surprise usually
involves the fact that some major design flaw has been found in the untested
Design and that repairing it properly requires a brand new cycle of Coding
(note that the problem is rarely described this succinctly - design flaws
discovered after so much Coding work are usually mis-labelled as "bugs" and
are treated incrementally as Coding defects instead of as Design defects).
Recipe for mitigating disaster: find a way (manual and technological) to
express a Design in a breadth-first manner that can be tested and iterated.
The Design must address all of the issues listed above (yes, including
integration, including code shrinkage). [Manual methods include CRC cards,
eXtreme Programming, Jef Raskin's Humane Interface mathematics]. [Note that
I do not include UML - IMO, UML is a graphical way of expressing
Coding-level decisions - completely the wrong emphasis].
So, back to the question. I conclude that Lisp is miles better than Java
for the important aspect of multi-person programming - Design.
[We did a survey of textual languages a few years ago, including C++,
Java's, VB, Perl, Tcl/Tk, Python, Smalltalk, Lisp. Lisp was way better than
all of these for what I call Design. Tcl/Tk came in as a distant second.
The others didn't place.].
Lisp is a good Design language because:
- Lisp allows you to factor problems using techniques like lisp-macros and
little languages.
- The descriptions of factored solutions can be very succinct, therefore,
the descriptions communicate the solution well. The descriptions are
couched in terms of the most appropriate paradigm.
- Lisp allows experimentation with various solution techniques - it is
non-intrusive - you don't have to add types until you want to, you can trade
off efficiency for rapid design iteration by choosing generic data
structures (hashes, lists (not List classes - lists)), you can add code and
types incrementally.
- Non-intrusiveness - Lisp allows working code (i.e. a Design iteration) to
be expressed using very little detail.
- Lisp is multi-paradigmatic - Lisp easily supports every paradigm that I
know of (procedural, OOP, rule-based, functional, symbolic,
continuation-based, GUI-based, application-specific-language,
code-generating, tree-transforming, command-based).
- Testing of the design - rapid GUI turn-around, rapid code turn-around,
incremental everything, lets you get to see the design sooner, so you can
kick its tires sooner.
- Integration - by being allowed to design in a breadth-first manner you can
solve the integration issues while you converge the design (on the surface,
most other languages "allow" breadth-first design, but practically this is
not the case - when one has to specify great amounts of detail in a
language, one falls into a depth-first development strategy and "forgets" to
continue designing in a breadth-first manner); by incrementally adding
types, you can flesh out the application type system and test to see how it
affects integration of disparate components.
- Integration - less Code -> fewer Coders -> fewer integration problems ->
less integration time.
Lisp's non-intrusiveness also enables / encourages achieving other Design
goals, such as:
- Significant reductions in the amounts of code required to express the
final solution. When you feel free to experiment (i.e. an experiment is
cheap in time and labour), you *will* experiment. In my company, we had
been living with an OODB data structure for 5 years on a project. One day,
someone tried an experiment - they converted the OODB into a fact base using
Perl. The result was astonishing - a huge reduction (about an order of
magnitude) in the space needed to store the same information and a major
reduction in the amount of code needed to support the concept. This
experiment was avoided for 5 years, because the original design had been
done in a depth-first manner in a Coding language (C++). During the
original development cycle, we started to have a gut feel that something was
wrong with the data structure, but it was too late - the project was already
late being delivered and we had to pull whatever panic attacks we could.
The project stayed in a panicked, deer-caught-in-the-headlights state for 5
years, until we found that we could safely iterate its design using Lisp,
Tcl/Tk and Perl.
- Communicating precisely what code needs to be written (and what must not
be written). Many people are disgusted with the syntax of Lisp, but, the
syntax is very clean and regular. I occassionally chortle to myself about a
former employee to whom I'd assigned the task of finishing a compiler
project (an Eiffel compiler with an experimental incremental linker). The
code I gave to the employee represented the full compiler, less the code
emitter and was entirely written in lisp (emacs lisp, to be exact). The
employee was so shocked and disgusted that he immediately converted the
*whole* thing into C. The conversion took less than a week. Obviously, the
compiler design and code had to have been succinctly expressed for the
conversion to be successful in such a short amount of time (and executed by
such an avid non-lisper). The project was later canned, because it became
unmaintainable and inflexible :-). Sometimes, the most rabid Lisp-haters
will go out of their way to prove why Lisp is such a great tool...
Lisp is very mature - of living langauges, only assembler and Fortran
pre-date it - COBOL is younger than Lisp. Due to this maturation process,
Lisp also has a number of Coding and Engineering features (performance
tuning, ability to specify types, good compilers). Unlike with most other
methods, it is possible to express the Design in Lisp and then use that very
same design to express the final Code, if you feel that this will afford you
some advantages.
In summary, I feel that our desire to compare cheapo consistency-checking
baubles to each other is a misguided attempt to reach a nirvana where
programming has been dumbed-down to the point where we can go to the
unemployment line, pick up casual labourers and have them producing useful
results by the afternoon. It ain't gonna happen! At best, programming will
become an Engineering discipline where thinkers are allowed to perfect their
designs and then precisely specify them to tradespeople for implementation.
Until that happens, languages like C, C++, Eiffel, Java shoulde be used to
do what they're good for - Coding (single-person activity) - and we
shouldn't fool ourselves by imagining that they will ever help us with the
real multi-person programming problem - Design.
Paul Tarvydas
[Aside: in my view, eXtreme Programming is a process that emphasizes Design,
not Coding. Somebody finally had the "aha!" that Design has been
underserviced, and tried to do something about it.]
Marc Spitzer
> * Kenny Tilton
> | The downside is that average folk get crippled resumes because no one
> | else wants their skills.
>
> If they can learn one domain-specific language in a reasonable amount of
> time and become proficient in it, why would they be unable to repeat such
> an endeavor? If they could not learn it, they would move on to something
> else before it became a millstone around their neck, right? So I do not
> understand this argument.
>
> ///
I do not know how it is in other parts of the world, but in my corner
of the US(metro NYC) much of the hiring process is done by the buzz
word brigade. You need to have enough crap on your resume(ejb, jms,
vb, ...) to get past the screeners to see a techinical person. And
since most jobs have a turnover rate of 2-3 years they do not want to
invest much time in you. Also the perception is that you will be here
2-3 years why should we invest in you, it is a bad investment. They
hire employes like they hire consultants.
marc
ps I have been at the same company for 5+ years so I am odd.
marc
Chris Beggy
> - user interface design
> - design for maintainability
> - design for expressibility
> - design for reduction of Code
> - design for testability
> - design for/with paradigm(s).
Thanks for this insightful post.
What do you mean by design for expressibility?
Thanks.
Chris
Paul Tarvydas
"Chris Beggy" <chr...@kippona.com> wrote in message
news:87k7r1l...@lackawana.kippona.com...
> What do you mean by design for expressibility?
Good question - trying to verbalize an answer is making me squirm :-).
Short answer: expressibility is the idea that a problem has been factored
into its greatest common divisors and that its solution has been expressed
in terms of these factors.
A non-expressive solution would be one where the factors are too small to
describe the solution "at a glance".
For example, you could factor a problem down to register transfers (i.e.
assembler), but expressing the problem that way often does not lead to a
meaningful (aka readable) design.
Likewise, one could choose too high a level of abstraction which leaves the
reader guessing at what's going on.
Expressibility, maintainability and testability are all related, but are
different concerns.
Expressibility = can someone else read this Design and understand our design
intentions?
Maintainability = can someone else change the design without causing
unpredicted side effects?
Testability = can someone else test this and be reasonably sure (i.e.
guarantee) that this works as advertised?
Long answer:
One of the few things I remember from my schooling in electrical engineering
is the theory of suppression of sources. It's a way of analyzing a
complicated circuit, one that has lots of places that signals (electrical
sources) can come from. The theory is a trick that simplifies the problem
into a bunch of sub-problems - blot out all of the signal sources, except
one and analyze the circuit (something which is straight-forward). Then
blot out all the sources, except another one, and so on. When you've solved
all of the sub-problems this way, you use the theory to calculate the union
of the effects.
My first full-time job was with Mitel in Ottawa, where I was employed as a
"software test engineer". At first, I didn't have a clue what that meant
and thought that it was mumbo-jumbo to make a dull job seem attractive to a
fresh grad. At the time, Mitel built small PBX's (telephone switching
boxes) that used digital and analogue circuitry and microprocessors. They
could buy fancy ATE's (automated test equipment) that would test for
production defects in a large portion of the circuitry (say, 80% or so). My
job was to find all of the parts of the circuits that couldn't be tested
automatically (e.g. the analogue stuff, the microprocessors, RAM and ROM)
and to devise tests for them.
As I did this job, I found that there were ways that the overall circuits
could be designed that made it hard for me to devise tests and, conversely,
there were ways to design circuits that made it easy to do my job. Usually,
the difference between the two ways added no extra cost to the design and
manufacture. I found myself kibitzing with the designers to get them to
design their circuits so that they satisfied my "needs".
Software design is very complicated. I believe that the idea of viewing the
design from many angles, while suppressing other angles, is a good way to
attack the design problem and to manage it. Analogous to "plan view" in
drafting.
The list of design "jobs" that I gave is not exhaustive nor definitive, but
represents the things that popped into my mind while I wrote the response
(which, probably, represents the list of things that I think are important).
Gedanken experiment:
You have to deliver a software system that is perfect. Like a Civil
Engineer, you are going to affix your Professional Seal to the result, sign
it and certify that you, and only you, are responsible for its final
perfect-ness, under penalty of law. You have a sufficiently large budget.
You have 6 seasoned expert designers that you trust. You assign the each of
them a separate job. You decree that they each get $1M if they've done
their job right, $0 if they didn't. The separate jobs are:
(1) make sure that the GUI is perfect and that users love it
(2) make sure that final product can be easily modified (maintained) to
include new features after we deliver it
(3) make sure that any competent designer can understand the design with the
least amount of effort (expressibility - your original question)
(4) make sure that we write as little code as possible to solve the problem
(less code -> fewer potential problems)
(5) make sure that our testing team can find all of the design defects and
implementation defects before we deliver the system and
(6) make sure that the most appropriate, state-of-the-art paradigms are used
for each sub-problem (-> less code, better maintainability, better
expression of the result).
I'm convinced that each of the six experts would come to the table with
different concerns and that they would be bloody adamant about their
individual concerns (lots of great conflict - could be a good movie or a
book :-).
Does it clarify what I meant?
pt
Software Scavenger
...
> This leads to depth-first implementation and bottom-up design. Both of
There is one minor problem with your whole theory. You want
breadth-first design, tested before implementation. But testing
requires code. Code before overall design implies bottom-up
development. You seem to be saying bottom-up development is to be
avoided. You call it "depth-first implementation and bottom-up
design" but it seems to be the same thing as bottom up development.
The problem with your theory is that in reality bottom up development
is required for breadth first design and testing, because the testing
requires code.
> these practices lead to code-size growth, not shrinkage. People write reams
The excess code does not have to become part of the end product. But
it would be nice if we had a better way to manage it. I should at any
time be able to easily navigate all versions of any subset of my code,
even if they no longer exist in the current version.
Paolo Amoroso
wrote:
> We had lots of people collaborating internal to Symbolics with a heavy
> amount of new development and interdependent patching and things generally
> worked quite fine.
Approximately what fraction of Symbolics employees (more than a thousand at
its peak?) dealt with development?
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
Tim Bradshaw
> If they can learn one domain-specific language in a reasonable amount of
> time and become proficient in it, why would they be unable to repeat such
> an endeavor? If they could not learn it, they would move on to something
> else before it became a millstone around their neck, right? So I do not
> understand this argument.
Ah, you assume people who hire people can read. They can't, they can
only search for fixed strings in CVs. Unless it says `C++' and `UML'
and `XML' you don't get past the pruning stage. And if you have any
multiple-word buzzwords, make sure you provide all possible spellings:
`E10k' *and* `Enterprise 10000' (and probably better make sure
`Enterprise 10k' is in there too).
I have, seriously, failed to get past the pruning stage for saying
`SunOS 4 & 5' rather than `SunOS and Solaris'.
--tim
Thien-Thi Nguyen
> I'm convinced that each of the six experts would come to the table with
> different concerns and that they would be bloody adamant about their
> individual concerns (lots of great conflict - could be a good movie or a
> book :-).
what is the best resolution protocol for these conflicts?
thi
Thien-Thi Nguyen
> There is one minor problem with your whole theory. You want
> breadth-first design, tested before implementation. But testing
> requires code. Code before overall design implies bottom-up
> development. You seem to be saying bottom-up development is to be
> avoided. You call it "depth-first implementation and bottom-up
> design" but it seems to be the same thing as bottom up development.
> The problem with your theory is that in reality bottom up development
> is required for breadth first design and testing, because the testing
> requires code.
if integration points are well-specified, behavior can be provisionally
hard-coded (aka "stubbed"), to enable testing early on. actual implementation
can later replace these stubs very easily. design changes precipitate changes
in both stubs and implementation, the former being easier to handle and thus
motivating delaying the start of the latter (if minimizing implementation
changes is valued).
thi
Will Hartung
"Erik Naggum" <er...@naggum.net> wrote in message
news:32283253...@naggum.net...
> * Kenny Tilton
> | The downside is that average folk get crippled resumes because no one
> | else wants their skills.
>
> If they can learn one domain-specific language in a reasonable amount of
> time and become proficient in it, why would they be unable to repeat
such
> an endeavor? If they could not learn it, they would move on to
something
> else before it became a millstone around their neck, right? So I do not
> understand this argument.
Because I think that many "programmers" today have evolved into simply
sophisticated transcriptionists. The "Programmer Pool" so to speak. I like
to refer to them as simply "coders" rather than so much as "programmers".
They understand how to string lines of code together, but not particularly
how and why things actually work. They cut and paste their way through
problems figuring that it's more a typing error than anything truly deeper.
These "coders" have troubles moving from language to language in the way
that a clerical worker may have trouble moving from Word to WordPerfect. To
the point of saying "Oh, I don't know WordPerfect" as a mean of
disqualifying themselves from any action potentially involving WordPerfect.
These clerical workers "know Word" but not anything about "Word Processing".
They know what buttons to push, but not necessarily what the buttons "do".
When 90% of your day involves writing validation logic for screen forms,
simple interfaces to a database, or summing columns for a report, they don't
particularly need to know much more. But language choice does tend narrow
their options, as they only know how apply the language they've learned,
rather than understanding the concepts that the language was made to
manipulate. When you change languages, the underlying concepts are the same,
the problem is the same, but the scripting involved may be completely
different. Since they never understood the basic concepts, they have
difficulty thinking upwards from concept to language and start with a clean
empty slate in the new language, or punt completely "I don't know
WordPerfect".
Now, certainly, not only must one understand the basic underlying computing
concepts, but also the intricacies of the development language to become
efficient and capable in the language. But, when their point of view is
completely backward, they have problems making the leap to new language.
Will Hartung
(wi...@msoft.com)
Joe Marshall
"Thien-Thi Nguyen" <t...@glug.org> wrote in message
news:kk9vgal...@glug.org...
Fire five of the experts.
Gabe Garza
> "Erik Naggum" <er...@naggum.net> wrote in message
> news:32283253...@naggum.net...
> > * Kenny Tilton
> > | The downside is that average folk get crippled resumes because no one
> > | else wants their skills.
> >
> > If they can learn one domain-specific language in a reasonable
> > amount of time and become proficient in it, why would they be
> > unable to repeat such an endeavor? If they could not learn it,
> > they would move on to something else before it became a
> > millstone around their neck, right? So I do not understand this
> > argument.
>
> Because I think that many "programmers" today have evolved into simply
> sophisticated transcriptionists. The "Programmer Pool" so to speak. I like
> to refer to them as simply "coders" rather than so much as "programmers".
> They understand how to string lines of code together, but not particularly
> how and why things actually work. They cut and paste their way through
> problems figuring that it's more a typing error than anything truly deeper.
;; Rest of very spiffy post snipped
As someone who recently graduated and went on to work for "MegaCorp,"
this all seems completely correct (and very well put). I'd add that I
think the trend is even more malignant. It seems like there's a
culture and set of tools out there that conspire to prevent those
"coders" from ever really getting it.
The language of choice of the group that I work for is Delphi, a
proprietary dialect of Object Pascal sold by Borland that's designed
for "Rapid Application Development" in Windows. It's not at all
fun.
A coworker recently wrote an application that looped over the result
of a query and performed another query on each tuple in the result set
to map a numeric id into a name. It wasn't running fast enough; I
suggested constructing a hash table that mapped the numeric ids to
names and then using that hash table in the inner loop that iterated
over the other table.
He didn't know what a hash table was. Delphi doesn't have a "Hash
Table" component (nor could it, really. It's been 21 years and there
*still* is no escape.) He went to google, found a "THashIntToString"
(or something like that) module someone had written, and used that.
The points:
[1] The language doesn't include hash tables as first-class objects.
It also isn't powerful enough to have hash table objects that are
anywhere near as seemless as those in Lisp.
[2] There's a gap between knowing how to use a hash table and knowing
how to implement one.
[3] Because the language can't support hash tables well (compared to
Lisp), you aren't likely to use them unless you can write a "custom"
hash table each time you need to use them.
[4] The people who typically use these languages probably don't know
enough to implement a hash table, unless someone else has already
written an example conforming to their precise needs.
[5] You could substitute many different things for "hash table" in 1-4.
The net result is that elegance is inhibited, learning is
discouraged, reliance on cutting-and-pasting is encouraged,
and programming in general is tarnished.
Gabe Garza
Kenny Tilton
Erik Naggum wrote:
>
> * Kenny Tilton
> | The downside is that average folk get crippled resumes because no one
> | else wants their skills.
>
> If they can learn one domain-specific language in a reasonable amount of
> time and become proficient in it, why would they be unable to repeat such
> an endeavor?
I said the resumes were crippled, not them.
woof!
Ray Blaak
> The language of choice of the group that I work for is Delphi, a
> proprietary dialect of Object Pascal sold by Borland that's designed
> for "Rapid Application Development" in Windows. It's not at all
> fun.
Not as fun as Lisp, maybe, but if you just *have* to use a compiled language on
a Windows box, Delphi is pretty much the way to do it.
It provides a much better way of accessing the Windows OS compared to
Microsoft's C++ and VB environments.
In general, there is much more evidence of intelligent design: most of the
common stuff can be readily done with existing components, and when one needs
to dig into the guts of things there are well-defined and controlled ways of
doing so. One has full control.
> [5] You could substitute many different things for "hash table" in 1-4.
> The net result is that elegance is inhibited, learning is
> discouraged, reliance on cutting-and-pasting is encouraged,
> and programming in general is tarnished.
Only for stupid programmers. They would suffer the same problems in any
language whenever the slightest bit of creativity is called for.
Any reasonable programmer should be able to whip off any one of these kind of
components on demand very quickly. Delphi also has an active user community
where help is readily available.
Check out comp.lang.pascal.delphi.misc or borland.public.delphi.objectpascal,
for example.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
bl...@telus.net The Rhythm has my soul.
Erik Naggum
| The downside is that average folk get crippled resumes because no one
| else wants their skills.
* Erik Naggum
> If they can learn one domain-specific language in a reasonable amount of
> time and become proficient in it, why would they be unable to repeat such
> an endeavor?
* Kenny Tilton <kti...@nyc.rr.com>
| I said the resumes were crippled, not them.
|
| woof!
You are barking up the wrong tree. Please realize that I was arguing
against the notion that the resumes would be "crippled" -- if they had
acquired a skill in a short amount of time, that should be valuable, etc.
Gabe Garza
> Gabe Garza <g_g...@ix.netcom.com> writes:
> > The language of choice of the group that I work for is Delphi, a
> > proprietary dialect of Object Pascal sold by Borland that's designed
> > for "Rapid Application Development" in Windows. It's not at all
> > fun.
>
> Not as fun as Lisp, maybe, but if you just *have* to use a compiled language on
> a Windows box, Delphi is pretty much the way to do it.
Not Common Lisp?
> > [5] You could substitute many different things for "hash table" in 1-4.
> > The net result is that elegance is inhibited, learning is
> > discouraged, reliance on cutting-and-pasting is encouraged,
> > and programming in general is tarnished.
>
> Only for stupid programmers. They would suffer the same problems in any
> language whenever the slightest bit of creativity is called for.
A point I was trying to make (ineffectively), is that I don't think
it's as simple as "stupid programmers" (or "coders") and "reasonable
programmers." I wouldn't classify beginners as "stupid," yet they're
not likely to know the things that "reasonable programmers" take for
granted. They're not going to know how slow querying a relational
database can be. They're not likely to have an intuitive feel for the
difference between an O(n^2) algorithm and O(n). They aren't even
likely to know what "O" is, for that matter. They're not going to
know the difference between the heap and the stack, or anything else
related to memory. I could go on for a long time...
The problem is that Delphi makes the common things *so* easy that you
need to know very little about programming to make an application that
seems impressive. Make a form, drag down the requisite components,
type a bit of glue to link them together, you've just made a Windows
application with a GUI and a database connection. Nifty.
But what if you need to call into some part of the Windows API that
Borland hasn't provided a wrapper for? Like, say, ODBC? The same
programmer I spoke of earlier regarding the hash table also needed to
do this. But calling into Windows required a lot of knowledge he
didn't have: pointers, function call conventions, the number of bytes
it takes to represent a Word.
Thus, you have an environment that makes it far easier to create an
XML-aware database-connected multi-threaded FTP-server (Delphi does
have an FTP-server drag-and-drop component) then it does to call out
to the operating system (or some third-party library) or use a basic
data structure (like a hash table). Note I'm only commenting on
the disparity: it's no harder to make a hash table in Delphi then in
any other similar language, though it's still a bit more work then
(make-hash-table :test #'equalp).
If you had an environment like Lisp where you wrote programs the same
way the system was written (by typing Lisp, as opposed to a
Delphi-esque dragging of Lisp components onto a form) the disparity
isn't nearly as sharp; you don't have to rely on an IDE to write your
program for you. It's certainly harder to start with, but I think a
beginner would understand programming better by taking this approach.
The subject line was changed to "Dissing Delphi," but I wasn't trying
to say "Delphi is an evil language". I was trying to say that Delphi
encourages ignorant programmers to remain so by trying hard to put a
drag-and-drop interface on everything one could possibly want to do.
Gabe Garza
Fernando Rodríguez
>The problem is that Delphi makes the common things *so* easy that you
Hash tables are rather common... ;-)
>The subject line was changed to "Dissing Delphi," but I wasn't trying
>to say "Delphi is an evil language". I was trying to say that Delphi
>encourages ignorant programmers to remain so by trying hard to put a
>drag-and-drop interface on everything one could possibly want to do.
I guess its actually worse: it encourages ignorant managers to hire ignorant
people to do our job, since 'with vb and delphi anyone can program'. BTW, VB
has the same problem: lots of bells and whistles on top of a weak foundation.
If you want a 'classic' rad tool, I'd go for Borland Builder, it has all the
bells and whistles of Delphi and the STL, in case you need 'exotic' stuff like
lists or maps. ;-)
Of course, as soon as you get sick of C++ you can upgrade to Lispworks and
still use BCB for the nifty gui stuff that capi might lack. ;-)
PS This is sort of related:
The dumbing down of programming
http://www.salon.com/21st/feature/1998/05/cov_12feature.html
-----------------------
Fernando Rodriguez
Alain Picard
> Multi-person Activity: Design.
> Single-person(s) Activity: Coding.
[snip]
and
> Doing "multiple-person programming" during the Coding phase(s) is not a
> productive use of resources.
and finally
> [Aside: in my view, eXtreme Programming is a process that emphasizes Design,
> not Coding. Somebody finally had the "aha!" that Design has been
> underserviced, and tried to do something about it.]
Interesting viewpoint. I think, rather, that the XP people
(myself among them, I guess) think that the source code _IS_ the
design, and that the separation we've been used to is artificial.
This explains the emphasis on pair-programming (i.e. pair-designing)
and the refusal to do any big design up front (you aren't gonna need it).
It also explains the love of dynamic languages, in which refactoring
(aka changing your mind) is not so costly.
The best starting point for interested readers is at
http://c2.com/cgi-bin/wiki?ExtremeProgrammingRoadmap
Ray Blaak
> A point I was trying to make (ineffectively), is that I don't think
> it's as simple as "stupid programmers" (or "coders") and "reasonable
> programmers." I wouldn't classify beginners as "stupid," yet they're
> not likely to know the things that "reasonable programmers" take for
> granted. They're not going to know how slow querying a relational
> database can be. They're not likely to have an intuitive feel for the
> difference between an O(n^2) algorithm and O(n). They aren't even
> likely to know what "O" is, for that matter. They're not going to
> know the difference between the heap and the stack, or anything else
> related to memory. I could go on for a long time...
If this is the level of ability or lack of it that you are talking about, then
such programmers are simply not educated. Ignorance is not necessarily
stupidity, but one cannot program without knowing about stacks, heaps, basic
ideas of complexity, and so on.
Delphi does indeed require one to know these things, so if that is your point,
then I agree. I would point out, though, that to program properly in any
language, really does need to understand these things.
> The problem is that Delphi makes the common things *so* easy that you need
> to know very little about programming to make an application that seems
> impressive. [...] But what if you need to call into some part of the
> Windows API that Borland hasn't provided a wrapper for? [...] But calling
> into Windows required a lot of knowledge he didn't have: pointers, function
> call conventions, the number of bytes it takes to represent a Word.
One needs to know their machine. Calling conventions, etc., matter, especially
when dealing with the OS. That one is able to in Delphi, with full control, is
a good thing. It is actually Visual Basic that provides great support of easy
things, but obscure retarded hacks to do low level things.
It is not a coincidence the VB is implemented in C++, whereas Delphi is
implemented in Delphi.
> If you had an environment like Lisp where you wrote programs the same
> way the system was written (by typing Lisp, as opposed to a
> Delphi-esque dragging of Lisp components onto a form) the disparity
> isn't nearly as sharp; you don't have to rely on an IDE to write your
> program for you. It's certainly harder to start with, but I think a
> beginner would understand programming better by taking this approach.
Well, there is nothing stopping a beginner from taking a tutorial and doing
exactly that. But I suppose your point is that they are not intuitively aware
of that.
> The subject line was changed to "Dissing Delphi," but I wasn't trying
> to say "Delphi is an evil language". I was trying to say that Delphi
> encourages ignorant programmers to remain so by trying hard to put a
> drag-and-drop interface on everything one could possibly want to do.
Fair enough.
Ray Blaak
> BTW, VB has the same problem: lots of bells and whistles on top of a weak
> foundation.
VB is like that. I would characterize Delphi instead as bells and whistles on
top of a good foundation.
I have programmed in both. I despise VB. I can get real work done in Delphi.
Of course, Lisp is far more cool.
Russell Wallace
wrote:
>I think that an important component of team programming is lets call
>deontinc programming, for the lack of a better name.
("Deontinc"? I haven't heard that word before, though I get the
intended meaning.)
>Constructs that
>forbids and forces the other programmer to do stuff.
Would you hire a builder you believed to be incompetent, and then
require him to use a hand saw because you didn't trust him with a
power saw? I suspect not; I think most people would wait until they
found someone they trusted.
More generally, is there _any_ other field of human activity in which
it is considered acceptable, let alone normal, practice to hire people
one believes to be incompetent and try to compensate by giving them
deliberately crippled tools? Serious question - I'm not aware of any,
but maybe there is one that I don't know of.
If the answer to the above question is no, then why is programming the
exception? Again, this is a serious question; I'd like to know the
answer.
--
"Mercy to the guilty is treachery to the innocent."
http://www.esatclear.ie/~rwallace
mail:rw(at)eircom(dot)net
Craig Brozefsky
> they have clear and simple interfaces. This is how a large software
> system should be constructed, not by using traditional group
> programming. The difference is that the communication between
> programmers should be reduced to clear and simple interfaces, so two
> programmers can make each other understand how to make their
> subsystems work together, even if both programmers consider each other
> to be idiots.
If you are working with people you consider to be idiots than you are
already losing. This can be remedied by replacing that person, or as
is most often the case, recognizing that they are not an idiot and
attempting to help them with the difficulty they are having with the
task at hand.
> One key to group success is that the blame for any failure should be
> easy to identify. If the subsystem written by programmer X doesn't
> work, the clear and simple interfaces will make it easy for
> programmers Y and Z to prove it. X will be highly motivated to make
> that subsystem work, by being so clearly, easily, and fairly, blamed
> for it, and by so clearly getting the credit for it when it does
> work.
Blame is not a suitable motivator IMO, because it doesn't actually
solve the problem, it just makes it possible for the other people to
dissociate and isolate themselves from the failure. If you want to
solve the problem you need to get your team to cooperate and address
the problem as a whole, not isolate an individual behind a wall of
interfaces and then put the sword of Damocles over their head.
There will be design and implementation failures in your project once
it goes beyond a certain size, and if you have isolated your
developers behind these interfaces you will have a more difficult time
extracting them from their kingdoms in order to cooperate across the
boundaries to actually solve the problem.
This is why the XP process suggests you do away with code ownership,
and while I do not subscribe to all of XPs tenets I DO subscribe to
this one.
> Traditional group programming doesn't work because of the phenomenem
> known as "the tragedy of the commons."
But it has and does work, and I see nothing except for the unsupported
recitation of a bit-rotted sociological term "tragedy of the commons"
in your argument supporting a destructive and non-cooperative
behavior.
What you are creating is not a team, but a set of individuals who will
succeed or fail as individuals, and therefor can preserve their
position and prestige in their tiny fiefdoms within the project thru
succesful manipulation and control of the interface definition
process. If you want to talk about team programming, you have to at
least assume you have a team, a group of cooperating people who will
succeed or fail as a whole, and where inevitable individual failures
and shortcomings are compensated for by the cooperative effort of the
group.
> Programmers are motivated to give the appearance of doing a lot of
> good work. The nature of programming is such that the work itself
> gets sacrificed for the sake of that appearance. If the programmer
> does something to improve the overall quality of the overall system,
> sacrificing the appearance of doing good work, that programmer is
> one of the most likely to get laid off when the project has cost
> overruns and cutbacks.
But your proposal does nothing to eliminate the problem of local
optimizations which don't move the project towards completion but
instead solidify the position of the developer within the project.
> The non-traditional group programming I describe above, on the other
> hand, might be the perfect solution to such problems.
I think that it is more likely a recipe for disaster. I would guess
either that you have not participated in many *team* projects, or the
ones that you have were run by managers who did not know what they
were doing and your adoption of the above strategy is a justification
for the defensive actions you had to take to keep your position within
such mismanaged projects.
So at best your proposal is a individual strategy within a mismanaged
project, not a strategy which will lead to succesful *team*
programming.
--
Craig Brozefsky <cr...@red-bean.com>
Free Software Sociopath(tm) http://www.red-bean.com/~craig
Ask me about Common Lisp Enterprise Eggplants at Red Bean!
Will Hartung
"Gabe Garza" <g_g...@ix.netcom.com> wrote in message
news:u1q41o...@kynopolis.org...
> The subject line was changed to "Dissing Delphi," but I wasn't trying
> to say "Delphi is an evil language". I was trying to say that Delphi
> encourages ignorant programmers to remain so by trying hard to put a
> drag-and-drop interface on everything one could possibly want to do.
And that's its blessing and its curse. When I was talking about "coders",
these are exactly the kind of folks I'm talking about. In their limited
domains, tools like Delphi and VB are remarkably productive. They have
market share for a reason.
But, the biggest issue, IMHO, is that many of the users of these tools
"Learn Delphi", versus the concepts of computing. They're literally simply
scripters tieing components together.
This is not necessarily a bad thing. These tools are wonderful for their
domain, but users then get this myopic view of the world. If it's not on the
pallette, it can't be done.
I had a co-worker, a novice programmer, working with Delphi, who, after
working with it for 6 months, couldn't get "the difference between memory
and disk" straight in his head(!!!).
But when all you're doing is stringing SQL statements together, you don't
need a lot of deep understanding.
When you have a "central guru/designer/engineer", he can easily be
surrounded by a half dozen people who can spend their day lining up buttons
and bolting dialogs onto the core functionality. You don't need a
"programmer" to do that.
Will Hartung
(wi...@msoft.com)
Stefan Schmiedl
Russell Wallace <sp...@devnull.com> wrote:
>
> More generally, is there _any_ other field of human activity in which
> it is considered acceptable, let alone normal, practice to hire people
> one believes to be incompetent and try to compensate by giving them
> deliberately crippled tools? Serious question - I'm not aware of any,
> but maybe there is one that I don't know of.
Jails.
>
> If the answer to the above question is no, then why is programming the
> exception? Again, this is a serious question; I'd like to know the
> answer.
>
So we are not alone.
s.
Kent M Pitman
> On Sat, 20 Apr 2002 16:40:24 GMT, Kent M Pitman <pit...@world.std.com>
> wrote:
>
> > We had lots of people collaborating internal to Symbolics with a heavy
> > amount of new development and interdependent patching and things generally
> > worked quite fine.
>
> Approximately what fraction of Symbolics employees (more than a thousand at
> its peak?) dealt with development?
This is a good question. I don't know the answer. Maybe I can find out.
Duane Rettig
> On 18 Apr 2002 09:29:19 -0300, Jacques Wainer <wai...@ic.unicamp.br>
> wrote:
>
> >I think that an important component of team programming is lets call
> >deontinc programming, for the lack of a better name.
>
> ("Deontinc"? I haven't heard that word before, though I get the
> intended meaning.)
The OP means "deontic".
> >Constructs that
> >forbids and forces the other programmer to do stuff.
>
> Would you hire a builder you believed to be incompetent, and then
> require him to use a hand saw because you didn't trust him with a
> power saw? I suspect not; I think most people would wait until they
> found someone they trusted.
>
> More generally, is there _any_ other field of human activity in which
> it is considered acceptable, let alone normal, practice to hire people
> one believes to be incompetent and try to compensate by giving them
> deliberately crippled tools? Serious question - I'm not aware of any,
> but maybe there is one that I don't know of.
Any kind of assembly-line manufacturing would qualify. I remember a
term we used when I was in the hardware-engineering field:
"gorrilla-proofing", which was not to say that there were apes on the
manufaturing floor, but that we would try to build our equipment to
protect themselves and the manufacturing process from any worker that
the Company has hired, thus allowing the Company to hire non-skilled
workers for bottom dollar. These machines would do a lot, but they
would thwart any attempts to do anything other than was called for
in the specific manufacturing process involved.
In general, Henry Ford made the process of cheap labor and assembly-line
manufacture popular, because it tends to drive down prices. Of course,
the assembly-line process does not kill the demand for the manufacture
of hand-crafted items of the same kind. But the workers in such shops
tend more to be crafstmen, who know how to use their tools in amazing
ways, and less so just warm bodies that have learned how to push the
right buttons at the right time. The crafstman's tools also tend not
to disallow the crafstman from doing anything; the crafstman knows what
the tool can do, and knows that it might break if misused.
> If the answer to the above question is no, then why is programming the
> exception? Again, this is a serious question; I'd like to know the
> answer.
Since the answer was yes, programming is not necessarily an exception.
What the OP misunderstood was that programming covers a huge range of
activity which include innovation, crafstmanship, and the grunt-work
of manufacturing programs. Deontic programming tends to lend itself
best to assembly-line programming.
Lisp tends to fall into the category of "crafstman's tool". It tends to
be more forgiving (and thus breakable - it allows programmers to shoot
themselves in the foot). Deontic programming tends to be foreign to
Lisp programmers, although since Lisp is a language-writing language,
it is certainly possible to create a domain-specific language that
forces its programmers into a certain mold. Such sub-languages tend to
be discouraged by the Lisp community, however.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 du...@Franz.COM (internet)
Erann Gat
[A lot of good stuff]
> Lisp tends to fall into the category of "crafstman's tool". It tends to
> be more forgiving (and thus breakable - it allows programmers to shoot
> themselves in the foot).
IMO it's much harder to shoot yourself in the foot with Lisp than in, say,
C++ or even Java. Or do you consider these to be "craftsman's tools" as
well?
> Deontic programming tends to be foreign to
> Lisp programmers, although since Lisp is a language-writing language,
> it is certainly possible to create a domain-specific language that
> forces its programmers into a certain mold. Such sub-languages tend to
> be discouraged by the Lisp community, however.
If this is true (the Lisp community discouraging domain-specific
sub-languages), then IMO this is an example of the Lisp community shooting
itself in the foot.
E.
Duane Rettig
> In article <4hem3r...@beta.franz.com>,
> Duane Rettig <du...@franz.com> wrote:
>
> [A lot of good stuff]
>
> > Lisp tends to fall into the category of "crafstman's tool". It tends to
> > be more forgiving (and thus breakable - it allows programmers to shoot
> > themselves in the foot).
>
> IMO it's much harder to shoot yourself in the foot with Lisp than in, say,
> C++ or even Java. Or do you consider these to be "craftsman's tools" as
> well?
Of course. They're just not as good as Lisp at building tool-building
tools.
> > Deontic programming tends to be foreign to
> > Lisp programmers, although since Lisp is a language-writing language,
> > it is certainly possible to create a domain-specific language that
> > forces its programmers into a certain mold. Such sub-languages tend to
> > be discouraged by the Lisp community, however.
>
> If this is true (the Lisp community discouraging domain-specific
> sub-languages), then IMO this is an example of the Lisp community shooting
> itself in the foot.
The consequent is not true because the predicate is false. Your
predicate does not match my statement - if it had, you would be asking
whether the lisp community discourages domain-specific sub-languages
_which_ _force_ programmers into a particular mold. This is definitely
false. I'm sure there are many such sub-languages out there, but the
most successful Lisp-based domain-specific sub-languages are the ones
which tend to allow rather than disallow; many of them even allow exposure
to their underlying Lisp implementation.
Duane Rettig
> > > Deontic programming tends to be foreign to
> > > Lisp programmers, although since Lisp is a language-writing language,
> > > it is certainly possible to create a domain-specific language that
> > > forces its programmers into a certain mold. Such sub-languages tend to
> > > be discouraged by the Lisp community, however.
> >
> > If this is true (the Lisp community discouraging domain-specific
> > sub-languages), then IMO this is an example of the Lisp community shooting
> > itself in the foot.
>
> The consequent is not true because the predicate is false. Your
> predicate does not match my statement - if it had, you would be asking
> whether the lisp community discourages domain-specific sub-languages
> _which_ _force_ programmers into a particular mold. This is definitely
===============================================================^^^^^^^^^^
> false.
==^^^^^
Sorry, I got my logic wrong. I should have said that my ammended
predicate is not necessarily false, but that leaving out the phrase
regarding restrictions into a mold makes your original predicate
definitely false. In fact, Lisp encourages the writing of domain
specific sublanguages for particular tasks.
Erann Gat
> > > Deontic programming tends to be foreign to
> > > Lisp programmers, although since Lisp is a language-writing language,
> > > it is certainly possible to create a domain-specific language that
> > > forces its programmers into a certain mold. Such sub-languages tend to
> > > be discouraged by the Lisp community, however.
> >
> > If this is true (the Lisp community discouraging domain-specific
> > sub-languages), then IMO this is an example of the Lisp community shooting
> > itself in the foot.
>
> The consequent is not true because the predicate is false. Your
> predicate does not match my statement - if it had, you would be asking
> whether the lisp community discourages domain-specific sub-languages
> _which_ _force_ programmers into a particular mold. This is definitely
> false. I'm sure there are many such sub-languages out there, but the
> most successful Lisp-based domain-specific sub-languages are the ones
> which tend to allow rather than disallow; many of them even allow exposure
> to their underlying Lisp implementation.
Ah. Then I guess I don't understand what you mean by "forc[ing]
programmers into a certain mold." It seems to me I can't force anyone
into any kind of mold by any design decision I might make as the designer
of a DSL because programmers are always free not to use my DSL. On the
other hand, if I'm going to design a DSL then I have no choice but to
"force" its users into some sort of mold whose structure is dictated by
the structure of the domain for which the language is designed.
Maybe it would clarify things for me if you could give an example of a
forcing and a non-forcing DSL.
E.
Bruce Hoult
sp...@devnull.com (Russell Wallace) wrote:
> Would you hire a builder you believed to be incompetent, and then
> require him to use a hand saw because you didn't trust him with a
> power saw? I suspect not; I think most people would wait until they
> found someone they trusted.
>
> More generally, is there _any_ other field of human activity in which
> it is considered acceptable, let alone normal, practice to hire people
> one believes to be incompetent and try to compensate by giving them
> deliberately crippled tools? Serious question - I'm not aware of any,
> but maybe there is one that I don't know of.
I mention one below.
> If the answer to the above question is no, then why is programming the
> exception? Again, this is a serious question; I'd like to know the
> answer.
I believe it is because the demand for programmers in the USA exceeded
the natural supply a decade ago, and the bottom of the barrel has been
being scraped ever since.
I had absolutely no idea that this was the case until I visited the US
on a short term contract in 1998. To my great shock I found that the
average programmer in at least that firm was ... incredibly average.
And everyone was so specialised and compartmentalised. Of course there
were *some* very good people there, but not many. And most of the best
were foreigners -- either asian or Russian.
> More generally, is there _any_ other field of human activity in which
> it is considered acceptable, let alone normal, practice to hire people
> one believes to be incompetent and try to compensate by giving them
> deliberately crippled tools?
The military.
A classic example of this is the M16 rifle and the "spray and pray"
tactics introduced along with it in place of any attempt at marksmanship
on the part of the average soldier.
It seems to me that the techniques involved in *sucessfully* organising
a large and unskilled military is one of the great strengths of the US.
And from my time there, it seems to me that the same techniques (and
often ex military people) are being used in management of unskilled
programmers.
-- Bruce
Russell Wallace
wrote:
>The OP means "deontic".
Haven't heard that word before either :)
>Any kind of assembly-line manufacturing would qualify. I remember a
>term we used when I was in the hardware-engineering field:
>"gorrilla-proofing", which was not to say that there were apes on the
>manufaturing floor, but that we would try to build our equipment to
>protect themselves and the manufacturing process from any worker that
>the Company has hired, thus allowing the Company to hire non-skilled
>workers for bottom dollar. These machines would do a lot, but they
>would thwart any attempts to do anything other than was called for
>in the specific manufacturing process involved.
Ah, that makes sense. Yes, it's a good analogy. So the design
philosophy behind Java amounts to a bet that many unskilled workers in
a rigid process, will beat a few skilled workers in a more flexible
process, in programming as they did in car manufacturing.
(Of course, in the long run the tide turned in car manufacturing, as
the legions of unskilled workers were replaced by computer-controlled
machines :))
>Since the answer was yes, programming is not necessarily an exception.
>What the OP misunderstood was that programming covers a huge range of
>activity which include innovation, crafstmanship, and the grunt-work
>of manufacturing programs. Deontic programming tends to lend itself
>best to assembly-line programming.
Right.
Olivier Drolet
> > Deontic programming tends to be foreign to
> > Lisp programmers, although since Lisp is a language-writing language,
> > it is certainly possible to create a domain-specific language that
> > forces its programmers into a certain mold. Such sub-languages tend to
> > be discouraged by the Lisp community, however.
>
> If this is true (the Lisp community discouraging domain-specific
> sub-languages), then IMO this is an example of the Lisp community shooting
> itself in the foot.
>
> E.
Are all sub-languages by definition deontic? If so, can there be
degrees of donticity? If so, which ones does the Lisp community
discourage?
Erik Naggum
> I think that an important component of team programming is lets call
> deontinc programming, for the lack of a better name.
* Russell Wallace
| ("Deontinc"? I haven't heard that word before, though I get the intended
| meaning.)
I think people have a moral obligation to spell "deontic" correctly.
| Would you hire a builder you believed to be incompetent, and then require
| him to use a hand saw because you didn't trust him with a power saw? I
| suspect not; I think most people would wait until they found someone they
| trusted.
The problem is that some people think they cannot wait. Computers, even
with buggy software, are believed to be such cost-effective productivity
booster that managers and workers alike refuse to do things manually,
even though it would actually be more productive and less expensive.
E.g., a good secretary can type a letter on a good typewriter in far
shorter time than it takes an accomplished Word user to type the same
letter and print it out, but this does not appear to produce any insight,
even after the fourth failed attempt to get it right from the printer.
(One of the curious effects of this is that people can no longer type
accurately without electronic crutches like "spell checkers". When my
last gun purchase license was approved, the type-through copy I got back
featured 14 typos in less than 50 typewritten letters. Quite amazing.)
| More generally, is there _any_ other field of human activity in which it
| is considered acceptable, let alone normal, practice to hire people one
| believes to be incompetent and try to compensate by giving them
| deliberately crippled tools? Serious question - I'm not aware of any,
| but maybe there is one that I don't know of.
I have no idea how they hire various paper pushers in public offices, but
some of them appear to receive some sort of unemployment benefit combined
with locking them up in an office where they are believed to be somewhat
less harmful to society than if they had to be anywhere else.
| If the answer to the above question is no, then why is programming the
| exception? Again, this is a serious question; I'd like to know the
| answer.
Massive shortage of manpower, the inherent complexity of programming that
exceeds the skills of the hordes of incompetents that are still believed
to be more useful than not doing anything. I mean, Grace Hopper believed
that COBOL would be used to build small languages for application areas
and that people would not want to build everything from scratch, and was
somewhat surprised that people still went ahead and did just that. So
this is not new. Language design is obviously too hard for most people,
and it appears to be one of the (many) areas where competition is nothing
but _seriously_ harmful and standardization equally seriously beneficial.
Unfortunately, competition and standardization are seen as being at odds
by many people, in the belief that adhering to a stadndard is competitive
disadvantage. I personally find this utterly amazing, but then again, I
have devoted several thousand hours of my life to standardization efforts
-- and that has been to _my_ competitive advantage. Perhaps I digress.""
Erik Naggum
| I had absolutely no idea that this was the case until I visited the US on
| a short term contract in 1998. To my great shock I found that the
| average programmer in at least that firm was ... incredibly average. And
| everyone was so specialised and compartmentalised. Of course there were
| *some* very good people there, but not many. And most of the best were
| foreigners -- either asian or Russian.
Has you or anybody else read anything by Edward Yourdon? Back in 1993 or
so, I got a copy of his book «Decline & Fall of the American Programmer»,
but I found the little I read misguided and boring, so never completed
it. Much has happened in the decade since this book was published.
<surf Amazon> In 1996, he published «Rise & Resurrection of the American
Programmer» and seems to have reversed many of his predictions. In any
case, he appeared to be ardent adherent of the kind of assembly-line
programming that India in particular was famous for at that time. If any
of his writing is still relevant, it would be insteresting to hear what
people here think of his ideas.
Thien-Thi Nguyen
> it would be insteresting to hear what
> people here think of his ideas.
i don't know anything about this person's ideas, but imagine anyway i
would find more interesting to hear about his actions, especially if
they include publishing (self-written) source code.
thi
Scott McKay
"Kent M Pitman" <pit...@world.std.com> wrote in message
news:sfw1yd7...@shell01.TheWorld.com...
There were at least 50 "core product" software developers on the
east coast, maybe 20 graphics developers on the west coast. There
were a number of other developers working on our internal VLSI
design tools. Plus Macsyma, and a few other things, all of which had
to be kept in sync. All in all, maybe 100 software developers.
There was also a large contingent of documentation, QA, and support
people who were directly involved in the development process, but
who were not writing Lisp software.
Frode Vatvedt Fjeld
> Has you or anybody else read anything by Edward Yourdon?
The "Coad/Yourdon" method of OO design was very popular with the
industry people that were hired to theach what I guess is the project
management course here at UiTø/Norway, when I took it maybe 5 years
ago. So I suppose the man is quite influential.
--
Frode Vatvedt Fjeld
Greg Menke
> > Has you or anybody else read anything by Edward Yourdon?
>
> The "Coad/Yourdon" method of OO design was very popular with the
> industry people that were hired to theach what I guess is the project
> management course here at UiTø/Norway, when I took it maybe 5 years
> ago. So I suppose the man is quite influential.
In my experience His Teachings were applied with similar religious
fervor as UML is now.
I think the half-lives of these fads is about 2 to 3 years- but then
TQM came and went much more quickly. The software maturity model
thing must be getting near done at this point (since everybody who
cares has achieved their Level 3). Does anyone know how long 6-Sigma
has been around?
Gregm
Erik Naggum
| Does anyone know how long 6-Sigma has been around?
I had to look that up. Yourdon actually uses a capital sigma in the
"standard deviation" meaning that is associated only with small sigma,
capital sigma meaning sum of series. How amazingly ignorant and silly.
Paul Wallich
Wallace) wrote:
>On Mon, 22 Apr 2002 18:00:00 GMT, Duane Rettig <du...@franz.com>
>wrote:
>
>>The OP means "deontic".
>
>Haven't heard that word before either :)
>
>>Any kind of assembly-line manufacturing would qualify. I remember a
>>term we used when I was in the hardware-engineering field:
>>"gorrilla-proofing", which was not to say that there were apes on the
>>manufaturing floor, but that we would try to build our equipment to
>>protect themselves and the manufacturing process from any worker that
>>the Company has hired, thus allowing the Company to hire non-skilled
>>workers for bottom dollar. These machines would do a lot, but they
>>would thwart any attempts to do anything other than was called for
>>in the specific manufacturing process involved.
>
>Ah, that makes sense. Yes, it's a good analogy. So the design
>philosophy behind Java amounts to a bet that many unskilled workers in
>a rigid process, will beat a few skilled workers in a more flexible
>process, in programming as they did in car manufacturing.
Even in skilled-craft fields there is a significant place for tools that
limit what the worker can do, because even the most skilled workers
aren't always at the top of their form. For example, stage electricians
learn to put safety lines on all their tools even though that makes them
less convenient, and they often use short-handled wrenches that make
it effectively impossible to overtorque bolts or nuts. Similarly, system
administrators generally avoid being logged in as root (or its equivalent)
except when actually necessary.
One of the things I have for a long time appreciated about Lisp is the
way that it and its developers put the software equivalent of safety
ropes on almost everything, so that there are few situations you can't
successfully recover from. (It's perhaps a different level of gorilla proofing,
since you don't actually prevent people from jumping off the cliff, you
just reduce the number of cliffs and make sure there's a net pretty much
everywhere.)
paul
Software Scavenger
> Has you or anybody else read anything by Edward Yourdon? Back in 1993 or
> so, I got a copy of his book «Decline & Fall of the American Programmer»,
> but I found the little I read misguided and boring, so never completed
> it. Much has happened in the decade since this book was published.
> <surf Amazon> In 1996, he published «Rise & Resurrection of the American
> Programmer» and seems to have reversed many of his predictions. In any
> case, he appeared to be ardent adherent of the kind of assembly-line
> programming that India in particular was famous for at that time. If any
Which of those two books and/or times do you mean by "at that time"?
Does he actually discuss programming in India in one or both of those
books? I'm starting to get interested in this subject because I've
been working with a lot of programmers from India, and learning what
they're really like as individuals.
Duane Rettig
> In article <4d6wrq...@beta.franz.com>, Duane Rettig <du...@franz.com> wrote:
>
> > > > Deontic programming tends to be foreign to
> > > > Lisp programmers, although since Lisp is a language-writing language,
> > > > it is certainly possible to create a domain-specific language that
> > > > forces its programmers into a certain mold. Such sub-languages tend to
> > > > be discouraged by the Lisp community, however.
> > >
> > > If this is true (the Lisp community discouraging domain-specific
> > > sub-languages), then IMO this is an example of the Lisp community shooting
> > > itself in the foot.
> >
> > The consequent is not true because the predicate is false. Your
> > predicate does not match my statement - if it had, you would be asking
> > whether the lisp community discourages domain-specific sub-languages
> > _which_ _force_ programmers into a particular mold. This is definitely
> > false. I'm sure there are many such sub-languages out there, but the
> > most successful Lisp-based domain-specific sub-languages are the ones
> > which tend to allow rather than disallow; many of them even allow exposure
> > to their underlying Lisp implementation.
>
> Ah. Then I guess I don't understand what you mean by "forc[ing]
> programmers into a certain mold." It seems to me I can't force anyone
> into any kind of mold by any design decision I might make as the designer
> of a DSL because programmers are always free not to use my DSL.
That depends on how the programmer is presented the DSL. If it is a
requirement for his job, yes, he is "forced". But also, of course,
a programmer is free to walk away from a job which requires a specific
language, and thus my use of the word "force" is probably a little bit
of overkill. I should have instead used "restricted".
> On the
> other hand, if I'm going to design a DSL then I have no choice but to
> "force" its users into some sort of mold whose structure is dictated by
> the structure of the domain for which the language is designed.
But what if the field is changing, and you know it? You would definitely
not want your tool to become obsolete as soon as it is deployed. You
would want to build in at least some flexibility to allow for growth.
> Maybe it would clarify things for me if you could give an example of a
> forcing and a non-forcing DSL.
Maybe this is a little to specific a domain, and not Lisp, but ...
===
In my previous field as a test engineer, various vendors produced
products specific to the problem of testing digital logic, primarily
on Printed Circuit boards. These generally came with a logic simulator,
fault analysis software (to tell you what percentage of the possible
faults on the board your test pattern has caught) and the model
library. Watching these products grow over the years, I noticed that
what started out as very restricted and simple, with models for just
the 74xxx SSI chips, had to be modified as new chips were designed.
It was not just a matter of adding new models to the library; for
example, one of the problems that had to be solved was the "tri-state"
problem; not only could the TTL logic drive the signal to zero, or
drive it to one, but it could also be "off" and not drive it in either
direction. In chip technology, this gave a better way to drive bus
architectures, rather than a "wired-or" concept (where any of the
drivers on the bus could force the signal to zero, and all were always
active). But in the fault-simulation technology, this was a real
problem.
Another growth aspect came about with the advent of MSI and LSI
technology; where the logic within a chip became too complex to
model with primitive logic; it would take hours to run the simulation
for such chips. These problems tended to be solved by allowing the
logic to be described programmatically (a precursor to a scripting
language, before scripting languages became popular). So the behavior
of the chip would be described in higher level terms (with more
possibility for error, undfortunately).
===
Nowadays, scripting languages are commonplace. I believe that this is
true precisely because when users of a restricted domain-specific
product discover a scripting language for that product, they realize
how much power it opens up to them. For that reason, I can't think
of too many other cases where deontic programming is successful.
But let's now switch gears a little; if I write a complete programming
language in CL, then that qualifies as a DSL (the domain is in fact
the language source for the target language). Now, let's consider
strong vs weak typing - I consider strong typing to be a good example
of deontic programming. Thus, if I write a Pascal compiler in CL,
then that becomes a restrictive DSL wrt types. But if I write a C
compiler in CL, then that becomes a non-restrictive DSL.
Another example of a restrictive langauge is Prolog, which has often
been written in CL. The deontic style in this case involves the
purity of the functional approach. However, prologs written in CL
tend to interact with CL, and thus the restrictions are not pure,
thus providing potentially the full power of CL.
Another example of a non-restrictive DSL is Macsyma. You can enter
math expressions in its own language, or you can do so at a Lisp
prompt. There is no restriction as to the use of the underlying Lisp.
As always, I believe that CL's greatest claim is the very thing which
keeps it obscure because it is so hard to describe; it is as many
things as possible to as many programmers as possible. It is like the
elephant, which 5 blind men approached to "see" - one felt his trunk
and described him as a firehose; one ran into his side and described
him as a wall; one touched his legs and thought the elephant very like
a tree; one touched his ears and thought of him as a cloth or sheet,
and one touched his tail and thought he was like a snake. In fact, he
was all of these, and none of these. CL is like that, and strives to be
inclusive, which is why I say that it discourages restrictive
sublanguages. They are of course possible, and as part of its own
style CL wouldn't place restrictions on making a restrictive
sublanguage.
Erik Naggum
| Even in skilled-craft fields there is a significant place for tools that
| limit what the worker can do, because even the most skilled workers
| aren't always at the top of their form.
How does _safety_ imply _crippling_?
| For example, stage electricians learn to put safety lines on all their
| tools even though that makes them less convenient, and they often use
| short-handled wrenches that make it effectively impossible to overtorque
| bolts or nuts.
This seems like _enabling_ tools to me. If even a professional had to
worry about these things all the time, they would probably err on the
side of caution and be less efficient than they could be.
| (It's perhaps a different level of gorilla proofing, since you don't
| actually prevent people from jumping off the cliff, you just reduce the
| number of cliffs and make sure there's a net pretty much everywhere.)
I may be showing some Europeanisms here, incompatible with the American
automotive culture, but across Europe, we generally have barriers of some
kind along the side of a road without which it would be too easy to drive
right into the generally unsupporting air and plummet unsafely into
unpaved territory, and we also have silly laws about seat belts. Despite
these limiting artefacts of our automotive culture, there is no shortage
suicides by car, so the limitations in automotive freedom are hardly
crippling. Quite the contrary, literally.
Erik Naggum
| Which of those two books and/or times do you mean by "at that time"?
| Does he actually discuss programming in India in one or both of those
| books? I'm starting to get interested in this subject because I've been
| working with a lot of programmers from India, and learning what they're
| really like as individuals.
I dislike the implications you seem to attempt to bring up intensely.
Are you even _aware_ of what you are implying?
You can read the books. I do not pretend to speak for anyone, especially
not when the person who asks seems to want to make implications from no
more than referring to what somebody else has opined.
Kenny Tilton
Erik Naggum wrote:
>
> * Kenny Tilton
> | The downside is that average folk get crippled resumes because no one
> | else wants their skills.
>
> * Erik Naggum
> > If they can learn one domain-specific language in a reasonable amount of
> > time and become proficient in it, why would they be unable to repeat such
> > an endeavor?
>
> * Kenny Tilton <kti...@nyc.rr.com>
> | I said the resumes were crippled, not them.
> |
> | woof!
>
> You are barking up the wrong tree. Please realize that I was arguing
> against the notion that the resumes would be "crippled" -- if they had
> acquired a skill in a short amount of time, that should be valuable, etc.
This is almost as much fun as chasing my tail. See Tim's remarks on
"consider the reader", they had me leaping with joy.
There is no disagreement. "resume-crippler" is how average programmers
would view a job using an in-house language. And the problem I was
trying to convey is that rank-and-file types would slip their collars.
Maybe the answer is to elim the rank-and-file by making the in-house
language so powerful the accounting people (the "power-user" type,
anyway) can write their own reports, captive no longer to the systems
group. The friction between users and systems goes away. The systems
folks are just a few bright people having a ball building a programming
language and DB schema and other top-salary stuff. The job description
changes from "process information in ways the user specifies and likes"
to "create something with which the user can process information as they
see fit".
Techies of course help users with the scripting language, so there is
true cooperation where each brings their own expertise to the problem:
techie for tricky programming problems, user with domain expertise. And
since everyone in the corp is using the same language, the users can
help each other. Some users probably enjoy programming so much they
crossover to fulltime support of other users.
Anybody got a frisbee?
--
kenny tilton
clinisys, inc
---------------------------------------------------------------
"Harvey has overcome not only time and space but any objections."
Elwood P. Dowd
Marc Spitzer
Was not this tried already, they were called 4gls?
marc
Kenny Tilton
Marc Spitzer wrote:
>
> In article <3CC5E9CE...@nyc.rr.com>, Kenny Tilton wrote:
> >
> >
> > Erik Naggum wrote:
> >>
> >> * Kenny Tilton
> > Maybe the answer is to elim the rank-and-file by making the in-house
> > language so powerful the accounting people (the "power-user" type,
> > anyway) can write their own reports
....
>
> Was not this tried already, they were called 4gls?
Yes and no. And the no is why they failed. 4GLs as a commercial product
need many customers. But their selling point is productivity, and the
productivity offered is illusory. They simply write some of the code for
me. But there is no way to write code which pleases everyone. If that
code happens not to work the way I need, I am now /fighting/ my
so-called productivity tool. Getting the vendor to change the 4GL would
take too long even if they agreed tot he change.
In the end, 3GL is faster for real programmers. As for non-programmers
using a 4GL, fuggedaboutit. The 4GL has to expose enough options to come
close to being general-purpose, but doing so makes them almost as hard
to use as a 3GL, and in some ways harder.
My pipe dream fixes all that. Since Mega (the language) is designed for
MegaCorp and developed by MegaCorp, the only inflexibility is the kind
you want: users have to do things the MegaCorp Way. You get conformance
for free.
But if a Mega user really needs some new feature -- in it goes. A quick
fix might take an hour to get ready for testing.
As for Mega not necessarily being a snap to program, well, in-house tech
support and support from the MUG will be a lot cheaper than support from
a vendor.
Software Scavenger
> I dislike the implications you seem to attempt to bring up intensely.
> Are you even _aware_ of what you are implying?
I wasn't aware of any particular implication. I was just curious
about your reference to assembly line programming in India, and
whether it came from one or the other of the two books you mentioned.
I haven't read either of them, have no particular interest in either,
but might become interested if there actually is a significant
discussion in either of them of anything having to do with the history
of software development in India.
What specific implication are you referring to and asking about my
awareness of?
Erann Gat
* Duane:
> it is certainly possible to create a domain-specific language that
> forces its programmers into a certain mold.
* Erann:
> Ah. Then I guess I don't understand what you mean by "forc[ing]
> programmers into a certain mold." It seems to me I can't force anyone
> into any kind of mold by any design decision I might make as the designer
> of a DSL because programmers are always free not to use my DSL.
* Duane:
> That depends on how the programmer is presented the DSL. If it is a
> requirement for his job, yes, he is "forced".
But then it's the employer doing the forcing, not the language.
> I should have instead used "restricted".
My confusion is not about the degree of coercion involved (I think) but
rather how the design of a DSL can be coercive or not. You clarified that
in the rest of your post. Thanks.
> As always, I believe that CL's greatest claim is the very thing which
> keeps it obscure because it is so hard to describe; it is as many
> things as possible to as many programmers as possible.
I agree.
E.
Erik Naggum
| What specific implication are you referring to and asking about my
| awareness of?
This:
| I'm starting to get interested in this subject because I've been working
| with a lot of programmers from India, and learning what they're really
| like as individuals.
You clearly imply that _someone_ is not treating people as individuals.
It is, in fact, possible to say something intelligent and accurate about
cultures and communities without dumbing down your thinking to that of
not treating people as individuals when you deal with individuals just
because they belong to some group. Some cultures are bad and have good
invididuals in spite of them, just as some cultures are good and still
have bad invididuals in spite of them. But I digress a little.
One of Yourdon's arguments was that the "India way" with CASE and other
automated software generation tools would crush American programmers
because of their much lower productivity with stone-age tools. From what
little I have read of Yourdon's arguments, programming had become an
assembly- line activity in India about a decade ago, and I have heard
this from other sources, too, but not recently. I have absolutely no
first-hand knowledge of this. I have even not received junk mail from
what appeared to be software sweatshops for long time.
Dave Bakhash
> I agree with what you are implying and think that you are far too kind
> in your summation. I have watched people lament the capabilities of
> Lisp for the past 5 years, jumping to Perl or Java or Python or Jython
> or Visual Basic or C# or C++ for no other reason than to play with
> something else. A different language will not solve the intrinsic
> problems: lack of experience and a failure to engineer a solution. A
> good craftsman doesn't blame his tools.
This is interesting to me, because there was a time when I was given
problems where I felt I could either:
1) reinvent the wheel in CL, or
2) use convenient libraries in Perl (or other language, though Perl was
the one I usually picked).
During that time, I used to post to this newsgroup, esp. to defend Perl,
and suggest that people try it significantly before bashing it. I still
like Perl, though I came to realize something...
I realized after a lot of time (and success, even) that it's much more
worthwhile to build up Common Lisp than to run to another language
because it provides you with some short-term advantages. What worked
for me was to give up the myopic view that CL would require lots of work
to reproduce efforts that were already done in other languages. Going
back to CL turned out to be an excellent decision for me, and now having
everything from telephony interfaces for Lisp to voice and data modems,
using in transaction processing, IVRs, etc. is my most valuable asset.
My main point is not that Common Lisp will directly address your exact
problem better than another language. But Common Lisp will be the
language which, in the end, will let you address all of your problems
with the least overall effort, and will guarantee never needing to jump
to another general programming language because of a paradigm or style.
With a fair amount of effort, you can make your CL interfaces better
than those provided in other languages. This is because:
1) we can incorporate macro-level constructs for certain features
and paradigms, where appropriate.
2) using CLOS, we can create nicer interfaces (this is mostly
opinion, but I havn't seen an OOP system better than CLOS).
3) CL has the richest set of types I've ever seen
To compare with Java, I'd say that while Java is a language designed
primarily to build applications, CL is a language design to be extended,
to build new tools, and to be used, along with these new tools, to build
applciations. So if you're doing anything significantly large, CL can
be a big win.
dave