Programmeertaal Cyclone: bugwerende C-variant

Op New Scientist is te lezen dat er een nieuwe programmeertaal in ontwikkeling is, die het verschijnsel bugs moet gaan elimineren. Het betreft de taal Cyclone, die ontworpen wordt door de Cornell University in samenwerking met AT&T Labs. Wetenschappers omschrijven de nieuwe taal als een dialect van het veelgebruikte C, met als grootste verschil dat software haast geen onvoorziene fouten meer kan hebben.

Om dit te bereiken heeft men de kracht van C gecombineerd met een aantal extra veiligheidscontroles. Het gaat hierbij voornamelijk om fouten die pas optreden als het programma op volle toeren werkt, zoals bijvoorbeeld buffer overruns waarbij het geheugen van de computer verkeerd gebruikt wordt. Hiertoe controleert de engine niet alleen de syntax, maar daarnaast ook de manier waarop een programma werkt. Dit leidt volgens de plannen tot een nette foutmelding in het uiterste geval, in plaats van een vastloper zoals nu nog wel eens het geval is.

De programmeurs verzekeren dat Cyclone genoeg op C lijkt om bestaande applicaties eenvoudig om te kunnen zetten. Tot nu toe hebben ze zelf alleen nog maar een eenvoudige webserver geschreven in hun eigen taal, maar deze test wees wel uit dat Cyclone bijzonder stabiele software oplevert. Men hoopt eens nog een keer een groot besturingssysteem zoals Linux in de nieuwe taal te zien verschijnen, maar voordat het zover zal zijn willen critici ongetwijfeld meer voorbeelden van goede toepassingen gezien hebben.

Reacties (48)

[boner]

ooit van lint gehoord?

een utility die bij ELKE goeie c-compiler zit en die dit soort warnings geeft.

[Dawai]

Of BoundsChecker:

http://www.compuware.com/products/numega/bounds/inde x.htm

wel een dure grap

[Munters]

Lint was prachtig en noodzakelijk in de tijd dat compilers niet veel verder kwamen dan "Syntax error detected at line ###, compilation aborted", waarbij de fout enige tientallen regels eerder kon liggen.
En de compiler van warnings nog helemal niet gehoord had.

Als je gcc of vc of zo hebt, heb je lint echt niet meer nodig.

