valw

That's manageable: https://vvvvalvalval.github.io/posts/2018-05-01-making-a-dat...

> The Events here give up on the naming, granularity, and semantics problem: they're extremely low level fine-grained changes to fields in a database.

You say "fields", I say "facts".

Which of a set of nominal events or a graph of facts is higher-level will ultimately depend on the domain, but using Datomic over several years now has led me to think that it's much more often the latter than conventional Event Sourcing has trained us to believe.

In fact, it may well be that Event Sourcing has traditionally been relegated to those (few) use cases where the "set of nominal Event Types" approach is better, being the only situations where conventional Event Sourcing is practical.

> Events themselves are no longer interesting or semantically meaningful, because they're a single atomic change to a database field. A change in the way state is represented means a different set of events is produced. Subscribing to meaningful occurrences in this model is difficult,

Datoms are not 'single' or 'atomic' - they're packed coherently together in a Transaction, and are immediately relatable to entire database values. Subscribing is just pattern matching, and is not hard, as the following section of the article tried to show: https://vvvvalvalval.github.io/posts/2018-11-12-datomic-even....

> [...] and probably will eventually result in the creation of a "meta-event" for each action that contains the semantic intent of the outcome.

Which would only bring you back to the 'set of nominal Events' case, so it's not a regression compared to conventional Event Sourcing anyway. That's what the article meant by 'annotating Reified Transactions', and that's something you can even do after the fact (i.e in a later transaction, when the requirement for it becomes apparent) which means that you don't have to get these aspects rights upfront, nor commit to them.

For a more in-depth discussion of Datomic's Reified Transactions, I suggest this talk by Tim Ewald: https://docs.datomic.com/on-prem/videos.html#reified-transac...

Amen https://www.youtube.com/watch?v=f84n5oFoZBc

It really depends on how long you wait before making the students sensitive to these issues.

Wait 6 months or 1 year, and you've given them time to gather sufficient experience for motivating a more mindful way of working.

Wait 3 years or more, and you've just taught them bad habits.

I'm tired of interviewing candidates who were supposedly trained extensively in programming, asking them "how do you approach making quality software?" and hearing the usual "oh, I indent my code and write a lot of comments" as an answer.

I never wrote "think before you code", and agree that's not always the most suitable way to go about a problem, although I believe a lot of programmers would benefit from doing that more often.

I wrote "think about what you're doing".

I don't think that's the main motive for his creating 42, but he does have a very strong anti-Grandes Écoles bias.

Even without the burden of understanding business requirements, it still takes programmers a fair amount of analysis to program without making a mess that will kill their ability to make progress; learning the latest JavaScript framework does not help at all in that regard. I'm glad to hear you manage, but your employer may want to consider hiring fewer programmers and paying them higher wages - I know a lot of companies would benefit from that.

Sure, but this doesn't tell us anything about the role 42 played in these successes - there's also a fair number of successful entrepreneurs without any higher education, should we infer from it that no education is the key to success?

Having interviewed a bunch of 42 graduates, my main issue with 42 is that it doesn't teach their students to think about what they're doing, encouraging them instead to rush to the keyboard and emit as much code as they can as if programming for the last day of their project. This seems to resonate well with the culture of piscines at 42.

To me, this is as silly as training Biathlon athletes to not even aim before they shoot.

So far, I've always ended up not recruiting the candidates, because they would have made a mess of the codebase in no time, bringing negative net productivity to the team (more so than most junior candidates I've seen). And this was for jobs in a startup!

I wish 42 would teach them the necessary insights to program sustainably - that's where teachers and mentors are indispensable, and that's the rare skill most companies are lacking. Anyone can pick up tutorials and read manuals on their own. Make them developers, not eternal coding beginners. I'm not asking for an academic or scientific focus, just a good philosophy of programming in general, the kind of which you see in SICP for example.

Unfortunately, 42 does not have a monopoly on producing short-sighted developers in France, by far - that's the case of most "learn to code in X days/months/years" programs.

> The best framework is always the one with the most users.

What???

> Out of curiosity couldn't you just treat queries as a composable AST and "compile" the query text from that?

You could write such a wrapper, but it won't be standard, which means that there will never be a robust library ecosystem and set of practices that arises from that. If GraphQL was to evolve, you also wouldn't be sure your wrapper can express all of GraphQL. Finally, this would add new practical hurdles, like a new dependency, additional runtime cost of compilation, obscured source mapping, etc.

Meanwhile, because GraphQL is just a text-based DSL, most people don't have a clear idea of the _information model_ of GraphQL queries - you have to read the spec to get this idea. If we are to build a robust ecosystem on top of GraphQL, this information model should be evident in the API.

All these problems are present, and very damaging, in SQL.

> if you have db schemas on the backend if using orm, get ready to duplicate them again for graphql.

I would consider this a weakness of ORMs, not of GraphQL.

