Re:GTK is alright...but no raves
on
Why Use GTK+?
·
· Score: 1
It may not be what the OP (Hosiah) wanted, but it's much better, cleaner, more maintainable code.
Hosiah's code: No, I'm not kidding: a dialog box with three buttons should be: D(H:50,W:200){M:"Quit without saving?",B1:"Save"(do_save()),B2:"Don't Save"(no_op&exit()),B3:"Cancel"(drop_quit())};
It's nice and all that he's managed to squeeze 7 or 8 lines of easily understandable code into 1 very long line that needs a fair amount of visual parsing to understand, but:
* Windows like this should not be specifying exact sizes - aside from all the time wasted determining what numbers fit, the end user is going to have a different font size, resolution, and screen size than you do. I hope your default window is resizable!
* It does not specify positioning - yes, it's assumed to be centered, but if you're all that interested in having so much control over the button text, it seems like an oversight to leave this up to the system.
* I hope you don't ever need to pass any params (or deal with any return values) from those functions.
* Yes, it's nitpicking, but his logic is wrong. The "Save" handler should save and exit, the "Don't Save" handler doesn't need a NOP for no reason, and the "Cancel" handler should do nothing (what on earth does drop_quit() do?
The art of programming does not consist in geting your program down to the least number of statements possible. It has much more to do with using the least amount *necessary to do the job and be clearly understandable*.
How is that code any better than this (other than being able to specify the button text)?
// Win SDK syntax off the top of my head from a long time ago... // What is up with the <ecode> tag? retval = MessageBox("Quit without saving?", NULL, MB_YESNOCANCEL); if (retval != BM_CANCEL) { // Save first, then bail // MB_NO == don't quit without saving
if (retval == MB_NO)
do_save();
do_quit(); }
There. 10 lines, yes, but 2 are comments, 2 are just braces, and one is blank. Not a lot of stress on the old typing fingers, and a dramatic increase in readability and extensibility.
Re:Purpose of being verbose
on
Ruby Off the Rails
·
· Score: 2, Interesting
No, verbosity like this serves no purpose whatsoever. It's just like writing: if you want those that come after you to understand it, write clean, spare code with useful symbol names and use comments on the non-obvious parts, for chrissake - that's what they're for. In fact, verbosity does just the opposite - it encourages vast amounts of cut-and-paste monkeywork, and all the attendant bugs and inefficiencies that come with it.
I've seen enough cryptic, overterse code that was incomprehensible, but I've seen just as many 2000 line monster modules that took a week of tracing through to understand what was going on. What's worse, the more verbose the code, the harder it is to modify and extend it, or - god forbid - try to use it for something else.
It's not elitist to want to write as little code as possible - it should be your goal. I have a lot of work to do and not a lot of time, and I do not want to write 20 lines where 3 will do. If you have to resort to tools to autogenerate gobs of code to use your language, you're doing something very wrong.
Excessive verbosity is great if you're a) overly anal retentive, b) not really a very imaginative programmer, or c) getting paid by the hour.
Oh, and Sun's primary contribution seems to be shovelloads of methodolgies and APIs starting with the letter 'J', thrown aperiodically at the community in the hopes that some of them will stick, most of which are deprecated or outright disappeared when some new strained coffee metaphor comes out saying "No, *this* is the Right Way To Do It!"
[he] is hardly likely to come to the conclusion that Biblically-based Christianity is wrong.
Swinburne was writing in this vein before he came to either of those places.
My point was that he's a devoted Christian, so it's likely to influence his views somewhat. It can be very tempting to develop and convince yourself of the truth of a philosophy that matches your existing belief system.
Much of Swinburne's initial tetrology shows that even without the Bible, one can deduce the existence of a single God consisting of three Persons, that mankind has some kind of debt to this God, and that this God somehow provided an atonement for this debt. It isn't until after the tetrology that he begins to draw in Biblical evidence to a large degree.
This actually sounds really interesting. I'd like to read some of it. My thinking on this subject is not all that far away (except for the 3-part god idea), although we wind up in very different places. It's refreshing to hear about someone making logical, well-reasoned arguments for Christianity (or any religion) without a priori assuming the truth of the sacred texts.
But your original response to fyngyrz about religion being "the gentle road away from honest inquiry" was what I initially responded to. His point was that religion has traditionally been a discipline of belief in ancient dogma and the comfort of benevolent parental figures, as opposed to pure scientific reason. Your response sounded like more of the usual "no it's not, read this intellectual defense of the Bible" style of argument. Thank you for pointing out that some Christian thinkers are arguing otherwise.
I've always been under the impression that the Bible is the sole authority for Christian doctrine, and that all other dogma was derived from it, hence my original comment about the self-defining nature of the Bible.
Indeed. The basic idea being that if you assume there's just one thing, the chances of it being exactly right are probably zero. If there are a near-infinite number of them, the chance of none of them being right are about zero.
So, either God created us *just like this*, or we just randomly happened. I think this is where I came in...
Having just done some looking into Plantinga and Swinburne, I stand somewhat corrected. These appear to be serious, respected philosophers. I fully agree I have no academic background in philosophy, so I don't know the players or all the terminology.
The point I was making was that, within the context of a particular philosophy (say, Christian Philosophy), one can be intellectually rigorous and sound, but that the conclusions that one comes to do not necessarily apply to anything outside that philosophical context.
In The Resurrection of God Incarnate (Oxford University Press, 2003), Swinburne discusses support for and against the truth of the Bible. He doesn't at all make an assumption of its truth.
This article in "Philosophy Now" seems to describe Plantinga and Swinburne's views pretty well. This bit from the section on 'Christian Philosophy' makes him sound like he has, in fact, made an assumption of Biblical truth:
"...perhaps the most systematic treatment of issues arising from the Christian creeds is Richard Swinburne's tetralogy. The first volume of this is Responsibility and Atonement, which is about humankind's sinfulness, guilt, and God's salvation of humans by the atonement. The second volume, Revelation, discusses what it would be for a sacred book, such as the Bible, to be a revelation from God. The third, The Christian God, deals with the doctrines of the incarnation and the Trinity."
I'm sorry, but someone who holds the position of Professor of the Philosophy of the Christian Religion at Oxford University, and is a member of the Orthodox Church, is hardly likely to come to the conclusion that Biblically-based Christianity is wrong.
In any event, most support for Christian doctrine can be found better through simple ontological and epistemological bases than by recourse to the Bible.
Well, that's just going to get you support for generic religious principles and the existence of some form of God. You can't make it support Christianity until you add the Bible as a set of axioms.
It reflects badly on you to rant and rage about Christians being ignorant when you seem to have not even the slightest training in philosophy of religion.
I did not "rant and rage", and I called no one ignorant. Please, it reflects poorly on you to suggest that I did.
Well, until there is some independent attribution for that book of theirs, it's not really "honest inquiry" or "defense through reason". "Honest philosophical inquiry", yes, but only within the scope of a self-consistent philosophy that stands on its own, but doesn't describe anything outside of itself.
I'm not familiar with either of the books you mention, but every Christian bit of writing I've ever read takes as its primary, foundational assumption that the Bible is the true (sometimes literal) word of God and that all statements attributed to people are exactly as they were spoken. That's an awful lot to take for granted from a book with less corroborating evidence than could be used in a court of law, especially if you want to extrapolate from it to describe the world.
Yes, but how do we know how many different times the universe was created with different sets of parameters that didn't work?
There is no way to tell if existence was a one-shot or if the gods are running a script that iterates through every combination of possible values. Given the probabilities involved, the try-everything-and-see-what-works scenario seems more likely.
Assuming it's not something *completely* different.
...at the time of Java, C++ SUCKED!! If you used 3 different compilers, your C++ WOULD NOT COMPILE on all 3. gcc (g++ or whatever it was called back then), sunCC, and MC C++ are three main ones that come to mind.
Actually, C++ did not suck. C++ *compilers* sucked, especially with some of the more esoteric features. It's certainly not C++'s fault that gcc had broken implementations of STL. To be fair, much of the problem was because (as I recall) the C++ standards committee still hadn't decided on what the standard would be, so most of the vendors (rightly or not, but wisely) waited on making a lot of big changes to their code until everything had settled down.
Hell, C++ was originally a HACK to C. I remember running the "CC" SUN compiler which literally could spit out the intermediate C code.
C++ was originally a preprocessor to the C compiler ('cfront', from AT&T), which is a good way to start out if you don't want to actually write a compiler first thing. I'm not at all surprised that Sun kept this approach up for a while.
Remember directives like extern "C" { } or whatever the hell that was.. It just told the pre-processor to skip that section when translating C++ symbols.
'extern "C"' tells the compiler not to generate name-mangling for the given symbols and prototypes, so they can be linked in with C code. That's how you can have a nice C interface to your C++ libraries.
I'll stand away from all the argument and hype. I came up with C and started using C++ in earnest in 1994 or so. I like it a lot, except for template syntax. I like Perl, too. It takes discipline to write clean, structured Perl, but you can't be a good programmer without discipline anyway. Both languages are showing their age - if C++ had garbage collection and could specify return types in function templates (and didn't have to maintain so much backwards compatibility with C), and if Perl had nested reference syntax and prototypes that didn't suck (and if modules and scoping weren't so baroque), I'd be a happy happy boy.
I think I get it now. My problem was with getting to the more general case. The idea is that each monk sees N marks, and knows that the ones with marks see either N or N - 1 marks, so they have more information than he does. On each successive day, they each know that the previous day's scenario didn't happen, so after N days, they have it figured out, right?
I still get hazy with more than 4 marks, but I'll just trust that it works. It makes my brain hurt too much to follow it otherwise.
No, I know about induction. I just didn't read the problem carefully enough. I understand the argument now.
I don't think it holds if there are more than two monks with marks, though. If there are three monks and two of them have marks, and all that they know is that some of them have marks, they don't have enough information to make a decision.
Actually, the problem as stated implies that more than more than one not but not all of the monks will be chosen, so if N is more than 2 and there are more than two with marks, it won't work.
I see the idea behind your solution, but I don't see how you get from case 1 (one spotted monk) to case 2 (two spotted monks). If each monk sees another with a spot, he knows that guy is slated for death, but how can either be sure about himself? On day N + 1, isn't the state the same as on day N?
My idea (and this is not at all my thing, so I'm sure I'm missing something) is this: Each morning, each monk looks out at the others. One at a time, if a monk sees another with a spot, he goes back inside (and, presumably, waits for tomorrow). The last monk left knows he has a spot and does himself in (perhaps by leaping off the balcony). We should have a complete solution in N days, right?
The one problem I can see is if there are just two monks left, both with spots. One goes in, but the next day, he'll never know if he has a spot or not. I suppose this could be solved by each of them sitting down if he sees a spot. If one sees the other guy sitting, he knows it's his turn.
Like I said, I suck at these things, but it seems like it should work. My only question is, who cleans up the bodies?
Well, it sounds like your design is pretty much locked in. My advice in this case would be to go with your current scheme of writing out the global structure in one go. If running your app on other architectures is important, then you'll want to handle endianness. I believe Unicode uses a neat trick where they write 0x00FF into the file header, and, when they read it in, if it's negative, they have little-endian.
Of course, you did ask specifically about OO techniques. The idea is not that you have "oddball" member functions - it's that an object knows how to deal with itself. At the most basic level, OO is all about data and functions that operate on that data. It's really just abstraction and information hiding, which are the basic concepts of structured programming, except instead of saying foo(&data), you say data -> foo() (okay, it's a little more complicated than that).
I would say, though, that if a secondary feature like saving the game is having this much of an effect on your design, perhaps you might want to look at why this is, and consider a different sort of design, even if it means performing major surgery. I think you'll find that it makes your code a lot cleaner and easier to modify and extend in the long run.
I was sort of going off on a bit of a tangent with my comment about premature optimization, but it was speaking to the point of view that always crops up in threads like this that anything other than raw C code is "bloated" and inefficient. And you did mention "horrid bloat" in your original posting. Anyway, my point was that picking your initial design (or language) specifically to avoid bloat is trying to optimize before you've even started.
I guess the main point that someone could take from this ramble is that it's really hard to mix procedural and OO techniques in the same design, and that it's especially hard to mix them after the design is already in place.
Do try an OO design sometime - maybe for your next (small) project. It takes a different mindset, and your design has to be *really* worked out *before* you start coding (trust me), but you might be pleasantly surprised by how well it works out. Good luck however you wind up doing it.
All true, but don't forget, class method declarations are distant from use, too (they're in a different file, even!). The "module-specific data" idea (nope, no "globals" here) works in a limited way. If you only have a few, and name them like
static int gLinesPerPage = 25;
(and have some setter routine), then you should be okay. It doesn't scale, but can be a reasonable alternative to a more "correct' implementation in the right circumstances.
The instantiation order can bite you hard, but if you're careful, and don't depend on global vars until your program is at a known state, you should be safe. Relying on a bunch of gXXXConfig objects that refer to each other is a guaranteed disaster, though.
This discussion illustrates several very good principles:
* Beware of absolutists who say "XYZ is always a bad idea" Yes, global variables can be a bad thing and make your code a nightmare. I've had to make changes to horribly tangled spaghetti code that relied on dozens of global variables in dozens of modules and I'm several years older because of it. However, it's virtually impossible (or at least very impractical) to write a program without any globals. You're always going to have some kind of global system state, or pointers to main windows or instance handles or whatever.
You seem to have a pretty clean design here - I use the one-global-config-struct a lot myself, and it works very well for the class of problems where there are a lot of application config variables. It gets a little silly if you ty to scale it up to 200 members, but if that's the case, you have other design problems and should seriously look into how much of this data is truly global an how much is only used for certain specific sections of the app.
One thing to consider - it's true that a compiler is not going to reorder fields of a struct (it's just a high-level wrapper around the underlying data layout), but different compilers *will* pack the fields differently - padding out ones that are not multiples of 4 or 8 or whatever. Make free with the #pragma pack (or whatever) directives and comment them well.
* Saying "adding all this object-oriented behavior will bloat my app and slow it down" is just another instance of Donald Knuth's (originally from CAR Hoare) principle "Premature optimization is the root of all evil".
Do not worry about the runtime speed, or the size of the code, required to have objects (which are the only things that know all about themselves) save their own state. The time involved to iterate through all your game objects with something like
for each object in gGameObjects
object -> save(savehandle)
is so incalculably trivial that if you can even notice it, you have much bigger design problems elsewhere.
The object-oriented solution is the garrish hack here. Object classes should have no inherent duty to serialize their game state information at runtime. That should be a responsibility of the language itself (as other posts have mentioned), or some sort of holistic game object, or precomputed as a global data structure as I've shown. You are adding code, data, and object bloat when you create so many classes, all (yes, all) of which have to manage the persistance of their objects.
I am afraid you're dead wrong here. A good, well thought out object oriented design is rarely, if ever, a "garish hack". On the contrary - a design for something as complex as as a game that doesn't take OOP principles into account is almost bound to become a hack over time.
Object classes have the *exact* duty to serialize themselves - like I said, they're the only entities that know how to. The language has no responsibility whatsoever here other than to provide the tools you need to accomplish this. A global game object only goes so far and doesn't scale - how do you handle thousands of characters or treasure items or whatever? What happens when you add a new kind of item to the game? Will you want to add a dozen fields to the status object every time?
You are adding code and data, but you are not adding "bloat". You are adding functionality and making your life as a designer, coder and maintainer orders of magnitude easier. Objects manage their persistence in exactlty one place - the save() or serialize() method, most of whose work is done in a base class. Write it once, use it everywhere.
I really think that a lot of people don't use C++ or other OO languages because they've been taught so badly, by academic purists like your professor. It also takes a big mindset change to start thinking in OO terms, and that can be scary as hell.
The biggest roadblock, though, is attitudes like "C++ i
Imagine how society would be different if we had instead gone with the Magnifying Transmitter. Power usage would not be meterable, so electricity would be free to everyone.
Well, what would have happened is that no one would have starting generating electricity in the first place, since they couldn't make any money from it. Since there are huge startup and rollout costs, either a) the governments would have done this, b) we would still be using candles and oil lamps, or c) some other scheme would have happened.
The difference with Internet access is that the infrastructure was already in place by the time consumers caught on to it, and it's (essentially) free to resell, within the limits of bandwidth. Since it's also (essentially) free to generate - you don't need, say, tons of coal or nuclear powerplants - the pricing model is radically different.
I don't expect to ever see free, or even cheap, electricity happen, ever, unless some government-sized entity suddenly develops advanced altruism - barring the discovery of some fantastic new technology, of course.
It's a bit obsolete these now, but, if you use Windows, I highly recommend Dreaming of Brazil, a GPL'ed app for talking to the Rio. Small, clean, looks just like a normal Windows app (*why* must every media app try to make itself look like some godawful simulation of an acid trip?), and lets you download from the player to your PC. Plus, it's not the steaming pile of rotting fish entrails that is MusicMatch.
I bought a Rio PMP 300 (with an amazing 64 meg of memory!) way back in the day, and it was the serious shit at the time. However, it didn't age well (it sucks batteries even when turned off, and the battery door is really poorly designed). Happily, it's been retired since I got an iPod for Christmas. Thanks, Santa!
Shuffle is great, and I use it all the time, but it only operates on the entire list of songs. What I want is to play a playlist randomly - Fast and Loud Tunes For the Gym, Blues, Thoughtful Singers, etc. I know iTunes can randomize a playlist, but I would have to upload it every time I wanted a different order. That's way too much trouble.
I really like the auto-volume setting, but until I looked it up just now, I thought it was only in iTunes. According to the user guide (which is helpfully not copied to my machine during installation), that's what the cryptic "Sound Check" setting does. However, it apparently only works if you also have it set in iTunes (Huh?). Thank you for pointing this out - it will make my life much happier.
Hi - I'm the AC who originally posted the GWAPict comment. Now that there have been all these relevant replies, I don't feel so embarassed any more...
Wow, a random thought that went through my head turned out to be right. Cool. You don't see too many classic Pink Floyd fans these days. That's a shame.
I like the sound of "Grooving With the Pict" - kinda like "Riding With the King" (without the lamentable hairstyles *).
Your wife cooks comfort food, and really well? Stop it, you're making me envious. My ex made ribs and blueberry cobbler to do crimes for (sigh). You sound like two very cool people. Blessings to you both.
* See liner photos of B.B. King/Eric Clapton album of that name: EC with a very '60s 'do, and BB with the world's dorkiest-looking process.
I won't comment on the winners and losers list, but the number one thing *I* want to see? A volume control for the iPod. Yeah, the scroll wheel is a great metaphor, and I love it, but it's a pain in the ass for changing the volume.
For one thing, you have to be at the "Now Playing" screen for volume to even be available. Now, imagine you have the unit in your shirt pocket, walking down the street. The next song comes on way too loud (or way too quiet). Quick - reach in and try to find the right spot on the wheel and rotate it in the right direction, without hitting any of the other buttons. Or, try to press the pause/next/previous buttons. Not too easy, is it?
Ideally, there would be a volume slider and the three playback buttons on the top of the unit, between the hold switch and the remote adapter on the Mini. The hold switch is too big anyway, and could be rotated 90 degrees so so that it moves front-to-back, with no loss of usability.
Yes, I know you can get an aftermarket remote-control dongle from Apple that does this, but have you looked at those? Big, ugly, heavy things that dangle from the headphones like a tumor. Couldn't they have made something that fit flat against the top of the unit - you know, kind of an elegant design?
Anyway, I love the unit, but hate the annoyance. It's a small annoyance, but it makes an obvious wart on a really clean design.
Oh, and the ability to randomize a playlist/album would be absolutely fantastic.
According to Timothy's comment on the submission, "Unstructured" is the key word in this patent, which (like most) is written in language that does more to obscure than illuminate. Just how structured was Mavis Beacon Teaches Typing?
Actually, Mavis Beacon was very structured (I worked for Software Toolworks/Mindscape for a number of years, and am very familiar with that product). The patent app describes "unstructured" as input specifically not from a keyboard, but from a stylus or a microphone. In Mavis, the enitire point was to press the specific keys that it wanted you to at any time, either in typing practice or in the games. It's very much a call-and-response type of learning rather than a more arbitrary scribble-random-stuff method. For that matter, so is the Speak-and-Spell (as I recall), and some of the other prior art that was suggested here.
I've read and been (unwillingly) involved in a lot of patent applications, and the point is not to write them to be obufuscatory, but not to be any more specific than necessary. Patent writing has its own language and metaphors that sound incredibly dense and complex until someone translates them for you. The main idea is to state everything in such a way that it's a) not so specific that the entire thing falls apart if you change the shape of the box and b) resistant to a sharp patent attorney picking it apart for not being specific enough (hence all the block diagrams of CPUs and descriptions of The Internet and re-restatements of the initial claim in slightly different forms). It took me several years before I could read these things and not go blind. So, this application is pretty clear: a device that takes free-form input and determines if it meets whatever criteria define a "correct" answer, and optionally talks to the instructor's computer over the network to do this.
A neat idea, yes. New and novel? Not particularly. Patentable? I don't think it should be, but that's pretty irrelevant these days. I do wish the editors would think a little more about their comments on the stories, though.
I would suggest that relevance here refers to an artist who is doing or saying something new and interesting, making insightful social commentary, generally doing something beyond the average make-it-just-like-what's-selling-at-the-moment. U2, The Clash, Bob Dylan, The Who, and Eric Clapton were all, at one time, relevant.
I actually liked U2 back when they were political and had a unique sound. I think they lost it when they began coveting industry awards and MTV cash. Now they're pretty much just another band. Good musicians, though.
You're both confusing popularity with relevance and quality. Just because something sells a bajillion copies doesn't mean it's any good. Or should we consider Britney Spears to be the peak of musical relevance? I could also mention that an awful lot of Grammy-winning albums are pretty boring, or that Jimmy Fallon and Adam Sandler movies tend to be "The Number One Movie in the Country" at any given time.
Or, to put it yet another way: Windows is hugely popular.
This sounds like a really cool device, although I don't particularly want or need one (if I was rich, though, hell yeah). What I'm excited about is the idea that this means that the prices for regular iPods *should* come down a little. For $250, I could rationalize a 20G unit. Or will Apple be dropping all the old models?
On a related note, I like the black model but I really wish it didn't come with all that U2 crap on it. Yes, they had several classic, groundbreaking albums, but they haven't been very relevant since what - the late 80s? How about the Little Feat model iPod, or the Stax/Volt collection model? I'd buy one of those.
Slashdot Mirror
Hosiah's code:
No, I'm not kidding: a dialog box with three buttons should be:
D(H:50,W:200){M:"Quit without saving?",B1:"Save"(do_save()),B2:"Don't Save"(no_op&exit()),B3:"Cancel"(drop_quit())};
It's nice and all that he's managed to squeeze 7 or 8 lines of easily understandable code into 1 very long line that needs a fair amount of visual parsing to understand, but:
* Windows like this should not be specifying exact sizes - aside from all the time wasted determining what numbers fit, the end user is going to have a different font size, resolution, and screen size than you do. I hope your default window is resizable!
* It does not specify positioning - yes, it's assumed to be centered, but if you're all that interested in having so much control over the button text, it seems like an oversight to leave this up to the system.
* I hope you don't ever need to pass any params (or deal with any return values) from those functions.
* Yes, it's nitpicking, but his logic is wrong. The "Save" handler should save and exit, the "Don't Save" handler doesn't need a NOP for no reason, and the "Cancel" handler should do nothing (what on earth does drop_quit() do?
The art of programming does not consist in geting your program down to the least number of statements possible. It has much more to do with using the least amount *necessary to do the job and be clearly understandable*.
How is that code any better than this (other than being able to specify the button text)?There. 10 lines, yes, but 2 are comments, 2 are just braces, and one is blank. Not a lot of stress on the old typing fingers, and a dramatic increase in readability and extensibility.
No, verbosity like this serves no purpose whatsoever. It's just like writing: if you want those that come after you to understand it, write clean, spare code with useful symbol names and use comments on the non-obvious parts, for chrissake - that's what they're for. In fact, verbosity does just the opposite - it encourages vast amounts of cut-and-paste monkeywork, and all the attendant bugs and inefficiencies that come with it.
I've seen enough cryptic, overterse code that was incomprehensible, but I've seen just as many 2000 line monster modules that took a week of tracing through to understand what was going on. What's worse, the more verbose the code, the harder it is to modify and extend it, or - god forbid - try to use it for something else.
It's not elitist to want to write as little code as possible - it should be your goal. I have a lot of work to do and not a lot of time, and I do not want to write 20 lines where 3 will do. If you have to resort to tools to autogenerate gobs of code to use your language, you're doing something very wrong.
Excessive verbosity is great if you're a) overly anal retentive, b) not really a very imaginative programmer, or c) getting paid by the hour.
Oh, and Sun's primary contribution seems to be shovelloads of methodolgies and APIs starting with the letter 'J', thrown aperiodically at the community in the hopes that some of them will stick, most of which are deprecated or outright disappeared when some new strained coffee metaphor comes out saying "No, *this* is the Right Way To Do It!"
[he] is hardly likely to come to the conclusion that Biblically-based Christianity is wrong.
Swinburne was writing in this vein before he came to either of those places.
My point was that he's a devoted Christian, so it's likely to influence his views somewhat. It can be very tempting to develop and convince yourself of the truth of a philosophy that matches your existing belief system.
Much of Swinburne's initial tetrology shows that even without the Bible, one can deduce the existence of a single God consisting of three Persons, that mankind has some kind of debt to this God, and that this God somehow provided an atonement for this debt. It isn't until after the tetrology that he begins to draw in Biblical evidence to a large degree.
This actually sounds really interesting. I'd like to read some of it. My thinking on this subject is not all that far away (except for the 3-part god idea), although we wind up in very different places. It's refreshing to hear about someone making logical, well-reasoned arguments for Christianity (or any religion) without a priori assuming the truth of the sacred texts.
But your original response to fyngyrz about religion being "the gentle road away from honest inquiry" was what I initially responded to. His point was that religion has traditionally been a discipline of belief in ancient dogma and the comfort of benevolent parental figures, as opposed to pure scientific reason. Your response sounded like more of the usual "no it's not, read this intellectual defense of the Bible" style of argument. Thank you for pointing out that some Christian thinkers are arguing otherwise.
I've always been under the impression that the Bible is the sole authority for Christian doctrine, and that all other dogma was derived from it, hence my original comment about the self-defining nature of the Bible.
Indeed. The basic idea being that if you assume there's just one thing, the chances of it being exactly right are probably zero. If there are a near-infinite number of them, the chance of none of them being right are about zero.
So, either God created us *just like this*, or we just randomly happened. I think this is where I came in...
Having just done some looking into Plantinga and Swinburne, I stand somewhat corrected. These appear to be serious, respected philosophers. I fully agree I have no academic background in philosophy, so I don't know the players or all the terminology.
The point I was making was that, within the context of a particular philosophy (say, Christian Philosophy), one can be intellectually rigorous and sound, but that the conclusions that one comes to do not necessarily apply to anything outside that philosophical context.
In The Resurrection of God Incarnate (Oxford University Press, 2003), Swinburne discusses support for and against the truth of the Bible. He doesn't at all make an assumption of its truth.
This article in "Philosophy Now" seems to describe Plantinga and Swinburne's views pretty well. This bit from the section on 'Christian Philosophy' makes him sound like he has, in fact, made an assumption of Biblical truth:
"...perhaps the most systematic treatment of issues arising from the Christian creeds is Richard Swinburne's tetralogy. The first volume of this is Responsibility and Atonement, which is about humankind's sinfulness, guilt, and God's salvation of humans by the atonement. The second volume, Revelation, discusses what it would be for a sacred book, such as the Bible, to be a revelation from God. The third, The Christian God, deals with the doctrines of the incarnation and the Trinity."
I'm sorry, but someone who holds the position of Professor of the Philosophy of the Christian Religion at Oxford University, and is a member of the Orthodox Church, is hardly likely to come to the conclusion that Biblically-based Christianity is wrong.
In any event, most support for Christian doctrine can be found better through simple ontological and epistemological bases than by recourse to the Bible.
Well, that's just going to get you support for generic religious principles and the existence of some form of God. You can't make it support Christianity until you add the Bible as a set of axioms.
It reflects badly on you to rant and rage about Christians being ignorant when you seem to have not even the slightest training in philosophy of religion.
I did not "rant and rage", and I called no one ignorant. Please, it reflects poorly on you to suggest that I did.
Well, until there is some independent attribution for that book of theirs, it's not really "honest inquiry" or "defense through reason". "Honest philosophical inquiry", yes, but only within the scope of a self-consistent philosophy that stands on its own, but doesn't describe anything outside of itself.
I'm not familiar with either of the books you mention, but every Christian bit of writing I've ever read takes as its primary, foundational assumption that the Bible is the true (sometimes literal) word of God and that all statements attributed to people are exactly as they were spoken. That's an awful lot to take for granted from a book with less corroborating evidence than could be used in a court of law, especially if you want to extrapolate from it to describe the world.
Yes, but how do we know how many different times the universe was created with different sets of parameters that didn't work?
There is no way to tell if existence was a one-shot or if the gods are running a script that iterates through every combination of possible values. Given the probabilities involved, the try-everything-and-see-what-works scenario seems more likely.
Assuming it's not something *completely* different.
A few points...
...at the time of Java, C++ SUCKED!! If you used 3 different compilers, your C++ WOULD NOT COMPILE on all 3. gcc (g++ or whatever it was called back then), sunCC, and MC C++ are three main ones that come to mind.
Actually, C++ did not suck. C++ *compilers* sucked, especially with some of the more esoteric features. It's certainly not C++'s fault that gcc had broken implementations of STL. To be fair, much of the problem was because (as I recall) the C++ standards committee still hadn't decided on what the standard would be, so most of the vendors (rightly or not, but wisely) waited on making a lot of big changes to their code until everything had settled down.
Hell, C++ was originally a HACK to C. I remember running the "CC" SUN compiler which literally could spit out the intermediate C code.
C++ was originally a preprocessor to the C compiler ('cfront', from AT&T), which is a good way to start out if you don't want to actually write a compiler first thing. I'm not at all surprised that Sun kept this approach up for a while.
Remember directives like extern "C" { } or whatever the hell that was.. It just told the pre-processor to skip that section when translating C++ symbols.
'extern "C"' tells the compiler not to generate name-mangling for the given symbols and prototypes, so they can be linked in with C code. That's how you can have a nice C interface to your C++ libraries.
I'll stand away from all the argument and hype. I came up with C and started using C++ in earnest in 1994 or so. I like it a lot, except for template syntax. I like Perl, too. It takes discipline to write clean, structured Perl, but you can't be a good programmer without discipline anyway. Both languages are showing their age - if C++ had garbage collection and could specify return types in function templates (and didn't have to maintain so much backwards compatibility with C), and if Perl had nested reference syntax and prototypes that didn't suck (and if modules and scoping weren't so baroque), I'd be a happy happy boy.
You're probably right...
I think I get it now. My problem was with getting to the more general case. The idea is that each monk sees N marks, and knows that the ones with marks see either N or N - 1 marks, so they have more information than he does. On each successive day, they each know that the previous day's scenario didn't happen, so after N days, they have it figured out, right?
I still get hazy with more than 4 marks, but I'll just trust that it works. It makes my brain hurt too much to follow it otherwise.
No, I know about induction. I just didn't read the problem carefully enough. I understand the argument now.
I don't think it holds if there are more than two monks with marks, though. If there are three monks and two of them have marks, and all that they know is that some of them have marks, they don't have enough information to make a decision.
Actually, the problem as stated implies that more than more than one not but not all of the monks will be chosen, so if N is more than 2 and there are more than two with marks, it won't work.
I see the idea behind your solution, but I don't see how you get from case 1 (one spotted monk) to case 2 (two spotted monks). If each monk sees another with a spot, he knows that guy is slated for death, but how can either be sure about himself? On day N + 1, isn't the state the same as on day N?
My idea (and this is not at all my thing, so I'm sure I'm missing something) is this: Each morning, each monk looks out at the others. One at a time, if a monk sees another with a spot, he goes back inside (and, presumably, waits for tomorrow). The last monk left knows he has a spot and does himself in (perhaps by leaping off the balcony). We should have a complete solution in N days, right?
The one problem I can see is if there are just two monks left, both with spots. One goes in, but the next day, he'll never know if he has a spot or not. I suppose this could be solved by each of them sitting down if he sees a spot. If one sees the other guy sitting, he knows it's his turn.
Like I said, I suck at these things, but it seems like it should work. My only question is, who cleans up the bodies?
Damn, son, that was well done. You are to be commended!
+3, Funny at least.
Well, it sounds like your design is pretty much locked in. My advice in this case would be to go with your current scheme of writing out the global structure in one go. If running your app on other architectures is important, then you'll want to handle endianness. I believe Unicode uses a neat trick where they write 0x00FF into the file header, and, when they read it in, if it's negative, they have little-endian.
Of course, you did ask specifically about OO techniques. The idea is not that you have "oddball" member functions - it's that an object knows how to deal with itself. At the most basic level, OO is all about data and functions that operate on that data. It's really just abstraction and information hiding, which are the basic concepts of structured programming, except instead of saying foo(&data), you say data -> foo() (okay, it's a little more complicated than that).
I would say, though, that if a secondary feature like saving the game is having this much of an effect on your design, perhaps you might want to look at why this is, and consider a different sort of design, even if it means performing major surgery. I think you'll find that it makes your code a lot cleaner and easier to modify and extend in the long run.
I was sort of going off on a bit of a tangent with my comment about premature optimization, but it was speaking to the point of view that always crops up in threads like this that anything other than raw C code is "bloated" and inefficient. And you did mention "horrid bloat" in your original posting. Anyway, my point was that picking your initial design (or language) specifically to avoid bloat is trying to optimize before you've even started.
I guess the main point that someone could take from this ramble is that it's really hard to mix procedural and OO techniques in the same design, and that it's especially hard to mix them after the design is already in place.
Do try an OO design sometime - maybe for your next (small) project. It takes a different mindset, and your design has to be *really* worked out *before* you start coding (trust me), but you might be pleasantly surprised by how well it works out. Good luck however you wind up doing it.
All true, but don't forget, class method declarations are distant from use, too (they're in a different file, even!). The "module-specific data" idea (nope, no "globals" here) works in a limited way. If you only have a few, and name them like
static int gLinesPerPage = 25;
(and have some setter routine), then you should be okay. It doesn't scale, but can be a reasonable alternative to a more "correct' implementation in the right circumstances.
The instantiation order can bite you hard, but if you're careful, and don't depend on global vars until your program is at a known state, you should be safe. Relying on a bunch of gXXXConfig objects that refer to each other is a guaranteed disaster, though.
This discussion illustrates several very good principles:
* Beware of absolutists who say "XYZ is always a bad idea"
Yes, global variables can be a bad thing and make your code a nightmare. I've had to make changes to horribly tangled spaghetti code that relied on dozens of global variables in dozens of modules and I'm several years older because of it. However, it's virtually impossible (or at least very impractical) to write a program without any globals. You're always going to have some kind of global system state, or pointers to main windows or instance handles or whatever.
You seem to have a pretty clean design here - I use the one-global-config-struct a lot myself, and it works very well for the class of problems where there are a lot of application config variables. It gets a little silly if you ty to scale it up to 200 members, but if that's the case, you have other design problems and should seriously look into how much of this data is truly global an how much is only used for certain specific sections of the app.
One thing to consider - it's true that a compiler is not going to reorder fields of a struct (it's just a high-level wrapper around the underlying data layout), but different compilers *will* pack the fields differently - padding out ones that are not multiples of 4 or 8 or whatever. Make free with the #pragma pack (or whatever) directives and comment them well.
* Saying "adding all this object-oriented behavior will bloat my app and slow it down" is just another instance of Donald Knuth's (originally from CAR Hoare) principle "Premature optimization is the root of all evil".
Do not worry about the runtime speed, or the size of the code, required to have objects (which are the only things that know all about themselves) save their own state. The time involved to iterate through all your game objects with something like
for each object in gGameObjects
object -> save(savehandle)
is so incalculably trivial that if you can even notice it, you have much bigger design problems elsewhere.
The object-oriented solution is the garrish hack here. Object classes should have no inherent duty to serialize their game state information at runtime. That should be a responsibility of the language itself (as other posts have mentioned), or some sort of holistic game object, or precomputed as a global data structure as I've shown. You are adding code, data, and object bloat when you create so many classes, all (yes, all) of which have to manage the persistance of their objects.
I am afraid you're dead wrong here. A good, well thought out object oriented design is rarely, if ever, a "garish hack". On the contrary - a design for something as complex as as a game that doesn't take OOP principles into account is almost bound to become a hack over time.
Object classes have the *exact* duty to serialize themselves - like I said, they're the only entities that know how to. The language has no responsibility whatsoever here other than to provide the tools you need to accomplish this. A global game object only goes so far and doesn't scale - how do you handle thousands of characters or treasure items or whatever? What happens when you add a new kind of item to the game? Will you want to add a dozen fields to the status object every time?
You are adding code and data, but you are not adding "bloat". You are adding functionality and making your life as a designer, coder and maintainer orders of magnitude easier. Objects manage their persistence in exactlty one place - the save() or serialize() method, most of whose work is done in a base class. Write it once, use it everywhere.
I really think that a lot of people don't use C++ or other OO languages because they've been taught so badly, by academic purists like your professor. It also takes a big mindset change to start thinking in OO terms, and that can be scary as hell.
The biggest roadblock, though, is attitudes like "C++ i
Imagine how society would be different if we had instead gone with the Magnifying Transmitter. Power usage would not be meterable, so electricity would be free to everyone.
Well, what would have happened is that no one would have starting generating electricity in the first place, since they couldn't make any money from it. Since there are huge startup and rollout costs, either a) the governments would have done this, b) we would still be using candles and oil lamps, or c) some other scheme would have happened.
The difference with Internet access is that the infrastructure was already in place by the time consumers caught on to it, and it's (essentially) free to resell, within the limits of bandwidth. Since it's also (essentially) free to generate - you don't need, say, tons of coal or nuclear powerplants - the pricing model is radically different.
I don't expect to ever see free, or even cheap, electricity happen, ever, unless some government-sized entity suddenly develops advanced altruism - barring the discovery of some fantastic new technology, of course.
Re the Diamond Rio:
It's a bit obsolete these now, but, if you use Windows, I highly recommend Dreaming of Brazil, a GPL'ed app for talking to the Rio. Small, clean, looks just like a normal Windows app (*why* must every media app try to make itself look like some godawful simulation of an acid trip?), and lets you download from the player to your PC. Plus, it's not the steaming pile of rotting fish entrails that is MusicMatch.
I bought a Rio PMP 300 (with an amazing 64 meg of memory!) way back in the day, and it was the serious shit at the time. However, it didn't age well (it sucks batteries even when turned off, and the battery door is really poorly designed). Happily, it's been retired since I got an iPod for Christmas. Thanks, Santa!
As near as I can tell, and from Googling around the user groups, I don't think it does. At least not on the Mini with the latest updater. Feh.
Shuffle is great, and I use it all the time, but it only operates on the entire list of songs. What I want is to play a playlist randomly - Fast and Loud Tunes For the Gym, Blues, Thoughtful Singers, etc. I know iTunes can randomize a playlist, but I would have to upload it every time I wanted a different order. That's way too much trouble.
I really like the auto-volume setting, but until I looked it up just now, I thought it was only in iTunes. According to the user guide (which is helpfully not copied to my machine during installation), that's what the cryptic "Sound Check" setting does. However, it apparently only works if you also have it set in iTunes (Huh?). Thank you for pointing this out - it will make my life much happier.
Hi - I'm the AC who originally posted the GWAPict comment. Now that there have been all these relevant replies, I don't feel so embarassed any more...
Wow, a random thought that went through my head turned out to be right. Cool. You don't see too many classic Pink Floyd fans these days. That's a shame.
I like the sound of "Grooving With the Pict" - kinda like "Riding With the King" (without the lamentable hairstyles *).
Your wife cooks comfort food, and really well? Stop it, you're making me envious. My ex made ribs and blueberry cobbler to do crimes for (sigh). You sound like two very cool people. Blessings to you both.
* See liner photos of B.B. King/Eric Clapton album of that name: EC with a very '60s 'do, and BB with the world's dorkiest-looking process.
I won't comment on the winners and losers list, but the number one thing *I* want to see? A volume control for the iPod. Yeah, the scroll wheel is a great metaphor, and I love it, but it's a pain in the ass for changing the volume.
For one thing, you have to be at the "Now Playing" screen for volume to even be available. Now, imagine you have the unit in your shirt pocket, walking down the street. The next song comes on way too loud (or way too quiet). Quick - reach in and try to find the right spot on the wheel and rotate it in the right direction, without hitting any of the other buttons. Or, try to press the pause/next/previous buttons. Not too easy, is it?
Ideally, there would be a volume slider and the three playback buttons on the top of the unit, between the hold switch and the remote adapter on the Mini. The hold switch is too big anyway, and could be rotated 90 degrees so so that it moves front-to-back, with no loss of usability.
Yes, I know you can get an aftermarket remote-control dongle from Apple that does this, but have you looked at those? Big, ugly, heavy things that dangle from the headphones like a tumor. Couldn't they have made something that fit flat against the top of the unit - you know, kind of an elegant design?
Anyway, I love the unit, but hate the annoyance. It's a small annoyance, but it makes an obvious wart on a really clean design.
Oh, and the ability to randomize a playlist/album would be absolutely fantastic.
According to Timothy's comment on the submission,
"Unstructured" is the key word in this patent, which (like most) is written in language that does more to obscure than illuminate. Just how structured was Mavis Beacon Teaches Typing?
Actually, Mavis Beacon was very structured (I worked for Software Toolworks/Mindscape for a number of years, and am very familiar with that product). The patent app describes "unstructured" as input specifically not from a keyboard, but from a stylus or a microphone. In Mavis, the enitire point was to press the specific keys that it wanted you to at any time, either in typing practice or in the games. It's very much a call-and-response type of learning rather than a more arbitrary scribble-random-stuff method. For that matter, so is the Speak-and-Spell (as I recall), and some of the other prior art that was suggested here.
I've read and been (unwillingly) involved in a lot of patent applications, and the point is not to write them to be obufuscatory, but not to be any more specific than necessary. Patent writing has its own language and metaphors that sound incredibly dense and complex until someone translates them for you. The main idea is to state everything in such a way that it's a) not so specific that the entire thing falls apart if you change the shape of the box and b) resistant to a sharp patent attorney picking it apart for not being specific enough (hence all the block diagrams of CPUs and descriptions of The Internet and re-restatements of the initial claim in slightly different forms). It took me several years before I could read these things and not go blind. So, this application is pretty clear: a device that takes free-form input and determines if it meets whatever criteria define a "correct" answer, and optionally talks to the instructor's computer over the network to do this.
A neat idea, yes. New and novel? Not particularly. Patentable? I don't think it should be, but that's pretty irrelevant these days. I do wish the editors would think a little more about their comments on the stories, though.
I would suggest that relevance here refers to an artist who is doing or saying something new and interesting, making insightful social commentary, generally doing something beyond the average make-it-just-like-what's-selling-at-the-moment. U2, The Clash, Bob Dylan, The Who, and Eric Clapton were all, at one time, relevant.
I actually liked U2 back when they were political and had a unique sound. I think they lost it when they began coveting industry awards and MTV cash. Now they're pretty much just another band. Good musicians, though.
I'll reply to you and the poster above:
You're both confusing popularity with relevance and quality. Just because something sells a bajillion copies doesn't mean it's any good. Or should we consider Britney Spears to be the peak of musical relevance? I could also mention that an awful lot of Grammy-winning albums are pretty boring, or that Jimmy Fallon and Adam Sandler movies tend to be "The Number One Movie in the Country" at any given time.
Or, to put it yet another way: Windows is hugely popular.
This sounds like a really cool device, although I don't particularly want or need one (if I was rich, though, hell yeah). What I'm excited about is the idea that this means that the prices for regular iPods *should* come down a little. For $250, I could rationalize a 20G unit. Or will Apple be dropping all the old models?
On a related note, I like the black model but I really wish it didn't come with all that U2 crap on it. Yes, they had several classic, groundbreaking albums, but they haven't been very relevant since what - the late 80s? How about the Little Feat model iPod, or the Stax/Volt collection model? I'd buy one of those.