[HN Gopher] Little is a statically typed, C-like scripting language
___________________________________________________________________
Little is a statically typed, C-like scripting language
Author : Thedarkb
Score : 152 points
Date : 2021-02-20 14:15 UTC (8 hours ago)
(HTM) web link (www.little-lang.org)
(TXT) w3m dump (www.little-lang.org)
| [deleted]
| mannykannot wrote:
| This language clearly avoids some of the run-time errors that can
| occur with C, but I would like to learn a little more about the
| remainder. For example, if you make an out-of-bounds assignment
| to an array, the array is grown to accommodate it (for +ve offset
| only, I assume) - but what about out-of-bounds retrieval?
| luckydude wrote:
| You get undef, that's part of the reason we added an undef
| concept (it's a value that isn't a value, though if you treat
| it like an int I believe it is zero, like a string and you get
| "").
| CyberDildonics wrote:
| 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.
| luckydude wrote:
| Without providing an example of how to do it better, I'm
| not sure I see your point. Yeah, I see the problem you
| point out.
|
| Consider
|
| char *p = 0;
|
| some complicated code that should have set p but didn't...
|
| char c = *p; // SEGV
|
| So do you have a way to push that error all the way back to
| wherever you think it should be pushed?
| CyberDildonics wrote:
| The person you replied to asked what the behavior was
| when you access an offset of an array that doesn't exist
| and you are giving me an example of dereferencing a null
| pointer.
|
| The array access should error out on the line that it
| happens.
|
| The dereference could print a line of the last
| assignment, but this isn't what was being talked about.
| luckydude wrote:
| I don't see the array access as any different than a null
| pointer dereference, in both cases you are asking for
| something that isn't there.
|
| In Tcl, stuff just gets auto expanded on assignment and
| returns "" (I think) on dereference. We chose to return
| undef. I'm not sure what the problem is.
| CyberDildonics wrote:
| I explained the problem already (the error does not show
| up where it actually happens).
|
| I also explained a huge difference between the two
| already (you know how large an array is and can detect an
| out of bounds access when it happens).
| [deleted]
| IshKebab wrote:
| 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
| luckydude wrote:
| There is no null, only undef. It's not a value, there is no
| value that means undef. We implemented by stealing the high
| order bit from the reference counter that tcl uses for
| garbage collection. If it is set, the variable undefined,
| if it isn't, it's a normal variable.
|
| I thought that was clever given that tcl's reference
| counter was signed and it only uses positive values. So we
| made it unsigned and got the bit for free.
| skybrian wrote:
| What happens if you call a Tcl function with an undef
| argument? Is this running Tcl code on a slightly
| different runtime, or do they interop in some other way?
| luckydude wrote:
| In Tcl, everything is a string. The string rep of undef
| is "" so Tcl gets "" but doesn't know that it is undef.
|
| So yeah, there is some sloppiness there. Tcl tends to use
| "" as sort of a null or undef so lots of stuff just works
| but no promises on that.
|
| This is sloppy simply because the Tcl die hards (are
| there any left?) refused to see the value of undef, a
| value for a variable that said there is no value. We used
| it all over the place, there clearly is value. They
| didn't see that, Little never got pushed back into the
| Tcl source base so Tcl never thought about undef.
|
| It is what it is, we live in an imperfect world. I tried.
| CyberDildonics wrote:
| What would you want a language to do if you try to access an
| array offset that doesn't exist except for give you a clear
| error?
| mannykannot wrote:
| 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.
| CyberDildonics wrote:
| That's actually C avoiding a run time error which is the
| opposite of what you asked.
| mannykannot wrote:
| You are right, it is avoiding a runtime error, but there
| have been, and continue to be, many cases where it leads
| to one. I suppose am asking about things that are
| undefined behavior in C.
| tyingq wrote:
| The repo is odd, it's hard to tell where the actual little-lang
| code is. I guess it's in the tclXXX directory?
|
| https://github.com/bitkeeper-scm/little-lang
| rbsmith wrote:
| All the files that begin with L in :
|
| https://github.com/bitkeeper-scm/tcl/tree/master/generic
| fuball63 wrote:
| Not to be confuse with lil, which is a small scripting language
| based on TCL: http://runtimeterror.com/tech/lil/
|
| I think this is a super interesting project. It reminds me what
| Groovy is to Java, but backwards. Groovy is a "looser" version of
| Java that compiles Java. Little is a "stricter" version of TCL
| that compiles TCL.
| narrator wrote:
| TCL had some bad features that kind of killed it. For example,
| "upvar" was a really bad idea. Bad features tend to kill
| languages over time. Everyone used to use Perl in the late 90s.
| It had too many bad features though, and nobody wanted to
| maintain those programs.
| nrclark wrote:
| 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?
| fuball63 wrote:
| I like it too because it's DIY pass by reference.
| luckydude wrote:
| We obviously liked it because upvar is how Little passes
| by reference. I don't know why someone thought upvar was
| bad, it is useful.
| csande17 wrote:
| What's upvar?
| luckydude wrote:
| http://www.tcl.tk/man/tcl8.5/TclCmd/upvar.htm
|
| That man page isn't the most clear. upvar gives you a way
| to modify a variable in the calling context (and I think it
| can go up more than one stack frame).
|
| It's a way to pass by reference rather than the default
| pass by value (how tcl passes is more complicated than that
| for performance but the default semantics are pass by
| value).
| derefr wrote:
| 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.
| luckydude wrote:
| I just liked what is in Little, it's enough like C that it
| is trivial for me to jump into it (tcl always took a half a
| day, I really dislike the tcl syntax), it's got enough of
| the shortcuts from perl that it is pretty terse, and credit
| where credit is due, syntax aside, tcl has a bunch of
| useful stuff, check out Little's switch(), that's tcl's
| switch.
| TimWillebrands wrote:
| For c++ there is orthodox c++ which is a subset of the
| larger language. Although as far as I know there is no
| linter/compiler.
| https://gist.github.com/bkaradzic/2e39896bc7d8c34e042b
| nanofortnight wrote:
| Is Little embeddable? This seems like a perfect scripting
| language for embedding into a larger C application.
| luckydude wrote:
| I would think so but I haven't done it. People embed tcl all
| the time, perl/tk is perl with a tcl interpreter embedded just
| so they can get at the tk part (gui stuff).
| dilawar wrote:
| is there a list of acomputer languagesn(dead or alive) and spoken
| languages (dead or alive)? Would like to see at what time
| computer languages are likely to outnumber spoken language.
| zabzonk wrote:
| Unsurprisingly, Wikipedia has both.
| rvense wrote:
| The highest estimate for number of natural languages I've seen
| is about 7,000 living. But I think you'd have to have a very,
| very restrictive definition of programming language for it to
| be lower than that.
| endergen wrote:
| Definitely depends on the definition, it seems every
| programmer and their mother has some toy programming language
| they poke at.
| mhd wrote:
| Most of which would probably more qualify as dialects in
| natural language terms. We're all mostly speaking broken
| Algol with some fancy loan words and maybe a slight lisp.
| 0xbadcafebee wrote:
| Why are there so many different languages that are almost the
| same except for one or two attributes? Why not make one language
| that can do everything?
|
| If you can make one language strongly typed, and one weakly
| typed, then you should be able to build one language which can do
| either/or, depending on a compiler flag. Then you simply decide
| before you start writing your code whether you want to write it
| weakly typed or strongly typed, and pass the correct compiler
| option.
|
| Take that same idea, but add in every language's quirks, and just
| enable/disable them. Then we wouldn't need to constantly reinvent
| languages, because we'd have one that can do everything.
|
| Otherwise we're going to keep re-writing the same damn thing for
| hundreds of years, and that just seems like such a pointless
| waste of effort.
| [deleted]
| arunix wrote:
| I think that's what Larry Wall was trying to do with
| Perl6/Raku:
|
| https://thenewstack.io/larry-walls-quest-100-year-programmin...
| BruceEel wrote:
| Compiles to Tcl byte codes
|
| Interesting, I didn't even know there was such a thing. Good to
| see <> and =~ live on.
| simias wrote:
| =~ is nice and convenient but I really don't think <> was worth
| bringing back. I'm sure people who never used Perl could figure
| out what `buf =~ /${regexp}/` does, but I wonder if they'd be
| able to figure out the `while (buf = <>)`.
|
| Perl has a lot of good ideas and things I find myself missing a
| lot when I use Python or JS (autovivification being probably
| #1) but IMO these one or two symbol magic variables would
| generally be improved if they were more descriptive, with maybe
| one exception for $_/@_.
|
| Although I must admit reminiscing about this made me realize
| how much I miss Perl now that I'm forced to use Python for
| work.
| tyingq wrote:
| I do find <> helpful. Perhaps if it were more descriptive?
| <ARGVorSTDIN> or similar?
| simias wrote:
| Yeah to be clear it's not the functionality that bothers
| me, it's just the syntax. Ideally since it's not even a
| proper variable since it changes after reading it should
| probably look like a function call.
|
| These ultra terse shorthands make some sense in the shell
| because it's meant for interactive, write-only commands but
| a scripting language should be a little more verbose and
| consistent IMO.
| Spivak wrote:
| There's a balance because people really seem to like ? as
| null coalescing, => for lambdas =~ for regex match, etc..
|
| I think <> as a fancy readline and _ as a
| default/throwaway variable does really improve
| readability and lowers the mental load of understanding
| programs.
| luckydude wrote:
| I'm a huge fan of preserving knowledge and building on
| it. Most people, at the time at least, knew what
|
| while (buf = <>)
|
| did. So I didn't want to invent a new syntax, there is
| way too much of that going on, I like C, I like perl,
| pull the useful stuff from each and move on.
|
| I freely admit it's not how everyone would do it.
| derefr wrote:
| In Ruby it's called ARGF (https://ruby-
| doc.org/core-2.7.1/ARGF.html) -- which, if not perfectly
| descriptive, is at least evocatively similar to ARGV.
|
| If you're already aware that ARGV exists, you'll guess that
| ARGF might be used in relation to it, and so when writing a
| CLI program that uses ARGV, you might wonder if ARGF could
| simplify your code and look up what it is/does.
| jiofih wrote:
| 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.
| Tade0 wrote:
| I originally read it as "Life is..." and thought "that's an
| interesting take on things".
| slazaro wrote:
| Make it a T-shirt, the fake-deep tone for a nonsensical
| statement is kind of ironic/cool.
| swagonomixxx wrote:
| > undef(argv[1]); // left shift down the args
|
| Can someone explain what this does? Is this some Perl or Tcl
| thing? Unfortunately I've never used either :)
| tyingq wrote:
| It's not a Perl thing. In Perl, that would set argv[1] to
| undef. It would not delete or left-shift @ARGV. There is a
| delete() function that acts similarly, but is discouraged to
| use on regular arrays. Shift() would be more appropriate in
| this case.
|
| Given the context, in little-lang, it appears to delete argv[1]
| and shift all of the right of that down, such that argv[2]
| becomes argv[1] and so on. That's so that the the _" while (buf
| = <>)"_ construct used right below it doesn't process the regex
| as if it were a file to "grep" through.
|
| In Perl, you would typically do it this way...
| if (!defined(my $regex=shift(@ARGV))) { die("usage:
| grep regexp [files]"); }
| luckydude wrote:
| I'll grant you it is sort of weird. I think that's a perl
| thing, we just copied how they did it.
|
| undef is both a function and a (non) value. It is the main
| reason Little never got pushed back into tcl, the tcl crowd
| hates the idea that there can be a value for a variable that is
| undefined. I found that very useful, for example, undef is the
| error return from any function. Just made sense to me, didn't
| make sense to the Tcl people.
| vram22 wrote:
| Has any one else noticed that programming-language-topic threads
| on HN seem to come in batches, sometimes? I'm not complaining. I
| like it, since I am a language fan, though not an implementer or
| lawyer. I have seen this phenomenon at least a few times in the
| last few years. (Did not check much during Covid.)
| JNRowe wrote:
| I've been enjoying this series of "Breakfast With Forth Week",
| best one yet.
|
| It had left me wondering what had caused it. There was a thread
| a few weeks ago where the old guard were describing an actual
| attempt to game the system, and I wondered if we were seeing a
| version of that being played out.
|
| https://news.ycombinator.com/item?id=25787374
| rurban wrote:
| I really like the syntax. But it should be compiled to lua, not
| tcl.
| luckydude wrote:
| Well the compiler is open source, have at it :-)
|
| Personally, I would _love_ a gcc --little dialect complete with
| a String type (and others) that is garbage collected and auto
| resized just like tcl /Little. With all the other Little
| goodness in there. Man, that would make C super pleasant. And
| it wouldn't be a new syntax like Go/Rust/whatever.
| mastrsushi wrote:
| This sort of reminds me of the old MUD VM language Pike
| https://pike.lysator.liu.se/
| luckydude wrote:
| I remember Pike, I looked at it. It was too far away from C for
| me. I'm a died in the wool C programmer (I started as a kernel
| programmer and formed some strong opinions there). I get that C
| is not for everyone but for me, it's enough of a language to do
| what I want and not filled with this, that, and the other
| kitchen sink.
|
| So Little looks a lot more like C than Pike does. And I like it
| that way. It's not for everyone but C programmers will probably
| like it.
| forgotmypw17 wrote:
| this is amazing, like a dream come true!
| asicsp wrote:
| http://www.little-lang.org/why.html is pretty interesting
|
| > _We (BitKeeper folks) did our GUI interfaces in Tcl /Tk years
| ago because it meant we could have one gui person and get the
| same gui tools on Windows, Mac, Unix, and Linux._
|
| > _While some of us could switch from C to Tcl easily, our
| pointy-haired boss could not, he 's mostly C and would lose about
| a half a day to get back into Tcl._
|
| > _Success was realized when one of our engineers, who is not a
| Little fan, fixed a bug in a patch that flew by in email without
| realizing it was Little instead of C_
| luckydude wrote:
| Wow, just noticed this. I'm the guy who paid for Little, a bunch
| of other people did all the work.
|
| I'm surprised to see it getting some attention but happily so.
| Little is what I'd like C to evolve towards, there is a lot of
| useful (to me) stuff in the language.
|
| I'll wander through the comments and reply where I can.
| amacbride wrote:
| Avocet (CodeManager) ruined me for other source control systems
| for years and years -- I still look back on it fondly.
| luckydude wrote:
| 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 :-)
| rdpintqogeogsaa wrote:
| I just wanted to say thank you for believing in the SCCS weave
| when making BitKeeper. It is an incredibly elegant design
| (though I've failed to properly implement it myself yet).
| luckydude wrote:
| 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.
| froh wrote:
| How does dcfs weave compare or relate to what pijul.org is
| doing?
|
| Some recent discussion of pijul on HN:
|
| https://news.ycombinator.com/item?id=24592568
| luckydude wrote:
| It's based on patches. I'm perhaps not going to win any
| friends, but I think that is ill-advised. Patches are
| great for emailing around, they are a horrible idea for
| an SCM.
|
| Perhaps I need to write up how weaves work in more
| detail. Once you get that, you won't want an SCM based on
| anything else.
| rdpintqogeogsaa wrote:
| By all means, please do. There's a severe lack of
| material.
| marktangotango wrote:
| I'm curious if you've written about the decisions around
| licensing that essentially killed the bitkeeper business by
| inspiring Linus to create git? What are your thoughts around
| that today?
| luckydude wrote:
| 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.
| luckydude wrote:
| 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.
| JNRowe wrote:
| Now that all _that_ isn 't so raw, I'd love to know how you
| felt about the other contenders that were floating about at
| the time. Were any of them doing things you wanted to see
| in BK?
|
| I can't be the only one who'd be interested in your views
| on the general developments for such important tools of our
| trade. Have you written about it anywhere? I'll pre-order
| "Larry walks us from SCCS to the git monoculture".
| luckydude wrote:
| Actually I was part of an SCM conference put together by
| Facebook and Google recently. People are starting to
| think about what happens after Git.
|
| Unfortunately, even now, it seems that there is a lot
| catching up to BK still to be done. To be fair, we had
| kernel level programmers working on it, we don't think
| anyone will pick up our code, you pretty much have to be
| a top 1-2% programmer to work on it, it's all in very
| disciplined C, people don't seem to like that any more.
|
| So far as I know, BK is the only system that gets files
| right, we have a graph per file, everyone else has a
| single graph per repository. The problem with that is the
| repository GCA may be miles away from the file GCA; BK
| gets that 100% right, other systems guess at the GCA.
| Graph per file means each file has a unique identifier,
| like an inode in the kernel. So create/delete/renames are
| actually recorded instead of being guessed at. SCM
| systems shouldn't guess in my opinion (actually in anyone
| with a clue's opinion, would you like it if your bank
| guessed about your balance? Of course not, so why is
| guessing OK in an SCM? It's not). Graph per file means
| that bk blame is instant no matter how much history you
| have.
|
| BK is the only system that even attempts to get sub-
| modules (we call them components) right. Where by "right"
| I mean you can have a partially populated collection and
| you get identical semantics from the same commands
| whether it is a mono-repo or a collection of repos.
| Nobody else has anything close, Git sub-modules turn Gits
| workflow into CVS workflow (no sideways pulls).
|
| I tried my best to show what we did in BK at that
| conference, I have no idea if they will swipe any of it.
| It's not like BK is perfect, it didn't do everything, no
| named branches, a clone is a branch, which is a model
| that absolutely will not scale to what people are doing
| today (we can argue whether TB repos should exist, but
| they do).
|
| But for the problems BK did solve, it tended to solve
| them very well. Hell, just our regression tests are a
| treasure trove of things that can go wrong in the wild
| and we open sourced both the tests and the test harness.
| ymbeld wrote:
| > Unfortunately, even now, it seems that there is a lot
| catching up to BK still to be done. To be fair, we had
| kernel level programmers working on it, we don't think
| anyone will pick up our code, you pretty much have to be
| a top 1-2% programmer to work on it, it's all in very
| disciplined C, people don't seem to like that any more.
|
| Oh my oh my.
| luckydude wrote:
| Believe me, I would do backflips if someone wanted the BK
| source base, it's got almost 2 decades of my work in it,
| north of 140 man years. It's a lot to just let fade away.
|
| But I assembled a team of people better and smarter than
| me, I did my best to keep the code simple but I didn't
| always succeed.
|
| If you, or anyone, wants to pick it up, I'm happy to
| answer questions.
| mucholove wrote:
| Will take a look at it.
|
| At this point, the trick to creating a sizable git
| alternative I think is to Trojan horse coding into a new
| realm with "no-code" like apps.
|
| One of my favorites is Fossil by Richard Hipp. I wonder
| what your thoughts on it are. I think it is RCS, but
| usability wise I think it's way ahead of git.
|
| I just recently learned C and I really like the coding
| style Hipp uses as well. :)
| JNRowe wrote:
| Thanks, although I think you're demonstrating here and in
| the other comments why you should write a real history.
|
| Was the conference recorded? I've tried searching, but
| I'm not turning anything up.
|
| As an outsider you get my worthless full agreement on
| strictness of history, and on solving the monorepo or
| vendoring dilemmas. My employer at the time of the
| upheaval was a bitmover customer, and as we slowly
| switched away one repo at a time it definitely felt like
| a sideways step. I'd hesitate to say backwards because it
| did come with some big process improvements for us, but
| definitely not forwards.
|
| I'd surely have been proud of solving problems with the
| quality that BK did too. I remember playing with a lot of
| the open source systems of the time1, and none of them
| were in the same league. I'll make no apologies for this
| sounding like truly weird fan mail.
|
| 1 I'm remembering hg, darcs, monotone,
| $some_implementation_of_arch, prcs, codeville but there
| was a lot of people in the space to some degree.
| luckydude wrote:
| I think it was recorded, I'll go look.
|
| Apologize for saying BK is quality? None needed, we
| prided ourselves on producing a quality product. And
| great support, our average response time, 24x7, was 24
| minutes. It was only that "slow" because we were North
| America based. If you only considered the US work week,
| response time was usually under 2 minutes, but that's not
| reasonable because we had customers all over the world.
|
| I'm gonna start with a write up of the SCCS weave, with a
| goal that it is enough of a spec that you could go
| implement it. Maybe add some notes about how I did it
| because the way I did it was unusual and had the side
| benefit that you could extract the GCA, left tip, and
| right tip for a merge in one pass.
| brundolf wrote:
| I hadn't heard of BitKeeper but it sounds interesting. Have
| you considered open-sourcing it now for people to look at,
| even though the business has faded?
| momszack wrote:
| This makes me feel old. The bitkeeper saga is why GitHub
| exists. The drama is archived in 2004-5 lkml.
| brundolf wrote:
| I was twelve :)
| luckydude wrote:
| http://bitkeeper.org
|
| Been open source for years
| nightowl_games wrote:
| Curious on performance benchmarks. For me, I'm comparing this to
| wren:
|
| https://wren.io/
| luckydude wrote:
| There are some benchmarks here:
|
| http://mcvoy.com/lm/L/tcl/tests/langbench/
|
| some results in the README. Perl holds up well. These are
| probably 10 years old though.
| tyingq wrote:
| Tcl is historically very slow. Especially for synthetic CPU
| intensive benchmarks. However, since it's so easy to interop
| with C, it didn't seem to matter much in the real world. You
| just put anything performance sensitive in C and left the bits
| that didn't matter in tcl. Some benchmarks:
| https://github.com/trizen/language-benchmarks
| rkeene2 wrote:
| Additionally, you can compile Tcl to machine code with
| TclQuadCode for up to a 66x speed improvement
| synergy20 wrote:
| so this is a c-like-interface for tcl/tk libraries? I was
| thinking it's a c-style lua script alternative so I can use it on
| embedded boards.
___________________________________________________________________
(page generated 2021-02-20 23:01 UTC)