* Erik Naggum wrote: > 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'.
"Paul Tarvydas" <tarvy...@attcanada.ca> writes: > 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?
cubicle...@mailandnews.com (Software Scavenger) writes: > 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).
> * 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.
> > 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?
"Will Hartung" <wi...@msoft.com> writes: > "Erik Naggum" <e...@naggum.net> wrote in message > news:3228325348518404@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.
> * 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!
--
kenny tilton clinisys, inc --------------------------------------------------------------- "Harvey has overcome not only time and space but any objections." Elwood P. Dowd
Gabe Garza <g_ga...@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.
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.
* 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 <ktil...@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.
/// -- 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.
Ray Blaak <bl...@telus.net> writes: > Gabe Garza <g_ga...@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.
On Mon, 22 Apr 2002 01:59:53 GMT, Gabe Garza <g_ga...@ix.netcom.com> wrote: >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. ;-)
> 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.
Gabe Garza <g_ga...@ix.netcom.com> writes: > 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.
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.
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.)
>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.
cubicle...@mailandnews.com (Software Scavenger) writes: > 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!
> 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.
> 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.
Paolo Amoroso <amor...@mclink.it> writes: > 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.
s...@devnull.com (Russell Wallace) writes: > 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)
In article <4hem3r6s0....@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?
> 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.
> > 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 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)
Duane Rettig <du...@franz.com> writes: > > > 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
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.
-- 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)
In article <4d6wrqzwa....@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. 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.
In article <3cc43709.353003...@news.eircom.net>, s...@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.
