1. 3

    Does anyone know any more about this? I’ve never heard of it and it seems very new, but there is already a BallerinaCon in July? Looks like it’s owned by WSO2 who I’ve never heard of before either.

    1. 3

      It has been about 3 years in development but we really started talking about it earlier this year. The origins indeed have been in WSO2’s efforts in the integration space (WSO2 is an open-source integration company and had a research project on code-first approach to integration). Ballerina is an open-source project - at this moment has 224 contributors.

      It is getting a lot of interest in the microservices and cloud-native (CNCF) space because it supports all the modern data formats and protocols (HTTP, WebSockets, gRPC, etc.), has native Docker and Kubernetes integration (build directly into a Docker image and K8S YAMLs), is type-safe, compiled, has parallel programming and distributed constructs baked in, etc.

      You can see lots of language examples in Ballerina by Example and Ballerina Guides.

      1. 2

        I actually posted this hoping someone would have more info. The language looks interesting and far along to be under the radar.

        1. 1

          The company seems to be based in Sri Lanka. It is nice to see cool tech coming from countries like that.

          1. 1

            The company seems to be based in Sri Lanka. It is nice to see cool tech coming from countries like that.

            The project has non-WSO2 contributors as well, and WSO2 has also offices in Mountain View, New York, Pao Paolo, London, and Sydney, but indeed Colombo (Sri Lanka) is the biggest office so at the moment my guess would be that Ballerina is 90% from Sri Lanka - which indeed is a fantastic place! :)

        1. 5

          The author mentions that ASCII-friendly APL successors (see J) “are all ugly far beyond the possibility of public success.” While I don’t necessarily agree, I feel like ligature fonts would be a perfect fit for a language like J. It could be used to map verbs onto their APL equivalents, and just make things look a bit more cohesive.

          1. 7

            J is beautiful and, in terms of semantics, is even more elegant than APL. The notation is its primary drawback, to me, for two reasons: there is no longer a one-to-one mapping of action to symbol (because some symbols are digraphs or semi-trigraphs); and because the symbols used already have well-known meanings, causing cognitive burden when switching between the J and the everywhere-else meaning.

            Also:

            This is the Game of Life in APL

            I love APL but I swear if all you read is pop-CS articles about APL you’d think it’s Life: The Language

            1. 3

              Would you have some recommendation of array language snippets that are more representative of the things people end up writing?

              As someone extremely tired of seeing fibonacci examples for functional languages, I’m very interested in knowing what real APL looks like

              1. 2

                The Co-dfns compiler (https://github.com/Co-dfns/Co-dfns) is an APL-to-C++ compiler written in APL.

                GNU APL has a pretty nice community page at https://www.gnu.org/software/apl/Community.html where they list some APL projects (some written in APL and others in other languages).

                J has an extensive standard library and a complete relational database written in J, all at https://jsoftware.com

                Array languages get the most use today in finance, I believe. The K language from Kx Systems (and the Q query language strongly related to it) are widely used there and have a free-as-in-beer version available with some documentation.

                (I don’t remember who said it, but the statement “every time you buy stock you’re using K” is probably a reasonably true statement.)

            1. 1

              Seems like he had the answer in the first few paragraphs: Ideally, the people determining the scope and timing of the work should be the people doing the work. After that, he went elsewhere.

              1. 12

                I thought it would actually be about std::optional, not workspace issues that have nothing to do with the problem at hand.

                TL;DR: keep your toolchain up to date if you want to use recent language features.

                1. 3

                  yeah. I suspect better article naming would be better at not leaving people feel like they kept on expecting the article to go somewhere it didn’t.

                  1. 9

                    I think it’s funny because the reader’s experience parallels the author’s experience of wanting to get someplace.

                    1. 4

                      Somebody gets me! :)

                    2. 2

                      Sorry folks :(. But std::optional works as one expects - you can write functions to accept std::optional and you just check early on if it evaluates to true and just return empty as needed, so you can chain functions neatly.

                      Now, if only we could have pattern matching …

                      1. 3

                        I think the consensus of languages with options and pattern matching is “don’t use pattern matching, use combinators”.

                        1. 4

                          Hmm as a full-time Haskeller “don’t use pattern matching” is news to me. Do you mean “don’t use pattern matching for fundamental vocabulary types like Maybe or Either? In which case it’s a reasonable guideline. For types representing your business domain, pattern matching is perfectly good practice. IMHO exhaustiveness checking of pattern matching is an indispensable feature for modelling your domain with types.

                          1. 1

                            Do you mean “don’t use pattern matching for fundamental vocabulary types like Maybe or Either?

                            Yes.

                          2. 3

                            Consensus, really? I’m a big fan of combinators, but I’ll still match on option types sometimes if I think it looks clearer.

                            1. 2

                              Ooh, this is interesting to me - can you expand on this (or point me to some writeups)? Thanks!

                          3. 2

                            Agreed. I read all the way down and nothing significant about std::optional.

                            I thought it was going to be some sort of piece about how using std::optional could lead to yak shaving or something :(

                        1. 2

                          It looks similar to ideas I have as I work on my keywordless language [1]. A simple example would be:

                          ? t < v : ^ ERANGE , v;
                          

                          (where ? is IF, : is THEN and ^ is RETURN). A more complex example is:

                          {? err,c = getc()
                             == EOF , _           : ^ 0   , v;
                             != 0   , _           : ^ err , v;
                             _      , _           : { ungetc(c) ; ^ 0 , v; }
                             _      , is_digit(c) : n = c - '0';
                             _      , is_upper(c) : n = c - 'A' + 10;
                             _      , is_lower(c) : n = c - 'a' + 10;
                          }
                          

                          (where _ is “don’t care” placeholder). Internally, the compiler will [2] re-order the tests from “most-specific” to “least-specific” (so the _ , _ : bit is like ELSE). Also, here, getc() returns two values [3], both of which are checked. I do not have exceptions because I’m not fond of exceptions [5] so I don’t have syntax for it.

                          [1] Based off an idea I read about in the mid-80s [4].

                          [2] I’m still playing around with syntax.

                          [3] I had a hard time moving from assembly to C, simply because I could not return multiple values easily.

                          [4] It’s a long term PONARV of mine.

                          [5] It’s a dynamic GOTO and abused way too much in my opinion.

                          1. 1

                            Very nice. Re [2], does that mean that the sequence of the checks in this construct really is immaterial?

                            1. 1

                              Non-existent. I’m still working (even after all these years) on syntax. It was only after I posed the above did I realize that trying to go from “most-specific” to “least-specific” is problematic in the above example. Of these two:

                              == EOF , _
                              != 0 , _
                              

                              Which one is more specific? It’s for these reasons (and some more) that this is taking a long time.

                          1. 2

                            This article makes me think about the difference between constructs where we have to impose an order on the checks and ones where we don’t. The latter seems nicer but they would lead us to drop ‘else’ and be explicit about the full decision space.

                            1. 4

                              Author here, thought this might create some interesting discussion!

                              TL;DR:

                              Why have multiple distinct syntactic constructs for if-then-else, pattern matching and things like if-let, when they are largely doing the same thing (check some condition to make a decision on how the program should go on)?

                              The core idea is having a single, unified condition syntax that scales from simple one-liners to complex pattern matches that subsumes the existing syntax options.

                              1. 3

                                Are they the same?

                                Why do we even use if statements anyway?

                                k/q doesn’t use them very often, since it rarely makes things clearer. Function application is indexing, decode, projection and each-left, and so on, make it possible to write much less code.

                                for example, if x == 1.0 then "a" else "z" could be simply "za"1=

                                “one comparison operator on multiple targets” is: "zba"2 sv 1 2=\:

                                “different comparison operators, equality and identity” is: "zna"2 sv(1=;0w=)@\:

                                “method calls” are "zne"2 sv(isempty;0 in)@\:

                                Scala is an atom-language though. It can only do one thing at a time, so you see there to be a need to “check some condition to make a decision on how the program should go on” but, let’s say those lists are big, we can trivially parallelise “each”; In a data-parallel language, you very infrequently check some condition to make a decision on how the program should go on.

                                1. 9

                                  Your “simply” is my “incomprehensibly”.

                                  Computer languages need to strike a balance between human-language intuition and machine-parser explicitness. Simply slamming the slider all the way to the right isn’t a solution, so much as an admission of defeat, IMO.

                                  1. 2

                                    My idea was totally different. I’ve noticed what people comprehend depends on their thinking style, background (esp prior languages), and so on. However, there’s fewer underlying concepts or structures in play than there are surface syntaxes or API’s. So, I was thinking that maybe languages should try multiple front-ends with different syntaxes, coding styles, etc. As a start, C and Python. Each client has a tool that automatically translates it to their style with same meaning.

                                    1. 1

                                      maybe languages should try multiple front-ends with different syntaxes, coding styles, etc.

                                      is it just me or does it sound like racket’s #lang?

                                      1. 1

                                        Probably also not a coincidence that Racket is at the top of my list for a future project doing something similar. ;)

                                    2. 1

                                      Your “intuition” is really mediocracy.

                                      Code that is shorter has a higher chance of being correct. If you can’t read it now, learning how to read it will make you a better programmer, and that benefits you, and everyone you work with.

                                      1. 1

                                        (laughs)

                                        Downvote my thoughtful response as a troll, insult me, and then talk down to me. Really hit the internet trifecta, huh?

                                        1. 0

                                          You’re the one who said you can’t comprehend something, and yet you believe you have something important to comment on it?

                                          How is that not mediocrity?

                                  2. 2

                                    Nice. I wonder how it works out grammatically for parser.

                                    1. 4

                                      Either indentation-based, or requiring some delimiter.

                                      I’m largely in the indentation-based camp these days, so I haven’t spent much time thinking about how to make the delimitation to look nice. I’d probably just go with mandatory curly braces around the branches.

                                  1. 4

                                    On HN someone said: “This will be a tongue in cheek comment, but there’s another thing Datomic isn’t making you do either: GDPR compliance.”

                                    Immutable data stores are great but the world wants some level of mutability. I’ll link to the comment and responses if anyone is interested.

                                    1. 6

                                      I’m probably biased, but I think Datomic’s model of deletion is perfect for GDPR.

                                      When you delete something permanently, we call it “excision.” (As in “cutting out”.) After the excision, the data is gone, gone, gone. Any old storage segments that held the excised data get reindexed and garbage collected.

                                      But, we record the event of the excision as its own transaction. So there’s a permanent record of what got deleted (by the matching criteria) and when. And like any transaction, the excision transaction can have extra attributes attached like who did it and in response to what document number, etc.

                                      With any other database, once data is deleted, you don’t know that it ever existed and you don’t know who deleted it, when, or why.

                                      1. 1

                                        The link @mfeathers linked to says that excision is very expensive but it’s unclear what that means for use. Do you have any guidance on that?

                                        1. 1

                                          Excision does require a full scan of the log, plus a full index job. Depending on the size of your database that can take a while. Because this has to be done atomically, the transactor can’t do anything else while that excision runs.

                                          This is for the on-prem version of the product. I don’t know how the cloud version does it… it may be friendlier to throughput there.

                                          1. 2

                                            The way you describe it seems like it could be so expensive as to not be viable in production.

                                            1. 1

                                              EDIT: Sorry for the wall of text… I wanted to say a bit more than “you have to design for it.”

                                              I have seen installations where we had to get creative to work around 3 or 4 hour excision times. But I’ve also seen installations where it took a couple of minutes. But even on the low end, it requires design work to handle those delays.

                                              There’s a cluster of related design techniques to achieve high throughput with Datomic. I’m still learning these, even after 6 years with the product. But it turns out that designing for stability under high throughput makes you less sensitive to excision time.

                                              Mostly it comes down to the queue. Datomic clients send transactions to the transactor via a queue. (This is actually true for any database… most just don’t make the queues evident.) Any time you look at the result of a transaction, you’re exposed to queuing time. “Transaction” here specifically means changing data, not queries. Those are unaffected by excision or the tx queue.

                                              I design my systems to start with a DB value that I capture at the beginning of a request. That means I freeze a point in time and all my queries are based at that point in time. This would be similar to a BEGIN TRAN with repeatable read isolation. Then while processing a request, I accumulate all the transaction data that I want to submit. At the end of the request, I make a single transaction out of that data so all the effects of the request happen atomically.

                                              When I call the transact function, I get back a future. I pass that future off to an in-memory queue (really a core.async channel, if you’re a Clojurist.) A totally different thread goes through and checks the futures for system errors.

                                              All this means that even if the tx-queue is slow or backed up, I can keep handling requests.

                                              As a separate mechanism, I’m also exploring the idea of separating databases by the calendar. So like you’d roll a SALES table over each year and keep a history of SALES_2016, SALES_2017, etc. Since I can query across multiple databases quite easily, I can keep my working set smaller by doing that.

                                              1. 1

                                                All this means that even if the tx-queue is slow or backed up, I can keep handling requests.

                                                Can you? For example, let’s say we have a request from the web that is updating my Tinder profile and we’re running an excise to remove old GPS coordinates and this takes 3 minutes. That means my request will hang 3 minutes, right? While you might technically be correct, from a UX perspective, you’re not continuing to handle requests. Or did I misunderstand your description? If I understand you correctly, if you were pitching this technology to me I would probably reject it. I can’t have multi-minute write outages in my super important most popular product ever.

                                                like you’d roll a SALES table over each year and keep a history of SALES_2016, SALES_2017,

                                                I haven’t used Datomic so maybe the model is so great putting up with things like this is worth it, but I do really dislike having to decide a sharding strategy (should I do years? months? weeks? how do I know? How expensive is it to change after I decide?). Certainly most databases have pretty miserable payoffs, though. Also, is excise just inside a DB or is it across all DBs?

                                      2. 5
                                        1. 1

                                          That was one of my points against blockchains due to encumberance pollution attacks repos. I had ideas for dealing with it but each had tradeoffs. Tricky paradox to address.

                                        1. 2

                                          A lot of clunky error handling is a side effect of returning data. When we call getLocation we get back the retrieved location and an error code. If we were messaging, we could simply message someone the location when we can get it, and message an entirely different part of code if we can’t get it.

                                          1. 3

                                            Good point about beginners, but thing about non-trivial abstractions is that they always leak someplace.

                                            He uses memory management as an example of something programmers don’t have to think about day to day, but you kinda need to have a mental model of memory. I’ve visited teams that haven’t and they’ve dug themselves into deep holes.

                                            The cases for data are real. The question is how much rework you have to do when you come across one.

                                            1. 12

                                              Nested functions in Swift aren’t too modern. They were in ALGOL, Simula 67, and Pascal.

                                              1. 2

                                                Yeah, most of these techniques would work in any modern language. I assume the target audience is recidivist C coders.

                                                1. 1

                                                  The goal was to demonstrate how modern code, as in code you’d write today in Swift, would solve the same problems without relying on goto or multiple inheritance. I don’t claim that Swift pioneered any of this or that any of it is novel.

                                                1. 5

                                                  This a fascinating case. It’s very unfortunate that the cyclist had to die for it to come before us. However, had the car been driven by a human, nobody would be talking about it!

                                                  That said, the law does not currently hold autonomous vehicles to a higher standard than human drivers, even though it probably could do so given the much greater perceptiveness of LIDAR. But is there any precedent for doing something like this (having a higher bar for autonomous technology than humans)?

                                                  1. 13

                                                    Autonomous technology is not an entity in law, and if we are lucky, it never will be. Legal entities designed or licensed the technology, and those are the ones the law finds responsible. This is similar to the argument that some tech companies have made that “it’s not us, it’s the algorithm.” The law does not care. It will find a responsible legal entity.

                                                    This is a particularly tough thing for many of us in tech to understand.

                                                    1. 25

                                                      It’s hard for me to understand why people in tech find it so hard to understand. Someone wrote the algorithm. Even in ML systems where we have no real way of explaining its decision process, someone designed it the system, someone implemented it, and someone made the decision to deploy it in a given circumstance.

                                                      1. 11

                                                        Not only that, but one other huge aspect of things nobody is probably thinking about. This incident is going to probably start the ball rolling on certification and liability for software.

                                                        Move fast and break things is probably not going to fly in the faces of too many deaths to autonomous cars. Even if they’re safer than humans, there is going to be repercussions.

                                                        1. 8

                                                          Even if they’re safer than humans, there is going to be repercussions.

                                                          Even if they are safer than humans, a human must be held accountable of the deaths they will cause.

                                                          1. 2

                                                            Indeed, and I believe those humans will be the programmers.

                                                            1. 4

                                                              Well… it depends.

                                                              When a bridge breaks down and kills people due to bad construction practices, do you put in jail the bricklayers?

                                                              And what about a free software that you get from me “without warranty”?

                                                              1. 4

                                                                No - but they do take the company that build the bridge to court.

                                                                1. 5

                                                                  Indeed. The same would work for software.

                                                                  At the end of the day, who is accountable for the company’s products is accountable for the deaths that such products cause.

                                                                2. 2

                                                                  Somewhat relevant article that raised an interesting point RE:VW cheating emissions tests. I think we should ask ourselves if there is a meaningful difference between these two cases that would require us to shift responsibility.

                                                                  1. 2

                                                                    Very interesting read.

                                                                    I agree that the AI experts’ troupe share a moral responsibility about this death, just like the developers at Volkswagen of America shared a moral responsibility about the fraud.

                                                                    But, at the end of the day, software developers and statisticians were working for a company that is accountable for the whole artifact they sell. So the legal accountability must be assigned at the company’s board of directors/CEO/stock holders… whoever is accountable for the activities of the company.

                                                                  2. 2

                                                                    What I’m saying is this is a case where those “without warranty” provisions may be deemed invalid due to situations like this.

                                                                  3. 1

                                                                    I don’t think it’ll ever be the programmers. It would be negligence either on the part of QA or management. Programmers just satisfy specs and pass QA standards.

                                                              2. 2

                                                                It’s hard to take reponsability for something evolving in a such dynamic environment, with potentially used for billions of hours everyday, for the next X years. I mean, knowing that, you would expect to have a 99,99% of cases tested, but here it’s impossible.

                                                                1. 1

                                                                  It’s expensive, not impossible.

                                                                  It’s a business cost and an entrepreneurial risk.

                                                                  If you can take the risks an pay the costs, that business it not for you.

                                                            2. 4

                                                              It’s only a higher bar if you look at it from the perspective of “some entity replacing a human.” If you look at it from the perspective of a tool created by a company, the focus should be ok whether there was negligence in the implementation of the system.

                                                              It might be acceptable and understandable for the average human to not be able to react that fast. It would not be acceptable and understandable for the engineers on a self-driving car project to write a system that can’t detect an unobstructed object straight ahead, for the management to sign off on testing, etc.

                                                            1. 5

                                                              There really needs to be a federated github.

                                                              1. 46

                                                                Like… git ?

                                                                1. 21

                                                                  So github but without the hub. May be on to something.

                                                                  1. 7

                                                                    Github is one of my favorite stories when I talk about how decentralized systems centralize.

                                                                    1. 7

                                                                      But did GitHub really centralize something decentralized? Git, as a VCS is still decentralized, nearly everyone who seriously uses it has a git client on their computer, and a local repository for their projects. That part is still massively decentralized.

                                                                      GitHub as a code sharing platform, that allows issues to be raised and discussed, patches/pull requests to be submitted, etc. didn’t previously exist in a decentralized manner. There seems to have always been some central point of reference, be it website or just a mailing list. It’s not as if whole project were just based around cc’ing email to one another all the time. How would new people have gotten involved if that were the case?

                                                                      The only thing I could see as centralising is the relative amount of project hosted on GitHub, but that isn’t really a system which can be properly described as “decentralized” or “centralized”..,

                                                                      1. 4

                                                                        It’s the degree to which people are dependent on the value-adds that github provides beyond git. It’s like a store having a POS that relies on communication with a central server. Sure, they can keep records on paper do sales but it’s not their normal course, so they don’t. This comment on HN sums it up: https://news.ycombinator.com/item?id=16124575

                                                                      2. 1

                                                                        Got any other examples?

                                                                        1. 3

                                                                          Email would be a prominent one. Most people (and I can’t say I am innocent) use gmail, hotmail, yahoo mail, etc. I belive there is some general law that describes this trend in systems, which can then be applied to the analysis of different topics, for example matter gathering in around other matter in physics or money accumulating itself around organization with more money, etc.

                                                                          On the other side you have decentralized systems which didn’t really centralized significantly, for whatever reason, such as IRC, but which had a decrease in users over time, which I also find to be an interesting trend.

                                                                          1. 4

                                                                            Many businesses run their own email server and also I don’t have to sign up to gmail to send a gmail user an email but I do have to sign up to github.

                                                                            1. 1

                                                                              A tendency towards centralisation doesn’t mean that no smaller email servers exist, I’m sorry if you misunderstood me there. But on the other hand, I have heard of quite a few examples where businesses just use gmail with a custom domain, so there’s that.

                                                                              And it’s true that you don’t have to be on gmail to send an email to a hotmail server, for example, but most of the time, if just a normal person were to set up their mail server, all the major mail providers automatically view this new host as suspicious and potentially harmful, thus more probably redirecting normal messages as spam. This wouldn’t be that common, if the procentual distribution of mail servers weren’t that centralised.

                                                                          2. 1

                                                                            Did a talk using them. This cuts to the chase: https://www.youtube.com/watch?v=MgbmGQVa4wc#t=11m35s

                                                                      3. 1

                                                                        Git has a web interface?

                                                                        1. 7

                                                                          … federation is about data/communications between servers.. but seeing as you asked, yes it does: https://manpages.debian.org/stretch/git-man/gitweb.1.en.html

                                                                          1. 10

                                                                            To be fair, whjms did say “a federated github”. The main feature of GitHub is its web interface.

                                                                            1. 2

                                                                              Right, and there are literally dozens of git web interfaces. You can “federate” git and use whichever web ui you prefer.

                                                                              1. 12

                                                                                But you then miss out on issue tracking, PR tracking, stats, etc. I agree that Git itself provides a decentralized version control system. That’s the whole point. But a federated software development platform is not the same thing. I would personally be very interested to see a federated or otherwise decentralized issue tracking, PR tracking, etc platform.

                                                                                EDIT: I should point out that any existing system on par with Gitea, Gogs, GitLab, etc could add ActivityPub support and instantly solve this problem.

                                                                                1. 4

                                                                                  Doesn’t give you access to all the issues, PRs and comments though.

                                                                                  1. 4

                                                                                    git-appraise exists. Still waiting for the equivalent for issues to come along.

                                                                                    https://github.com/google/git-appraise

                                                                                    1. 4

                                                                                      huh git appraise is pretty cool.

                                                                                      I was going to suggest some kind of activitypub/ostatus system for comments. A bit like peertube does to manage comments. But a comment and issue system that is contained within the history of the project would be really interesting. Though it would make git repos take a lot more space for certain projects no?

                                                                                      1. 3

                                                                                        I’d assume that those could potentially be compressed but yes. It’s definitely not ideal. https://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

                                                                                        ^^^^ Unless I’m mistaken, Fossil also tracks that kind of stuff internally. I really like the idea that issues, PRs, and documentation could live in the same place, mostly on account of being able to “go back in time”, and see when you go back to a given version, what issues were open. Sounds useful.

                                                                                    2. 3

                                                                                      BugsEverywhere (https://gitlab.com/bugseverywhere/bugseverywhere), git-issues (https://github.com/duplys/git-issues), sit (https://github.com/sit-it/sit) all embed issues directly in the git repo.

                                                                                      Don’t blame the tool because you chose a service that relies on vendor lock-in.

                                                                                      1. 4

                                                                                        If I recall correctly the problem here is that to create an issue you need write access to the git repo.

                                                                                        Having issues separated out of the repositories can make it easier, if the web interface can federate between services, that’s even better. Similar to Mastodon.

                                                                                        1. 1

                                                                                          There’s nothing to say that a web interface couldnt provide the ability for others to submit issues.

                                                                                    3. 3

                                                                                      Right, and there are literally dozens of git web interfaces.

                                                                                      Literally dozens of git web interfaces the majority of developers either don’t know or care about. The developers do use GitHub for various reasons. voronoipotato and LeoLamda saying a “federated Github” means the alternative needs to look like or work with Github well enough that those using Github, but ignoring other stuff you mentioned, will switch over to it. I’m not sure what that would take or if it’s even legal far as copying appearance goes. It does sound more practical goal than telling those web developers that there’s piles of git web interfaces out there.

                                                                                      1. 1

                                                                                        Im going to respond to two points in reverse order, deliberately:

                                                                                        or care about.

                                                                                        Well, clearly the person I replied to does care about a git web interface that isn’t reliant on GitHub.com. Otherwise, why would they have replied?

                                                                                        Literally dozens of git web interfaces the majority of developers either don’t know [about]

                                                                                        Given the above - The official git project’s wiki has a whole page dedicated to tools that work with git, including web interfaces. That wiki page is result 5 in google and result 3 in duckduckgo when searching for “git web interface”. If a developer wants a git web interface, and can’t find that information for themselves, nothing you, or I or a magic genie does will help them.

                                                                                2. 5

                                                                                  It’s not built-in, but Gogs and Gitea are both pretty nice.

                                                                                  1. 2

                                                                                    Hard agree. I run a personal Gogs site and it’s awesome.

                                                                              2. 7

                                                                                It would be enough if people stopped putting all their stuff on github.

                                                                                1. 8

                                                                                  It won’t happen for a while due to network effects. They made it easy to get benefits of a DVCS without directly dealing with one. Being a web app, it can be used on any device. Being free, that naturally pulls people in. There’s also lots of write-ups on using it or solving problems that are a Google away due to its popularity. Any of these can be copied and improved on. The remaining problem is huge amount of code already there.

                                                                                  The next solution won’t be able to copy that since it’s a rare event in general. Like SourceForge and Github did, it will have to create a compelling reason for massive amounts of people to move their code into it while intentionally sacrificing the benefits of their code being on Github specifically. I can’t begin to guess what that would take. I think those wanting no dependency on Github or alternatives will be targeting a niche market. It can still be a good one, though.

                                                                                  1. 2

                                                                                    I hear the ‘network effects’ story every time, but we are not mindless automatons who have to use github because other people are doing it. I’m hosting the code for my open source projects on a self-hosted gitlab server and i’m getting contributions from other people without problems. Maybe it would be more if the code was on github, but being popular isn’t the most important thing for everyone.

                                                                                    1. 1

                                                                                      Just look at sourceforge, if everyone had to set up their own CVS/SVN server back in the say do you think all those projects would have made it onto the internet?

                                                                                      Now we have a similar situation with got, if GitHub/Bitbucket/etc. didn’t exist I’m sure most people would have stuck with sourceforge (Or not bothered if they had to self host).

                                                                                      You can also look at Googlecode to see the problem with not reaching critical mass (IMHO). There were some high profile projects there, but then I’m sure execs said, why are we bothering to host 1% (A guess) of what is on GitHub?

                                                                                      1. 1

                                                                                        ‘Network effects’ doesn’t mean you’re mindless automatons. It means people are likely to jump on bandwagons. It also means that making it easy to connect people together, esp removing friction, makes more of them do stuff together. The massive success of Github vs other interfaces argues my point for me.

                                                                                        “Maybe it would be more if the code was on github”

                                                                                        That’s what I telling you rephrased. Also, expanded to the average project as some will get contributions, some won’t, etc.

                                                                                    2. 4

                                                                                      Heck even I won’t move off of it until there is a superior alternative, sorry.

                                                                                    3. 3

                                                                                      I thought about a project along these lines a while ago. Something along the lines of cgit, which could offer a more or less clean and consistent UI, and a easy to set up backend, making federation viable in the first place. Ideally, it wouldn’t even need accounts, instead Email+GPG could be used, for example by including an external mailing list into the repo, with a few addition markup features, such as internal linking and code highlighting. This “web app” would then effectively only serve as an aggregator of external information, onto one site, making it even easier to federate the entire structure, since the data wouldn’t even be necessarily bound to one server! If one were to be really evil, one could also use GitHub as a backend…

                                                                                      I thought about all of this for a while, but the big downsides from my perspective seemed to be a lack of reliability on servers (which is sadly something we have come to expect with tools such as NPM and Go’s packaging), asynchronous updates could mess stuff up, unless there were to be a central reference repo per project, and the social element in social coding could be hard to achieve. Think of stars, followings, likes, fork overviews, etc. these are all factors which help projects and devs display their reputation, for better or for worse.

                                                                                      Personally, I’m a bit sceptical that something along these lines would manage to have a real attractiveness, at least for now.

                                                                                      1. 3

                                                                                        Lacks a web interface, but there are efforts to use ipfs for a storage backend.

                                                                                        https://github.com/cryptix/git-remote-ipfs

                                                                                        1. 3

                                                                                          I think there have been proposals for gitlab and gitea/gogs to implement federated pull request. I would certainly love it since I stuff most of my project into my personal gitea instance anyway. Github is merely a code mirror where people happen to be able to file issues.

                                                                                          1. 3

                                                                                            I think this would honestly get the work done. Federated pull request, federated issue discussion

                                                                                            1. 1

                                                                                              I’m personally a bit torn if a federated github-like should handle it like a fork, ie, if somebody opens an issue they do it on their instance and you get a small notification and you can follow the issue in your own repo

                                                                                              Or if it should merely allow people to use my instance to file issues directly there like with OAuth or OpenID Connect. Probably something we’ll have to figure out in the process.

                                                                                              1. 2

                                                                                                just make it work like gnusocial/mastodon. username@server.com posted an issue on your repo. You can block server, have a whitelist, or let anyone in the world is your oyster.

                                                                                            2. 1

                                                                                              Would be nice if I could use my gitlab.com account to make MRs on other gitlab servers.

                                                                                            3. 1

                                                                                              I always thought it would be neat to try to implement this via upspin since it already provides identity, permissions, and a global (secure) namespace. Basically, my handwavy thoughts are: design what your “federated github” repo looks like in terms of files. This becomes the API or contract for federation. Maybe certain files are really not files but essentially RPCs and this is implemented by a custom upspin server. You have an issue directory, your actually git directory, and whatever else you feel is important for managing a software project on git represented in a file tree. Now create a local stateless web interface that anyone can fire up (assuming you have an upspin user) and now you can browse the global upspin filesystem and interact with repos ,make pull requests, and file issues.

                                                                                              I was thinking that centralized versions of this could exist like github for usability for most users. In this case users’ private keys are actually managed by the github like service itself as a base case to achieve equal usability for the masses. The main difference is that the github like service exports all the important information via upspin for others to interact with via their own clients.

                                                                                            1. 3

                                                                                              I disagree with the article. Behavioral Subtyping (LSP) is the only one that keeps you out of trouble.

                                                                                              1. 6

                                                                                                I don’t think that is inconsistent with my thesis. You can want LSP and build an inheritance taxonomy that gives you LSP. You will (probably) have to relax domain fidelity and maximal reuse to get LSP.

                                                                                              1. 1

                                                                                                Predictions:

                                                                                                • APL operations will start to sneak into mainstream programming languages
                                                                                                • Some platform change will occur that will allow a massively simplified stack.
                                                                                                • People will rediscover on-prem/embedded for some problems and migrate to them from the cloud.
                                                                                                • ML will generate code we can’t understand for common programming tasks, thus fulfilling two of the common cases for programmers.
                                                                                                • Scaling will become less important as more businesses move toward niches.
                                                                                                • There will be a push toward air gapped software.
                                                                                                • The AI personal assistant space will boom but is likely already captured by the big players.
                                                                                                • Culturally: the tech backlash will deepen with unforeseeable results.
                                                                                                • Culturally: the migration from large social media spaces to small private ones will continue.
                                                                                                • Blockchain-ish tech won’t be a big player in currency. It will, however, have a niche in the creation of durable records.
                                                                                                • The conversation around typing in program languages will become more nuanced (if I have anything to do with it).
                                                                                                1. 1

                                                                                                  APL operations will start to sneak into mainstream programming languages

                                                                                                  APL is a fairly old language. Why do you antifipate this happening now?

                                                                                                  1. 1

                                                                                                    Because:

                                                                                                    1. The operations are useful.
                                                                                                    2. People stayed away from APL/J for years because they are lexically scary.
                                                                                                    3. The chaining style of programming seen in point-free Haskell/F#, LINQ/RX, Java Streams, and Rust have made a less control-flow style of programming seem less alien.
                                                                                                1. 9

                                                                                                  “Only code at work? That doesn’t make you a worse programmer”

                                                                                                  The counter-point is: it doesn’t make you a better programmer either.

                                                                                                  Before I’m down-voted into oblivion I just want to mention that I hope it’s obvious what we’re doing here. We’re attempting “social steering.” About a decade ago, the ethic was: put in the outside-work hours on open source and everything else to “get good.” Now, the pendulum swings in the other way because that other path can be ruinous. It can burn people out and make people feel less comfortable if they feel that they should be doing the same thing. The latter is the real problem.

                                                                                                  Fact of the matter is, the truth is in the middle and neither way of approaching career is the “right one.” That’s a more nuanced view than most. It might not be welcome while we attempt to “socially steer.”

                                                                                                  1. 5

                                                                                                    I wonder what it’s like to become very used to something like this and then suddenly not have it.

                                                                                                    1. 2

                                                                                                      I have been thinking about this too. This is currently the biggest downside of optimising and modifying your system like this.

                                                                                                    1. 59

                                                                                                      This is why we can’t have good software. This program could literally have been an empty file, a nothing at all, a name capturing the essence perfectly.

                                                                                                      I’m not sure I could disagree more strongly. An empty file only has the true behavior because of a bunch of incredibly non-obvious specific Unix behaviors. It would be equally reasonable for execution of this file to fail (like false) since there’s no hashbang or distinguishable executable format to decide how to handle it. At a somewhat higher level of non-obviousness, it’s really weird that true need be a command at all (and indeed, in almost all shells, it’s nottrue is a builtin nearly everywhere).

                                                                                                      true being implementable in Unix as an empty file isn’t elegant—it’s coincidental and implicit.

                                                                                                      1. 15

                                                                                                        I mean, it’s POSIX specified behavior that any file that is executed that isn’t a loadable binary is passed to /bin/sh (”#!” as the first two bytes results in “implementation-defined” behavior), and it’s POSIX specified behavior that absent anything else, a shell script exits true.

                                                                                                        It’s no more coincidental and implicit than “read(100)” advances the file pointer 100 bytes, or any other piece of standard behavior. Sure, it’s Unix(-like)-specific, but, well, it’s on a Unix(-like) operating system. :)

                                                                                                        1. 25

                                                                                                          It’s precisely specified, yes, but it’s totally coincidental that the specification says what it does. A perfectly-reasonable and nearly-equivalent specification in an alternate universe where Thomson and Ritchie sneezed five seconds earlier while deciding how executables should be handled would have precisely the opposite behavior.

                                                                                                          On the other hand, if read(100) did anything other than read 100 bytes, that would be extremely surprising and would not have come about from an errant sneeze.

                                                                                                          1. 35

                                                                                                            Black Mirror Episode: The year is 2100 and the world is ravaged by global warming. The extra energy aggregated over decades because non executables went through /bin/sh caused the environment to enter the tipping point where the feedback loops turned on. A time machine is invented, where one brave soul goes back in time with a feather, finds Thomson and makes him sneeze, saving humanity from the brink of extinction. But then finds himself going back to 2100 with the world still ravaged. Learns that it was fruitless because of npm and left-pad.

                                                                                                            1. 12

                                                                                                              it’s totally coincidental that the specification says what it does.

                                                                                                              This is true of literally all software specifications, in my experience.

                                                                                                              1. 8

                                                                                                                Surely we can agree that it is far more coincidental that an empty executable returns success immediately than that e.g. read(100) reads 100 bytes?

                                                                                                                1. 7

                                                                                                                  Why isn’t 100 an octal (or a hex or binary) constant? Why is it bytes instead of machine words? Why is read bound to a file descriptor instead of having a record size from an ioctl, and then reading in 100 records?

                                                                                                                  Just some examples. :)

                                                                                                                  1. 5

                                                                                                                    Obviously, minor variations are possible. However, in no reasonable (or even moderately unreasonable) world, would read(100) write 100 bytes.

                                                                                                                    1. 12

                                                                                                                      Pass a mmap’ed pointer to read, and it shall write. :)

                                                                                                              2. 12

                                                                                                                The current (POSIX) specification is the product of historical evolution caused in part by /bin/true itself. You see, in V7 Unix, the kernel did not execute an empty file (or shell scripts); it executed only real binaries. It was up to the shell to run shell scripts, including empty ones. Through a series of generalizations (starting in 4BSD with the introduction of csh), this led to the creation of #! and kernel support for it, and then POSIX requiring that the empty file trick be broadly supported.

                                                                                                                This historical evolution could have gone another way, but the current status is not the way it is because people rolled out of bed one day and made a decision; it is because a series of choices turned out to be useful enough to be widely supported, eventually in POSIX, and some choices to the contrary wound up being discarded.

                                                                                                                (There was a time when kernel support for #! was a dividing line between BSD and System V Unix. The lack of it in the latter meant that, for example, you could not make a shell script be someone’s login shell; it had to be a real executable.)

                                                                                                                1. 10

                                                                                                                  The opposite isn’t reasonable though. That would mean every shell script would have to explicitly exit 0 or it will fail.

                                                                                                                  Every. Shell. Script.

                                                                                                                  And aside from annoying everyone, that wouldn’t even change anything. It would just make the implementation of true be exit 0, instead of the implementation of false be exit 1.

                                                                                                                  And read(100) does do something besides read 100 bytes. It reads up to 100 bytes, and isn’t guaranteed to read the full 100 bytes. You must check the return value and use only the amount of bytes read.

                                                                                                                  1. 7

                                                                                                                    It’s not obvious to me that an empty file should count as a valid shell script. It makes code generation marginally easier, I suppose. But I also find something intuitive to the idea that a program should be one or more statements/expressions (or functions if you need main), not zero or more.

                                                                                                                    1. 3

                                                                                                                      So if you run an empty file with sh, you would prefer it exits failure. And when you run an empty file with python, ruby, perl, et al., also failures?

                                                                                                                      Why should a program have one or more statements / expressions? A function need not have one or more statements / expressions. Isn’t top level code in a script just a de facto main function?

                                                                                                                      It’s intuitive to me that a script, as a sequence of statements to run sequentially, could have zero length. A program with an entry point needs to have at least a main function, which can be empty. But a script is a program where the entry point is the top of the file. It “has a main function” if the file exists.

                                                                                                                      1. 3

                                                                                                                        I think whatever the answer is, it makes equal sense for Perl, Python, Ruby, shell, any language that doesn’t require main().

                                                                                                                        In my opinion, your last argument begs the question. If an empty program is considered valid, then existing is equivalent to having an empty main. If not, then it isn’t.

                                                                                                                        In any case, I don’t mean to claim that it’s obvious or I’m certain that an empty program should be an error, just that it seems like a live option.

                                                                                                                      2. 2

                                                                                                                        Exactly. It sounds like arbitrary hackery common in UNIX development. Just imagine writing a semi-formal spec that defines a program as “zero characters” which you pass onto peer review. They’d say it was an empty file, not a program.

                                                                                                                        1. 2

                                                                                                                          I guess true shouldn’t be considered a program. It is definitely tied to the shell it runs in, as you wouldn’t call execv("true", {"/bin/true", NULL}) to exit a program correctly. for example. true has no use outside of the shell, so it makes sense to have it use the shell’s features. That is why now it tends to be a builtin. But having it a builtin is not specified by POSIX. Executing file on the other end, is, and the spec says the default exit code it 0 or “true”. By executing an empty file, you’re then asking the shell to do nothing, and then return true. So I guess it is perfectly fine for true to jist be an empty file. Now I do agree that such a simple behavior has (loke often with unix) way too many ways to be executed, ans people are gonna fight about it for quite some time! What about these?

                                                                                                                          alias true=(exit)
                                                                                                                          alias true='/bin/sh /dev/null'
                                                                                                                          alias true='sh -c "exit $(expr `false;echo $? - $?`)"'
                                                                                                                          

                                                                                                                          The one true true !

                                                                                                                          1. 1

                                                                                                                            It depends upon the system. There is IEFBR14, a program IBM produced to help make files in JCL which is similar to /bin/true. So there could be uses for such a program.

                                                                                                                            It also has the distinction of being a program that was one instruction long and still have a bug in it.

                                                                                                                            1. 1

                                                                                                                              “That is why now it tends to be a builtin.”

                                                                                                                              Makes sense. If tied to the shell and unusual, I’d probably put something like this into the interpreter of the shell as an extra condition or for error handling. Part of parsing would identify an empty program. Then, either drop or log it. This is how such things are almost always handled.

                                                                                                                        2. 1

                                                                                                                          That would mean every shell script would have to explicitly exit 0 or it will fail.

                                                                                                                          I don’t see how that follows.

                                                                                                                          Once the file is actually passed to the shell, it is free to interpret it as it wishes. No reasonable shell language would force users to specify successful exit. But what the shell does is not in question here; it’s what the OS does with an empty or unroutable executable, for which I am contending there is not an obvious behavior. (In fact, I think the behavior of running it unconditionally with the shell is counterintuitive.)

                                                                                                                          And read(100) does do something besides read 100 bytes.

                                                                                                                          You’re being pedantic. Obviously, under some circumstances it will set error codes, as well. It very clearly reads some amount of data, subject to the limitations and exceptions of the system; zero knowledge of Unix is required to intuit that behavior.

                                                                                                                          1. 7

                                                                                                                            I don’t see how that follows.

                                                                                                                            You claim the exact opposite behavior would have been equally reasonable. That is, the opposite of an empty shell script exiting true. The precise opposite would be an empty shell script—i.e. a script without an explicit exit—exiting false. This would affect all shell scripts.

                                                                                                                            Unless you meant the opposite of executing a file not loadable as an executable binary by passing it to /bin/sh, in which case I really would like to know what the “precise opposite” of passing a file to /bin/sh would be.

                                                                                                                            You’re being pedantic. Obviously, under some circumstances it will set error codes, as well. It very clearly reads some amount of data, subject to the limitations and exceptions of the system; zero knowledge of Unix is required to intuit that behavior.

                                                                                                                            No. Many people assume read will fill the buffer size they provide unless they are reading the trailing bytes of the file. However, read is allowed to return any number of bytes within the buffer size at any time.

                                                                                                                            It also has multiple result codes that are not errors. Many people assume when read returns -1 that means error. Did you omit that detail for brevity, or was it not obvious to you?

                                                                                                                            1. 6

                                                                                                                              If a file is marked executable, I think it’s quite intuitive that the system attempt to execute. If it’s not a native executable, the next obvious alternative would be to interpret it, using the default system interpreter.

                                                                                                                          2. 3

                                                                                                                            Saying the behavior is totally (or even partially) coincidental is a bit strong. You’re ignoring the fundamental design constraints around shell language and giving the original designers more credit than they deserve.

                                                                                                                            Consider this experiment: you pick 100 random people (who have no previous experience to computer languages) and ask them to design a shell language for POSIX. How would all of these languages compare?

                                                                                                                            If the design constraints I’m talking about didn’t exist, then it would indeed be random and one would expect only ~50% of the experimental shell languages to have a zero exit status for an empty program.

                                                                                                                            I strongly doubt that is what you would see. I think you would see the vast majority of those languages specifying that an empty program have zero exit status. In that case, it can’t be random and there must something intentional or fundamental driving that decision.

                                                                                                                            1. 7

                                                                                                                              I don’t care about how the shell handles an empty file. (Returning successful in that case is basically reasonable, but not in my opinion altogether obvious.) I’m stating that the operating system handling empty executables by passing them to the shell is essentially arbitrary.

                                                                                                                              1. 4

                                                                                                                                The reason for the existence of human intelligence isn’t obvious either but that doesn’t make it random. A hostile environment naturally provides a strong incentive for an organism to evolve intelligence.

                                                                                                                                As far as the operating system executing non-binaries with “/bin/sh” being arbitrary, fair enough. Though I would argue that once the concepts of the shebang line and an interpreter exist, it’s not far off to imagine the concept of a “default interpreter.” Do you think the concept of a default is arbitrary?

                                                                                                                            2. 1

                                                                                                                              It’s precisely specified, yes, but it’s totally coincidental that the specification says what it does.

                                                                                                                              laughs That’s really taking an axe to the sum basis of knowledge, isn’t it?

                                                                                                                          3. 2

                                                                                                                            yes an empty file signifying true violates the principle of least astonishment.However if there were a way to have metadata comments about the file describing what it does, how it works, and what version it is without having any of that in the file we’d have the best of both worlds.

                                                                                                                            1. 2

                                                                                                                              true being implementable in Unix as an empty file isn’t elegant—it’s coincidental and implicit.

                                                                                                                              But isn’t this in some sense exactly living up to the “unix philosophy”?

                                                                                                                              1. 3

                                                                                                                                No.

                                                                                                                              2. 1

                                                                                                                                Why is it weird that true need be a command at all?

                                                                                                                                1. 0

                                                                                                                                  To me, the issue is whether it is prone to error. If it is not, it is culture building because it is part of the lore.

                                                                                                                                1. 3

                                                                                                                                  I like being aware of this. Sometimes people try to improve things that are perfectly ok already and when you examine why, it’s usually because they feel that they need to do something. It happens outside of software and engineering too,

                                                                                                                                  1. 3

                                                                                                                                    Isn’t it better though to have an ELF binary which just returns 0, rather than having to start a shell interpreter every time you want to invoke /bin/true? Also, when every other part of a collection of tools (in this case GNU coreutils) follows a convention (i.e that --version prints version information and --help prints usage information), is it really better that /bin/true is the one binary which doesn’t follow that convention?

                                                                                                                                    This seems like a classic case of making the world a little bit better.

                                                                                                                                    1. 3

                                                                                                                                      Isn’t it better though to have an ELF binary which just returns 0, rather than having to start a shell interpreter every time you want to invoke /bin/true?

                                                                                                                                      I can see an alternate viewpoint where it just seems like bloat. It’s yet another chunk of source to carry around to a distribution, yet another binary to build when bootstrapping a system, and other holdovers.

                                                                                                                                      Also the GNU coreutils implementation of true is embarrassing. https://github.com/coreutils/coreutils/blob/master/src/true.c is 65 lines of C code and accepts 2 command-line arguments, which means that the binary has to be locale aware in those situations.

                                                                                                                                      1. 1

                                                                                                                                        Yep, I’d call depending on sh to deal with /bin/true bloat, if only due to the overall extra time to exec() sh in general. Times with a warm cache, not cold. Yes this is golfing to a degree, but this kind of stuff adds up. A minimal binary in my opinion is not worse, its seeing the forest over a single sh tree.

                                                                                                                                        $ time sh -c ''
                                                                                                                                        
                                                                                                                                        real    0m0.004s
                                                                                                                                        user    0m0.000s
                                                                                                                                        sys     0m0.003s
                                                                                                                                        $ time /bin/true
                                                                                                                                        
                                                                                                                                        real    0m0.001s
                                                                                                                                        user    0m0.000s
                                                                                                                                        sys     0m0.002s
                                                                                                                                        

                                                                                                                                        Even that though is gnu true, compared to a return 0 binary its also slow due to the locale etc… stuff you mention:

                                                                                                                                        $ time /tmp/true
                                                                                                                                        
                                                                                                                                        real    0m0.001s
                                                                                                                                        user    0m0.001s
                                                                                                                                        sys     0m0.000s
                                                                                                                                        
                                                                                                                                  1. 7

                                                                                                                                    My sense of the error handling issue is that Go implicitly says “We’re not going to let you hide or abstract away your error handling. We’re going to force you to make it explicit so that you really think about it.”

                                                                                                                                    When you start to use the chaining style presented in the article as an alternative (in other languages), you can hide a lot with bad names - lead the reader of the code to believe the handling isn’t there. Throwing exceptions puts people in that mode too.