XL Compiler Bootstrapped
descubes inputs: "An XL compiler bootstrapped two days ago (that means it compiled itself). Take a look at the project homepage to discover this language, designed around concept programming ideas, which is a sort of cross between C++, Lisp and XML. Much help is now needed to improve this rudimentary first iteration." One thing to note is that the C++ version of the compiler came in at 4500 lines, while the XL equivalent came in at some 2700 lines. This seems to imply that XL may be easier to work in than C/C++. Might XL someday be nudging the old workhouse out of a job in the near future?
Its a big mistake to confuse number of lines with a "better" language.
To me, "better" means to more readable, more maintainable, compiles to better object core, etc, etc.
Who cares how many lines it needs?
"It is difficult to catch a black cat in a dark room. Especially if there is no cat there." - Confucius
The web site seems to completely lack examples. It also isn't apparent how they do 'objects' (ie bundles of data and the functions that operate on them). It just looks like a very poor man's version of Python to me.
The bootstrap compiler is limited. For instance, it doesn't have a 'switch' statement, or dynamic dispatch ("virtual functions" in C++ terms). The name lookup is very constrained by what the C++ back-end can do for me at low cost ;-) So overall, there is still a lot of verbosity and ugliness that is imposed by these limitations.
Regarding header files, the compiler has an "import" statement. XL has modules, with separate files for module interface and module implementation. It's not fully functional in the boostrap compiler (for instance, the body is actually visible to the caller...)
-- Did you try Tao3D? http://tao3d.sourceforge.net
Lines of code is indeed a pretty bad abstraction for complexity. I always prefer a little verbosity (e.g. using more than one character for variable names, always use brackets for blocks, even though they are one line only). However, if an equivalent program takes up significantly less space in a particular language that can point out poor levels of abstraction in the other language. The general trend of new programming languages is that they reduce the amount of lines of code needed for programs (and, ironically, require more loc for hello world). Java is a good example of less lines of code and more functionality compared to e.g. C.
IMHO one of the major problems of modern programming languages is its reliance on ascii as the storage and editing medium. Most of the innovations in IDEs for example try to work around the fact that the program is stored in ascii by maintaining a parse tree of the entire source code. This allows for all sorts of on the fly transformations (refactoring) and presentations (e.g. uml diagrams). The problem with this approach is that the internal representation is richer than the external. This information is typically lost when you exit the IDE or requires hacks like putting stuff in comments so the compiler can ignore it (e.g. GUI editors). Many of the concepts you work with in an IDE do not exist in first class representations at the source code level.
Because things need to be typed in manually, many programming languages are full of syntactic sugar which aim to reduce the amount of typing. For example the distinction between for and while is that for requires less typing than the equivalent while for some special cases of while. Neither captures the concept of iteration very well. In some languages this is addressed with more syntactic sugar.
Syntactic sugar is a poor replacement for proper abstractions. Intentional progamming may be a way out. However, I have yet to see a convincing and insightful example. So far all I see is variations of lisp.
Jilles