Slashdot Mirror

You need to handle pointers and references, google for pointer swizzling. Garbage Collection by Richard Jones and Rafael D. Lins explains some of the issues involved. Alexei Andresceu's Modern C++ Design gives a sample implementation. This is one of the tasks that reflection, aspect-oriented programming or a meta object protocol makes easier, otherwise you need to add a .serialize() method to each object.

Lisp has one of the best object-oriented paradigm implementation, Meta-Object Protocol among languages with both scripting and bytecompiling capabilities.

Scheme has been proved as a good language for GUI and configuration: GIMP, Sawfish, TeXmacs.

OCaml has all the power as Lips, just in syntax conviniect for many Java/C-poisoned brains to read faster. No wonder there are many real-world applications on it.

Haskell... I just love how it demonstrates that OOP is not everything (and even not enough) :)

Sun works for telecom industry - why not consider Erlang?

And don't ignore Mozart - it's multi-paradigm pradigm might be just what we all will thing as the best in 3-5 years.

The list is not complete, of course. And it's inspired by Functional Programming.

My main point here is: each of above languages, would it be in hands of Sun marketed instead of Java (with all that money invested to), would have quality of implementation much better than Java.

In fact, I am impressed how such poorly designed language as Java succeed so far on the market. It wouldn't without so much money behind. And without so many classes written by Sun to compensate the poor design of the core language itself.

Would Sun invest so much efforts and money to FP language then the result would be much better. Because quality is why FP matters.

Great thing about Lisp, is if you need to convert your communications, you can write Lisp against it to convert it while you convert your Lisp source.. easily.

I plopped an XSLT processor in front of it. Took minutes to implement. In the mean time, I was able to properly rewrite the XML producing code. So I had some flexibility in terms of patching the protocol quickly, while taking the weeks I needed to fix things right.

I plopped a Lisp processor in front of it. Took minutes to implement. In the mean time, I was able to properly rewrite the Lisp producing code. So I had some flexibility in terms of patching the protocol quickly, while taking the weeks I needed to fix things right.

the point is, XML IS descriptive, so long as you use good names.

the point is, Lisp IS descriptive, so long as you use good names.

If you use XML to develop a lower level protocol you end up with bloated 10k messages.

If you use Lisp S-expressions to develop a lower level protocol you don't end up with bloated 10k messages.

Besides, in Common Lisp you'll really appreciate MOP - Meta-Object Protocol. Much better than SOAP.

Trust me, I know well, actively use and actually love both Lisp *AND* XML.

• Why Functional Programming Matters
• Haskell: The Craft of Functional Programming Second Edition
• FAD: A Functional Analysis and Design Methodology
• Structure and Interpretation of Computer Programs
• Concepts, Techniques, and Models of Computer Programming
• CLOS Meta Object Protocol

So, still keeping some Java projects, I've decided to try something else. First I've tried was Python, which I used for while in OS automation scripts, but now I've tried to use it for a bigger scope: "servlets", UI, JMS-like messaging, XSLT, text processing, RDF, and finally in some AI stuff using FP, which is poor in Python, but at least it is there. By the way, OOP in Python is also far away from being perfect. It is slow on massive calculations, although it is fast enough for script -based OS automation, UI, "servlets" and XML processing (but not on huge files). it is dynamically typed and it has lazy evaluation - both very important features for messaging. Python is less known, comparing to Java, but its community is not really tiny as Perl and other *n*x hackers usually know Python.

After Python I've tried Erlang, Oz, OCaml, Haskell. I think Erlnag is ready for distributed messaging and for OS automation. The others are not - the lack of libraries. Although, each of them, Oz, OCaml and Haskell, has a very great potential if some big corp will do support. Any of these three may need just 10% of Java marketing to collect a crical mass and become recognized.

Before Java I had an experience also in C, Perl, Scheme, Lisp and Tcl, in few projects each. C is very "crashy" in you hands if you don't use it every day. Tcl does not handle well big enough apps. Perl is a "write-only" self-obfuscated lang. The only choice left is Lisp and Scheme. Lisp is very power for big standalone apps, Scheme is convinient for being embedded somewhere.

So, in the finals I've got Python, Erlang, Scheme and Lisp. Not a bad choice.

Coming back to UML. It does same help for Python programming as for Java. As for Lisp/Scheme and Erlang, I think that things like UML are too primitive to fit. On serious languages you need a serious math, and usually diagram is just an iluustration in the math article, not a whole article.

So, if you tired from kid pictures get the math in your hands :)

The "How to write Unmaintainable Code" article on the web is an excellent resource for documentation - much as "Web Pages that Suck is an excellent guide for web designers.

Your organisation - even if it's just 1 man and a dog - should already have a style guide in place. Don't have one? Well then it's easy, there are plenty of good ones on the Net, for Java, C++,Lisp,MATLAB, Ada and many others.

A good list of C and C++ styleguides is here. Just pick one. The important thing is to make sure everyone uses the same one, exactly which one is more a religious issue than anything else. That's an over-simplification, some really are better than others, but at least all the ones on that list have been tried, tested and peer-reviewed.

As for my own opinions, a few issues

• Make variable names meaningful. If you do this, then most of your comments will be metadata, e.g why you did something, and who and when a change was made, rather than what is being done. If you're doing something tricky or unusual, then having a pseudocode preamble can be worthwhile.
• If you can, try to use a relatively high-level language like Ada rather than a low-level one like C. But this is almost never under your control. The Javadoc auto-documentation tool is one of the biggest plusses that Java has over other languages - so if programming in Java, Use It!!

Why not just use Common Lisp? It has a lot of users, and it has garbage collection, and macros (like templates done right). It's object oriented, too.

It was updated in 1995, becoming the first standardized Object Oriented langugage

Nope: Common Lisp became a standard on December 8th, 1994.

Have a poke around the ALU site for more stuff, you should find a list of commercial projects here.
S.

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny the historical fact that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny the historical fact that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

Those who do not understand Unix are condemned to reinvent it, poorly.

It's what Henry Spencer said.

It's widely known.

There may be merit to your contention that not understanding Lisp results in reinventing it badly; Erik Naggum commonly makes that contention about Scheme, and I have no problem with the assertion that anyone building new systems that ignores the Common Lisp HyperSpec is likely doomed to reinvent parts of it less well than CLTL2.

That may mean that a more valid claim would be more like

Those who do not understand both Lisp and UNIX are doomed to reinvent parts of both, badly.

That still does not deny that what is in my .signature is what Henry Spencer said.

I've got a "cookie file" that populates email and news .signatures with random quotes; not all of them are true, at all. Some represent downright falsehoods; the Spencer quote isn't one of those.

If you are feeling so much feeling towards Lisp, then I'm wondering why you're not running Ocelot or SilkOS or NASOS or the rendition of DrScheme atop FluxOS, or, if you're a Common Lisp partisan, perhaps Genera.

You ask the wrong questions. Lisp is not used to solve common problems, people gravitate towards Lisp because their problems cannot be solved by the 'common' languages.

Anyway, take a look at:

• www.franz.com (the "applications" link)
• Lisp on the Deep Space 1 spacecraft
• Why Lisp?
• Lisp 'portal'

Given that elisp only runs inside emacs, that's trivially true. I haven't seen a program using xlib that wasn't `just meant' for extending the X Window System

In the _interesting_ sense, though, how do you claim that a mail reader, a news reader or a web browser are extensions of a text editor?

I won't address your other comments about Lisp, as they're either flamebait or chronically ill-informed. If anyone else is more interested in learning things than pissing on them (someone mentioned 'hackers'?) could do worse than start at the ALU web pages

-dan