Little is a statically typed, C-like scripting language

Hind sight is 20-20. The BitKeeper business had a good run, we were around for 18 years. It made enough that I and my business guy are retired off of what we made.

On the other hand, we didn't make enough for everyone to retire if they wanted to. We had a github like offering and it's pretty clear that we should have put a bunch of money into that and open sourced BitKeeper.

All I can say is it is incredibly hard to make that choice when you have something that is paying the bills. I tried to get Sun to do it with the BSD based SunOS and they wouldn't. And even though I had that vision for Sun, when it was my livelihood, I couldn't see the path to doing so.

Shoulda, coulda, woulda, my biggest regret is not money, it is that Git is such an awful excuse for an SCM. It drives me nuts that the model is a tarball server. Even Linus has admitted to me that it's a crappy design. It does what he wants, but what he wants is not what the world should want.

It says a lot that we have a bk fast-export and we can incrementally run that and get idempotent results. As in go from BK to Git on an ongoing basis, have two people do it in parallel and they both get bit for bit identical results. If you try and go the other way, Git -> BK, if you do it in parallel you get different results because Git doesn't store enough information, so BK has to make up the missing bits.

Git has no file create|delete|rename history, it just guesses. That's my biggest regret, I wish Linus had copied that part.

BTW, Linus switched to Git 2005. BitKeeper didn't give up and turn to open source until 2016. So we had a 10 year run after Git showed up where people still paid us.

It was good run, not many software companies get an 18 year run. I'm fine with it, would have liked to do more for my people.

Though, when we were shutting things down and I was bumming that I had not gotten retirement money for all of my people, one of them said something like "Dude, are you kidding me? My best friend barely knows his kids, he is out the door by 7am to fight Houston traffic and not home until close to 7pm. My commute is from my bedroom to my office down the hall. I've got to help my wife with the kids, I see the kids all day every day, my life is infinitely better than my friend's life and you gave that to me. You're fine."

I'm a wimp, I teared up a bit, that was the nicest thing he ever said to me. It's not just about money.

The SCCS weave was our secret sauce. Tichy did the world a huge disservice in his PhD about RCS (like that was worth a PhD, come on) where he bad mouthed SCCS's weave (without understanding it, or maybe he was spreading misinformation on purpose, he implied that SCCS was forward deltas where RCS is backwards deltas, see below for what that means).

When we were still in business, each new SCM that came out, we'd hold our breath until we looked at it and said "No weave!"

For those who don't know, the SCCS weave is how your data is stored. Most people are used to something like RCS which is patch based. For the RCS trunk, the head is stored as plain text, the previous delta is a reverse patch against the head, lather, rinse, repeat. Branches are forward deltas, so if you want to get something on a branch, you start with the head, apply reverse deltas until you get to the branch point and then forward deltas until you get to the branch tip. Ask Dave Miller how much he loved working on a branch of gcc, spoiler, he hated it. With good reason.

SCCS has a weave that is not aware of branches at all, it only knows about deltas. So you can get 1.1 in exactly the same amount of time as it takes to get head, it is one read through all the data. bk annotate (git blame) is astonishingly fast.

And merges are by reference, no data is copied across a merge. Try that in a patch based system. How many of you have been burned because you merged in a branch full of code that someone else wrote, and on the trunk all the new data from the branch looks like you wrote it, so you get blamed when there is a bug in that code? That's because your brain dead system copied code from the branch to the trunk (Git does this as well, that's what the repack code is trying to "fix", it is deduping the copies).

Weaves are the schnizzle, any SCM system that doesn't use them today is so 1980.

That was me as well, though I wrote it in perl4 and C. My version was called NSElite. The Solaris kernel was developed under NSElite, some stuff is here:

http://mcvoy.com/lm/nselite

2000.txt documents the first 2000 resyncs (think bk pull) of the kernel.

Avocet was what you got when you took all my perl code and handed it to the tools group and they rewrote it in C++ (which they later admitted was a horrible idea). The only thing of mine that they kept was smoosh.c and that was because not a single one of them had the chops to write that code (yeah, there was no love lost between me and the tools group).

