my photos are categorized by location, then sub-categorized by date. My emails are categorized by sender or by mailing list. My music is categorized by artist, and subcategorized by CD. All this is done automatically, with very little effort on my part.
Ah, but that's very different. In the case of photos and emails, the metadata is created at the moment the content comes into existence, and so what that argues for is more power on cameras and so forth which would allow the user to assign metadata at the time the content is created (geotagging is an excellent example of this).
As for music, I hate to break it to you, buddy, but someone manually created that metadata for you. You just get to benefit from their labour.
Now, what about semantic tagging? I've got 54,000 photos. Manual tagging would take months: I'd need to inspect each photo to figure out what tags to apply
Yeah, and it would take a long time to properly organize 54k images into folders, too. But, of course, you'd never do that. Every time you took a batch of photos, you'd assign the metadata at that point, and so you'd amortize the effort over time.
This is a slow process, and it's not clear that the benefits would outweigh the costs.
Well, now that's a separate question. Perhaps, for you, it wouldn't be. But the simple fact is, at least in the near-term, computers will simply be incapable of automatically deducing metadata based on the content itself, so manual organization is really the only option, and I don't think most people would expect anything else.
And disposing of moderately radioactive fusion reactors at end-of-life. Mustn't forget that part.
Well, unless we can develop and commercialize aneutronic fusion (eg, hydrogen-boron). 'course, that's a hell of a lot harder, but certainly not impossible (particularly given the lessons that will be learned while mastering sustainable D-T fusion).
Well, if you just RTFS, you'll note that "Dr. Dittmar's final conclusions paint a dire picture, stating that options like large-scale commercial fission breeder reactors are not an option by 2013", due to simple engineering and logistical hurdles thanks to the immaturity of the technology (ie, while the science and basic engineering is done, that's an far cry from commercialization).
After I started using nepomuk, that number icreased by around 20% - still pretty lean considering what it does.
What on earth can it be doing such that 400MB of RAM is justified? AFAICT, it's nothing more than a glorified metadata database. Sounds like the precise opposite of "lean" to me...
I saw a preview of the semantic desktop at the Open World Forum in Paris and I think it has the same down-fall as other initiatives: you need to tag most of it yourself.
Umm... so? Last I checked, you had to manually organize your various files, documents, etc, into folders, and given that tags are just a superset of the functionality provided by folders, I don't see why one wouldn't expect to have to do the same with tags.
Oh, and aside from the fact that wine isn't, actually, an emulator:), you're right, in principle Wine could implement graphics scaling/doubling in their output routines, although TBH, I'm not sure how complex that would be (it's not like Wine does all it's rendering in a back-buffer and then just dumps the whole thing to the screen).
OTOH, I wonder if, perhaps, compiz could come to the rescue, here? In theory, one could pretty easily write a plugin which would actually scale up the contents of a window while using the card's onboard antialiasing hardware to keep things nice and clear.
Wine is an emulator(yes I know that it claims not to be, but it is). It emulates Windows(or at least a part of windows) on Linux. Yes it emulates system calls instead of emulating an OS, but that's really neither here nor there.
Uhuh. So, what, glibc just emulates the POSIX standard? Mono emulates.NET? OpenJVM emulates Java? Because these are all precise analogous to Wine (which is an independent, portable implementation of a wide variety of Windows APIs).
I was initially impressed by the MS 'open' pledges, until I talked to several coder friends.
And, what, your "coder friends" have some uniquely gifted insight into the workings of MS?
The problem, as it was explained to me, is that if you want to do anything useful, you have to call a bunch of things that are not opened, will not be opened, and MS can still sue your *ss off for using.
Then don't use them. Mono has an excellent stack of APIs which provide access to all manner of free software, including databases, Gtk, Gnome and it's libraries, Gstreamer, and so forth.
As for the core.NET libraries, they're already covered by the community promise, so go nuts.
Sir, your attitude is a breath a fresh air. Any programmer who doesn't submit a formal and rigorous proof of every algorithm they write to a peer reviewed academic research journal is an incompetent hack who couldn't program his way out of a cardboard box.
Are you *seriously* trying to equate the ability to understand one's own code with "a formal and rigorous proof"? Really? To that, all I can really say is: Wow. Please, get out of the industry. Now.
True enough. Any kind of external dependency may force hacky solutions to problems, be it buggy libraries or a wonking programming language (BTW, I quite enjoy writing Perl, but it's definitely... idiosyncratic:).
But in a case like that, it's important that the developer describe what they'd like to do, and why they settled on the solution they selected, so that someone coming along later can understand why it's written the way it is.
you often wind up using certain functions heavily that reveal themselves to have strange quirks
since these functions are effectively black boxes that your average developer has no legal ability to understand deeper, you have to leave it at that
Ah, external dependencies are a very different thing, though.
If I'm coding against an external library, and it behaves unexpectedly, there's little I can do but to document the issue, explain that the code is written to work around a mysterious library bug, and move on, understanding that what I've produced may be brittle going forward.
But we're not talking about external dependencies, here. The OP simply wrote a piece of code he didn't understand. And that's a problem.
Nowhere in "faster and cheaper" is there room for your mythic "formalized discipline."
Wait... suddenly understanding your own code is "formalized discipline"? Might I suggest your standards are simply too low? Because, in my mind, understanding your own code is in the category of "basic competency".
Construction, even of your vaunted bridges is filled with hacks carried out at all levels of the build.
Oh please. Inexactitude is *not* the same thing as not understanding why something works at all. We can build miles-long bridges *specifically* because we understand the underlying physics, and anyone who built a bridge without understanding the physics of why it stood under load would be drummed out of the industry.
Software development typically isn't engineering. It's usually a business of maximizing productive features versus minimizing cost and time. Rarely is the answer to further investigate working code.
Sorry, that's crap. Any code complex enough to be difficult to understand is specifically the code that requires extra care and attention to ensure it's correct. If you don't understand why your complex algorithm works, you need to spend more time to understand it, as the odds are extremely good that it's a) not correct, and b) not maintainable.
I worked tech support a few years at company writing foxpro code who got on a conference call with Microsoft before and they told us they didn't know why it was doing this either because as far as their documentation was concerned it shouldn't be working under those circumstances.
And as management was concerned we were wasting time and MS support call fees if we continued any further on the matter.
That's not at all the same thing. In this case, the code is clearly not conforming to the requirements/specification laid out, and as such, the behaviour you've identified is a bug, and MS should, internally, be treating it accordingly, which means investigating the issue, and then either fixing it in a subsequent release, or documenting it if a fix isn't possible (eg, backward compatibility concerns, possible unintended side-effects, etc).
As for the customer, it may be perfectly acceptable to live with the issue as a known bug in the current release and move on.
But the GP admitted to something very different, whereby he actually wrote code he didn't understand, and then *never bothered to try and understand it*. And that is behaviour indicative of someone who, frankly, isn't fit to be a professional software developer.
On the basis of your username, I'm perplexed as to why you somehow failed to properly letter the items of your list. Perhaps "c) ???" should have come in front of "d) Profit!" (well, a rather long and windy version of "profit", but boils down to it basically)?
ROFL, because I'm a moron, that's why. Honestly, is that so hard to understand?
And while you're spending your time figuring out why something that isn't broken works, he is coding something that you aren't coding at all. Sure, coding until it passes isn't the ideal, but it's a whole lot better than not coding at all (you).
Bullshit. Software development isn't just about "coding". It's about producing software that's functional and maintainable. "Hacking it until it works" is completely antithetical to those goals.
Frankly, morons like you are the reason the industry is laughed at by other, more formalized disciplines. Could you imagine what we'd do to a bridge builder who just tacked stuff on until it kinda sorta stood?
In your example, the code you got working for -x, +y may not have been "Good", but if it passes the Unit Tests, then how is it really bad?
How is it bad?? Christ, the metric for "good" code isn't that it simply "works". It also needs to be readable, comprehensible, and maintainable. If you can't understand how your own code works, it's bloody obvious it fails on at least one of those metrics.
Besides which, unless you are 100% positive that your unit test covers *all* cases, the fact that your code passes tells you nothing about it's correctness.
You know, back in my university days, we used to scoff at the morons in the labs who would, quite literally, randomly hack their projects until they worked. I never dreamed that some would consider that a valid development methodology out in the real world. Apparently there *is* a dark side to a high-quality unit test suite... it gives idiots a false sense of security and justifies their idiotic development practices.
The code worked, but I didn't understand why and said so. Is that bad coding? It worked!
Yes. It's bad coding. Very very bad coding. And, no offense, but it indicates intellectual laziness on your part.
Any developer worth their salt would spend the time to understand *why* their code is mysteriously working, rather than just throwing up their hands and moving on, as a) it might be working for your test cases but still be incorrect, and b) anyone coming along later will be hosed, as if you couldn't understand it, there's a good chance they won't be able to, either. And of course, d) any developer worth their salt *wants* to know why their code is working, simply because it's interesting and *part of their job*.
Well, I think the parenthetical is actually the key bit. I find when I'm implementing a complex algorithm, I'll write out a fairly long-winded comment that explains, in prose, what the code is doing, and then in the code itself, I'll include comments for the trickier bits. I do this because I find that a bunch of small comments in a routine is harder to conceptualize, as you have to assemble the global picture yourself. But a large comment at the start that sets the stage and outlines the algorithm takes care of that for you, and the inner comments then make more sense within that framework.
But this is *very* different from a large comment that comes down to, as the author puts it, an "excuse". OTOH, I can't say I've ever come across such a thing... a developer embarrassed by their code is far more likely to not document it at all, rather than take the time to justify themselves.
this is probably wrong on a couple of levels. First, teachers don't really have money to spend.
If that's true, then this is a non-issue, as the marketplace will never get going, right?
And second, at every job I've had the employers own my work.
No, they *tell* you they own your work. The reality may be very different, and depends strongly on the contents of your employment contract, and how that work was created. For example, work created on the clock, or using work resources, might qualify as a work-for-hire. But if these teachers create their lesson plans at home, outside the classroom, then unless the contract with their school explicitly lays claim to their work-related creations (and as I understand it, your average teaching contract doesn't), it's not at all clear that the school owns the rights to that work.
Have you not watched "Where No Man Has Gone Before"? Jesus christ, the entire plot is centered around them deliberately flying through the galactic barrier in order to find a lost ship.
Slashdot Mirror
my photos are categorized by location, then sub-categorized by date. My emails are categorized by sender or by mailing list. My music is categorized by artist, and subcategorized by CD. All this is done automatically, with very little effort on my part.
Ah, but that's very different. In the case of photos and emails, the metadata is created at the moment the content comes into existence, and so what that argues for is more power on cameras and so forth which would allow the user to assign metadata at the time the content is created (geotagging is an excellent example of this).
As for music, I hate to break it to you, buddy, but someone manually created that metadata for you. You just get to benefit from their labour.
Now, what about semantic tagging? I've got 54,000 photos. Manual tagging would take months: I'd need to inspect each photo to figure out what tags to apply
Yeah, and it would take a long time to properly organize 54k images into folders, too. But, of course, you'd never do that. Every time you took a batch of photos, you'd assign the metadata at that point, and so you'd amortize the effort over time.
This is a slow process, and it's not clear that the benefits would outweigh the costs.
Well, now that's a separate question. Perhaps, for you, it wouldn't be. But the simple fact is, at least in the near-term, computers will simply be incapable of automatically deducing metadata based on the content itself, so manual organization is really the only option, and I don't think most people would expect anything else.
corporations and the wealthy *flaunt* the tax system
Like... walk it around town and show everyone how incredibly sexy it is? Or mayhap you meant flout? :)
And disposing of moderately radioactive fusion reactors at end-of-life. Mustn't forget that part.
Well, unless we can develop and commercialize aneutronic fusion (eg, hydrogen-boron). 'course, that's a hell of a lot harder, but certainly not impossible (particularly given the lessons that will be learned while mastering sustainable D-T fusion).
Well, if you just RTFS, you'll note that "Dr. Dittmar's final conclusions paint a dire picture, stating that options like large-scale commercial fission breeder reactors are not an option by 2013", due to simple engineering and logistical hurdles thanks to the immaturity of the technology (ie, while the science and basic engineering is done, that's an far cry from commercialization).
After I started using nepomuk, that number icreased by around 20% - still pretty lean considering what it does.
What on earth can it be doing such that 400MB of RAM is justified? AFAICT, it's nothing more than a glorified metadata database. Sounds like the precise opposite of "lean" to me...
I saw a preview of the semantic desktop at the Open World Forum in Paris and I think it has the same down-fall as other initiatives: you need to tag most of it yourself.
Umm... so? Last I checked, you had to manually organize your various files, documents, etc, into folders, and given that tags are just a superset of the functionality provided by folders, I don't see why one wouldn't expect to have to do the same with tags.
Oh, and aside from the fact that wine isn't, actually, an emulator :), you're right, in principle Wine could implement graphics scaling/doubling in their output routines, although TBH, I'm not sure how complex that would be (it's not like Wine does all it's rendering in a back-buffer and then just dumps the whole thing to the screen).
OTOH, I wonder if, perhaps, compiz could come to the rescue, here? In theory, one could pretty easily write a plugin which would actually scale up the contents of a window while using the card's onboard antialiasing hardware to keep things nice and clear.
Wine is an emulator(yes I know that it claims not to be, but it is). It emulates Windows(or at least a part of windows) on Linux. Yes it emulates system calls instead of emulating an OS, but that's really neither here nor there.
Uhuh. So, what, glibc just emulates the POSIX standard? Mono emulates .NET? OpenJVM emulates Java? Because these are all precise analogous to Wine (which is an independent, portable implementation of a wide variety of Windows APIs).
I was initially impressed by the MS 'open' pledges, until I talked to several coder friends.
And, what, your "coder friends" have some uniquely gifted insight into the workings of MS?
The problem, as it was explained to me, is that if you want to do anything useful, you have to call a bunch of things that are not opened, will not be opened, and MS can still sue your *ss off for using.
Then don't use them. Mono has an excellent stack of APIs which provide access to all manner of free software, including databases, Gtk, Gnome and it's libraries, Gstreamer, and so forth.
As for the core .NET libraries, they're already covered by the community promise, so go nuts.
Comments need maintained.
So do design documents and test suites. Are you suggesting we shouldn't bother with those, either?
Sir, your attitude is a breath a fresh air. Any programmer who doesn't submit a formal and rigorous proof of every algorithm they write to a peer reviewed academic research journal is an incompetent hack who couldn't program his way out of a cardboard box.
Are you *seriously* trying to equate the ability to understand one's own code with "a formal and rigorous proof"? Really? To that, all I can really say is: Wow. Please, get out of the industry. Now.
ROFL, well, it looks like someone came along and fixed it, not only modding your comment Funny, but giving mine a +1 Informative.
Also known as survivorship bias.
True enough. Any kind of external dependency may force hacky solutions to problems, be it buggy libraries or a wonking programming language (BTW, I quite enjoy writing Perl, but it's definitely... idiosyncratic :).
But in a case like that, it's important that the developer describe what they'd like to do, and why they settled on the solution they selected, so that someone coming along later can understand why it's written the way it is.
you often wind up using certain functions heavily that reveal themselves to have strange quirks
since these functions are effectively black boxes that your average developer has no legal ability to understand deeper, you have to leave it at that
Ah, external dependencies are a very different thing, though.
If I'm coding against an external library, and it behaves unexpectedly, there's little I can do but to document the issue, explain that the code is written to work around a mysterious library bug, and move on, understanding that what I've produced may be brittle going forward.
But we're not talking about external dependencies, here. The OP simply wrote a piece of code he didn't understand. And that's a problem.
Nowhere in "faster and cheaper" is there room for your mythic "formalized discipline."
Wait... suddenly understanding your own code is "formalized discipline"? Might I suggest your standards are simply too low? Because, in my mind, understanding your own code is in the category of "basic competency".
Construction, even of your vaunted bridges is filled with hacks carried out at all levels of the build.
Oh please. Inexactitude is *not* the same thing as not understanding why something works at all. We can build miles-long bridges *specifically* because we understand the underlying physics, and anyone who built a bridge without understanding the physics of why it stood under load would be drummed out of the industry.
Software development typically isn't engineering. It's usually a business of maximizing productive features versus minimizing cost and time. Rarely is the answer to further investigate working code.
Sorry, that's crap. Any code complex enough to be difficult to understand is specifically the code that requires extra care and attention to ensure it's correct. If you don't understand why your complex algorithm works, you need to spend more time to understand it, as the odds are extremely good that it's a) not correct, and b) not maintainable.
I worked tech support a few years at company writing foxpro code who got on a conference call with Microsoft before and they told us they didn't know why it was doing this either because as far as their documentation was concerned it shouldn't be working under those circumstances.
And as management was concerned we were wasting time and MS support call fees if we continued any further on the matter.
That's not at all the same thing. In this case, the code is clearly not conforming to the requirements/specification laid out, and as such, the behaviour you've identified is a bug, and MS should, internally, be treating it accordingly, which means investigating the issue, and then either fixing it in a subsequent release, or documenting it if a fix isn't possible (eg, backward compatibility concerns, possible unintended side-effects, etc).
As for the customer, it may be perfectly acceptable to live with the issue as a known bug in the current release and move on.
But the GP admitted to something very different, whereby he actually wrote code he didn't understand, and then *never bothered to try and understand it*. And that is behaviour indicative of someone who, frankly, isn't fit to be a professional software developer.
On the basis of your username, I'm perplexed as to why you somehow failed to properly letter the items of your list. Perhaps "c) ???" should have come in front of "d) Profit!" (well, a rather long and windy version of "profit", but boils down to it basically)?
ROFL, because I'm a moron, that's why. Honestly, is that so hard to understand?
And while you're spending your time figuring out why something that isn't broken works, he is coding something that you aren't coding at all. Sure, coding until it passes isn't the ideal, but it's a whole lot better than not coding at all (you).
Bullshit. Software development isn't just about "coding". It's about producing software that's functional and maintainable. "Hacking it until it works" is completely antithetical to those goals.
Frankly, morons like you are the reason the industry is laughed at by other, more formalized disciplines. Could you imagine what we'd do to a bridge builder who just tacked stuff on until it kinda sorta stood?
In your example, the code you got working for -x, +y may not have been "Good", but if it passes the Unit Tests, then how is it really bad?
How is it bad?? Christ, the metric for "good" code isn't that it simply "works". It also needs to be readable, comprehensible, and maintainable. If you can't understand how your own code works, it's bloody obvious it fails on at least one of those metrics.
Besides which, unless you are 100% positive that your unit test covers *all* cases, the fact that your code passes tells you nothing about it's correctness.
You know, back in my university days, we used to scoff at the morons in the labs who would, quite literally, randomly hack their projects until they worked. I never dreamed that some would consider that a valid development methodology out in the real world. Apparently there *is* a dark side to a high-quality unit test suite... it gives idiots a false sense of security and justifies their idiotic development practices.
The code worked, but I didn't understand why and said so. Is that bad coding? It worked!
Yes. It's bad coding. Very very bad coding. And, no offense, but it indicates intellectual laziness on your part.
Any developer worth their salt would spend the time to understand *why* their code is mysteriously working, rather than just throwing up their hands and moving on, as a) it might be working for your test cases but still be incorrect, and b) anyone coming along later will be hosed, as if you couldn't understand it, there's a good chance they won't be able to, either. And of course, d) any developer worth their salt *wants* to know why their code is working, simply because it's interesting and *part of their job*.
Well, I think the parenthetical is actually the key bit. I find when I'm implementing a complex algorithm, I'll write out a fairly long-winded comment that explains, in prose, what the code is doing, and then in the code itself, I'll include comments for the trickier bits. I do this because I find that a bunch of small comments in a routine is harder to conceptualize, as you have to assemble the global picture yourself. But a large comment at the start that sets the stage and outlines the algorithm takes care of that for you, and the inner comments then make more sense within that framework.
But this is *very* different from a large comment that comes down to, as the author puts it, an "excuse". OTOH, I can't say I've ever come across such a thing... a developer embarrassed by their code is far more likely to not document it at all, rather than take the time to justify themselves.
this is probably wrong on a couple of levels. First, teachers don't really have money to spend.
If that's true, then this is a non-issue, as the marketplace will never get going, right?
And second, at every job I've had the employers own my work.
No, they *tell* you they own your work. The reality may be very different, and depends strongly on the contents of your employment contract, and how that work was created. For example, work created on the clock, or using work resources, might qualify as a work-for-hire. But if these teachers create their lesson plans at home, outside the classroom, then unless the contract with their school explicitly lays claim to their work-related creations (and as I understand it, your average teaching contract doesn't), it's not at all clear that the school owns the rights to that work.
Have you not watched "Where No Man Has Gone Before"? Jesus christ, the entire plot is centered around them deliberately flying through the galactic barrier in order to find a lost ship.