Coder Forum

....dann viel spaß mit dem compiler

Die Idee ist blödsinn.
Welche Vorteile ergeben sich daraus? Keine

Und das würde nicht 10 Jahre dauern... Das würde niemals aufhören.
Für jede neue Syntax müsstest du dann wieder am Compiler rumfuschen damit er das korrekt übersetzt.
Und da Softwareentwicklung Teamarbeit ist, würde ich mal ganz stark vermuten, das niemand aus so einem Team
jedes mal Lust hat sich über irgendeine neue Syntax zu informieren.

Mal abgesehen davon, dass sich Codestyles schlechter umsetzen lassen, bei einer immer wechselden Syntax.

Ich glaube nicht das du weist welche Arbeit hinter einem Compiler stecken, bzw. glaube ich nicht das du von der Materie
viel Ahnung hast.


Mfg
nobody

Jeder Programmierer würde dann seine eigene Syntax definieren was ein gigantisches Tohuwabohu zur Folge hätte. Klingt für mich eher nach einem Bug-Feature.

Ganz verschweigen möchte ich meine Ablehnung des Grundsatzes gleichsam meiner Vorredner nicht, aber so richtig verstanden habe dein Beispiel nicht (

Quoted

void convert <char a> to <int &b>

)

Kannst du das nochmal genauer beschreiben, was das genau bedeuten soll ?
Ist denn deine Idee also vielmehr die hypothetische Umsetzung -trotz der c syntax- noch in der imperativen Welt zu finden ?

Ja wie würdest du es finden, wenn jeder seine eigene Sprache (non programmierung) definieren würde, hättest du dann interesse und lust jede dieser, zumindest ein Teil davon, aus der unendlichen Viellfalt zu lernen?
Wohl eher nicht. Zwar nette Idee, aber nicht vollständig durchdacht.

Mfg Rushh0ur

Jetzt gebt ihm doch erstmal die Chance, die Fragen zu beantworten.

Die Idee ist voll beknackt. Aus Gründen die Rushh0ur nannte und eines Logikfehlers, würde ich mal sagen.
Wenn es denn unbedingt eine Funktion für eine Konvertierung sein soll, warum dann void? Damit erreicht man doch dann gar nichts, wenn man den konvertierten Endwert nicht erhält.
Was würde bei dir dann eine "Konvertierungsfunktion" vom Typ INT zurückgeben? °_°
Da wäre doch auch eine Doppelung darin, da man den Typ der Funktion als den Typen deklarieren müsste, der in den zweiten 'Klammern' steht, oder nicht?
Sprich: Eines von beiden muss weg. Beides würde, mehr oder weniger, auf Syntax von schon vorhandenen Sprachen zurückführen.

MfG
Check

PS: So besser?

Quoted from "bidu2004"

was hättet ihr denn für verbesserungsvorschläge??....

ich würde sonderzeichen in funktionen verbieten um den entwickler zu zwingen, so zu programmieren wie man spricht.... die unendliche vielfalt müsste man iwie einschränken.... habt ihr eine idee wie man das umsetzen könnte??
genau aus diesem grund hab ich den post aufgetan.... dass ich vorschläge habe wie ich nicht nen totallen mist zusammenstelle

Mein Vorschlag: lass es.

Wenn du Programmierer zwingen willst so zu coden, wie sie sprechen, dann ergibt dann ebenso ein Choas.
Man braucht etwas "einheitliches", da sich sowas von einem Team besser nutzen lässt.
Da bringts nicht wenn Entwickler A den Code von Entwickler B bekommt, weil er da noch etwas erweitern muss,
und nicht ein Ding versteht.

Und es tut mir leid, aber das wird daraus hinauslaufen das, das der totale mist wird.

Quoted from "Runnable"

Jetzt gebt ihm doch erstmal die Chance, die Fragen zu beantworten.

Ich denke auch, dass es nich sehr konstruktiv ist, die Idee sofort in 1000 Einzelteile zu zerreissen. Richtig, es wurde nach der persönlichen Meinung gefragt, aber falsch ist es, sofort Anwednungsgebiete und Fälle zu suchen warum es schlecht ist. Man kann eine neue Sprache/Syntax auch einfach auf dem Papier entwickeln und allen öffentlich zugänglich machen, vielleicht ist ein Entwickler später dankbar und greift den ein oder anderen Ansatz auf? Man kann auch einfach nur just4fun so etwas realisieren. Wenn man sich die Liste der esoterischen Porgrammiersprachen anschaut, dann findet man dort genug nonsense. Warum sollte man aus Lernzwecken nicht einfach selber was realisieren?

Quoted from "bidu2004"

das ist doch nur ne beispielfunktion....

Aber eine ziemlich schlechte.
Brainf*ck haut am meisten rein, finde ich.

MfG
Check

Quoted from ""Checkmateing""

Brainf*ck haut am meisten rein, finde ich.

Yeah, fand ich auch, ich habe vor einiger Zeit mal einen Brainfuck-Interpreter in Java geschrieben - hat Spass gemacht
Leider gibt es javacore.de nicht mehr, dort hatte ich das gepostet.

Prinzipiell gibt es IMHO (zumindest aus akademischer Sicht) keinen Grund, nicht noch eine neue Sprache zu bauen, es gibt schon über 2000 und keiner wird irgendeine verurteilen, weil sie nicht populär geworden ist.
Der Trend ist ja -kA, vlt schon immer gewesen- nützliche Pattern direkt in die Sprache zu integrieren. Google's Go zB- die Integration von althergebrachten CoRoutinen (Go nennt es go routinen ) == sehr highlevelmässige Unterstützung für parallele Aufgaben. Oder Scala in Hinsicht auf das Decorator Pattern. Oder Erlang mit Blick auf Immutabilität. Ganz prominent C#: events/delegates == Observer Pattern / yield Schlüsselwort == (lazy implementierter) Iterator .......

Was ich sagen will, vlt hat der Threadersteller einfach eine (durch Erfahrung entsatndene) Idee, ein oft gebrauchtes Muster in eine Sprache einfliessen zu lassen.

Quoted from ""bidu""

habt ihr eine idee wie man das umsetzen könnte??

Das ist leichter als du vermutlich denkst; mach dich mal in Richtung/rund um formale Sprachen/Grammatiken, Chromski-Hierarchie, theoretische Informatik schlau, falls du keine Vorlesung darüber gehört hast.
Dann ist es mit einigen abstrakt formulierten Regeln ganz gut möglich, einen Compiler zu bauen.
-> yacc (*.ix) / bison (M$) sind zwei von s.g. compiler compilern

IMHO das Schwierigste bei der Pflege und Weiterentwicklung von Sprachen ist das Problem, Erweiterungen und Verbesserungen so einzubauen, dass jede Folgeversion abwärtskompatibel und legacy Code compilierbar bleibt. Diese Meinung beruht aber nur auf Beobachtung (Java/C#) und nicht auf Erfahrung.