valw

14 ms·

91.
by valw 8y ago
That's manageable: https://vvvvalvalval.github.io/posts/2018-05-01-making-a-dat...
92.
by valw 8y ago
> 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 ev
93.
by valw 8y ago
Amen https://www.youtube.com/watch?v=f84n5oFoZBc
94.
by valw 8y ago
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
95.
by valw 8y ago
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
96.
by valw 8y ago
I don't think that's the main motive for his creating 42, but he does have a very strong anti-Grandes Écoles bias.
97.
by valw 8y ago
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 do
98.
by valw 8y ago
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 suc
99.
by valw 8y ago
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
100.
by valw 8y ago
> The best framework is always the one with the most users. What???
101.
by valw 8y ago
> 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 li
102.
by valw 8y ago
> 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.
103.
by valw 8y ago
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.
104.
by valw 8y ago
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
105.
by valw 8y ago
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.
106.
by valw 8y ago
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!
107.
by valw 8y ago
I'm sorry you feel that way, but why get so angry?
108.
by valw 8y ago
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
109.
by valw 8y ago
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.).
110.
by valw 8y ago
> 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
111.
by valw 8y ago
I don't recommend assessing languages by looking at features individually - how they play together is much more important
112.
by valw 8y ago
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
113.
by valw 8y ago
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?)
114.
by valw 8y ago
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 ha
115.
by valw 8y ago
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?"
116.
by valw 8y ago
So yeah, the best way to preserve the environment is to blow up mountains. What could go wrong?
117.
by valw 8y ago
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 awa
118.
by valw 9y ago
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.
119.
by valw 9y ago
> ...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. H
120.
by valw 9y ago
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

More ›