En gelukkig, want of je source lint-warning-free te krijgen (zonder de opties uit te schakelen) (dit was vaak een eis van opdrachtgevers) stond je code vol met lint-commentaar.
(Dit waren lint-specifieke commentaren die begonnen met /*lint , die op dat moment een bepaalde warning eenmalig uitschakelde).

Br, wat een tijden. Zo 'n SCO compiler, waarbij je (als de code correct door lint kwam) bij een vreemd resultaat eerst de assembler code maar eens ging bekijken . Vooral de optimizer kon er wat wat...
Had je weer compiler-directives om een stukje lang de optimizer uit te schakelen.

(Tjongejonge, opa vertelt... )

[zakalwe]

Hoe zou deze taal zich verhouden tot een ander C-dialect: Objective-C? Dit is een soort java-achtige, objectgeorienteerde runtime variant van C welke Apple gebruikt in haar MacOSX (voorheen dus in NeXTstep en OpenStep). Dit dialect is daardoor alleen populair bij de oude NeXT en OpenStep ontwikkelaars en Apple zelf. Het lijkt me dan ook lastig voor deze nieuwe variant om wat marktaandeel weg te snoepen van C, C++, Java en de MS talen.

[Parlor_Inventor]

Objective-C is een heel mooi taaltje met een veel betere implementatie van OOP dan C++, maar toch meer op C lijkend dan C++. Heel NeXT is er in geschreven, en er zijn compilers voor voor oa Linux. Het hele GnuStep platform wordt er bijvoorbeeld in geprogrammeerd. Zoals het hele NeXT-systeem is het technisch gezien prachtig, maar is het qua marketing een complete flop geworden, en Objective-C wordt dus alleen nog maar door een kleine groep mensen gebruikt. Dat er een vervanger moet komen voor C++ is al zo'n 18 jaar bekend, maar of Cyclone het gaat worden? Ik denk eerder dat andere talenbouwers de ideeen van Cyclone toe gaan passen in hun talen en dat Cyclone een stille dood sterft......

[Verwijderd]

Ik heb nog nooit van objective -C gehoor maar uit jouwn verhaal lijkt mij op te maken dat het alleen voor de MAC is, dan lijkt mij inderdaad dat het niet echt bekend is bij andere programmeurs, aangezien veel applicaties die voor de MAC worden geschreven, eerst voor win. zijn geschreven en dan wil je niet weer van voor af aan beginnen te programmeren , maar pak je gewoon een multi-platform compiler zoals C,

[zakalwe]

Zoals in de post van Parlor te lezen is is Objective-C ook voor ander platvormen beschikbaar.

Je andere argument klopt, maar om andere redenen dan je hier noemt.

Er zijn maar weinig applicaties die een directe port zijn van hun windows broertjes, zelfs Office voor de Mac bevat ongeveer 50% nieuwe code (bron: Wired http://www.wired.com/news/technology/0,1282,48160,00 .html ). Nattuurlijk is het wel zo dat de verschillende development teams zo veel mogelijk code sharen, maar dat is iets heel anders dan porten.

Toch klopt jouw statement dat maar weinig (Mac)programeurs bekend zijn met Objective-C.
Veel applicaties voor OSX zijn namelijk ports van OS9 applicaties naar 10. Omdat Apple ruim voor de introductie van OSX iedereen dwong hun applicaties om te zetten naar de Carbon API werken al deze programma's dus zonder een regel Objective-C te bevatten.

C is van het begin af aan opgezet als een systeemonafhankelijke taal (net zoals vrijwel alle programeertalen). Het zijn juist de APIs die roet in het eten gooien (ja, er bestaan inderdaad platform onafhankelijke APIs).

[Verwijderd]

controlles betekend preformanceverlies.
ik ben dus benieuwd hoe snel die taal wordt

het idee met C was dat als je controlles nodig hebt je ze maart programeren moet.

Als ze elk probleem uit gaan sluiten d.m.v. controlles zou het zelfs langzamer dan Java kunnen worden.
(hoewl java niet zo heel langzaam tegenwoordig is)

[Parlor_Inventor]

C is gemaakt in 1970 ofzo, toen performance alles was en er nog delen van een applicatie werden gemaakt in Assembler, puur voor de performance. Tegenwoordig is het snel bouwen van applicaties veel belangrijker. Tijd is geld, en het besef is er vooral bij de consument niet echt dat software net zo goed een product is als een auto of een radio of iets anders tastbaars, dus mensen zijn niet bereid om veel geld te betalen voor software, vooral niet als ze voor een knaak een kopietje kunnen krijgen. Wat je nu ziet is veel erg slecht geprogrammeerde software waar bugs in zitten om maar zo snel mogelijk software te maken. Deze taal zou veel van deze bugs er uit moeten kunnen halen. Ik denk dat een techniek als deze wel succesvol gaat worden. De computers zijn tegenwoordig toch hartstikke snel, en als de computer zelf de rotklusjes op kan knappen dan is dat alleen maar goed denk ik (tenzij je 100% performance wilt natuurlijk)

[Verwijderd]

Uhm ja en als het controlesyteem nou buggy is?

[Verwijderd]

dan laat je je originele programma toch door de (misschien buggy) variant scannen en met die uitkomst kun je dan weer verder

maar even serieus, zo'n taal bestaat volgens mij nooit helemaal, omdat je altijd denkfouten van de programmeur hebt en als je een beetje leuk met pointers aan het knoeien bent kan het altijd nog wel fout gaan, de loop van een programma is namelijk nooit helemaal na te gaan. (vergelijk met het 'halting problem' een leuk probleem uit de theoretische informatica)

[Verwijderd]

Lijkt me ook inderdaad, standaard dingen als objectdeclaraties die niet goed afgesloten worden, memoryleaks etc. zijn volgens mij we redelijk makkelijk op te sporen door een proggie, maar als de programmeur bijvoorbeeld een infinite loop creeert met als oorzaak een door de gebruiker van het programma veroorzaakte handelingen (Invoeren van data etc) kan dat controlesystem dat dus echt niet opsporen bij design-time.

[tweakerbee]

Dat weet je overigens niet zeker. Het zou namelijk redelijk revolutionair zijn, en ook moeilijke fouten als die jij begrijpt opsporen.
Blijf erbij dat dit soort dingen alleen maar hulpjes voor een programmeur mogen zijn. Hij moet zelf nog steeds goed weten waar hij mee bezig is, en kunnen debuggen (handmatig).

[tweakerbee]

Lijkt me logisch

Want die is niet met het controle systeem gecompileerd

Nee, ga er maar vanuit dat als ze voor stabiliteit gaan dat de compiler redelijk bugfree zal zijn!

[raptorix]

Klinkt goed, zeker voor bepaalde toepassingen die bijvoorbeeld nogal bedrijfs/proces kritisch zijn is dit zeer interessant, een gast op GOT had een tijdje terug ook zo een idee maar weet niet of ie ook bezig was het uit te werken.

[TheGhostInc]

Ik geloof dat de meeste mensen een grotere hekel hebben aan die irritante BSOD en irritante foutmeldingen dan gewoon meteen een Reboot.

Foutmeldingen moeten gewoon niet voorkomen in een comercieël produkt, dit is eigenlijk een manier om de huidige, soms slordige, manier van programeren weer een beetje te ondersteunen.

* 786562 TheGhostInc

[Ludewig]

TheGhostInc denkt dat dit alleen maar meer geheugen en cpu tijd kost, en voorkomt dat een programeur echt z'n best doet op zijn werk. Fouten moeten hersteld worden, niet omzeild.

Het mooie van deze technologie is dat het in de compiler zit en niet in een virtual machine (zoals bij Java). De code wordt dus gecontroleerd tijdens het compilen, waardoor het niet meer geheugen en cpu-tijd kost.

Het is wel duidelijk dat TheGhostInc en oisyn nooit zelf iets geprogrammeerd hebben. Bugs zijn onvermijdelijk gezien de complexiteit van programma's en de gebrekkige ontwikkeltools. Java en Cyclone zijn nodig om dom werk uit de handen van programmeurs te nemen. Nu moet een programmeur bijvoorbeeld heel erg oppassen op geheugenleaks in C, terwijl de compiler/VM dat zelf moet bijhouden. Dan kan de programmeur zich richten op de functionaliteit, wat al lastig genoeg is.

Het is inderdaad zo dat bedrijven zoals M$ gewoon niet goed genoeg programmeren. Maar ik denk niet dat het eerlijk is om programmeurs de schuld te geven als er zelfs fouten zitten in de software van NASA-raketten, waar NASA verschrikkelijk veel geld uitgeeft aan tests. Testen is een kwestie van tijd en geld versus bugs. Wil jij dat Unreal II twee jaar later uitkomt en fl. 500 kost in plaats van fl. 100, maar bijna geen bugs bevat?

Er zijn twee alternatieven:
1. Zoals het nu gaat. De bugs worden gefixed terwijl de software al in de winkel ligt.
2. Het wordt makkelijker gemaakt voor programmeurs door betere ontwikkeltools. Er zijn minder bugs voor hetzelfde geld.

Ik weet het wel.

[.oisyn]

Het is wel duidelijk dat TheGhostInc en oisyn nooit zelf iets geprogrammeerd hebben.

whaahaha, je moest eens weten... maar dat even terzijde

ik ging aan de reactie van TheGhostInc ervan uit dat er ook runtime gecheckt wordt, ik heb dus niet het hele artikel gelezen

al vraag ik me af hoe dit tijdens compiletijd te controleren is, omdat de compiler geen verstand heeft van je codeflow, dus ik sta nog steeds achter de conclusie van TheGhostInc

.edit: even het artikel gelezen:

Even if a bug still occurs, the compiled system will lead the program to halt safely, not crash

dus er zit ook runtime checking in

[Codin the Coder]

Het is wel duidelijk dat ......... oisyn nooit zelf iets geprogrammeerd hebben.

Codin.SetMood(SURPRISED);
Codin.ProduceReaction();

[surprise-mode]
Oisyn nog nooit wat geprogrammeerd ??
[/surprise-mode]

Codin.SetMood(CARRIEDAWAY);
Codin.ProduceReaction();

[got-carried-away-mode]
WHAAAAAAAA HA HA HA HA HA HA HA HAAAAAAAAAAAAAAARRRRGH!!!!

WHOE HA HAAAAAAA!!!!!!!!!
[/got-carried-away-mode]

Codin.GoToSleep();

[.oisyn]

TheGhostInc denkt dat dit alleen maar meer geheugen en cpu tijd kost, en voorkomt dat een programeur echt z'n best doet op zijn werk. Fouten moeten hersteld worden, niet omzeild

mee eens, maar je zult dit best kunnen gebruiken tijdens het test-traject... Als er fouten in zitten moet je die verbeteren net zolang tot ze er allemaal uit zijn, en vervolgens compileer je met normaal C en dat release je dan

[Verwijderd]

Cyclone? Waarom niet gewoon D genoemd?

[farlane]

Of C+2? What's in a name?

[Parlor_Inventor]

Ik kwam laatst op CPAN een Perl-module tegen waarmee je spelfouten in variabelenamen kunt maken en de compiler kan dan zelf raden welke variabele je bedoelde. Het ding was bedoeld voor extreem snel prototypen van apps (daar zijn scripttaaltjes sowieso wel koel voor). Hoe ze het deden weet ik niet, volgens mij handig gebruik van een of andere geavanceerde funxie van Perl, maar het is wel geinig op zich.

[Verwijderd]

Ik houd persoonlijk niet zo van dit soort programma's omdat je dan de controle kwijt bent bij wat ie doet. Waarschijnlijk zal ie wel met waarschuwingen komen, van ik heb deze variabele door deze vervangen. Maar wat als de keuze van de compiler niet de goede was? Omdat ie meestal wel met de goede variabele zou komen ga je na verloop van tijd de waarschuwingen negeren.

Dit soort geavanceerde tools maakt de programmeur enigzins lui, omdat ie op zijn tools gaat vertrouwen.
De meeste fouten zijn volgens mij toch denkfouten van de programmeur of gewoonweg verkeerde specificaties. Deze zijn eigenlijk alleen op te sporen door goed te testen, maar meestal is daar te weinig tijd voor, omdat een manager meestal de deadline wil halen of hooguit slechts een keer wil uitstellen. Dit komt de kwaliteit van programma's meestal niet ten goede.
Het is gewoon vrijwel onmogelijk om een bugvrij programma te maken. Ofwel een patch is oude bugs eruit en nieuwe erin.

[henkleerssen]

Ik weet ook niet of je hardcore proggers C(en C++ .. voor het gemak scheer ik deze over een kam.. fout he.. ) een VB achtige compiler moet gaan aanbieden, die alle prog fouten maar slikt (variabele declaratie en casten zo on the fly, slecht opzetten van constructs en structs etc.).
Het is toch ook de kracht om juist via wat strictere prog regels toch geheel vrij te zijn met wat je progt... en alles vrijelijk kan benaderen (een stuk geheugen met een pointer) binnen je PC zonder dat een extra interpreter erover heen gaat die op bugs gaat controleren (Zie ook artikel "type checking engine", dat wordt toch ook al gedaan in Visual Studio?)?.

[Parlor_Inventor]

Of je maakt een pragma als 'use strict' in Perl in je taal. Voor erg snelle hacks kun je gewoon je gang gaan, maar als je wat meer wilt doen kun je de compiler zeggen dat hij niet alles hoeft te slikken.

[Verwijderd]

Jammer dat voor C i.p.v. C++ gekozen is..

[hneel]

Kan heel handig zijn.

Met de 'gewone' C en C++ compilers heb je ook nog enorme verschillen wat foutmeldingen betreft.

Op mijn werk heb ik ooit een MsDos C compiler gebruikt die zelfs op statements als
if ( a = b ) {...}
of
if ( .... ); {.....}
geen warnings gaf

Met de huidige Visual Studio wordt je gelukkig vaak genoeg gewaarschuwd.

[Verwijderd]

Dat je geen warnings krijgt is omdat die twee regels code prima en correct C zijn. Misschien niet netjes, en niet altijd even gebruikelijk, maar wel correct

if( a = b ) { ... }

zal bijvoorbeeld altijd { ... } uitvoeren waneer b niet 0 is, soms is dit handing.

if( ... ); {... } is ook correct, maar niet iets wat je ooit echt nodig zult hebben.

[hneel]

Dat is wat ik bedoelde: het is wel correct, maar in 99% van de gevallen het gevolg van een typo.

Als je een beetje netjes programmeert schrijf je zulke code niet bewust.