Comment by rossdavidh

7 years ago

This reminds me of the idea of "wouldn't it be great if we could use the same programming language for frontend, backend, and database queries". Well, maybe, but in practice not really. They are doing different kinds of things, you will have to use them differently, it doesn't really help all that much to have the same language. It SOUNDS like this would be really helpful, until you get it, and then discover that it doesn't really help all that much, because what matters most is not the language syntax, but the problem space.

Laptops and smartphones are made for doing different kinds of things. The real-estate requirements are different, as are the typical use cases, and even in the case where you solve them both with, for example, dynamic web pages, you still end up coding for both use cases separately, you just now have it all stuffed into the same codebase, which is harder in many cases instead of easier.

I believe Microsoft has been trying to make all OS usecases the same for decades. I believe they have not succeeded, not because Microsoft is deficient somehow, but rather because it's not, fundamentally, a good idea.

You can live that dream in clojure land! Clojurescript on the front end, Clojure on the backend, and datalog/honeysql for the database if you'd like. And it is awesome! After using a stack like this I'm spoiled for the slog that is developing in separate languages for each of those things.

I think that dream is possible with OS usecases as well, it's just that nobody has made it work yet. And I can't think of a better way to eventually get there than to build it slowly out of free and open source software. It might take a while, but since people have the ability to adapt the software to their needs when it is free, I'm confident with time that it will serve those needs.

  • It never works out that way though.

    Clojure for the frontend? What about native APIs that you need to use on, say, iOS or Android? What about graphics libraries and APIs? What about browser APIs? I'm sure you can write your own wrapper or bindings for whatever you need, but it's an ongoing effort/pain that isn't worth it for most people.

    Every platform, backend or frontend, supports specific languages that are suitable for the platform's problem space and are subsequently preferred by the platform's community. Software rarely stands alone. You can always go against the grain with your own efforts, but it's no longer a dream, just another compromise.

    • In my experience, it works just fine.

      Clojure for the frontend is the best-in-class frontend dev environment that I've worked with. Instant hot code reloading, a browser-connected repl, great debugging tools, and a really nice collection of libraries for getting stuff done. I've never had to use native APIs for iOS and Android, so I can't speak to that from experience, but I know that there's some really nice machine learning work that's done in Clojure[0]. One of the main bits of Clojure philosophy is to just embrace the host platform, and our company has done that very successfully.

      I think I agree that there are compromises, but on the whole I've come out pretty far ahead with the tools I get to use. My point, though, wasn't to proselytize for Clojure (even though I do love it!), but to point out that there are ecosystems that have made significant progress towards this idea of convergence, and that some people (me in particular) are very happy to be moving in that direction. I'm excited to see progress on the OS front.

      [0]https://dragan.rocks/

      4 replies →

  • I'm glad it's working for you. My usual work involves python, javascript, and occasional SQL, and really the syntax is not that much of an issue. The problem space difference matters a lot more (for me) than the syntax (which an IDE can help me with anyway).

    I think part of the motivation was also managers thinking they could easily shuttle developers between frontend, backend, and database work, and that has mostly not worked out, because what takes time to learn about each is not the language, it's the problem space and the tradeoffs.

    But, if it's working out for you, I'm glad it is. I was not impressed.

  • You can live that dream in clojure land!

    Spending 70% of your time doing tedious interop doesn't sound like living the dream ;)

    • For what it's worth, I've been writing Clojure since 2013 and I can count the number of times I've had to write interop code on one hand. And in those cases it was a wonderful escape hatch! That's probably more reflective of the type of projects I've worked on than anything else, but it's my experience and I don't think it's that unusual.

Just for myself, I will say that I know how to do some amount of management on Linux. That the same sort of thing is available on the phone, and that I could use that knowledge out of the box, is exciting to me.

For example: SSH clients and servers. I've tried playing with various apps from F-Droid to make it happen, with varying success. If I have just Linux, I know what should work. Another one is backups. I have a better sense of what I need to back up on a common Linux system than an Android-like one.

  • I'm totally with you here.

    Last year, I realized that the direction that smartphones have taken is not a direction that is good and useful for me, so I decided that I'd better design and build my own smartphone before I need to replace the one I have. I have it breadboarded up and fundamentally working. It should be completed this year.

    One of my very first decisions was that the phone was going to run ordinary Linux, for all of the reasons you cite. I'm VERY excited about being able to ditch Android!