>>>>>> Blowing in the wind, all blowing in the wind. >>>>> 1. A new programming language, accompanied with a new way of teaching >>>>> programming. >>>> That might help a bit. But there are a lot of very important legacy >>>> applications already out there. Like it or not we are tied into the >>>> existing applications codebase. >>>>> 2. A new OS, which uses a nanokernel approach and wastes processors in >>>>> the name of reliability. >>>> Can't fault the idea of keeping the Ring0 protected kernel as small as >>>> possible, or giving users the least privileges needed to do their job. >>>> But wasting performance for reliablity though is never going to fly - >>>> not least because most times it would not have the desired effect.
>>>> Hardware enforced memory protection for threads on a timesliced CPU can >>>> be made every bit as reliable as giving each one a physical CPU just a SMOP. >>>>> 3. Ultimately, a new multicore cpu architecture that exerts much more >>>>> hardware control over the things that programmers tend to screw up. >>>> You mean like enforcing bounds checking on array and pointer access? >>> Pointers have to be the first thing to go. And of course array bounds >>> should be checked, but all that can do is crash a program, which was >>> going to crash sooner or later anyhow. >> Pointers are OK provided you can only trash your own memory space. >> Anything else and you should get squashed flat.
>>> We are programming antique hardware in antique languages. >> Speak for yourself. I program in the language that best fits the problem >> (or is dictated by the clients requirements). Sometimes both. The >> fastest way to develop really tricky algorithms is in a language where >> human errors and typos are mostly caught at compile time. The final >> version is then translated back into C (which is mostly what people seem >> to want). ISTR NAGLIB used this approach a very long time ago (when >> FORTRAN was the main language of choice for scientific computing).
>> I wish that a more robust language had won the language wars, but it is >> too late now to cry over spilt milk.
> So, a hundred years from now, everybody will still be programming in > C++? Writing billion-line programs with millions of bugs?
I didn't say that at all. Hand written code has a worryingly high defect rate of about 0.2% (average) and as high as 5% worst case (IBM OS/360 study). So either you have to make every line do more by improving the languages to match specific application domains or weed out the human errors sooner by more sophisticated static code analysis.
Almost every language from the birth of computing with a significant codebase is still going strong more than half a century later. The languages have evolved a bit and standards committees have haggled over the small print but they still exist. And they are still used.
Cobol, Fortran, Algol, Basic, Lisp all have their roots in the late 1950's.
I fully expect new kids on the block like Java and SQL and the various web markup languages to last at least a similar length of time.
> Something to look forward to.
If I had to bet how software engineering will evolve in the future then I would say that formal specifications will become more common for mission critical work. Z and VDM that we have now are effective, but very few people can read or work with them and manipulate proofs.
Tools to support them and automatically convert the formal spec to a users view of how the interface will look and from that a conversion to functional code. Every path also has to handle changes and allow proof of correctness to be applied back to the specification. There are research projects trying to do this. It is distinctly non-trivial.
And yet again you quietly snip away the embarrassing failure of the Transputer and Occam which followed your proposed massively parallel hardware route though expensively and somewhat ahead of its time.
>Consider this comparison of Microsoft Windows "Recommended >System requirements" (and we all know that Windows really >needs a lot more than the minimum to run fast and well):
>Windows version Processor Memory Hard disk >Windows 95 25 MHz 8 MB 50 MB >Windows 98 66 MHz 24 MB 140–255 MB >Windows Me 150 MHz 32 MB 320 MB >Windows 2000 Server 133 MHz 64 MB 1 GB >Windows XP 300 MHz 128 MB 1.5 GB >Windows Vista 1 GHz 1 GB 15 GB
>Are the new features in Vista really worth 40 times more >cycles, 125 times more ram and 300 times more hard disk? >Is Vista 40 times better? Am I 40 times more productive?
I dunno about Vista, I think much encrypt /decrypt stuff for 'security' eats cycles in it.
>Why should a business have to keep buying new PCs, to >support new bloatware when most of the workers are trying >to complete the same tasks?
True, I use 'joe' (should be on your Slackware system) as text editor, even to write this (it is called from the news reader). In an xterm, now compare that to MS-Word bloat... 'joe' is faster, cheaper (free), better (more efficient).
>Meanwhile, I am running the latest version of Slackware >Linux on a box that has:
>100 Mhz 486 Processor >100 MB RAM >2.1 GB HDD
Ah, have an old 486 in the attic, but it has lost it power supply. hard disk, floppy drive.... But Slackware was very good when it ran on it.
Remember 'Slackware' is one man's work, maybe that is why.
>...and it runs just fine -- in fact it runs faster than some >of the older versions of Slackware Linux do. Yet I installed >that same version of Slackware Linux on a 8-processor Xeon box >with 4GB of RAM and a 1TB RAID array, and it worked great there >as well.
I run grml www.grml.org these days, but modified it so much it is a totally different system, not using the 'live CD', but have it on disk.
The main issue with 'new features' that requires more processor power, is HD video editing and processing, never enough speed. The multimedia PC is what people want, to edit the footage they shoot with their Canon HV20 cameras. The masses need ever more computing power for that, your 486 will not be able to cope.
Martin Brown <|||newspam...@nezumi.demon.co.uk> writes:
> If you don't remember your history you are doomed to repeat the same > mistakes. Do you not remember the Transputer and its lovely little > parallel processing language Occam. Scaled really well but they went > bust - probably because they were manufacturing in the UK.
Since that wikipedia page mentions C, Ada, Fortran and Pascal compilers by Inmos for their transputers, I wonder if there were any lessons learned then that could be used today. But I it looks like those compilers didn't have any automatic parallelization of anything, so I suppose they weren't that different than what threads provide today.
Jan Panteltje <pNaonStpealm...@yahoo.com> writes: > FPGA is the perfect solution here. > So we have then mother boards with on the fly programmable logic as > part of the programs that run on it.
Hmm, I wonder if there are any consumer priced motherboards like that? Some retro computers implemented with FPGAs exist, but they don't exactly have 3 GHz C2Ds as the main CPU... More interesting FPGA boards tend to be a little pricey, like the Xilinx ML-505, which is shaped so that it can fit in an x4 PCIe slot.
>>>But there are a lot of very important legacy applications already >>>out there. Like it or not we are tied into the existing applications >>>codebase.
>> I run all such legacy applications in VMWare virtual machines >> under the OS that they work best under, thus letting me choose >> the best main OS available without regard to backwards compatibility.
> CP/M? > MP/M? > Odin?
Correction: I run all such legacy x86 PC applications in VMWare virtual machines under the x86 PC OS that they work best under, thus letting me choose the best main x86 PC OS available without regard to backwards compatibility.
I prefer to run CP/M applications on my Commodore 128, but emulators are available that allow it to run under a x86 PC OS.
>> FPGA is the perfect solution here. >> So we have then mother boards with on the fly programmable logic as >> part of the programs that run on it.
>Hmm, I wonder if there are any consumer priced motherboards like that? >Some retro computers implemented with FPGAs exist, but they don't >exactly have 3 GHz C2Ds as the main CPU... More interesting FPGA >boards tend to be a little pricey, like the Xilinx ML-505, which is >shaped so that it can fit in an x4 PCIe slot.
Well, 'mass production' will help... A Stratix 4 with 680k logic elements in quantities that we see for PC sales would perhaps be possible. What needs to be invented is a way to interface it to the CPU and rest of the system, in such a way that each program can reserve and use some of those gates at the same time. Lots of IO I'd imagine. Yes PCIe boards exist, I like this picture too: http://www.heise.de/bilder/113681/1/1 It does not have to be just _one_ FPGA (picture is from this link in German: http://www.heise.de/security/Von-Woerterbuechern-und-Regenboegen--/ar... )
There is a whole lot of issues to be solved, clock domains, what not, but at least the FPGA approach should increase speed. It is a proven concept... unlike using n cores on sequential code...
<|||newspam...@nezumi.demon.co.uk> wrote: >John Larkin wrote: >> On Tue, 19 Aug 2008 20:53:38 +0100, Martin Brown >> <|||newspam...@nezumi.demon.co.uk> wrote:
>>> John Larkin wrote: >>>> On Tue, 19 Aug 2008 17:23:58 +0100, Martin Brown >>>> <|||newspam...@nezumi.demon.co.uk> wrote:
>>>>> John Larkin wrote: >>>>>> On Tue, 19 Aug 2008 15:07:51 GMT, Jan Panteltje >>>>>> <pNaonStpealm...@yahoo.com> wrote:
>>>>>>> Blowing in the wind, all blowing in the wind. >>>>>> 1. A new programming language, accompanied with a new way of teaching >>>>>> programming. >>>>> That might help a bit. But there are a lot of very important legacy >>>>> applications already out there. Like it or not we are tied into the >>>>> existing applications codebase. >>>>>> 2. A new OS, which uses a nanokernel approach and wastes processors in >>>>>> the name of reliability. >>>>> Can't fault the idea of keeping the Ring0 protected kernel as small as >>>>> possible, or giving users the least privileges needed to do their job. >>>>> But wasting performance for reliablity though is never going to fly - >>>>> not least because most times it would not have the desired effect.
>>>>> Hardware enforced memory protection for threads on a timesliced CPU can >>>>> be made every bit as reliable as giving each one a physical CPU just a SMOP. >>>>>> 3. Ultimately, a new multicore cpu architecture that exerts much more >>>>>> hardware control over the things that programmers tend to screw up. >>>>> You mean like enforcing bounds checking on array and pointer access? >>>> Pointers have to be the first thing to go. And of course array bounds >>>> should be checked, but all that can do is crash a program, which was >>>> going to crash sooner or later anyhow. >>> Pointers are OK provided you can only trash your own memory space. >>> Anything else and you should get squashed flat.
>>>> We are programming antique hardware in antique languages. >>> Speak for yourself. I program in the language that best fits the problem >>> (or is dictated by the clients requirements). Sometimes both. The >>> fastest way to develop really tricky algorithms is in a language where >>> human errors and typos are mostly caught at compile time. The final >>> version is then translated back into C (which is mostly what people seem >>> to want). ISTR NAGLIB used this approach a very long time ago (when >>> FORTRAN was the main language of choice for scientific computing).
>>> I wish that a more robust language had won the language wars, but it is >>> too late now to cry over spilt milk.
>> So, a hundred years from now, everybody will still be programming in >> C++? Writing billion-line programs with millions of bugs?
>I didn't say that at all. Hand written code has a worryingly high defect >rate of about 0.2% (average) and as high as 5% worst case (IBM OS/360 >study). So either you have to make every line do more by improving the >languages to match specific application domains or weed out the human >errors sooner by more sophisticated static code analysis.
>Almost every language from the birth of computing with a significant >codebase is still going strong more than half a century later. The >languages have evolved a bit and standards committees have haggled over >the small print but they still exist. And they are still used.
>Cobol, Fortran, Algol, Basic, Lisp all have their roots in the late 1950's.
>I fully expect new kids on the block like Java and SQL and the various >web markup languages to last at least a similar length of time.
>> Something to look forward to.
>If I had to bet how software engineering will evolve in the future then >I would say that formal specifications will become more common for >mission critical work. Z and VDM that we have now are effective, but >very few people can read or work with them and manipulate proofs.
>Tools to support them and automatically convert the formal spec to a >users view of how the interface will look and from that a conversion to >functional code. Every path also has to handle changes and allow proof >of correctness to be applied back to the specification. There are >research projects trying to do this. It is distinctly non-trivial.
>And yet again you quietly snip away the embarrassing failure of the >Transputer and Occam which followed your proposed massively parallel >hardware route though expensively and somewhat ahead of its time.
I have not proposed a "massively parallel hardware route". I have observed that most CPU makers are going multicore, and that hundreds of cores, and maybe 1000 threads, will be available soon. And I have speculated on how that might affect OS design and programming. What's remarkable to me is how entrenched the current bloated and broken programming models are in the minds of programmers. Virtually everyone has responded to my speculations by telling me how good things are now, and how things will not change. So much for "design."
As far as failed architectures go, lots of good stuff didn't make it. 68K is mostly gone. PPC ditto, as far as mainstream apps go. VAX and Alpha were wonderful. Modern structured languages used to be the rage. All have been blown away by Intel and Microsoft, x86 and Windows and C, the worst of the litter.
On a sunny day (Wed, 20 Aug 2008 07:53:03 -0700) it happened John Larkin <jjlar...@highNOTlandTHIStechnologyPART.com> wrote in <8bboa45fqqqr2kbvbgct271v2uen83r...@4ax.com>:
>All have been blown away by Intel and Microsoft, x86 and Windows and >C, the worst of the litter.
Not to be so in envy, You can learn C too, it is a beautiful language:
// test.c #include <stdlib.h> #include <stdio.h>
int main(int argc, char **argv) { #define SMART 10 #define c_programmer SMART int he;
for(he = 0; he <= SMART; he++) { if(he == c_programmer) { fprintf(stderr, "\ For he's a jolly good fellow, for he's a jolly good fellow\n\ For he's a jolly good fellow, which nobody can deny\n\ Which nobody can deny, which nobody can deny\n\ For he's a jolly good fellow, which nobody can deny\n"); } }
exit(1);
} /* end function main */
gcc -o test test.c grml: ~ # ./test For he's a jolly good fellow, for he's a jolly good fellow For he's a jolly good fellow, which nobody can deny Which nobody can deny, which nobody can deny For he's a jolly good fellow, which nobody can deny grml: ~ #
In fact C is a step upwards the ladder from your asm. It has many of the features that asm alows, making C especially suited for writing drivers. The pointers are absolutely great for writing high speed code, with some self dicipline you won't make many mistakes with those. Always check in a function for null pointers, and do a graceull exit.
> On Tue, 19 Aug 2008 12:29:35 -0700 (PDT), James Arthur wrote:
> >On Aug 19, 11:41 am, Jim Thompson wrote: > >> On Tue, 19 Aug 2008 11:22:54 -0700, John Larkin wrote:
> >> [snip]
> >> >When later versions of programs are slower and buggier, "the market" > >> >will oblige by not upgrading. We have seen this here a few times - a > >> >new rev is worse than the current one - so we drop support and stick > >> >with the one that works. Or we go to a free equivalent, like PDF > >> >utilities or LT Spice, and dump the bloatware.
<SNIP: The advance of civilization has been built tool upon tool...and Bill Gates breaks ours.>
On a sunny day (Wed, 20 Aug 2008 08:38:48 -0700 (PDT)) it happened James Arthur <dagmargoodb...@yahoo.com> wrote in <aa4586b7-fe50-4a61-88ee-0d511998f...@o40g2000prn.googlegroups.com>:
