46,677 reputation
8122207
bio website tech.turbu-rpg.com
location Seattle, WA
age 32
visits member for 4 years, 2 months
seen 10 hours ago
A lifelong programmer who's been coding in Delphi since its initial release and currently makes a living at it.

Jan
8
comment What are the complexities of memory-unmanaged programming?
@ThomasEding: GC certainly is an optimization; it optimizes for minimal programmer effort, at the expense of performance and various other program quality metrics.
Dec
28
comment What's the difference between a macro and a script?
@Frustrated: Yeah, but from the context it doesn't look like that's what he's asking.
Dec
9
comment Exceptions or Error codes
@JensG: If this is a web service and not a website, the client should be professional enough to email it to you as a bug report.
Dec
8
comment How to best protect from 0 passed to std::string parameters?
Hooray for leaky abstractions! I'm not a C++ developer, but is there any reason why you couldn't check the string object's c_str property?
Nov
12
comment How should I make searching a relational database more efficient?
Second, it's a bit confusing what you're asking for. Can you edit your question to clarify a little about your large object graph and what it has to do with setting up searches? Right now I'm having a lot of trouble visualizing the problem you're trying to solve.
Nov
12
comment How should I make searching a relational database more efficient?
First off, a single string search as part of a web application (or any other system in which the possibility of a hostile user exists) is never a good idea. There are all sorts of little ways that a hostile user can manipulate query strings--even ones that someone is trying hard to sanitize properly--into creating a special query that hacks your database. This whole class of attacks is known as SQL Injection, and the only truly safe way to handle it is with parameterized queries.
Nov
10
comment When there's no TCO, when to worry about blowing the stack?
@Giorgio: Umm... it is a well-known truth, and has been for decades. The complexity of proving correctness of code rises exponentially faster than the complexity of the code itself, making it infeasible to the point of impossibility to produce any proof worthy of the term for non-trivial code. Did you seriously not know that, or are you trolling me?
Nov
9
comment The clock problem - to if or not to if?
Would the downvoter care to comment?
Nov
9
comment When there's no TCO, when to worry about blowing the stack?
@Giorgio: First, how does tail recursion make it easier to track your variables? Second, what does that have to do with modifying the values of variables? (This is something that's always taken as an article of faith by the Cult of Immutability, but never with any comprehensible rationale attached.) Third, "proving the correctness of code" is a bad joke for just about anything more complicated than "Hello world," and everyone knows it, so why are you even bringing that up?
Nov
8
comment When there's no TCO, when to worry about blowing the stack?
It's supposed to be designed to stay out of your way and let you focus on what you want instead of how you want to do it, but in many cases, writing simple code for what you want turns out to be horribly inefficient, and you need a lot more code describing how to do it right. (For some real fun, check out what Paul Graham says about Lisp to a non-Lisp audience. Then check out his book, On Lisp, in which literally the first thing he talks about is how all sorts of naive/intuitive constructs are horribly inefficient, and here is "the right way" to do them, which is about 3x more complicated.)
Nov
8
comment When there's no TCO, when to worry about blowing the stack?
@Giorgio: Oy, where do I even begin? The fundamental model is "let's pretend we're not actually programming a computer." (Not nearly as bad--or as pretentious about it--as Haskell, but still.) The fundamental iteration model isn't iteration, and naive recursion often doesn't work well, so you have to go way out of your way in many cases to transform your intuitive recursion into the special tail-recursive form, which is a lot more complicated and harder to read, so that the compiler can magically turn it into iteration for you! If that's not an abstraction inversion, I don't know what is!
Nov
8
comment When there's no TCO, when to worry about blowing the stack?
@Evicatos: I just looked it over, and you're right. It used to be a lot better; I think a bunch of obnoxious wikipedians (you know the type) have been weakening it over the last few years.
Nov
8
comment When there's no TCO, when to worry about blowing the stack?
@Ingo: I wouldn't say that. If I'm iterating over a list of a thousand elements, sending each one to a processing method, and one of them several hundred elements in has some unusual pattern of data that my code can't handle, having an accurate stack trace for that is crucial to debugging it. I've had that happen before.
Nov
8
comment When there's no TCO, when to worry about blowing the stack?
@Giorgio: en.wikipedia.org/wiki/Abstraction_inversion
Nov
8
comment When there's no TCO, when to worry about blowing the stack?
@Evicatos: First, that's not adding 2 numbers; that's another set operation. Second, I've never accused any Lisp dialect of being a sane language. ;) It's hard not to look at one without saying "this entire language is one big abstraction inversion from start to finish."
Nov
8
comment Can anyone explain to me what problem Core Data solves?
@RobertHarvey: *checks* Aha! Yes, I see what you mean. OK, the current version is a worthwhile question. It appears we're in agreement on both points. :P
Nov
8
comment Can anyone explain to me what problem Core Data solves?
@RobertHarvey: I'm a mod over at Christianity.SE. It's safe to say I have some experience with rants and trolls. This right here isn't one IMO. Seems to me he's asking a legitimate question, trying to get an answer.
Nov
7
comment When there's no TCO, when to worry about blowing the stack?
No it's not. Adding two numbers is adding two numbers. It's a single operation. All of the other things you mentioned (aside from the string concatenation) are set operations: they don't work on two numbers, but on each corresponding element of two datasets. There's a world of difference there.
Nov
7
comment When there's no TCO, when to worry about blowing the stack?
What would it be if not a call? An arithmetic operation, of course. (Why in the world would any sane language designer burden a primitive operation with all the overhead of a function call? If you need a function that adds two numbers--such as to pass to a function pointer--it's trivial to write one, but 99% of the time that's not necessary.)
Nov
7
comment When there's no TCO, when to worry about blowing the stack?
The vast majority of calls in a program are tail calls. Not if "the vast majority" of methods called perform more than one call of their own. Every subroutine has a last call, so every subroutine has at least one tail call. This is trivially demonstrable as false: return a + b. (Unless you're in some insane language where basic arithmetic operations are defined as function calls, of course.)