I seem to recall a tool called Hypercard. Programs were mostly written in natural language, user interfaces drawn rather than coded, the environment was written in Hypercard, you could develop components and share them without difficulty, script most of your applications, deploy, add features, etc. And all of this was targetted at non-programmers. If I recall correctly, it was a huge success until Apple tried to remarket it.
So, is it time for a new Hypercard ? I'd say yes. Do we want to make it Ajax ? Probably not, or at least non-visibly. JavaScript and XML have terrible syntaxes for non-programmers and way too many pitfalls for everybody's good. But yes, I'd say now would be a good time to reintroduce L4Gs, preferably open-source. Heck, if anyone is willing to start a project on this, please contact me, I'd be interested in joining.
Oh, and just for the sake of design, I'd say that this language/ide would need
an environment easily customizable with itself
dynamic typing, with clear error messages
optional strong static typing, with clear error messages, too, presented as an automatical "check this program" tool
a nearly natural language syntax, both for programs and for data
perhaps several applied syntaxes, with non-lossy conversion from one to the other, say for programming in your native language even if it's not US English -- that's actually much easier to do than it sounds
an extendable syntax -- I don't really know how, perhaps with a beginner-targetted variant of Lisp-style static introspection
optional data structures
no visible compilation process
saving projects under a form which would both contain the executable (if the user "double-clicks" on the package, the program should be executed), the source and resources (if the user opens the package from the ide), and optionally the dependencies
Ajax, yes, but hidden behind a nice beginner-oriented language -- no beginner wants to mess with asynchrony, especially in JavaScript, much less with improperly implemented closures, and no beginner should have to know any of the actual xml details, that's for the computer to handle
a nice semantic model of the language would probably make it easier to develop the "check this program" options, but that might not be a priority
a number of Joe Averages taking part in the design process
Most of the problems you cite are only truly applicable to "C".
I'm afraid that's not true. C++ does provide crutches for C, and can solve a few problems indeed, but in my experience, in the long run, it just fails.
* Macros largely unnecessary with the use of templates
True, in theory. Macros stay largely used in practice.
* C++ is strongly typed (much more than C)
I'm afraid you're confusing "static typing" and "strong typing". C++ is a mix of static weak typing, tiny bits of dynamic typing and big chunks of no typing at all. In other words,
the type system is invalid (i.e. no subject reduction)
just the template type system itself is invalid
the type system doesn't guarantee anything -- constants can change, references can be NULL, a variable of type T can contain a value of unrelated type U, etc.
except for some aspects of virtual methods, no type errors are caught at run-time.
* Character strings unnecessary (object-oriented replacements more generic, more powerful)
Indeed. However, Mozilla has 12 different classes of character strings, Apache Xerces 2 or 3, wxWidgets 4 or 5, and none of them are compatible across project or with the STL. Which was exactly my point.
* GC? Well, it can be done a bit more nicely with some object-oriented techniques and programmer dicipline)
True. Unfortunately, that's quite hard to do, and it grows nigh-impossible when you're trying to mix two different libraries. And, well, come on, unless I'm writing a critical or semi-critical app, I don't want to spend half of my time, if not more, managing memory. If I'm writing a critical or semi-critical app, I won't use C++ in the first place. I'll probably go Ada or Esterel, depending on the task.
* Could be extremely portable, but most people seem to not bother to make their programs that way.
In my experience, it's doomed at low-level, starting with the low-level libraries you will probably need to write your program. Making it portable actually requires fighting against the conventions of these libraries.
I'm not sure what you mean about "extreme verbosity"... Sounds like you're a Perl programmer (;-> :)
I'm a functional programmer. Walking through a tree to collect informations should be something I can write in 5 short lines, including type information. Not in 100 lines (assuming a good library), to obtain unsafe, MT-unsafe and harder to read results.
Also static introspection is possible in C++ using overloading and/or templates... [...]
True. But comparing this to Lisp-style or MetaOCaml-style static introspection makes me want to weep.
In terms of writing complex, high-performance software, I don't see anything replacing C++ (not even Java). But for applications where performance is not an issue, I find the strong typing features of C++ to be an advantage...
I believe it depends on the domain. Given complete choice, for most applications which do not require direct access to the hardware, I would probably use OCaml (if performances matter most) or Haskell (if readability matters most) and now maybe F# (for portability). For distributed applications, I would probably use Mozart. Or my own upcoming language:) For expert systems, I'll use Prolog. For databases, well, either SQL or some embedded SQL (what's the name ? link ?). Etc. In any case, I will choose a language with actual strong typing rather than a false sense of security.
Think of how many web CGI scripts have security flaws because they are passing un-sanitized data from the GET/POST data to SQL queries or the command-line? Well, these flaws could have been prevented at COMPILE TIME, with a strongly typed language, such as C++. (Strings in different domains could have different types, forcing the programmer to run specialized functions for sanitizing one string before using it in a different domain)
I agree
C still has a niche, can't realy change that.
C definitely has a niche. I, for one, vote to let C return to it.
Large parts of the kernel, if not the whole kernel, fall into that niche. I'm less convinced about the network stack. Compilers fall quite far away from it. Graph-based or continuous path-finding, artificial intelligence, concurrent programming, interpreters, webservers, webbrowsers, VoIP applications... all that is getting further and further away from that niche.
But, please, whatever you do, everyone, stop considering C as a general-purpose language. It has been. It is not anymore. It wastes too many precious hours of everyone's life. Which could be better spent trolling on/.
Seriously, if C bothers you that much, don't use it.
Seriously ? If I could avoid using C, I would. But there is a perverse logic by which every "serious" application or library seems to be doomed to be written in C or, in the best case, C++, regardless of the application. Don't take me wrong. C or C++ is probably the best language for low-level, embedded and/or kernel development. But not for writing, say, Mozilla (according to my measurements nearly 2/3 of the native code of Mozilla is actually spent mapping a different paradigm on top of C++), or gcc, or evolution. Frankly, there are better languages for this.
Oh, and I'm not planning to use Ruby for the kernel or for Gcc, mind you. I'm not a specialist of Ruby, but the language looks quite appropriate for user interfaces or dynamic websites. If I had to choose a more modern language for the kernel, I would probably use either D, or OCaml, or a language with explicit continuations or explicit concurrency (Mozart-style). Some use C# and I'm willing to bet that their development will be significantly faster and that the resulting system is not going to be significantly slower.
I tend to assume that, after a few years of life and real-life profiling and optimization, a properly-designed system implemented in a high-level language would end up rather faster than a C kernel: while many low-level optimizations would have to be removed, a number of high-level optimizations can be introduced once you're sure of your code. Removing memory protection, for instance, is quite possible, if the system only executes programs without pointer arithmetics. In turn, this can be checked when the (possibly typed) binary is loaded, rather than at every single memory access. Let's not quabble about the fact that this check is hard-wired in the CPU. It's still a waste of time and energy somewhere and it's not the only one.
Several variants of Fortran have something like this. Other concurrent languages... well, a number of other concurrent languages typically don't need or use for, but most likely offer concurrent/distributed map or fold, which are the common "clean" approximation of for.
take one of the most unsafe, slowest-to-compile, pitfall-ish, unspecified languages in existence (ok, I might be exagerating on the "unspecified" part)
add even more #pragmas and other half-specified annotations which are going to change the result of a program near invisibly
don't provide a debugger
require even more interactions between the programmer and the profiler, just to understand what's going on with his code
add unguaranteed and slow static analysis
...
lots of money ?
Am I the only one (with Unreal's Tim Sweeney) who thinks that now might be the right time to let C die, or at least return to its assembly-language niche ? I mean, C is a language based on technologies of the 50s 60s (yes, I know, the language itself only came around in the late 60s), and it shows. Since then, the world has seen
Lisp, Scheme, Dylan,... -- maximize code reuse and programmer's ability to customize the language, automatic garbage-collection
ML, Ocaml, Haskell,... -- remove all hidden dependencies, give more power to the compiler, make code easier to maintain, check statically for errors
Java, C#, VB, Objective-C... -- remove pitfalls, make programming easier to understand, include a little bit of everything
Python, Ruby, JavaScript -- maximize programming speed, make code readable, make writing prototypes a breeze...
Erlang, JoCaml, Mozart, Acute -- write distributed code (almost) automatically, without hidden dependencies, with code migration
Fortress -- high-performance low-level computing, with distribution
SQL, K, Q -- restrict the field of application, remove most of the errors in existence
and probably plenty of others I can't think of at the moment.
And what are C and C++ programmers stuck with ?
a macro system which was already obsolete when it was invented
slow compilers
no modules or any reasonable manner of modularizing code
neither static guarantees nor dynamic introspection
no static introspection
an unsafe language in which very little can be checked automatically
mostly-untyped programming (not to be confused with dynamically-typed programming)
about a thousand different incompatible manners of doing just about everything, starting with character strings
manual garbage-collection (yes, I know about the Boehm garbage-collector -- but I also know about it's limits, such as threads)
a false sense of safety with respect to portability
extreme verbosity of programs.
So, now, we hear that IBM is trying to maintain C alive, under perfusion. IBM, please stop. Let granddaddy rest in peace. He had his time of glory, but now, he deserves that rest.
Oh, and just for the record. I program in C/C++ quite often as an open-source developer and my field is distributed computing. But I try to keep these subjects as far away from each other as I can.
(well, venting off feels good)
I do, most definitely. When I was coding with/for DOM, not a week passed without me sacrificing a chicken in an attempt to curse whoever invented DOM to hell. Or at least to using it.
Slashdot Mirror
Disclaimer: I'm member of one of these projects.
Oh, and feel free to add other projects as replies to this spam... er, mail.
So, is it time for a new Hypercard ? I'd say yes. Do we want to make it Ajax ? Probably not, or at least non-visibly. JavaScript and XML have terrible syntaxes for non-programmers and way too many pitfalls for everybody's good. But yes, I'd say now would be a good time to reintroduce L4Gs, preferably open-source. Heck, if anyone is willing to start a project on this, please contact me, I'd be interested in joining.
Oh, and just for the sake of design, I'd say that this language/ide would need
Anything else ? Anybody interested ?
I'm wondering, too. How's this something to be voted about ?
Interesting. Do you have any documentation on this ?
I'm afraid that's not true. C++ does provide crutches for C, and can solve a few problems indeed, but in my experience, in the long run, it just fails.
* Macros largely unnecessary with the use of templates
True, in theory. Macros stay largely used in practice.
* C++ is strongly typed (much more than C)
I'm afraid you're confusing "static typing" and "strong typing". C++ is a mix of static weak typing, tiny bits of dynamic typing and big chunks of no typing at all. In other words,
* Character strings unnecessary (object-oriented replacements more generic, more powerful)
:)
Indeed. However, Mozilla has 12 different classes of character strings, Apache Xerces 2 or 3, wxWidgets 4 or 5, and none of them are compatible across project or with the STL. Which was exactly my point.
* GC? Well, it can be done a bit more nicely with some object-oriented techniques and programmer dicipline)
True. Unfortunately, that's quite hard to do, and it grows nigh-impossible when you're trying to mix two different libraries. And, well, come on, unless I'm writing a critical or semi-critical app, I don't want to spend half of my time, if not more, managing memory. If I'm writing a critical or semi-critical app, I won't use C++ in the first place. I'll probably go Ada or Esterel, depending on the task.
* Could be extremely portable, but most people seem to not bother to make their programs that way.
In my experience, it's doomed at low-level, starting with the low-level libraries you will probably need to write your program. Making it portable actually requires fighting against the conventions of these libraries.
I'm not sure what you mean about "extreme verbosity"... Sounds like you're a Perl programmer (;->
I'm a functional programmer. Walking through a tree to collect informations should be something I can write in 5 short lines, including type information. Not in 100 lines (assuming a good library), to obtain unsafe, MT-unsafe and harder to read results.
Also static introspection is possible in C++ using overloading and/or templates... [...] :) For expert systems, I'll use Prolog. For databases, well, either SQL or some embedded SQL (what's the name ? link ?). Etc. In any case, I will choose a language with actual strong typing rather than a false sense of security.
True. But comparing this to Lisp-style or MetaOCaml-style static introspection makes me want to weep.
In terms of writing complex, high-performance software, I don't see anything replacing C++ (not even Java). But for applications where performance is not an issue, I find the strong typing features of C++ to be an advantage...
I believe it depends on the domain. Given complete choice, for most applications which do not require direct access to the hardware, I would probably use OCaml (if performances matter most) or Haskell (if readability matters most) and now maybe F# (for portability). For distributed applications, I would probably use Mozart. Or my own upcoming language
Think of how many web CGI scripts have security flaws because they are passing un-sanitized data from the GET/POST data to SQL queries or the command-line? Well, these flaws could have been prevented at COMPILE TIME, with a strongly typed language, such as C++. (Strings in different domains could have different types, forcing the programmer to run specialized functions for sanitizing one string before using it in a different domain)
I agree
C still has a niche, can't realy change that. /.
C definitely has a niche. I, for one, vote to let C return to it.
Large parts of the kernel, if not the whole kernel, fall into that niche. I'm less convinced about the network stack. Compilers fall quite far away from it. Graph-based or continuous path-finding, artificial intelligence, concurrent programming, interpreters, webservers, webbrowsers, VoIP applications... all that is getting further and further away from that niche.
But, please, whatever you do, everyone, stop considering C as a general-purpose language. It has been. It is not anymore. It wastes too many precious hours of everyone's life. Which could be better spent trolling on
Seriously, if C bothers you that much, don't use it.
Seriously ? If I could avoid using C, I would. But there is a perverse logic by which every "serious" application or library seems to be doomed to be written in C or, in the best case, C++, regardless of the application. Don't take me wrong. C or C++ is probably the best language for low-level, embedded and/or kernel development. But not for writing, say, Mozilla (according to my measurements nearly 2/3 of the native code of Mozilla is actually spent mapping a different paradigm on top of C++), or gcc, or evolution. Frankly, there are better languages for this.
Oh, and I'm not planning to use Ruby for the kernel or for Gcc, mind you. I'm not a specialist of Ruby, but the language looks quite appropriate for user interfaces or dynamic websites. If I had to choose a more modern language for the kernel, I would probably use either D, or OCaml, or a language with explicit continuations or explicit concurrency (Mozart-style). Some use C# and I'm willing to bet that their development will be significantly faster and that the resulting system is not going to be significantly slower.
I tend to assume that, after a few years of life and real-life profiling and optimization, a properly-designed system implemented in a high-level language would end up rather faster than a C kernel: while many low-level optimizations would have to be removed, a number of high-level optimizations can be introduced once you're sure of your code. Removing memory protection, for instance, is quite possible, if the system only executes programs without pointer arithmetics. In turn, this can be checked when the (possibly typed) binary is loaded, rather than at every single memory access. Let's not quabble about the fact that this check is hard-wired in the CPU. It's still a waste of time and energy somewhere and it's not the only one.
Several variants of Fortran have something like this. Other concurrent languages... well, a number of other concurrent languages typically don't need or use for, but most likely offer concurrent/distributed map or fold, which are the common "clean" approximation of for.
Let me summarize
- take one of the most unsafe, slowest-to-compile, pitfall-ish, unspecified languages in existence (ok, I might be exagerating on the "unspecified" part)
- add even more #pragmas and other half-specified annotations which are going to change the result of a program near invisibly
- don't provide a debugger
- require even more interactions between the programmer and the profiler, just to understand what's going on with his code
- add unguaranteed and slow static analysis
- ...
- lots of money ?
Am I the only one (with Unreal's Tim Sweeney) who thinks that now might be the right time to let C die, or at least return to its assembly-language niche ? I mean, C is a language based on technologies of the 50s 60s (yes, I know, the language itself only came around in the late 60s), and it shows. Since then, the world has seenAnd what are C and C++ programmers stuck with ?
So, now, we hear that IBM is trying to maintain C alive, under perfusion. IBM, please stop. Let granddaddy rest in peace. He had his time of glory, but now, he deserves that rest.
Oh, and just for the record. I program in C/C++ quite often as an open-source developer and my field is distributed computing. But I try to keep these subjects as far away from each other as I can.
(well, venting off feels good)
I do, most definitely. When I was coding with/for DOM, not a week passed without me sacrificing a chicken in an attempt to curse whoever invented DOM to hell. Or at least to using it.