The Go Programming Language [Archiv]

Pinoccio

2009-11-11, 17:36:08

hört sich interessant an wobei mich einige dinge doch etwas verwundern.
hab ich das richtig verstanden, dass es weder überladung noch generizität gibt?Aus den tiefen der FAQ: Why does Go not support overloading of methods and operators? (http://golang.org/doc/go_lang_faq.html#overloading)

the := declare-and-initialize construct
Ohje, ich bekomm ja jetzt schon Heulkrämpfe, wenn ich mal zwischen Maple (Zuweisung mit :=) und MATLAB (Zuweisung mit =) wechsle. Jetzt aber := und = als verscheidene Zuweisungsoperatoren in einer Sprache? Go, wir werden wirklich keine Freunde.

A related detail is that, unlike in C, int and int64 are distinct types even if int is a 64-bit type. The int type is generic; if you care about how many bits an integer holds, Go encourages you to be explicit.
Klingt für mich auch nicht sonderlich überzeugend.

mfg

samm

2009-11-11, 18:17:11

Wuah, neben der Syntax finde ich auch die gewählte Form von "OO" bedenklich. in Go a type automatically satisfies any interface that specifies a subset of its methods.Nehmen wir mal das in der FAQ genannte Beispiel voninterface (io.Writer) representing a single method (Write), d.h. alles, was eine "Methode" Write (wieso gross geschrieben?) hat, ist automatisch ein io.Writer - dabei ist nirgends irgendeine Form von Kontrakt festgelegt. Natürlich ist das auch in Sprachen mit interfaces nicht der Fall, aber dort muss man immer noch angeben, welche Interfaces implementiert werden, und verpflichtet sich selbst, diese auch richtig zu verwenden.

Pinoccio

2009-11-11, 18:30:07

(wieso gross geschrieben?)Aus dem Tutorial (http://golang.org/doc/go_tutorial.html#tmp_17):
09 func main() {
10 fmt.Printf("Hello, world; or Καλημέρα κόσμε; or こんにちは世界\n");
11 }
Scheint uneinheitlich zu sein.

mfg

Tesseract

2009-11-11, 18:33:19

Wuah, neben der Syntax finde ich auch die gewählte Form von "OO" bedenklich.

warum? subtyping kannst du allein durch inheritence sowieso nicht sicherstellen.
conditions usw. muss man sowieso per comment festlegen.
in dem fall fehlt also eher die trügerische sicherheit.

Gast

2009-11-11, 18:50:32

"Interfaces are also used where C++ uses templates." -> no go (ui, der war flach...)

Shink

2009-11-11, 19:01:19

Templates und Exceptions (noch so ne unwichtige Nebensache anscheinend) werden ja anscheinend nachgeliefert (wenn es wirklich sein muss).

Die Sache mit der Vererbung find ich so dämlich eigentlich nicht. Man wohl einiges nicht machen damit; vielleicht ist das aber gar nicht so dumm. Kann mir das gerade nicht vorstellen...

Kann mir irgendwie nicht erklären warum gerade Google mit sowas kommt. Wollen die damit ihr OS schreiben?

The_Invisible

2009-11-11, 19:07:54

irgendwie überflüssig, was bringts mir wenn ich c/c++ "kann" (ich weiß, keiner kann das :D))?

mfg

aths

2009-11-11, 19:37:15

Bietet diese Sprache irgendeinen Vorteil, den D nicht hat?

Der_Donnervogel

2009-11-11, 20:36:18

Bietet diese Sprache irgendeinen Vorteil, den D nicht hat?Auf den ersten Blick nur einen großen:

Sie kommt von Google

Steckt so ein großer Konzern dahinter sind die Chancen größer, dass die Sprache eine gewisse Relevanz erreicht.

samm

2009-11-11, 21:30:31

Kann mir irgendwie nicht erklären warum gerade Google mit sowas kommt. Wollen die damit ihr OS schreiben?Browser werden immer OS-ähnlicher ;)

Tesseract: Stimmt schon, ausser bei Sprachen, wo Kontrakte explizit formuliert werden (gibt's da überhaupt was? Eiffel?) Dennoch ist es immerhin ein Schritt mehr, der einen Entwickler u.U. zum überlegen bringen könnte. Natürlich sollte man sich das schon vor der Implementation überlegt haben.... ;)

Coda

2009-11-11, 21:52:07

Ich weiß ja nicht. Meine Prognose ist ja, dass die nächste "große" Programmiersprache zumindest funktionale Anteile haben muss, denn das ist ein enormer Vorteil bei Parallelisierung.

Schaut euch mal F# an. Dahin geht die Reise. OCAML kann man auch schon ewig zu sehr performantem native code kompilieren. Das wird durch Microsoft jetzt sehr breit Verwendung finden.

Außerdem halte ich die Lücke zwischen C/C++ und .NET/Java für zu klein um da noch eine solche Sprache zu etablieren. Das gilt auch für D.

Das finde ich ziemlich häßlich.
Syntax kann nie hässlich sein, nur ungewohnt ;)

Bietet diese Sprache irgendeinen Vorteil, den D nicht hat?
Es wird eher zu irgendeiner Relevanz kommen.

Exxtreme

2009-11-11, 22:27:50

Sehe ich auch so. Funktionale Programmiersprachen wie Scala oder F# werden eine grössere Bedeutung bekommen denn der Trend geht halt zur Parallelisierung. Ich glaube nicht ob Google die Marktmacht hat eine weitere C++-ähnliche Sprache durchzusetzen. Welche Nische soll Go denn füllen?

Gast

2009-11-11, 22:34:01

Ich weiß ja nicht. Meine Prognose ist ja, dass die nächste "große" Programmiersprache zumindest funktionale Anteile haben muss, denn das ist ein enormer Vorteil bei Parallelisierung.

Schaut euch mal F# an. Dahin geht die Reise. OCAML kann man auch schon ewig zu sehr performantem native code kompilieren. Das wird durch Microsoft jetzt sehr breit Verwendung finden.
Da stimme ich soweit zu, man sollte aber vielleicht noch das funktional/OO-Gegenstück auf der JVM Seite erwähnen, nämlich Scala. Die Sprache ist auch sehr performant auf der JVM (mehr oder weniger genau so schnell wie Java) und Microsoft will wohl höstselbst einen aktuellen .NET Compiler für sie sponsern.

Coda

2009-11-11, 23:45:32

Naja, hab's mir jetzt mal angeschaut. Die goroutines sind ganz interessant, aber im Prinzip ähnlich wie z.B. Grand Central Dispatch. Das kann man mit C++0x-Lambdas + Library wohl auch ziemlich ähnlich erreichen. Erinnert mich auch stark an Erlang.

Was gut ist, sind die kurzen Kompilierzeiten. Da wurde damals bei C einfach ein fundamentaler Fehler gemacht mit den Headern, und das schleppt C++ heute immer noch mit sich rum. Precompiled Header helfen da aber sehr gut dagegen. Java und C# sind da soweit ich weiß auch ähnlich schnell.

Das OOP-Modell ohne Hierarchie ist interessant. Hat sicher aber auch seine Nachteile.

Da stimme ich soweit zu, man sollte aber vielleicht noch das funktional/OO-Gegenstück auf der JVM Seite erwähnen, nämlich Scala. Die Sprache ist auch sehr performant auf der JVM (mehr oder weniger genau so schnell wie Java) und Microsoft will wohl höstselbst einen aktuellen .NET Compiler für sie sponsern.
Von Scala hab ich auch schon gehört, es aber noch nicht angeschaut.

