warum die D kompiler fürn _arsch_ sind
-
sothis_ schrieb:
falls, du irgendwo gelesen hab solltest, dass ich auf einer sprache rummeckere, dann bitte ich dich mir das zu zeigen. in diesem falle lösche ich das dann natürlich wieder. und wenn ich compiler als fürn _arsch_ kennzeichne, dann ist das ganz normale kritik.
Du brauchst nicht auf den Compiler auszuweichen, wenn du im Threadtitel ganz explizit gegen die Sprache wetterst!
-
D ist gut schrieb:
Du brauchst nicht auf den Compiler auszuweichen, wenn du im Threadtitel ganz explizit gegen die Sprache wetterst!
sag bloss du hast 3 minuten gebraucht, um diesen satz zu schreiben.
-
Für normale Kritik verwendet man nicht solche Vokabeln. Das ist einfach nur unterstes Niveau.
-
tntnet schrieb:
Für normale Kritik verwendet man nicht solche Vokabeln. Das ist einfach nur unterstes Niveau.
ich bin auf'm dorf aufwachsen. da ist das niveau halt noch nicht so weltmännisch. entschuldigung
-
Davon abgesehen dass mir die Ausdrucksweise hier ziemlich egal ist ... ist der Thread wohl genauso sinnlos wie der kürzlich erst gehabte "D und Python sind so supi lala blabla" Thread.
Jo, D is Scheisse weil's keinen Support für irgendwas gibt, der Compiler Kacke ist etc. Big news.
Eiffel gehts (leider) genauso, und da würde ich mehr Potential sehen als bei D.Was mich jetzt aber doch interessiert: was bitte soll an den Möglichkeiten für Error-Handling so toll sein? Was meinst du damit bitte?
-
hustbaer schrieb:
ist der Thread wohl genauso sinnlos wie der kürzlich erst gehabte "D und Python sind so supi lala blabla" Thread.
wenn du das so siehst ist's ok, ich wollte nur meine meinung kundtun
hustbaer schrieb:
Big news.
für mich ja, weil ich mich nich nie eingehender damit beschäftigt habe.
hustbaer schrieb:
Was mich jetzt aber doch interessiert: was bitte soll an den Möglichkeiten für Error-Handling so toll sein? Was meinst du damit bitte?
da ich ein prozeduralfreak bin, fand ich die spracheigenen möglichkeiten interessant, um z.b. vor und nachbedingungen in der funktion definieren zu können, die vom caller, bzw. von der funktion selbst erfüllt werden müssen. aber insbesondere fand ich die idee von scopes gut, die eine fehlerbehandlung innerhalb eines blockes möglich macht.
-
sothis_ schrieb:
D ist gut schrieb:
Du brauchst nicht auf den Compiler auszuweichen, wenn du im Threadtitel ganz explizit gegen die Sprache wetterst!
sag bloss du hast 3 minuten gebraucht, um diesen satz zu schreiben.
Das nicht, aber um den kompletten Thread durchzulesen ja.
Du hättest den Titel halt schneller ändern müsssen, bevor ich den Thread öffnete, du warst eindeutig zu langsam.
-
sothis_ schrieb:
hustbaer schrieb:
Was mich jetzt aber doch interessiert: was bitte soll an den Möglichkeiten für Error-Handling so toll sein? Was meinst du damit bitte?
da ich ein prozeduralfreak bin, fand ich die spracheigenen möglichkeiten interessant, um z.b. vor und nachbedingungen in der funktion definieren zu können, die vom caller, bzw. von der funktion selbst erfüllt werden müssen. aber insbesondere fand ich die idee von scopes gut, die eine fehlerbehandlung innerhalb eines blockes möglich macht.
OK, das mit den Scopes muss ich mir nochmal ansehen. Das mit den pre-/postconditions ist cool, ja. Hat aber IMO nix mit Error-Handling zu tun. Zumindest nicht mit dem was ich darunter verstehe.
Kennst du Eiffel schon? Wenn nein guck dir das mal an. Ist auch nicht so toll was die Umsetzung angeht (Standard-Library), aber vom Konzept her ganz nett.
-
Eh D hat doch alles abgekupfert von Eiffel o.O
-
Zeus schrieb:
Eh D hat doch alles abgekupfert von Eiffel o.O
das ist mir persönlich alles sowas von egal was von wem abstammt und wer von wo etwas geklaut hat. solange es keine vernünftige toolchain, insbesondere compiler für die entsprechende sprache gibt, ist sie für mich von vornherein nicht brauchbar. da kann das konzept stimmen wie will, wenn ich es nicht einsetzen kann, nützt es mir nichts
-
Das war auch nicht an dich gerichtet, sondern an hustbaer. *gg*
-
Der Thread fing doch recht sachlich an. Warum kommt ihr nicht zur Sache zurück?
Wenn ich das richtig verstanden habe, bietet D konzeptionell einige interessante Features, allerdings fehlt noch die Realisierung auf akzeptablem Praxisniveau. Mal eine ganz einfache Frage: Wieso arbeiten an D nur zwei Entwickler? Das bedeutet doch schlicht und einfach, dass sich fast niemand dafür interessiert.
-
D wäre für C++-Programmierer eine Möglichkeit, um java oder C# auszuweichen. Man kann den Digital Mars D-Compiler in Code::Blocks integrieren.
Das Problem ist IMHO die zu geringe Differenzierung. Gibt es eine Übersichtstabelle C++/D/Java/C# ?
D als Alternative zu C? Wohl kaum.
-
Erhard Henkes schrieb:
Wieso arbeiten an D nur zwei Entwickler?
ich bezog mich dabei im übrigen auf gdc. das bei digital mars auch nur sehr wenige arbeiten wusste ich garnicht
-
Wenn man keine Ahnung hat, einfach mal die Fresse halten!!!
Werde mich aber nich äußern welche Personen ich damit meine^^
-
CantLogin schrieb:
Werde mich aber nich äußern welche Personen ich damit meine^^
dann brauchst du hier auch nicht zu posten
-
Dich meine ich nicht _sothis, keine panik;)
-
@CantLogin: Na, dann erzähl uns doch mal die Wahrheit über D, wenn Du Insiderwissen hast. Wir sind interessiert. Immerhin hat es D noch nicht geschafft, hier eine eigene Sektion zu erhalten.
Übersichtlicher Vergleich C++/D/Java/C#, das wäre z.B. ein Fortschritt in der sachlichen Diskussion.
-
Das Liegt wohl daran, dass Walter an zuviele Fronten ist. Anstellte sich mehr um den Compiler und der Sprache kömmert, baut er Phobos, welches er immer wieder neuschreibt, weil er paar Sachen geändert hat. Dann würde mal Angeboten, dass die Tango-Leute die Lib machen, damit Walter mehr Zeit hat.
Aber bis jetzt geht dies nicht:import unit; import lib.unit; void main() { }lib\unit.d: module unit is in multiple defined
Und dann soll D für große Projekte geeignet sein, wenns D nicht unterscheiden kann zwischen eine "Unit" von mir und eine Unit einer Lib?
-
