L FAQ

 


 


 


Frequently Asked Questions

1. Why is it called "L", rather than a longer, more descriptive name?
2. L programs run too slowly. Will you make them faster?
3. How does L compare to C++? To Java? To Perl?
4. Do I need a run-time or virtual machine to run an L program?
5. Do I have to pay royalties on L?
6. Is it GPL'd? Do I have to distribute my source code in a product using L?
7. Can I modify the L compiler and/or base?
8. How are you making money on this?
9. What is "Swizzy.org", and what is its relationship to L?

1. Why is it called "L", rather than a longer, more descriptive name?

It came about like this: before the beginning of Swizzy, Peter was stewing about how he could make his life easier. One day he went to Martin and said, "What if we wrote a programming language? What would it be like? Well, imagine a language, let's call it L, that has such-and-such properties..." And from then on we just fell into the habit of calling it "L".

For a while we tried to think up different names, but in the end "L" was too attractive for a number of reasons:

  • It's easy to say and remember. L for language.
  • Imagine the slogans: "If you're tired of C++, go to L."
  • The language is L-egant.
  • It's fun to say some cool programming construct is "L-ish".
  • 'L' is a nice short prefix we could put on all the C++ classes that make up the L runtime.

2. L programs run too slowly. Will you make them faster?

We're going to do what we can, but the main thing you can do is to hand-code critical portions of your program in C++ (which is very easy to in-line with L). Moore's Law will do the rest.

What you can do. Most programs have a few routines that take most of the time. Identify those routines, and write some blazing fast in-line C++ code. Just put it right in your L code. Tweak it to your heart's content, even add in-line assembly if you want to. And continue to use L for the parts of the program where you won't notice the speed difference.

What we'll do. We will continue to optimize the compiler and runtime as we go along. But the primary goal of L is to make programming easier, and we won't sacrifice that noble goal.

What Moore's Law will do. Observe that if you change nothing, and L doesn't change, your program will still get faster. In fact, due to Moore's Law, your program will roughly double in speed every 18 months. I know it's not really a law, but it's been a great rule of thumb for 30+ years, and we're not slowing down.

3. How does L compare to C++? To Java? To Perl?

Please see the separate section devoted to this topic.

4. Do I need a run-time or virtual machine to run an L program?

No. Since L compiles to C++ code, you can compile that C++ code into a standalone executable file. You may choose to link in the L core statically (which makes the executable bigger), or dynamically (in which case the program will need to locate the shared library files when it runs.)

5. Do I have to pay royalties on L?

No. L is provided royalty-free and under a straightforward, permissive license. It's short, so it can't hurt you to read it here.

6. Is it GPL'd? If I make a product with L do I have to give away my source code?

No, it's not under the GNU Public Licnse. You may distribute your code with your product, or not. You may use L to build commercial products, provided you don't violate the simple terms of the Swizzy License Agreement.

7. Can I modify the L compiler and/or base?

Sure. Just be sure you obey the simple terms of the Swizzy License Agreement, found here. It basically says you can't sue us over the code we provided, that you won't claim you wrote the original code, and that you keep the license agreeement with the code.

If you make improvements or bug fixes, we'd appreciate hearing from you so we can look at integrating your changes into the next release of L. Try to do a nice job documenting the code so we can drop it right in.

8. How are you making money on this?

We're not making money on it, and we won't. L is free and will stay free. As industry professionals for several years, we've felt fortunate to be paid well while having so much fun, and that it's time we gave something back to the programming community.

9. What is "Swizzy.org", and what is its relationship to L?

We are Swizzy.org, a not-for-profit organization dedicated to making computers easier to use. L is our first major project, but not, we hope, the last.

 

 

L Compared to Other Languages

