6,351 reputation
1633
bio website
location United Kingdom
age 43
visits member for 3 years, 9 months
seen yesterday

Aug
15
comment Has whitespace in identifiers ever been idiomatic?
Some dialects of BASIC have multi-keyword command names. Not the same thing, of course, but considering these are built-in commands in dialects with huge numbers of commands that should really be in libraries, they're related in a cheating kind of way. Anyway, examples include game-oriented BASIC dialects old and new (Dark BASIC, IIRC STOS on the Atari ST) and I think even the original Dartmouth BASIC (for matrix operations). Of course two or more keywords making a command name is trivial provided the parser recognizes the commands.
Jul
30
revised Why the scorn for COBOL?
Got the older standard year wrong twice (1973 instead of 1974) - fixed
Jul
30
revised Why the scorn for COBOL?
Confessions now that I can check facts - bought a copy of the book I originally learned from
Jul
17
comment Are there any scientifically rigorous studies of coding style principles?
Personally, I particularly like exceptions for success in the found case for a recursive depth-first search - they hand the responsibility for unwinding all the recursive calls to the compiler so there's no need for don't-keep-searching-if-I-already-found-something handling after every recursive call, keeping those details from complicating the search code.
Jul
17
comment Are there any scientifically rigorous studies of coding style principles?
Anyway, I think a lot of people think of exceptions as kind of alternative alternative exit points - because they're meant for error cases (sort of) they don't really count. I understand that's a bit language-culture sensitive, though. In some languages "exception" is more than the name - an exceptional success case is valid (and IIRC Stroustrup said something like that about C++, raising a philosophical point about whether an error is an error if it's handled). Some even say exceptions are just another control flow to use whenever it gives the control flow you need.
Jul
17
comment Are there any scientifically rigorous studies of coding style principles?
I saw your point about the 1995 paper only after that last comment, and decided to upvote - interesting point. I think your downvote may be more because your post is long, and starts out with a subjective point, so probably the downvoter didn't read the whole thing (the same as me, at first). Basically, it's a good idea to introduce your real point early.
Jul
17
comment Are there any scientifically rigorous studies of coding style principles?
I didn't downvote this, but on your "But in doing so you may have to introduce additional variables and/or code duplication both of which typically make the program harder to understand." point, that's a subjective claim. I agree that adding a variable or code duplication makes it hard to understand, but arguably adding a goto makes it hard to understand too, plus arguably the damage done by duplication can be mitigated by factoring the duplicated code out into a function (though IMO moving complexity into the call graph doesn't automatically eliminate it).
Jul
2
awarded  Curious
Jun
15
comment Why are most functional programming languages also interpreted languages?
Then again, Haskell is statically typed (and definitely compiled) yet has a similar tiny-but-there run-time cost for calling typeclass members - yet another form of late binding, really - and although I don't know much about ML, it probably has some equivalent too. In my mind, late binding is one of those things that shows that interpreting vs. compiling is blurry - though thinking of particular kinds of run-time work as left-over interpreting is probably a bit odd when the whole point of a program is to do work at run-time.
Jun
15
comment Why are most functional programming languages also interpreted languages?
They're not. The Lisp family used to be commonly considered interpreted (I still have old books that make the claim) but that's not true now and maybe never really was. However, unlike ML and Haskell, Lisp has dynamic typing. That means a tiny bit of work must be done at run-time (unless the optimizer can eliminate it) to determine which implementations of certain operations to use for particular values based on their types - similar to the tiny "overhead" for late-binding member functions in object-oriented programming. Dynamic typing is really just another form of late binding.
Jun
12
comment Can an object oriented program be seen as a Finite State Machine?
@cline - In this case, you're absolutely right, but I think what I had in mind was the kind of concurrency and timing variation that happen in a real-world machine - things like a core running a bit slower because it's too hot, the exact time when the data happens to be under the read head etc. This all fits in the non-deterministic finite automata model you describe, of course, so you're absolutely correct - but the number of states will be insanely huge. I guess I might have had continuous measures such as those temperatures in mind as part of the system state too (not just consequences).
Jun
8
comment programming on handheld devices
@Nav - basically, stop thinking in terms of a device getting "good enough" for development. Having a faster processor and more memory won't mean you can read lots of code at once on a 4-inch screen or type reasonably quickly on a tiny touch-screen keyboard or that your development tools will run on that device. For example that Psion, the screen was crappy but still as big or bigger than some current phones, and there was a physical keyboard that didn't waste screen-space (Psion series 3 and 5 looked a bit like pocket-size laptops).
Jun
8
comment programming on handheld devices
@Nav - it's not about whether the device is "good" in general terms. It's not about a ranking system. A device that's better for one thing isn't automatically better for everything else. A modern phone is far more powerful than the home micros I used for programming 20 or 30 years ago - but now, developers who target phones or tablets work on laptop/desktop computers. Keyboards and larger screens make a big difference, having laptops and desktops available means developers will tend to choose them, and the tools (IDEs etc) aren't really available for phones.
Jun
3
comment Can an object oriented program be seen as a Finite State Machine?
@kevin cline - thanks - and what was I thinking!!! Edited to strike that bit out. Despite what I said about formal study, I know better than that and should have known better back then.
Jun
3
revised Can an object oriented program be seen as a Finite State Machine?
added 986 characters in body
Apr
30
comment If you need more than 3 levels of indentation, you're screwed?
@Izkata - Of course my original "If we interpret it as meaning one word, we'll have big problems." is relevant here. If you're looking to claim somethings incomprehensible because it has more than 7 things in it, you can do that with 8 lexical tokens. Scratch that - there's often more than one thing to understand per lexical token, so you don't even need 8 to be incomprehensible. Remember, my original point was to "fall back on common sense". Any rule simple enough to state is too simple and will sometimes mislead you - that doesn't mean you switch to the opposite simple rule.
Apr
30
comment If you need more than 3 levels of indentation, you're screwed?
@Izkata - If you think you need to analyze every little detail to have an at-a-glance overview, you haven't understood the concept of an overview. Would you apply the same standard to functions? Insist that reading the call isn't enough - you must analyze every detail of its implementation (and recursively, the implementation of everything it calls) in order to claim any understanding of the original call? Just because a little less complexity was moved to the call graph doesn't mean you need to analyse every detail - the visually obvious structural summary from indentation helps with that.
Apr
4
comment Will B-Trees and Other Data Structures Become Obsolete With The Advent of Solid State Drives?
@user955091 - I meant because of cache-oblivious data structures (pedantically meaning structures that are optimal in the cache-oblivious model), but I was a bit overexcited about them back then. Other data structures aren't going to disappear any time soon. For one thing, cache isn't the only performance issue - parallelism makes different demands. Besides, needing key-based ordering is often a special case - normally, hash tables are king. It can be hard to see a "randomized" layout as cache-friendly, but one access to directly fetch the item is hard to beat - you don't need locality.
Mar
18
comment When does implementing MVVM not make sense
@Luke - that's true, but my point was also that you shouldn't let a beautiful design stop you shipping your product. A good design pattern is only good so long as you use it appropriately, and so long as the real world behaves itself.
Mar
12
comment Why would a language let programmer to handle divison by zero
@supercat - maybe you're referring to something like NaN which (in effect) is an error value defined as part of IEEE754 - so that IEEE754 floats are similar, in a way, to a Haskell Maybe type. I would say that is a kind of checked operation and arguably a kind of exception handling that propagates through expressions (rather than calls), though of course the "did an error occur" check must be done explicitly somewhere. The downside of this approach is that, after the NaN result has propagated out through many layers of calculations, it's hard to trace the original cause.