amw-zero

17 ms·

211.
by amw-zero 5y ago
And he had a condescending tone from the beginning (as he always does). Maybe if he was more respectful / likable, the developers would have responded better.
212.
by amw-zero 5y ago
Found one in the wild.
213.
by amw-zero 5y ago
Yes
214.
by amw-zero 5y ago
I have never come across a popular CS paper that was not available on the web, for what it’s worth. Maybe some of the lesser known papers are lost, but all of the important ones, such as Codd’s writing, are very easily accessible with simpl
215.
by amw-zero 5y ago
Such a format would not matter, because most programmers are anti-research, anti-math, and anti anything other than shipping Agile software.
216.
by amw-zero 5y ago
Some references to the state of the data world in the 70s is found Codd’s initial paper itself: https://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf . I strongly recommend everyone pick up basic set theory no
217.
by amw-zero 5y ago
> How are those types any different than outright stating a behavioral invariant? Because the behavior of programs can't be verified without executing the program, but types can be checked purely based on syntax. There is way less s
218.
by amw-zero 5y ago
The trivial bugs that type systems are catching are in the most basic type systems that we know about. Types are not just what is present in Java, types are any proposition that can be made about a program before program execution. The prop
219.
by amw-zero 5y ago
That is a VM running in a web browser. If I was thinking about a joke that was so comically far away from the metal, that’s pretty much what I would use as an example. This is why it’s very difficult to have conversations. Most programmers
220.
by amw-zero 5y ago
Have to jump in on a TLA+ comment, especially one about how it handles “types.” I say this all over the Internet - the way that TLA+ handles types is the absolute ideal from the programmer’s perspective - there is nothing special about them
221.
by amw-zero 5y ago
You learned one way of programming, and that’s how you think. Nothing wrong with that. But, many people are used to the functional paradigm. That that’s baffling to you is strange. People have different perspectives.
222.
by amw-zero 5y ago
Here’s a talk where someone shares proofs within the sel4 verified OS project: https://youtu.be/AdakDMYu4lM .
223.
by amw-zero 5y ago
How is ML syntax any different from Typescript?
224.
by amw-zero 5y ago
This just means that you thought of something in the test suite that wasn't in the spec. You can underspecify something.
225.
by amw-zero 5y ago
Can you initialize a kernel with JS?
226.
by amw-zero 5y ago
It boils down to two camps: open to formal methods, and not open to formal methods. And, I would say the overwhelming majority of developers, especially here on HN, are in the "not open to formal methods" camp. I can find comments
227.
by amw-zero 5y ago
That’s an interesting example, that’s exactly where you’re likely to find bugs - at boundary values. You should test those more than you should test the number 5. This is exactly why unit testing gives a false sense of security. You’ve done
228.
by amw-zero 5y ago
Well, by this I mean math (and mathematical logic). Math is the tool for reasoning about possibly infinite concepts, i.e. you can make a statement about infinite sets and still know if it’s true or not. We aren’t limited to what we can see
229.
by amw-zero 5y ago
Correct, there’s still nothing stopping us from writing the wrong spec or writing an insufficient spec, but there’s really no solution to that problem anyway. And the same problem exists with tests today - you can have an insufficient amoun
230.
by amw-zero 5y ago
Yes I agree - I have been a testing fanatic for the better part of the last 10 years, after being absolutely paralyzed at a company without tests. But, after all this time, I believe their cost-to benefit-ratio is horrendous. It’s fairly co
231.
by amw-zero 5y ago
Now you understand - testing is extremely close to useless. You can't perfectly choose the test cases for code without looking at its implementation. And by that point, you are just testing the implementation and working backwards. Wha
232.
by amw-zero 5y ago
Yet it's extremely popular to have huge, inefficient test suites running on continuous integration servers hundreds of times a day. It boggles the mind.
233.
by amw-zero 5y ago
They're in your source code - they are reachable.
234.
by amw-zero 5y ago
You don’t even need to do a study to arrive at this conclusion. Has no one read Djikstra’s writings? https://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF “Program testing can be used to show the presence of
235.
by amw-zero 5y ago
Well, coverage can still tell you that this line is not covered at all. The absence of coverage is a signal, but the presence of it is not sufficient to prove that the code works for all inputs. We’ve also known this since forever, this has
236.
by amw-zero 5y ago
They go hand in hand. It’s obvious that missing branch coverage means your data cases are not exercising all of the edge cases in the code.
237.
by amw-zero 5y ago
I've been replying to you in other threads. There is no answer to this question, it is an art. I understand that it's frustrating, but that doesn't make it any less true. As far as what the goal of the art is - the goal is to
238.
by amw-zero 5y ago
Forming your bounded contexts based on technical complexity and team configuration is certainly not advocated by DDD. Is "larger than 10 software engineers" a rule that domain experts would suggest? Would that be in the ubiquitous
239.
by amw-zero 5y ago
> Try to mininimize the overlap between bounded contexts - loosely coupling domain models. What if this doesn't lead to a more accurate representation of the domain? What if two contexts are just coupled in the business, for good re
240.
by amw-zero 5y ago
It may seem like common sense, but I have worked with many people who don't understand the importance of the actual software reflecting the domain that is being served. It's funny that DDD is criticized for being "too technic

More ›