L - the Little Language on Top of Tcl/Tk | Hacker News Reader

L - the Little Language on Top of Tcl/Tk

bitmover.com

11 pointsacqq8 comments

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);
}

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

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.

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

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.

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

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.

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 :)

Reply on news.ycombinator.com