Slashdot Mirror
C with Safety - Cyclone
Paul Smith writes: "New Scientist is carrying a story about a redesigned version of the programming language C called Cyclone from AT&T labs. "The Cyclone compiler identifies segments of code that could eventually cause such problems using a "type-checking engine". This does not just look for specific strings of code, but analyses the code's purpose and singles out conflicts known to be potentially dangerous.""
Yet another language...
AT&T has solved the traveling salesman problem by translating it into an input their program understands...
wasn't this supposed to be an NP-Complete problem?
I read the internet for the articles.
Not a flame, but more "modern" languages such as Java and C# have constructs explicitly built to avoid the buffer overflow/pointer gone insane problems.
For the rest of the world, secure C programing is far from a secret.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
I have an idea, let's call it C#.
Amazing magic tricks
one of the main things i use C for is when i want to be unsafe. C lets you fuck with the system in completely arbitrary ways. i program in C because i'm smarter than the compiler, so i want it to let me do whatever i want, and assume i know what i'm doing. when you need to write code that needs to be safe, and you want the compiler to double check everything you do, use java or ML or something...
This is a self-referential sig
buggy code to tell me when my code is buggy.
She sat at the window watching the evening invade the avenue.
C is *supposed* to be dangerous, damnit.
It seems to me that much of what this does could be easily implemented in a C library directly or with #define'd replacements of the C library functions in question. The type issues seem to be all that is unique here.
- Michael T. Babcock (Yes, I blog)
We had C, then C++, then C#. So shouldn't the next logical step be C followed by three vertical lines and three horizontal lines (that'd be C-tic-tac-toe)?
On a lighter note, prehaps they should just come out with a piece of hardware that will reach out and slap you if you make a stupid mistake.
And isn't a cyclone an infinite loop? You have to like a scientist who uses the word humongous.
Someone created a language the enforces types and does bounds checking! It's news!
(right on the web page detailing the language)
Quite trivial, mind you, but wouldn't it be confused with this Cyclone?
In Soviet Russia, Jesus asks: "What Would You Do?"
I'm a professional software developer, and all for anything that makes my code safer without unduly compromising it. But I can't help thinking that starting from C is probably a mistake.
C is a fundamentally unsafe language. It has some easy fixes (remove the always-unsafe gets() function from the library, for example). It has some fundamental "flaws" (pointer arithmetic and the use of void*, for example). I quoted "flaws" because, while these features make the language necessarily unsafe, they are also very helpful in the low-level programming that got C to where it is today.
The underlying problem here has never been with C, it's been with using C for the wrong jobs. Application code, and certainly high-level code where security is essential, just aren't C's strong suits. I can't see how even the geniuses we're talking about can start from such a broken language (in the context we're discussing) and successfully make a non-broken language out of it.
I would expect a much better solution to be that followed by later C-like languages. C++ retains the low-level control, but other languages (Java, C#, etc) are available to those willing to sacrifice some of that control in exchange for added safety, and consequently may be better tools for different types of project. The biggest problem at the moment is that none of these "safer" languages has yet developed the same raw expressive power of C++. As they evolve, and catch up on the 20-odd year head start, hopefully we'll see programmers given a genuine choice between "safe but somewhat limited" and "somewhat safe but unlimited".
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I have been beta testing the cyclone development environment for some time now. For mature cyclone development, the amount of code output generated is equal to that being dissipated due to bug tracking. The dissipation rate per unit area is code density times the lag coefficient times the CPU speed cubed (See Emanuel 1999 for details). One could either integrate a typical code profile over a range of radii from the projects center to the outer radius encompassing the core, or assume an average CPU speed for the inner core of the system. Doing the latter and using 40 m/s (90 mph) coding on a scale of radius 60 km (40 n.mi.), one gets a code dissipation rate (bug generation rate) of 1.5 x 1012 Watts. This is equivalent to about half the world-wide script generating capacity - also an amazing amount of bugs being produced!
Either method is an enormous amount of overhead being generated by Cyclone. However, one can see that the amount of lines of code released in a release (by creating overflows) that actually goes to maintaining the Cyclone System spiraling bugs is a huge ratio of 400 to 1.
Stick with C++ I think.
...is getting cheap pussy in all the cities he visits.
The Cyclone compiler will rewrite the code or suggest fixes to avoid potential bugs
I don't mind suggestions, but I'm not sure I like the idea of having my code rewritten.
Couldn't the same error-checking be incorporated into a pre-processor rather than developing an entirely new compiler/language?
this is quite possibly the funniest thing i've seen all day! it's so true, i never came up with names for any of this phenomena, but i think it has all happened here at work!
Am I the only one to whom this sounds like potentially a really bad idea? I mean, think about it, coding along one day:
#include
int main() {
printf("He
At this point, small, cute cartoon versions of Kernighan and Ritchie pop onto the screen and say "It looks like you're writing a Hello World program! Click here to check this program for bugs automatically..."
I'm just shuddering at the thought...
It can be done in C, if necessary:
if (!infile) { perror("input file"); exit(1); }
The advantage of C is that you are allowed to not use it, if you think it's not recommended in that case.
Why didn't they name it d?
IF you know where I can get
a taste of cmdr TACO's device,
then by all means tell me.
I'm sorry, Dave, I can't compile that.
I know it's cliche, but really, do we expect it to be as smart as another competent programmer reviewing code?
A lot of the static checking made possible by Cyclone can be done for ordinary C with lclint, which lets you add annotations to C source code to express things like 'this pointer may not be null', 'this is the only pointer to the object' and so on. You write these assertions as special comments, for example /*@notnull@*/. These are checked by lclint but (of course) ignored by a C compiler so you compile as normal.
(If you weaken the checking done, lclint can also act as a traditional 'lint' program.)
Also C++ provides a lot of the Cyclone features, not all of them, but it certainly has a stronger type system than C. I'd like to see something which combines all three: an lclint-type program that lets you annotate C++ code to provide the extra checks that Cyclone (and lclint) have over C++.
-- Ed Avis ed@membled.com
The interesting thing here is that Cyclone may be able to solve C++ wrapper problems. This is not a new problem in the C/C++ world.
When programmers started using C++ to enhance systems written in C, they needed some way to allow C functions (functions that had no knowledge of C++ calling conventions) to call the methods of C++ objects. They wrote wrapper functions to do this. A wrapper functions is a C function that is compiled as if it were a C++ function. Because the wrapper is compiled as a C++ function, it understands the C++ calling conventions. Since it is a C function, other C functions can call it. Anytime a non-wrapper C function needs to call a C++ class method, it calls the wrapper function and requests the wrapper to make the call for it.
Cyclone allows you to permiate your code with wrapperless sub functions which demand redundancy. You can't ask for better than thay when dealing with wrappers!
You're Just Jealous Because The Voices Are Talking To Me.
Other than "new" and "improved" sell products better than "useful".
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I always let out a bit of a grumble when a new programming language comes out; they seldom add anything truly new to programming. When I read that Cyclone was strikingly similar to C, I was intrigued enough to skim through the docs.
Put bluntly, Cyclone seems to be little more than C for lazy programmers. Fat pointers for those who can't follow the logic of pointer arithmetic and *`H for those intimidated by malloc() is not a beneficial service.
UNIX *is* user-friendly. Its just more selective on who its friends are. --Scott Adams
I wish it could figure out my code base here, at least them someone would know WTF is up with this mess.
I'm a professional software developer, and all for anything that makes my code safer without unduly compromising it. But I can't help thinking that not starting from C is probably a mistake.
C is a fundamentally safe language. It has some easy fixes (remove the always-unsafe gets() function from the library, for example). It has some fundamental "bonuses" (pointer arithmetic and the use of void*, for example). I quoted "bonuses" because, while these features make the language necessarily safe, they are also very helpful in the low-level programming that got C to where it is today.
The underlying problem here has never been with C, it's been with using C for the wrong jobs. Application code, and certainly high-level code where security is essential, are C's strong suits. I can see how even the geniuses we're talking about can start from such a great language (in the context we're discussing) and successfully make a broken language out of it.
I would not expect a much better solution to be that followed by later C-like languages. C++ retains the low-level control, but other languages (Java, C#, etc) are available to those willing to sacrifice some of that control in exchange for added safety, and consequently may be better tools for different types of project. The biggest problem at the moment is that none of these "safer" languages has yet developed the same raw expressive power of C++. As they evolve, and catch up on the 20-odd year head start, hopefully we'll see programmers given a genuine choice between "safe but somewhat limited" and "somewhat safe but unlimited".
Seems to me PC-LINT gives you the same contextual checking... but I could be mistaken.
you're not up-to-date on some bullets
the 1.4 jdk (currently in beta) has pattern matching
parametric polymorphism (iow - templates) are in development and being called generics
The One Rule Of Chess You'll Ever Need: Don't play someone who carries a kit in their bookbag.
This sounds like an enhancement on C++ and Lint atop C, so why not "clint++". (I really am kidding...don't flame). As long as the unsafe "C" is around, many will be happy (so that we can play with the system). Otherwise, significant/robust applications should use these features to strive to be non-Microsoftian (i.e. buggy).
Perhaps Cyclone will be open. Can they at least allow for add-on modules so that we can increase the rules that it follows?
I'd like to see Cyclone's kind of safety, but if you're going to require garbage collection and forbid pointer arithmetic, you may as well use Java.
I've proposed "Strict Mode" for C++, a compatible retrofit to C++ that uses reference counts like Perl, but with some optimizations to get the overhead down.
A basic decision is whether to have garbage collection. If you have garbage collection, C++ destructors don't fit well. (Java finalizers, called late, during garbage collection, can't be used for things like closing files and windows. Microsoft's C' has destructors, but the semantics are confusing and ugly, and we don't have much mileage yet on how well that will work.)
Reference counts work reasonably well. There's a problem with not releasing circular structures, but that doesn't keep Perl from being useful. Perl now has "weak" pointers (they won't keep something around, and turn to null when their target goes away), and if you use weak pointers for back pointers, most of the circularity problem goes away. True rings of peer objects are rare, and they're the main case where weak pointers won't solve the problem.
If you don't have garbage collection or reference counts, programs obsess on who owns what. A basic problem of C and C++ is that it's essential to track who owns which objects and when they're supposed to be released, yet the language offers no help whatsoever in doing so. This is the fundamental cause of most crashes in C and C++ programs. Almost every core dump, "bus error", or "general protection fault" comes from that problem. So it's worth fixing.
It's the right time to address this. We're in a period of consolidation, now that the dot-com boom has collapsed. Our task as programmers over the next few years is to make all the stuff that sort of works now work 100%.
When I take a dump at work, I go to the Marketing bathroom.
Let them smell my shit, it serves them good!
I've already identified, singled out and deleted code known to be potentially dangerous and installed Linux instead.
try { do() || do_not(); } catch (JediException err) { yoda(err); }
This could save a whole lot of time if it worked correctly... I spend more time tracking down stupid errors Ive made compared to that of tracking down missing semi-colins; 8-) -- FearLinux.com
--
FearLinux.com
Compiling...
test.c
C:\stuff\test.c(3) : 'int main(void) {' : Error 0. Program is in C. This section of code could cause problems.
---
http://slashdot.org/moderation.shtml
Then I got chewing on it and realized something: when I came on board and suggested running lint on our code, I was shot down by both the rank & file and by management (who each blamed the other). When I suggested a concerted effort to rewrite our code to eliminate or justify (in comments) every warning our compiler spewed on a build, I got a similar reaction.
Don't get me wrong. I think cyclone still sounds great, especially the pattern matching and polymorphism indicated on its home site. If it can gain some momentum, it stands to have a real place (niche?) in dealing with legacy systems. For my shop, though, I fear much of the value would be wasted. Until we change our motto from "There's never time to do it right, but always time to do it over" we're going to continue repeating our mistakes.
"Prepare for the worst - hope for the best."
lint - is name of it. And it was made 20 years ago.
p.
This sounds even more annoying than lint. :-)
(I'm not associated with this at all, but I read about it in Game Developer once, and it's really interesting.) @ Gimpel software.
I generally don't like internal type-checking within a language, because it results in slowness, and some los of power. (Sometimes there are times you want to do things that you normally shouldn't be doing, in order to speed up routines.) A language which prevents "bad programming practice" ends up screwing itself over. However, having an external source-code checking utility that tests for bad programming, while still allowing complete power would be much more useful, to me, at least....
Plus, it works. Kewl, actually. It's not Java or C# by any stretch of the imagination, but it does boost productivity quite a lot, and it's not a speed hog, either.
I think we're going to see more of this in the future -- semi-low level languages such as C/C++ with some sort of extensions or "plug-ins" that not only encapsulate a lot of functionality but also save us from our own mistakes. Think of STL with a GC'ed memory space.
I would tend to say loading up the whole of .NET is a bit much just to keep me from reading three bytes outside of a memory buffer but it's an interesting idea nonetheless. How far can this go on before we start complaining about someone turning C++ into a scripting language...? Hmmm.
Maybe Raster can use it to code E 17...after all e16 was a buggy
I heard those groans of disgust!
:-)
Seriously, modern Pascal compilers like Delphi/Kylix are capable of some compile-time checking...Pascal already has strict var type checking, and all you have to do is make sure its turned on when you compile.
This also includes bounds checking for arrays. Pointers are handled better than most C compilers, too.
The key difference here is that it sounds as if Cyclone checks the code for *intent* rather than just checking the types and such. That IS a hard problem.
My journal has hot
Cannot cast what I want? Oh, I feel cast-rated!!
Another potential way to crash a program or violate security is to dereference a dangling pointer---a pointer to storage that has been deallocated. These are particularly insidious bugs because the error might not manifest itself immediately.The way that Cyclone fixes this is by assigning each object a symbolic region that corresponds to the lexical block in which the object is declared, and each pointer type reflects the region into which a pointer points.
Support Texas Troops use TXGoogle
Well, that's not too difficult. Compilers are just a bunch of algorythms.
Question is - are you smarter than the person that wrote the compiler?
Microsoft Word's grammar check has suggested to me in the past that "do it for the greater good" should probably be "do it for the greater well ".
It's sometimes helpful in helping my catch my grammar mistakes. But more often than not, it's a PITA, and the act of wading through its incorrect suggestions is more work than I think it's worth. And that's when it's SO easy to figure out if the suggestion is right or wrong...the sentence is on the screen, standing alone, and I can instantly decide if it's right or not.
Now, imagine wading through a bunch of suggestions and warnings on your code. Imagine having to figure out the context for the flagged code segnments, and having to review the code and all code which references it to see if it's correct or not.
Sure, if you've got free time or resources to throw at it, using computer heuristics to attempt to help out humans is nice. But you have to realize that at this stage in the game, it often takes a lot of work to vet those results in order to glean any gain.
...if only they could do this with the current C code!
"Hello, as an experienced MCSE"
...good programs...good interfaces, truth. Obviously users do care about source-code.
uhhh... minesweeper certified solitaire expert...
"1) Remove the bloat. Most linux distro?s ship with way to many useless programs. Desktop users do not need 10 different text editors. Give them one or two good ones and that will be enough."
Truth.
"2) Dump the command line. Desktop users do not use command lines. Windows is light-years ahead in this regard. Even their server OS has a great gui, and it is not necessary to use the command line. Linux needs to follow Microsoft?s lead and get rid of the command line. You could maybe include an option for advanced users, like how windowsXP has an ms-dos prompt, if you really want to use it."
I thought the idea of Linux was to not follow Microsoft's lead. Great gui?? Please define great. The MS-DOS prompt is fairly neutered, and has been for some time. Make up your mind, gui or not.
"3) Dump open-source. Normal desktop users do not care about source code, they care about good programs. They do not want to compile anything. Linux needs real companies that actually know how to make good interfaces. Right now they are few and far between."
"4) A universal gui system. Linux needs ONE gui. Perhaps people should focus on developing KDE into a competitive platform. Forget about gnome and everything else."
Why? KDE and Gnome and all the others are fairly distinct, giving different types of users different types of gui's. *gasp*
"5) Make upgrading the software easier. Desktop users need an easy way to upgrade the kernel."
Have you used a recently released distro lately? This is one of the concerns being addressed (ie Red Hat, Debian, Mandrake etc.).
"6) Get a good web browser. Linux has no good web browsers right now. Netscape is old and bloated. Opera cost extra and lacks some features. Mozilla is still beta and isn?t even up to version 1.0 yet, so it doesn?t count. Linux needs a browser that is competitive with IE, and right now IE is light-years ahead of anything for linux."
What happens in 6 months when there are numerous browsers available that are better than IE? Of course "better" is a rather ambiguous term...
"7) Proper office programs. If you want Linux to be used in offices, you need decent applications. These programs should be able to import all MS formats, past and present. Microsoft is still light years ahead when it comes to their office programs. "
MS Office can't open older Office formatted documents properly either. Are K-Office and/or Star Office so horrible?
"8) Backward compatibility. WindowsXP can run dos programs, windows 3.11 programs, windows9x programs, windowsNT programs, ect? Linux is barely backward compatible."
Not true! The NT/2000 kernel is different than the 9x kernel, and alot of the older programs don't work on the "other" kernel.
"Right now I would recommend windowsXP for any sensible desktop user."
Right now, I would stick with something that is known to be stable, like Windows 2000 Professional. If I was not using Linux that is...
Actaully the word was coined/invented by Lewis Caroll (of Alice in Wonderland fame). Lewis Carol, of course being a pen name for Charles Lutwidge Dodgson. Chuck was, as you may know, a bit of a mathematician and published many works on the subject - usually text & guides. In short, "a scientist who uses the word humongous" may not be as rare as you think :)
"Sanity is not statistical", George Orwell, "1984"
What a rubbish troll. It is neither funny or clever, and thus it's blantant vulgarity tarnishes it with the "stupid brush". And learn to spell - bad spelling gives an air of incompetence and reduces chances of people taking your (seemingly inferior) intellect seriously.
I have not been saved through your website. I however have been saved on my own at my church. I spent 21 years living the ways of the world, the ways of satan. I'm not proud of this, but I committed almost every sin known to man (except murder and rape and incest and reading slashdot). I lied, cheated, stole, condemned, cursed, even cursed God, I had so much hatred in me I even scared myself, I even hated myself. I was for myself and nobody else, drank, took drugs, thought the whole world owed me something. But in November 2001 my whole world crashed around me, I almost lost my wife, kids, lively hood due to my ignorance. I went to God in prayer in front of family and friends, and accepted the Lord as my own personal savior, I gave my life to him. I left him in my heart and soul. My life has changed greatly from this, its still not "peaches and cream", but things are so much better. God never promised uncloudy days in our lives, but he makes it much, much easier when times are troubled because when we accept him and turn our lives over to him he stands and walks with us every step of the way. And I know he's with me, I know it!!! And I'm PROUD of it, and feel much better. My life has changed, and its for the better. I found your website by accident actually, and it has been a great inspiration to me. I am not a man of means (not much money) and cannot send a donation right now, but I've touched the hand of God and I know he will make it possible for me to do things like that soon. In the mean time, keep up the great website, May God Bless and the farts stay silenced!!
get safety from the vm like java does. that way you don't have to re-write all your code. even java still has null pointer exceptions at runtime and it is regarded as very safe.
i'd say more but i cut my right hand today and typing sucks.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Damn, I used "it's" rather than "its". DAMN IT.
I tried it out on my software packages... and -I does not seem to be totally working. Or is it just me?
a) Computers would increase in speed, to the tune of 2^(year-1984) MIPS. [That would put us at 131,072 MIPS today, and 262,144 MIPS in a few months.]
b) He predicted the rise of a safe system programming language he called C+++=-- (pronounced "see plus plus, plus equals, minus minus), which is a safe subset of a C++ superset.
Java hadn't been invented yet, but Gosling (who was busy inventing NeWS at the time) wrote Oak aka Java several years later, and it fit the description to a tee, but just had a different name or two.
[I'll never forgive Bill Joy for writing VI and CSH. Ewwww icky yucko!]
-Don
Take a look and feel free: http://www.PieMenu.com
These tips might give you a good start as you conduct your own research, reflection and dialogue about how Cyclone can beat BASIC. There are many other approaches, based on the organization, regulatory or collective researching requirements, and programmer perceptions. Often, the coders that channel information (including recognition) to managers also need the same exhibited by their leaders/managers, so there isn't a quick fix; a systemic approach is most effective in the long-term. But if you begin with the simple "thank you" messages, particularly if you've not been doing it regularly already, you'll be making an improvement and off to a positive start.
Oh man, it hurts to read sometimes...
I guess that means csh is just cat and echo with syntactic syrup of ipicac.
And vi is just insert and delete with semantic anthrax.
-Don
Take a look and feel free: http://www.PieMenu.com
Java is great for applications, but you'd never want to start writing device drivers or a virtual memory system in Java. For that you need c, which is basically just a step up from assembly language. Still, people make mistakes, and this will help them.
Of course, if you're still writing applications in c, you're just asking for it. Cyclone might help, but you probably have other issues anyway.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
There is a whole host of languages more "modern" than C, Java, C++, C#, Pascal, Ada, Perl, or any other of the essentially von Neumann-style languages out there. I highly recommend that anyone out there who is interested in advanced type-safe languages take a look at SML, O'Caml, Haskell or Clean. Most of these languages have more or less formalized language semantics (as in mathematically precise). Formal descriptions and strong type systems allow the compiler to *prove* (again, in a mathematically precise sense) that a program can not go wrong at run time.
Benjamin
is the ability to write "unsafe" code. There are plenty of bondage and discipline languages out there if you need that kind of thing.
This goes in the same incomprehensible category of pointless inventions as decaffinated coffee and N/A beer.
What's next, object bash?
Hi,
In 1999, the Ariane 5 launcher exploded a few seconds after leaving the ground. The faulty program, written in type-safe Ada, has been submited to a static program analyzer developped by Alain Deutsch at INRIA in France. The analyzer spotted the error right away!
It was a number going out of range after too many iterations and wrapping back to 0.
The verification technique used was based on abstract interpretation.
This is just to say that even a strongly type-checked language can fail and that type checks, whether static or dynamic, are not the only way to catch bugs.
Alain Deutsch has started a company called Polyspace that sells static verifiers for Ada and C (See www.polyspace.com). The idea is not to rewrite C or Ada but to spot potential bugs inside programs.
I have no special interest in this company, (I know Alain Deutsch), but I mean that improving C does not imply removing the type-unsafe onstructs.
What about function pointers? What "region" do they live in? Say I create a struct with a bunch of function pointers (dur, to emulate OO), and the struct goes out of scope, what about the functions? I guess my question is, are all functions in global scope?
It's 10 PM. Do you know if you're un-American?
Microsoft?
The workhorse C programming language must remain robust and "close to the iron" in preparation for its role in Public Domain Artificial Intelligence.
A special Mind-to-C liaison page has been updated to direct your attention to Open Source AI-in-C projects on SourceForge.
The bulletproof nature of C makes it a major avenue towards Technological Singularity.
You seem to have assumed, for the purpose of the above exposition, that implementation languages are chosen by well-informed people, and substantially on the basis of technical merit. That's not always the case. Well, outside your shop in any case. ;-)
In my opinion, acceptably safe languages that are quite expressive do already exist. I do not believe that the alleged deficiencies of safe languages explains the continued use of "unsafe" languages in domains for which the latter are not a good fit; I believe that, on the average, ill-conceived implementation strategies are more likely at fault. How many projects struggle with inadequate languages as a result of misinformed (or even uninformed) managers' inconsiderate (and uncontestable) decrees? Too many. :-(
I am happy to learn that smart people are busy inventing the next great programming language, but I think that, collectively, we need to spend less time improving our tools and more time addressing the organizational deficiencies that result in our having to use the wrong tools when we know better.
why are you here then??
If I can't write things like:
;
( * ( void ( * ) ( ) ) 0 ) ( )
Then I don't want C anymore.
C is not for dummies.
Where do you work? I want to short your stock.
I am not sure of the usefulness of this particular language/compiler/etc, but I like the direction they are going. DWIM(Do What I Mean) programming is becoming more and more possible, with this kind of language research. We want programmers to solve problems in the macro world, not be bothered with the minutia of the language they are using. This has been one of the appeals of perl over the years.
YHBT, HAND.
This guy's a troll. He's dissing C because it punishes people who don't know what they're doing. (Unlike other languages we won't mention, which reward people for not knowing what they're doing.)
"Hardly used" will not fetch you a better price for your brain.
I think you must have had bad experiences with safe languages (Java?). Static checking doesn't result in slowness (in fact, it can make compiled code faster in many cases, for instance by enabling alias analysis).
Static typing and safety also allow for *more* power than a "do anything you like" language. One kind of power I get when I write in a language like this is the ability to enforce invariants without runtime checks. So if I am writing a program with several other people (or by myself across several evenings, except I am drunk some of those evenings), I can arrange my code such that bugs in one part of the program can NEVER affect other parts of the program. Thus, it is easier to figure out who to blame and where the bug is. This is impossible in a language like C, where any code can write over another module's memory, free its data structures more than once, or cast, etc.
Speeding up routines with hacks is pretty overrated; there are very few places where this is necessary, and even fewer where it is desirable. In those cases, we can always fall back to C or assembly.
# is enough for tic-tac-toe, and is probably what's usually used... I used it... but what do I know?
The coolest voice ever.
You have successfully Trolled, as evidenced by the response from BigBir3d. Did you write that yourself? If so, bravo, it's a well-crafted and effective Troll.
Canada #2 The greatest imitation of the USA in the world
Microsoft is working on a programming language called Vault that is very similar. They'll probably be using it in a future operating system to ensure that key parts of the OS, as well as first and third party drivers, behave well. If they do this, I sure hope that linux jumps on some automated technology too, because then I think they will have quite a leg up on us as far as security and stability go.
I think your second paragraph is totally bullshit. If it's not hard, why do some of the most well known linux network daemons have multiple remote buffer overflows in them? Do the people who wrote BIND, wu_ftpd, xinetd, apache, telnetd, Quake 3, Half-Life, etc. not know what they're doing? No, they know what they're doing, it's just very hard to manually secure large C programs.
The simple fact is that C encourages a style of programming that leads to these kinds of bugs. This has been a solved problem in many other languages for dozens of years now. Using a safe language, for instance, makes you totally immune to buffer overflows and format string attacks, the two most common sources of security holes in unix.
I don't imagine that the primary use of this is
going to be to create new programs. This compiler
can be used to compile old legacy C code (and
there is a lot of that around) to correct bugs
in already existing programs.
A mascot. It needs a little animated tornado, maybe named Cyclonius, to pop up and interact with the user.
"You appear to be coding with Visual Studio. Please stop!"
--
"Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
We need to apply some of the innovations that have been built for everyone else, such as text with attributes, letting the compiler keep track of certain details, etc. Why do I have to track down every instance of a variable if I decide to change it's name? Why can't I simply change the value in the symbol table, and have the compiler spit it out with that new name when it saves it?
Why not integrate the compiler, editor, runtime, all into an effecient kernel of an environment, similar to FORTH, but with the added benefits of type checking?
It's been a long time, yet nothing has changed... what a waste.
--Mike--
Clearly what's needed is a new version of English that doesn't permit grammatical errors.
Sounds good -- do you have any links to docs on Java pattern matching? I can't find anything on sun's site.
Comment removed based on user account deletion
Bwahahahahahaha!
All your souls are belong to Satan.
REGULAR EXPRESSIONS ARE NOT PATTERN MATCHING (in this context)
Please read what pattern matching means when Safe-C (and ML and Prolog and Erlang and...) says "pattern matching" before you post your irrelevant link anymore.
haha... oh.
Regular Expression matching is not the kind of pattern matching they mean here. Check out the language docs or a language like ML that has datatypes and pattern matching to see what they mean.
thats a joke right?? I seriously hope that is a joke.
If that was a joke, its one of the best trolls I have ever seen(natalie portman nude petrified non-distributable open source is getting kinda old).
If it was serious, you really need to do you research before you post. MCSE certifies you as an idiot with an ego. an MCSE makes sure you know how to wipe your ass without calling techsupport but not much else.
I wish i could point at you and laugh and laugh and laugh... and think to myself in a self satisfied way- thats not how **WE** do it!
The recounts showed Gore won in most scenarios.
THe media just didn't report it, no doubt because
to reveal GWB stole the election by the mass
disenfranchisment of black voters would have
rather undercut his claim to be defending
democracy against terrorism.
We're in a period of consolidation, now that the dot-com boom has collapsed. Our task as programmers over the next few years is to make all the stuff that sort of works now work 100%.
Are we? I think we could be, and should be, but thanks to a lot of folks' insistence upon reinventing the wheel, we aren't going to be in the forseeable future. Every month there's a new language that offers miniscule advantages over existing languages (i.e., Ruby, the "two thirds Perl, one third Python" language), and of course MS wants to duplicate in C# and .NET all the work that went into Java and the advances we've seen in distributed computing, such as CORBA. Say what you will about Java and CORBA (here, I'll say it for you: "If it's not C or Perl it's shite!", "CORBA's a bloated standard!"), but they have the advantage of being mature technologies.
MS is pulling their usual bullshit tactic of releasing a product that offers nothing new except the new bugs introduced in unproven rewrites.
And given the current state of the economy, telling developers to go learn yet another language is not a very prudent expenditure of resources. Nonetheless, a great many PHB's will give precisely that directive.
...which is why they call it "C++."
It's nice to see this kind of thing come around again, but it's not like it's new technology. Still, it'll be a godsend to have it again. Gdb and Visual C++ suck as debugging tools.
jim frost
jimf@frostbytes.com
One day, a city slicker with a spotless seersucker suit and a perfectly pointy moustache was reported travelling from station to station, selling his new technology suite. It included remote manipulators for making repairs from a higher level, without having to go under the trains. It also came equipped with "parking brakes" for trains, to prevent them accidentally moving while they were under repair.
This new "high level" technology was a hit in many towns, where the young repair technicians were unenthusiastic about life with missing limbs. In addition, the new technology came with many interlocking "safeguard" mechanisms to make sure that no fittings were left unsecured when the repair was completed. This saved many a "crash".
But there remained many towns with older engineers, who had grown up doing things the "fast" way, repairing the trains on the fly (because things went faster that way!), and of course having the scars and stumps to show for it. They were also unenthusiastic about the "safeguards", declaring that they were "smarter than any newfangled machine", and could remember to close the latches and fittings themselves.
In one of these Ancient Telegraph Towns, one of the older engineers, Cyclone Bob, came up with his answer to the newfangled "high-level machines" -- special steel braces to wear over arms and legs while repairing the moving trains. "In most every case, these braces will protect your precious limbs from the hazards of moving wheels!", enthused Cyclone Bob.
The older engineers, who, when all was said and done, actually enjoyed mucking about under trains, and who had already paid their dues in missing limbs, were rather proud of the new braces, and wore them proudly. "My trains hardly ever crash now", they would say, "and now I don't always have to lose a leg to prove it!".
The younger, smarter engineers continued using their "high-level" machines, and were happy that they still had arms so they could snigger up their sleeves.
Just wanted to remind you that deciding at compile time if a given program will go wrong (division by zero, memory faults, infinite loops) or not is an undecidable problem for any Turing-complete language. That certainly limits the "smartness" of a compiler. Detecting typos is an useful feature, but certainly you can't rely on the compiler to find higher level bugs.
Runtime checking is useful, however I'd rather use a tool like Purify/CheckerGcc/Insure++ with gcc and standard C/C++ than switch to a new language.
The Raven
One of my complaints about C (my principal language) is that there is no way to check if a pointer is valid. That is, if it points to a place that I'm not allowed to access, I get a segfault, and am not supposed to return from that. So it becomes impossible to check if the data structures have become corrupted. Oog.
I feel your pain.
What I did was perform a coup on the release process, and now I look at every warning before I release a new version. Sure, I end up doing the work, but at least I don't foist crap on the world.
Trolling, but I'll bite...
experienced MCSE
See: oxymoron
Remove the bloat. Most linux distro's ship with way to many useless programs. These "useless" programs must be useful to someone. Maybe not everyone, but certainly someone. If you don't want to use them, don't install them. The option is a checkbox away in most distro installs.
Dump the command line.
Granted, most users don't give a shit about the command line, or even know such a thing exists for that matter. Most of linux's power comes from the shell, though. Once you get used to it, you start to feel kind of God like.
And if you're admining a system, I'll take a shell any day over some Windows manager snap-ins or whatever the hell they're called. I don't want to be restricted to what some UI designer's whimsey.
Dump open-source.
Once the source is out there it can really be taken back, so dumping OSS is kind of impossible. Even if, for whatever imaginary reason, the Linux kernel suddenly became closed-source, all of the previous versions would still be OSS, and development would just continue along another fork.
[Desktop users] do not want to compile anything.
If a setup process involved compiling but the user couldn't see it, would that make it better? What would be the difference? In Windows, a setup.exe file unpacks some stuff, moves it around, writes some registry settings. What if some executable in linux unpacked some source code, compiled it and put it where it should go? Would that make things better for you, MCSE?
A universal gui system. Linux needs ONE gui.
First of all, choice is a good thing. Unlike Microsoft, where you're stuck with the GUI they give you, at least with UNIX-like systems you're free to choose from any number of GUIs, then proceed to configure them exactly how you want them. Right now I'm using KDE with Mosfet's Liquid engine, some NeXT-ish stuff and a bit of quartz thrown in. I like it. Other people might not, but they can roll their own. Choice.
Now, about having ONE GUI -- you mean like Windows 2000 and XP? (Okay, so can modify XP to look like 2000, but I doubt most users even know that option exists.)
Make upgrading the software easier. Desktop users need an easy way to upgrade the kernel.
This depends on the distro you're using (or if you've rolled your own), but it really isn't that hard. Here's what I do (yes, I do run Red Hat, 'cause I'm kind of attached to it. Bite me.):
1. Download a new kernel.
2. # rpm -ivh kernel*.rpm
3. Reboot.
If you're still clammoring for a GUI to do that for you, KDE and Gnome have nice package managers that will let you click your way through it. If you're using Grub, you don't even really have to do any config editing, especially with RH 7.2's kernel upgrades...
Get a good web browser.
What's wrong with Konqueror? (I don't use Gnome, so I don't know how it's browser is.) Back in the day, we used lynx and we liked it.
And that Mozilla version number stab is utter bull shit. Version numbers are arbitrary. If MSFT released their next version of IE as IE 2002, would that suddenly mean it was 2002 times better than IE 1.0? Would you compare SuSE 7.3 to RH 7.2 based on version numbers?
Proper office programs
Indeed. They're getting there. KOffice isn't terrible, and OpenOffice is okay.
These programs should be able to import all MS formats
Oh, right, you mean those MS formats that Microsoft doesn't provide specs for? Reverse engineering those things doesn't happen overnight. And I can't see MSFT suddenly opening that sort of thing up. (I can, however, see MSFT making arbitrary changes to the formats whenever reverse engineers get close...)
Backward compatibility
Not all Win16, DOS and even Win32 apps run on WinNT, 2000 and XP.
And Linux is backwardly compatible. Stuff that worked on kernel 2.2 and older work fine on 2.4. Just get the source and re-compile it. Oh, wait, source code is useless, I forgot.
J
Cyclone is a remarkable achievement, given they
started with C...
MISRA-C is also a good effort, although somewhat
built on sand.
The safety-critical community over here in Europe,
and also a few projects in the USA use SPARK
though, which is a high-integrity, annotated
subset of Ada. It's static analysis tool
is really remarkable - anyone for static proof
of exception freedom? (e.g. static proof of
no buffer overflow for all input data)
Eiffel is also very good from a high-integrity
point of view, and well worth a look. It amazes
me how much effort goes into researching static
analysis of langauges that are simple not designed
for that purpose at all...ah well...
- Rod Chapman
C with type checking and safety.... yep it is Pascal. Why reinvent the wheel ?
When you have to go to the lengths of thinking in conspiracies, that should be a signal to you that your thought processes have gone out of control.
Bush won. He won by every measure, even the unreasonable ones.
And thank God he did. If Gore had ended up winning, we would still be whining at Afghanistan to please stop letting the bullies pick on us.
Sometimes it's best to just let stupid people be stupid.
First off, good programming practices will resolve 99% of these problems. They aren't unavoidable, they're just the result of being careless. Of the few that any good programmer will let slip through once in a while, most could probably caught with an advanced lint-like tool that checks for things in the source code, or for that matter just a little bit of peer code review. I can't see much in the way of difficult-to-avoid problems that require runtime support to adequately detect in plain old C.
In any case, a programmer's failure to be able to adequately program in C is no excuse for moving to a whole new language, compilers, runtime, libraries, standards, etc. The cost associated with migrating to the new language is excessive. It's like buying $10,000 gold-plated titanium training wheels for your sportsbike to solve your initial problem of being unable to ride the thing without falling over.
11*43+456^2
I won't name my company (you'll have to go to my site for that), but I'm stuck in a very weird industry: In Flight Entertainment. Our customers (airlines) expect our products to perform to the level of reliability that they are used to in the cockpit (99.99% seat availability - a simple stuck cord retractor on a game controller will mark the seat as dead), but they aren't willing to pay the price for mil-spec level engineering ($20K for a single barometer guage in a cockpit is acceptable, but $5Kx400 seats is not). When we try to explain that it can't be done, they just keep pointing out how cheap a VCR/DVD/whatever consumer product is. We never even get to discuss consumer products' EMI risks (the attendant asks you to kill your cellphone on a flight not because it will crash the plane but because no one's spent the $2-4M for each product to prove it won't) or weight or power, because our chief competitor is a subsidiary of a Japanese conglomerate. For more than a decade they've sold their product at a loss to drive us under and dominate the industry (to be fair, same as we'd try if we had deep enough pockets). But we're like a cockroach, hanging on by sheer force of will... and the occasional stellar product (hey, I've got some pride left).
The thing is, I hear similar tales from friends in other companies in this industry and in other industries. The common factors are these:
- The customer demands quality, but is willing to sacrifice it for price.
- The supplier is unwilling to stand up and tell the customer the hard facts (here, out of fear of a competitor but also on the mistaken belief that we'll make it up on the maintainance contracts).
- The customer doesn't have a lot of insight into what's "under the hood," allowing the supplier to provide flash over substance.
IMHO, it is the industry that allows this kind of behavior. In a military shop, we'dve been eliminated years ago. In a consumer shop, the occasional hiccup isn't noticed. And, just like an abusive/codependant relationship, as long as the same destructive factors remain in place, the same results will occur."Prepare for the worst - hope for the best."
From another MCSE (of many years)....Windows 2000 is DEFINATELY NOT stable. In short, NT stability is heading in the wrong direction!
C++ provides plenty of support for resource managements issues. The standard library includes vector, string, auto_ptr and many other related tools, all of which assist with guaranteeing memory is released properly. The fact that ill-trained C++ programmers continue to use raw arrays and pointers, when they should almost never be used beyond low-level code, is not C++'s fault.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I think I have a bathroom phobia.
Or should that be that it would be funny if it weren't true? As was once said of Lisp, those who forget Pascal are doomed to recreate it ... eventually.
I'm sure you solve the halting problem for any application within 4 standard deviations without waiting too long.
While I agree with most of your post, I have to point out that coming within a factor of two is not very impressive for the halting problem. Since a given program on a given input will in fact either halt in finite time or it won't, your statement boils down to the assertion that it is possible to say either the word "true" or the word "false" (at random) in polynomial time. If you do this, you will either be right-within-a-factor-of-two (what most people would call wrong) or you will be exactly right. In the industry, this algorithm is called "guessing" and can be proven to be within a factor of two of correct on all binary choices.
-- MarkusQ
Like invoking a script written in Perl?
Practice random senselessness and act kind of beautiful.
I've been using ada at a job for 6 months now. It is a "safe" language.
..Y is an it between -360 and 360.
I didn't like it at first. Now I find I'm liking it more and more. It does a lot that make it really usefull in the "very very high" reliability programing.
It does have very strong type checking al la jave. You can make you own range constraints on types you create
If you try to make Y bigger or smaller that that range you throw a contraint exception
You pay a little in performance for this, but although I hear that if you did all that checking manually in another language it would be even slower.
It has some other nice features that other programming languages have in various forms, including enumeration types , records types (like a struct) and you can specify down to the bit level the arrangement of the struct..ie which fields go where. It even has "packages" which are a bit like objects.
Ada isn't as powerful as C though and it lacks a lot of the tools and libraries . Its also hard to find good books on it too.
One joke at work is that Ada actually more powerfull because you can bind it to C code.
We hear stories about other projects having problems with C and bigger problems with C++. Ada although slow to program in does nice for systems that require very high reliability.
There is a Gnatt compiler which is free and open source too... Try it.
I wonder if this Cyclone makes programming "safer" by making it more difficult. What I mean by this is that some languages out there don't let you use pointers at all, or perform all sorts of checks on array bounds before each access. I like to call this "broken programming" simply because it isn't right in my opinion.
A programmer should have all tools available to him, and should choose the best tool for the job when solving any given problem. Taking away tools doesn't make programming safer--it makes programming messier.
I didn't read the article or the language description or anything, so I don't know if this is the case with Cyclone. But it certainly is with many languages. I thought this is what Lint is for. Lint is a program which performs source-level sanity checks on your code. You write your program in C and/or C++, and whenever you compile, you first run Lint to make sure everything's ok. Sure, it's not perfect, and probably won't find all problems, but it will find quite a few things wrong that you didn't even know about. (There are free and commercial implementations of various source-level things like this.)
I think that careful programming and use of a tool like Lint can make a better improvement than taking away some of the most powerful tools in programming just because some people don't know how to use them. Oh well.
Would there be any validity in compiling hurd with this cycylone thing to in effect double up in some areas?
--
"we live in a post-ideological world..." - Billy Bragg.
In most places the person getting the most votes is generally known as the winner. Face it, democracy in the US is finished. Some of us are patriotic enough to let us go. The others are going to give up their rights and slip towards fascism. You won't talk me into being a good German.
Take a look... it basically is Ada, redone with C syntax and without the built in tasking niftiness.
[Ada => Cyclone]
type checking => type checking
exceptions => exceptions
discriminated types => tagged unions
parameterized types => polymorphic data structures
access types => * pointers
polymorphism => polymorphic functions
private sections in package spec => abstract types
array slices => subtypes
Ada has a lot more features, the only ones Cyclone boasts over Ada are: garbage collection as the norm not the exception, and tuples.
Now granted, noone knows the first much any more, because "Learn XXX in 30 minutes" doesn't cover it. I wouldn't teach someone C unless they were really a computer geek, and anyone who doesn't know what a register and MMU are should NOT be using C.
But if you do know how a computer works, and can avoid the traps in libc, you'll be fine and have nearly 100% portable code as well.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
Ada95 has supported all these features, both staticly and dynamicly, for the last six years. 20 years if you consider Ada83 before that.
People keep fiddling with this Java/C#/language dejour bullshit for safety critical systems, when theres already a tool out there(Ada95) that does 100 times what these other tools only grasp at.
Hey, C,C++,Java, et... are all nice tools, but for the love of G-d, dont write anything critical using them.
http://www.adapower.com
comp.lang.ada
http://www.adaic.org
The only IDE that I know of that does this is CodeGuide, by Omnicore, and they've only applied it to Java. (free 30 day trial!) I've been using it professionally and at home for years, and it's an absolute joy.
The sooner you can detect a problem, the better. Cyclone pushes some run-time defect detection into compile-time. CodeGuide pushes compile-time defect detection to typing-time. Maybe someday soon our development environments will be able to automatically detect many run-time defects as we type our code.
But on modern architectures, many of these design decisions are not that sensible anymore. For example, pointer arithmetic is more of a burden to modern optimizers. Languages that don't have pointer arithmetic but use array notation instead usually do as well as C in terms of performance, and often better. Similarly, the many unsafe operations in C, like "*(double *)&x" are better expressed using something that is syntactically distinguishable from a safe operation, say, "unsafe_get_bits(x,double)"; doing so involves no loss of functionality.
But language success involves a lot of psychology. Java is much more like Lisp than like C++, yet people think of it differently because of its syntax. And if it takes Cyclone to get C programmers to program in what amounts to Modula-3, so be it--the world will be better off for it.
But just because Ada is like that doesn't mean every safe systems programming language has to be like that. Modula-3 is a whole lot nicer than Ada. Sather is a whole lot nicer than Ada. And there are other examples of safe systems programming languages.
I think Cyclone has a good chance to deliver safer systems programming to C programmers in a package that they find palatable.
Seriously, I hope they'll start packaging Cyclone for Debian as well. That's a good way to get more exposure for it.
I think I'll stick to Python and Jython.
From their description, it just sounds like an improvement on C. So you don't need to "rewrite" your C code, just modify and recompile it.
Your assertion that this is for "lazy" programmers recognizes that avoiding or fixing pointer bugs takes time and effort. Programmers spend a certain number of hours per day programming. They can spend those hours avoiding or fixing pointer bugs, or they can spend those hours improving the UI, fixing other bugs, or creating entirely new applications. I find the latter much more useful than the former.
The whole purpose of computers is to automate repetitive operations, and ensuring pointer safety seems like a very repetitive operation to me, and one that everybody makes mistakes on.
C is a fundamentally unsafe language.
.. it'll be a bit more work, of course, but blaming the C language for the incompetency of some of the people that use it seems a tad unfair. It doesn't take a whole lot of effort to innoculate C code from the type of buffer overrun attacks and memory errors that have been seen in the past. Unfortunately, a lot of people learned this lesson about 10 years too late.
..
Nonsense. It's more appropriate to say "there's a lot of poorly-written C code that is fundamentally unsafe." It's true that C has some lower-level capabilities that can potentially be used in an unsafe manner. That doesn't mean that they have to be used in an unsafe manner. A well-written C program can be just as "safe" as its Ada counterpart in terms of array bounds checking and exception handling and things of that nature
Furthermore, a flawed and insecure algorithm is going to be flawed and insecure regardless of what language is used to implement it. A "safe" language like Ada might prevent you from trashing the stack and/or writing to arbitrary regions of memory, but it's not going to prevent you from implementing a mathematically weak encryption scheme, and it won't warn you if a programmer forgets to take out a debugging back door before a piece of code is released to production. You can write poor code in any language. You can write great code in any language.
Application code, and certainly high-level code where security is essential, just aren't C's strong suits.
And yet C works well enough to implement what is perhaps the world's most secure operating system (OpenBSD.) I'm not sure what you mean by "application code" (that's an awfully wide brush you're using there.) If I wanted to write, for example, a GUI application for Unix with database access, I'd most likely use C++ and Qt. However, this choice would be based on the fact that it's a lot less work to use C++ and Qt than it would be to use something like C and GTK+. Security and safety have nothing to do with it.
I can't see how even the geniuses we're talking about can start from such a broken language
C is not a broken language. A lot of code written in C is broken. When you make this distinction, you are on the road to understanding why this bias against C is completely unjustified.
We're going down, in a spiral to the ground
It's amazing the attitude of some people. I'm curious to know what kind of jobs these programmers who think they're too good for modern techniques actually have. Do they spend all day writing code in machine language?
So lottery systems tend to have redundant communications links, Tandem Non-Stop hosts, and lots of error and sanity checking. In the Mexico City earthquake, the lottery system stayed up, using its own backup radio links.
This doesn't kill the systems vendors. GTech, which runs many state lottery systems, reports that they pay out about 0.3% of revenue in penalties. Of course, they spend more than that avoiding trouble. And it works.
There are lots of cool things you just can't do easily with flat text, like tagging sections of code, perhaps to facilitate aspect oriented programming. You could show all related code in one text face, color, or whatever.
The overhead doesn't have to be great, it doesn't even have to imply a GUI, you could do it under MS-DOS (or use CURSES in GNU/Linux systems).
--Mike--
Cyclone could be a winner if it gave you C-like performance with safety and minimal changes to your programs. But it doesn't match C performance as it is and I don't think large, existing C programs will port to it easily, despite superficial similarities.
The way it is, I think you are better off using O'CAML or MLton. They are probably easier to learn and give you better performance. O'CAML, in particular, has already been used for a number of UNIX/Linux utilities. And Java is probably as C-like as Cyclone and runs faster (although programs have a bigger footprint).
RealityMaster101 said, among other things: "Bush won. He won by every measure, even the unreasonable ones." To which the only response is to say, well, that's just not true. I'm sure there are lots of unreasonable measures by which Bush didn't win (I think you forget just how unreasonable humans can be :), but there are a
couple of very good reasonable measures.
First, Gore had the most votes of any candidate across the US, winning narrowly but clearly in what is often referred to as the "popular vote" measure.
Second, there was a small but extremely signficant minor left-wing player (Ralph Nader) participating in the election, and I believe it may be reasonable to assume that most of the Nader-voters would have preferred Gore over Bush. If the US had a preferential voting system instead of this ludicrous first-past-the-post crap, Gore should (probably :) have won quite clearly. And hell, Bush senior might well have
beaten Clinton in '92, assuming most of that very
large number voting for Perot would have preferred Bush.
Third, and this (probably) being the one that the guy's sig referred to, there were a number of quite major fuckups in the Florida election (and possibly elsewhere, but Florida was the most significant). I don't think there was any simple way to solve this - probably the only really viable solution would have been to hold another election (for the whole country, not just Florida) and that would be way too embarrassing for the USA as a country. "Look! we're the leaders of the free world, the richest and most powerful country in the world, and champions of Democracy(tm)... and we still managed to screw up our presidential election so badly that we had to do it again!"
*grin* Actually, that would be pretty funny. But at least it would be admirable that you (the US as a country, not RealityMaster101 personally :) had
the balls to admit the mistake and actually
fix it, even if it was embarrassing to do so.
Instead, you ended up with a situation that was
more sad and pathetic than funny, as a classic
demonstration of the PHB ethos of "it's more
important to get something done on time, even
if it's wrong!" rather than being willing to
take the time to be sure you got it right.
There was one significant positive to come out of that election though - it can now be almost the canonical example of what is wrong with the first-past-the-post voting system. Though I don't have any great hopes of the US changing their system anytime soon, at least there's now something that people can point to and say "This is why we should change."
Pete.
I was kidding. The point was that we do the same things we've always done, except we use nifty new stuff to do it.
A deep unwavering belief is a sure sign you're missing something...
Agreed. There are an immense number of ways the US voting system could be improved. FPTP is just a bad system. For the likes of presidential elections and congress elections, implementing a STV (Single Transferrable Vote) system would be a huge improvement. That way, those who wanted to vote for a candidate, yet protest dissatisfation with them in some way could give their first preference to a different candidate and their second to the candidate they wanted elected. A much better system.
I don't like trolls and mod against me if you like, but I'd prefer if you'd reply.
What about C+-?
I doubt you can beat a subject-oriented language!!!
Getting facetious, Cyclone sounds like an interesting idea - I just wish they'd released an open source edition of C+@, and let Unir be the little fish in the big pond that that would've provided, instead of letting Unir be the extra-size fish in the tiny little pond that resulted - yes, we've read DJJ, and no we can't afford C+@!!! What more can you want?
"I his bow, and spun and wove, likes you." Vere de Vere out of my mould's mouth dragged me of the voluntary apes.
Whoa, troll! I'll bite on youir ruby comment!
:-)
I'm not conversant with python beyond a quick peruse of a basic primer, but the more I look at ruby the less like perl it seems. Now, if you had mentioned smalltalk you might have been right in your description of the ancestry of ruby.
Not that I'm a ruby zealot, I use 1/2 a dozen languages all the time - its always a case of tools for the job.
Anyway, the big difference between perl and ruby is that I can understand what I wrote 3 months ago in ruby without commenting it to death
Regards
da frog
And the basic procedural programming mechanisms they use, right down to the almost identical grammar for structured programming constructs and right up to their use of exceptions to transfer control up to higher level code.
And large parts of their OO system, including the way they model with classes, objects, members, access modifiers and inheritance.
And even, if the near future unfolds as expected, such support as they have for generic types.
In other words, the underlying underlying models for each of these languages are pretty similar. There are some truly significant differences: the garbage collected memory management in Java and C#, the use of templates in C++, the use of multiple inheritance in C++ vs. interfaces elsewhere, and the standard libraries. But even these still fit into similar basic programming frameworks.
Of course, Java and C# are each used differently, idiomatically, from C++, and this is where most of the differences lie. But, when compared to the field of programming languages as a whole, they are small differences. Java and ML have big differences. C++ and Visual Basic have big differences. Java, C# and C++ are a family.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.