Ich muss mich unbedingt mal in diese Sachen einarbeiten, was ich bisher von F# gesehen habe war wirklich beeindruckend. Gegen die Eleganz und Ausdrucksstärke des Codes sehen die etablierten Sprachen wirklich schlecht aus.

Exxtreme

2009-11-12, 09:45:13

Ich könnte mir vorstellen, daß Google diese Sprache per Android pushen wird. Genauso wie Apple es mit Objectiv-C gemacht hat.

Gast

2009-11-12, 11:55:36

Welche Nische soll Go denn füllen?
Eine Nische wollen sie glaub ich nicht füllen. Wenn es nicht nur der eigene Anwendungszweck ist, könnte es eher auf Verdrängung von anderen im Markt hinauslaufen.

Exxtreme

2009-11-12, 12:22:10

Eine Nische wollen sie glaub ich nicht füllen. Wenn es nicht nur der eigene Anwendungszweck ist, könnte es eher auf Verdrängung von anderen im Markt hinauslaufen.
Eine neue Sprache, die eine grössere bestehende Nische nicht bedient wird es IMHO verdammt schwer haben. Google könnte mittels Android eine Nische erschaffen wenn sie wollten. Apple hat es beim iPhone auch geschafft und ObjC gewinnt stark an Beliebtheit.

Und bei Go sehe ich jetzt keinen Bereich wo es definitiv große Vorteile ggü. anderen Sprachen gibt. Oder anders ausgedrückt: ich sehe nicht wo Go bestimmte Problematiken sehr viel besser löst als z.B. C.

Pinoccio

2009-11-12, 12:26:51

Eine Nische wollen sie glaub ich nicht füllen. Wenn es nicht nur der eigene Anwendungszweck ist, könnte es eher auf Verdrängung von anderen im Markt hinauslaufen.Mal sehen, was es verdrängt. Ich bin gespannt.
In dieser Folie (pdf) (http://golang.org/doc/go_talk-20091030.pdf) heißt es auf Seite 6:
No new major systems language in a decade.
Zusammen mit dem, was dort noch so alles steht, glaube ich schon, daß Google den Anspruch hat, mit Go etwas von Bedeutung zu schaffen, also mehr als nur eine Nische zu füllen.

Die Folie ist insgesammt recht erhellend. Scheint eine Menge Gehirnschmalz in Go zu stecken.

Eine neue Sprache, die eine grössere bestehende Nische nicht bedient wird es IMHO verdammt schwer haben. Google könnte mittels Android eine Nische erschaffen wenn sie wollten. Apple hat es beim iPhone auch geschafft und ObjC gewinnt stark an Beliebtheit.

Und bei Go sehe ich jetzt keinen Bereich wo es definitiv große Vorteile ggü. anderen Sprachen gibt. Oder anders ausgedrückt: ich sehe nicht wo Go bestimmte Problematiken sehr viel besser löst als z.B. C.Siehe Folie (http://golang.org/doc/go_talk-20091030.pdf): Go scheint einiges besser machen zu wollen als C. Ob es gelingt (noch ist Go ja ganz am Anfang) werden wir wohl abwarten müssen.

sOT:
Was gut ist, sind die kurzen Kompilierzeiten. [...] Java und C# sind da soweit ich weiß auch ähnlich schnell.Ich kann mich noch an meine ersten JAVA-Schritte erinnern, da hatten wir Kompilierzeiten um zwei Minuten, für kleine Programme! (Möglicherweise ein wenig den nicht mehr ganz aktuellen Schulrechnern damals geschuldet.) Syntax kann nie hässlich sein, nur ungewohnt ;)Das mag für die neuen Frisuren von Lebenspartnerinnen gelten: Schatz, sie ist ... äh ... ungwohnt. :freak:
Aber stimmt natürlich, wobei ich Sprachen, die es darauf anlegen (z. B. Brainfuck) durchaus wirklich häßlich finde.

mfg

Exxtreme

2009-11-12, 13:05:44

Siehe Folie (http://golang.org/doc/go_talk-20091030.pdf): Go scheint einiges besser machen zu wollen als C. Ob es gelingt (noch ist Go ja ganz am Anfang) werden wir wohl abwarten müssen.

Ausser "Wir machen alles einfacher, schneller und balastfreier" sehe ich da nichts Weltbewegendes, sry. Sollte Go wirklich alles so vereinfachen/beschleunigen, daß sich das spürbar im Betriebsergebnis auswirkt dann hat es durchaus eine Chance. Diesen Anspruch hatten aber auch sehr viele Sprachen davor auch. Nur leider haben sie kaum eine Bedeutung.

Und mit Nischen meine ich bestimmte Ansprüche an die Software, die sich mit den bestehenden Sprachen/Frameworks nur sehr mühsam und teuer umsetzen lassen. Z.B. haben funktionale Sprachen Vorteile bei Parallelisierung. Java + Framework deckt die Nische der Plattformunabhängigkeit ab und man bekommt noch Robustheit gegen Bufferoverflows und Memoryleaks mit ins Paket was die Kosten beträchtlich senken kann. Bei Go sehe ich derartige Vorteile eben nicht.

Yavion

2009-11-13, 00:17:15

Also ich finde schon dass es so etwas wie hässliche Syntax gibt.
Z.B finde ich die in heutigen C-artigen Sprachen übliche Zuweisung wie i=1 völlig albern, weil ein Gleichheitszeichen im Grunde eine symetrische Sache sein sollte, dennoch meckert der Compiler, wenn ich schreibe 1=i.
Auch Dinge wie i++ oder i+=1 ist zwar heute so gewöhnt, dass es keinen mehr aufregt aber im Grunde ist es Quatsch.
Da macht es Go schon besser, wie damals Pascal i:=1.

Go ist für mich yet another c-style language. Ich habe kein Problem damit, weil dieser Syntax den meisten, mich eingeschlossen, wohl am geläufigsten ist aber ich brauche es nicht wirklich.

Dieses F# werde ich mir mal ansehen. Ich habe heute in diesem Zusammenhang erst von Dingen wie CMUCL gelesen und war recht überascht, dass sich selbst heute noch Leute mit Lisp-Compilern rumschlagen, offenbar sogar mit bemerkenswerten Ergebnissen.

mrt

2009-11-13, 00:44:37

Mir erschließt sich der Sinn von Go nicht so ganz, ich tu mir allerdings bei .net schon schwer.

P.S.: Java + Scala ist sehr nett, solltet ihr euch anschaun ;)

Der_Donnervogel

2009-11-13, 20:55:12

Also ich finde schon dass es so etwas wie hässliche Syntax gibt.Ich finde, dass "hässlich" bei Syntax das falsche Wort ist. Was es aber gibt ist "umständlicher" und "undurchsichtiger" Syntax.
Z.B finde ich die in heutigen C-artigen Sprachen übliche Zuweisung wie i=1 völlig albern, weil ein Gleichheitszeichen im Grunde eine symetrische Sache sein sollte, dennoch meckert der Compiler, wenn ich schreibe 1=i. Auch Dinge wie i++ oder i+=1 ist zwar heute so gewöhnt, dass es keinen mehr aufregt aber im Grunde ist es Quatsch.
Da macht es Go schon besser, wie damals Pascal i:=1.Das ist genau so viel oder weniger Quatsch wie jede andere syntaktische Vereinbarung. Entscheidend ist dass die Logik in sich schlüssig ist. Ich könnte auch Beispiele aus der Mathematik bringen wo Symbole verschiedene Bedeutungen haben können, je nachdem in was für einem Kontext sie eingesetzt werden. Genau so ist das auch bei der Programmierung zu sehen. In diesem Kontext ist eben ein "=" sozusagen nur ein "ist" und nicht ein "ist gleich". Auch das mit i++ schlägt in die selbe Kerbe. Das ist eine Vereinbarung, dass der Operator "++" die Variable um eins erhöht. Wenn man das mal z.B. mit dem Betragsoperator aus der Mathematik vergleicht. In wie weit ist ein i++ mehr Quatsch als ein |a| in der Mathematik?

patermatrix

2009-11-13, 21:05:29

Wenn man das mal z.B. mit dem Betragsoperator aus der Mathematik vergleicht. In wie weit ist ein i++ mehr Quatsch als ein |a| in der Mathematik?
Der Betragsoperator hat aber durchaus eine grafische Interpretation, nämlich wird die Zahl quasi "isoliert" und das Vorzeichen abgetrennt. Schwieriger wirds dann bei ||a|| :wink:

i:=1 finde ich unsinnig, da es umständlicher zu schreiben ist. Ausserdem haben wir uns doch jahrelang das if(a == true) angewöhnt ;-)

Sephiroth

2009-11-13, 21:44:03

Der Betragsoperator hat aber durchaus eine grafische Interpretation, nämlich wird die Zahl quasi "isoliert" und das Vorzeichen abgetrennt. Schwieriger wirds dann bei ||a|| :wink:

i:=1 finde ich unsinnig, da es umständlicher zu schreiben ist. Ausserdem haben wir uns doch jahrelang das if(a == true) angewöhnt ;-)
wo sie ein zeichen einsparen, da führen sie woanders eins wieder ein *g*

aber foo := bar ist ja jetzt keine so dramatische Umstellung (zumal man bei neuen/anderen Sprachen sich immer an den Syntax gewöhnen muss) ... wer Pascal, Modula, Ada, VHDL etc. kennt, der kennt auch das ;)

Von F# und Scala hab ich noch nie was gehört - mal anschauen. :)

p.s.
durch Google mag Go mehr Popularität als D erreichen aber es wird sicher nur ein Nischenprodukt

Der_Donnervogel

2009-11-14, 01:40:14

Der Betragsoperator hat aber durchaus eine grafische Interpretation, nämlich wird die Zahl quasi "isoliert" und das Vorzeichen abgetrennt. Schwieriger wirds dann bei ||a|| :wink:Wenn man es so betrachtet, kann man es so sehen. So viel ich mich erinnere ist der Betrag aber nicht so definiert, dass er das Vorzeichen einfach abtrennt. Stattdessen ergänzt er bei negativen Zahlen ein weiteres Minus, sodass das Ergebnis immer eine positive Zahl ist.:

( x falls x >= 0
|x| = {
( -x falls x < 0

Eigentlich habe ich den Betrag aber nur deshalb als Beispiel genommen, da die Betragstriche praktischer Weise auf der Tastatur zur Verfügung stehen. Da musste ich nicht versuchen ASCII-Art zu basteln um die mathematischen Symbole irgendwie darzustellen wie jetzt bei der Definition vom Betrag. ;)
wo sie ein zeichen einsparen, da führen sie woanders eins wieder ein *g*Ja das bringt wirklich nicht viel. Wenn sie wenigstens die {} Klammern entsorgt hätten. Die finde ich bei den ganzen Sprachen immer am lästigsten. Alt Gr+7 und Alt Gr+0 sind ziemlich ungünstig für ein Sprachelement das so oft vorkommt. Auch wenn ich schon länger primär mit Java und C# arbeite bin ich diesbezüglich immer noch ein Fan von Basic. Diesen "sprechenden" Code finde ich angenehmer und besser lesbar als die doofen Klammern. Vor allem bei den End-Statements. Wenn man da mehrere Klammern untereinander hat, weiß man entweder nicht was die jetzt schließen oder man muss sie kommentieren und dann kann man gleich entsprechende Kommandos schreiben.

Coda

2009-11-14, 01:55:44

Deshalb verwendet man ja auch englische Tastatur zum programmieren, da ist { direkt drauf :tongue:

Tesseract

2009-11-14, 02:08:16

also ich finde gerade die {}-strukturierung an den C-artigen sprachen viel übersichtlicher als so begin-end-wall-of-text zeug.
mag aber auch daran liegen, dass ich ein sehr visueller mensch bin der hinter eingerücktem code primär die blockstrucktur und weniger die zeichen selbst sieht.

The_Invisible

2009-11-14, 09:58:03

dafür gibts ja python.

weiß aber nicht was da besser sein soll wenn beim hin- und herkopieren auf einmal tabs/leerzeichen miteinander vertauscht werden und nix mehr geht :freak:

mfg

Monger

2009-11-14, 10:53:40

Auch wenn ich schon länger primär mit Java und C# arbeite bin ich diesbezüglich immer noch ein Fan von Basic. Diesen "sprechenden" Code finde ich angenehmer und besser lesbar als die doofen Klammern.
Dito.

Außerdem: man "schreibt" ja selten solchen Code, sondern die Intellisense übernimmt das Gros der Codevervollständigung. Die Mnemonik ist aber um Welten besser, wenn die Sonderzeichen auf ein Minimum reduziert werden. Für Wörter und Sätze haben wir nunmal ein gutes Gedächtnis - weil wir sie auch ausprechen können. Sonderzeichen sind ganz schlecht zu merken und zu lesen.

Yavion

2009-11-14, 15:50:46

Deshalb verwendet man ja auch englische Tastatur zum programmieren, da ist { direkt drauf :tongue:

Ja. Gerade auf deutschen Notebooktastaturen nerven die [] und{}. In der Zeit für die Fingerverrenkung kann ich genau so gut ein end, rof oder fi schreiben. Und gesünder ist es wohlmöglich auch.

Der_Donnervogel

2009-11-14, 16:40:38

Deshalb verwendet man ja auch englische Tastatur zum programmieren, da ist { direkt drauf :tongue:Sie sind dort besser erreichbar, aber direkt sind sie dort auch nicht erreichbar. Man braucht statt Alt Gr auch dort Shift um an die geschwungenen Klammern zu kommen. Für mich kommt eine englische Tastatur aber nicht in Frage, da ich dann mein 10 Finger-System nicht mehr verwenden kann. Es ist unwahrscheinlich irritierend, wenn ein Teil der Zeichen wo anders sind. Da mache ich massenhaft Tippfehler beim Programmieren. Ich verwende deshalb auch ausschließlich wirklich deutsche Tastaturen, und keine angepassten englischen. Also nur die wo auch die "<" Taste links zwischen Shift und "Y" liegt und nicht dort nur eine extra große Shift-Taste zu finden ist.also ich finde gerade die {}-strukturierung an den C-artigen sprachen viel übersichtlicher als so begin-end-wall-of-text zeug.
mag aber auch daran liegen, dass ich ein sehr visueller mensch bin der hinter eingerücktem code primär die blockstrucktur und weniger die zeichen selbst sieht.Da hängt vieles mit persönlichem Geschmack zusammen. Ich vermute auch es ist wichtig, mit welcher Sprache man das Programmieren begonnen hat. Ich habe seinerzeit mit BASIC begonnen. Ich will nicht ausschließen, dass wenn ich damals mit C begonnen hätte, mir die C-Syntax besser gefallen würde. Viele dieser Dinge sind sowieso mehr ästhetische Fragen die sich objektiv kaum beantworten lassen. Ein gutes Beispiel ist da auch die ewige Frage ob man öffnende { auf der selben Zeile schreiben soll wie das Kommando (Java) oder aber in einer extra Zeile (C#).
Für Wörter und Sätze haben wir nunmal ein gutes Gedächtnis - weil wir sie auch ausprechen können. Sonderzeichen sind ganz schlecht zu merken und zu lesen.Bei mir geht es da nicht mal ums Gedächtnis, sondern ums Denken. Wenn ich Code schreibe oder lese, dann muss ich den ja "transformieren". Ich muss aus meinen Gedanken ja einerseits sozusagen den Code "compilieren" den ich schreibe, bzw. den gelesenen Code "interpretieren". Das geht mir leichter/angenehmer von der Hand wenn das ganze näher an der natürlichen Sprache dran ist und man das ganze sozusagen als "Sätze" formulieren kann. Um das mal an einem Beispiel zu verdeutlichen:

Der Gedanke ist: "Wenn a größer 5 ist dann wars ein Überlauf, also zurück auf 5 setzen, sonst einfach 1 dazu zählen"

If a > 5 Then
a = 5
Else
a = a + 1
End If

if (a > 5) {
a = 5;
} else {
a++;
}

a = (a > 5 ? 5 : a + 1);

Aus meiner Sicht ist Variante 1 am besten lesbar, da sich die praktisch wie ein (englischer) Satz lesen lässt. Beim trinären Operator (Variante 3) muss ich dagegen zwei mal hinsehen um zu ermitteln, was denn der macht. Aber auch bei Variante 2 sind einige Sachen drinn die eher ablenken aber nicht inhaltlich etwas beitragen. z.B. die () beim If oder auch die ; um das Statement zu beenden. Da sie aber wichtig sind kann man sie nicht einfach ignorieren. Natürlich kann man auch Variante 2 gut lesen, aber Variante 1 finde ich noch besser lesbar.

Tesseract

2009-11-14, 17:12:40

Ich vermute auch es ist wichtig, mit welcher Sprache man das Programmieren begonnen hat. Ich habe seinerzeit mit BASIC begonnen. Ich will nicht ausschließen, dass wenn ich damals mit C begonnen hätte, mir die C-Syntax besser gefallen würde.

ich hab auch mit basic begonnen und fand die C-syntax trotzdem auf anhieb wesentlich besser lesbar.

Viele dieser Dinge sind sowieso mehr ästhetische Fragen die sich objektiv kaum beantworten lassen. Ein gutes Beispiel ist da auch die ewige Frage ob man öffnende { auf der selben Zeile schreiben soll wie das Kommando (Java) oder aber in einer extra Zeile (C#).
ich hab z.B. mit einer neuen zeile für jedes { begonnen weil es meiner meinung nach die "schönere" variante war. allerdings hab ich später auf { in der selben zeile umgestellt weil es den code einfach wesentlich kompakter und kürzer macht und komplexer code dadurch imho übersichtlicher belibt.

aus diesem grund würde ich dein codebeispiel überhaupt so schreiben:

if (a > 5) a = 5;
else a++;

vergleich z.B. mal diese beiden schreibweisen auf ihre kompaktheit:

int lol(int a) {
for (int i = 0; i < a; i++) {
doSomething1(a);
doSomething2(i);
if (i > 2) doSomething3();
}
if (a < 5) return a;
else return 0;
}

int lol2(int a)
{
for (int i = 0; i < a; i++)
{
doSomething1(a);
doSomething2(i);
if (i > 2)
{
doSomething3();
}
}
if (a < 5)
{
return a;
}
else
{
return 0;
}
}

Der_Donnervogel

2009-11-14, 19:47:07

allerdings hab ich später auf { in der selben zeile umgestellt weil es den code einfach wesentlich kompakter und kürzer macht und komplexer code dadurch imho übersichtlicher belibt.

aus diesem grund würde ich dein codebeispiel überhaupt so schreiben:

if (a > 5) a = 5;
else a++;
Kompaktheit ist oft gut. Das ist mir aber schon fast zu kompakt, da man optisch die Struktur nicht mehr so gut sieht. Außerdem ist es potentiell gefährlich die Blockklammern weg zu lassen. Falls man später was im else-Teil ergänzt und vergisst die zu machen hat man ein Problem. Wenn ich kompakt programmiere, dann gehe ich immer gleich in die Vollen und nehme bei sowas trinäre Operatoren, z.B:
public int min (int a, int b) {
return a < b ? a : b;
}
Ansonsten nehme ich die lange Variante mit Blockklammern.

Tesseract

2009-11-14, 20:50:04

Falls man später was im else-Teil ergänzt und vergisst die zu machen hat man ein Problem.
wenn man es in der selben zeile hat wie bei meinem beispiel sollte ein derartiger fehler eigentlich nicht vorkommen. ist mit jedenfalls noch nie passiert.

Der_Donnervogel

2009-11-14, 21:23:03

wenn man es in der selben zeile hat wie bei meinem beispiel sollte ein derartiger fehler eigentlich nicht vorkommen. ist mit jedenfalls noch nie passiert.Murphys Gesetz (http://de.wikipedia.org/wiki/Murphys_Gesetz) ;)

Das ist mir auch noch nie passiert. Was ich aber schon mal hatte, ist dass sich ein Strichpunkt irgendwo hin geschmuggelt hatte, wo er nicht hin gehört. Etwas in der Art:
if (a > 5); a = 5;
Solche Fehler zu suchen kann "lustig" sein. ;D

Das Problem bei all den Sachen ist, dass es normalerweise nicht passiert. Es genügt aber oft eine kleine Unaufmerksamkeit oder ein Konzentrationsfehler und schon hat man so einen Fehler eingebaut. Ich programmiere deshalb so, dass ich möglichst viele Fehlerquellen vermeide, selbst wenn sie nur selten vorkommen.

Novox

2009-11-14, 22:49:39

Ein gutes Beispiel ist da auch die ewige Frage ob man öffnende { auf der selben Zeile schreiben soll wie das Kommando (Java) oder aber in einer extra Zeile (C#).

Anders Hejlsberg sieht das auch nicht ganz so eng (http://channel9.msdn.com/pdc2008/TL16/) (z.B. bei 27 Min.) :wink:

Controller Khan

2009-11-14, 23:02:37

Wenn sie wenigstens die {} Klammern entsorgt hätten. Die finde ich bei den ganzen Sprachen immer am lästigsten. Alt Gr+7 und Alt Gr+0 sind ziemlich ungünstig für ein Sprachelement das so oft vorkommt. Auch wenn ich schon länger primär mit Java und C# arbeite bin ich diesbezüglich immer noch ein Fan von Basic. Diesen "sprechenden" Code finde ich angenehmer und besser lesbar als die doofen Klammern. Vor allem bei den End-Statements. Wenn man da mehrere Klammern untereinander hat, weiß man entweder nicht was die jetzt schließen oder man muss sie kommentieren und dann kann man gleich entsprechende Kommandos schreiben.
Mit den {} haben sich die Deutschen selbst ins knie geschossen.
Auf den meisten Keyboard layouts sind die sehr gut erreichbar, selbst in der Schweiz.

Zur Sprache selber: interessant sind die Frameworks/IDE dazu.
Da find ich .Net mit C# am besten. Pascal für .Net gibts auch.

Bei Go fehlt mir das Killerfeature, das mich überzeugt, das Ding ist wohl für Google selber gedacht.

Marscel

2009-11-14, 23:29:48

Mit den {} haben sich die Deutschen selbst ins knie geschossen.

Muss mir entgangen sein, jedenfalls hab ich mich noch nie bewusst während des Schreibens daran gestört. ;)

Kinman

2009-11-16, 13:48:51

ich hab z.B. mit einer neuen zeile für jedes { begonnen weil es meiner meinung nach die "schönere" variante war. allerdings hab ich später auf { in der selben zeile umgestellt weil es den code einfach wesentlich kompakter und kürzer macht und komplexer code dadurch imho übersichtlicher belibt.

vergleich z.B. mal diese beiden schreibweisen auf ihre kompaktheit:

...

bei mir siehts so aus:

int lol2(int a)
{
for (int i = 0; i < a; i++)
{
doSomething1(a);
doSomething2(i);

if (i > 2) doSomething3();
}

if (a < 5) return a;
else return 0;
}

Somit mir persönlich kompakt genug, aber trotzdem die { in einer eigenen Zeile.

mfg Kinman

Shink

2009-11-16, 14:44:27

Somit mir persönlich kompakt genug, aber trotzdem die { in einer eigenen Zeile.
Oh Mann, was ist nur aus meinem Thread geworden.:rolleyes:

Muss das hier sein? Schreibt euch gefälligst einen DSL-Compiler wenn ihr so unglaublich heiß auf eine bestimmte Art von Bezeichnern seit.

Wenn ihr mit der vorgeschlagenen Formatierungskonvention nicht zurechtkommt macht euch eben einen 2-Richtungs-Autoformatter.

Das sind alles keine Argumente für oder gegen eine Sprache. Ich kann mir nicht vorstellen das deshalb irgendeine Sprache erfolgreich war oder auch nicht.

Monger

2009-11-16, 21:02:09

Um vielleicht das Thema wieder auf die Spur zu bringen:

Ich finde es irgendwie schon witzig, wie jede größere Firma ihre eigenen Sprachdialekte einführt. Ich hab bei uns wenigstens vier kleinere, assemblyartige Sprachen gesehen, die sich eben in Nuancen vom üblichen Industriestandard abheben.
Und wozu das ganze? Genau aus dem selben Grunde weshalb es auch bayrisch und pfälzisch gibt: Um sich abzuheben und abzugrenzen.

Anders kann ich es mir kaum erklären, dass es dermaßen viele C/C++ Varianten gibt. Der Wille in der Industrie zu einheitlichen, möglichst effizienten und flexiblen Standards scheint mir ohnehin eher gering.

Ich hab nur mal so ein bißchen überflogen was auf der Webseite zu Go steht. Einige interessante Features dabei. Einiges sicherlich nützliches, einiges fragwürdiges... aber alles andere als ein Paradigmenbruch. Ich sehe da nichts, was zu nennenswert klarerem, besseren Code führen würde. Definitiv nichts, was für mich einen Umstieg rechtfertigen würde.

Ich persönlich glaube nicht, dass wir noch einen C++ Konkurrenten brauchen - aber ich bin ja ohnehin Java/.NET Fanboy! :tongue:

Demirug

2009-11-16, 22:14:13

Ich persönlich glaube nicht, dass wir noch einen C++ Konkurrenten brauchen - aber ich bin ja ohnehin Java/.NET Fanboy! :tongue:

Vor allem da C++ eine sterbenden Sprache ist. Die Entwicklungs und Wartungskosten für ein größeres in C++ geschriebenes Projekt sind einfach viel zu groß. Das ist nicht mehr tragbar.

Gast

2009-11-17, 01:20:30

bei mir siehts so aus:

...
if (i > 2) doSomething3();
...
if (a < 5) return a;
else return 0;
...

Somit mir persönlich kompakt genug, aber trotzdem die { in einer eigenen Zeile.

mfg Kinman

Kompakt ja, aber schlecht lesbar und vorallem kann man schnell Fehler in den Code bauen, wenn man ihn so schreibt. Ich würde bei bedingten Audrücken immer mit {} abeiten.

Gast

2009-11-17, 01:31:57

Vor allem da C++ eine sterbenden Sprache ist. Die Entwicklungs und Wartungskosten für ein größeres in C++ geschriebenes Projekt sind einfach viel zu groß. Das ist nicht mehr tragbar.

Welche Zeitspanne ist denn für das Sterben von C++ nach deiner Meinung vorgesehen? Schön, dass es Leute wie dich gibt, die absolut ungewisse Dingen, mit einer derartigen Selbstsicherheit vortragen können, als seien sie schon morgen Gewissheit und unabdingabr. Aber ich glaube Ähnliches hat man auch von COBOL behauptet.

Coda

2009-11-17, 01:35:33

C++ ist schon länger auf dem absteigenden Ast. Das ist nun wirklich kein Geheimnis. COBOL ist auch nur noch ein Zombie.

Was mich wirklich immer wieder erschreckt, ist das C immer noch die meistbenutzte Programmiersprache überhaupt ist. Und wenn C++ für große Projekte nicht geeignet ist, kann es C ja wohl erst recht nicht sein X-D

Exxtreme

2009-11-17, 09:25:30

Welche Zeitspanne ist denn für das Sterben von C++ nach deiner Meinung vorgesehen? Schön, dass es Leute wie dich gibt, die absolut ungewisse Dingen, mit einer derartigen Selbstsicherheit vortragen können, als seien sie schon morgen Gewissheit und unabdingabr. Aber ich glaube Ähnliches hat man auch von COBOL behauptet.
COBOL "lebt" nur noch deshalb weil bestehende in COBOL geschriebene Anwendungen auch gepflegt sein müssen. Große Projekte werden in COBOL nicht mehr frisch programmiert.

Und genauso wird es früher oder später C++ ergehen.

Gast

2009-11-17, 21:08:12

Und genauso wird es früher oder später C++ ergehen.

Aber was kommt danach? Nennt mal eine ernst zu nehmende Alternative im Software-Produktsegment. Klar, bei kundenspezifischen Projekten ist C++ kein Thema. Dort gibt es Java und .NET. Aber wie schaut es bei der Entwicklung von betriebssystemnaher Software aus? Oder will irgendwer Photoshop als Java App haben? Ich denke nicht. Es sprechen nachwievor tausend Gründe gegen Java oder .NET. Java wäre eine echte Konkurrenz, wenn mal jemand endlich ein Java OS herausbringen würde.

Monger

2009-11-17, 21:23:19

Aber wie schaut es bei der Entwicklung von betriebssystemnaher Software aus? Oder will irgendwer Photoshop als Java App haben?

Was bezeichnest du als "betriebssystemnah"?

Bei Java sehe ich das größte Problem darin, dass sie sich partout auf Plattformunabhängigkeit festnageln, deshalb sieht es mit Windows-spezifischen APIs dort eher mau aus.

Aber ich sehe keinen Grund, warum .NET nicht für praktisch alle Bereiche der Anwendungsentwicklung taugen sollte. Selbst User-Mode Treiber und Services sind machbar. Teilweise n bissl frickelig, weil der Übergang in den Unmanaged Code mitunter etwas holprig ist, aber auch nicht holpriger als natives C++.

Damit bleibt eigentlich nicht mehr viel. Eigentlich nur der Windows Kernel, und die paar Kernel Mode Treiber. Davon sind weltweit vielleicht noch ein paar tausend Entwickler betroffen.

Dass so viele andere Plattformen jenseits von Windows noch dermaßen sklavisch an den alten Sprachen festhalten, ist ja deren Problem.

Exxtreme

2009-11-17, 21:50:34

Aber was kommt danach? Nennt mal eine ernst zu nehmende Alternative im Software-Produktsegment. Klar, bei kundenspezifischen Projekten ist C++ kein Thema. Dort gibt es Java und .NET. Aber wie schaut es bei der Entwicklung von betriebssystemnaher Software aus? Oder will irgendwer Photoshop als Java App haben? Ich denke nicht. Es sprechen nachwievor tausend Gründe gegen Java oder .NET. Java wäre eine echte Konkurrenz, wenn mal jemand endlich ein Java OS herausbringen würde.
Was spricht denn gegen Photoshop als Java-Anwendung? Die Startzeit könnte bissl lang sein. Andererseits gibt es bereits Java-Compiler, die ein Binary backen.

Und betriebssystemnahe Software aka Treiber machen jetzt nicht so einen riesigen Teil der Software aus. Die kann man ruhig weiterhin in C/C++ lassen.

Demirug

2009-11-17, 22:16:06

Was spricht denn gegen Photoshop als Java-Anwendung? Die Startzeit könnte bissl lang sein. Andererseits gibt es bereits Java-Compiler, die ein Binary backen.

Habe ich auch schon für MSIL gesehen. Das lustige war das die „kompilierte“ MSIL Testprogramme schneller als die C++ Lösungen für die gleichen Probleme waren. Das dürfte allerdings primär an dem besseren Backend bei dem MSIL 2 Binary Compiler gelegen haben,

Und betriebssystemnahe Software aka Treiber machen jetzt nicht so einen riesigen Teil der Software aus. Die kann man ruhig weiterhin in C/C++ lassen.

Microsoft hat ja schon ein experimentelles Betriebssystem in .Net geschrieben.

Ganon

2009-11-17, 22:56:05

Oder will irgendwer Photoshop als Java App haben? Ich denke nicht.

Äh, es gibt sogar kleinere Photoshop-Versionen in Flash ;)

Es sprechen nachwievor tausend Gründe gegen Java oder .NET. Java wäre eine echte Konkurrenz, wenn mal jemand endlich ein Java OS herausbringen würde.

Dann zähle mal die Gründe gegen Java oder .NET auf ;)

Performance kann es nicht sein, da Qt/C++-Anwendungen nur ca. 10% "schneller" sind bei GUI-Benchmarks als Java/Swing. Das diese fern ab jeder Realität ablaufen ist auch klar á la "fülle 10000000 mal das Textfeld und messe die Zeit". Im normalen Betrieb gibt es da so gut wie keine Performance-Unterschiede.

Speicherverbrauch/GarbageCollector-Nachteile? Galten vor 10 Jahren vllt. noch. Glaube kaum, dass große C++ Anwendungen keinen Speichermanager o.ä. benutzen. Und wenn dein Beispiel Photoshop statt 50 nun 80 MB verbraucht, macht den Braten bei 600MB an Bilddaten auch nicht mehr fett ;)

Startzeit? Die .NET Runtime läuft eh im Hintergrund bereits und afaik kompiliert .NET sowieso schon alles vor. Würde es mehr Java-Anwendungen geben, würde hier das Gleiche gelten.

Da wir hier von Windows und .NET reden gibt es sogar "wichtigere" Vorteile.
- die größte Sicherheitslücke "Bufferoverflow" fällt weg -> sicherere Anwendungen
- Performance und ggf. Feature-Umfang der Anwendung steigt ohne neue Programm-Version
- man benötigt keine 32bit, 64bit oder was auch immer Version, eine Version für alles
- läuft die VM auf den Windows-Versionen laufen auch die Programme

Bei intensiven Berechnungen o.ä. mag C++ momentan noch Vorteile haben, aber gerade bei GUI-Anwendungen ist das wirklich nicht mehr ausschlaggebend. Aber auch die VMs schlafen nicht. Mono hat ja bereits SIMD-Klassen eingeführt und vllt. übernimmt Microsoft die ja auch. Dann wäre dieser "Hardwarenah-Vorteil" von C++ auch gefallen. Und der Java-Hotspot-Compiler optimiert entsprechende Konstrukte eh schon zu SIMD-Befehlen. Und die Standard-Befehle wie sin, pow, sqrt usw. werden eh 1:1 weitergeleitet und nutzen den gleichen Befehl wie eine C++-Anwendung.

Und wenn du ein Java-Betriebssystem willst:
http://www.jnode.org/

Und wenn du eines in .NET willst:
http://research.microsoft.com/en-us/projects/singularity/

Und passend dazu:
"AMD schlägt Optimierung der CPUs für Java und .NET vor"
http://www.golem.de/0708/54193.html

Coda

2009-11-18, 00:08:43

Ich mochte Java und C# bisher vor allem nicht weil es mich zu sehr einschränkt. Da ich aber bei .NET für bestimmte Sachen in Zukunft auch F# nehmen kann ist es deutlich attraktiver geworden ;)

PHuV

2009-11-18, 02:23:20

COBOL ist auch nur noch ein Zombie.
Hast Du einen Ahnung. ;) Glaub mir, Cobol ist (leider) noch ein Stück davon entfernt, ein Zombie zu werden. Klar kein Mainstream. Wer kann hier überhaupt richtig Cobol. Da melde ich mich mal, fast 3 Jahre PPS-System damit entwickelt.

Was mich wirklich immer wieder erschreckt, ist das C immer noch die meistbenutzte Programmiersprache überhaupt ist.

Ganz einfach, C ist noch einigermaßen portabel auf allen Plattformen verfügbar. Bei C++ hört es hier sehr schnell auf. Die meisten Unix-OSe sind in C geschrieben (nehmen wir mal die großen HP-UX, AIX, Solaris, Linux). Da findet man bis heute recht wenig C++ drin.

Und wenn C++ für große Projekte nicht geeignet ist, kann es C ja wohl erst recht nicht sein X-D

Darüber kann man sich streiten. Fakt ist, das es C bis heute tut.

Coda

2009-11-18, 02:46:55

Wer kann hier überhaupt richtig Cobol.
Dürfte kaum ein Problem sein eine rein prozedurale Sprache innerhalb einer Woche zu lernen. Der Syntax ist halt gruselig.

Darüber kann man sich streiten. Fakt ist, das es C bis heute tut.
Nicht darüber streiten kann man allerdings dass C in 99% der Fälle die schlechtere Lösung ist. Für System-Programming seh ich's ja noch ein, sonst überhaupt nicht.

Und ja, ich kann C.

Ganon

2009-11-18, 08:32:20

Ich mochte Java und C# bisher vor allem nicht weil es mich zu sehr einschränkt.

Kommt auch immer auf die Ebene an, auf der man entwickelt ^^

Wenn ich mir z.B. angucke wie viele ORM-Frameworks es für C++ gibt und was für Features die haben, dann wird mich C++ ziemlich einschränken ;)

Gast

2009-11-18, 10:17:18

Ganon

2009-11-18, 12:28:10

Für .NET gillt allgemein, dass es sich nur auf Windows-Plattformen verbreitet hat. Kommt also eher nicht in Frage, auch wenn es portabel ist.

Na du musst dich schon entscheiden. Entweder dir schmecken die Nachteile von Java nicht (Windows-Intergration) oder dir schmecken die .NET-Nachteile nicht (Windows-Intergration). Du kannst nicht bei beiden die jeweilig gegenteilige Integration bemängeln ;)

Und mal so nebenbei. Mit C++ hast du an sich gar keine GUI und bist immer an eine Plattform gebunden. Und Qt sieht nicht viel besser aus als Swing/SWT.

Und wegen "Java-OS". In OS X und Solaris (und einigen Linux-Distries) ist Java standardmäßig dabei ;)

Gast

2009-11-18, 12:30:25

Für .NET gillt allgemein, dass es sich nur auf Windows-Plattformen verbreitet hat. Kommt also eher nicht in Frage, auch wenn es portabel ist.

Das ist aber eher irrelevant. Es geht ja um die Spezifikationen, nicht die konkrete Implementierung. Die MSIL ist plattformunabhängig. Klar heißt das auch, dass man für plattformübergreifende Bibliotheken für jede Plattform eine extra Assemlby ausliefern muss. Ändert aber nichts an der Tatsache, dass man für die jeweilige Plattform (sowohl OS oder HW) nicht neu kompilieren muss.

Ganon

2009-11-18, 12:42:27

Gast

2009-11-18, 12:56:21

Naja, solange Microsoft keine .NET VM für andere Systeme anbietet, würde ich .NET nicht unter "plattformunabhängig" einstufen. Windows-Anwendungen sind ja auch nicht per se plattformunabhängig nur weil es WINE gibt ;) Ergo denke ich, dass .NET Anwendungen plattformunabhängig sind, nur weil es Mono gibt.

Zumal viele .NET Anwendungen Windows-Funktionen aufrufen, die nicht in der Spezifikation sind. Und solche Sachen wie WPF usw. sind afaik bei Mono noch nicht mal in der Planung, dass sie überhaupt implementiert werden.

Mit Spezifikation meine ich den Aufbau der Infrastruktur: CLI/CLS. Dazu gehört aber nicht, aus welchen Funktionen eine Bibliothek besteht oder gar zugreift. Wenn man eine plattformunabhängige Bibliothek haben möchte, dann muss man diese eben selbst designen und für alle Plattformen implementieren. Das ist aber der MSIL oder dem GC vollkommen egal. Klar hast du Recht, dass die Microsoft "Implementierung" nicht plattformübergreifend ist, weil es einfach nicht plattformübergreifend angeboten wird. Aber das hat nichts mit der Spezifikation der .NET Sprachen/Laufzeitumgebung zu tun.

Gast

2009-11-18, 13:28:50

Na du musst dich schon entscheiden. Entweder dir schmecken die Nachteile von Java nicht (Windows-Intergration) oder dir schmecken die .NET-Nachteile nicht (Windows-Intergration). Du kannst nicht bei beiden die jeweilig gegenteilige Integration bemängeln ;)

Ich wusste, dass mir das um die Ohren gehauen wird *gg*. Aber es ging ja um DIE nächste Sprache für alle Plattformen. Natürlich bilden Java und .NET auf Windows ein gegenseitiges Ausschlusskriterium. Deswegen kann ich auch argumentieren, dass beide als Ablösung für C/C++ ersteinmal nicht in Frage kommen.

Ganon

2009-11-18, 13:38:49

Ich wusste, dass mir das um die Ohren gehauen wird *gg*. Aber es ging ja um DIE nächste Sprache für alle Plattformen.

Es wird nie die perfekte plattformunabhängige Sprache/Framework(inkl. GUI) geben. Das kannst du gleich vergessen. Java versucht sich schon Jahrzehnte daran und ich kenne bisher kein System, was es besser macht. Dazu sind die Bedienungskonzepte (Windows, Xorg, OS X) einfach zu verschieden, um es mit einer einzigen Funktion abzudecken. Selbst NetBeans unterscheidet hier unter Java zwischen den Systemen, um spezifischen Code zu nutzen.

Das ganze fängt ja schon beim einfachen GUI-Layout an, was einem die Sprache nicht abnimmt. Darum fühlen sich auch meist Java-Anwendungen unter anderen Systemen fremd an, weil sie einfach nicht den Guidelines des entsprechenden Systems entsprechen, weil der Programmierer nicht darauf geachtet hat.

Deswegen kann ich auch argumentieren, dass beide als Ablösung für C/C++ ersteinmal nicht in Frage kommen.

Aber selbst C/C++ bietet doch das von dir gewünschte gar nicht. Die verhalten sich sogar noch schlimmer (Endianess, verschiedene Compiler, etc.)

Gast

2009-11-18, 13:40:41

Mit Spezifikation meine ich den Aufbau der Infrastruktur: CLI/CLS. Dazu gehört aber nicht, aus welchen Funktionen eine Bibliothek besteht oder gar zugreift. Wenn man eine plattformunabhängige Bibliothek haben möchte, dann muss man diese eben selbst designen und für alle Plattformen implementieren. Das ist aber der MSIL oder dem GC vollkommen egal. Klar hast du Recht, dass die Microsoft "Implementierung" nicht plattformübergreifend ist, weil es einfach nicht plattformübergreifend angeboten wird. Aber das hat nichts mit der Spezifikation der .NET Sprachen/Laufzeitumgebung zu tun.

Wenn man genau darüber nachdenkt, dann stimmt es sogar, was du schreibst ;) Dennoch, .NET hat sich bis heute nicht großartig verbreitet. Und es gibt ebenfalls kein .NET OS. Vorallem scheint es auf UNIX Systemen so eine Art Antisympathie gegen .NET zu geben, wohl weil es von MS ist. Aber das ist jetzt nur meine Interpretation.

Gast

2009-11-18, 13:52:43

Aber selbst C/C++ bietet doch das von dir gewünschte gar nicht. Die verhalten sich sogar noch schlimmer (Endianess, verschiedene Compiler, etc.)

Mit Endianess hat nun wirklich jede Sprache zu kämpfen, wenn es z.B. um den Import einer TIFF Datei geht. Und in C/C++ merkt man in der Regel gar nichts davon. Aber egal.

Ließ mal, was der eine Gast zu .NET gechrieben hat bezüglich des Modells hinter der Sprache. Und eigentlich geht es nur darum. Und C bietet nun einmal das maschinennaheste, bestens getestete und portabelste Modell. Und das sogut wie jedes OS in C geschrieben ist, hat seinen Grund.

Ich will C/C++ ja gar nicht bis aufs Messer verteidigen. Aber wenn man vom Abgesang gerade einer solchen Sprache spricht, dann sollte man schon eine gute Alternative parat haben. Und die sehe ich aktuell nicht.

ESAD

2009-11-18, 14:00:18

Und das sogut wie jedes OS in C geschrieben ist, hat seinen Grund.

millionen von codezeilen wo wohl jeder bwller in ohnmacht fallen würde würde man ihm die kosten für eine portierung sagen.

Gast

2009-11-18, 14:06:06

Dennoch, .NET hat sich bis heute nicht großartig verbreitet.

Es mag sein, dass für den Endkonsumenten viele Softwareprodukte noch in C/C++ geschrieben sind. Aber der überweältigende Großteil ist das Projektgeschäft mit zig Millionen Entwicklern. Und da hat sich .NET/Java schon längst durchgesetzt. In den USA werden sogar mehr Projekte in .NET als Java erstellt, in Europa sieht es umgekehrt aus. Dagegen sind die paar Spiele/Standardsoftware etc. nicht der Rede wert.

Coda

2009-11-18, 14:21:31

Kommt auch immer auf die Ebene an, auf der man entwickelt ^^
Ich meine jetzt die Sprache an sich, nicht die Libraries :)

Wenn ich mir z.B. angucke wie viele ORM-Frameworks es für C++ gibt und was für Features die haben, dann wird mich C++ ziemlich einschränken ;)
Für Datenbank-GUI-Zeug würde ich auch kein C++ nehmen. Allerhöchstens mit Qt, das hat AFAIK nen DB-Layer.

Gast

2009-11-18, 14:25:39

Es mag sein, dass für den Endkonsumenten viele Softwareprodukte noch in C/C++ geschrieben sind. Aber der überweältigende Großteil ist das Projektgeschäft mit zig Millionen Entwicklern. Und da hat sich .NET/Java schon längst durchgesetzt. In den USA werden sogar mehr Projekte in .NET als Java erstellt, in Europa sieht es umgekehrt aus. Dagegen sind die paar Spiele/Standardsoftware etc. nicht der Rede wert.

Du wirst dich wundern, aber ich bin sogar Softare - Consultant in der Projekt - Branche. Ich entwickel seit numehr 10 Jahren Java WEB Apps bei große Kunden. Sicher ist das ein großer Markt und es wurde ja auch in diesem Thread schon ausführlich darüber diskutiert, dass in diesem Markt alle Sprachen ausser Java/.NET tot sind. Trotzdem ist der Endconsumer Markt vorhanden und dort sieht es mit Killer-Apps, die mit Java/.NET geschrieben werden, eher düster aus.

Shink

2009-11-18, 14:26:46

Nun ja; C ist der de-facto-Standard-Assembler-Ersatz. Daran ändert sich wohl auch mit Go nichts (da es dort z.B. auch einen GC gibt).

Wer es als Argument sieht dass so viel C in heutigen Betriebssystemen steckt sollte sich auch mal ansehen wie "modern" die aufgebaut sind.
Das es auch anders ginge sieht man z.B. an Solaris (da können zumindest Treiber in Java geschrieben werden) oder eben JNode (das Betriebssystem übersetzt sich beim Start selbst aus Java bis eine VM läuft).

Wer sich aufregt dass Java nicht nativ genug ist kann auch in einer betriebssystemnahen Library programmieren (z.B. java-gnome, qt-jambi, Cocoa Java-bridge) oder gleich seine Libraries über JNI einbinden.
Davon abgesehen ist das mit den nativen Anwendungen ohnehin Unsinn: Was fühlt sich heutzutage schon nativ an? Office 2007 auf einem Windows XP-Rechner? Adobe-Produkte? OpenOffice?
Im Vergleich dazu schneiden z.B. Eclipse-RCP-Produkte gar nicht so übel ab.

Ganon

2009-11-18, 14:42:58

Und C bietet nun einmal das maschinennaheste, bestens getestete und portabelste Modell.

Was willst du an "C" großartig testen? Der reine Umfang von C ist recht mager. Und C-Compiler wie GCC bauen heutezutage noch genügend Bugs in den Code.

Und "maschinennahe"... nunja. Hast du davon jetzt großartig einen Vorteil? Das ist doch meist alles historisch bedingt, dass man so an die Sache herangehen muss bei bestimmten Betriebssystemen.

Wenn Windows jetzt Treiberschnittstellen für .NET bereitstellen würde, wüsste ich nicht was es gegen .NET-Treiber spricht. Unterm Strich wird aus allem Maschinencode und ob der nun im Vorfeld kompiliert wird oder erst nach der Installation ist doch Jacke wie Hose.

"Portabel" und C ist auch so eine Sache. Du kannst in C-Syntax zwar überall programmieren, aber "portabel" macht es die Sache nun auch nicht. Es endet eher in einer ifdef-Hölle. Schaue z.B. mal in die Header von Darwin oder SDL. Auch C, aber nicht unbedingt sprachbedingt "portabel".

Und das sogut wie jedes OS in C geschrieben ist, hat seinen Grund.

Weil es in den 80ern noch kein Java und .NET gab, vllt.? ;) Davor waren alle Betriebssysteme in Assembler programmiert. Und irgendwann wird auch C abgelöst. Aber aufgrund der Abwärtskompatibilität will das keiner übers Knie brechen.

Exxtreme

2009-11-18, 21:47:37

Also ich sehe hier immer noch kein echtes Argument für eine Sprache die es schaffen wird, C/C++ als die eierlegende Wollmilchsau abzulösen.

Nehmen wir mal ja Java.

Pros für den End-User.
- Kann auf sogut wie jeder Plattform laufen

Cons für den End-User:
- Kein Java OS verfügbar (ich meine von Herstellern wie MS und nicht irgendeinem Studentenexperiment)
- MS unterstützt eher .NET (wenn jemand glaubt das sei kein Argument, dann mal bitte aufwachen)
- Der End-User hat keine Lust eine VM vorher zu installieren
- Kaum nativ Window Support für ein jeweiliges OS (Swing sieht zudem echt kacke aus)

Pros für Kundenprojekte:
- Systemunabhängig
- Lesbare Syntax
- Extrem großer Umfang an Bibliothken und Werkzeugen
- Das Meiste davon ist kostenlos
- Für Web-Anwendungen die Ideallösung

Cons für Kundenprojekte:
(fällt mir nichts ein)

Für .NET gillt allgemein, dass es sich nur auf Windows-Plattformen verbreitet hat. Kommt also eher nicht in Frage, auch wenn es portabel ist.

Objective-C findet auch eher ein Nischendasein auf Apple Computern und iPhones.

F# habe ich mir nicht angesehen.

Also was bleibt übrig? Mir ist klar, dass die Frage nicht pauschal zu beantworten ist. Im Moment ist C die Sprache. Mir ist allerdings auch nicht klar, warum man nicht wenigsens C++ nimmt anstelle von C. Es kann aber auch gut passieren, dass C++ eine renaissance erlebt. Wenn man sich den neuen Standard so anschaut, dann sind da extrem nützliche Dinge wie z.B. R-Value Referenzen enthalten. Mal abwarten, was passiert.
C/C++ hat für die meisten Projekte den Status erreicht den Assembler auch hat: man kann damit alles machen, es ist aber für die meisten Dinge suboptimal. Deshalb würde ich nicht mehr von einer eierlegenden Wollmilchsau reden. C/C++ kann sich jetzt noch auf Tonnen bestehenden Code ausruhen. Nur wird es immer bedeutungsloser werden.

Klar gibt es keine Customer-Killerapplikation für in Java oder MSIL weil es wohl noch billiger ist bestehende Anwendungen aufzubohren anstatt komplett neu zu implementieren. Aber sobald angefangen wird komplett neu zu programmieren kommt C/C++ nur noch selten zum Einsatz.

Und deine aufgezählten Nachteile von Java sind real gar keine. Daß MS eher .NET unterstützt ist kein Nachteil von Java. Native Window Support hat sich selbst obsolet gemacht nachdem jede neue Version eines Betriebssystems anders aussieht. Daß es kein natives praxistaugliches Java-OS gibt ... wayne? Wäre wohl sowieso nicht zum Einsatz gekommen etc.