Hi! Currently I'm working for a company on a project with ~60Megs of C++
code. It has become clear to the management that the code has become
unmanageable. What would be a good way to persuade the management that
Lisp is the way to go (we do some calculations; that is written in Fortran;
we use some OpenGL, but Lisp would be used for glueing the system together
and scripting). The major argument against Lisp (as I see it) is that
very few programmers in the firm know Lisp.
The Lord of Chaos <······@trade.secret> writes:
> What would be a good way to persuade the management that Lisp is the
> way to go (we do some calculations; that is written in Fortran; we
> use some OpenGL, but Lisp would be used for glueing the system
> together and scripting).
show stuff that works, and how quick you hacked it together? Especially
if its possible for you to quickly replace some part of your system with
a working lisp part.
--
(espen)
The Lord of Chaos <······@trade.secret> wrote in message news:<·····················@fly.srk.fer.hr>...
> Hi! Currently I'm working for a company on a project with ~60Megs of C++
> code.
Why? Ah, but your name.
The Lord of Chaos wrote:
> Hi! Currently I'm working for a company on a project with ~60Megs of C++
> code.
IIUC, big C++ systems take forever to build. Work that angle by
demonstrating dynamic interaction with Lisp. ie, compiling one function
at a time, or changing a class in mid-run, or hitting a backtrace,
fixing a nug then resuming execution, etc etc.
ie, get 'em drooling.
> The major argument against Lisp (as I see it) is that
> very few programmers in the firm know Lisp.
Hire one Lisp guru with good people skills and have them
teach/review/help everyone get up to speed?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
>>>>> "The" == The Lord of Chaos <······@trade.secret> writes:
The> The major argument against Lisp (as I see it) is that very few
The> programmers in the firm know Lisp.
I maintain that any competent programmer that has mastered OO
programming in any language[1] also is able to learn lisp.
With a project to replace 60Mb of C++ code, even small gains in
productivity should be able to finance even rather substantial
up-front training. You pay training once, productivity penalities are
paid over and over for as long as the product lives.
This is not to say that you should take training lightly. If you get
management on the wagon, consider getting outside help for the initial
teaching (at least Franz Inc. does various courses on Common Lisp).
Also do not forget Greenspuns 10. rule of programming. You may be able to
simulate a number of productivity enhancing features of common lisp in
any given language, but it will come at great pain and cost.
The list of things believed to be wrong with lisp is long, but few
people disputes that lisp is the most advanced and sophisticated
programming environment around.
[1] Being able to write a program in Java is not the same as
understanding the basics of OO.
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.se
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
From: Friedrich Dominicus
Subject: Re: How to convince employer..
Date:
Message-ID: <87k7h5jdzb.fsf@fbigm.here>
Christian Lynbech <·················@ted.ericsson.se> writes:
>
> This is not to say that you should take training lightly. If you get
> management on the wagon, consider getting outside help for the initial
> teaching (at least Franz Inc. does various courses on Common Lisp).
Xanalys offers such trainings too...
Anyway 60 MB code is definitly not a small project and unfortunatly
don't we know anything about it. We do not know what tools are uses
(how many code might have been generated?) and and.
We too do not have an idea on how long and with how many people they
are working for it. In projects of such extend the programming
language is just one factor and I bet one of the smaller
ones.
Regards
Friedrich
In article <··············@fbigm.here>, Friedrich Dominicus wrote:
>
> Anyway 60 MB code is definitly not a small project and unfortunatly
> don't we know anything about it. We do not know what tools are uses
> (how many code might have been generated?) and and.
>
Sorry, but I am bound by trade secret so I can't reveal many details.
I even fake me e-mail address so that I don't reveal too much.
There are two parts of the application: the calculation kernel (all written
in Fortran and not likely to change that) and the GUI front-end for visualizing
results, file format conversion, etc. All of the front-end is written in C++
(bad C++, as everyoune agrees). GUI is written with one of LGPL'd
cross-platform toolkits. As for automatically generated code, only some dialogs
from textual specification are dynamically generated. There is no generated
code as such. All other GUI is constructed by C++ code. Other classes deal
with representation of 3-D models.
The idea is to make a set of well-defined objects, operations on those objects
and to export such functionality to lisp (would be used for scripting, too).
Anyway, thanks for your input!
* The Lord of Chaos wrote:
> Sorry, but I am bound by trade secret so I can't reveal many details.
> I even fake me e-mail address so that I don't reveal too much.
I bet whatever it is doesn't run on the HP48 though...
--tim
In article <···············@cley.com>, Tim Bradshaw wrote:
> * The Lord of Chaos wrote:
>
>> Sorry, but I am bound by trade secret so I can't reveal many details.
>> I even fake me e-mail address so that I don't reveal too much.
>
> I bet whatever it is doesn't run on the HP48 though...
>
No, it doesn't :) BTW, how did you remember it? It's my favorite calculator :)
I have own one..
>>>>> "Friedrich" == Friedrich Dominicus <·····@q-software-solutions.com> writes:
Friedrich> In projects of such extend the programming language is just
Friedrich> one factor and I bet one of the smaller ones.
In theory you are correct. With competent programmers, thorough
documentation discipline and rigorous use of highlevel abstraction in
the description of requirements and design decisions, the choice of
programming language becomes secondary. The intellectual capital
invested in an application is in principle mostly in the datamodels,
the application architecture, the selected algorithms and the user
interface, more so than how those things are realised in any given
language.
In practice, I believe the choice of programming language (and to some
extent also the tools to support that) to be of a much more important
factor than people normally realise. Computers do not care about
documentation for instance. They go stubbornly by what is in the code,
so the actual pratical maintainability of the source code is a huge
parameter in the overall success of a project. Another matter is that
spending hour after hour realising ideas in concrete source code
affects the mindsets of the programmers. In some sense our thinking is
if not bounded then at least affected by what we can say and I do not
think that it is very common for programmers to be really fluent in
more than one language at a time.
Time for another of my favourite quotes:
"In theory, theory and practice are the same, in practice they are not."
------------------------+-----------------------------------------------------
Christian Lynbech | Ericsson Telebit, Skanderborgvej 232, DK-8260 Viby J
Phone: +45 8938 5244 | email: ·················@ted.ericsson.se
Fax: +45 8938 5101 | web: www.ericsson.com
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
On 16 Jan 2003 07:11:38 GMT, The Lord of Chaos <······@trade.secret> wrote:
> Lisp is the way to go (we do some calculations; that is written in Fortran;
The f2cl Fortran to Common Lisp translator maintained as part of CLOCC
(Common Lisp Open Code Collection) might help:
http://clocc.sourceforge.net
Paolo
--
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://www.paoloamoroso.it/ency/README
"The Lord of Chaos" <······@trade.secret> wrote in message
··························@fly.srk.fer.hr...
> Hi! Currently I'm working for a company on a project with ~60Megs of C++
> code. It has become clear to the management that the code has become
> unmanageable. What would be a good way to persuade the management that
> Lisp is the way to go (we do some calculations; that is written in Fortran;
> we use some OpenGL, but Lisp would be used for glueing the system together
> and scripting). The major argument against Lisp (as I see it) is that
> very few programmers in the firm know Lisp.
>
Personal Character.
Wade
The Lord of Chaos <······@trade.secret> writes:
> Hi! Currently I'm working for a company on a project with ~60Megs of C++
> code. It has become clear to the management that the code has become
> unmanageable. What would be a good way to persuade the management that
> Lisp is the way to go (we do some calculations; that is written in Fortran;
> we use some OpenGL, but Lisp would be used for glueing the system together
> and scripting).
Would it be possible to convince the managment that for the next
(major) project planned to be implemented in C++ that they put 10% of
the budget into creating a secondary version in Lisp in case the C++
version runs into serious problems? Another argument you could use is
that this will create some competition so that the C++ programmers
would do better work so that the extra money could be well spent even
if the Lisp version is not used in the end.
If you are good enough the result could be a real eye opener for the
managment (and for the C++ programmers if the competition has been
friendly).
> The major argument against Lisp (as I see it) is that
> very few programmers in the firm know Lisp.
If they are any good they will recognize the results and be interested
in learing more.
Oluf
Not sure what to say.....
At work we have a need to load function definitions from a text file and
iteratively evaluate them. The current code is >5KLOC of C++ and the author
admits that it badly needs rewriting. So, a few evenings ago I hacked
together less than a page of Lisp to show that I can convert the text
strings to prefix form, compile them, then execute against any argument
list. Dead easy to write, didn't even finish one beer in the process. Also
disassembled the code to "prove" it was compiled and not interpreted (which
the C++ code does). Even added type declarations to get inline FP
instruction. I didn't even get a reply to my email with the demo code and
timings. Oh, while I'm preaching to the converted, the Lisp code runs
faster.
My solution - a serious slap up the side of the head might get their
attention. I wish I could be more creative.
Alan.
"The Lord of Chaos" <······@trade.secret> wrote in message
··························@fly.srk.fer.hr...
> Hi! Currently I'm working for a company on a project with ~60Megs of C++
> code. It has become clear to the management that the code has become
> unmanageable. What would be a good way to persuade the management that
> Lisp is the way to go (we do some calculations; that is written in
Fortran;
> we use some OpenGL, but Lisp would be used for glueing the system together
> and scripting). The major argument against Lisp (as I see it) is that
> very few programmers in the firm know Lisp.
>
Alan Walker wrote:
> Not sure what to say.....
>
> ... a few evenings ago I hacked
> together less than a page of Lisp to show that I can convert the text
> strings to prefix form....
> I didn't even get a reply to my email with the demo code and
> timings.
These things aint easy, and I am not even that good at it my self, but I
do suspect you made a mistake I often make, viz, thinking everyong will
"get it" on the basis of one email or article or letter or whatever.
I imagine there are books or at least papers on how to introduce new
ideas into organizations. Certainly marketing books are like that, and
to a degree you are looking at a tough marketing problem, like getting a
customer to switch from Windows to OS X. So I think you are looking at
putting together a coherent strategy and being prepared to execute over
multiple tactical forays.
Your first foray was pretty cool, but if you just dropped it in their
email boxes without any warning they probably opened it, read it, then
thought "ok, but we are not using lisp, so what's the point?". did you
prepare them in advance for this email? or do they know you have been
arguing for Lisp, so they already had the context? If there was no
"readiness" for the info you provided it will roll off them like water
off a duck. and by no means should you expect them just to read the
thing and come running to your cubicle.
I hear the way to get ideas across is to tell them what you are going to
be saying, then say it, then tell them what you just told them. You have
to expect to make multiple pitches and follow-up, make it a drumbeat of
information they get accustomed to thinking about ("I wonder what Alan
will do next on his Lisp mission"). One email does not create mindshare.
To me the first question is, are /you/ sure Lisp is the way to go. If
not, do more feasibility checks like the one you already did. Once/if
you are satisfied, suck it up and make a laughing stock of yourself by
proposing Lisp formally. Offer in support all the feasibility checks.
Demonstrate the interactivity of Lisp by showing how easy it is to
develop iteratively. But...
Like I said, I am no expert on this. One thing I just thought of: in The
Soul of a New Machine, Kidder describes how the rebel leader quietly
walked around to key player after key player to get them to sign on in
advance. Maybe one-on-one gets past groupthink in some way. Only when he
had enough support did he propose the parallel project to management as
a fallback (fully expecting to win outright).
Something like that.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> I imagine there are books or at least papers on how to introduce new
> ideas into organizations.
Yes, there are. See "Introducing New Ideas into Organizations":
http://www.cs.unca.edu/~manns/intropatterns.html
Pascal
--
"If I could explain it, I wouldn't be able to do it."
A.M.McKenzie
Kenny Tilton:
[...]
> To me the first question is, are /you/ sure Lisp is the way to go. If
> not, do more feasibility checks like the one you already did. Once/if
> you are satisfied, suck it up and make a laughing stock of yourself by
> proposing Lisp formally. Offer in support all the feasibility
> checks. Demonstrate the interactivity of Lisp by showing how easy it
> is to develop iteratively. But...
>
> Like I said, I am no expert on this.
And I am certainly not an expert, but I wonder if the point was made
by people at Boeing ages ago: protect your software investments. Show
how using Lisp can protect previous, current and future software
investments (if that is a property of Lisp).
--
Odd Skjaeveland ····@sivos.rl.no
From: Michael S. Zraly
Subject: Re: How to convince employer..
Date:
Message-ID: <H8xzvC.56t@world.std.com>
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
>
>
>Alan Walker wrote:
>> Not sure what to say.....
>>
>> ... a few evenings ago I hacked
>> together less than a page of Lisp to show that I can convert the text
>> strings to prefix form....
>
>> I didn't even get a reply to my email with the demo code and
>> timings.
>
>These things aint easy, and I am not even that good at it my self, but I
>do suspect you made a mistake I often make, viz, thinking everyong will
>"get it" on the basis of one email or article or letter or whatever.
>[...]
You must also be able to answer other concerns, e.g.:
1. We can't find / don't have the money to train more lispers to
maintain this when/if you leave.
2. We don't have the budget for another development environment
(if not for licenses, at least for support)
etc.
Questions like #1 can be addressed by showing how easy it is to
train someone in lisp, I suppose: the minimal syntax helps, even
if some of the quoting stuff looks like perl sigils.
Questions like #2 are more difficult. Conservative organizations
(and most are conservative, especially in this economy) want to
have someone they can call when they find a compiler bug,
preferably someone who is under contract to render assistance,
so freeware compilers tend to be suspect. If you are asking an
existing organization to migrate code from one language to another,
there will be a time when that organization has to support *both*
old and new languages. Depending on how much the company supports
older versions of its product, it may *never* be able to make a
complete switch. Even if there is no additional cash required,
though, those responsible for maintaining the developers'
environment may balk at having to track patches for yet another
product. I ran into this recently when I wanted to run some
regression tests in expect and was asked if I couldn't use perl
instead, to avoid the need to support expect on all our development
and build machines.
--
Mike Zraly There's only one good solution,
······@world.std.com and that's bulldozers at 30 paces.
-- WSJ headline, 3 Dec 1992
Michael S. Zraly wrote:
> You must also be able to answer other concerns, e.g.:
>
> 1. We can't find / don't have the money to train more lispers to
> maintain this when/if you leave.
>
> 2. We don't have the budget for another development environment
> (if not for licenses, at least for support)
>
> etc.
>
> Questions like #1 can be addressed by showing how easy it is to
> train someone in lisp...
yep.
>
> Questions like #2 are more difficult. Conservative organizations
> (and most are conservative, especially in this economy) want to
> have someone they can call when they find a compiler bug,
> preferably someone who is under contract to render assistance,
> so freeware compilers tend to be suspect.
CMIIAW, but aren't commercial products pretty reasonably-priced? And I
know for a fact MCL and ACL support (the only ones I've experienced, but
I get the feeling LW is up there) are superb, almost near-real-time and
sharp.
And isn't the price of these things negligible compared against the cost
of using something else? Consider the OP's premise: "everyone knows C++
is killing us, a death by a thousand cuts". Hey, is C++ short for?:
(cuts thousands thousands)
Anyway, think about the OP's premise. Is that not what I have been
saying? C++ is the end of the static branch of language evolution. Java
is the lingering last gasp, the Perostroika of Communism. Too little,
too late, despised in its own right.
We must strike at the weakest point: productivity. Fortunately that
happens to be our strongest, whether from the expressive power, the
language-within-a-language thang, or restarting from a backtrace
successfully after an hour of refactoring.
> If you are asking an
> existing organization to migrate code from one language to another,
> there will be a time when that organization has to support *both*
> old and new languages.
They won't forget the older language /that/ fast! :)
> Depending on how much the company supports
> older versions of its product, it may *never* be able to make a
> complete switch.
With UFFI, you do not have to. :)
> Even if there is no additional cash required,
> though, those responsible for maintaining the developers'
> environment may balk at having to track patches for yet another
> product.
Another argument for Lisp, because it is mature, stable and
standardized. That had me diving for the checkbook when someone
recommended Lisp, cuz I'd just been through Component Workshop and
SmalltalkAgents in my unwitting search for MCL.
> I ran into this recently when I wanted to run some
> regression tests in expect and was asked if I couldn't use perl
> instead, to avoid the need to support expect on all our development
> and build machines.
I have the answer! Fuck 'em. Go code. :)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
"Alan Walker" <·························@charter.net> writes:
> the C++ code does). Even added type declarations to get inline FP
> instruction. I didn't even get a reply to my email with the demo code and
> timings. Oh, while I'm preaching to the converted, the Lisp code runs
> faster.
Political issues are unfortunately often more important
than facts. ( Just as they are in the current war-to-be )
--
natsu-gusa ya / tsuwamono-domo-ga / yume no ato
summer grasses / strong ones / dreams site
Summer grasses,
All that remains
Of soldier's dreams
(Basho trans. Stryk)
"Alan Walker" <·························@charter.net> writes:
> Not sure what to say.....
>
> [snip Lisp solution that wins over C++ solution]
>
> My solution - a serious slap up the side of the head might get their
> attention. I wish I could be more creative.
You probably won't win. One of the biggest difficulties I've had
convincing co-workers to try Lisp was that they thought they wouldn't
be able to use it in any other job--and they were right. No
demonstration of Lisp's superiority will ever trump that.
Fortunately, I'm the only one working on the non-web portion of it,
and get to pick my own language...
Gabe Garza
Gabe Garza wrote:
> "Alan Walker" <·························@charter.net> writes:
>
>
>>Not sure what to say.....
>>
>>[snip Lisp solution that wins over C++ solution]
>>
>>My solution - a serious slap up the side of the head might get their
>>attention. I wish I could be more creative.
>
>
> You probably won't win. One of the biggest difficulties I've had
> convincing co-workers to try Lisp was that they thought they wouldn't
> be able to use it in any other job--and they were right.
True. So I guess the first recruits to the cause should be those
confident enough in their skills that they know they do not worry about
having Lang du Jour on the rez. And those would be the ones most
susceptible to Lisp anyway.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Cells let us walk, talk, think, make love and realize
the bath water is cold." -- Lorraine Lee Cudmore
In article <··············@corp.supernews.com>,
"Alan Walker" <·························@charter.net> wrote:
> Not sure what to say.....
>
> At work we have a need to load function definitions from a text file and
> iteratively evaluate them. The current code is >5KLOC of C++ and the author
> admits that it badly needs rewriting. So, a few evenings ago I hacked
> together less than a page of Lisp to show that I can convert the text
> strings to prefix form, compile them, then execute against any argument
> list. Dead easy to write, didn't even finish one beer in the process. Also
> disassembled the code to "prove" it was compiled and not interpreted (which
> the C++ code does). Even added type declarations to get inline FP
> instruction. I didn't even get a reply to my email with the demo code and
> timings. Oh, while I'm preaching to the converted, the Lisp code runs
> faster.
Don't be so defensive.
What you should have done was just send them an email saying "I rewrote
the XXX program, here's the new binary for you to try ... btw it's xx%
faster than the previous version". Don't even *mention* what language
you wrote it in or whether it is compiled or interpreted ... let them
come and ask.
-- Bruce