Reputation
23,833
Next tag badge:
84/100 score
21/20 answers
Badges
1 50 98
Newest
 Nice Answer
Impact
~1.3m people reached

Jun
30
comment How do I make this functional DSL written in an imperative language more efficient?
Writing a parser and interpreter also defines a language. Just not one that is easy for humans to reason about, which I think is the point you are trying to make. One can define semantics on an AST itself, and postpone dealing with the concrete syntax (i.e. specifying and then parsing) until a later time. I would even say that often that is the preferable approach. People always obsess over syntax, but that's just bikeshedding. Semantics are the most important thing and for your first iteration you should pick the easiest representation possible that helps you define and validate them.
Jun
30
comment How do I make this functional DSL written in an imperative language more efficient?
I disagree with the second paragraph. Syntax is a representation ;)
Jun
23
comment Compiler time versus programmer time
@supercat Your beliefs are yours to choose, but without explanation, they add very little value. I'm not even sure what you mean by "generated code". With your major interest in C# I suppose you are referring to something as CIL. But the fact is that with any decent JIT, the final machine code that actually gets executed can depend heavily on as little as different user input and doesn't even require implementation changes. That would make C# a bad language by your standards. In the end "programs must be written for people to read, and only incidentally for machines to execute".
Jun
23
comment Compiler time versus programmer time
@supercat I'm not saying programmers should not specify invariants. Of course they should. Simply because it makes it easier to reason about. The fact that it also makes it easier to compile is a nice side effect.
May
17
awarded  Nice Answer
Apr
29
awarded  Enlightened
Apr
29
awarded  Nice Answer
Mar
25
awarded  Nice Answer
Feb
27
revised Frankly, do you prefer Cowboy coding?
added 264 characters in body
Feb
16
awarded  Nice Answer
Feb
6
awarded  Guru
Feb
5
comment Is prototypal inheritance inherently slower?
@JonathanJ.Bloggs: Yes, although that's really just a REPL with access to the DOM. Smalltalk and later Self had programming environments that were fully interactive and persistent. I think you will find Self: The Movie quite impressive.
Feb
5
answered Is prototypal inheritance inherently slower?
Feb
5
comment Leaving intentional bugs in code for testers to find
@Dunk I have pondered this a lot. We probably just have a very different culture. You seem to perceive work as a process that creates products to satisfy some metric. I think of it as a path to personal growth, a broadening as well as a deepening of skills. Circumstances change. What has been good enough yesterday, may be obsolete tomorrow. The habit of putting yourself to the test helps in transcending the volatile nature of things. Developing and following it, I think, is not a terrible idea, but one well worth the attempt and even failure.
Feb
2
awarded  Nice Answer
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk You are simply contradicting yourself. You said the number you proposed is a sensible metric. It is far from it, as I have abundantly explained. Your analogy is much better suited for your claim than mine. Why I say the idea is not terrible is because it is merely the application of the general idea that if somebody improves during training, they will do better in the field. That's why people train. Of course you cannot accurately measure the effectiveness of QA. I didn't claim you can. But suggesting to therefore not even try is a perfect solution fallacy.
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk No that is not "completely and totally false". Try reasoning in categories other than extremes. I said the number correlates more than the one you proposed. If less bugs make it into production in release B than in release A, then it can meaning anything. For example that release B was easier to get right. Or, as I said, that the programming methodology has improved or what not. Or that users do not discover the features in B and therefore do not report defects they encounter. Almost none of the effects you propose measuring say anything about the QA.
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk As opposed to that, the "false error" actually does give you more information, under the assumption that the difficulty of finding them doesn't fluctuate erratically (which can be arranged). Because you know how many artificial defects there are, you can tell exactly what percentage of them were caught in QA. So the extra information you get is how effective QA is in detecting artificial defects. And that number certainly correlates more with their overall effectiveness than the one you suggested.
Jan
29
comment Leaving intentional bugs in code for testers to find
@Dunk Then you didn't read the question properly. It suggests that this method increases morale and also thoroughness. Also the number of bugs that make it through QA doesn't reliably measure the effectiveness of the QA team. It is equally affected by how many bugs the developers introduce. If they start using TDD and there is a sudden decrease in defects in the release, what does that say about the testers? Nothing.
Jan
28
comment Leaving intentional bugs in code for testers to find
@Dunk: Keeping track of that number won't make your team better automatically, much like keeping score in a sport doesn't make you the best athlete you could be. In fact athletes do train, i.e. perform artificial tasks to increase their performance in a controllable fashion, which is not unlike what is being proposed here. Unless you have an idea how to get people to improve that number, it's of little value.