1. 1

    Interesting idea! How does Preql compare to Datalog? And wouldn’t the Affero GPL protect you from having your software exposed as a commercial service by others?

    1. 1

      Thanks!

      How does Preql compare to Datalog?

      I’m not very familiar with Datalog, but I think it’s a very different language. Preql is built with the idioms of procedural/functional programming, while Datalog is based around logic-programming (iirc).

      And wouldn’t the Affero GPL protect you from having your software exposed as a commercial service by others?

      No, it wouldn’t protect it from being provided as a cloud service, for example. And it would actually be too restrictive for my taste, because I want other projects to be able to use Preql as a library.

    1. 3

      I have two wild ideas about OS’s that I never have time to really develop. One is for the graphical interface, the other for the OS structure in general:

      • Combine graphical applications as if they were layers in Photoshop: one of the key limitations, to me, of graphical interfaces is that they are based around a desktop metaphor, where the screen is an office table and the windows are sheets of paper. This prevents applications from talking to one another and being combined with one another as commands can be using UNIX pipes. (I think Alan Kay pointed this out in his famous talk to OOPSLA). But it is difficult to imagine graphics applications talking to one another if you see them as sheets of paper lying on top of each other. The only way I have ever seen one “functionality” being applied after another “functionality” in a graphics environment are the layers of Photoshop, where a blur is applied on top of a color correction. This is straightforward in the case of graphics processing, but if it were applied to other applications, you could have an application that “corrects the spelling” and another one that “holds notes” and then apply “one on top of the other” as if you were working on a light table, instead of an office desk.

      • Substitute “everything is a file” with “everything is a URL”: the original UNIX metaphor does not scale well outside of a single server, which is fine because we have learned to string servers together via something called Internet, but what if we applied the larger scale to the smaller scale? Every command from the user is considered a request to be served, all system resources are identified by an unique resource location, and the role of the system is to match requests to resources. In the same metaphor, a filesystem based around database-like tables fits very well (I think BeOS introduced this idea), removing the hierarchical tree of directories. The manual pages can directly be Stack Overflow. That does not mean that everything is a remote request over the network: resources that are requested often can be cached locally, just like a browser does.

      I hope those two ideas are interesting to anyone. I just wished I had the time to pursue them.

      1. 13

        The cynical (but true) answers:

        1. Work on “greenfield” projects. Never maintain anything. The first line written in a module is always 100000x more code than an empty file.
        2. Promote whatever you write. Any person you get to use your code is a justification to continue working on that.
        3. Write your own requirements. It is easier to meet deadlines if you are supplying what you already have.

        The true (but hard) answers:

        1. Do not develop fast, develop correctly.
        2. Code, like art, is never finished, it is only abandoned. Think about the person who is going to extend/modify your code after you abandon the project.
        3. Get a lot of feedback from the person that is going to sign off whatever you ship. They are the ones that can say if you “shipped shit” or you did not. Much more telling than JIRA, in the end.
        1. 2

          When I read the title I thought you were looking for languages that were designed for remote work, but on opening the question I saw you are looking for languages that are in demand for remote work …

          I actually think that the former question is more interesting. What would a language look like, if it was designed specifically to address remote work?

          And to answer your question, I was working two years in remote mode, for a team that was around 600 km away from me. We used Python almost exclusively, but it was not web development: it was a backend service for a mobile client. I love Python very much, but that experience showed me that using it in a distributed team requires a lot of discipline and a lot of code conventions. It is not easy to convey complex requirements over a phone line.

          1. 1

            You’re right, that would be a more interesting question. Slightly less practical for my present need though :)