(Prolog + LISP + Erlang) with integration issues versus C++
devfun...@gmail.com
Given the insistence of the members of the team to use the
best language for specific purpose, we have code that is
written in
1. Prolog (enumerating device drivers, goal seek)
2. LISP (classical AI stuff, inference)
3. Erlang (server, communication and distributedness)
The products we have used are
1. gprolog
2. clisp
3. Erlang/OTP
The independent modules have been developed successfully,
however we are unable to surmount the language boundaries
and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
The team has quickly built the components (less than 3 months)
and proven the idea.
The management is worried about our choice of three languages
and has strongly suggested a relook at this strategy.
The External Consultant (Subject Matter Expert) has suggested that -
0. since the individual components are implemented,
the idea is partially proven
1. the language barriers will cause problems in integration
and performance
2. the long-term success and reach of the product will be
based on complete implementation in C++.
3. The Visualizer will be implemented in OpenGL and C++ based modules
will be quite easy to integrate.
4. C++ performance will be good if a ANN component is added later
due to customer request.
5. Multi-language maintenance costs will be high
The team is disappointed, since the effort in learning the languages
will be wasted. The 6 developers are from C/Java background.
Greatly appreciate if the more experience members of this group
share their experiences and put forward the suggestions.
I need to present a case for the proposed solution, on the coming
Monday.
Thanks in advance.
thanks
Dev.
Friedrich Dominicus
> Hello
>
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in
> 1. Prolog (enumerating device drivers, goal seek)
> 2. LISP (classical AI stuff, inference)
> 3. Erlang (server, communication and distributedness)
>
> The products we have used are
> 1. gprolog
> 2. clisp
> 3. Erlang/OTP
>
> The independent modules have been developed successfully,
> however we are unable to surmount the language boundaries
> and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
Well I feel that you had checked that before going on that
journey. But what should be an insurmountable problem? You did not say
anything about what information should be exchanged.
>
> The team has quickly built the components (less than 3 months)
> and proven the idea.
>
> The management is worried about our choice of three languages
> and has strongly suggested a relook at this strategy.
>
> The External Consultant (Subject Matter Expert) has suggested that -
> 0. since the individual components are implemented,
> the idea is partially proven
> 1. the language barriers will cause problems in integration
> and performance
Well if you use different languages you have to find a way to make
them talk to another. That true for any language
> 2. the long-term success and reach of the product will be
> based on complete implementation in C++.
Utterly nonsense.
> 3. The Visualizer will be implemented in OpenGL and C++ based modules
> will be quite easy to integrate.
Well you can't integrate C++ easily with any other language but
writing all the Interface stuff in C.
And you can implement the OpenGL stuff with Common Lisp also.
> 4. C++ performance will be good if a ANN component is added later
> due to customer request.
So what? this is just word-of-mouth, in this context. C++ can be poor
as hell.
> 5. Multi-language maintenance costs will be high
So will the manual book keeping of memory allocations.
>
> Greatly appreciate if the more experience members of this group
> share their experiences and put forward the suggestions.
>
> I need to present a case for the proposed solution, on the coming
> Monday.
IMHO you will get into deep trouble. The external will be heard and
you will restart re-implementing all that stuff, and it will take you
more then double the time as finding a way to let interact the
different langauges.
However IMHO it is naive to start working without knowing on how the
interfaces should look. What did you expect? If you don't look after
the interface problems before starting you have made a real *big*
mistake.
But reimplementing a thing in a different languages is IMHO a much
bigger one.
check what data should be exchanged and add the components to
read/write such data, and then you are "done"
Regards
Friedrich
Pascal Costanza
> Hello
>
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in
> 1. Prolog (enumerating device drivers, goal seek)
> 2. LISP (classical AI stuff, inference)
> 3. Erlang (server, communication and distributedness)
>
> The products we have used are
> 1. gprolog
> 2. clisp
> 3. Erlang/OTP
>
> The independent modules have been developed successfully,
> however we are unable to surmount the language boundaries
> and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
It's relatively straightforward to embed a Prolog in Common Lisp. There
are books that describe how to do that (On Lisp, Paradigms of Artificial
Intelligence Programming), and there are Common Lisp implementations
that already provide it (Allegro, LispWorks and, IIRC, Christophe Rhodes
is working on something for SBCL).
Server, communication and distributedness is not alien to Common Lisp,
but that part depends on how Erlang-specific your code is. Again, it's
relatively straightforward to whip up something simple yourself, by
sending s-expressions over sockets, and again several Common Lisp
implementations already provide good solutions.
Consider contacting a commercial Common Lisp vendor. They are probably
happy to support you in the decision making process.
> The team has quickly built the components (less than 3 months)
> and proven the idea.
>
> The management is worried about our choice of three languages
> and has strongly suggested a relook at this strategy.
>
> The External Consultant (Subject Matter Expert) has suggested that -
> 0. since the individual components are implemented,
> the idea is partially proven
> 1. the language barriers will cause problems in integration
> and performance
> 2. the long-term success and reach of the product will be
> based on complete implementation in C++.
That's nonsense. Many succesful products are not implemented in C++, and
many products implemented in C++ are not successful.
> 3. The Visualizer will be implemented in OpenGL and C++ based modules
> will be quite easy to integrate.
> 4. C++ performance will be good if a ANN component is added later
> due to customer request.
> 5. Multi-language maintenance costs will be high
There is at least anecdotal evidence that switching languages from
Common Lisp (or other languages) to C++ have caused serious failures. I
would try to google for such evidence and collect it. The point is not
to prove that switching to C++ will definitely be desastrous, but that
it's by far not obvious that this is guaranteed to be a successful path
either.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Pascal Bourguignon
> Hello
>
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in
> 1. Prolog (enumerating device drivers, goal seek)
> 2. LISP (classical AI stuff, inference)
> 3. Erlang (server, communication and distributedness)
>
> The products we have used are
> 1. gprolog
> 2. clisp
> 3. Erlang/OTP
>
> The independent modules have been developed successfully,
> however we are unable to surmount the language boundaries
> and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
>
> The team has quickly built the components (less than 3 months)
> and proven the idea.
If you want to quickly integrate the components, just use sockets
(unix or even TCP/IP) to let them communicate, (with an ASCII
protocol!). Then you don't have any problem of FFI, and since the
modules runs in different processes, you get free multitasking. You
could even put these processes on different CPU to improve parallel
performance if it was needed.
Have a look at mod_lisp (language independant protocol), or swank
(slime) (perhaps the protocol is dependent on lisp, but swank runs on
a wide range of CL implementations and one scheme).
--
__Pascal Bourguignon__ http://www.informatimago.com/
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d? s++:++ a+ C+++ UL++++ P--- L+++ E+++ W++ N+++ o-- K- w---
O- M++ V PS PE++ Y++ PGP t+ 5+ X++ R !tv b+++ DI++++ D++
G e+++ h+ r-- z?
------END GEEK CODE BLOCK------
Paolo Amoroso
> There is at least anecdotal evidence that switching languages from
> Common Lisp (or other languages) to C++ have caused serious
> failures. I would try to google for such evidence and collect it. The
See for example:
http://wiki.alu.org/Evaluate_Lisp
Paolo
--
Why Lisp? http://lisp.tech.coop/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
Wade Humeniuk
>
> The team is disappointed, since the effort in learning the languages
> will be wasted. The 6 developers are from C/Java background.
>
This is by far the biggest problem your group now has. The team is
disappointed, an external consultant has passed judgment, management
is confused. This will require a political solution. Sorry to hear this
but this is a classic case of too many cooks spoiling the broth.
In an ideal world I would split off your programming team into a different
company, code the solution and sell it back at a signifigant profit.
If the company wishes to proceed with a parallel C++ solution, let them. I am sure
your multi-language approach will finish miles ahead of the C++ effort.
Wade
Richard J. Fateman
devfun...@gmail.com wrote:
> Hello
>
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in
> 1. Prolog (enumerating device drivers, goal seek)
> 2. LISP (classical AI stuff, inference)
> 3. Erlang (server, communication and distributedness)
>
> I need to present a case for the proposed solution, on the coming
> Monday.
1. I suspect that any
product that you distribute with CLISP falls under the GPL and
you therefore must give away your source code if you distribute
your program.
2. I don't know about Erlang; presumably Ericsson will sell/support
it; if you use an open-source version, there may be issues of
control of your company's code.
3. I don't know about gprolog with respect to licensing, but if
your use of prolog is fairly standard, there may be a simple solution...
A suggestion which has already been posted... find a compatible
lisp system
which supports prolog code (should be any, but some may be better
than others), and also a lisp allows commercial development on
top of it. I do not know if the erlang code can easily be redone in
lisp or C++ and linked to lisp.
A commercial lisp vendor may really be helpful in your argumentation,
because lisp vendors presumably have seen this kind of argument before.
Good luck
RJF
jayessay
> 1. Prolog (enumerating device drivers, goal seek)
> 2. LISP (classical AI stuff, inference)
> 3. Erlang (server, communication and distributedness)
>
> The products we have used are
> 1. gprolog
> 2. clisp
> 3. Erlang/OTP
>
> The independent modules have been developed successfully,
> however we are unable to surmount the language boundaries
> and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
Put the following into google:
1. prolog corba
2. lisp corba
3. corba erlang
I'm fairly sure this will solve your integration issues. Using CORBA
I've had at least the following all talking together via some set of
interface descriptions: Common Lisp, Java, Shell, C, C++, Python, Ada,
and VB(!!!). It just works. Mind you, corba is not exactly the "best
such glue ever" or some such, but it does just work. It may be more
than good enough for what you want.
However, note that you should be careful in your interface definitions
and be extra mindful that they are for distributed communication.
That may seem obvious, but it is amazing how many utterly hopeless
such descriptions I've seen that take the interface as if it were
simply a linked in FFI or something. Totally collapses under its own
weight.
You could also mix and match this a bit: There are Prologs in Common
Lisp (and some are _very_ good; certainly the offerings from Franz
(Allegro) andLispWorks are this). So, you could have these two very
tightly integrated and then just "corba" to and from Erlang.
> The External Consultant (Subject Matter Expert) has suggested that -
> 1. the language barriers will cause problems in integration
> and performance
Integration? almost certainly no. Performance? maybe, but probably not.
> 2. the long-term success and reach of the product will be
> based on complete implementation in C++.
Sounds like a risky business move unless you have huge amounts of
backing. But, whatever.
> 3. The Visualizer will be implemented in OpenGL and C++ based modules
> will be quite easy to integrate.
Various people have so integrated OpenGL and Lisp. They talk about it
here all the time. Also, there is a new effort afoot to make general
C++ integration with Lisp (tight integration ala FFI) straightforward
if not totally dummy level.
> 4. C++ performance will be good if a ANN component is added later
> due to customer request.
Common Lisp performance is typically on par with C++ code. There have
been various examples of this presented here in the past (some even
faster than the C++).
> 5. Multi-language maintenance costs will be high
Not necessarily. Often it can be much cheaper (as per your own
"experiement"): A _lot_ more can be done with a _lot_ less. OTOH,
square peg into round hole (C++ for most of what you have stated)
development and maintenance costs will almost certainly bury you.
> The team is disappointed, since the effort in learning the languages
> will be wasted. The 6 developers are from C/Java background.
Which probably goes a long way toward why they are so disappointed
with the "external consultant" (who presumably knows the subject
matter but is clueless about programming and thinks it is just a
detail). Why would you want to go back to something even more painful
than what you were doing before.
> Thanks in advance.
No problem.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
antoan...@hotmail.com
I am not famigliar with Erlang but here is my 2 cents :
1 Integrating Prolog and Lisp with Commercial Lisp implementation
as Allegro http://www.franz.com/products/packages/ or Lispworks
http://www.lispworks.com/products/features.html
would be piece of cake (Based on my humble experience).
Integrating with Erlang could be done through Corba
Both vendors have vast experience in such cases so contact them i'm
sure
that you will find painless solution.
2 Implementing whole project with C++ would be a huge mistake:
a You would have to start from scratch with disappointed
that's nothing like fresh start, very bad atmosphere.
b You said that 6 developers were from C/Java, learning another
language would couse a further delay.
c You have to recode everything in a less powerfull language
that is nightmare ,
3 You consultant sound questionable did he has any experience
with Lisp/Prolog ? Hiring the consultant with strong emphasis
on C++ and with small to nothong Lisp/Prolog wouldn't surprise
his words . He wants counsiling you again which will be barely
possible if he doesn't understand them .
So consider finding someone who does.
http://www.hypermeta.com/lisp-consulting.html
http://www.markwatson.com/consulting/
http://www.ssccorp.com/new/services.htm
Don't surrender you make wise choice with 3 languages
i'm sure that your project will be successfully integrated.
Antoan
Rob Thorpe
> devfun...@gmail.com wrote:
> > Hello
> >
> > Given the insistence of the members of the team to use the
> > best language for specific purpose, we have code that is
> > written in
> > 1. Prolog (enumerating device drivers, goal seek)
> > 2. LISP (classical AI stuff, inference)
> > 3. Erlang (server, communication and distributedness)
>
> >
> > I need to present a case for the proposed solution, on the coming
> > Monday.
>
> 1. I suspect that any
> product that you distribute with CLISP falls under the GPL and
> you therefore must give away your source code if you distribute
> your program.
Only if you distribute a modified CLISP does the GPL force you to
distribute your source code. You could distribute just the CL code
under any license.
Of-course, using lisp often involves modifying it though.
Rob Thorpe
I don't like to buck the general trend of the advice, but I'd pick one
language and implement the final version in that.
For example, if the program only needs one person to maintain it, it's
difficult to find someone who can program Prolog, CL and Erlang. If
you do it's likely that they won't be very knowledgable about all of
them. Even if there are two people it might be difficult from them to
understand the whole.
As others have mentioned, it should be easy to incorporate the Prolog
bits in another language. I'd convert the whole thing into either CL
or Erlang.
Of-course this depends on how long it is, if the bits to be converted
are only say ~3000 lines, then that's quite easy. If there's 30000
it's a much bigger job and it's probably worth working out how to stick
all the languages together instead.
Converting any of these languages into C++ will be hard.
There are several CL implementations that are faster than CLISP.
Joe Marshall
> Hello
>
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in
> 1. Prolog (enumerating device drivers, goal seek)
> 2. LISP (classical AI stuff, inference)
> 3. Erlang (server, communication and distributedness)
> The External Consultant (Subject Matter Expert) has suggested that -
>
> 2. the long-term success and reach of the product will be
> based on complete implementation in C++.
Huh? Did C++ get a garbage collector? This sounds stupid.
If you rewrote it all in one of the three original languages, you'd at
*least* be able to avoid 1/3 of the work.
> The team is disappointed, since the effort in learning the languages
> will be wasted.
I'm not surprised. Is it worth pissing off the developers? If they
were adamant about using the best language, I can't imagine they'd be
interested in using the *worst* (hmmm, although maybe Perl would be
worse).
> The independent modules have been developed successfully,
> however we are unable to surmount the language boundaries
> and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
What's the issue? It seems to me that the amount of effort needed to
communicate via pipes or sockets would be less than the amount of
effort to rewrite the whole thing in C++.
~jrm
Peter Seibel
That depends on whether you CL code uses any of CLISP's
implementation-dependent features. See the license file that comes
with CLISP for more information.
-Peter
--
Peter Seibel * pe...@gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
Adrian Kubala
> For example, if the program only needs one person to maintain it, it's
> difficult to find someone who can program Prolog, CL and Erlang. If
> you do it's likely that they won't be very knowledgable about all of
> them.
You really think so? It might be hard to find someone with 5 years'
commercial experience in all three, but a developer who knows one of
them very well should be able to pick up the others on the job,
especially since s/he already has interest and experience in learning
non-mainstream-languages. And since the OP said the modules were written
by C/Java people, it's at least possible for C/Java people to learn to
maintain them.
Rob Thorpe
Firstly, it requires someone with a particular skill to be able to
switch between several languages quickly anyway. I find myself
forgetting to prepend variable with "$" when switching from C to perl
for example. I can manage lisp easily since it's so different. Some
people aren't good at this though.
More importantly though, there's a different level of knowledge
required by a maintainance programmer than by the programmer writing
the intial implementation. Many programmer know a lot of C++, so they
can easily write programs in C++. However few programmer understand
all of C++, most of them seem to use different parts, some use only the
OO, some only the STL, others use boost. Some use algorithm, others
don't. This means that when you have a C++ program to maintain you
must preferably find a C++ programmer who actually knows C++. These
are not very commonly encountered. This happens in lisp too, I think
there are quite a lot of lispers who don't know CLOS.
The problem is multiplied when more languages are involved. Someone
could probably learn what they needed, but it would take a great deal
of time.Also, CL, Prolog and Erlang written by C and Java programmers
is going to be pretty wierd.
Writing things in obscure languages is a trick used by consultants to
gaurantee further work. One guy I know wrote his first consulting job
in Prolog, not because it was appropriate, but because so few people
know Prolog. When the company wanted changes to the software they had
to come back to him no matter what he charged because they couldn't
find another Prolog programmer. It's not a trick that should be
tolerated. He's also the only guy I know who knows Prolog, it's not a
commonly known language even in the UK.
Also, maintaining the build system will be very complicated. Different
versions of the various compilers and interpreters will conflict with
each other. It's quite likely the original combination will have to be
retained throughout the life of the program, maybe with some careful
changes.
As a sometime maintainance programmer I wouldn't touch this program
with a bargepole even if it was forced to fit together.
What all of this really depends on is the amount of work, if the OP has
~100000 lines written they should not throw them away, if they have
~10000 they should think about doing it another way.
ram...@bigpond.net.au
>
> > The External Consultant (Subject Matter Expert) has suggested that -
> >
> > 2. the long-term success and reach of the product will be
> > based on complete implementation in C++.
>
> Huh? Did C++ get a garbage collector? This sounds stupid.
It doesnt sound like the "Subject Matter Expert" is a language
expert.
--
Seek simplicity and mistrust it.
Alfred Whitehead
A witty saying proves nothing.
Voltaire
ram...@bigpond.net.au
> The External Consultant (Subject Matter Expert) has suggested that -
> 0. since the individual components are implemented,
> the idea is partially proven
Right
> 1. the language barriers will cause problems in integration
> and performance
Integration, well yes as you are finding.
> 2. the long-term success and reach of the product will be
> based on complete implementation in C++.
LOL !
At least he didnt suggest that you reimplement it in FORTRAN !
> 3. The Visualizer will be implemented in OpenGL and C++ based modules
> will be quite easy to integrate.
So would Erlang modules.
> 5. Multi-language maintenance costs will be high
True.
Ulrich Hobelmann
> Firstly, it requires someone with a particular skill to be able to
> switch between several languages quickly anyway. I find myself
> forgetting to prepend variable with "$" when switching from C to perl
> for example. I can manage lisp easily since it's so different. Some
> people aren't good at this though.
Well, if they can't deal with the ideosyncrasies of their paid-for PL,
they shouldn't be programmers!
> More importantly though, there's a different level of knowledge
> required by a maintainance programmer than by the programmer writing
> the intial implementation. Many programmer know a lot of C++, so they
> can easily write programs in C++. However few programmer understand
> all of C++, most of them seem to use different parts, some use only the
> OO, some only the STL, others use boost. Some use algorithm, others
> don't. This means that when you have a C++ program to maintain you
> must preferably find a C++ programmer who actually knows C++. These
That's a C++ problem, because the language is huge, complicated, and has
lots of pitfalls inbetween.
> are not very commonly encountered. This happens in lisp too, I think
> there are quite a lot of lispers who don't know CLOS.
But CLOS is quite compact to pick up decently. It doesn't have lots of
rules that commonly bite (does it?).
> The problem is multiplied when more languages are involved. Someone
> could probably learn what they needed, but it would take a great deal
> of time.Also, CL, Prolog and Erlang written by C and Java programmers
> is going to be pretty wierd.
If they are Java only coders so far and can't manage to learn CL,
Prolog, etc., they shouldn't do that job in the first place. That's a
thing the HR people should make sure; it's their job.
> Writing things in obscure languages is a trick used by consultants to
> gaurantee further work. One guy I know wrote his first consulting job
> in Prolog, not because it was appropriate, but because so few people
> know Prolog. When the company wanted changes to the software they had
> to come back to him no matter what he charged because they couldn't
> find another Prolog programmer. It's not a trick that should be
> tolerated.
Easy: don't buy their consulting if you don't like their language
choice. It's not a trick (well, maybe); it might just be the right
language for the job. Want to do Prolog in C??
> He's also the only guy I know who knows Prolog, it's not a
> commonly known language even in the UK.
Not Java-common. But the basics are easy to pick up, even if variable
casing is a bit weird, IMHO. There are (more than a couple) persons (in
a given country) who have seen and understood Prolog before (probably
most functional programmers would qualify). Hire those, and reject the
Java-only people.
> Also, maintaining the build system will be very complicated. Different
> versions of the various compilers and interpreters will conflict with
> each other. It's quite likely the original combination will have to be
Why would they conflict? You have components and interfaces. You
change the language implementation, the interface stays.
> retained throughout the life of the program, maybe with some careful
> changes.
Why that? Why would a program's behavior change suddenly just because
you update (not even replace) the implementation?
> As a sometime maintainance programmer I wouldn't touch this program
> with a bargepole even if it was forced to fit together.
Maybe you aren't the person to work on that project.
> What all of this really depends on is the amount of work, if the OP has
> ~100000 lines written they should not throw them away, if they have
> ~10000 they should think about doing it another way.
What's wrong with 10000 LOC spread over different components that are
each performing their job exceptionally (right tool for the job...)?
Would your prefer a monolithic C++ blob, just because "everybody knows
it?" How's that even a criterion for a program? Especially if the
current programs *work* and only need to be connected somehow (hint hint
sockets hint hint)? How much does it cost to develop a huge blob,
rather than writing some interfacing code for five or so components?
--
I believe in Karma. That means I can do bad things to people
all day long and I assume they deserve it.
Dogbert
Adrian Kubala
> More importantly though, there's a different level of knowledge
> required by a maintainance programmer than by the programmer writing
> program to maintain you must preferably find a C++ programmer who
> actually knows C++.
My personal experience is that it's the exact opposite. I learned PHP by
being asked to maintain an existing PHP project, and now I maintain some
Java servlet stuff and still don't know a thing about Java servlets.
It's possible because the entire codebase is there for a tutorial -- not
sure how to do something? Just immitate the existing code, and you won't
do a worse job than the person that wrote it. Of course you want to
start with small changes, read the reference manuals, and test your
understanding carefully, but it's possible.
On the other hand, if you're creating a project from scratch in a
language you don't know well, you're bound to make all kinds of terrible
design decisions and do things in unidiomatic, awkward ways -- that's
when you need experience.
Paul F. Dietz
> It's possible because the entire codebase is there for a tutorial -- not
> sure how to do something? Just immitate the existing code, and you won't
> do a worse job than the person that wrote it. Of course you want to
> start with small changes, read the reference manuals, and test your
> understanding carefully, but it's possible.
This style of programming is called 'cargo culting', I think.
Paul
Paul Griffioen
> Hello
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in ...
It's my experience that if management is worried, then they want to know how
much things are gonna cost. I would suggest to make your case a financial
one and be carefull with technical arguments because that tends to make
managers uncomfortable.
Paul
Rob Thorpe
> Rob Thorpe <robert...@antenova.com> schrieb:
> > More importantly though, there's a different level of knowledge
> > required by a maintainance programmer than by the programmer writing
> > the intial implementation. [...] This means that when you have a C++
> > program to maintain you must preferably find a C++ programmer who
> > actually knows C++.
>
> My personal experience is that it's the exact opposite. I learned PHP by
> being asked to maintain an existing PHP project, and now I maintain some
> Java servlet stuff and still don't know a thing about Java servlets.
> It's possible because the entire codebase is there for a tutorial -- not
> sure how to do something? Just immitate the existing code, and you won't
> do a worse job than the person that wrote it. Of course you want to
> start with small changes, read the reference manuals, and test your
> understanding carefully, but it's possible.
It depends on how idiomatic the program is initially.
For example, I was given to a C program to maintain a while ago. This
program:-
* Used no "file static" functions, all functions were global.
* Used three file static variables in the whole program. Stuff that
should be file static was just global, it contained hundreds of global
variables.
* Didn't use \t or \n for tabs or line feeds, but instead their ascii
equivalent chars.
* Used DWORDs, int and longs strangely (because the programmer though
ints were 16 bit on the system, but they were 32)
If I hadn't know how C worked, and which bits were hacks, I would have
got nowhere. This wasn't even written by a bad programmer, just a
fortran programmer writing C code as fast as possible with little
thought for maintainance. First versions are first stabs at the
problem, so they are by their nature pretty hacky. They can be very
disciplined of-course, but I'd expect them to be hacky more often.
Learning from the source is very dangerous.
> On the other hand, if you're creating a project from scratch in a
> language you don't know well, you're bound to make all kinds of terrible
> design decisions and do things in unidiomatic, awkward ways -- that's
> when you need experience.
In that case you should read a good book/tutorial on the language you
intend to use. And maybe read any free source you can find, judging of
course whether it works in an intelligent way.
Rob Thorpe
> Rob Thorpe wrote:
> > Firstly, it requires someone with a particular skill to be able to
> > switch between several languages quickly anyway. I find myself
> > forgetting to prepend variable with "$" when switching from C to perl
> > for example. I can manage lisp easily since it's so different. Some
> > people aren't good at this though.
>
> Well, if they can't deal with the ideosyncrasies of their paid-for PL,
> they shouldn't be programmers!
There are plenty of programmers who can deal with any amount of
idiosyncracy, but who can't do so immediately on switching language.
They need time to renormalize.
> > More importantly though, there's a different level of knowledge
> > required by a maintainance programmer than by the programmer writing
> > the intial implementation. Many programmer know a lot of C++, so they
> > can easily write programs in C++. However few programmer understand
> > all of C++, most of them seem to use different parts, some use only the
> > OO, some only the STL, others use boost. Some use algorithm, others
> > don't. This means that when you have a C++ program to maintain you
> > must preferably find a C++ programmer who actually knows C++. These
>
> That's a C++ problem, because the language is huge, complicated, and has
> lots of pitfalls inbetween.
The problem isn't unique to C++, although CL isn't so complicated, it's
still huge and compilicated.
> But CLOS is quite compact to pick up decently. It doesn't have lots of
> rules that commonly bite (does it?).
:) I don't know.
> > The problem is multiplied when more languages are involved. Someone
> > could probably learn what they needed, but it would take a great deal
> > of time.Also, CL, Prolog and Erlang written by C and Java programmers
> > is going to be pretty wierd.
>
> If they are Java only coders so far and can't manage to learn CL,
> Prolog, etc., they shouldn't do that job in the first place. That's a
> thing the HR people should make sure; it's their job.
There's a difference between learning a language in order to do a job
and writing it idiomatically. Probably, those asked to write the code
will consider their job done if the code works. It's unlikely that
they will write idiomatic lisp so soon after learning it.
> > He's also the only guy I know who knows Prolog, it's not a
> > commonly known language even in the UK.
>
> Not Java-common. But the basics are easy to pick up, even if variable
> casing is a bit weird, IMHO. There are (more than a couple) persons (in
> a given country) who have seen and understood Prolog before (probably
> most functional programmers would qualify). Hire those, and reject the
> Java-only people.
This is not the way hiring works. People are hired on their merits in
helping across several different projects. This means they're hired on
their general skill and their skill in well known languages like C++ or
Java. You cannot assume that the right people for the job are
available, they almost never are.
Learning the language on the job is not a recipe for good maintainance.
> > Also, maintaining the build system will be very complicated. Different
> > versions of the various compilers and interpreters will conflict with
> > each other. It's quite likely the original combination will have to be
>
> Why would they conflict? You have components and interfaces. You
> change the language implementation, the interface stays.
Have you ever tried to make this work in practice? Humans and the
systems they create aren't perfect. Components have bugs, people rely
on those bugs, then they get fixed. People forget how configuration
was done, people use no-standard interfaces that change between
versions. Versions of software report the same version when they're
really different versions (eg. the several MFCv4.2s).
All of this is much worse between languages, because the interfacing
doesn't get well tested.
> > retained throughout the life of the program, maybe with some careful
> > changes.
>
> Why that? Why would a program's behavior change suddenly just because
> you update (not even replace) the implementation?
In a perfect world it shouldn't, in the imperfect world we live in it
does.
Anyone who's ever used a compiler of any type will experience this, the
language changes throughout the versions of the compiler, even if it's
supposed to.
The problem is compounded the more compilers are involved.
> > As a sometime maintainance programmer I wouldn't touch this program
> > with a bargepole even if it was forced to fit together.
>
> Maybe you aren't the person to work on that project.
It's not a job anyone should be given. Probably the only way to ensure
the program continues working would be to never touch the interfaces or
the build system. It would take a great deal of effort to do anything
more. I'm sure anyone who's done maintainance work before will agree
with me.
> > What all of this really depends on is the amount of work, if the OP has
> > ~100000 lines written they should not throw them away, if they have
> > ~10000 they should think about doing it another way.
>
> What's wrong with 10000 LOC spread over different components that are
> each performing their job exceptionally (right tool for the job...)?
>
> Would your prefer a monolithic C++ blob, just because "everybody knows
> it?"
C++ is slightly more difficult to maintain than say C because everyone
writes in their own personal dialect of it. It would certainly be much
preferable to 3 different obscure languages, even if they're doing what
they're designed to do.
Maintainance is the most expensive part of the software life-cycle, so
more expense should be spared at development to make it simple. That
means writing everything in one language at all practical.
CL or Erlang might be a good choice for the OPs program, since bits of
it are already in those languages and the Prolog bits could be handled
in those languages.
> How's that even a criterion for a program? Especially if the
> current programs *work* and only need to be connected somehow (hint hint
> sockets hint hint)?
Try doing GC over sockets!
> How much does it cost to develop a huge blob,
> rather than writing some interfacing code for five or so components?
Who knows, even if it costs twice or three times as much it would
probably pay for itself in maintainance.
Ulrich Hobelmann
> There's a difference between learning a language in order to do a job
> and writing it idiomatically. Probably, those asked to write the code
> will consider their job done if the code works. It's unlikely that
> they will write idiomatic lisp so soon after learning it.
Yes.
> This is not the way hiring works. People are hired on their merits in
> helping across several different projects. This means they're hired on
> their general skill and their skill in well known languages like C++ or
> Java. You cannot assume that the right people for the job are
> available, they almost never are.
Well, you can always contract people for just one project. This is
being routinely done, I hear.
> Learning the language on the job is not a recipe for good maintainance.
Of course not. But if you're a company that has its competitive
advantage by always using appropriate tools, instead of C++/Java all the
time, then you'd better deal with hiring some more language-open
programmers. If the languages used often change, only hire on a project
basis.
>>> Also, maintaining the build system will be very complicated. Different
>>> versions of the various compilers and interpreters will conflict with
>>> each other. It's quite likely the original combination will have to be
>> Why would they conflict? You have components and interfaces. You
>> change the language implementation, the interface stays.
>
> Have you ever tried to make this work in practice? Humans and the
> systems they create aren't perfect. Components have bugs, people rely
> on those bugs, then they get fixed. People forget how configuration
> was done, people use no-standard interfaces that change between
> versions. Versions of software report the same version when they're
> really different versions (eg. the several MFCv4.2s).
Well, I've heard there are standard protocols like SMTP, FTP, HTTP, X11
and file formats like ogg, QT, avi, and various standardized codecs like
MP3, all with various differing implementations.
We aren't talking C interfaces here, but even something without static
type checking can and often should work, if tests are being done
correctly. It might be a good idea to write a prettyprinter or
validator first for a given protocol, depending on how complex it is.
> All of this is much worse between languages, because the interfacing
> doesn't get well tested.
See above. In-language you have either type-checks or the builtin
debugging aids, but between languages you can still check what's going
on. The internet works quite well.
>>> retained throughout the life of the program, maybe with some careful
>>> changes.
>> Why that? Why would a program's behavior change suddenly just because
>> you update (not even replace) the implementation?
>
> In a perfect world it shouldn't, in the imperfect world we live in it
> does.
> Anyone who's ever used a compiler of any type will experience this, the
> language changes throughout the versions of the compiler, even if it's
> supposed to.
Those are bugs and should be corrected on short notice, especially if
everybody works at your company.
All standard C, Lisp, Scheme implementations I know usually handle
standard code quite well. That's what test suites are for.
> The problem is compounded the more compilers are involved.
Maybe. But since you probably focus on just one for each language
anyway, behavior should be predictable. Otherwise, it's usually easy to
see what's going on and where the compiler works different from what
you're used to, probably throwing errors.
>>> As a sometime maintainance programmer I wouldn't touch this program
>>> with a bargepole even if it was forced to fit together.
>> Maybe you aren't the person to work on that project.
>
> It's not a job anyone should be given. Probably the only way to ensure
> the program continues working would be to never touch the interfaces or
> the build system. It would take a great deal of effort to do anything
> more. I'm sure anyone who's done maintainance work before will agree
> with me.
As with any project, interfaces should remain quite stable. For
upgrades/small changes an extensible protocol might make sense (maybe
versioned).
The world knows *many* protocols, and most of them work really well.
> C++ is slightly more difficult to maintain than say C because everyone
> writes in their own personal dialect of it. It would certainly be much
> preferable to 3 different obscure languages, even if they're doing what
> they're designed to do.
Oh the irony, or did you forget a not? Just because a technology or
tool isn't used by 90% of programmers out there doesn't mean it's
obscure (with that bad sound to it), or doesn't work fine.
People routinely use tools for jobs, that's how we got technology in the
first place.
> Maintainance is the most expensive part of the software life-cycle, so
> more expense should be spared at development to make it simple. That
> means writing everything in one language at all practical.
But why? I'd say that Unix could use more uniform interfaces in
general, but that doesn't mean you need one language for everything.
Components can communicate fine. There's CORBA, but there are other
possibilities too (XML, sexps, plain text).
> CL or Erlang might be a good choice for the OPs program, since bits of
> it are already in those languages and the Prolog bits could be handled
> in those languages.
It could, but a full, tested, standard Prolog implementation might have
a few advantages in maturity.
>> How's that even a criterion for a program? Especially if the
>> current programs *work* and only need to be connected somehow (hint hint
>> sockets hint hint)?
>
> Try doing GC over sockets!
Why do GC over sockets? If you need data on both sides, copy it. If
you copy stuff all the time in both directions, your interfaces maybe
aren't quite right.
>> How much does it cost to develop a huge blob,
>> rather than writing some interfacing code for five or so components?
>
> Who knows, even if it costs twice or three times as much it would
> probably pay for itself in maintainance.
If you ever get it working ;)
--
My ideal for the future is to develop a filesystem remote interface
(a la Plan 9) and then have it implemented across the Internet as
the standard rather than HTML. That would be ultimate cool.
Ken Thompson
Rob Thorpe
> > It's unlikely that
> > they will write idiomatic lisp so soon after learning it.
>
> Yes.
>
> > Learning the language on the job is not a recipe for good maintainance.
>
> Of course not. But if you're a company that has its competitive
> advantage by always using appropriate tools, instead of C++/Java all the
> time, then you'd better deal with hiring some more language-open
> programmers. If the languages used often change, only hire on a project
> basis.
If you can find such people, then that's fine. They're not exactly
common though, and they might cost you more than run-of-the-mill
programmers. This add to the cost of maintainance, and makes it more
sensible to clean the project up before starting maintainance.
To get a competitative advantage from using appropriate tools the
programmers must know how to use them well.
> Well, I've heard there are standard protocols like SMTP, FTP, HTTP, X11
> and file formats like ogg, QT, avi, and various standardized codecs like
> MP3, all with various differing implementations.
I wasn't talking about these standards, but rather about interfacing
bits of the same program together, which is a bit of a different thing.
Referring to the protocols you mention above, only SMTP and FTP are
really good examples, since they are open standards that work well and
compatibly between implementations. HTTP is similar, but so trivial
it's hard to get very wrong. X11 isn't really compatible between X
servers. Between 2000 & 2002 myself and some others tried to make a
system work where an application was held on a remote machine and
remote X logons used to access it. We tried 4 different X servers, but
none worked so in the end we had to give up. It's supposed to be a
standard, but it's been extended so heavily it may as well not be.
> We aren't talking C interfaces here, but even something without static
> type checking can and often should work, if tests are being done
> correctly. It might be a good idea to write a prettyprinter or
> validator first for a given protocol, depending on how complex it is.
Yes, you can invest a large amount of time writing tests to make sure
things glue together properly. It's concievable that this may be
better than just writing everything in the same langauge.
Let's say your plugging the system together with CORBA for example. If
you do find a problem then does anyone else actually care? If no-one
else uses the interface then probably not, so the program won't get
fixed.
> The internet works quite well.
> The world knows *many* protocols, and most of them work really well.
? Do we use the same internet! The internet I use certainly doesn't
work well at all. Much of the time it doesn't work properly unless you
use Microsoft IE, even then it doesn't work properly because your using
MSIE.
I get at least one incomprehendible error messages thrown up from a
webserver per day, and sometimes a dozen. Often because the DB
interfaces don't work.
Open protocols only work well when there's an overpowering economic
need to make them work, and/or no overpowering economic need to break
them.
> Those are bugs and should be corrected on short notice, especially if
> everybody works at your company.
Not the ones in the compilers, they're the problem. Besides, why
tolerate finding and fixing bugs in three different build systems when
you could be doing more useful work.
> All standard C, Lisp, Scheme implementations I know usually handle
> standard code quite well. That's what test suites are for.
C implementations certainly don't, try giving them the output of the
Scheme compiler Stalin and watch them turn to jelly. Ask Lisp
compilers how "supercede" is spelt. Just a couple of good ones I came
across in the last few weeks :)
> > The problem is compounded the more compilers are involved.
>
> Maybe. But since you probably focus on just one for each language
> anyway, behavior should be predictable. Otherwise, it's usually easy to
> see what's going on and where the compiler works different from what
> you're used to, probably throwing errors.
Yes, certainly only change one thing at once.
> Oh the irony, or did you forget a not? Just because a technology or
> tool isn't used by 90% of programmers out there doesn't mean it's
> obscure (with that bad sound to it), or doesn't work fine.
Really, I would say it makes it fairly uncommon at least.
(What's wrong with "obscure" I quite like it, it's a good word)
> > Maintainance is the most expensive part of the software life-cycle, so
> > more expense should be spared at development to make it simple. That
> > means writing everything in one language at all practical.
>
> But why? I'd say that Unix could use more uniform interfaces in
> general, but that doesn't mean you need one language for everything.
> Components can communicate fine. There's CORBA, but there are other
> possibilities too (XML, sexps, plain text).
If you want to put in the effort to make components communicate, then
yes, it can work fine. But when you only have a little code it's not
worth it. It might take say 500 lines of code to make a Lisp program
communicate significant date with one in another language (probably
most of it in the other language). And it will be slow compared to
just passing a reference to a place in memory.
So, if you only have 1000 lines in that other language you may as well
finish the job properly and rewrite that part in Lisp.
> > Try doing GC over sockets!
>
> Why do GC over sockets? If you need data on both sides, copy it. If
> you copy stuff all the time in both directions, your interfaces maybe
> aren't quite right.
I find GC quite useful. An large amount of data are passed around in
the high-levels of programs, behide struct and objects and things, so
its useful to have GC. If you decide to use several langauges then you
must be careful to clean up after yourself after passing data around.
Also, you have to declare the data types you pass around in all the
languages you must give them to.
> > Who knows, even if it costs twice or three times as much it would
> > probably pay for itself in maintainance.
>
> If you ever get it working ;)
I get the feeling you don't do maintainance :)
Ulrich Hobelmann
> I've snipped some bits and moved some bits ...
>
>>> It's unlikely that
>>> they will write idiomatic lisp so soon after learning it.
>> Yes.
>>
>>> Learning the language on the job is not a recipe for good maintainance.
>> Of course not. But if you're a company that has its competitive
>> advantage by always using appropriate tools, instead of C++/Java all the
>> time, then you'd better deal with hiring some more language-open
>> programmers. If the languages used often change, only hire on a project
>> basis.
>
> If you can find such people, then that's fine. They're not exactly
> common though, and they might cost you more than run-of-the-mill
> programmers. This add to the cost of maintainance, and makes it more
> sensible to clean the project up before starting maintainance.
Then just pay them $5 more an hour than the competition. This is not
McDonalds!
> To get a competitative advantage from using appropriate tools the
> programmers must know how to use them well.
Really, not McDonalds! Do you know any programmer in a Java shop that
doesn't know how to leverage Eclipse, or whatever (complex) frameworks
they use? How did they learn all that rocket science I wonder. It must
have fallen from the sky.
>> We aren't talking C interfaces here, but even something without static
>> type checking can and often should work, if tests are being done
>> correctly. It might be a good idea to write a prettyprinter or
>> validator first for a given protocol, depending on how complex it is.
>
> Yes, you can invest a large amount of time writing tests to make sure
> things glue together properly. It's concievable that this may be
> better than just writing everything in the same langauge.
Isn't glueing (or setting up and accessing libraries etc.) the easy
part? Once you have the structure it gets interesting...
> Let's say your plugging the system together with CORBA for example. If
> you do find a problem then does anyone else actually care? If no-one
> else uses the interface then probably not, so the program won't get
> fixed.
That's why you should use standard implementations that are maintained.
>> The internet works quite well.
>> The world knows *many* protocols, and most of them work really well.
>
> ? Do we use the same internet! The internet I use certainly doesn't
> work well at all. Much of the time it doesn't work properly unless you
> use Microsoft IE, even then it doesn't work properly because your using
> MSIE.
Even in my Windows times (one year of 98, one of XP) I've never used IE
at all. No big showstoppers here.
> I get at least one incomprehendible error messages thrown up from a
> webserver per day, and sometimes a dozen. Often because the DB
> interfaces don't work.
Yours, or the websites's? In the first case I'd look for alternatives,
in the latter one I'd mail the webmaster and look for other web
resources that do the same for me.
> Open protocols only work well when there's an overpowering economic
> need to make them work, and/or no overpowering economic need to break
> them.
True. Usually everybody profits from adhering to standards, that's why
we all still talk HTTP and NNTP, not MS-Web-protocol 2005. Notice that
MS's proprietary anti-spam email-extension didn't really get much notice
at all, due to being not openly implementable.
>> Those are bugs and should be corrected on short notice, especially if
>> everybody works at your company.
>
> Not the ones in the compilers, they're the problem. Besides, why
> tolerate finding and fixing bugs in three different build systems when
> you could be doing more useful work.
Good question. I'd use those systems that have endured more than a
couple of years and are mature in their use.
>> All standard C, Lisp, Scheme implementations I know usually handle
>> standard code quite well. That's what test suites are for.
>
> C implementations certainly don't, try giving them the output of the
> Scheme compiler Stalin and watch them turn to jelly. Ask Lisp
> compilers how "supercede" is spelt. Just a couple of good ones I came
> across in the last few weeks :)
That's what evaluating implementations is for. If you see that your
toolchain doesn't work with Stalin (and the vendor gives shit and you
can't change the vendor quickly and there's no gcc for your system or it
doesn't work either) use something else. Note that the OP has running
programs in all implementations they use so there aren't any problems as
the ones you mention here.
>> Oh the irony, or did you forget a not? Just because a technology or
>> tool isn't used by 90% of programmers out there doesn't mean it's
>> obscure (with that bad sound to it), or doesn't work fine.
>
> Really, I would say it makes it fairly uncommon at least.
> (What's wrong with "obscure" I quite like it, it's a good word)
Lisp is considered obscure my many, as are all functional languages.
Still, they are used in some contexts and work well.
This is different from tools that are used only by maybe 10 people...
>>> Maintainance is the most expensive part of the software life-cycle, so
>>> more expense should be spared at development to make it simple. That
>>> means writing everything in one language at all practical.
>> But why? I'd say that Unix could use more uniform interfaces in
>> general, but that doesn't mean you need one language for everything.
>> Components can communicate fine. There's CORBA, but there are other
>> possibilities too (XML, sexps, plain text).
>
> If you want to put in the effort to make components communicate, then
> yes, it can work fine. But when you only have a little code it's not
> worth it. It might take say 500 lines of code to make a Lisp program
> communicate significant date with one in another language (probably
> most of it in the other language). And it will be slow compared to
> just passing a reference to a place in memory.
Maybe, but it's probably fast enough and less than 500 lines. Either
way, with existing working components you save a lot of reimplementation
(that you don't know will work) and redebuggung. Getting sockets to
work is usually a given (I'd include that in "evaluating an
implementation").
> So, if you only have 1000 lines in that other language you may as well
> finish the job properly and rewrite that part in Lisp.
What if those 1000 lines translate to 30000 lines of *really* hairy C?
I'd rather hook it up a socket.
>>> Try doing GC over sockets!
>> Why do GC over sockets? If you need data on both sides, copy it. If
>> you copy stuff all the time in both directions, your interfaces maybe
>> aren't quite right.
>
> I find GC quite useful. An large amount of data are passed around in
> the high-levels of programs, behide struct and objects and things, so
> its useful to have GC. If you decide to use several langauges then you
> must be careful to clean up after yourself after passing data around.
> Also, you have to declare the data types you pass around in all the
> languages you must give them to.
Yes, you have to de/serialize, but that's not that hard with standard
metaformats (XML, sexps). GC IMHO is most useful for extremely dynamic
environments (Lisp), or when you don't know object lifetimes and can't
hide them in the API (construction/destruction, like Lisp's
with-open-bla). Debugging code in C almost never revolves around memory
issues for me.
>>> Who knows, even if it costs twice or three times as much it would
>>> probably pay for itself in maintainance.
>> If you ever get it working ;)
>
> I get the feeling you don't do maintainance :)
Haven't yet. Cleaning up the dirt others made could be hard I guess,
depending on how well it's tested or documented.
Julian Stecklina
> I wasn't talking about these standards, but rather about interfacing
> bits of the same program together, which is a bit of a different thing.
> Referring to the protocols you mention above, only SMTP and FTP are
> really good examples, since they are open standards that work well and
> compatibly between implementations. HTTP is similar, but so trivial
> it's hard to get very wrong. X11 isn't really compatible between X
> servers. Between 2000 & 2002 myself and some others tried to make a
> system work where an application was held on a remote machine and
> remote X logons used to access it. We tried 4 different X servers, but
> none worked so in the end we had to give up. It's supposed to be a
> standard, but it's been extended so heavily it may as well not be.
I booted an old HP-UX workstation (about 10 years old) some months
ago, telnetted (the HP-UX box has no ssh) to my laptop running a
current FreeBSD with X.Org and was able to use gaim with the HP's X
server which said it supports X11R5. I found that quite amazing.
Regards,
--
Julian Stecklina
(Of course SML does have its weaknesses, but by comparison, a
discussion of C++'s strengths and flaws always sounds like an
argument about whether one should face north or east when one
is sacrificing one's goat to the rain god.) -- Thant Tessman
jayessay
> Yes, you can invest a large amount of time writing tests to make sure
> things glue together properly. It's concievable that this may be
> better than just writing everything in the same langauge.
You have to invest that time in "tests/testing" even when using a
single language to see if the various modules "glue together properly"
(the interfaces are correct and used correctly). A single language
doesn't magically remove this need.
> Let's say your plugging the system together with CORBA for example. If
> you do find a problem then does anyone else actually care? If no-one
> else uses the interface then probably not, so the program won't get
> fixed.
How is this different than using "the interface" within the same
language from another module? At the level you are talking here, it
is the same thing.
> Ask Lisp compilers how "supercede" is spelt. Just a couple of good
> ones I came across in the last few weeks :)
Are you saying the standard spells it in different ways? I haven't
noticed that. If not, then if the compiler is conforming it better
spell it "supersede".
> > But why? I'd say that Unix could use more uniform interfaces in
> > general, but that doesn't mean you need one language for everything.
> > Components can communicate fine. There's CORBA, but there are other
> > possibilities too (XML, sexps, plain text).
>
> If you want to put in the effort to make components communicate, then
> yes, it can work fine. But when you only have a little code it's not
> worth it. It might take say 500 lines of code to make a Lisp program
> communicate significant date with one in another language (probably
> most of it in the other language).
Have you actually ever used this stuff? Maybe it is even more than
500 lines (maybe it's even thousands of lines if you have loads of
interfaces), but if 90% of it is generated by the IDL compiler for
whatever language is involved, who cares?
> And it will be slow compared to just passing a reference to a place
> in memory.
Probably. But if it accounts for less than a few percent total of
runtime, who cares? More to the point, _why_ should you care? If the
interface is designed half right, and the components are on the same
box, the performance is often more than good enough. If it isn't
then, well, you better not have those parts be distributed components
- whether in the same language or not.
> So, if you only have 1000 lines in that other language you may as well
> finish the job properly and rewrite that part in Lisp.
That might well be true, but it would be independent of any (pseudo)
concerns you have brought up here.
> > > Try doing GC over sockets!
This is a red herring if the interface has a sensible granularity,
i.e., the distributed objects should be "module level things" not the
typical "OO object level things".
> > Why do GC over sockets? If you need data on both sides, copy it. If
> > you copy stuff all the time in both directions, your interfaces maybe
> > aren't quite right.
This is basically on target, ime.
> its useful to have GC. If you decide to use several langauges then you
> must be careful to clean up after yourself after passing data around.
You're confused again into thinking that distributed <=> different
languages and fine grained distributed objects. Both implications are
untrue and would be even if you split the conjunction.
> Also, you have to declare the data types you pass around in all the
> languages you must give them to.
Sure, but in the case of CORBA (and other such "orb" things), it is in
_one place_: the interface description. The IDL compilers generate
all the "type information" as well as the marshalling/unmarshalling,
etc. for each language involved.
Adrian Kubala
> Adrian Kubala wrote:
>> Just immitate the existing code, and you won't do a worse job than
>> the person that wrote it.
> even written by a bad programmer, just a fortran programmer writing C
> code as fast as possible with little thought for maintainance.
I'm talking about maintaining solid production code, not refactoring a
hasty prototype. Obviously it's hard to write *better* code than the
code you're learning from. Nevertheless, your anecdote just seems to
emphasize my point that, e.g. Fortran programmers have no business
writing a program from scratch in C, but if it *had* been written by a
strong C programmer, there's no reason a Fortran programmer couldn't
have maintained it.
Pascal Bourguignon
Ulrich Hobelmann <u.hob...@web.de> writes:
> Lisp is considered obscure my many, as are all functional
> languages. Still, they are used in some contexts and work well.
Perhaps we should advertize the (un)structured procedural programming
style of lisp. Viva PROV & TAGBODY!
>> So, if you only have 1000 lines in that other language you may as well
>> finish the job properly and rewrite that part in Lisp.
>
> What if those 1000 lines translate to 30000 lines of *really* hairy C?
> I'd rather hook it up a socket.
1000 lines of lisp definitely translate to 10000 to 30000 lines of
hairy C. (Unless you're implementing Greenspun's Tenth Law, in which
case you just keep the original 1000 and add a 30000-line half-assed
lisp implementation, or if you're smart, you just a normal CL
implementation written in C (to be able to tell the manager: see I
just type make install on a system with only C installed, and it
compiles our "C" program)).
I'm in the process of rewriting yet another C program into CL and the
size reduction I see is impressive. It's not finished yet, I'll post
statistics when done.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In deep sleep hear sound,
Cat vomit hairball somewhere.
Will find in morning.
Rob Thorpe
> "Rob Thorpe" <robert...@antenova.com> writes:
>
> > I wasn't talking about these standards, but rather about interfacing
> > bits of the same program together, which is a bit of a different thing.
> > Referring to the protocols you mention above, only SMTP and FTP are
> > really good examples, since they are open standards that work well and
> > compatibly between implementations. HTTP is similar, but so trivial
> > it's hard to get very wrong. X11 isn't really compatible between X
> > servers. Between 2000 & 2002 myself and some others tried to make a
> > system work where an application was held on a remote machine and
> > remote X logons used to access it. We tried 4 different X servers, but
> > none worked so in the end we had to give up. It's supposed to be a
> > standard, but it's been extended so heavily it may as well not be.
>
> I booted an old HP-UX workstation (about 10 years old) some months
> ago, telnetted (the HP-UX box has no ssh) to my laptop running a
> current FreeBSD with X.Org and was able to use gaim with the HP's X
> server which said it supports X11R5. I found that quite amazing.
Interesting, it was HP-UX that we had the problem with.
We could connect to the app running on HP-UX remotely with X, the app
involved a 3D drawing interface. The lines and areas drawn by this
interface looked different on all the X servers we tried. Some parts
of drawings wouldn't show on some implementations.
The interesting thing was that every X server had a good go at
rendering it, even if it didn't succeed, none flaked out with errors.
Rob Thorpe
> Rob Thorpe <robert...@antenova.com> schrieb:
> > Adrian Kubala wrote:
> >> Just immitate the existing code, and you won't do a worse job than
> >> the person that wrote it.
> > It depends on how idiomatic the program is initially. For example, I
> > was given to a C program to maintain a while ago. [...] This wasn't
> > even written by a bad programmer, just a fortran programmer writing C
> > code as fast as possible with little thought for maintainance.
>
> I'm talking about maintaining solid production code, not refactoring a
> hasty prototype.
This was the production version.
> Obviously it's hard to write *better* code than the
> code you're learning from. Nevertheless, your anecdote just seems to
> emphasize my point that, e.g. Fortran programmers have no business
> writing a program from scratch in C, but if it *had* been written by a
> strong C programmer, there's no reason a Fortran programmer couldn't
> have maintained it.
The programmer in question had been writing C for more than 15 years.
Though he'd started with Fortran long before that. The problem was not
his lack of knowledge of C, but the speed with which the code was
written.
There's a lot of code around that uses the constructs of the language
it's written in badly. It not a good idea to rely on the code you
maintain to teach you, but it's certainly useful.
Rob Thorpe
> Rob Thorpe wrote:
> > I've snipped some bits and moved some bits ...
> >
> >>> It's unlikely that
> >>> they will write idiomatic lisp so soon after learning it.
> >> Yes.
> >>
> >>> Learning the language on the job is not a recipe for good maintainance.
> >> Of course not. But if you're a company that has its competitive
> >> advantage by always using appropriate tools, instead of C++/Java all the
> >> time, then you'd better deal with hiring some more language-open
> >> programmers. If the languages used often change, only hire on a project
> >> basis.
> >
> > If you can find such people, then that's fine. They're not exactly
> > common though, and they might cost you more than run-of-the-mill
> > programmers. This add to the cost of maintainance, and makes it more
> > sensible to clean the project up before starting maintainance.
>
> Then just pay them $5 more an hour than the competition. This is not
> McDonalds!
What I was talking about was the cost of maintainance, paying more
increases the cost of maintainance.
> > To get a competitative advantage from using appropriate tools the
> > programmers must know how to use them well.
>
> Really, not McDonalds! Do you know any programmer in a Java shop that
> doesn't know how to leverage Eclipse, or whatever (complex) frameworks
> they use? How did they learn all that rocket science I wonder. It must
> have fallen from the sky.
There are probably far more people using eclipse and other Java
frameworks than using the languages in question.
> >> We aren't talking C interfaces here, but even something without static
> >> type checking can and often should work, if tests are being done
> >> correctly. It might be a good idea to write a prettyprinter or
> >> validator first for a given protocol, depending on how complex it is.
> >
> > Yes, you can invest a large amount of time writing tests to make sure
> > things glue together properly. It's concievable that this may be
> > better than just writing everything in the same langauge.
>
> Isn't glueing (or setting up and accessing libraries etc.) the easy
> part? Once you have the structure it gets interesting...
In the context of the problem was updating the system after it's built.
Part of the problem is testing changes to the system once it's in
place.
> > Let's say your plugging the system together with CORBA for example. If
> > you do find a problem then does anyone else actually care? If no-one
> > else uses the interface then probably not, so the program won't get
> > fixed.
>
> That's why you should use standard implementations that are maintained.
?? How
Do you expect that the CORBA gprolog interface is well maintained, or
the CORBA Erlang interface. They may be, that's true and I wouldn't
want to offend the authors of such things by suggesting that I know
they aren't. But it's equally likely that they aren't, or that parts
of them aren't well tested. Connecting to a CORBA prolog program is
uncommon enough that there may only a handful of people who've ever
done it.
> >> The internet works quite well.
> >> The world knows *many* protocols, and most of them work really well.
> >
> > ? Do we use the same internet! The internet I use certainly doesn't
> > work well at all. Much of the time it doesn't work properly unless you
> > use Microsoft IE, even then it doesn't work properly because your using
> > MSIE.
>
> Even in my Windows times (one year of 98, one of XP) I've never used IE
> at all. No big showstoppers here.
You must not buy stuff online. I recently tried to buy car insurance
in the UK online, about half the sites would only work for IE.
> > Open protocols only work well when there's an overpowering economic
> > need to make them work, and/or no overpowering economic need to break
> > them.
>
> True. Usually everybody profits from adhering to standards, that's why
> we all still talk HTTP and NNTP, not MS-Web-protocol 2005. Notice that
> MS's proprietary anti-spam email-extension didn't really get much notice
> at all, due to being not openly implementable.
We'll see, I remember someone once said:
"I've survived IBM, I've survived Disco, I think I can survive
Microsoft."
A wise man replied to him:
"You have not yet done so."
> >> Those are bugs and should be corrected on short notice, especially if
> >> everybody works at your company.
> >
> > Not the ones in the compilers, they're the problem. Besides, why
> > tolerate finding and fixing bugs in three different build systems when
> > you could be doing more useful work.
>
> Good question. I'd use those systems that have endured more than a
> couple of years and are mature in their use.
Certainly, but even then you have problems.
> >> All standard C, Lisp, Scheme implementations I know usually handle
> >> standard code quite well. That's what test suites are for.
> >
> > C implementations certainly don't, try giving them the output of the
> > Scheme compiler Stalin and watch them turn to jelly. Ask Lisp
> > compilers how "supercede" is spelt. Just a couple of good ones I came
> > across in the last few weeks :)
>
> That's what evaluating implementations is for. If you see that your
> toolchain doesn't work with Stalin (and the vendor gives shit and you
> can't change the vendor quickly and there's no gcc for your system or it
> doesn't work either) use something else. Note that the OP has running
> programs in all implementations they use so there aren't any problems as
> the ones you mention here.
Evaluating implementations is all right if you're at the start of the
project, not half way down the line. Regarding the C compiler, the one
I had problems with was GCC, some versions of GCC seem to work with
Stalin and some don't.
I've seen it happen by a programmer going to a shop and buying MSVC v.6
and saying "I'm using this". I've also seen it happen that the
customer thinks something is really cool, like MS .NET and asks for
something implemented in that for that reason.
> >>> Maintainance is the most expensive part of the software life-cycle, so
> >>> more expense should be spared at development to make it simple. That
> >>> means writing everything in one language at all practical.
> >> But why? I'd say that Unix could use more uniform interfaces in
> >> general, but that doesn't mean you need one language for everything.
> >> Components can communicate fine. There's CORBA, but there are other
> >> possibilities too (XML, sexps, plain text).
> >
> > If you want to put in the effort to make components communicate, then
> > yes, it can work fine. But when you only have a little code it's not
> > worth it. It might take say 500 lines of code to make a Lisp program
> > communicate significant date with one in another language (probably
> > most of it in the other language). And it will be slow compared to
> > just passing a reference to a place in memory.
>
> Maybe, but it's probably fast enough and less than 500 lines.
It could well be much more. Remember, you have to redeclare each data
structure you're using across languages in both languages. The problem
grows in size as the program grows, though only steadily. Then theres
the issue of the build system, making all these programs dependent on
each other in the correct way without making build times huge.
"Probably fast enough" is far too casual a way to write the problem
off, in the future the program may have to shift significant data
between it's component parts. What you're doing is tantamount to
preventing this at the initial implementation stage.
> Either
> way, with existing working components you save a lot of reimplementation
> (that you don't know will work) and redebuggung. Getting sockets to
> work is usually a given (I'd include that in "evaluating an
> implementation").
>
> > So, if you only have 1000 lines in that other language you may as well
> > finish the job properly and rewrite that part in Lisp.
>
> What if those 1000 lines translate to 30000 lines of *really* hairy C?
> I'd rather hook it up a socket.
That would be a rather extreme case, I would keep it as it is in that
case.
If the converted code would be say 3000 lines, then I would certainly
convert it. It would save overall in time tinkering with three
different language implementations.
Besides, who mentioned C?
> >>> Try doing GC over sockets!
> >> Why do GC over sockets? If you need data on both sides, copy it. If
> >> you copy stuff all the time in both directions, your interfaces maybe
> >> aren't quite right.
> >
> > I find GC quite useful. An large amount of data are passed around in
> > the high-levels of programs, behide struct and objects and things, so
> > its useful to have GC. If you decide to use several langauges then you
> > must be careful to clean up after yourself after passing data around.
> > Also, you have to declare the data types you pass around in all the
> > languages you must give them to.
>
> Yes, you have to de/serialize, but that's not that hard with standard
> metaformats (XML, sexps).
Yes, but it could be very inefficient. I've sometimes written program
that pass around large tables between parts of the top-level via
pointers. This would be extremely tiresome to convert to text.
> GC IMHO is most useful for extremely dynamic
> environments (Lisp), or when you don't know object lifetimes and can't
> hide them in the API (construction/destruction, like Lisp's
> with-open-bla).
It's often useful higher up in programs. Emacs for example needs it
throughout, at least it would be difficult to implement Emacs without
GC at the top.
> >>> Who knows, even if it costs twice or three times as much it would
> >>> probably pay for itself in maintainance.
> >> If you ever get it working ;)
> >
> > I get the feeling you don't do maintainance :)
>
> Haven't yet. Cleaning up the dirt others made could be hard I guess,
> depending on how well it's tested or documented.
Have a go, you might like it :)
dev
I would sincerely like to thank all of the people who responsded to my
mail.
Here are the details of the discussion and decisions made.
1) It was pointed out that while each language will have merits and
strength,
however, together they would have both interop (performance) and
maintenance
issues.
2) It was stated that it is better to fight with the nuances of one
language,
rather than drool on the strength of each of them independently and
then face licensing issues, interop issues, performance issues,
support
issues , not to speak of the maintenance.
3) It was pointed out that today even Ericcsson does not use Erlang
for its
new product development. Why ?
4) The following products of Ericcsson are written in C++
TelORB
distributed RAM database, the base for the TSP application
server platform
TDMA-CDMA HLR
GSM-TDMA-CDMA mobility gateway
AAA server.
5) It was pointed out that clisp has GPL licensing and no money should
be
wasted on acquiring software licenses (eg. Franz)
6) It was pointed out that Prolog, CLISP are themselves interested in
C !
So, if there is a smart idea present eg. backtracking, we can see
the
implementation and use it in the code. There is no need to take
the complete
load of the language, since we don't want all the features any way.
7) RPC and message passing related weakness in Erlang can cause
security
vulnerability issues.
8) High performance in computation, high responsiveness in network
i/o,
aync and disk i/o is mandatory.
The performance slide related to yaws was mentioned and the
management
wondered why the world hasn't moved on to yaws by ditching
oh-so-slow Apache ?
8) The management has decided to organize 4 week long formal rigorous
training
in C++ and Template Programming. There will be sessions in
competency
building in tools like gprof, gdb, g++4, gcc4 etc.
9) The decision has been taken by the management and the tools to be
used are
- C++ (user land), g++4
- C (kernel land) gcc4
- STL
- Boost Library
There is no license fees to be paid to anybody.
10) All storage related standards have types defined in C and it makes
sense
to have the programmatic representation as close as possible to
the standard.
11) The management also highlighted that if the languages so far used
(prolog,lisp,erlang)
were so great then the capitalists would have grabbed them up
long time ago
and made lots of money by now by developing and selling products.
So, either the capitalists are fools or the current development
team !
It was also pointed out that Google does lot of work related to
information
retrieval, inference, distributed computing over thousands of
compute nodes
but does not use Erlang ! Why ?
In the final analysis, the project will proceed with the above made
decisions
and I will need to abide by these decisions if I am to keep my job.
Once again thanks to all the people on this list, who tried to help me
out.
thanks
Dev.
John
> 8) The management has decided to organize 4 week long formal rigorous
> training in C++ and Template Programming. There will be sessions in
> competency building in tools like gprof, gdb, g++4, gcc4 etc.
Wow. Surely a 4 week long formal course for multiple developers cost much
more than a few licenses.
> 11) The management also highlighted that if the languages so far used
> (prolog,lisp,erlang) were so great then the capitalists would have
> grabbed them up long time ago and made lots of money by now by
> developing and selling products. So, either the capitalists are
> fools or the current development team !
I think lisp isn't very popular because it lacks serious 3rd party library
support and its a pain in the ass to distribute a binary (i.e. non-source)
application.
You can fault C/C++/Java for a million different things and you'd be
correct. But at the end of the day, if you want a library in C/C++/Java
that does "X" then you can probably find several with a simple google
search. Add to that the fact that anyone with half of a clue (much less a
full clue) can compile-tar/jar to ship a "binary" and its not hard to see
why everyone goes that route. Its easier.
Lisp is cool and powerful but it takes a bit of time before you call it
"easy". Its hard to fault people for not wanting to invest that time.
Just my $.02
Pascal Costanza
> 11) The management also highlighted that if the languages so far
> used (prolog,lisp,erlang) were so great then the capitalists would
> have grabbed them up long time ago and made lots of money by now by
> developing and selling products. So, either the capitalists are fools
> or the current development team !
This statement is based on the assumption that the majority of people
(managers, capitalists, developers) make rational decisions. Note,
however, that your management's decision is not rational, i.e. not based
on an analysis what is best for the concrete project, but rather to just
follow the crowd. That's also what everyone else does. So, yes,
capitalists are fools, and your project is probably going to fail.
Pascal
--
OOPSLA'05 tutorial on generic functions & the CLOS Metaobject Protocol
++++ see http://p-cos.net/oopsla05-tutorial.html for more details ++++
Wade Humeniuk
Even before the consultant was brought in the decision to go
with C++ was already made. A consultant supplies the rhetorical
horsepower to deal with technical vocabulary and psychology.
The arguments you outlined in your post were supplied to management
by you and your very own team. It was freely offered up in the
guise of technical honesty, in effect shooting yourself in the
foot. I would strongly suggest that you and the team want to
use C++ for the very reasons outlined and are afraid of the
alternative. Management sensed doubt, fear and uncertainty.
You see this all the time here on c.l.l., people assert how
much they like Lisp , but.... they go on about how it is
not *fast* enough, not *popular* enough, not enough *libraries*,
too *old-fashioned*, blah, blah, blah.
Wade
Friedrich Dominicus
> Hello all
>
> I would sincerely like to thank all of the people who responsded to my
> mail.
Well every point in this messages were forseeable, you first visit
here has mad that clear, I'm in no way suprised. It was clear that
everything would be done to keep a "political correct" solution. Which
means. "use what everyone used if that fails you just can blame it on
bad luck".
>
> Here are the details of the discussion and decisions made.
>
> 1) It was pointed out that while each language will have merits and
> strength,
> however, together they would have both interop (performance) and
> maintenance
> issues.
Well quite a few pointed out the different way. Obviously that wasn't
even considered.
>
> 2) It was stated that it is better to fight with the nuances of one
> language,
> rather than drool on the strength of each of them independently and
> then face licensing issues, interop issues, performance issues,
> support
> issues , not to speak of the maintenance.
Well great so use a complete different langauge, how logical.
>
> 3) It was pointed out that today even Ericcsson does not use Erlang
> for its
> new product development. Why ?
This is untrue, and you can convince youself while visiting there web
pages.
>
> 4) The following products of Ericcsson are written in C++
> TelORB
> distributed RAM database, the base for the TSP application
> server platform
> TDMA-CDMA HLR
> GSM-TDMA-CDMA mobility gateway
> AAA server.
So what? They may use it for a reason. Maybe C++ has something to
offer to them in this area to let them choose it.
>
> 5) It was pointed out that clisp has GPL licensing and no money should
> be
> wasted on acquiring software licenses (eg. Franz)
Well you wasted your money on learnign C++ templates don't you?
>
> 6) It was pointed out that Prolog, CLISP are themselves interested in
> C !
> So, if there is a smart idea present eg. backtracking, we can see
> the
> implementation and use it in the code. There is no need to take
> the complete
> load of the language, since we don't want all the features any
> way.
So what?
>
> 7) RPC and message passing related weakness in Erlang can cause
> security
> vulnerability issues.
Proofs? Seems to me just prejudices. I can remember reading about
serious security problems in tons of C/C++ projects. But you are going
to use it. How logical.
>
> 8) High performance in computation, high responsiveness in network
> i/o,
> aync and disk i/o is mandatory.
>
> The performance slide related to yaws was mentioned and the
> management
> wondered why the world hasn't moved on to yaws by ditching
> oh-so-slow Apache ?
As said every reason is good enough to "support" their view.
>
> 8) The management has decided to organize 4 week long formal rigorous
> training
> in C++ and Template Programming. There will be sessions in
> competency
> building in tools like gprof, gdb, g++4, gcc4 etc.
good luck
>
> 9) The decision has been taken by the management and the tools to be
> used are
> - C++ (user land), g++4
> - C (kernel land) gcc4
> - STL
> - Boost Library
> There is no license fees to be paid to anybody.
Great there would have been no licences fee for
- SBCL
- CMUCL
- Ocaml
and and and be needed also
>
> 10) All storage related standards have types defined in C and it makes
> sense
> to have the programmatic representation as close as possible to
> the standard.
Then you should not use C++, you should use C!
>
> 11) The management also highlighted that if the languages so far used
> (prolog,lisp,erlang)
> were so great then the capitalists would have grabbed them up
> long time ago
> and made lots of money by now by developing and selling products.
> So, either the capitalists are fools or the current development
> team !
Yes the glorious mangages, there decision are obviously just rational
driven, I assume the dilbert stuff does not mean anything to them
Let me see the "merits" of C++. Wasn't there the Talingent stuff once
(the end-of-all-business-related-programming-problems, wasn't that
written in C++?, how successfull was it?)
If they just cared to read a few lines in some books, maybe the
"mythical man-month" would be a good choice, but so would certainly
others maybe those from Weinberg or whatever, but I guess that would
not have changed their "rational" decison either....
Friedrich
--
Please remove just-for-news- to reply via e-mail.
antoan...@hotmail.com
devfun...@gmail.com wrote:
> Hello
>
> Given the insistence of the members of the team to use the
> best language for specific purpose, we have code that is
> written in
> 2. LISP (classical AI stuff, inference)
> 3. Erlang (server, communication and distributedness)
>
> The products we have used are
> 1. gprolog
> 2. clisp
> 3. Erlang/OTP
>
> The independent modules have been developed successfully,
> however we are unable to surmount the language boundaries
> and connect Erlang to Prolog, Erlang to CLisp and CLisp to Prolog.
>
> The team has quickly built the components (less than 3 months)
> and proven the idea.
>
> The management is worried about our choice of three languages
> and has strongly suggested a relook at this strategy.
>
> The External Consultant (Subject Matter Expert) has suggested that -
> 0. since the individual components are implemented,
> the idea is partially proven
> and performance
> based on complete implementation in C++.
> will be quite easy to integrate.
> due to customer request.
> 5. Multi-language maintenance costs will be high
>
> will be wasted. The 6 developers are from C/Java background.
>
> Greatly appreciate if the more experience members of this group
> share their experiences and put forward the suggestions.
>
> I need to present a case for the proposed solution, on the coming
> Monday.
>
> Thanks in advance.
>
> thanks
> Dev.
Since the decision has allready been made I can't say you more than
Good Luck , but your project is probably doomed .
If i was in rewriting whole project in one language than
would certainly be one of the three allready used (you could save at
least
1/3 of the job) and the best one is certainly lisp at least for me.
Paolo Amoroso
> Here are the details of the discussion and decisions made.
[...]
> 3) It was pointed out that today even Ericcsson does not use Erlang
> for its
> new product development. Why ?
>
> 4) The following products of Ericcsson are written in C++
> TelORB
> distributed RAM database, the base for the TSP application
> server platform
> TDMA-CDMA HLR
> GSM-TDMA-CDMA mobility gateway
> AAA server.
At least until a few years ago, Microsoft used to have web servers
based on FreeBSD or other Unix systems.
> 6) It was pointed out that Prolog, CLISP are themselves interested in
> C !
> So, if there is a smart idea present eg. backtracking, we can see
> the
> implementation and use it in the code. There is no need to take
> the complete
> load of the language, since we don't want all the features any way.
Have a nice Greenspunning :)
> It was also pointed out that Google does lot of work related to
> information
> retrieval, inference, distributed computing over thousands of
> compute nodes
> but does not use Erlang ! Why ?
If they care, they can read the transcript of Peter Norvig's talk
"Large-Scale Web Services, and the Programming Languages that Build
Them" in the ILC 2003 proceedings. From what I understand, they have
so much hardware at Google that any language would do, possibly even
INTERCAL :) For the record, Python is used a lot at Google.
Paolo
--
Why Lisp? http://wiki.alu.org/RtL%20Highlight%20Film
Recommended Common Lisp libraries/tools:
- ASDF/ASDF-INSTALL: system building/installation
- CL-PPCRE: regular expressions
- UFFI: Foreign Function Interface
jayessay
> On 2005-09-05, dev <devfun...@gmail.com> wrote:
> > 8) The management has decided to organize 4 week long formal rigorous
> > training in C++ and Template Programming. There will be sessions in
> > competency building in tools like gprof, gdb, g++4, gcc4 etc.
>
> Wow. Surely a 4 week long formal course for multiple developers cost much
> more than a few licenses.
Probably a lot less.
> > 11) The management also highlighted that if the languages so far used
> > (prolog,lisp,erlang) were so great then the capitalists would have
> > grabbed them up long time ago and made lots of money by now by
> > developing and selling products. So, either the capitalists are
> > fools or the current development team !
>
> I think lisp isn't very popular because it lacks serious 3rd party library
> support and its a pain in the ass to distribute a binary (i.e. non-source)
> application.
Given the above, this is nonsense - i.e., if you license, say Allegro
(which you agree will be much cheaper than the "training") lib support
is for the taking and it is _trivial_ to distribute executables.
> Lisp is cool and powerful but it takes a bit of time before you call it
> "easy". Its hard to fault people for not wanting to invest that time.
Isn't this part irrelevant since the development team already was
using it???
jayessay
> 11) The management also highlighted that if the languages so far
> used (prolog,lisp,erlang) were so great then the capitalists would
> have grabbed them up long time ago and made lots of money by now by
> developing and selling products. So, either the capitalists are
> fools or the current development team !
Well, of course the "capitalists" are fools. That should go without
saying. Just look at all the "capitalist/investor" fools who poured
ludicrous amounts of money into the most ridiculous valueless nonsense
in the dot-bomb era. But then only another fool would expect these
people to be a good barometer of what's "good" or "bad" Hmmmm...
> It was also pointed out that Google does lot of work related to
> information retrieval, inference, distributed computing over
> thousands of compute nodes but does not use Erlang ! Why ?
They use Python instead? ;-)
BR
> So, yes, capitalists are fools, and your project is probably going to
> fail.
And guess were the blame for that failure's going to land? There's a
reason CYA is used a lot in business.
Pascal Costanza
>> 3) It was pointed out that today even Ericcsson does not use
>> Erlang for its new product development. Why ?
>
> This is untrue, and you can convince youself while visiting there web
> pages.
>
>> 4) The following products of Ericcsson are written in C++ TelORB
>> distributed RAM database, the base for the TSP application server
>> platform TDMA-CDMA HLR GSM-TDMA-CDMA mobility gateway AAA server.
>
> So what? They may use it for a reason. Maybe C++ has something to
> offer to them in this area to let them choose it.
Again, the statements about Ericsson's use or lack of use of Erlang are
based on the assumption that decisions are always rational elsewhere,
while it's more likely that development teams and their managers inside
Ericsson are trying to take shortcuts like everyone else does.
Ericsson is a large company, and such companies are made up of divisions
that are actually competing with each other. That's because such
companies start being their own economies with different divisions
fighting for larger budgets, etc. Just because some development teams
within Ericsson decide to use one particular language doesn't mean that
it's the company's "strategic" decision to do so. It may even be that
some or maybe even most development teams inside Ericsson don't know
about Erlang.
Pascal
P.S.: Dick Gabriel has a nice deconstruction exercise about managers and
software developers at http://www.dreamsongs.com/NewFiles/OutSourcing.pdf
Rob Thorpe
> Hello all
>
> I would sincerely like to thank all of the people who responsded to my
> mail.
>
> Here are the details of the discussion and decisions made.
Four points:-
* If you're going to use C++ avoid templates and operator overloading
if you possibly can, they cause all manner of wierd trouble.
* Don't think you can immitate bits of the clever things CLISP does in
your program. CLISP is written in a preprocessed dialect of C and all
the variable names are in german. It is very, very difficult to
understand. You can't copy it anyway, it's GPLed.
* Don't just copy the current programs to C++, since they will make all
kinds of wierd and subtle assumptions about object lifetimes.
* Don't think that large companies (especially large Scadanavian
companies) make coherent, high level decisions about the programming
languages they use (or anything else).
Lastly, try to be more polite.