I think NO penalties for ignoring copyright infringement is a bad idea,
I'm a bit confused about what you mean here. Who is ignoring copyright infringement and should be penalized for it?
The pirates today are _performing_ infringement. The Swedish MPs in question want to change the law so that it is _not_ an infringement. In free countries it is not normal to punish civilians for ignoring the petty crimes of their fellow citizens. Is it the law enforcers you want to punish, than, if they fail to crack down on file-sharers?
Why is that any more stupid than eastern and western hemispheres of a planet?
Both designations are arbitrary, but once agreed on they are useful for communicating, which is sort of what language is for. Just because _you_ don't often need to differentiate between far regions of the galaxy doesn't mean astronomers don't, and have arranged it so they can.
Several other energy conversions have this kind of high efficiency. Solar-to-electric has been lagging, and this tech might make it catch up by using a completely different approach. Lots of people have been expecting some sort of breakthrough in solar efficiency to come along for quite a while now. It is after all pretty damn obvious that there must be more efficient ways than current photovoltaics for converting light into usable energy, seeing as plants and algae do it all the time.
I'm still of course skeptical of anything until it's demonstrated, and even if the principle is sound it might take a few years of engineering to iron out the unexpected technicalities enough to make it viable ion the real world, and there's still some math an experience missing when it comes to comparing lifetime output to energy cost of production (where solar cells still suck badly, even if they've passed brak-even).
But the efficiency claim alone is no reason to call BS on this.
though I know plenty of people who just leave their photos on the camera, but they're not really doing photography for art's sake, they're just recording social events on their cheap digital cameras, on automatic
Don't those count? I guess I should have explicitly said wasn't talking about art photography. Since we were in the territory of camera phones, i was thinking about the everyday cameras that most people use.
The artistic merit may vary, but the main reason they take pictures (besides remembering) is to show them to other people. Even if you don't "just leave" your pictures on the camera, you frequently want to show them to people, _before_ you've had the chance to print them, or drag people to a PC, or find a suitable cable for using a nearby screen.
Zooming around on a stamp is just no match for a decent print when it comes to social use. Even a computer screen is terrible compared to passing around prints. TV is a good 2nd, but you need the screen, _and_ the cable. A projector might easily be next in line, and in many circumstances the only good way available.
Why you would need to project photographs from a cell phone,
Umm, have you ever tried _looking_ at photos on a typical cell phone screen? How about showing on to a group of people? No matter what resolution we might get, they remain _small_.
If you can get fair quality and resolution on a monitor-sized surface, its a whole different world. I think it would be a hit for exactly the same reasons that camera phones have been.
Hell, even pure digital cameras would would about double their usefulness with something like this.
I may sound like an old fart here, but I say teach them assembler. Just a little, mind you, and teach more high-level stuff alongside it, but have them hand in a small exercise or two that requires them to understand the basics, and gives then a mental image of what their code compiles to.
As for TFA, it sounds like the course in question was simply bad, and would have been no matter what language was used. It's like blaming the car model used in drivers' training for the bad results.
I do agree that if nothing pokes deeper than java, then the course is lacking. But the fix should be is a proper appreciation of deeper technical understanding as part of the curriculum, right along with many other goals, like information modelling and good engineering practices. That can be realized in many ways, but which language is used to teach the higher-level concepts is _not_ key.
I couldn't say for sure what is the norm for open standards development, but just about all _good_ standards are merely a codification of existing technology and implementations. Standards that are ratified before the real-world working experience exists are usually hell to work, or never get off the ground at all. Commonly they are hodegepodges of compromise between conflicting interests serving none of them well, are impossible to implement correctly, implementation efforts reveal gaping holes of under-specification, and the official 'reference implementations' tend to rather be useless, buggy, incomplete 'toy' technology demos than what their name would suggest.
Now, I agree that getting their standard ratified should not be just a rubber stamp process. There should be some vetting that might require MS to change certain things. But accusing the advantage of having the pre-standard implementation of being unfair is in itself unfair. There always will and should be someone who has that position, because the alternative is for the standard to suck.
You could argue that it should not be Microsoft who gets that position all the time, and that having someone there still doesn't guarantee that the standard won't suck, and I might agree. But argue those points, not for a 'clean-slate' standard.
The last thing we need is more paper tigers that are unusable but slow development of alternatives because "there is a standard".
they could hear the difference between a master CD and a copy of the CD. The difference? Clock jitter.
On the same player? Between lossless digital copies? Sorry, not f'ing possible. The clock that times the D/A process is in the _player_, not the disc, so the clock jitter would be exactly the same.
The clock is used to read bits from a RAM-buffer in the player (without which you couldn't implement standard CD error-correction), so unless the player is insanely stupidly built, jitter in the stream coming off the CD has no effect on the stream from the buffer to the D/A.
Either they're imagining things, or there were differences in the data stream, or some other environmental factor changed. My bet is on the first or last.
Uh, DIVs are better than tables for layout. They let the designer create more elaborate layouts more efficiently than tables, but they also make even simple layouts much more consistent and easy to implement.
The simple stuff, OK. But for elaborate layouts, I say CSS is just plain complex, unpredictable (even if implemented correctly, you have to think really hard to predict the effects of a small change), and requires lots of subtle hacks to achieve very common things. In other words, a bad design. Not because the people behind it are stupid, but because the early ideas were ratified as standard long before there was any industry experience using them to do real work and improving the dsign. This happens all the time in standardization, and it always has the same result.
I wish, when they designed a "proper" layout system, that they had included a mode more similar to the table way of thinking. No not actual tables, keep your shorts on. Not with the same syntax, of course, and optimized for layout, and not called tables, but something grid-based that would give a similar level of control and a similar mix of fixed and implicit sizing. And I'm not even talking about fixed-pixel layout: it is still much easier to make a page that scales nicely to varying font- and page sizes with tables than with CSS. This does not mean one should use tables for layout, but it does point to some fundamental flaws in CSS.
As for semantics: HTML is a _lousy_ language for expressing semantic info, and always has been. It is a persistent but irrational geek myth that HTML is a beautiful semantic design, ruined by amateurs abusing it to do layout. The semantic framework is rudimentary to say the least, and the very names of even the basic tags already mix sematics and presentation. Sorry guys, this problem is coded right into the langauge, and has been from day one.
Or is it a problem? Could it be that the reason HTML has been so successful has fuck-all to do with the semantics and everything to do with it being easy to start using, "worked" even if you did a lot of stuff "wrong", _and_ gave you some control over presentation. Those are _good_ reasons. It is what people really need. Learn from _that_ and build new stuff to suit _those_ factors.
If you want semantics today, use xml microformats and xsl-fo or something (in my dreams: a successor to css that actually provides in an easy-to-use way the layout mechanisms people need most often). HTML will continue to be a mixed bag, bacause that is what it is.
HTML is simply too convoluted for application development.
Html is not the problem. The differing javascript APIs the browsers offer is the biggie, and secondly the roundabout way you have to use to get from server response to a change in page state. And he of course CSS is just bananas even if implemented correctly and consistently, which it never is.
The goal is to meet the need, not to fulfill some inner desire to create art with lines of code.
That is true. But it is also true that code will usually be read many more times than it is written. So clarrity and structure does pay. Your example sounds more like megalomania: trying to design the universe. It is much more important for the foce to be easy to maintain and alter that for it to be 'perfect' for some fleeting and illusory interval of 'finishedness'. Just don't ever let it slip too far away from 'shippable'.
Naah. Sure, you need a good design, but you also need sound engineering practices while you're coding. From the problems he describes, I would guess he either has a bit to learn there, or is finding out the hard way how skipping the good advice doesn't pay off for long.
Not so. I have had to take over several other people's code, and the differnce in quality is huge. OK, so everyone has _something_ that bugs me, but some things are pretty easy to deal with (or quick to change, if you're really anal about style), while others are just plain cargo-cult programming where it is quite clear that even they didn't know why it works, demonstrated by how they've worked around shortcomings in a section of code that has grown too hairy, in stead of just fixing it.
Beware of the guy who delivers at staggering speed the first two weeks. Jeezus, some of the messes I've seen.
To the original poster: The most important part is not in your boss but in you - if you want to be proud of your code, you have to start by taking pride in the readability of you code. Your ambition should not be to write code that is readable, but textbook quality: it should be suitable not just as an example to others, but should itself be instructive to others. Not hat you can always do that, but you should hold it as something you _want_ not something you 'ought to'.
Yes, crunch times and asshole bosses can make it necessaary to cut corners, but make it clear that this way of working insults you (not for aesthetic reasoons, but because it's wasteful ands stupid). But you can get away with a lot of best-practice work if you stay focused and don't start adding stuff you don't need. And it usually takes less than days for tidy code to pay off, so unless someone is peeking over you shoulder, you might not even have to defend it. _Never_ do anything "quick-and-dirty". There will never be an 'afterwards' in which to tidy up. If it's worth doing, it's worth doing properly. What you _can_ (and should) do is "quick-and-_simple_": cut features to the bone until you need them. Don't be tempted to make framework when what you need is a function. But be ready to refactor it out (to the germ of a framework) when a more general version is needed. It sounds like more work, but it usually isn't in reality, and there's less code to debug later, and you won't introduce bugs when one implementation changes and the other does not. This, again, has noticable effect even on the scale of days.
To the parent: I agree that proper API comments are essntial, but faced between a well-commented but ugly API and a well-designed, well-named and consisten one with only minimal comments, I'm not sure I'd always take the well-documented one. Especially not if the code inside is clean enough to worthy an little look.
But when it comes to commenting internal code, a rally good habit is to rough out the general structure in a coarse pseudocode of TODO comments before coding, and then fill in the blanks, removing the TODO tag but leaving the text as a heading as each block is completed. And adding new todos as you think of stuff as you go along. That way the commenting becomes not a chore but a _really_ useful aid in you work, helping you think clearly and reminding you of context even when littel code is written yet. And of course, when it _saves_ work in stead of adding it, it becomes a lot more likely to get done, too.
This comment style goes very well with another good practice for readable code, that probably has another name but which I call "bailout" logic: Use guards of various types to throw out pathological or skip-cases as early as possible (throw exceptions, use 'return', 'break', and 'continue') in stead of nesting everything that actually happens deep inside multilevel if/else/switches, or constructing complex or clever (a.k.a. bug-prone) condition statements.
This makes for a nice, 'story-like' read for the 'normal' or most intersting flow. It will often be a good idea to add a brief comment after such a bailout (or the block it is in), stating the precondition that has now been met by virtue of getting here. Some people oppose this style, since you have exit points all over the place in stead of everything merging at the end. I will gladly trade that for making it _much_ easier to get a clear picture of what kind of state I'm in when I actually reach some interesting code. And you simply have less cases to worry about for most of the code.
Sometimes, if neither 'while', 'for' or 'do-while' _really_ map all that well to your actual loop logic, you can be a lot more by understandable with "while true", and then break or continue explicitly where they fit naturally in the sequence, in stead of forcing it to the start or end (or *shudder*, abusing the increment statement to do actual work)
I'd say people have displayed impressive inventiveness in order to do that. The lengths people will go to to get high are just staggering. Liking toads comes to mind.
Slashdot Mirror
I think NO penalties for ignoring copyright infringement is a bad idea,
I'm a bit confused about what you mean here.
Who is ignoring copyright infringement and should be penalized for it?
The pirates today are _performing_ infringement.
The Swedish MPs in question want to change the law so that it is _not_ an infringement.
In free countries it is not normal to punish civilians for ignoring the petty crimes of their fellow citizens.
Is it the law enforcers you want to punish, than, if they fail to crack down on file-sharers?
Actually they recently criminalized _buying_ sexual services. Selling therm is still legal, though.
All you need are two terrorists and a binary explosive with inert components that are safe enough to be consumed seperately in small quantities.
Or, evn better, one of those new-fangled "solid form" explosives.
Why is that any more stupid than eastern and western hemispheres of a planet?
Both designations are arbitrary, but once agreed on they are useful for
communicating, which is sort of what language is for. Just because _you_
don't often need to differentiate between far regions of the galaxy doesn't mean
astronomers don't, and have arranged it so they can.
Probably just one of those vertical-flip typos.
What he meant was "w00ted!".
It's not too good to be true.
Several other energy conversions have this kind of high efficiency. Solar-to-electric has been lagging, and this tech might make it catch up by using a completely different approach. Lots of people have been expecting some sort of breakthrough in solar efficiency to come along for quite a while now. It is after all pretty damn obvious that there must be more efficient ways than current photovoltaics for converting light into usable energy, seeing as plants and algae do it all the time.
I'm still of course skeptical of anything until it's demonstrated, and even if the principle is sound it might take a few years of engineering to iron out the unexpected technicalities enough to make it viable ion the real world, and there's still some math an experience missing when it comes to comparing lifetime output to energy cost of production (where solar cells still suck badly, even if they've passed brak-even).
But the efficiency claim alone is no reason to call BS on this.
Why a cellphone? [...] What about adding this projector to portable videoplayers/camera's or a (video) iPod
Duh. Because those others have already (or will very soon) moved into your cellphone too.
though I know plenty of people who just leave their photos on the camera, but they're not really doing photography for art's sake, they're just recording social events on their cheap digital cameras, on automatic
Don't those count?
I guess I should have explicitly said wasn't talking about art photography. Since we were in the territory of camera phones, i was thinking about the everyday cameras that most people use.
The artistic merit may vary, but the main reason they take pictures (besides remembering) is to show them to other people. Even if you don't "just leave" your pictures on the camera, you frequently want to show them to people, _before_ you've had the chance to print them, or drag people to a PC, or find a suitable cable for using a nearby screen.
Zooming around on a stamp is just no match for a decent print when it comes to social use. Even a computer screen is terrible compared to passing around prints. TV is a good 2nd, but you need the screen, _and_ the cable. A projector might easily be next in line, and in many circumstances the only good way available.
I've never heard it called a 'lecture' before. Oh, wait....
Why you would need to project photographs from a cell phone,
Umm, have you ever tried _looking_ at photos on a typical cell phone screen?
How about showing on to a group of people?
No matter what resolution we might get, they remain _small_.
If you can get fair quality and resolution on a monitor-sized surface,
its a whole different world. I think it would be a hit for exactly
the same reasons that camera phones have been.
Hell, even pure digital cameras would would about double their usefulness
with something like this.
I may sound like an old fart here, but I say teach them assembler. Just a little, mind you, and teach more high-level stuff alongside it, but have them hand in a small exercise or two that requires them to understand the basics, and gives then a mental image of what their code compiles to.
As for TFA, it sounds like the course in question was simply bad, and would have been no matter what language was used. It's like blaming the car model used in drivers' training for the bad results.
I do agree that if nothing pokes deeper than java, then the course is lacking. But the fix should be is a proper appreciation of deeper technical understanding as part of the curriculum, right along with many other goals, like information modelling and good engineering practices. That can be realized in many ways, but which language is used to teach the higher-level concepts is _not_ key.
It's a warning.
I thought you guys didn't believe in global warning?
Is this how an open standard is developed?
I couldn't say for sure what is the norm for open standards development, but just about all _good_ standards are merely a codification of existing technology and implementations. Standards that are ratified before the real-world working experience exists are usually hell to work, or never get off the ground at all. Commonly they are hodegepodges of compromise between conflicting interests serving none of them well, are impossible to implement correctly, implementation efforts reveal gaping holes of under-specification, and the official 'reference implementations' tend to rather be useless, buggy, incomplete 'toy' technology demos than what their name would suggest.
Now, I agree that getting their standard ratified should not be just a rubber stamp process. There should be some vetting that might require MS to change certain things. But accusing the advantage of having the pre-standard implementation of being unfair is in itself unfair. There always will and should be someone who has that position, because the alternative is for the standard to suck.
You could argue that it should not be Microsoft who gets that position all the time, and that having someone there still doesn't guarantee that the standard won't suck, and I might agree. But argue those points, not for a 'clean-slate' standard.
The last thing we need is more paper tigers that are unusable but slow development of alternatives because "there is a standard".
As I understand it
You don't. If unicode domain names becomes commonplace, why would not browsers adapt to displaying them 'properly'?
when you turn information into your lawyer,...
-then that's a pretty darn neat trick.
they could hear the difference between a master CD and a copy of the CD. The difference? Clock jitter.
On the same player? Between lossless digital copies?
Sorry, not f'ing possible.
The clock that times the D/A process is in the _player_, not the disc, so the clock jitter would be exactly the same.
The clock is used to read bits from a RAM-buffer in the player (without which you couldn't implement standard CD error-correction), so unless the player is insanely stupidly built, jitter in the stream coming off the CD has no effect on the stream from the buffer to the D/A.
Either they're imagining things, or there were differences in the data stream, or some other environmental factor changed. My bet is on the first or last.
Were they told which disc was which?
I couldn't help wondering how he rose to IT support
Too easy: you don't rise to IT support...
Uh, DIVs are better than tables for layout. They let the designer create more elaborate layouts more efficiently than tables, but they also make even simple layouts much more consistent and easy to implement.
The simple stuff, OK. But for elaborate layouts, I say CSS is just plain complex, unpredictable (even if implemented correctly, you have to think really hard to predict the effects of a small change), and requires lots of subtle hacks to achieve very common things. In other words, a bad design. Not because the people behind it are stupid, but because the early ideas were ratified as standard long before there was any industry experience using them to do real work and improving the dsign. This happens all the time in standardization, and it always has the same result.
I wish, when they designed a "proper" layout system, that they had included a mode more similar to the table way of thinking. No not actual tables, keep your shorts on. Not with the same syntax, of course, and optimized for layout, and not called tables, but something grid-based that would give a similar level of control and a similar mix of fixed and implicit sizing. And I'm not even talking about fixed-pixel layout: it is still much easier to make a page that scales nicely to varying font- and page sizes with tables than with CSS. This does not mean one should use tables for layout, but it does point to some fundamental flaws in CSS.
As for semantics: HTML is a _lousy_ language for expressing semantic info, and always has been. It is a persistent but irrational geek myth that HTML is a beautiful semantic design, ruined by amateurs abusing it to do layout. The semantic framework is rudimentary to say the least, and the very names of even the basic tags already mix sematics and presentation. Sorry guys, this problem is coded right into the langauge, and has been from day one.
Or is it a problem? Could it be that the reason HTML has been so successful has fuck-all to do with the semantics and everything to do with it being easy to start using, "worked" even if you did a lot of stuff "wrong", _and_ gave you some control over presentation. Those are _good_ reasons. It is what people really need. Learn from _that_ and build new stuff to suit _those_ factors.
If you want semantics today, use xml microformats and xsl-fo or something (in my dreams: a successor to css that actually provides in an easy-to-use way the layout mechanisms people need most often). HTML will continue to be a mixed bag, bacause that is what it is.
HTML is simply too convoluted for application development.
Html is not the problem. The differing javascript APIs the browsers offer is the biggie,
and secondly the roundabout way you have to use to get from server response to a change in page state. And he of course CSS is just bananas even if implemented correctly and consistently, which it never is.
The goal is to meet the need, not to fulfill some inner desire to create art with lines of code.
That is true. But it is also true that code will usually be read many more times than it is written. So clarrity and structure does pay. Your example sounds more like megalomania: trying to design the universe. It is much more important for the foce to be easy to maintain and alter that for it to be 'perfect' for some fleeting and illusory interval of 'finishedness'. Just don't ever let it slip too far away from 'shippable'.
Naah. Sure, you need a good design, but you also need sound engineering practices while you're coding. From the problems he describes, I would guess he either has a bit to learn there, or is finding out the hard way how skipping the good advice doesn't pay off for long.
Not so. I have had to take over several other people's code, and the differnce in quality is huge. OK, so everyone has _something_ that bugs me, but some things are pretty easy to deal with (or quick to change, if you're really anal about style), while others are just plain cargo-cult programming where it is quite clear that even they didn't know why it works, demonstrated by how they've worked around shortcomings in a section of code that has grown too hairy, in stead of just fixing it.
Beware of the guy who delivers at staggering speed the first two weeks. Jeezus, some of the messes I've seen.
To the original poster:
The most important part is not in your boss but in you - if you want to be proud of your code, you have to start by taking pride in the readability of you code. Your ambition should not be to write code that is readable, but textbook quality: it should be suitable not just as an example to others, but should itself be instructive to others. Not hat you can always do that, but you should hold it as something you _want_ not something you 'ought to'.
Yes, crunch times and asshole bosses can make it necessaary to cut corners, but make it clear that this way of working insults you (not for aesthetic reasoons, but because it's wasteful ands stupid). But you can get away with a lot of best-practice work if you stay focused and don't start adding stuff you don't need. And it usually takes less than days for tidy code to pay off, so unless someone is peeking over you shoulder, you might not even have to defend it. _Never_ do anything "quick-and-dirty". There will never be an 'afterwards' in which to tidy up. If it's worth doing, it's worth doing properly. What you _can_ (and should) do is "quick-and-_simple_": cut features to the bone until you need them. Don't be tempted to make framework when what you need is a function. But be ready to refactor it out (to the germ of a framework) when a more general version is needed. It sounds like more work, but it usually isn't in reality, and there's less code to debug later, and you won't introduce bugs when one implementation changes and the other does not. This, again, has noticable effect even on the scale of days.
To the parent:
I agree that proper API comments are essntial, but faced between a well-commented but ugly API and a well-designed, well-named and consisten one with only minimal comments, I'm not sure I'd always take the well-documented one. Especially not if the code inside is clean enough to worthy an little look.
But when it comes to commenting internal code, a rally good habit is to rough out the general structure in a coarse pseudocode of TODO comments before coding, and then fill in the blanks, removing the TODO tag but leaving the text as a heading as each block is completed. And adding new todos as you think of stuff as you go along. That way the commenting becomes not a chore but a _really_ useful aid in you work, helping you think clearly and reminding you of context even when littel code is written yet. And of course, when it _saves_ work in stead of adding it, it becomes a lot more likely to get done, too.
This comment style goes very well with another good practice for readable code, that probably has another name but which I call "bailout" logic:
Use guards of various types to throw out pathological or skip-cases as early as possible (throw exceptions, use 'return', 'break', and 'continue') in stead of nesting everything that actually happens deep inside multilevel if/else/switches, or constructing complex or clever (a.k.a. bug-prone) condition statements.
This makes for a nice, 'story-like' read for the 'normal' or most intersting flow. It will often be a good idea to add a brief comment after such a bailout (or the block it is in), stating the precondition that has now been met by virtue of getting here.
Some people oppose this style, since you have exit points all over the place in stead of everything merging at the end. I will gladly trade that for making it _much_ easier to get a clear picture of what kind of state I'm in when I actually reach some interesting code. And you simply have less cases to worry about for most of the code.
Sometimes, if neither 'while', 'for' or 'do-while' _really_ map all that well to your actual loop logic, you can be a lot more by understandable with "while true", and then break or continue explicitly where they fit naturally in the sequence, in stead of forcing it to the start or end (or *shudder*, abusing the increment statement to do actual work)
I'd say people have displayed impressive inventiveness in order to do that. The lengths people will go to to get high are just staggering. Liking toads comes to mind.
What is wrong with the seed bank at Kew Gardens near London?
Well, in the event of, say, a nuclear war, the Greater London area seems a tad more likely to be hit than Svalbard.
Plus, the trek to Svalbard to retrieve the seeds that will save mankind will make a much more spectacular movie than strolling over to Kew Gardens.