BitKeeper is what Avocet could have been if Sun had not stopped me from doing any more work on NSElite (I was 1 guy who was coding circles around 8 tools people and they didn't like it). Shrug. C++ was just wrong, perl4 was just way faster to code in, and when I needed performance I coded in C. It's not my fault they picked the wrong way to go about things. (That, BTW, was the first time I ever personally saw that you really can have one guy who can do the work of 8, almost, but not quite a 10x programmer :-)

I've always been surprised that nobody has tried to take a "The Good Parts" subset of a big language (C++, Perl, etc.), codified/formalized it as its own language, and then attempted to popularize the new reduced language as a distinct effort/project/community to that of the original language.

One could release this "language" as a distribution of the inner language's compiler together with a wrapper (like C++ originally was to C), that, rather than adding features and compiling down, just analyzes the source file and errors out on use of forbidden syntax; or, if no forbidden syntax is used, just passes your code straight through to the inner compiler. A bit like a pre-commit-hook style checker, but a pre-compile-hook style checker.

I always thought upvar was kind of a cool feature, and allowed laser-specific targeting in places where you'd use a global otherwise in C. Is there any specific way that it's caused problems?

Hmm, I would disagree with this (quite strongly). Not that tcl doesn't have misfeatures (of course it does), but that `upvar` or `uplevel` are one of them.

Those commands effectively make any tcl function be able to operate as an f-expr (in old lisp parlance). Effectively (this is a simplification), an fexpr is a runtime macro, as opposed to the more traditional lispy compiletime macro.

Its what makes tcl feel more like a lisp-for-strings. Much of the truly horrible tcl code out there in the wild is from folks who try to use tcl as just another c-style scripting language.

Treat it more as a lisp, and it some of its inherent elegance shines through.

My $0.02 anyway ...

What's upvar?

Autovivification was one of the most painful features I’ve had to live with - in a large codebase it completely erases trust on any kind of defined() check and breaks all sorts of things unexpectedly.

Yet another horrible hack in Perl that for some reason is advocated for. Optional chaining / null propagation is a much, much better idea and shouldn’t have been any harder to implement.

I wrote most of my first source management system (NSElite, mentioned elsewhere in this thread) in perl4. I was learning perl at the time and my first and second efforts were awful. Perl really lets you get sloppy and create unmaintainable code.

My 3rd rewrite was very stylized and, I felt, maintainable. Which proved to be true as I had to fix bugs in it.

I did weird stuff like using $whatever as the index into the @whatever array.

But I digress. On the <>, Little has argv so you can do

int main(string argv[]) { int i; string buf; FILE f;

    if (defined(argv[1]) && streq(argv[1], "-") && !defined(argv[2])) {
        while (buf = <STDIN>) bputs(buf);
    } else {
        for (i = 1; defined(argv[i]); i++) {
            if (defined(f = fopen(argv[i], "r")) {
                while (buf = <f>) puts(buf);
                fclose(f);
            } else {
                 fprintf(stderr, "unable to open '%s'\n", argv[i]);
            }
        }
    }
    return (0);

but why would you want to when all of that is

int main(string argv[]) { string buf;

    while (buf = <>) puts(buf);
    return (0);

I mean, come on, that's cat(1) in 8 lines of code.

edit: I need to learn hacker markup. My code looks like crap.

I do find <> helpful. Perhaps if it were more descriptive? <ARGVorSTDIN> or similar?

It takes Little 3.53 seconds to find the 33rd number in the Fibonacci sequence recursively versus 30.23 seconds for Tcl8.6 on my i5-3320M.

Additionally, you can compile Tcl to machine code with TclQuadCode for up to a 66x speed improvement

I think there's a very real possibility that trying to do that I would dissolve from the embarrassment like the witch in The Wizard of Oz.

I think that is a giant design mistake since you are pushing the discovery of an error to some place else in the program, potentially very far from where the error occurred.

So there's `undef` and `null`? I wonder if there's a popular language that made the same mistake you could have learnt from :-P

You are kind of making my point. In tcl, they'd just give you "", but you can't tell the difference between "past the end of the array" or an element where you said

set foo[i] = ""

In Little you can tell, we'll return undef (your clear "error" though in these languages it is a supported feature, not an error). So we support the auto expanding array but give you that extra bit of info that you are past the end.

Well, it's that line of thought that prompted my question. It is, of course, a well-known source of problems in C that it will uncomplainingly dereference an invalid pointer.

Yep

Definitely depends on the definition, it seems every programmer and their mother has some toy programming language they poke at.

Will check,thanks.

Yes, that's probably part of the reason - apart from a fad-of-the-month kind of thing, and also due to genuine interest in the topics.