|
|

|
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. |
|