47,434 reputation
8126211
bio website tech.turbu-rpg.com
location Seattle, WA
age 32
visits member for 4 years, 3 months
seen 21 mins ago
A lifelong programmer who's been coding in Delphi since its initial release and currently makes a living at it.

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.)
Oct
28
comment I want a trivial example of where MongoDB can scale but a relational database will have trouble
@RyanWeir: Morons is right, really. NoSQL is only better in large environments. Unless you're trying to build something on massive scale (ie. Facebook, Flickr, EBay, Amazon, etc) you almost certainly don't need it, and the tradeoffs in dev time become worth it once you get to moderate-to-large scale, which the relational model handles quite well on modern hardware. That's when you really start to appreciate the benefits and guarantees that ACID and the relational model bring.
Oct
28
comment I want a trivial example of where MongoDB can scale but a relational database will have trouble
@Morons: The A* pathfinding algorithm, used for finding the shortest distance between two nodes on a graph.
Oct
28
comment I want a trivial example of where MongoDB can scale but a relational database will have trouble
Why is this a database problem in the first place? If I had to run calculations like this, I'd set it up as a variant on A* that doesn't stop after the first result. Pull all relevant flight data from the database (or have it already cached in memory), build a graph weighted according to the priorities the user has set, and report the first X number of results.
Oct
11
comment How would I implement a “self-destruct” feature into the free trial version of my software?
I downvoted on factual accuracy grounds, because you claimed that something impossible is actually "not difficult to do."
Oct
9
comment If I try to monetize free software, what could possibly prevent someone from forking that software and creating a proprietary version?
The GPL was created to prevent a lot more than just that. It's pushing an ideology that believes that proprietary software in general is inherently evil and must be fought against, which is why the GPL is a strongly viral license that requires its terms to be spread not only to modifications of the software, but to essentially anything the software touches as well.
Oct
6
comment Why is Global State so Evil?
being able to unit test code is a major step in the process of proving its correctness (or at least fitness for purpose). No it isn't. "It is now two decades since it was pointed out that program testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence. After quoting this well-publicized remark devoutly, the software engineer returns to the order of the day and continues to refine his testing strategies, just like the alchemist of yore, who continued to refine his chrysocosmic purifications." -- Djikstra, 1988. (That makes it 4.5 decades now...)
Oct
3
comment xml based programming languages
The fact that you try to respond to this in terms of escaping in the first place--which is and always has been the wrong way to prevent SQL injection--and not in terms of separation of code from data via Parameters--which is the only correct way to do it--shows that you really don't understand the problem. And that's why SQL injection attacks keep happening: people keep not understanding why these things are important and how to do them right.
Oct
3
comment xml based programming languages
Conflating code with data is not an advantage; it's a security hole at the language level. The classic example is SQL injection: every time some site gets hacked and millions of dollars worth of damage is done and tens of thousands of users have to order new credit cards due to a SQL injection exploit, the fundamental reason is because some developer somewhere set up a query in some way that did not properly segregate data from code. Throwing around fancy words like "homoiconicity" does not change this fundamental fact.
Oct
2
comment Optional semicolons
@delnan: Python isn't designed to look like C. It's well-known to be indentation-based and thus highly line-oriented, and It doesn't require semicolons. JavaScript technically does require them; it's inserting one when it finds one missing, which transforms what looks like one syntactically valid statement into two distinct statements with completely different semantics.