One way to learn about L is to see how it compares to a programming language you already understand. In this section we examine some popular languages and their similarities to L. Here's a really quick summary, with more detailed analyses afterward.

 
L
C/C++
Java
Perl
Original purpose
Desktop apps
O/S, drivers
Multimedia applets
Utilities
Simple syntax
Yes
No
Yes
No
C-like syntax
Yes
Yes
Yes
No
Large project development
Yes
Yes
Yes
No
Built-in data structures
Yes
No
No
Yes
Automatic memory mgmt
Yes
No
Yes
Yes
Powerful pattern matching
Yes
No
No
Yes
Easy pattern matching
Yes
No
No
No
Dynamic types
Yes
No
A little
Yes
In-line hand-coded C/C++
Yes
Yes
No
No
Ship an EXE (i.e. no runtime)
Yes
Yes
No
No
Platform independent
Not yet
No
Mostly
Yes
Make graphical UI apps
Not yet
Difficult
Yes
No
Create virtual built-in types
Not yet
No
No
No
Open, free source code
Yes
Varies
Varies
Yes
Small, friendly design team
Yes
No
No
Yes
   

 

 
C / C++
L
Computers for which language was originally developed.
A new PDP-11 in 1970 had 56Kb RAM, 400Mb hard drive, 1.25Mhz processor. Cost: $20,000+. A new PC in 2001 has 256,000Kb RAM, 40,000Mb hard drive, 2,200Mhz processor. Cost: about $2,000.
Original purpose of language

Enable programmer to interact with crude hardware. Develop O/S, drivers, and compilers. Time: Early 1970's.

Enable programmers to work faster. Develop applications for desktop and web. Time: Early 2000's.
Language syntax

Complex and difficult to learn; very widely recognized.

