

L - the Little Language on Top of Tcl/Tk - acqq
http://www.bitmover.com/lm/L.html

======
luckydude
Wow, someone noticed it :)

If you're in a mood to give feedback what we're looking for are suggestions
that make it easier to review the code without making it really unpleasant to
write the code.

Here's an example of where we're borderline too pedantic (the whole
class_method(instance) instead of instance->method() )

class wtf { instance { public int x, y; }

    
    
            constructor wtf_new()
            {
                    self->x = self->y = 0;
            }
    
            public void wtf_incboth(wtf self)
            {
                    printf("%d,%d\n", ++self->x, ++self->y);
            }

}

void main(void) { wtf huh = wtf_new();

    
    
            wtf_incboth(huh);
            wtf_incboth(huh);
    }

~~~
acqq
Maybe I'm missing something but why not just:

    
    
        struct wtf { int x, y; }
    
        inc_both( wtf& t ) { ++t->x; ++t->y; }
        
        main() {
            r := wtf(); // x, y by default 0, string when exists, empty
            inc_both( r );
            inc_both( r );
        }
    

If you want to keep it C-like, don't do all that public/private things, keep
implicit creation of the struct etc.

    
    
        main() {
             r := wtf( 22, 33 ); // assigns to x and y
        }
    

Do you really need to hide variables or make real inheritance in a simple
language? "Information hiding" is overvalued and actually rarely really needed
on the single class level -- you have to care only about interfaces. Which are
probably going to remain too clumsy as long as you use header files (in my
humble opinion, I always liked Turbo Pascal (and Modula) modules, more
recently Go also manages to avoid headers).

void for return type was needed in ANSI C only because omitting it would mean
int in the code written in old K&R. You can make void as default when the
return type is not specified and keep the code nicer. Ditto for no parameters.
You'll get the slim appearance of K&R C code and the semantic would still be
clear to everybody as nobody would assume he's reading K&R C. Or would he in
your case, even with strings etc?

Btw C++ since recently has

    
    
        auto n = 1; // int
        auto s = "abc"; // char ptr
    

but IMHO Limbo idea is clearer and wouldn't introduce any problems (it's
really easy to add the new operators for "declare and assign" and the semantic
is obvious):

    
    
         n := 1;
         s := "abc";
    

And I thing I would also allow omitting ; before }.

~~~
luckydude
On the class thing, I bowed to pressure to have some sort of classes. And I
can see how we'll use them in our guis, each gui will be a class and we can
safely combine them in an uber gui w/o name space conflicts.

Could have just as easily been modules (all this crud is built on top of tcl
namespaces, it's just syntactic sugar to make things look nice).

We are not doing inheritance of any sort. L is not trying to be cool, it's
trying to be useful and easy to review.

On that note, the

    
    
           n := 1;
    

is shorter than

    
    
          int n = 1;
    

but which one reviews faster? My opinion, which matters a lot in this tiny
instance, is the second one reads faster, especially when you consider we flip
from C to L to tcl to shell. We're optimizing for the reader, not for the
writer. Much bigger win in our code-review heavy environment.

~~~
acqq
> L is not trying to be cool, it's trying to be useful and easy to review.

I appreciate that, but your compiler checks the types anyway, so later n .=
"abc" will be an error if I understand it, that's why you have them, so if the
code you review compiles without error you certainly won't catch any new error
when using eyes?

~~~
luckydude
The types help enormously, but so does being slightly verbose.

Lots of "reviews" happen in diffs. Much like Linus reads patches and modifies
the patches because he knows the source base, we read commit messages (which
are a patch) and the first review frequently happens in email.

Which doesn't address your point, I realize. Let's try this. Given the choice
between make life better for the writer (n := 1 is shorter) and the reader
(int n = 1 is more explicit), we pick the reader _every_ time. We have
multiple readers and we work in multiple languages. So while you are
absolutely right, n := 1 is just fine, and it is type checked and it is
"obvious", it will hiccup anyone coming from C (and is about to switch back to
C after this review).

We review _everything_. And the review is just part of it, when a support call
comes in we're in the source, looking at the code, trying to make the customer
happy with an instant fix (which we do a lot). Every second that we have to
spend swapping in tcl syntax is time where the customer is going "why am I
paying for this when I could use git for free?". And a few second later they
find out when get them a fix.

Time matters. Ease of reading yields shorter time on support and shorter time
on reviews.

That's my take, and that's how it works here. That may not be true for you.

------
acqq
Interesting idea, still a bit "stiff" for my taste. I'd allow a few more
"modern" tricks but still keep it mostly "C-like" (because it's obvious its
main goal was to be immediately readable and editable without the surprises to
the C programmers). For example,

    
    
      n := 1;
      s := "abc";
    

like in Go (and Limbo) as an allowed replacement for

    
    
      int n = 1;
      string s = "abc";
    

And then the same would function in the for loop:

    
    
       for ( i := 0; i < 10; i++ ) {
       }
    

(I'd also rather write:

    
    
      struct dirstats {
         int files, size, total_files, total_size;
      }
    

than in four rows member by member.)

------
p_h
Might be a bit late for this, but it's a real bitch to google help for a
programming language with a name like 'L'.

That's what I learned from 'R' anyways.

~~~
luckydude
Yeah, I know. I'm horrible with names, I named a product BitKeeper and the
company BitMover and people ask when the next version of BitMover is going to
be released.

We're looking for a fantastic jack-of-all-trades marketing person, can you
tell? We frigging need it, if I'm the best we've got we're screwed :)