Sure, but as always in software that's still better than the speculations of people who have no experience using it but think they can make an informed comparison.

We migrated most of our backend (written in Clojure) from REST to GraphQL (actually a homemade alternative to GraphQL, but not relevant to this discussion).

It went well, it greatly simplified both our backend and frontend code. The backend code got simpler and more stable because it no longer had to deal with "data packaging". The frontend code became more transparent, because you can now easily read what data gets exchanged, and more decoupled, because different components can independently require the data they care about. One of the biggest benefits has been the degree of independence to evolve both the client and server.

We haven't had the performance issues some people have mentioned (N+1 query etc.), because of the server-side design of our homemade GraphQL engine - in which data resolvers are batching and asynchronous by default, unlike most backend libs which approach this problem more naively. Will open-source that soon.

The biggest limitations I see to GraphQL are:

- it doesn't really have a story for caching. I have some ideas for addressing that, but it hasn't been a problem for us really.

- it repeated the SQL mistake of exposing a query language based on text, not data structures. Now we have to write queries as templates instead of assembling them programmatically. This hurts both application developers and library authors.

- it doesn't really have a story for structured writes.

A lot of past knowledge is also very available and mostly ignored. Even the most popular books about programming are read only by a tiny minority of programmers. Listening to our elders is simply not part of the current programming culture.

While Clojure has failed to become mainstream so far, it certainly hasn't failed to be influential. Whatever programmers use in a generation, it may have a lot of ideas from Clojure in it!

I'm sorry you feel that way, but why get so angry?

The innovation dynamics in the software industry are (have been) really different than in these fields IMHO.

But there are some similar historical precedents. Fourier's work was rejected in his time because Lagrange wouldn't adopt his approach to mathematics.

This video is a great retrospective on the evolution and adoption of programming languages / paradigms: https://www.youtube.com/watch?v=JxAXlJEmNMg

Revolutions do happen! For instance, JavaScript, with all its defects, brought a lot of great ideas to the mainstream (first-class functions, data literals, etc.).

> Not so sure about this. I see more of a trend to repeat previous errors because the industry as a whole quickly forgets lessons.

It is a necessary condition, certainly not a sufficient one

I don't recommend assessing languages by looking at features individually - how they play together is much more important

Sure, but I do hope that there's at least one revolutionary jump per generation. If the next generation ends up with Kotlin, we'll have missed ours

Totally agree - and "new paradigms" isn't the same thing as "choke-full of paradigms". What's more, there's as much value in taking things away than in adding them (how about classes for example?)

I have nothing against Kotlin, but we should be much more ambitious for the Next Generation of programmers. There's so much more progress to be made in (mainstream) programming languages than the tiny step from Java to Kotlin.

As it has always been in the history of programming, what it takes for this potential to come true is for the current generation of programmers to retire, leaving room for fresh paradigms.

Imagine if all the industry got one generation after Assembly language was "hey, we've made the instruction codes shorter and an IDE that can navigate to line numbers".

This makes me think of Rich Hickey's Hammock Driven Development: https://www.youtube.com/watch?v=f84n5oFoZBc

- "Stay away from the computer" - Start by asking: "what is the problem?"

So yeah, the best way to preserve the environment is to blow up mountains. What could go wrong?

Or, you know, maybe we could just emit less CO2 to start with.

To be clear, I'm all for research about carbon sequestration, but it should not be an excuse to keep polluting irresponsibly. On the long term, we simply can't get away with compensating all our big negative impacts with big positive ones - how about introducing some moderation in our lifestyles instead?

This sort of feedback would much more helpful and credible if you added what sort of project you're using Rust on, your technical background, and concrete facts (not just metaphorical opinions / complaints) about what goes wrong. As it is, this article helps no one make informed technology decisions. See https://vimeo.com/9270320.

> ...it is not appropriate for a system that has performance requirements

This is an unreasonably simplistic approach to assessing performance. A useful approach would be to describe what workloads Datomic may or may not be suited for. Having used Datomic (On-Prem) 2 years in production, here's my take on it:

1. For a system that writes a lot (eventually leading to 10 billion datoms or having high peaks of write throughput), Datomic is not a great fit, because it has a single writer thread and does quite a bit of indexing. 2. Reads are horizontally scalable, and because Datomic's semantic allow for pervasive and reliable cacheing, reads can handle a huge load, and have low latency for OLTP-style queries. 3. Datalog is relatively slow for aggregations, and offers no facilities for trading accuracy for speed: if you need big, low-latency aggregations, you should offload it to a specialized store like ElasticSearch. This is especially easy to do with Datomic, because Datomic makes it trivial to implement change detection, in-real time if needed (see Log API and txReportQueue) 4. When writes are overwhelmed and become unavailable, reads stay available, which is an awesome situation to be in.

This looks a lot like Clojure's standard library, and you could probably steal more ideas from it, e.g transducers https://clojure.org/reference/transducers