Simple, clear, powerful; inspired by the better parts of C++.
Memory management
Manual. Automatic.
Design features facilitate large-scale projects.
Yes Yes
Atomic types
char, unsigned char, short, unsigned short, int, unsigned int, long, unsigned long, bool, float, double, long long, pointers. No string. int, bool, float (double-precision), string, pattern, method, reference.
Built-in data structures
Array, struct, and class. No hash table, linked list, stack, or queue. Aggregate. Which combines the features of a class, struct, array, linked list, hash table, stack, and queue.
Pointing to objects
Strictly and statically typed, unsafe "pointers". Dynamically typed, safe "references".
Math and logical operations
Comprehensive set, including bit-manipulation. All C++ operators, plus a few extras.
Pattern matching (also known as "regular expressions")
None. Revolutionary, simple to use engine.
Compile-time type checking
Static type checking and enforcement; all connections must be known at compile time. Limited to checking variable names in prototypes.
Link-time binding
Strict and brittle. Loose and flexible.
Run-time dynamic types
Limited polymorphism; dynamic systems must be rolled from scratch (e.g. CORBA, COM) Very dynamic; simple run-time adaptation to different types.
Final product to customer
Executable file (EXE on Windows) Same
Platform independence
Yes, if you code carefully. Not yet. Linux and Mac support soon...
Standard I/O, string, etc.
Extensive but varies greatly across platforms. Limited at present, but platform-independent.
Standard data structure library
The "Standard Template Library" -- complete but tricky and bulky. Built-in "aggregate" structure handles almost all common tasks.
Speed of generated code
Fast. Just a bit slower than hand-optimized assembly language. As fast as you choose. Pure L code saves the programmer time but runs slower. Use in-line C++ to optimize speed-critical sections.
Object-oriented features
Grafted onto C. Workable but hard to get right. Brittle and tedious. Designed in. Powerful, easy to use features. Flexible, many conveniences.
Text macros
Yes. Not yet.
Compiles to
Processor-specific assembly language Platform-independent C++
Run-time introspection
Very limited Fully integrated.
Delayed code execution
No Yes ("executors"). Great for callbacks.
Code re-use
Possible but difficult / tedious (templates). Easy.
Recompile everything if one thing changes
Yes No
Order of static initialization
Undefined (i.e. essentially random). Alphabetical by class name.
Text string manipulation
Grafted on, clumsy, and/or error-prone. Built-in, easy, safe.
Throwing exceptions
Yes Not yet.
In-line code allowed
Assembly C++ (and assembly if you like)
Include header file only once
Requires #ifdef, #define, #endif Automatic (but overridable)
Conditional compilation
Yes Yes
Build graphical UI apps
Difficult. There's Win32, XLib, MFC, Gnome, and many many others. Which will you choose? L will eventually include a platform-independent graphical UI library.
Create virtual built-in types
No Soon. These could be used e.g. for transparent object shares across networks.
Compiler and run-time code
Usually proprietary and/or inscrutable. Open-source, free license, good code.
Language design team
Some committee somewhere Small, friendly, and responsive.

 

 
Java
L
Computers for which language was originally developed.
Handheld home-entertainment device, TV set-top box. The year: 1991. Desktop PCs and web servers. The year: 2001.
Original purpose of language
Platform independence. Remove unsafe and confusing features of C++. Develop multimedia (and later web) applications. Enable programmers to work faster. Develop applications for desktop and web.
Language syntax
Consistent, clear, somewhat tedious; inspired by the better parts of C++. Simple, clear, powerful; inspired by the better parts of C++.
Memory management
Automatic, including advanced garbage collection. Automatic. Currently reference-counted, but garbage collection is planned in.
Design features facilitate large-scale projects.
Yes Yes
Atomic types
char, byte, int, long, boolean, float, double, string, interface, object reference. int, bool, float (double-precision), string, pattern, method, reference.
Built-in data structures
Array and class are built-in. Libraries provide hash table, linked list, stack, or queue. Aggregate. Which combines the features of a class, struct, array, linked list, hash table, stack, and queue.
Pointing to objects
Statically typed, safe "object references". Dynamically typed, safe "references".
Math and logical operations
Comprehensive set based on C. Comprehensive set based on C.
Pattern matching (also known as "regular expressions")
Basic support in a library. Difficult to decipher. Revolutionary, simple to use engine. Named sub-patterns, recursion, readable syntax.
Compile-time type checking
Static type checking and enforcement; all connections must be known at compile time. Limited to checking variable names in prototypes.
Link-time binding
Fairly loose and flexible. Very loose and flexible.
Run-time dynamic types
Allows some dynamic binding using introspection, though cumbersome. Very dynamic; simple run-time adaptation to different types.
Final product to customer
Java VM code (.java file). Customer needs a separate run-time. Executable file (EXE on Windows). No run-time required.
Platform independence
Yes, in theory. In practice, it can be "write once, test everywhere." Windows only for now, but Linux and Mac are coming...
Standard I/O, string, etc.
Very extensive and powerful. Limited at present.
Standard data structure library
Not handy, but complete. Built-in "aggregate" structure handles almost all common tasks.
Speed of generated code
Varies greatly depending on customer's JIT. Adding optimized C/C++ code possible but cumbersome. As fast as you choose. Pure L code saves the programmer time but runs slower. Easily in-line C++ to optimize speed-critical sections.
Object-oriented features
Designed in. Simple, fairly easy to use. Brittle, limited conveniences. Designed in. Powerful, easy to use features. Flexible, many conveniences.
Text macros
No. Never. Not yet.
Compiles to
Java VM bytecode Platform-independent C++
Run-time introspection
Yes. Supported through library. Yes. Fully integrated.
Delayed code execution
No. Roll your own. Yes ("executors"). Great for callbacks.
Code re-use
Difficult. Statically typed, and no templates or macros to compensate. Easy. Dynamically typed.
Recompile everything if one thing changes
No No
Order of static initialization
(not sure...) Alphabetical by class name.
Text string manipulation
Built-in, fairly easy, safe. Built-in, very easy, safe.
Throwing exceptions
Yes Not yet.
In-line code allowed
No. C++ (and assembly if you like)
Include header file only once
What's a header file? Automatic (but overridable)
Conditional compilation
No. Yes
Build graphical UI apps
Yes. L will eventually include a platform-independent graphical UI library.
Create virtual built-in types
No. Soon. These could be used e.g. for transparent object shares across networks.
Language design team
Some committee somewhere Small, friendly, and responsive.
Compiler and run-time code
Usually proprietary and/or inscrutable. Open-source, free license, good code.

 

 
Perl
L
Computers for which language was originally developed.
UNIX workstations. The year: 1987. New computers of the day had 8Mhz CPU, 128k RAM. Desktop PCs and web servers. The year: 2001. New computers have 2,200Mhz Pentium IV CPU, 256,000Kb RAM.
Original purpose of language
Tool language, to enable efficient, powerful text processing. Develop utility and filtering tools. General language, to enable programmers to work faster. Develop applications for desktop and web.
Language syntax
Ugly, and a bit strange. Powerful for gurus, inscrutable to most people. Simple, clear, powerful. Writing readable code is easy.
Memory management
Automatic, reference-counted. Automatic. Currently reference-counted, but garbage collection is planned in.
Design features facilitate large-scale projects.
No. Yes.
Atomic types
float, string, regular expression, file, pointer. int, bool, float (double-precision), string, pattern, method, reference.
Built-in data structures
Array and hash-table are built-in, with features allowing use as list, stack, or queue. No struct or class. Aggregate. Which combines the features of a class, struct, array, linked list, hash table, stack, and queue.
Pointing to objects
Untyped "references" Dynamically typed, safe "references".
Math and logical operations
Comprehensive set based on C. Comprehensive set based on C.
Pattern matching (also known as "regular expressions")
Powerful, hard-to-use engine. NFA-based, thus easy to hang. No named sub-patterns or recursion. Inscrutable syntax. Revolutionary, simple to use engine. DFA-based, hard to hang. Named sub-patterns, recursion, readable syntax.
Compile-time type checking
None. Limited to checking variable names in prototypes.
Link-time binding
Very loose. In fact, it's not a link phase at all. Very loose and flexible.
Run-time dynamic types
Very dynamic. But limited support for complex types. Very dynamic; simple run-time adaptation to different types.
Final product to customer
Perl source file. Customer needs an interpreter to run it. Executable file (EXE on Windows). No run-time required.
Platform independence
Yes. Windows only for now, but Linux and Mac are coming...
Standard I/O, string, etc.
Very extensive and powerful. Limited at present, but platform-independent.
Standard data structure library
Built-in data structures handle almost all common tasks. Built-in "aggregate" structure handles almost all common tasks.
Speed of generated code
Slow, except the fast regular expression engine. Adding optimized C/C++ code possible but very cumbersome. As fast as you choose. Pure L code saves the programmer time but runs slower. Easily in-line C++ to optimize speed-critical sections.
Object-oriented features
Limited, grafted on, weird. Designed in. Powerful, easy to use features. Flexible, many conveniences.
Text macros
No. Not yet.
Compiles to
Interpreted, not compiled. Platform-independent C++
Run-time introspection
Yes. Fully integrated. Yes. Fully integrated.
Delayed code execution
Yes. Yes ("executors"). Great for callbacks.
Code re-use
Easy. Dynamically typed. Easy. Dynamically typed.
Recompile everything if one thing changes
No No
Order of static initialization
(not sure...) Alphabetical by class name.
Text string manipulation
Built-in, very easy, safe. Built-in, very easy, safe.
Throwing exceptions
No (I think). Not yet.
In-line code allowed
No. C++ (and assembly if you like)
Include header file only once
What's a header file? Automatic (but overridable)
Conditional compilation
No (but it's an interpreter anyway). Yes
Build graphical UI apps
No L will eventually include a platform-independent graphical UI library.
Create virtual built-in types
Yes. It's cool. Soon. These could be used e.g. for transparent object shares across networks.
Compiler and run-time code
Open-source, free license, interesting code. Open-source, free license, good code.
Language design team
Relatively small and accessible. Small, friendly, and responsive.