"Modern GPU's can do photo-realistic rendering at over 30 fps, and anything more than that is going to be completely wasted."
Yeah, right. A still image can be photorealistic. Photo- doesn't say anything about motion, does it? Ever seen realtime ray-tracing in a game? No, because it can't be done by "modern GPU's". Would it be a "waste"? How about voxel objects built by reaction-diffusion automata? Can the Dreamcast handle that? No?
"If you're serious about a "modeless" interface, it is hard to get less "modal" than a shell command line."
A shell still has the restriction that a command may only appear on the command line and be invoked with a [RETURN]. If the shell is in a window in a GUI, what about all the other text in other lines and other windows, or on the background (if the desktop itself can hold text)? This IS a severe restriction. Why not have commands appear anywhere that text can appear? In other words, why not let any bit of text be invoked at any time as a command, say with a particular mouse-click? There could still be a default output stream or "system log window".
This ultra-modeless GUI does exist, by the way: Oberon.
Yes, this is possible. See the papers written by Michael Franz at
www.ics.uci.edu/~franz/publications.html
He shows that applying compression to the parsed source tree leads to the smaller files than binaries, bytecode, compressed source, or any other known format. This "slim binary" format is compiled as it is loaded from disk. Since disks are very slow compared to processors, the time spent compiling is made up for by the time not spent loading a larger file. System 3 Oberon on various platforms uses these slim binaries.
1.When used as to name the language and not as an adjective, "Latin" should be capitalized.
2. The analogy between a 2000 year old natural language and a 15 year old computer language doesn't make any kind of sense.
3. The real problem with Objective-C is not that it isn't C++ but that like C++ it is an extension of C and is therefore not typesafe and cannot be garbage collected (except "conservatively": conservative GC being a hack which gets around the aliasing problem "statistically").
4. It is not necessary to post responses claiming that C's deficiencies are "necessary" for "efficiency". This is not true.
Good comment, although System 3 does have a window-based GUI as well as the track-viewer interface. Oberon is the bomb. If you are a real programmer and examine Oberon critically you will understand this. If there is anyone who disagrees let him post.
TYPE SAFETY BY ITSELF DOES NOT IMPLY ANY SPEED DISADVANTAGE AT ALL.
A nonoptimizing Oberon-2 compiler produces code that executes at close to the speed of optimized C++. Strong static typing is not slower than weak static typing. Naturally, if one uses dynamic type checks in Oberon there is a cost. But at least one has the option.
It is true that "[t]rying to force everything into a hierarchy - especially into a single-rooted hierarchy - can give truly contorted programs". That is why (considering imperative languages, not functional ones) a language should have both classes and modules. Trying to use classes to do the job of modules is what leads to contortion.
"One could think of a new type of desktop environment . .."
One certainly could. There is one thing wrong with Objective Caml, though: it is written in C, or at least bootstraps through C. While this is good for "interoperability", it is not so good for surveyability. System 3 Oberon is the real thing. Oberon isn't a functional language, but the latest beta of S3 Native Oberon (runs as its own OS on x86) comes with a Scheme module written by Erich Oswald. S3 with the Gadgets desktop is a complete GUI -- a strange one, in that it is completely modeless.
It is fun to install a new OS on its own partition, although you can also run a version on top of Linux -- the Oberon desktop in an X window.
From http://www.oberon.ethz.ch/native/:
"Native Oberon is written in the original Oberon language designed by Niklaus Wirth. The system is an evolution of the operating system co-developed by Niklaus Wirth and Jürg Gutknecht and published in the book Project Oberon: The Design of an Operating System and Compiler, Addison-Wesley, 1992. The system is completely modular and all parts of it are dynamically loaded on-demand. Persistent object and rich text support is built into the kernel. Clickable commands embedded in "tool" texts are used as a transparent, modeless, highly customizable and low-overhead user interface, which minimizes non-visible state information. Mouse "interclicks" enable fast text editing. An efficient multitasking model is supported in a single-process by using short-running commands and cooperative background task handlers. The basic system is small - it fits on one 1.44Mb installation diskette, including the compiler and TCP/IP networking. It is freely downloadable (with source code) for non-commercial use.
An optional GUI component framework called Gadgets is available, with integrated WWW support (FTP, Telnet and HTTP on Ethernet, SLIP or PPP). Many useful applications are available, and the system has been used to build embedded systems. Portable applications can be developed that run on Native Oberon and the other versions of ETH Oberon hosted on other platforms, e.g., Windows, Linux (Intel x86 and PowerPC), Solaris, etc. The LNO version of Native Oberon runs on Linux, but is binary compatible with PC Native Oberon. It was created by replacing a few low-level modules of the system with Linux implementations. "
Slashdot Mirror
"Modern GPU's can do photo-realistic rendering at over 30 fps, and anything more than that is going to be completely wasted."
Yeah, right. A still image can be photorealistic. Photo- doesn't say anything about motion, does it? Ever seen realtime ray-tracing in a game? No, because it can't be done by "modern GPU's". Would it be a "waste"? How about voxel objects built by reaction-diffusion automata? Can the Dreamcast handle that? No?
"If you're serious about a "modeless" interface, it is hard to get less "modal" than a shell command line."
A shell still has the restriction that a command may only appear on the command line and be invoked with a [RETURN]. If the shell is in a window in a GUI, what about all the other text in other lines and other windows, or on the background (if the desktop itself can hold text)? This IS a severe restriction. Why not have commands appear anywhere that text can appear? In other words, why not let any bit of text be invoked at any time as a command, say with a particular mouse-click? There could still be a default output stream or "system log window".
This ultra-modeless GUI does exist, by the way: Oberon.
sr
Yes, this is possible. See the papers written by Michael Franz at
www.ics.uci.edu/~franz/publications.html
He shows that applying compression to the parsed source tree leads to the smaller files than binaries, bytecode, compressed source, or any other known format. This "slim binary" format is compiled as it is loaded from disk. Since disks are very slow compared to processors, the time spent compiling is made up for by the time not spent loading a larger file. System 3 Oberon on various platforms uses these slim binaries.
1.When used as to name the language and not as an adjective, "Latin" should be capitalized.
2. The analogy between a 2000 year old natural language and a 15 year old computer language doesn't make any kind of sense.
3. The real problem with Objective-C is not that it isn't C++ but that like C++ it is an extension of C and is therefore not typesafe and cannot be garbage collected (except "conservatively": conservative GC being a hack which gets around the aliasing problem "statistically").
4. It is not necessary to post responses claiming that C's deficiencies are "necessary" for "efficiency". This is not true.
sr
Good comment, although System 3 does have a window-based GUI as well as the track-viewer interface. Oberon is the bomb. If you are a real programmer and examine Oberon critically you will understand this. If there is anyone who disagrees let him post.
TYPE SAFETY BY ITSELF DOES NOT IMPLY ANY SPEED DISADVANTAGE AT ALL.
A nonoptimizing Oberon-2 compiler produces code that executes at close to the speed of optimized C++. Strong static typing is not slower than weak static typing. Naturally, if one uses dynamic type checks in Oberon there is a cost. But at least one has the option.
sr
It is true that "[t]rying to force everything into a hierarchy - especially into a single-rooted hierarchy - can give truly contorted programs". That is why (considering imperative languages, not functional ones) a language should have both classes and modules. Trying to use classes to do the job of modules is what leads to contortion.
"One could think of a new type of desktop environment . . ."
One certainly could. There is one thing wrong with Objective Caml, though: it is written in C, or at least bootstraps through C. While this is good for "interoperability", it is not so good for surveyability. System 3 Oberon is the real thing. Oberon isn't a functional language, but the latest beta of S3 Native Oberon (runs as its own OS on x86) comes with a Scheme module written by Erich Oswald. S3 with the Gadgets desktop is a complete GUI -- a strange one, in that it is completely modeless.
It is fun to install a new OS on its own partition, although you can also run a version on top of Linux -- the Oberon desktop in an X window.
From http://www.oberon.ethz.ch/native/:
"Native Oberon is written in the original Oberon language designed by Niklaus Wirth. The system is an evolution of the operating system
co-developed by Niklaus Wirth and Jürg Gutknecht and published in the book Project Oberon: The Design of an Operating System and Compiler,
Addison-Wesley, 1992. The system is completely modular and all parts of it are dynamically loaded on-demand. Persistent object and rich text
support is built into the kernel. Clickable commands embedded in "tool" texts are used as a transparent, modeless, highly customizable and
low-overhead user interface, which minimizes non-visible state information. Mouse "interclicks" enable fast text editing. An efficient multitasking
model is supported in a single-process by using short-running commands and cooperative background task handlers. The basic system is small -
it fits on one 1.44Mb installation diskette, including the compiler and TCP/IP networking. It is freely downloadable (with source code) for
non-commercial use.
An optional GUI component framework called Gadgets is available, with integrated WWW support (FTP, Telnet and HTTP on Ethernet, SLIP or
PPP). Many useful applications are available, and the system has been used to build embedded systems. Portable applications can be developed
that run on Native Oberon and the other versions of ETH Oberon hosted on other platforms, e.g., Windows, Linux (Intel x86 and PowerPC),
Solaris, etc. The LNO version of Native Oberon runs on Linux, but is binary compatible with PC Native Oberon. It was created by replacing a few
low-level modules of the system with Linux implementations. "