It's a nice theoretical concept but a real pain in the ass to work with. Sure, Haskell is nice as a compsci masturbation language, but coding real projects in it is a task for lunatics.
I switched from CS to joint CS/Maths (and I might just end up doing applied maths) because CS was becoming less and less computer science and more and more software engineering.
I don't want a tool that tries to tell me how to do things. I want a tool that stays the hell out of my way and lets me do some work. Their "way things should be" is not suitable for all software development models, yet their tool is so closely tied to said model that they actively add in features to try to stop you from working any other way.
I've had two ultrabay optical drives fail on my ThinkPad. Both failed just after the year's warranty expired. One won't play anything at all, the other will play and burn CDs but refuses to read any DVDs (I get repeated DriveSeek errors for DVDs). Very annoying, considering the price.
Why bother? The documentation does not get read. I know this from experience. The only solution is to make it so obvious that there is no need for docs.
Arch (TLA) is still at the "incredibly buggy" stage. It also has some hugely nasty design flaws -- rather then making their software flexible, they try to tell you exactly how you should develop your software, and then they enforce their view of how development should be done by making it incredibly difficult to work any other way.
Subversion, sadly, is unusably slow once you go over a thousand or so files. It ended up being around twelve times slower than CVS (ouch) on tests with a ~120k files repo. Painful, and it's a real shame, since it's a far nicer technology.
Oh, brilliant idea. Force everyone to run arbitrary shell scripts before they can even unpack your package. At least with a tarball you can extract it and check the contents without having to run any untrusted package-supplied code.
Use a multiline input box and don't try to manually split it up into various fields. Let the user do that. Maybe stick with a dropdown box for Country is all.
I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. It's like Ada all over again! The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
Hardly vim-like... It's missing all the useful stuff like f F t T, all text objects and motions and all the modal stuff. These're the things that make vim so much more powerful than anything else.
But then, I guess "using a few simple manipulation commands" doesn't sound as sexy, eh?
Re:I just want C++ programs to COMPILE faster
on
GCC 4.0 Preview
·
· Score: 2, Informative
A lot of it is down to templates. As soon as you use them or STL you're upping the compile by an order of magnitude and gobbling up a hundred megabytes of RAM... With great power comes a cost.
Which is pretty funny, since Gentoo used to beat Debian in openssl benchmarks by over 400% on UltraSparc systems. See, Debian ship sparcv7 binaries, and v7 doesn't do hardware integer multiplication. Gentoo, on the other hand, are quite happy building v9 or UltraSparc binaries, which *do* do hardware integer multiplications, and which also allow you to schedule them straight after each other.
Of course, once the Debian guys realised this, they started shipping v9 binaries for openssl. So now Gentoo is just 400% faster on UltraSparcs for every other maths app.
It's a nice theoretical concept but a real pain in the ass to work with. Sure, Haskell is nice as a compsci masturbation language, but coding real projects in it is a task for lunatics.
I switched from CS to joint CS/Maths (and I might just end up doing applied maths) because CS was becoming less and less computer science and more and more software engineering.
Linux treats all keyboards and mice as a single input source, so you'll need to get patching if you want more than one active user at a time...
I don't want a tool that tries to tell me how to do things. I want a tool that stays the hell out of my way and lets me do some work. Their "way things should be" is not suitable for all software development models, yet their tool is so closely tied to said model that they actively add in features to try to stop you from working any other way.
"I don't like having disks crammed into me... unless they're Oreos, and then only in the mouth."
I've had two ultrabay optical drives fail on my ThinkPad. Both failed just after the year's warranty expired. One won't play anything at all, the other will play and burn CDs but refuses to read any DVDs (I get repeated DriveSeek errors for DVDs). Very annoying, considering the price.
I know that this is true because I read it in the Bible. They did not evolve, they were created by God.
For home it's easy. All you need is a baseball bat. It's when you can't get access to the other users that it starts to get tricky.
I think it's a shame Michael Sims was passed over this time around.
Why bother? The documentation does not get read. I know this from experience. The only solution is to make it so obvious that there is no need for docs.
Simple. Don't publish the exact snapshot date.
Arch (TLA) is still at the "incredibly buggy" stage. It also has some hugely nasty design flaws -- rather then making their software flexible, they try to tell you exactly how you should develop your software, and then they enforce their view of how development should be done by making it incredibly difficult to work any other way.
Subversion, sadly, is unusably slow once you go over a thousand or so files. It ended up being around twelve times slower than CVS (ouch) on tests with a ~120k files repo. Painful, and it's a real shame, since it's a far nicer technology.
LSB is a silly RedHatism. Remember, if you want to be LSB compliant, X11 support is mandatory.
Oh, brilliant idea. Force everyone to run arbitrary shell scripts before they can even unpack your package. At least with a tarball you can extract it and check the contents without having to run any untrusted package-supplied code.
"Avoid modifying published distfiles."
Oh heck yes. The number of times I've been bitten by a few projects (yes mplayer guys, I mean you) doing this and breaking Gentoo's digest system...
How about "french fries like salt"?
LSB is a redhatism. Some parts of it are utterly daft. You know that X is mandatory under LSB, right?
Use a multiline input box and don't try to manually split it up into various fields. Let the user do that. Maybe stick with a dropdown box for Country is all.
Because a lot of us don't like giving money to the crooks who make paying extortion money necessary in the first place.
One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thank you very much).
The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.
Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. It's like Ada all over again! The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.
On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?
I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.
Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD^H^H^H^H Perl is dying.
Hardly vim-like... It's missing all the useful stuff like f F t T, all text objects and motions and all the modal stuff. These're the things that make vim so much more powerful than anything else.
But then, I guess "using a few simple manipulation commands" doesn't sound as sexy, eh?
A lot of it is down to templates. As soon as you use them or STL you're upping the compile by an order of magnitude and gobbling up a hundred megabytes of RAM... With great power comes a cost.
Which is pretty funny, since Gentoo used to beat Debian in openssl benchmarks by over 400% on UltraSparc systems. See, Debian ship sparcv7 binaries, and v7 doesn't do hardware integer multiplication. Gentoo, on the other hand, are quite happy building v9 or UltraSparc binaries, which *do* do hardware integer multiplications, and which also allow you to schedule them straight after each other.
Of course, once the Debian guys realised this, they started shipping v9 binaries for openssl. So now Gentoo is just 400% faster on UltraSparcs for every other maths app.
Indeed. Gentoo supports everything that debian does and more. Well, except for Hurd.