1. 10

@logc said in response to this thread:

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?

I had the same response, and I too would love to hear Lobsters’ thoughts on this question!

I’m interested because, just like the author of that post, I’m interested in my next position having more of a remote or remote-friendly structure.

It seems fairly reasonable to assume that, following Conway’s law, the best architectures for remote work are pretty service-y, requiring a minimum of coordination between engineers. I wonder if you could claim that languages with sophisticated, robust concurrency models, like Erlang, in addition to lending themselves to that kind of architecture, also lend themselves to development by more distributed, independent actors.

It also occurs to me that the simple fact of module (that is, file) size would also have an impact. If only for minimizing VCS collisions: the closer the correspondence between a module and a single class/entity/what have you, perhaps the less the likelihood that developers will step on each others’ toes.

  1.  

  2. 5

    I work remotely and so far everyone’s mostly on the same path.

    I think it’s easier to answer it the other way around though. Why aren’t some languages good for remote work? Well… I do a lot of C++, and my compile times are like 40+ minutes for a full rebuild when I change something deep within Unreal Engine 4. My onsite coworkers use Incredibuild (actually SNDBS), as such their compile times are a fraction of mine. That makes C++ not fun to work with. I’m sure many would argue that it’s the codebase that causes the problem, but the language definitely plays a huge roll in it. Epic solves this by throwing infrastructure at it (ala Incredibuild) instead of trying to work around problems in the language (read: lack of modules, template bloating, etc).

    An absolute killer is binary files. So any binary serialized scripting system is terrible. They are bad enough onsite, but combined with exclusive locks it’s so much worse remotely. Onsite you can just roll over and ask the person with the lock when they’ll be done with it. Remotely it’s slack, they may look away and miss the message, you have no idea if they are at their desk, in a meeting, or out to lunch. It just slows everything down so much.

    1. 4

      One way to look at it is what life-features are useful in remote work and then go backwards from there. For example, as a remote worker I wish devices didn’t matter and I could just sit at any device and it would be setup exactly how I like it and I could just start using it and it would be magically on a network that lets me do my work. Right now I lug around a laptop and need VPN software installed and if my laptop breaks I have to get a new one and set it up again (which can be easy but only if you prepare for it).

      In that sense, I want an OS that supports this kind of work. If anyone’s see The Expanse, they can take their little pocket device and flick towards an screen in their area and now they are using that screen (MSFT was trying to do something like this with Continuum which I think is dead and Motorola with Altrix). For all of that to work, I think you need a safe language that makes writing robust network code easy but also makes interface with the OS easy. Maybe something like Mozart/Oz which supports this idea of moving data around.

      Of course, the above is all a cool fantasy. In reality, I don’t find being a remote worker changes how I work compared to an office. When I’m writing code I either run it locally or on a cloud machine, just like if I were in an office. The networking is the same except I need a VPN rather than just being on the office’s network. The actual mechanics of working remotely are the same, just talking to my coworkers is harder. I guess what I’m saying is I don’t think technology really changes here, it’s social.

      1. 2

        Seems to me like you just want plan9 (With a network of terminal servers in public spaces).

        In an ideal world you could carry your filesystem server in your pocket and use public cpu servers when doing computations the public terminal cant handle.

        1. 1

          It’s even more than that. Being able to move running applications across hardware, for example, not just the display. Or instead of firewalls having authentication everywhere and fractal so I can connect to anywhere from anywhere. There are a lot of structures that would need to change and a lot of how we do things to hit this ideal.

          1. 1

            Hhmm the closest thing I can think to moving running applications across hardware is the Acme Dump / Load command, which is really just dumping a snapshot of acme’s state in a file and loading the file at a later date. I use it so I can switch projects and still keep the context I had last time. Especially useful given acme’s way of writting commands in tag bars. I’ll sometimes share those files over the network and use them on a another machine, in which the file hierarchy for that project is the same.

            But then, that’s a lot less powerful, and only makes sense in plan9, where you can import a hierarchy of files from one machine to another.

            1. 1

              There is a bunch of work done in academia about for this. For example Mozart/Oz lets programs be moved across machines. I believe Tom7’s dissertation offers some ideas on this as well:

              http://www.cs.cmu.edu/~tom7/papers/modal-types-for-mobile-code.pdf

        2. 1

          The X Window System has been capable of this since I think the ’80s. The X Server has a message protocol and one server can serve multiple clients at the same time. A while back Joe Armstrong of Erlang fame even hacked together a simple client library that can talk to X: https://3e8.org/pub/scheme/doc/p1-armstrong.pdf

          Thanks to Erlang’s concurrency model, talking to the X Server turns out to be really easy:

          Label1 = swLabel:make(Win,10,10,220,30,0,?cornsilk,”First name:"),
          Entry1 = swEntry:make(Win,140,10,120, "Hello"),
          Label2 = swLabel:make(Win,10,60,220,30,?cornsilk, "Last name:"),
          Entry2 = swEntry:make(Win,140,60,120,"World"),
          Button = swButton:make(Win,10,100,120,30,?grey88, "Swap"),
          
          Button ! {onClick, fun(X) ->
            Val1 = Entry1 !! read,
            Val2 = Entry2 !! read,
            Entry1 ! {set, Val2},
            Entry2 ! {set, Val1}
          end},
          
          loop().
          

          Under this model, you send messages not just to the server but to the individual widgets, e.g. telling them what to do to handle events.

          1. 2

            Yes, I know about Erlang and X11. I know the X Windows is capable of doing the client server thing (very insecurely, mind you) but that is only a small part of what I’m talking about. I still need to be on a network that can connect to the X server and on a network that my work is on, etc.My data needs to move around the world with me (securely). there are a lot of components missing.

        3. 3

          I think the biggest thing that would be nice for a language designed for working remotely is encouraging designs that make it easy to isolate parts of your system during development. This leans in a functional/pure data sort of way, but generally reducing the need for VPN/WAN network IO to a database would be the biggest gain I could see for my current day to day work in a remote specific context. Being able to quickly, safely and correctly break pieces out (Erlang seems better than average at this, but I’m not very experienced with it) would be the sort of thing I’d aim for.

          1. 3

            I might need to think about this a bit, but I don’t think right now that there’s much to do at the language level for favoring remote work. Most of what I can think of is good architecture that applies to any language - at all levels, many small modules with strict barriers between them. Isolate as much code as possible in small classes/modules, isolate groups of classes and modules into microservices, DLLs, shared libraries, etc.