Re: (Prolog + LISP + Erlang) with integration issues versus C++

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.

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 :)

.

Relevant Pages

  • Re: CollabRx seeks brilliant engineers for an excellent e-science adventure
    ... belief that lisp programmers are smarter/better. ... Java or PHP programmers. ... a type of language that attracts a personality that meets my perceptions ...
    (comp.lang.lisp)
  • Re: I finally understand why Im not allowed to use Lisp
    ... language is powerful syntax and abstractions. ... I heard it when I used Lisp for ANYTHING. ... author of that bit of code was one of their /best/ programmers and I would do ... Management assumes that any software will have high maintenance costs. ...
    (comp.lang.lisp)
  • Re: subroutine stack and C machine model
    ... Hardly matters -- the type rules predate the standard by years. ... was defined as I have said to protect the profits of vendors. ... programmers and as such did a far more valuable service. ... how dare they come up with a common language definition so that people ...
    (comp.lang.c)
  • Re: (Prolog + LISP + Erlang) with integration issues versus C++
    ... 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. ... Ask Lisp compilers how "supercede" is spelt. ... That means writing everything in one language at all practical. ... My ideal for the future is to develop a filesystem remote interface and then have it implemented across the Internet as the standard rather than HTML. ...
    (comp.lang.lisp)
  • Re: Comparing Lisp conditions to Java Exceptions
    ... the first half of your posting was about a technical comparison ... > between Lisp conditions and Java exceptions. ... us what the language was. ... considering only the standard. ...
    (comp.lang.lisp)