Re:Sometimes the correct answer is the simplest
on
Why Corporates Hate Perl
·
· Score: 5, Insightful
The problem here is that small != mean efficient. Parsing the code is not what makes a program slow, and we don't code for 1K or RAM anymore.
"impressive" oneliners completely fail to impress me. Lines are cheap. Time is not. And bugs are expensive as hell.
I'm sure if you wrote code that walked through the steps in what you are trying to achieve, all the following would be quicker:
* for me to see the point of what you're doing * for me to correctly change what it does. * for you to get it working right in the first place.
If you feel it is childish to write code like
"find A"
"find B based on A"
"generate C based on B"
"silently fail for some values of C"
"replace B with C" -rather than one giant, brittle regex-replace, I submit that you are the childish one.
None of the things you mention improve clarity, modularity and maintainability. Well possibly wrapped accessors, but only when called for.
What i meant was avoid clever-but-stupid shit like displaying how much crap you can get done with a bodyless for-loop, deep if-trees that might save you a superflous comparison or two, but take all day to read correctly and correctly implement a really simple change in the underlying rule.
If you do database access, data representation, transformations and file output, please don't do them all all over the place. You don't need to amake a plugin architecture, but it really doesn't cost much to design a simple output module API so it might be switched with a completely different output engine later. And guess what: it will make your code clearer and better even if you never make that second output module.
Hell I've seen developers say C/C++ are "dead" and that shiny_language_x is going to take over.
That may be not so much fadism as well-informed wishful thinking.
OK, plain C is not _that_ bad, but you do need to fight its innate spirit in order to implement sane coding practices.
But I recently had to return to C++ on a recent project, and although I was expecting some tedium, it was way worse that I remembered. MY GOD how painful it makes a lot of really trivial things. Even the nasty hack known as PHP starts looking well planned in this light.
It may be better than alernatives if you really need the performance and low-level capabilities, but if you don't (or only a small part of your project does), you're paying a huge price for wizard points you don't need.
Glitzy clicky interfaces do not a good product make, but a platform where _some_ thought has been given to workflow really is something we should start to expect in this day and age.
I would also dispute the idea that the simplicity of newer code is necessarily a good thing. Maybe they are yet to find all the bugs that require inelegant solutions...
That could of course be the case.
But it is a fact that some programmers have slightly too much interest in "clever" tricks, compactness, and optimisations whether they're called for or not, and too little in clarity, modularity and maintainability. I won't claim this as fact, but I also strongly suspect that this kind of programmer also tends to love perl (you find them everywhere though). Many lose these traits as they mature, get to experience the pain and cost of working other people's unreadable code, and as you get more proficient you simply aren't that impressed by low-level coding skills any more. But some seem incurable.
That's a tough one. I guess what it boils own to is "is executing every motherfucking last one of you and extroverted or introverted thing to do?", and does it matter if you're the 77th one to do it?
No need to bring on the misanthropic nut jobs, this point (and the need to avoid it) has been recognized for as long as the rest of modern legal thinking.
The blocks (allegedly symbolic of wind, water, etc.) looked real (I mean physically existing), but controlled by hydraulics
Jesus Christ, you are so naïve. Can't you see the entire opening was faked? It's just like the moon thing: anyone not totally brainwashed only needs a passing glance at the night sky to tell the moon is 'shopped in. The shadow are all wrong. In fact China does not exist at all.
Nor do you, for that matter; that's just what they want you to believe.
complete with no gasoline/diesel powered vehicles,
Yeah, well I'm sure that will work out just fine, right up until someone with no common sense figures out he can just "drop no gasoline powered vehicle" for a free ride.
There is rather a lot more to how people behave than "knowledge", and some of them are in deed (as far as we can tell) innate. Good interfaces do play on those things, be it through explicit knowledge of them, trial and failure, or intuition.
In addition comes course all the cultural stuff, and you are right that this is hugely important too.
But if you haven't grasped (explicitly or tacitly) for example some of the basic human limitations in attention, perception, information retention, and processing, chances are you will make horrible interfaces.
Actually, a thorough round of moist wipes + deodorant to the armpits, while far from equivalent to a shower, will cut quite impressively into your BO unless it's been "maturing" for some time.
If in addition you were squeaky clean and deodorized just an hour ago (and are not the naturally most smelly person. There are big differences), you might be OK. The fresh clothes are still a must, though.
By thermal I meant all electric plants powered by heat (coal, oil, gas, nuclear, geothermal, solar-thermal). They don't use thermoelectric conversion because top-end mechanical conversion is much more efficient, and probably still will be even with this new step in thermoelectric converters. Waste heat is better used for heating, and in any case don't delver the sort of temperature gradient you need for efficient thermoelectric.
I agree that small-scale stuff is probably nearer in time as a viable application, since small-scale mechanical engines are less efficient (although a good sterling engine is still pretty impressive). Heating remains the best application for small-scale geothermal remains heating, though.
I think there is still a loong way to go to compete with modern land-based thermal plants. Even modern ships stretch their diesel impressively far.
But for applications where you can't lug around industrial-scale heavy machinery, all improvements in heat reclamation are welcome, even though it's all in a different ballpark for the foreseeable future.
The problem is that efficiency is utterly lousy to begin with, and then degrades, so it is only used in very niche applications. If the new material improves even just the lifetime issue, it expands usefulness quite dramatically.
Yeah, blowing up (as opposed to imparting a net impulse) such a rubble-pile-type asteroid with a nuke would slightly disperse it temporarily, after which it would largely reassemble under its own gravity and continue on its old course (center of mass etc..), only now its radioactive as hell...
With a hard and rocky asteroid the nuke might fragment and disperse it effectively enough for the fallout to be worth it, but we better have some more tricks up our sleeve for the other types.
OK, bad wording on my part. But the view I'm opposing, that RDMSs are the be-all end-all of application design and the correct solution to every problem, is equally dumb and actually quite widespread.
The RDBMS concept was a stroke of genius back when, I agree, and it is still a great solution for many things. But it has also become the lazy answer; the proverbial hammer. To the extent that people often sit down and design their tables before even thinking about user requirements. People forget - or even seem incapable of grasping - other models to evaluate. This hinders progress because there are a lot of things that simply don't go well with that kind of structure, but never get a chance because everyone takes the RDBM basis for granted.
Sadly, there are few mature persistence products out there using other models, beacause the market isn't there.
I was talking chiefly about stored procedures, and my issue was not with portability, but that most of the the application need to be shoehorned into how relational databases work, limiting the applicability of other lauded design principles.
Slashdot Mirror
The problem here is that small != mean efficient.
Parsing the code is not what makes a program slow, and
we don't code for 1K or RAM anymore.
"impressive" oneliners completely fail to impress me.
Lines are cheap.
Time is not.
And bugs are expensive as hell.
I'm sure if you wrote code that walked through the
steps in what you are trying to achieve, all the
following would be quicker:
* for me to see the point of what you're doing
* for me to correctly change what it does.
* for you to get it working right in the first place.
If you feel it is childish to write code like
"find A"
"find B based on A"
"generate C based on B"
"silently fail for some values of C"
"replace B with C"
-rather than one giant, brittle regex-replace, I submit that you are the childish one.
None of the things you mention improve clarity, modularity and maintainability.
Well possibly wrapped accessors, but only when called for.
What i meant was avoid clever-but-stupid shit like displaying
how much crap you can get done with a bodyless for-loop,
deep if-trees that might save you a superflous comparison or
two, but take all day to read correctly and correctly implement
a really simple change in the underlying rule.
If you do database access, data representation, transformations
and file output, please don't do them all all over the place.
You don't need to amake a plugin architecture, but it really
doesn't cost much to design a simple output module API so it might
be switched with a completely different output engine later.
And guess what: it will make your code clearer and better even if
you never make that second output module.
Hell I've seen developers say C/C++ are "dead" and that shiny_language_x is going to take over.
That may be not so much fadism as well-informed wishful thinking.
OK, plain C is not _that_ bad, but you do need to fight its innate spirit in order to implement sane coding practices.
But I recently had to return to C++ on a recent project, and although I was expecting some tedium, it was way worse that I remembered. MY GOD how painful it makes a lot of really trivial things. Even the nasty hack known as PHP starts looking well planned in this light.
It may be better than alernatives if you really need the performance and low-level capabilities, but if you don't (or only a small part of your project does), you're paying a huge price for wizard points you don't need.
Glitzy clicky interfaces do not a good product make, but a platform where _some_ thought has been given to workflow really is something we should start to expect in this day and age.
I would also dispute the idea that the simplicity of newer code is necessarily a good thing. Maybe they are yet to find all the bugs that require inelegant solutions...
That could of course be the case.
But it is a fact that some programmers have slightly too much interest in "clever" tricks, compactness, and optimisations whether they're called for or not, and too little in clarity, modularity and maintainability.
I won't claim this as fact, but I also strongly suspect that this kind of programmer also tends to love perl (you find them everywhere though). Many lose these traits as they mature, get to experience the pain and cost of working other people's unreadable code, and as you get more proficient you simply aren't that impressed by low-level coding skills any more. But some seem incurable.
Am I the only one who fails to read the article?
No.
everyone should be riding the exact same bike
So the winner would be the one who gets the front seat?
How extraverted is honey.bunny77@hotmail.de?
That's a tough one.
I guess what it boils own to is "is executing every motherfucking last one of you and extroverted or introverted thing to do?", and does it matter if you're the 77th one to do it?
It reads "aspergers" loud and clear, dude.
Ayn Rand,
No need to bring on the misanthropic nut jobs, this point (and the need to avoid it) has been recognized for as long as the rest of modern legal thinking.
I'm a chemistry,
Are you, now. I'm a skepticism.
The blocks (allegedly symbolic of wind, water, etc.) looked real (I mean physically existing), but controlled by hydraulics
Jesus Christ, you are so naïve. Can't you see the entire opening was faked? It's just like the moon thing: anyone not totally brainwashed only needs a passing glance at the night sky to tell the moon is 'shopped in. The shadow are all wrong. In fact China does not exist at all.
Nor do you, for that matter; that's just what they want you to believe.
Yeah, and all the porn you watch could be CG as well, but the fact is it is simply easier and cheaper to get people to do it for real.
complete with no gasoline/diesel powered vehicles,
Yeah, well I'm sure that will work out just fine, right up until someone with no common sense figures out he can just "drop no gasoline powered vehicle" for a free ride.
There is rather a lot more to how people behave than "knowledge", and some of them are in deed (as far as we can tell) innate. Good interfaces do play on those things, be it through explicit knowledge of them, trial and failure, or intuition.
In addition comes course all the cultural stuff, and you are right that this is hugely important too.
But if you haven't grasped (explicitly or tacitly) for example some of the basic human limitations in attention, perception, information retention, and processing, chances are you will make horrible interfaces.
Just wait till they discover what kids can get up to with paper and crayons!
That side of things is no different from regular desalination plants, and there are a lot of those.
If it's just a shell full of explosive: hell yeah.
But if it actually works: probably not.
Actually, a thorough round of moist wipes + deodorant to the armpits, while far from equivalent to a shower, will cut quite impressively into your BO unless it's been "maturing" for some time.
If in addition you were squeaky clean and deodorized just an hour ago (and are not the naturally most smelly person. There are big differences), you might be OK. The fresh clothes are still a must, though.
By thermal I meant all electric plants powered by heat (coal, oil, gas, nuclear, geothermal, solar-thermal). They don't use thermoelectric conversion because top-end mechanical conversion is much more efficient, and probably still will be even with this new step in thermoelectric converters.
Waste heat is better used for heating, and in any case don't delver the sort of temperature gradient you need for efficient thermoelectric.
I agree that small-scale stuff is probably nearer in time as a viable application, since small-scale mechanical engines are less efficient (although a good sterling engine is still pretty impressive). Heating remains the best application for small-scale geothermal remains heating, though.
Can you even make a transmitter + power supply that small that would still be powerful enough to communicate with the ground
Yes.
And even if you couldn't:
I'm not really sure what the point of this is
This really ought to get you barred, you know.
I think there is still a loong way to go to compete with modern land-based thermal plants. Even modern ships stretch their diesel impressively far.
But for applications where you can't lug around industrial-scale heavy machinery, all improvements in heat reclamation are welcome, even though it's all in a different ballpark for the foreseeable future.
You can run peltier elements backwards.
The problem is that efficiency is utterly lousy to begin with, and then degrades, so it is only used in very niche applications. If the new material improves even just the lifetime issue, it expands usefulness quite dramatically.
Yeah, blowing up (as opposed to imparting a net impulse) such a rubble-pile-type asteroid with a nuke would slightly disperse it temporarily, after which it would largely reassemble under its own gravity and continue on its old course (center of mass etc..), only now its radioactive as hell...
With a hard and rocky asteroid the nuke might fragment and disperse it effectively enough for the fallout to be worth it, but we better have some more tricks up our sleeve for the other types.
OK, bad wording on my part. But the view I'm opposing, that RDMSs are the be-all end-all of application design and the correct solution to every problem, is equally dumb and actually quite widespread.
The RDBMS concept was a stroke of genius back when, I agree, and it is still a great solution for many things. But it has also become the lazy answer; the proverbial hammer. To the extent that people often sit down and design their tables before even thinking about user requirements. People forget - or even seem incapable of grasping - other models to evaluate. This hinders progress because there are a lot of things that simply don't go well with that kind of structure, but never get a chance because everyone takes the RDBM basis for granted.
Sadly, there are few mature persistence products out there using other models, beacause the market isn't there.
I was talking chiefly about stored procedures, and my issue was not with portability, but that most of the the application need to be shoehorned into how relational databases work, limiting the applicability of other lauded design principles.