Det perfekte programmeringssprog: Eiffel

Ok, "perfekt" er måske et lidt voldsomt ord og det afhænger jo forøvrigt også af den pågældende opgave. Men set i datalogisk relation (læs: functional safety, static proving, maintenance og reuseability), så er Eiffel bestemt interessant. Og det kan jeg sige som erfaren udvikler indenfor C#, ANSI-C, C++, Delphi, Pascal, VB.NET, VB, m.f. ...

Det er forøvrigt i forbindelse med evaluering af de nye Code Contracts i .NET 4.0, at jeg har fået undersøgt sproget rigtigt.

Hvis man er lidt interesseret i ting som "garenteret fejlfrit kode", så kan jeg derfor anbefale præsentationerne på følgende side. I særdeleshed præsentationerne om "Design by Contract" (som forøvrigt også er gældende for mange andre sprog. Heriblandt C# 4.0) og også præsentationerne der sammenligner Eiffel med Java, C# og Delphi.

I får lige nogle af key pointerne:
- Eiffel kan compiles til .NET eller ANSI-C. (Syntax og kode uændret)
- Compiler man til ANSI-C, så er det reelt platforms-uafhængigt. (Selv embedded devices!)
- Kan konsume libs fra eg. Java, .NET, C++, ANSI-C, COM uden brug af wrappers.
- Kan benyttes og compiles fra Visual Studio.
- Garbage Collector. (Også i outputtet til eg. embedded devices.)
- Der findes gratis GPL-udgaver af sproget (samt værktøjer)
- Inline doc, generering af disse, UML-pladder ... yadayadayada

Alt sammen ligegyldigt! Her er det spændende:
- Bygget med henblik på Code Contracts
- Der findes ikke LINQ i Eiffel. Der findes ikke structs i Eiffel. Der findes ikke enums i Eiffel. Der findes ikke interfaces i Eiffel. Der findes ikke private, public, protected, nested, virtual, abstract ting i Eiffel. Der findes ikke <INDSÆT DIN YNGLINGS-FEATURE HER> i Eiffel! Hehehe ... Simplicitet og "én måde at gøre tingene på" er dominerende.

Der er dog også et par ting, som jeg ikke er så imponeret over. Bl.a. så er dens håndtering af namespaces ikke imponerende. Den mangler rigtige enums og ligesom andre sprog, så udvikler sproget sig fra tid til anden og den føromtalte simplicitet risikerer derfor hver gang, at blive forplumret med tiden.

Jeg har dog stadigvæk ikke prøvet at lave et rigtigt (til produktionsbrug) projekt i Eiffel, så jeg kan endnu ikke fortælle om rigtige erfaringer med sproget.

Hehehe ... Simplicitet og "én måde at gøre tingene på" er dominerende.

Det plejer i resultere i at folk så laver deres egen måde, som bliver til 10 forskellige måder.

Men det har jo agents og tuples, som de fleste funktionelle sprog.

Jeg tror dog ikke på argumenterne om "garenteret fejlfrit kode". Så jeg savner nogle argumenter for at bruge sproget.

(Ikke at det ikke er et interassant sprog at lære, men som de fleste funktionelle sprog)

Hvad med Go..?

Windcape (2) skrev:

Det plejer i resultere i at folk så laver deres egen måde

Ud over at IDE'en og værktøjerne slår hårdt ned på folk, som der eks. forsøger at implementere deres egen navngivning eller kommentering, så er sproget slet ikke fleksibelt nok til at "folk kan lave deres egen måde". Det er lidt af ideen.

Windcape (2) skrev:

Jeg tror dog ikke på argumenterne om "garenteret fejlfrit kode"

Static proved code er heldigvis noget der er matematisk beviseligt (deraf navnet), så det er ikke noget du behøver at tro på. Det betyder selvfølgelig ikke, at der ikke er noget vedligehold. Der er bare beviseligt mindre.

Windcape (2) skrev:

Men det har jo agents og tuples, som de fleste funktionelle sprog.

Eiffel hører ikke under funktionelle sprog og dets "agents og tupples" er forøvrigt ikke noget af det, som de er specielt stolte af.

illishar (4) skrev:

Static proved code er heldigvis noget der er matematisk beviseligt (deraf navnet), så det er ikke noget du behøver at tro på.

Ja, men code contracts skal jo stadigvæk defineres af programmøren før du kan lave static analysis på koden.

illishar (5) skrev:

Eiffel hører ikke under funktionelle sprog

Det er vel nærmere en hybrid.

#3 Hvis du tænker på Google "Go"-sproget, så tilbyder og/eller løser det umiddelbart det ikke noget, som eks. C# ikke gør. Tilgengæld løser og tilbyder C# en masse ting som Go ikke gør. (Ikke umiddelbart den bedste reklame for Go.) Men ok, Google's Go er simpelt, hurtigt og lægger sig tæt op af sprog som Java og C#.

Hvis du tænker på Go!-sproget, så ligger det ironisk nok ikke så langt fra Eiffel. Men det er nok bare en kende mere akademisk og excentrisk end Eiffel.

#7

Jeg må indrømme at jeg ser go (Google go) som en erstatning for C ikke for C# og Java.

Windcape (6) skrev:

Det er vel nærmere en hybrid

Umiddelbart så opfylder Eiffel ikke nogle af betingelserne for funktionelle sprog. Men ok, funktionelle sprog går også højt op i matematisk beviseligt kode. (Men dog på helt anden vis end Code Contracts.)

Windcape (6) skrev:

Ja, men code contracts skal jo stadigvæk defineres af programmøren før du kan lave static analysis på koden.

Ja, desværre og det er nok i virkeligheden den største forskel på "beviseligheden" i Code Contracts kontra funktionelle sprog. Tilgengæld så er både Visual Studio (Code Contracts) og Eiffel IDE'en ret arrige mht. tvinge programmørene til at lave dem og også selv foreslå egnede kontrakter. Eiffel har dog vendt processen om i forhold til C#, såldes at det er mere naturligt at skrive kontrakterne end den egentlige implementation.

Apropos Code Contracts, så er de forøvrigt også grunden til at SPARK (Ada) er langt mere anbefalelsesværdigt indenfor functional safety end eks. MISRA C. (Eiffel er dog mildest talt mere interessant end Ada.)

arne_v (8) skrev:

Jeg må indrømme at jeg ser go (Google go) som en erstatning for C ikke for C# og Java.

Ja ok, fair nok. Det var mest garbage collectoren jeg tænkte på.

#9

Jeg mener faktisk at Ada83 var et glimrende sprog.

Det blev bare for komplekst og for kludgy med Ada95.

Windcape (6) skrev:

Ja, men code contracts skal jo stadigvæk defineres af programmøren ...

Forøvrigt så bliver Code Contracts jo nedarvet gennem klasserne. Så hvis du laver den ultimative kontrakt i dit øverste interface/klasse. Så vil det gælde for alle dine efterfølgende objekter, til evig tid. ;)
... og det behøver ikke engang at være lavet af dig. Hvis C# lavede en kontrakt til "System.Object", der sagde at "object != null", så ville alt "void"-termologi blive udslettet med 1 slag. Ikke nødvendigvis en god ting i C#, men pointen er fin nok.

#10

GC er en stor forskel, men det betragter jeg som forårsaget af de 40 års forskel.

arne_v (11) skrev:

Det blev bare for komplekst og for kludgy med Ada95.

Ironisk nok, så var SPARK's bidrag til Ada faktisk bl.a. at skære kraftigt ned på Ada95. (Jeg ved dog ikke om det kom tilbage til noget der ligner Ada83.)

#14

83 var non-OO.

Og så vidt jeg kan læse finde SPARK i forskellige udgaver til 83 og 95.

Men SPARK folket har også indset at simpelt er godt.

PS. Måske skal der også lige lidt "historie" med til historien: De nye Code Contracts i C#/.NET er helt officielt stjålet fra Eiffel. Microsoft har ikke på nogen måde ændret eller bidraget til konceptet. (Så Microsoft syntes også at Eiffel var interessant.)

Desværre kunne man godt have ønsket at Microsoft havde bidraget lidt. C# er jo modsat Eiffel ikke direkte bygget til dem og jeg savner derfor mulighed for også at kunne definere kontrakter for eks. Events og Exceptions, i C#. (En slags MustImplement(MyEvent) feature.)