There may be things that can be done with regex that couldn't be done with (for example) the "parse" statement in Rexx, but it would be a very small percentage of the examples I've seen.
I don't think you understand the difference between "possible" and "easy". Using regular expressions to parse text is (really!) easy. Writing a 100% CSS 3, XHTML 1.1 and Javascript 1.7 compliant web browser entirely in x86 assembly by hand (on paper) in 24 hours or less is "possible".
Is there a KDE user out there who doesn't change every single panel and menu around first thing?
Yes.
There's only 2 things I change in a default KDE install, one of which is enabling mouse gestures, and the other of which is setting kicker to the smallest size possible (used to be the default).
The truth is only the cheapest computers can be bought without an OS.
Hmm... I just went onto Newegg.com and bought all the parts for a computer, the parts *I* wanted to be used, assembled them, and installed the OS of *my* choice.
Wasn't difficult at all and didn't get stuck with cheap inferior merchandise.
Why don't you try the same for a laptop and let us know how it goes?
And a stripped-down non-existent API is a way to make things simple?
No, quality != quantity, let's compare the C++ STL to the standard Java libraries. The STL is quite succinct, the standard Java libraries are outrageously bloated. Arguably, the standard Java libraries can do more, but god forbid if you ever actually want to use part of it that you're not already familiar with, as there'll be at least half a dozen slightly different ways to do what you want to do, 90% of which are obtuse and half of which are deprecated. In the time you spent searching for something suitable to use in the standard Java libraries, you could have written the same functionality yourself twice, taken a nap, gone grocery shopping and played 36 holes of golf. To add fuel to the fire, because the standard Java libraries are so bloated, it's not even feasible to actually know more than perhaps 5-10% of them, at most. In sharp contrast, the STL can be learned in it's entirety within a few hours.
The STL has the map container, the standard Java libraries have approximately a dozen map implementations, each of which is subtly different, but in ways that don't matter 95% of the time. Of course, for the other 5% of the time when you find out that you've picked the wrong map implementation, %s/Hashtable/HashMap/g will probably break things anyways, despite the fact that they're essentially the same.
The STL has the pair container, the standard Java libraries (as far as I can tell) do not have a pair implementation. How they managed to write approximately a trillion and one standard classes without thinking "Hey, a pair class could be useful!" is beyond me.
The STL has the list container, the standard Java libraries have at least a dozen different lists that can't easily be converted between one another, and classes will randomly only use a small (and inconsistent) subset of these lists.
Why should a programmer have to re-write common routines and data structures for every program?
They shouldn't, they also shouldn't spend more time scouring through documentation than coding.
Anyway, there is one thing I tend to end up doing quite often, and that SQL engines should have been able to optimize, but never seems to manage: pairing every row in a table with the next or previous row. This operation should be O(n), but ends up being O(n), since it's a join... Typical example is a table of timestamps, and you want the deltas between each timestamp and the next (but there are numerous other examples).
Erlang you say? Please elaborate. I daily work on a commercial product that is deeply based on Erlang and would only suggest it to some enemy. Smalltalk is wonderfully, too early in time. Maybe ADA but never did real work with it.
But please no Erlang
Even without having ever used Erlang, I feel no hesitation in saying that Ada is worse.
Windows may not be easy to use, but when you use it, it's only slightly more painful than removing one's own limbs with a rusty spoon... on a good day. Playing a game, for example. Windows, you put disc in, installer runs, you click "next" until your face goes blue, installer tells you that you're missing some other software package that it needs and demands that you install it (of course it can't do this itself) so recursively repeat this process a few times, once you've got everything the installer wants, you click "next" until your face goes blue again, you wait for a really long time while a few files copy, you put the next disc in, you wait for another really long time, you put the next disc in... assuming the installer eventually finishes you now need to check to see if there's any patches for your game (which there probably is) and then find, download, and install those separately, then you need to find the game in the start menu (which for some reason is organized by company name, not by program function), then if you haven't lost interest yet, you play game. Of course, if it's Vista, the game probably won't work anyways. Linux... well, if it's a native game, you install the game with your package manager, then you play it. If you're trying to play a windows game in Wine, you check the AppDB first, and if the rating is good, the experience will probably be better than it would be in Vista.
Ah, but you're missing the point. I agree that the raw sequential read/write speeds of SSD is not substantially different than that of a conventional hard drive, however, the seek time for SSD is way under 1 ms, while conventional hard drives are in the 10 ms range. So, a SSD might be 10% slower to write a 2G file, but it also might be 1000% faster (or more) when reading a couple hundred 1M files. Furthermore, a RAID array (of any type) does not improve seek time, in fact it normally has a small detrimental effect. On the other hand, most any RAID array will help sequential read/write performance.
Also, newer flash drives use transparent write leveling and other similar technologies to greatly extend the life of SSD, to the point where the device wearing out really isn't an issue at all, with expected lifetimes typically surpassing that of a conventional hard drive. Look at any Slashdot story in the last year or two about SSD and you'll see the issue hashed out in excruciating detail.
Well, Ada comes to mind... it has tasks (~= threads) as a primitive along with some interesting inter-thread communication and synchronization. The only problem is that Ada is incredibly awful to actually write anything in, kinda like Java, but more obnoxious (and inconsistent) and with even worse I/O capabilities (string support is basically non-existant, for example). Consider yourself warned.
Several other posters have suggested a functional language like Erlang or OCaml, but I've never actually used those... You could also look at some even more obscure languages like Occam, or special purpose languages like GLSL (which is massively implicitly parallel).
You should check out neural networks. They work based on the "do a bit and pass it along" principle. They're only good, however, for a certain subset of problems.
And as long as systems remain mostly limited by the harddisk, rather than the CPU, adding threads will not help. Even those massively parallel monster applications of tomorrow will just be spending their time waiting to be paged in.
Ah, but you need to consider another major (recent) development, that is, SSD. Prices on SSD are dropping faster than a skydiver without a parachute, and they greatly mitigate the major problem with conventional hard drives (seek time). At the current rate, I won't be surprised if SSD largely replaces conventional hard drives in the next year or two. So, in a year or two, the hard drive probably won't be the bottleneck that it is now, and we'll be better able to feed massively parallel CPUs more efficiently.
Actually, downloading can be done in parallel with Gentoo, the parallel-fetch feature starts a background job to download packages while you're compiling../configure could (fairly easily) be done in parallel as well, but AFAIK it's currently not. make install is primarily I/O bound, and thus wouldn't really benefit from parallelization (although it could be done pretty easily as well). Compiling is definitely not sequential across directories, try make -j5 in pretty much any project with multiple source directories and you'll see.
I'd like to ask a few related questions from a developer's point of view:
1) Is there a programming language that tries to make programming for multiple cores easier?
2) Is programming for parallel cores the same as parallel programming?
3) Is anybody aware of anything in this direction on the C++ front that does not rely on OS APIs?
My T60 has a Lenovo logo on it, right beside the T60 writing on the inside. The lower right corner of the inside and lid still says "IBM ThinkPad" though. As of the T61, "IBM ThinkPad" has been replaced with just "ThinkPad".
Does this make sense? What we're after is not an Ubuntu solution, but if they can figure it out, hey, I'm all for it. I just want better than native resolution on my monitor. And don't tell me native's all I can get ever, as I have used too many LCDs at too many different resolutions per to believe that each LCD will only display one resolution.
You can't get better (or worse) than native resolution on an LCD, it is physically impossible. Lower resolutions can be approximated in a number of ways, but the actual number pixels lit by the LCD does not change.
LCDs display a fixed set of pixels regardless of the image being fed to them. When a non-native image is fed to the LCD, it's up to the LCD to map the virtual pixels in the image to the real pixels on the screen itself. In the case of an image in native resolution, this is trivial, as it is simply a 1-1 mapping. In the case where the resolution of the fed image is less than the native resolution, (assuming the entire screen is to be filled,) each virtual pixel will be mapped to more than one actual pixel (typically some fractional amount, except for a few special cases, like an 800x600 image on a 1600x1200 LCD). As far as displaying a larger resolution than the native resolution on an LCD, it's theoretically possible, but you'd basically just be making everything smaller and less detailed (say goodbye to readable text!).
GIMP opens psd files already. I'm not an artist by any means, nor do I aspire to be one, but I haven't had any problems with it.
Actually, Kuickshow can open psds too, although Kuickshow doesn't support layers and other useful features, but it's quite sufficient if you only need to view psd files and not edit them...
Slashdot Mirror
I actually own that book... it talks about fake regular expressions though (ie, not regex).
I don't think you understand the difference between "possible" and "easy". Using regular expressions to parse text is (really!) easy. Writing a 100% CSS 3, XHTML 1.1 and Javascript 1.7 compliant web browser entirely in x86 assembly by hand (on paper) in 24 hours or less is "possible".
Like any sensible person, I don't install Flash. As for Youtube, youtube-dl works quite well.
Yes.
There's only 2 things I change in a default KDE install, one of which is enabling mouse gestures, and the other of which is setting kicker to the smallest size possible (used to be the default).
You can also get Dells preloaded with Ubuntu (including in Canada, now!), just search their site for "ubuntu": http://www.dell.com/content/topics/segtopic.aspx/linux_3x?c=us&cs=19&l=en&s=dhs
Hmm... I just went onto Newegg.com and bought all the parts for a computer, the parts *I* wanted to be used, assembled them, and installed the OS of *my* choice.
Wasn't difficult at all and didn't get stuck with cheap inferior merchandise.
Why don't you try the same for a laptop and let us know how it goes?
No, quality != quantity, let's compare the C++ STL to the standard Java libraries. The STL is quite succinct, the standard Java libraries are outrageously bloated. Arguably, the standard Java libraries can do more, but god forbid if you ever actually want to use part of it that you're not already familiar with, as there'll be at least half a dozen slightly different ways to do what you want to do, 90% of which are obtuse and half of which are deprecated. In the time you spent searching for something suitable to use in the standard Java libraries, you could have written the same functionality yourself twice, taken a nap, gone grocery shopping and played 36 holes of golf. To add fuel to the fire, because the standard Java libraries are so bloated, it's not even feasible to actually know more than perhaps 5-10% of them, at most. In sharp contrast, the STL can be learned in it's entirety within a few hours.
The STL has the map container, the standard Java libraries have approximately a dozen map implementations, each of which is subtly different, but in ways that don't matter 95% of the time. Of course, for the other 5% of the time when you find out that you've picked the wrong map implementation, %s/Hashtable/HashMap/g will probably break things anyways, despite the fact that they're essentially the same.
The STL has the pair container, the standard Java libraries (as far as I can tell) do not have a pair implementation. How they managed to write approximately a trillion and one standard classes without thinking "Hey, a pair class could be useful!" is beyond me.
The STL has the list container, the standard Java libraries have at least a dozen different lists that can't easily be converted between one another, and classes will randomly only use a small (and inconsistent) subset of these lists.
They shouldn't, they also shouldn't spend more time scouring through documentation than coding.
Yeah, darn.
Erlang you say? Please elaborate. I daily work on a commercial product that is deeply based on Erlang and would only suggest it to some enemy. Smalltalk is wonderfully, too early in time. Maybe ADA but never did real work with it.
But please no Erlang
Even without having ever used Erlang, I feel no hesitation in saying that Ada is worse.
There, fixed that for you.
Well, Emacs is a nice OS and all, but what it really needs is a good text editor.
Ah, but you're missing the point. I agree that the raw sequential read/write speeds of SSD is not substantially different than that of a conventional hard drive, however, the seek time for SSD is way under 1 ms, while conventional hard drives are in the 10 ms range. So, a SSD might be 10% slower to write a 2G file, but it also might be 1000% faster (or more) when reading a couple hundred 1M files. Furthermore, a RAID array (of any type) does not improve seek time, in fact it normally has a small detrimental effect. On the other hand, most any RAID array will help sequential read/write performance.
Also, newer flash drives use transparent write leveling and other similar technologies to greatly extend the life of SSD, to the point where the device wearing out really isn't an issue at all, with expected lifetimes typically surpassing that of a conventional hard drive. Look at any Slashdot story in the last year or two about SSD and you'll see the issue hashed out in excruciating detail.
Well, Ada comes to mind... it has tasks (~= threads) as a primitive along with some interesting inter-thread communication and synchronization. The only problem is that Ada is incredibly awful to actually write anything in, kinda like Java, but more obnoxious (and inconsistent) and with even worse I/O capabilities (string support is basically non-existant, for example). Consider yourself warned.
Several other posters have suggested a functional language like Erlang or OCaml, but I've never actually used those... You could also look at some even more obscure languages like Occam, or special purpose languages like GLSL (which is massively implicitly parallel).
Nonsense, Neural Networks are the wave of the future!
Ah, but you need to consider another major (recent) development, that is, SSD. Prices on SSD are dropping faster than a skydiver without a parachute, and they greatly mitigate the major problem with conventional hard drives (seek time). At the current rate, I won't be surprised if SSD largely replaces conventional hard drives in the next year or two. So, in a year or two, the hard drive probably won't be the bottleneck that it is now, and we'll be better able to feed massively parallel CPUs more efficiently.
Actually, downloading can be done in parallel with Gentoo, the parallel-fetch feature starts a background job to download packages while you're compiling. ./configure could (fairly easily) be done in parallel as well, but AFAIK it's currently not. make install is primarily I/O bound, and thus wouldn't really benefit from parallelization (although it could be done pretty easily as well). Compiling is definitely not sequential across directories, try make -j5 in pretty much any project with multiple source directories and you'll see.
1) Is there a programming language that tries to make programming for multiple cores easier?
2) Is programming for parallel cores the same as parallel programming?
3) Is anybody aware of anything in this direction on the C++ front that does not rely on OS APIs?
1) Yes.
2) Maybe.
3) Yes.
Yes!
No.
C++ isn't Java, try this instead:
std::disclaimer<std::legalese> sig; sig.dump();
You don't use T series ThinkPads then, none of them have Firewire.
My T60 has a Lenovo logo on it, right beside the T60 writing on the inside. The lower right corner of the inside and lid still says "IBM ThinkPad" though. As of the T61, "IBM ThinkPad" has been replaced with just "ThinkPad".
You can't get better (or worse) than native resolution on an LCD, it is physically impossible. Lower resolutions can be approximated in a number of ways, but the actual number pixels lit by the LCD does not change.
LCDs display a fixed set of pixels regardless of the image being fed to them. When a non-native image is fed to the LCD, it's up to the LCD to map the virtual pixels in the image to the real pixels on the screen itself. In the case of an image in native resolution, this is trivial, as it is simply a 1-1 mapping. In the case where the resolution of the fed image is less than the native resolution, (assuming the entire screen is to be filled,) each virtual pixel will be mapped to more than one actual pixel (typically some fractional amount, except for a few special cases, like an 800x600 image on a 1600x1200 LCD). As far as displaying a larger resolution than the native resolution on an LCD, it's theoretically possible, but you'd basically just be making everything smaller and less detailed (say goodbye to readable text!).
You're thinking of the Transputer.
GIMP opens psd files already. I'm not an artist by any means, nor do I aspire to be one, but I haven't had any problems with it.
Actually, Kuickshow can open psds too, although Kuickshow doesn't support layers and other useful features, but it's quite sufficient if you only need to view psd files and not edit them...
You clearly have not hugged your Model M today, they don't have Windows keys. (This response typed from a Model M.)