Reputation
23,924
Next tag badge:
85/100 score
21/20 answers
Badges
1 51 99
Newest
 Quorum
Impact
~1.3m people reached

Jul
20
awarded  Quorum
Jul
16
awarded  Good Answer
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.