>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.
> > 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?
> 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.""
/// -- 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.
* Bruce Hoult | 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.
/// -- 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.
Erik Naggum <e...@naggum.net> writes: > 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.
> > 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.
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.
Erik Naggum <e...@naggum.net> writes: > 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.
> > 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?
* Greg Menke | 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.
/// -- 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.
>>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.)
Erik Naggum <e...@naggum.net> wrote in message <news:3228516470377013@naggum.net>... > 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.
> > > > 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.
-- 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)
* Paul Wallich | 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.
/// -- 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.
* Software Scavenger | 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.
/// -- 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.
> * 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.
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
In article <3CC5E9CE.9067D...@nyc.rr.com>, Kenny Tilton wrote:
> 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 <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.
> 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".
Was not this tried already, they were called 4gls?
> 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
> In article <3CC5E9CE.9067D...@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.
--
kenny tilton clinisys, inc --------------------------------------------------------------- "Harvey has overcome not only time and space but any objections." Elwood P. Dowd
Erik Naggum <e...@naggum.net> wrote in message <news:3228581014355790@naggum.net>... > 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?
In article <4lmbetihg....@beta.franz.com>, Duane Rettig <du...@franz.com> wrote:
* 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.
* Software Scavenger | 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.
/// -- 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.
Steve Long <sal6...@hotmail.com> writes: > 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.
