zlacker

[return to "PureOS is convergent"]
1. rossda+jf[view] [source] 2019-03-07 15:55:07
>>iBelie+(OP)
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.

◧◩
2. robto+ss[view] [source] 2019-03-07 17:16:16
>>rossda+jf
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.

◧◩◪
3. themac+741[view] [source] 2019-03-07 20:46:23
>>robto+ss
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.

◧◩◪◨
4. robto+nH1[view] [source] 2019-03-08 02:29:43
>>themac+741
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/

◧◩◪◨⬒
5. rkange+Sr2[view] [source] 2019-03-08 14:00:37
>>robto+nH1
In that land, what are you doing about UI? Still falling back on Java?
◧◩◪◨⬒⬓
6. robto+xK2[view] [source] 2019-03-08 15:58:07
>>rkange+Sr2
Nope! Usually if I need ui I reach for Clojurescript, but if I need something "native" I go for cljfx[0], a wrapper of javafx. But it's so much better than javafx - you get a really nice repl-driven, live coding plaform with functional state management and smart re-rendering.

[0]https://github.com/cljfx/cljfx

[go to top]