A one way to address that is via tooling (e.g. to visualize state across time) but maybe there’s something more fundamental to be solved here? Or is it more about current tooling capabilities?
What? Does the idea of employment seem kinda novel in this take?
You can gain significant impact multipliers by focusing human attention on a single goal. And not many things do that better than throwing money at a problem.
However with individual's reach extended, the complexity and frequency of collaboration only increases so naive approaches get overstretched and, eventually, break.
If a person belongs to the society, then sick, suffering people are not a value but a cost and killing them becomes net gain for society.
It's very dangerous to give away body autonomy freedom to the collective as it could be potentially weaponised to target not only sick, old and poor but political opponents as well.
I understand your worry, but I've had a quite opposite take on this.
I think we can agree that it's not that hard to find ANY job as an experienced developer. However it's much more difficult to find a great, satisfying job. For that you need to navigate around a lot of corpo-bullshit type of projects, and Clojure has served me well as a useful filter in doing that.
My reasoning is that Clojure is niche enough that when company is using it, you can assume that it's due to a deliberate technical choice, and not just because of its popularity. That tells me two things that are symptomatic, in my opinion, of a healthy tech company culture:
- tech decisions are made by engineers, not by top-level executives,
- their conclusions and bets align with mine because we all see and agree on Clojure's edge over more popular solutions.
Admittedly, there's always a risk that someone just followed the hype and got out of their depth but I think this risk is relatively small, because Clojure's no longer a new kid on a block and choosing a tech stack is a major decision and usually done by senior tech leadership, hopefully less hype driven.
Of course, Clojure is no silver bullet and it's just a tool that gives you enough rope to hang yourself. Messy codebases are just as possible as in other languages, especially when the team is new to lisps that are very different from mainstream languages, but that's a nature of software development - you learn with the experience. I do cringe when I look at the Clojure code I wrote when I was just starting and wasn't fully grasping Clojure's way of thinking, but the more I use it, the more I come to appreciate how powerful it is.
Having said that, no software project is ever complete and so isn't Clojure as an ecosystem. The tooling is constantly evolving and new patterns are emerging. What's great about Clojure open-source community is that everyone seems to share the desire to harness complexity and Rich Hickey has convinced each one of us at some point that the way to do it is through simplicity https://www.infoq.com/presentations/Simple-Made-Easy/
Even within Clojure's community there's a diversity of approaches, and I think it's necessary to improve and evolve. The more recent trend, I've noticed is that the community is converging at Data Oriented Programming that's applicable in other languages as well, but has always been at the core of Clojure's mindset that is especially well suited for it.
Moreover, Clojure has already grown past the threshold of being just a niche toy and has sufficiently big market that it won't die off anytime soon. When you study history of programming languages, you'll notice that it's enormously difficult thing to do for an emerging player, especially without big corporate backing. And Clojure is as grassroot as it gets: https://clojure.org/about/history
However, the most important part is that Clojure is a very powerful piece of technology that made me reevaluate what software engineering really is.
You can efficiently use Clojure for both backend and frontend with easy access to libraries from JVM and npm so you will never run into the problem, common in other niche langs, of too few libraries.
Nevertheless, Clojure's own ecosystem is filled with many great, cutting-edge ideas that you wouldn't find working so well elsewhere. The community is very welcoming, growing and diverse with people coming from all different programming backgrounds - all sharing the disillusionment with other programming languages and determination to find and build a better way.
- access to both two largest ecosystems JVM, npm and of course clojure's own amazing libraries,
- vibrant and diverse community, converging people from all different programming backgrounds,
- much, much more.
Rails and Django are a bit tied to 2005ish MVC paradigm and while it's reliable and gets job done, it comes with compromises on flexibility and user experience - making it hard to be competitive in 2022 as a solo founder. Clojure on the other hand is known for empowering single/few developers to outcompete much larger teams.
Seriously, forget about Rails and Django and just focus on Clojure.
The punctuation serves a purpose of separating thoughts from each other and conveying the tone.
In messaging apps you separate thoughts by sending them as separate messages and convey the tone through emojis.
In the time-stressed and client-diverse environment of synchronous text conversations punctuation becomes redundant.
Nowadays, you can get VSCode support for Clojure pretty much out of the box with calva[1] extension working together with clj-kondo [2] almost without any configuration. It works great - I've switched over from Cursive and I'm not looking back.
Low code platforms, at their core, allow you to define the software with data (from predefined components usually through UI) and that's how they enable super productivity, until you hit a wall.
Data Declarative programming paradigm could potentially achieve the same levels of productivity without its limitations but it's very difficult to get the right implementation.
The most interesting development in this area I had found, is Fulcro Rapid Application Development Tools [1] - a fullstack clojure framework that's performant, declarative and extensible.
RAD is still alpha but it bases on battle-proved Fulcro. Once you hit the limits of declarative RAD you can easily extend it with regular Fulcro components which are, in their essence, a cheap abstraction over React/React Native components - offering industry standard performance.
> UBI is one of those ideas that is theoretically awesome but doesn't survive contact with reality
You don't know that - you just base it on your theory.
Of course, every idea gets perverted by current political system, but the problem is often not the idea itself.
Huge appeal of UBI is that it's simple hence easier to control. Taxes were supposed to be simple too and yet they got overcomplected to serve the special interests.
The danger of abusing UBI for political gains is as real as it happened with taxes, but it doesn't mean the idea is inherently bad - we just have an inefficient and harmful government system and fixing it should be a priority if we want anything nice like properly implemented UBI. Another Yang's idea, Ranked Choice Voting could at least mitigate some of the issues like political bipolarity.
> Probably minimum wage would have to be raised so that people would want to work as a maid or McDonald
The beauty of UBI is that government mandated minimum wage, with all its drawbacks, wouldn't be needed anymore. People would be able to refuse shitty job offers and not starve. Ultimately, employers would have to raise wages but not because of the law but because of workers' better negotiation position.
It needs to be universal so it doesn't penalize work. If there's any set limit, it'll create pathologies around it like people not taking up a job because it would lead them to loosing money/time.
The downsides are not clear to me as well. The only argument I could think of is a nationalistic sentiment that nations should live & work together but I find it poorly motivated in a global world. I see, however, a lot of benefits of easing out the wealth distribution geographically. And you rarely want to live in the cheapest 3rd world country far away from your family. It's a CoL-vs-comfort balance you need to figure out for yourself - no calculator will be 100% accurate here.
I've been riding this ride through most of my career, working remotely for western startups mostly from Poland. In the end, I don't care how "fair" your compensation policy is - it all comes down to the best alternative offer.
The original question made this mistake probably because the poster didn't know it but Pathom is the actual alternative to GraphQL-based APIs.
Datalog solves a subtly different problem of querying the data, while Pathom/GraphQL/REST is about exposing the data (interfacing?) as API.
It's more like:
Pathom vs GraphQL-based API (vs REST)
and
Datalog vs SQL (vs NoSQL)
The mainstream is in the process of migrating from REST to GraphQL, but I think Pathom could be the black horse in this race.
Just watch the last part of Wilker Silva's The Maximal Graph talk to see the potential:
https://youtu.be/IS3i3DTUnAI?t=2080
Rails were successful in the 2005-2015 era of server-rendered HTML but today MVC + REST API might not be enough anymore for solo founders to compete in multi-platform, client-rich reality.
After spending of +4 years working professionally with Ruby on Rails I've grown aware of its limitations. I've spent a long time searching for its successor in my programmer's toolbelt. I've waded through numerous Javascript frameworks yet every one of them proved to disappoint me after taking it for a spin.
I've finally arrived at Clojure at the beginning of 2019 and it has been really refreshing. I love how well designed the language is, how mature the community is and I am amazed by the quality of the ecosystem.
A one way to address that is via tooling (e.g. to visualize state across time) but maybe there’s something more fundamental to be solved here? Or is it more about current tooling capabilities?