jffhn

16 ms·

121.
by jffhn 6y ago
>it's impossible to get close to anyone the older you get. Reminds me of: "Few people past twenty preserve a little bit of that easy affection, the one of beasts." (Céline, Journey to the end of the night) >the older we
122.
by jffhn 6y ago
Your sad comment reminds me of this stanza: "The sweeping up the heart, / And putting love away / We shall not want to use again / Until eternity." (Emily Dickinson)
123.
by jffhn 6y ago
>Everyone who has taken a class on complex systems is aware of the phenomenon of emergence. Reminds me of some conference (lost the URL) of Robert Laughlin, where he said (if I recall correctly) that rigidity (e.g. of a steel bar) was an
124.
by jffhn 6y ago
>Social Darwinism/"what is supposed to fall, you should push" I always wondered how one could misinterpret natural laws, that whatever you do you cannot not obey, as human commandments, that you can obey or not. Considerin
125.
by jffhn 6y ago
It was rewrite "from scratch" (not refactoring), but with the previous team available to answer any question (either about the legacy code or the domain, which they knew well), which was an essential part of the success (I guess a
126.
by jffhn 6y ago
>people think rewriting is a solution. It very never is. I often see this idea formulated, in this forum or in articles. >what is really broken in your legacy system. Software can be arbitrarily broken (think of only copy-pasting code
127.
by jffhn 6y ago
>how incredibly far behind software tooling is in other industries. Every time I think of how great the tools for building software (IDEs, etc.) are, that’s what I think next. What could help is having more devs with knowledge and intere
128.
by jffhn 6y ago
Reminds me of "Programmer Anarchy" by Fred George: https://vimeo.com/43690647 Except that his talk is, on the contrary, about how preferrable it can be in some contexts not to have a hierarchy enforcing processes.
129.
by jffhn 6y ago
>Saying no is one of the most important jobs of a project maintainer. It's a thankless task that upsets a lot of people. But it's critical for a project to stay successful and achieve the leader's vision. Reminds me of Bri
130.
by jffhn 6y ago
>complicated codebases) can also change in ways you don't like. You can further mitigate this risk by using simple programs that have reached a "finished" state. That's exactly the kind of thing I'm working on, t
131.
by jffhn 6y ago
>It was all pretty simple and concurrency & parallelism were never an issue. A lot of developers are not aware of what thread is going to execute their code, or of what that implies (I think it takes practice, at least it did for me)
132.
by jffhn 6y ago
I mix both: mainly using camelCase, but using underscores sometimes instead of conjunctions to make things more readable (as you say), especially to make some important meta information stand out (as in "doSomething_locked()" for
133.
by jffhn 7y ago
Most interesting, but I feel like the author is being unfairly harsh with Taylor series, slide 64: "Taylor series suck". They are indeed less accurate than Chebyshev polynomials, but computing them is a breeze, and as highlighted
134.
by jffhn 7y ago
>[widgets] should compile to a standard format, most likely WASM, and then you can use any language (...) to interface with those widgets or components. Or be based on a standard canvas-level API that would be easy to support in most lan
135.
by jffhn 7y ago
>debating spending a trillion dollars on stimulus Engineered systems can have various modes (operational, degraded, maintenance, etc.), bears can hibernate, some frogs can burrow for years in the ground waiting for better times, etc. Our
136.
Show HN: Jadecy, to compute Java dependencies and cycles
2 points by jffhn 7y ago|0 comments
137.
by jffhn 7y ago
Ok, I was talking about actually waiting (like in "while(!condition)yield();") with more code to execute at the _same_ (*) virtual time after the wait, not taking care of having some code executed _later_, which is indeed
138.
by jffhn 7y ago
I meant rules out for the domain code that you want to be able to run in a single thread, which should be by far most of the code (unless you ensure that whatever your code wants to wait for, has then necessarily already happened, but that
139.
by jffhn 7y ago
>simulation of an entire FoundationDB cluster within a single-thread! Reminds me of an InfoQ post about simulating robot swarms in a single thread: https://www.infoq.com/articles/java-robot-swarms/ (links to Ja
140.
by jffhn 7y ago
Yes, I guess the proof is only relative to the formal spec, if the spec (formal or not) is nonsense it's another problem (so you might not have to test the program, but still have to test the complete system). But I guess (again) that
141.
by jffhn 7y ago
>critical software goes under a much more rigorous testing regime Testing is not only not enough, it's also not required :) (as Dijkstra said, it can only show the presence of bugs, not their absence) For example, the software for s
142.
by jffhn 7y ago
Agreed. When I consider the complexity of a piece of software, I always take into account the conceptual weight of all the stack behind it, down to ubiquitous basic constructs like primitive types, conditional operators, etc (but simple bin
143.
by jffhn 7y ago
From the article: "the view of many of our economics colleagues (...) that technology will always find a substitute for any depleted resource" Natural resources depletion has been deliberately overlooked by classical economics fro
144.
by jffhn 7y ago
>Developer productivity is not linear in function of task difficulty. Tried to come up with the draft of an equation (upgrades welcome ;): cDev = capability(dev); // > 0 dTask = difficulty(task); // > 0 ssttTask
145.
by jffhn 7y ago
>logic as you conceive it is incomplete Don't we all know that at least since Gödel. >very obvious axioms, like excluded middle I don't consider it something obvious. If you read Nagarjuna's Mulamadhyamaka-Karik, you mi
146.
by jffhn 7y ago
>dismiss facts that don’t fit their worldview I find this disconnect from reality especially fascinating in the software field, where nature's answers are just at our fingertips, and where we just have to open an editor or launch ou
147.
by jffhn 7y ago
>Many human philosophies reject logic (Or any mechanical system of derivation) as a valid epistemological device. People can reject what they want, but rejecting hammers doesn't make them less capable of hitting nails. >logic rem
148.
by jffhn 7y ago
Reminds me of a complementarity I sometimes see between being in society, which allows to share, collaborate, etc., and being in solitude, which allows to think, contemplate, etc., and of a south american indigenous tribe I forgot the name
149.
by jffhn 7y ago
>Microservices enforce separation of concerns Depending on where you work, it can be a problem, because the separation is not always appropriate, and can for political reasons be much harder to revert when visible at the service level (f
150.
by jffhn 7y ago
I like his view on how interfaces should be self-revealing. I used to feel dumb and waste time trying to figure things out, but then I decided that if I wouldn't get something quickly enough, that's because it was badly presented,

More ›