Well, I finally reached enlightenment. I understand why people don't use lisp. It took me a long time. It isn't a lack of libraries, or the number of parentheses. The thing that kills a language is powerful syntax and abstractions.
I work in C# (worst language EVER!) and I had to write some loops to accumulate some values in some collections. I spent a good deal of time looking for some standard accumulate function. Nothing. So I decided to roll my own using generics and anonymous functions. My manager looked at the code and asked "Who's going to maintain this? How will they understand it?" That's not the first time I've encountered these questions. I heard it when I used function pointers in C. I heard it when I used templates in C++. I heard it when I used Lisp for ANYTHING. :)
I can certainly understand concerns about over engineering a solution. I've been the victim of many over complicated class structures. I think there's a difference between complicating a design and using the language syntax. When I simplified the implementation from six independent functions to one that gets an anonymous function, I thought I was making it easier. I didn't worry that future developers would have to know ALL the syntax of the language instead of just the set that intersects with C++.
I'm finding that regardless of the language used, many "professional" developers have a serious issue with the more powerful abstractions available to them. A language like Lisp that supports the abstractions so naturally (as opposed to the syntactic mutilation that happens in C#) is doomed.
Sorry about the rant. I am incredibly frustrated. How is C#'s poor readability my fault? I didn't design or select the doggone language.
I hope our product's translators understand the languages they translate. Maybe they figure knowing a few major words is enough, and they can wing the rest! :)
Ben wrote: > Sorry about the rant. I am incredibly frustrated. How is C#'s poor > readability my fault?
Or is it, How is the poor readability of your code C#'s fault? I have seen impossibly dense COBOL code, code even its authors could not follow.
The big mistake is thinking Lisp is going to grow by first being adopted in Tall Buildings. They are the drones, the lemmings, the sheep. They follow where We the Blessed Gurus lead them. But this time it is to the slaughterhouse, because the world needs only fifty Lisp programmers to write All the Code.
In article <1179852769.863109.80...@p77g2000hsh.googlegroups.com>,
Ben <benbe...@gmail.com> wrote: > Well, I finally reached enlightenment. I understand why people > don't use lisp. It took me a long time. It isn't a lack of > libraries, or the number of parentheses. The thing that kills a > language is powerful syntax and abstractions.
There is a certain amount of truth to it.
There is a huge difference working with a language where you have to wait a year to get a new loop statement from the language designer and compiler implementer - or - where you do it yourself in twenty minutes.
There is also a huge difference working with a tool that stands between you and the code - or - working with a language where you can manipulate the code easily yourself.
This flexibility comes with costs. A Lisp developer needs to be trained to use the extension features and not go over board. There are principles one should follow:
* late binding / late decisions * reflective code * modular code * composable code * first class objects * runtime error checking
and so on.
The flexibility can be learned. Working with code from others that uses these features can also be learned. A good development environment and understanding of it is necessary.
The development style is very different from traditional batch programming. This has to be learned.
So, we need an average or above programmer. Plus you need people who can teach this. Bad teaching can create huge damage. Lisp suffered a long time from being a language for computer science courses. There Lisp gets taught with all kinds of strange concepts, but not with the purpose of learning programming with Lisp (well, sometimes). You'd learn to represent integer and some arithmetic with functions. Weird. ;-) I 'real' life, most Lisp developers don't represent numbers with functions. The 'shock' comes later when you get in contact with a larger piece of 'research software'. There are at least two different: one is written by competent research developers and the other is written over years by students hacking stuff without understanding it. When I saw such a system developed by some competent programmers, I didn't understand a thing. Much too complicated. A few years later I would be able to use it.
Working in a team helps. You'll get feedback if others have to use your code.
> I work in C# (worst language EVER!) and I had to write some loops to > accumulate some values in some collections. I spent a good deal of > time looking for some standard accumulate function. Nothing. So I > decided to roll my own using generics and anonymous functions. My > manager looked at the code and asked "Who's going to maintain this? > How will they understand it?" > That's not the first time I've encountered these questions. I heard > it when I used function pointers in C. I heard it when I used > templates in C++. I heard it when I used Lisp for ANYTHING. :)
> I can certainly understand concerns about over engineering a > solution. I've been the victim of many over complicated class > structures. I think there's a difference between complicating a > design and using the language syntax. When I simplified the > implementation from six independent functions to one that gets an > anonymous function, I thought I was making it easier. I didn't worry > that future developers would have to know ALL the syntax of the > language instead of just the set that intersects with C++.
> I'm finding that regardless of the language used, many > "professional" developers have a serious issue with the more powerful > abstractions available to them. A language like Lisp that supports > the abstractions so naturally (as opposed to the syntactic mutilation > that happens in C#) is doomed.
> Sorry about the rant. I am incredibly frustrated. How is C#'s poor > readability my fault? I didn't design or select the doggone language.
> I hope our product's translators understand the languages they > translate. Maybe they figure knowing a few major words is enough, and > they can wing the rest! :)
On Tue, 22 May 2007 19:32:36 +0200, Rainer Joswig wrote: > Working in a team helps. You'll get feedback if others > have to use your code.
Do many lisp users work in teams? I've gained the impression from discussions here that the lone-coder image is more the rule [and it certainly seems to be the case that that one can go a lot further in that mode with lisp than anything else.] From the little scheme coding that I've done so far, I think that I'd have to put a good deal more effort into documentation (at least) before I'd be happy to have my current project hacked-on by other programmers, although ultimately that will be necessary. Maybe I should make more use of OO and packages/modules, and lay off the functional abstraction a bit...
I struggle to learn C#. It's like someone put a pile of @#$% together and called it a language. Every time I think I'm starting to get the hang of it, they add another turd to the pile, and it doesn't look smell or taste like any of the other turds.
There's no rhyme or reason - it's not architecture, it's one turd on top of another.
Ugly language. <shudder>
Lisp, on the other hand, is very easy to read. The parenthesis have almost disappeared for me, and it's relatively easy to deduce what a piece of code is supposed to do. Damn you Paul Graham for turning me on to it! It's like seeing a pretty girl for the first time - now the bitch I've been sleeping with is revealed as a hag...
I struggle to learn C#. It's like someone put a pile of @#$% together and called it a language. Every time I think I'm starting to get the hang of it, they add another turd to the pile, and it doesn't look smell or taste like any of the other turds.
There's no rhyme or reason - it's not architecture, it's one turd on top of another.
Ugly language. <shudder>
Lisp, on the other hand, is very easy to read. The parenthesis have almost disappeared for me, and it's relatively easy to deduce what a piece of code is supposed to do. Damn you Paul Graham for turning me on to it! It's like seeing a pretty girl for the first time - now the bitch I've been sleeping with is revealed as a hag...
I struggle to learn C#. It's like someone put a pile of @#$% together and called it a language. Every time I think I'm starting to get the hang of it, they add another turd to the pile, and it doesn't look smell or taste like any of the other turds.
There's no rhyme or reason - it's not architecture, it's one turd on top of another.
Ugly language. <shudder>
Lisp, on the other hand, is very easy to read. The parenthesis have almost disappeared for me, and it's relatively easy to deduce what a piece of code is supposed to do. Damn you Paul Graham for turning me on to it! It's like seeing a pretty girl for the first time - now the bitch I've been sleeping with is revealed as a hag...
I struggle to learn C#. It's like someone put a pile of @#$% together and called it a language. Every time I think I'm starting to get the hang of it, they add another turd to the pile, and it doesn't look smell or taste like any of the other turds.
There's no rhyme or reason - it's not architecture, it's one turd on top of another.
Ugly language. <shudder>
Lisp, on the other hand, is very easy to read. The parenthesis have almost disappeared for me, and it's relatively easy to deduce what a piece of code is supposed to do. Damn you Paul Graham for turning me on to it! It's like seeing a pretty girl for the first time - now the bitch I've been sleeping with is revealed as a hag...
> I struggle to learn C#. It's like someone put a pile of @#$% together > and called it a language. Every time I think I'm starting to get the > hang of it, they add another turd to the pile, and it doesn't look > smell or taste like any of the other turds.
> There's no rhyme or reason - it's not architecture, it's one turd on > top of another.
> Ugly language. <shudder>
> Lisp, on the other hand, is very easy to read. The parenthesis have > almost disappeared for me, and it's relatively easy to deduce what a > piece of code is supposed to do. Damn you Paul Graham for turning me > on to it! It's like seeing a pretty girl for the first time - now the > bitch I've been sleeping with is revealed as a hag...
> :(
Googles groups ... <an error has occured...> sorry for the dupe posts
One thing I find most new lisp programmers find it difficult is its free-form. Control Abstractions are structured by position; The position in the list determines the kind of structure. This is very hard to digest for most programmers whose eyes search for keywords.
Ben <benbe...@gmail.com> writes: > Well, I finally reached enlightenment. I understand why people > don't use lisp. It took me a long time. It isn't a lack of > libraries, or the number of parentheses. The thing that kills a > language is powerful syntax and abstractions.
> I work in C# (worst language EVER!) and I had to write some loops to > accumulate some values in some collections. I spent a good deal of > time looking for some standard accumulate function. Nothing. So I > decided to roll my own using generics and anonymous functions. My > manager looked at the code and asked "Who's going to maintain this? > How will they understand it?" > That's not the first time I've encountered these questions. I heard > it when I used function pointers in C. I heard it when I used > templates in C++. I heard it when I used Lisp for ANYTHING. :)
> I can certainly understand concerns about over engineering a > solution. I've been the victim of many over complicated class > structures. I think there's a difference between complicating a > design and using the language syntax. When I simplified the > implementation from six independent functions to one that gets an > anonymous function, I thought I was making it easier. I didn't worry > that future developers would have to know ALL the syntax of the > language instead of just the set that intersects with C++.
> I'm finding that regardless of the language used, many > "professional" developers have a serious issue with the more powerful > abstractions available to them. A language like Lisp that supports > the abstractions so naturally (as opposed to the syntactic mutilation > that happens in C#) is doomed.
> Sorry about the rant. I am incredibly frustrated. How is C#'s poor > readability my fault? I didn't design or select the doggone language.
> I hope our product's translators understand the languages they > translate. Maybe they figure knowing a few major words is enough, and > they can wing the rest! :)
I wish I could say your wrong, but unfortunately, there is a good bit of truth in what you say - at least from my experience. Only yesterday I was given some code because it was supposed to do almost exactly what I've been asked to create. The code consisted of many many lines similar to
if (col[0] != '') { do-this
} else { do-that }
if (col[1] != '') { do-this
} else { do-that }
if (col[2] != '') { do-this
} else { do-that }
if .....
and on over an array of 30 elements. When you see this sort of code, you understand why so many programmers don't understand the great power of lisp or macros. I mean, this programmer didn't even understand a bloody loop, so what chance is there of them understanding things like macros, CLOS or even get past lisp parens?
The sad thing here is that when I arrived at this company, I was told that the author of that bit of code was one of their /best/ programmers and I would do well to use him as a mentor. This confused me until I realised that
1. Most managers wouldn't recognise well written software even if it bit them in the ass 2. Some programmers are able to establish a higher degree of influence over the system, not because they are good programmers, but rather because they are good communicators who understand either the bigger picture or at least the picture as seen by management. 3. Management, because it doesn't understand the long-term cost benefits of well written code produced by experienced (and therefore more expensive) programmers, concentrates on driving down the staff costs by employing recent graduates and people with little experience to work in an environment where the tools are dictated more by how easily you can get cheap staff rather than by what will produce the best product in the long-term. 4. Management assumes that any software will have high maintenance costs. The incorrect solution adopted is to either do anything to avoid creating your own systems (i.e. the 'vendor solution') and/or make sure your programmers are as cheap as possible. There has been no connection made between the high maintenance costs and inexperienced programmers using poor tools.
All of this is made worse by the short-term management style which seems to be prevalent these days. As a manager, your objective is to reduce the costs over the immediate short-term to make you appear successful and able to climb the greasy pole to the next higher position. Its irrelevant that your cost cutting measures have resulted in major cost blowouts in 5+ years, when you have moved on and are no longer accountable (your probably now the person that you would/should have been accountable to anyway).
The extent to which this happens appears to be linked to the size of the organisation you are in. I've found working for smaller organisations is often far more rewarding as the people involved appear to be more aware, will stick around for longer and therefore have a greater interest in long-term success and often you are able to more readily exercise your skills and experience to solve the problem, rather than be constrained by beurocratic ignorance!
On May 23, 1:16 am, Ken Tilton <kennytil...@optonline.net> wrote:
> Ben wrote: > > Sorry about the rant. I am incredibly frustrated. How is C#'s poor > > readability my fault?
> Or is it, How is the poor readability of your code C#'s fault? I have > seen impossibly dense COBOL code, code even its authors could not follow.
> The big mistake is thinking Lisp is going to grow by first being adopted > in Tall Buildings. They are the drones, the lemmings, the sheep. They > follow where We the Blessed Gurus lead them. But this time it is to the > slaughterhouse, because the world needs only fifty Lisp programmers to > write All the Code.
LOL, maybe that's the reason - nearly everyone in the world isn't one of the Chosen Fifty.
Ken Tilton <kennytil...@optonline.net> writes: > Ben wrote: >> Sorry about the rant. I am incredibly frustrated. How is C#'s poor >> readability my fault?
> Or is it, How is the poor readability of your code C#'s fault? I have > seen impossibly dense COBOL code, code even its authors could not > follow.
Happened a few times when I was hacking C. I then put in some comment like:
/* READ THIS CAREFULLY BEFORE CHANGING THE FOLLOWING CODE!
THIS CODE SEGMENT HAS BEEN OPTIMIZED. IT IS VERY UNLIKELY THAT YOU WANT TO CHANGE IT. IF SO DO IT AT YOUR OWN RISK. THIS CODE IS OPTIMIZED BEYOND READABILITY. IT MAY HAPPEN YOU DO NOT FULLY UNDERSTAND WHAT IT DOES. IF YOU REACH THAT CONCLUSION YOU ARE ADVICED TO BACK OFF FROM CHANGING THIS CODE SEGEMENT.
RESPECTFULLY THE AUTHOR OF THIS CODE */
I never saw someone change those code sections... And it made me reach Guru status actually quite fast.
On Wed, 23 May 2007 05:25:11 +0200, Tim X <t...@nospam.dev.null> wrote: > The sad thing here is that when I arrived at this company, I was told > that the > author of that bit of code was one of their /best/ programmers and I > would do > well to use him as a mentor. This confused me until I realised that
> 1. Most managers wouldn't recognise well written software even if it bit > them > in the ass > 2. Some programmers are able to establish a higher degree of influence > over the > 3. Management, because it doesn't understand the long-term cost benefits > of > well written code produced by experienced (and therefore more expensive) > programmers, concentrates on driving down the staff costs by employing > recent > 4. Management assumes that any software will have high maintenance > costs. The > incorrect solution adopted is to either do anything to avoid creating > Tim
Actually I think the manager is probably right and you are wrong. You seem to suffer from the 'my language has x why doesn't language y have x' syndrome. See that a lot in Lisp too. Each language has it's idioms. To use the language efficiently you have to think in those idioms not translate from the practice you are used to from Lisp.
What you seem to miss is that Lisp is optimally efficient for a middle sized program (20 000 - 100 000 lines say) written for a small number of developers. If you have 20 programmers having all of them implementing their own custom syntax is a nightmare. So it is not a style I would recommend for large programmes with many programmers. Let's say you have 50 developers. You need to fix a bug in code you didn't write. You extract the file from CVS. You track down the offending code. Now you discover that the problem is in a macro written in another module. Changing that affects other uses as well.. so you need to write an new one when you have figured out what this guy was trying to do in the first place. This can be more wasteful than helpful. You could say the more homogeneous the style the easier to maintain because it is easier for another person to read and understand. This and not the amount of code is more important for maintaining the program.
On May 23, 8:28 am, "John Thingstad" <john.things...@chello.no> wrote:
> Let's say you have 50 developers. You need to fix a bug in code you didn't > write. > You extract the file from CVS. You track down the offending code. > Now you discover that the problem is in a macro written in another module. > Changing that affects other uses as well.. so you need to write an new one > when you > have figured out what this guy was trying to do in the first place. > This can be more wasteful than helpful.
Judging from experience, that paragraph applies to at least C and C++ as well.
> You could say the more homogeneous the style the easier to maintain > because it is easier > for another person to read and understand. This and not the amount of code > is more > important for maintaining the program.
Homogenous style? In a C project involving more than 20 programmers? Good one :)
Each developer doing his own syntax will conceivably lead to problems - I couldn't say, I've yet to find the opportunity to use Lisp in a team. But the better teams I've worked in were organized so as let the better/older/lead developers do the design and the others do the brunt of the coding. Shouldn't that work in Lisp teams as well? Letting them who know what they're doing create the application-necessary abstractions and design guidelines, and then letting the junior coders use those abstractions and adhere to those guidelines?
> Each developer doing his own syntax will conceivably lead to problems > - I couldn't say, I've yet to find the opportunity to use Lisp in a > team. > But the better teams I've worked in were organized so as let the > better/older/lead developers do the design and the others do the brunt > of the coding. Shouldn't that work in Lisp teams as well? Letting them > who know what they're doing create the application-necessary > abstractions and design guidelines, and then letting the junior coders > use those abstractions and adhere to those guidelines?
Yes. But if you look at the post it is written by one of the rookie programmers who wanted to introduce new syntax for his code and the experienced programmer that refused him.
What I disagree is that this is C#'s fault.
I have experience with developing large systems in C++ but not in Lisp yet so it is hard to tell. I do know that this is why designers like design patterns. (Most programmers like me hate them I guess..)
> On Wed, 23 May 2007 05:25:11 +0200, Tim X <t...@nospam.dev.null> wrote:
> > The sad thing here is that when I arrived at this company, I was told > > that the > > author of that bit of code was one of their /best/ programmers and I > > would do > > well to use him as a mentor. This confused me until I realised that
> > 1. Most managers wouldn't recognise well written software even if it bit > > them > > in the ass > > 2. Some programmers are able to establish a higher degree of influence > > over the > > 3. Management, because it doesn't understand the long-term cost benefits > > of > > well written code produced by experienced (and therefore more expensive) > > programmers, concentrates on driving down the staff costs by employing > > recent > > 4. Management assumes that any software will have high maintenance > > costs. The > > incorrect solution adopted is to either do anything to avoid creating > > Tim
> Actually I think the manager is probably right and you are wrong. > You seem to suffer from the 'my language has x why doesn't language y have > x' syndrome. > See that a lot in Lisp too. Each language has it's idioms. > To use the language efficiently you have to think in those idioms not > translate from the practice you are used to from Lisp.
> What you seem to miss is that Lisp is optimally efficient for a middle > sized program (20 000 - 100 000 lines say) written for a small number > of developers.
'small team' is fine. Smaller teams are better and more productive. Lisp gives them lots of power. But 20 - 100k lines? I think Lisp scales more. If you need that many lines of code.
>If you have 20 programmers having all of them implementing > their own custom syntax is a nightmare.
But this is not how teams of programmers work. I had the 'pleasure' to be the project leader of upto 20+ Java programmers (no joke). Teams get organized by module, by architects, domain experts, and so on. Not everyone introduces new architectures, even if they want they have to discuss it with architects or lead programmers.
> So it is not a style I would > recommend for > large programmes with many programmers. > Let's say you have 50 developers. You need to fix a bug in code you didn't > write. > You extract the file from CVS. You track down the offending code.
Again this is not how larger groups work. Bugs tend to be described in a bug-tracking tool and some programmer has/gets/takes the task to fix that bug. There will be tests and reviews. If it is a core module where changes affect architecture and apis, you consult the architect (if he/she isn't doing the job him/herself).
> Now you discover that the problem is in a macro written in another module. > Changing that affects other uses as well.. so you need to write an new one > when you > have figured out what this guy was trying to do in the first place. > This can be more wasteful than helpful. > You could say the more homogeneous the style the easier to maintain > because it is easier > for another person to read and understand. This and not the amount of code > is more > important for maintaining the program.
I don't think scaling the one-programmer organisation to a team of 20 or even fifty is that simple. Larger teams tend to have some internal structure.
In article <pan.2007.05.23.00.55.32.401...@areilly.bpc-users.org>, Andrew Reilly <andrew-newsp...@areilly.bpc-users.org> wrote:
> On Tue, 22 May 2007 19:32:36 +0200, Rainer Joswig wrote:
> > Working in a team helps. You'll get feedback if others > > have to use your code.
> Do many lisp users work in teams?
If 'team' don't have to be not physically located in the same room, then team work is dominant.
Just check out the open source Lisp projects that are popular, most have more than one person submitting code. There are lively discussions about fixes and changes on mailing list and by other means.
In companies working on a project or product I guess two to ten people is normal. I wouldn't really have a project where just one person knows the code - that's a risk.
Also note that Lisp often creates a style of software where the line between developers and users get blurry. Users start hacking on the code and contribute. Actually that is the secret weapon how to create successful software communities. Open up the code and let users contribute. It does not necessarily mean to 'open source' it. Many 'users' of Lisp code get some good hacking skills over time. In Common Lisp there is often not the difference between implementation and extension language.
> I've gained the impression from > discussions here that the lone-coder image is more the rule [and it > certainly seems to be the case that that one can go a lot further in that > mode with lisp than anything else.] From the little scheme coding that > I've done so far, I think that I'd have to put a good deal more effort > into documentation (at least) before I'd be happy to have my current > project hacked-on by other programmers, although ultimately that will be > necessary. Maybe I should make more use of OO and packages/modules, and > lay off the functional abstraction a bit...
Christopher Koppler wrote: > On May 23, 8:28 am, "John Thingstad" <john.things...@chello.no> wrote: >> Let's say you have 50 developers. You need to fix a bug in code you >> didn't write. >> You extract the file from CVS. You track down the offending code. >> Now you discover that the problem is in a macro written in another >> module. Changing that affects other uses as well.. so you need to write >> an new one when you >> have figured out what this guy was trying to do in the first place. >> This can be more wasteful than helpful.
> Judging from experience, that paragraph applies to at least C and C++ > as well.
>> You could say the more homogeneous the style the easier to maintain >> because it is easier >> for another person to read and understand. This and not the amount of >> code is more >> important for maintaining the program.
> Homogenous style? In a C project involving more than 20 programmers? > Good one :)
> Each developer doing his own syntax will conceivably lead to problems > - I couldn't say, I've yet to find the opportunity to use Lisp in a > team. > But the better teams I've worked in were organized so as let the > better/older/lead developers do the design and the others do the brunt > of the coding. Shouldn't that work in Lisp teams as well? Letting them > who know what they're doing create the application-necessary > abstractions and design guidelines, and then letting the junior coders > use those abstractions and adhere to those guidelines?
Once again, apologies for my noobishness, but surely the way a team works is for a senior developer(s) to do the top-level design of the whole shebang, but leave the implementation details of each programmer's assigned work to the programmer? Otherwise, wouldn't you effectively be using the junior programmers as mere typists?
> Now you discover that the problem is in a macro written in another module. > Changing that affects other uses as well.. so you need to write an new one > when you > have figured out what this guy was trying to do in the first place.
Or for a one off problem, you could macroexpand-1 the statement and then patch it, leave the original in place as a comment, and, if it wasn't simple misuse of the macro, put a note next to the macro definition pointing to this fix.
Your solution is the same as rewriting a major library the first time you have problems calling it.
> Ben <benbe...@gmail.com> writes: > > Well, I finally reached enlightenment. I understand why people > > don't use lisp. It took me a long time. It isn't a lack of > > libraries, or the number of parentheses. The thing that kills a > > language is powerful syntax and abstractions.
> > I work in C# (worst language EVER!) and I had to write some loops to > > accumulate some values in some collections. I spent a good deal of > > time looking for some standard accumulate function. Nothing. So I > > decided to roll my own using generics and anonymous functions. My > > manager looked at the code and asked "Who's going to maintain this? > > How will they understand it?" > > That's not the first time I've encountered these questions. I heard > > it when I used function pointers in C. I heard it when I used > > templates in C++. I heard it when I used Lisp for ANYTHING. :)
> > I can certainly understand concerns about over engineering a > > solution. I've been the victim of many over complicated class > > structures. I think there's a difference between complicating a > > design and using the language syntax. When I simplified the > > implementation from six independent functions to one that gets an > > anonymous function, I thought I was making it easier. I didn't worry > > that future developers would have to know ALL the syntax of the > > language instead of just the set that intersects with C++.
> > I'm finding that regardless of the language used, many > > "professional" developers have a serious issue with the more powerful > > abstractions available to them. A language like Lisp that supports > > the abstractions so naturally (as opposed to the syntactic mutilation > > that happens in C#) is doomed.
> > Sorry about the rant. I am incredibly frustrated. How is C#'s poor > > readability my fault? I didn't design or select the doggone language.
> > I hope our product's translators understand the languages they > > translate. Maybe they figure knowing a few major words is enough, and > > they can wing the rest! :)
> I wish I could say your wrong, but unfortunately, there is a good bit of truth > in what you say - at least from my experience. Only yesterday I was given some > code because it was supposed to do almost exactly what I've been asked to > create. The code consisted of many many lines similar to
> and on over an array of 30 elements. When you see this sort of code, you > understand why so many programmers don't understand the great power of lisp or > macros. I mean, this programmer didn't even understand a bloody loop, so what > chance is there of them understanding things like macros, CLOS or even get past > lisp parens?
> The sad thing here is that when I arrived at this company, I was told that the > author of that bit of code was one of their /best/ programmers and I would do > well to use him as a mentor. This confused me until I realised that
> 1. Most managers wouldn't recognise well written software even if it bit them > in the ass > 2. Some programmers are able to establish a higher degree of influence over the > system, not because they are good programmers, but rather because they are good > communicators who understand either the bigger picture or at least the picture > as seen by management. > 3. Management, because it doesn't understand the long-term cost benefits of > well written code produced by experienced (and therefore more expensive) > programmers, concentrates on driving down the staff costs by employing recent > graduates and people with little experience to work in an environment where the > tools are dictated more by how easily you can get cheap staff rather than by > what will produce the best product in the long-term. > 4. Management assumes that any software will have high maintenance costs. The > incorrect solution adopted is to either do anything to avoid creating your own > systems (i.e. the 'vendor solution') and/or make sure your programmers are as > cheap as possible. There has been no connection made between the high > maintenance costs and inexperienced programmers using poor tools.
> All of this is made worse by the short-term management style which seems to be > prevalent these days. As a manager, your objective is to reduce the costs over > the immediate short-term to make you appear successful and able to climb the > greasy pole to the next higher position. Its irrelevant that your cost cutting > measures have resulted in major cost blowouts in 5+ years, when you have moved > on and are no longer accountable (your probably now the person that you > would/should have been accountable to anyway).
Kaizen :) Most managers think that all languages are roughly the same, if only thing you ever get exposed is c/c++/C#/java and some sql that's roughly true but cross at the dark side :lisp ,prolog, forth, erlang ... and things gets tricky. The main complaint against lisp (beside that java has more outsourcing contracts) is that you need a guru to code in lisp while anybody could code in java/c#/delphi which is complete rubbish. If some programmer is unable to learn lisp and only thing he could do is making fancy guis using the visual studio/ eclipse/delhi designer get rid of him :) http://wiki.alu.org/Slobodan
> The extent to which this happens appears to be linked to the size of the > organisation you are in. I've found working for smaller organisations is often > far more rewarding as the people involved appear to be more aware, will stick > around for longer and therefore have a greater interest in long-term success > and often you are able to more readily exercise your skills and experience to > solve the problem, rather than be constrained by beurocratic ignorance!
> Tim > -- > tcross (at) rapttech dot com dot au
It depends on the atmosphere of the firm, I've been lucky to work only for firms where coworkers share their knowledge and help each other. Compared with horror stories I've heard from my friends like lay offs of the 10% of worst performers EVERY YEAR I doubt that anybody will tell anybody else something useful. Some smaller firms even allow you to realise some of your ideas if they have a potential to be profitable.
> On Wed, 23 May 2007 05:25:11 +0200, Tim X <t...@nospam.dev.null> wrote:
>> The sad thing here is that when I arrived at this company, I was >> told that the author of that bit of code was one of their /best/ >> programmers and I would do well to use him as a mentor. This >> confused me until I realised that
>> 1. Most managers wouldn't recognise well written software even if >> it bit them in the ass >> 2. Some programmers are able to establish a higher degree of >> influence over the >> 3. Management, because it doesn't understand the long-term cost >> benefits of well written code produced by experienced (and >> therefore more expensive) programmers, concentrates on driving down >> the staff costs by employing recent >> 4. Management assumes that any software will have high maintenance >> costs. The incorrect solution adopted is to either do anything to >> avoid creating >> Tim
> Actually I think the manager is probably right and you are wrong. > You seem to suffer from the 'my language has x why doesn't language > y have x' syndrome.
No he's not. He's suffering from the "this language has X why didn't programmer Y use it?" syndrome.
When X is C's "for" loop, you really have to question the competency of programmer Y, and of the manager (Z) that says "Y is our best programmer".
In Z's defense, if he never looks at the code, Y's code consistently has the fewest bugs, then he could easily justify his statement. Y's code exhibits bad design, in that it's rigid, fragile, and immobile, but hey, it *works* (... in the hypothetical world of "few bugs").
Jeff Rollin wrote: > surely the way a team works is for a senior developer(s) > to do the top-level design of the whole shebang,
Both top and bottom. Regarding the twenty-different-styles issue, someone should be in charge of compiling one or more libraries, both application-specific and [company|department]-wide. Junior staff should be working in the middle, everyone using the same conventions. That can be done in any language.
On May 22, 7:16 pm, Ken Tilton <kennytil...@optonline.net> wrote:
> Ben wrote: > > Sorry about the rant. I am incredibly frustrated. How is C#'s poor > > readability my fault?
> Or is it, How is the poor readability of your code C#'s fault? I have > seen impossibly dense COBOL code, code even its authors could not follow.
Reminds of the old story before the computer era : (foo) What mark you got on the literature test? (bar) I failed. (foo) Why? (bar) Teach' couldn't understood my handwriting. (foo) Why didn't you read it yourself for her. (bar) I couldn't understand it too.
> The big mistake is thinking Lisp is going to grow by first being adopted > in Tall Buildings. They are the drones, the lemmings, the sheep. They > follow where We the Blessed Gurus lead them. But this time it is to the > slaughterhouse, because the world needs only fifty Lisp programmers to > write All the Code.
