Reputation
16,311
Top tag
Next privilege 20,000 Rep.
Access 'trusted user' tools
Badges
1 41 64
Newest
 Guru
Impact
~226k people reached

Jul
7
comment Shouldn't documentation be written together with tests rather than in the code?
That may make the implementation simpler (though I honestly doubt it, just getting the data out of there may require severe metaprogramming gymnastics), but I don't see it being better for the people who read and write the documentation. For starters, look at all the extra punctation and consider that many characters in string literals need escaping.
Jul
7
comment Shouldn't documentation be written together with tests rather than in the code?
And you think this is an improvement over existing markup languages for documentation (doxygen, reStructuredText, markdown)?
Jul
7
comment Shouldn't documentation be written together with tests rather than in the code?
What DSL would you write comments in? It's essentially free-form English (or whatever language you are using). The only formal bits belong to the markup language, and there's very little use in exposing those to the compiler/interpreter of the implementation language. It probably makes the documentation uglier as you have to adjust syntax to make it valid code in the implementation language.
Jul
7
comment Representing floating-point numbers in bytecode
Lua is more like OP's first option (go native, accept portability problems). The Lua bytecode format isn't intended to be portable, and (as the "normally" indicates) the number type can vary depending on how Lua is compiled.
Jul
4
comment Demonstration of garbage collection being faster than manual memory management
@GuySirton s/native/AOT compiled/. Also, yes and no. In the JIT-vs-AOT case, it's the AOT compiler writers' skill vs the JIT compiler writers' skill. In this case, it's the GC writers' skill vs the skill of who manages the memory, which is rarely a highly qualified expert who has worked on making it fast for years. Not that this necessarily changes the outcome...
Jul
4
comment Demonstration of garbage collection being faster than manual memory management
By "copy what the GC does" I didn't mean "build your own GC" (though note that this is theoretically possible in C++11 and beyond, which introduces optional support for a GC). I meant, as I've worded it earlier in the same comment, "do what gives the GC an edge over what you did manually". For example, if Cheney-like compaction helps this application a lot, you might manually implement a similar allocation + compaction scheme, with custom smart pointers to handle pointer fixup. Also, with techniques like a shadow stack, you can do root finding in C or C++, at the expense of extra work.
Jul
4
comment Demonstration of garbage collection being faster than manual memory management
Well, this is a bit tricky because you could always manually do whatever gives the GC an edge over what you did manually. Perhaps it's better to restrict this to "standard" manual memory management tools (malloc()/free(), owned pointers, shared pointers with refcount, weak pointers, no custom allocators)? Or, if you permit custom allocators (which may be more realistic or less realistic, depending on what kind of programmer you assume), put restrictions on the effort put into those allocators. Otherwise, the manual strategy "copy what the GC does in this case" is always at least as fast as GC.
Jul
4
revised Building a sequential list in languages with cons/linked lists
added 5 characters in body
Jul
4
revised Building a sequential list in languages with cons/linked lists
added 270 characters in body
Jul
4
answered Building a sequential list in languages with cons/linked lists
Jul
4
awarded  Civic Duty
Jul
1
comment Hide or Show singleton?
I'm talking about something like private int counter = 1; public static int NextID() { return Instance.counter++; } where Instance is the property that hides that. It adds an unnecessary Instance., sure, but not an extra line and you'd have to actively use the underlying field to get a NPE. How do you assume that method to be written?
Jul
1
comment Hide or Show singleton?
Playing devil's advocate: Couldn't one create a private static property or method which takes care of this, much like when the instance isn't hidden?
Jul
1
comment Hide or Show singleton?
The "hidden" variant reminds me of sites.google.com/site/steveyegge2/singleton-considered-stupid
Jul
1
comment Is a function plotter a legitimate use of eval() in JavaScript?
@SK-logic You still did not address 90% of what I said, you just pick and choose minor points and repeat claims I've challenged several times, up to and including code examples. You can stop commenting now.
Jul
1
comment Is a function plotter a legitimate use of eval() in JavaScript?
@SK-logic You already pointed me to that document once. To put it mildly, it hardly helps you case. As I already asked: How does term rewriting help in this case? JavaScript as implementation language and compilation target are set in stone, and the input language is just PEMDAS. So your neat esoteric tools are of no use here. How does the term rewriting approach help the compilation of simple arithmetic expressions to JavaScript more than it helps the interpretation of the same expressions, such that the former is clearly easier than the latter? Please think and read before replying.
Jul
1
comment Is a function plotter a legitimate use of eval() in JavaScript?
@SK-logic So you suggest that instead of 100 simple lines, we depend on a 100 to 500 line library to bring down our code to 80 simple lines? Ignoring that, you didn't address my concern at all. Would term rewriting simplify the compilation but not the evaluation? And does such a library already exist or would you have to create one yourself? But this is turning into a discussion...
Jul
1
comment Is a function plotter a legitimate use of eval() in JavaScript?
@SK-logic In this language, there is no context to speak of that must be maintained. There's one variable which can be passed along very naturally, and the call stack handles nesting. Compare the addition case: myEval(node.lhs, x) + myEval(node.rhs, x) versus "(" + myComp(node.lhs) + ")+(" + myComp(node.rhs) + ")". If you want to phrase it as term rewriting, you first need a term rewriting engine and it's still slightly more complex (I suppose the same engine could be used for evaluating it directly).
Jul
1
comment Is a function plotter a legitimate use of eval() in JavaScript?
@BenjaminGruenbaum With plain recursive descent, you have to either restructure the grammar to avoid left recursion (something I never quite got the hang of, I admit it), or drop operator precedence. The algorithms I mentioned are as simple as recursive descent, and have handling for operator precedence built in.
Jul
1
comment Is a function plotter a legitimate use of eval() in JavaScript?
@SK-logic Metaprogramming is good if it's what you want. And when you want metaprogramming, there's more tools for metaprogramming than eval. eval is without a doubt the most powerful, but it's also more brittle and dangerous than more specialized tools. For example, there is no reason to use eval for getting an attribute dynamically, as in eval('obj.'+attrname) - that's what obj[attrname] is for.