Hallo Leute! Hab neulich von der neuen Programmiersprache von Google gelesen, und wollte mal ein bisschen mit der Testversion herumspielen. Entweder bin ich zu blöd zum Suchen, oder es gibt noch keine "für den normal sterblichen verständlich zu installierende Entwicklungsumgebung".... Hat das schon jemand ausprobiert, oder wisst ihr wie's geht? Benutze WinXP SP2, danke für die Tips
Ich habe mir bei der Veroeffentlichung die Slides angesehen und dann auf mehr verzichtet. Traurigerweise scheinen es immer Entwickler mit sehr schlechtem Stil zu sein, die meinen, dass es eine neue Programmiersprache braucht.
Go scheint sich im Moment noch in einem sehr initialen Zustand zu befinden, da darf man insbesondere als Windows-User nicht allzu viel Support erwarten: http://golang.org/doc/go_faq.html#Why_doesnt_Go_run_on_Windows Aber vielleicht kannst du ja damit etwas anfangen: http://code.google.com/p/go-windows/ Leichter geht's mit Linux, BSD oder auf einem Mac. Da findet man etliche Anleitungen für beide derzeit existierenden Compiler (GC und GCCGO).
Danke für die schnelle Antwort. Nun soll ich die Umgebungsvariablen setzen set GOROOT=<the go folder> set GOOS=mingw set GOARCH=386 hab ich im DOS gemacht, müsste soweit passen. Was dann?
Ich kann mich ja grundlegend irren, aber vor etwa 30 Jahren gab es doch auch schon eine Programmiersprache namens GO. Will mir das jetzt nicht weiter ergoogeln; No GO!
irgendwie merkt man hier eine starke Abneigung gegen die Sprache. Woher das?
Gerry E. schrieb: > Ich kann mich ja grundlegend irren, aber vor etwa 30 Jahren gab es doch > auch schon eine Programmiersprache namens GO. Will mir das jetzt nicht > weiter ergoogeln; No GO! Es gibt sogar aktuell eine: http://en.wikipedia.org/wiki/Go!_(programming_language) Google scheint sich nicht gross darum zu scheren, dass der Name schon belegt ist...
So wie ich das verstehe, ist diese "derzeit existente" GO!- Sprache eben jene von Google- Entwicklern.
Henk schrieb: > So wie ich das verstehe, ist diese "derzeit existente" GO!- Sprache eben > jene von Google- Entwicklern. Steht doch ganz am Anfang des Wiki-Artikels: "Go! is a little-known[1] agent-based programming language in the tradition of logic-based programming languages like Prolog.[2] It was introduced in a 2003 paper by Francis McCabe and Keith Clark.[3]"
Daniel V. schrieb: > set GOROOT=<the go folder> > set GOOS=mingw > set GOARCH=386 > > hab ich im DOS gemacht, müsste soweit passen. > Was dann? Ich habe kein Windows, deswegen kann ich dir nicht so sehr weiterhelfen. Auf der oben geposteten go-windows-Seite kann man aber unter "Downloads" ein go-1.zip herunterladen, das die Binaries und die Bibliotheken enthält. Damit ist es mir immerhin gelungen, nach dieser Anleitung http://golang.org/doc/go_tutorial.html und dem Setzen der drei Environment-Variablen unter Wine ein Hello-World zu kompilieren und zu linken. Nur bei der Ausführung des fertigen Programms erntete ich einen Page-Fault, was aber auch an Wine liegen könnte. Vielleicht funktioniert es im nativen Windows besser. > irgendwie merkt man hier eine starke Abneigung gegen die Sprache. > Woher das? Ich kann nur einen einzigen ablehnenden Beitrag (plus einen Troll-Post) in diesem Thread finden. Generell ist es aber so, dass eine neue Programmiersprache aus gutem Grund immer erst einmal sehr skeptisch beäugt wird. Es gibt einfach schon viel mehr Programmiersprachen, als man in einem Menschenleben lernen kann. Warum sollte man sich jetzt ausgerechnet auf eine stürzen, die noch ganz in den Anfängen steckt und wo man nicht einmal sicher sein kann, dass die Entwicklung nach einem Jahr schon wieder eingestellt wird? Ich selbst bin der Sprache überhaupt nicht abgeneigt, immerhin steckt sogar einer der großen Gurus (Ken Thompson) dahinter. Allerdings ist sie als Produktivsprache noch zu unreif (da würde ich mir bspw. eher D näher anschauen), und als Spaßsprache unterscheidet sie sich für meinen Geschmack zu wenig von den Mainstream-Sprachen. Henk schrieb: > So wie ich das verstehe, ist diese "derzeit existente" GO!- Sprache eben > jene von Google- Entwicklern. Die eine heißt "Go!" und die andere "Go" (ohne Ausrufezeichen). Auf die Details kommt es manchmal an ;-) @Peter: Mit der vor 30 Jahren meinst du vielleicht das Go mit dem Lo davor? http://de.wikipedia.org/wiki/Logo_%28Programmiersprache%29 Das ist sogar schon über 40 Jahre alt.
yalu schrieb: > Ich selbst bin der Sprache überhaupt nicht abgeneigt, immerhin steckt > sogar einer der großen Gurus (Ken Thompson) dahinter. Gurus sind was fuer Religionen... wenn die Sprache gut ist, sollte sie durch ihre Eigenschaften ueberzeugen koennen, nicht durch ihren Erfinder. Ich find's schon sehr abschreckend, wenn die Code-Beispiele fuer eine neue Sprache gleich wie hingerotzt aussehen. Leider werden zwar immer wieder neue Sprachen geschaffen um das Programmieren irgendwie einfacher und weniger fehleraenfaellig zu machen, das zentrale Problem, der sauschlechte Stil vieler Entwickler, wird aber gerne als unwichtige Geschmacksfrage abgetan. Go wird sich wahrscheinlich trotzdem durchsetzen, einfach weil's von google ist und google halt einfach in ist. > @Peter: > Mit der vor 30 Jahren meinst du vielleicht das Go mit dem Lo davor? Die von vor 30 Jahren war von Gerry, musst du ihn fragen.
Peter Stegemann schrieb: > yalu schrieb: > >> @Peter: >> Mit der vor 30 Jahren meinst du vielleicht das Go mit dem Lo davor? > > Die von vor 30 Jahren war von Gerry, musst du ihn fragen. Jaja, da habe ich wohl was verwechselt. Macht Euch nur lustig über die alten. :-)
Peter Stegemann schrieb: > yalu schrieb: > >> Ich selbst bin der Sprache überhaupt nicht abgeneigt, immerhin steckt >> sogar einer der großen Gurus (Ken Thompson) dahinter. > > Gurus sind was fuer Religionen... wenn die Sprache gut ist, sollte sie > durch ihre Eigenschaften ueberzeugen koennen, nicht durch ihren > Erfinder. Das ist schon richtig, aber wer hat schon die Zeit, die vielen hundert Programmiersprachen, die es derzeit gibt, einzeln auf ihre Eigenschaften zu untersuchen? Nach irgendwelchen Kriterien muss man sich die interes- santeren daraus aussuchen, um sich anschließend ihre Eigenschaften aus der Nähe anzuschauen. Solche Kriterien können bspw. sein: - Ein Kumpel hat angefangen, die Sprache zu lernen, und ist begeistert. - Die Sprache kommt von IBM, Microsoft oder Google. - Die Sprache wird in einem c't-Artikel vorgestellt. - Die Sprache hat einen "Marktanteil" von über 40%. - Die Sprache ist im ICFP-Contest die "Programming Language of Choice for Discriminating Hackers" geworden. - ... - Oder eben: Einer, der schon Jahrzehnte lang erfolgreich komplexe Softwaresysteme programmiert, empfiehlt die Sprache oder hat sie selber entwickelt. Ganz klar ist keines dieser Kriterien ein Garant für eine wirklich gute Sprache, aber irgendwie muss man sich ja in der Vielfalt zurechtfinden. Und wenn Ken Thompson eine neue Programmiersprache entwickelt, macht mich das neugieriger, als wenn ein c't-Redakteur zu irgendeiner Sprache, deren Namen er zufälligerweise im Internet aufgeschnappt hat, einen Artikel zusammenpappt, um die Zeitschrift voll zu bekommen. Oder wie bist du auf die nach deinem Geschmack beste(n) Programmierspra- che(n) aufmerksam geworden? Bist du etwa die Liste in http://en.wikipedia.org/wiki/List_of_programming_languages in alphabetischer Reihenfolge durchgegangen, hast dir die jeweilige Dokumentation durchgelesen, jeweils zwei Wochen darin programmiert und sie anschließend bewertet? ;-) > Ich find's schon sehr abschreckend, wenn die Code-Beispiele fuer eine > neue Sprache gleich wie hingerotzt aussehen. Meinst du die Beispiele aus dem Tutorial? Wenn ja, was findest du daran hingerotzt? Die Syntax an sich, oder die Art und Weise, wie der Code formatiert wurde?
yalu schrieb: > Peter Stegemann schrieb: >> yalu schrieb: >> >>> Ich selbst bin der Sprache überhaupt nicht abgeneigt, immerhin steckt >>> sogar einer der großen Gurus (Ken Thompson) dahinter. >> >> Gurus sind was fuer Religionen... wenn die Sprache gut ist, sollte sie >> durch ihre Eigenschaften ueberzeugen koennen, nicht durch ihren >> Erfinder. > > Das ist schon richtig, aber wer hat schon die Zeit, die vielen hundert > Programmiersprachen, die es derzeit gibt, einzeln auf ihre Eigenschaften > zu untersuchen? Nach irgendwelchen Kriterien muss man sich die interes- > santeren daraus aussuchen, um sich anschließend ihre Eigenschaften aus > der Nähe anzuschauen. Solche Kriterien können bspw. sein: > > - Ein Kumpel hat angefangen, die Sprache zu lernen, und ist begeistert. > - Die Sprache kommt von IBM, Microsoft oder Google. > - Die Sprache wird in einem c't-Artikel vorgestellt. > - Die Sprache hat einen "Marktanteil" von über 40%. > - Die Sprache ist im ICFP-Contest die "Programming Language of Choice > for Discriminating Hackers" geworden. > - ... > - Oder eben: Einer, der schon Jahrzehnte lang erfolgreich komplexe > Softwaresysteme programmiert, empfiehlt die Sprache oder hat sie > selber entwickelt. > > Ganz klar ist keines dieser Kriterien ein Garant für eine wirklich gute > Sprache, aber irgendwie muss man sich ja in der Vielfalt zurechtfinden. > Und wenn Ken Thompson eine neue Programmiersprache entwickelt, macht > mich das neugieriger, als wenn ein c't-Redakteur zu irgendeiner Sprache, > deren Namen er zufälligerweise im Internet aufgeschnappt hat, einen > Artikel zusammenpappt, um die Zeitschrift voll zu bekommen. > > Oder wie bist du auf die nach deinem Geschmack beste(n) Programmierspra- > che(n) aufmerksam geworden? Bist du etwa die Liste in > > http://en.wikipedia.org/wiki/List_of_programming_languages > > in alphabetischer Reihenfolge durchgegangen, hast dir die jeweilige > Dokumentation durchgelesen, jeweils zwei Wochen darin programmiert und > sie anschließend bewertet? ;-) Braucht man nicht, wenn man vorher etwas kategorisiert: http://en.wikipedia.org/wiki/Programming_paradigm dann bleiben nur zwei grundlegende Richtungen übrig: imperativ und deklarativ. Will man nicht unterschiedlichste Syntaxen lernen, sieht man sich die Liste der Multi-Paradigmen-Sprachen an: http://en.wikipedia.org/wiki/List_of_multi-paradigm_programming_languages und wählt einen Vertreter der imperativ + objektorientiert unterstützt und man hat schon einen erheblichen Teil abgedeckt (nimmt man zwei, einen mit C-artiger und einen mit Algol-artiger Syntax hätte man schon fast alle in der Praxis genutzten Sprachen abgedeckt). Dazu noch einen Vertreter aus der deklarativ/funktionalen und einen aus der deklarativ/logischen Kategorie. Für die absoluten Grundlagen noch etwas Assembler, solange man da nichts auswählt was mit 80xx oder PIC1x anfängt ;-) und man ist fertig... Was auch gleich zur Kritik an Go führt: - die Syntax ist C + Algol - ein paar Klammern + irgendetwas + Oktalkonstanten (letztlich nur eine leicht geänderte Limbo-Syntax), dazu noch (halb) implizite Exports, eine krude Mischung aus Infix-, Präfix- und Postfix-Notation, gepaart mit einer "merkwürdigen" Aufteilung in Statements und Expressions. Man könnte auch sagen, dass schlechteste aus beiden Welten. Und typisch bei solchen Sprachen: Mehr Rauschen als Signal - teilweise völlig unsystematische Design-Entscheidungen (theoretischer Background?) - fehlendes Ökosystem und (z.Z.) kaum vorhandene Interoperabilität im Gegensatz zu JVM-, .NET-Sprachen oder C und C++ - absolut keine einzige Neuerung/Verbesserung gegenüber bestehenden Sprachen >> Ich find's schon sehr abschreckend, wenn die Code-Beispiele fuer eine >> neue Sprache gleich wie hingerotzt aussehen. > > Meinst du die Beispiele aus dem Tutorial? Wenn ja, was findest du daran > hingerotzt? Die Syntax an sich, oder die Art und Weise, wie der Code > formatiert wurde?
yalu schrieb: > Das ist schon richtig, aber wer hat schon die Zeit, die vielen hundert > Programmiersprachen, die es derzeit gibt, einzeln auf ihre Eigenschaften > zu untersuchen? Nach irgendwelchen Kriterien muss man sich die interes- > santeren daraus aussuchen, um sich anschließend ihre Eigenschaften aus > der Nähe anzuschauen. Solche Kriterien können bspw. sein: > > - Ein Kumpel hat angefangen, die Sprache zu lernen, und ist begeistert. Kommt auf den Kumpel an, das kann Ja oder Nein bedeuten :-) > - Die Sprache kommt von IBM, Microsoft oder Google. Nicht gerade meine Favoriten ;-) > - Die Sprache wird in einem c't-Artikel vorgestellt. Ich lese keine c't mehr, seit sie behauptet haben, der Sound von Pinball Dreams fuer den PC sei besser als der der Amiga-Version. > - Die Sprache hat einen "Marktanteil" von über 40%. Zumindest duerfte man dann nicht auf ein totes Pferd setzen :-) > - Die Sprache ist im ICFP-Contest die "Programming Language of Choice > for Discriminating Hackers" geworden. Ausschlusskriterium ;-) > - ... > - Oder eben: Einer, der schon Jahrzehnte lang erfolgreich komplexe > Softwaresysteme programmiert, empfiehlt die Sprache oder hat sie > selber entwickelt. Ueberzeugt mich nicht wirklich. Im Gegenteil, wenn ich mir ansehe, was aus seiner Feder kommt, bin ich mir recht sicher, dass ich es nicht moegen werde :-) Ich muss aber zugeben, dass ich weder seine Biografie gelesen, noch im Detail studiert habe, was er so alles gemacht hat. In einem anderen Thread wurde auch "xxx hat das gesagt, der ist Linux-Kernal-Hacker" als Argument angebracht - sowas beeindruckt mich schon lange nicht mehr. Oft sind das auch nur Leute, die waren zur rechten Zeit am rechten Ort. Dagegen kenne ich 2 Entwickler-Genies, deren Namen kennt kein Schwein. > Ganz klar ist keines dieser Kriterien ein Garant für eine wirklich gute > Sprache, aber irgendwie muss man sich ja in der Vielfalt zurechtfinden. Nur, wenn man Lust auf neue Spielzeuge hat. :-) > Oder wie bist du auf die nach deinem Geschmack beste(n) Programmierspra- > che(n) aufmerksam geworden? Ich wuerde nicht behaupten, dass eine davon die beste ist - dafuer haben alle zu viele Fehler. Gucken wir mal meine Liste durch: - Basic musst man ja machen, wenn man einen C64 hatte und programmieren wollte. - 6510 Assembler draengte sich danach auf. - AmigaBasic war eben dabei und Basic kannte man schon. - 68000 Assembler musste ich machen, weil ich Demos programmieren wollte. - C draengte sich dann auf, als ich mehr im Bereich Anwendungsentwicklung machen wollte. Das war die zweite Sprache, in der das AmigaOS entwickelt wurde und wohl mit die am besten unterstuetzte. Spaeter gab es auch Leute, die viel in Modula gemacht haben - aber da konnte ich schon C und habe in Modula keine Vorteile gesehen. - ARexx war einfach praktischer als Shell-Skripte und viel im Umlauf. Irgendwann hat man sich das halt angeeignet. - Pascal wurde mir von der Schule aufgedraengt :-) - C++ war zuerst noetig fuer's Studium. Mein Interesse daran war begrenzt, von mir aus haette ich das so schnell nicht angefangen. Das lag hauptsaechlich daran, dass ich C schon lange nicht mehr wie Kernighan & Ritchie, sondern sehr modular, eigentlich schon objektorientiert programmiert habe. Da werden die Vorteile von C++ nicht gleich offensichtlich. - bash-Skripte - kommt man da auf Unix nicht automatisch drauf? Und irgendeinen kleinen Job gibt es ja immer zu erledigen. - Java war damals neu. Irgendwie war das Erscheinen von Java ein wenig wie mit Go heute, nur hat mir Java einen sofort greifbaren Vorteil geboten: Browser-Applets. Ein echter Mehrwert, dass der sich so gar nicht durchsetzt, konnte man ja noch nicht wissen :-) - Lisp war Pflicht im Studium. Nett, auch mal so eine Sprache gesehen zu haben, aber Lust auf mehr habe ich nicht gerade bekommen ;-) - Perl kam erst im Beruf. Es gab was an existierenden Perl-Skripten zu machen, also habe ich es gemacht. Ich glaube, den schlimmsten Code habe ich bisher in Perl gesehen. - Python habe ich tatsaechlich gemacht, weil mir ein Kollege damit in den Ohren lag. Da ich ihn kenne, wusste ich, dass ich es nicht sonderlich moegen wuerde. Aber die Abneigung hielt sich in Grenzen :-) Persoenlich verwende ich heute C++ am meissten. Fuer mich die flexibelste Sprache, den meissten Muell kann man ignorieren, eine umfangreiche, ueber die Jahre entstandene Bibliothek begrenzt den neidischen Blick auf's Java-Umfeld deutlich und der Anwendungsbereich vom Mikrocontroller bis zum Grossrechner ist ein wichtiges Argument fuer mich. Wie du siehst, habe ich wenig Interesse daran, Sprachen zum Selbstzweck zu lernen. Da muss ich schon einen Vorteil fuer mich sehen - und das tue ich sehr oft nicht. Wuerde ich was im Webfrontend-Bereich machen wollen, wuerde ich mir vieleicht mal php ansehen - vorher aber nicht. > Meinst du die Beispiele aus dem Tutorial? Wenn ja, was findest du daran > hingerotzt? Die Syntax an sich, oder die Art und Weise, wie der Code > formatiert wurde? Beides. Guck dir zum Beispiel mal das hier an: 50 func (file *File) Read(b []byte) (ret int, err os.Error) { 51 if file == nil { 52 return -1, os.EINVAL 53 } 54 r, e := syscall.Read(file.fd, b) 55 if e != 0 { 56 err = os.Errno(e) 57 } 58 return int(r), err 59 } Zuerst einmal die geschweiften Klammern. K&R haben es vorgemacht, alle machen es nach - aber inzwischen kann man Code bequem scrollen und es passen auch so mehr als 25 Zeilen auf den Bildschirm. Fuer's Auge wesentlich einfacher ist, den Marker fuer den Blockanfang und den Marker fuer das Blockende uebereinander zu setzen und den Block dazwischen einzuruecken. func, ret, err - heftige Verwendung von Abkuerzungen sind leider ueberall ueblich. Vieleicht um sich vom Laien abzugrenzen? b, r, e - ?!? Und das auch noch in einem Tutorial, wo besonders auf Les- und Verstehbarkeit geachtet werden sollte. Leerzeilen und Leerzeichen erhoehen die Lesbarkeit auch enorm. Die paar Bytes machen keinen arm. if ohne runde Klammern mag syntaktisch fuer diese Sprache einen Sinn ergeben, die Lesbarkeit erhoeht es sicher nicht. := Schauen wir mal, ob sich da der Erfinder nicht ein Ei in's Nest gelegt hat und wie oft die Anwender nach fehlenden oder zu vielen : suchen werden... if e != 0 - da schuettelt es mich besonders. Das sieht ja wirklich nach 70er-Jahre C aus :-(
>Spaeter gab es auch Leute, die viel in Modula gemacht haben - aber da >konnte ich schon C und habe in Modula keine Vorteile gesehen. Na man muss die Augen schon aufmachen... Sauberes Modulkonzept, saubere Bit-Operationen, keine wilde Pointer-Arithmetik. Gut, Garbage-Collector und richtige Object-Orientierung kam dann erst mit Oberon. Wobei letzteres zugegebener maßen nicht voll überzeugt hat. Aber dennoch vermissse ich die Srachen der ETH etwas. Sachen wie Ruby sind ja nett, aber ob es für so abstrakte Sprachen je einen gut optimierenden Compiler geben wird, der dann auch effiziente Hardware-Nahe Programmierung erlaubt?
> Zuerst einmal die geschweiften Klammern. K&R haben es vorgemacht, alle > machen es nach - aber inzwischen kann man Code bequem scrollen und es > passen auch so mehr als 25 Zeilen auf den Bildschirm. Fuer's Auge > wesentlich einfacher ist, den Marker fuer den Blockanfang und den Marker > fuer das Blockende uebereinander zu setzen und den Block dazwischen > einzuruecken. Finde ich zwar auch, aber nur weil's dir nicht gefällt, ist es nicht unbedingt schlechter Stil, sondern eben ein anderer. > func, ret, err - heftige Verwendung von Abkuerzungen sind leider > ueberall ueblich. Vieleicht um sich vom Laien abzugrenzen? Wo ist da das Problem? "return_value" wäre deutlich länger und enthält genau gar keine Zusatzinformation, denn man weiß auch so sofort, was "ret" ist. Und was hat das mit Laien zu tun? Bei denen sind die Namen meistens eher noch kürzer. > b, r, e - ?!? Und das auch noch in einem Tutorial, wo besonders auf Les- > und Verstehbarkeit geachtet werden sollte. Allerdings. > Leerzeilen und Leerzeichen erhoehen die Lesbarkeit auch enorm. Die paar > Bytes machen keinen arm. Ich wüßte nicht, wo da irgendwo ein zusätzliches Leerzeichen die Lesbarkeit verbessern könnte. Ich finde nur, daß die Leerzeichen teilweise suboptimal verteilt sind. > if ohne runde Klammern mag syntaktisch fuer diese Sprache einen Sinn > ergeben, die Lesbarkeit erhoeht es sicher nicht. Ich glaube, das liegt nur daran, daß es für einen C-Programmierer ungewohnt aussieht. > := Schauen wir mal, ob sich da der Erfinder nicht ein Ei in's Nest > gelegt hat und wie oft die Anwender nach fehlenden oder zu vielen : > suchen werden... Für mich sieht der Funktionskopf sehr verwirrend aus. Anscheinenden kommen entgegen aller anderen gängigen Sprachen die Parameter zuerst und die Returnwerte zuletzt. Irgendwo dazwischen ist noch was, das wohl sowas wie lokale Variablen zu sein scheint. Irgendwie alles mal durchgemischt. Und "b []byte" sieht für mich auch irgendwie rückwärts aus. Sind diese Sachen von irgendeiner Sprache, die als Basis herhalten mußte, geklaut, oder ist das alles nur so gemacht, damit's halt anders ist?
Stefan Salewski schrieb: >>Spaeter gab es auch Leute, die viel in Modula gemacht haben - aber da >>konnte ich schon C und habe in Modula keine Vorteile gesehen. > Na man muss die Augen schon aufmachen... Blah blah. Sorry, aber netter kann ich es nicht sagen. Wenn du Vorteile fuer dich siehst, ist das toll. Wenn ich keine fuer mich sehe, kann es natuerlich sein, dass ich doof bin - vieleicht habe ich aber nicht deine Probleme mit anderen Sprachen. > Sauberes Modulkonzept, saubere Bit-Operationen, keine wilde > Pointer-Arithmetik. Alles kein Problem. Fordert halt vieleicht etwas mehr Disziplin als in Modula.
Rolf Magnus schrieb: > Finde ich zwar auch, aber nur weil's dir nicht gefällt, ist es nicht > unbedingt schlechter Stil, sondern eben ein anderer. Hmja, genau das habe ich ja schon erwaehnt - nicht alles laesst sich als schlechter Stil abtun. Es ist definitiv schlechter lesbar. Unterhalte dich mal mit einem Lingusiten ueber sowas. Ich hab's gemacht und das kann interessante Erkenntnisse mit sich bringen - und den eigenen Stil wirklich verbessern. >> func, ret, err - heftige Verwendung von Abkuerzungen sind leider >> ueberall ueblich. Vieleicht um sich vom Laien abzugrenzen? > Wo ist da das Problem? "return_value" wäre deutlich länger und enthält > genau gar keine Zusatzinformation, denn man weiß auch so sofort, was > "ret" ist. Dann koennte man auch f, r und e nehmen. Lernt man ja, wenn man die Sprache lernt. Sinkt die Produktivitaet so sehr, wenn man die Namen ausschreibt? >> Leerzeilen und Leerzeichen erhoehen die Lesbarkeit auch enorm. Die paar >> Bytes machen keinen arm. > Ich wüßte nicht, wo da irgendwo ein zusätzliches Leerzeichen die > Lesbarkeit verbessern könnte. Ich finde nur, daß die Leerzeichen > teilweise suboptimal verteilt sind. Absaetze strukturieren den Code besser und erhoehen die Lesbarkeit. Man erkennt leichter direkt zusammenhaengende Codebloecke. Erst neulich wieder auf der Arbeit gehabt: 300 Zeilen Code ohne eine Leerzeile. Auf den ersten Blick sieht man nur ein Meer von Buchstaben. Auch wichtig: In der Schriftsprache ist zwischen zwei Worten ein Leerzeichen. Das Gehirn ist (wenn man lesen kann) darauf trainiert, Wortanfaenge am Leerzeichen zu erkennen.Deswegen ist es klug, das bei Code auch so zu halten. Also kommt vor jedes Wort ein Leerzeichen. Wir koennen darueber streiten, ob vor die runde Klammer bei Funktionen auch eins sollte. 50 function ( file *File) Read( b []byte) ( ret int, err os.Error) 51 { 52 if( file == nil) 53 { 54 return -1, os.EINVAL 55 } 56 57 r, e := syscall.Read( file.fd, b) 58 59 if( e != 0) 60 { 61 err = os.Errno( e) 62 } 63 64 return int( r), err 65 } >> if ohne runde Klammern mag syntaktisch fuer diese Sprache einen Sinn >> ergeben, die Lesbarkeit erhoeht es sicher nicht. > Ich glaube, das liegt nur daran, daß es für einen C-Programmierer > ungewohnt aussieht. Mit den runden Klammern erfasst man auf einen Blick, von wo bis wo das "Argument" fuer das if geht. Das erhoeht die Lesbarkeit durchaus. Vor Allem, wenn >> := Schauen wir mal, ob sich da der Erfinder nicht ein Ei in's Nest >> gelegt hat und wie oft die Anwender nach fehlenden oder zu vielen : >> suchen werden... > Für mich sieht der Funktionskopf sehr verwirrend aus. Anscheinenden > kommen entgegen aller anderen gängigen Sprachen die Parameter zuerst und > die Returnwerte zuletzt. So genau habe ich mich dann auch nicht eingearbeitet. Die Idee, dass die Rueckgabewerte zuletzt kommen, weil ja auch die Rueckgabe zuletzt kommt, faende ich noch einsichtig. Machen wuerde ich es trotzdem nicht ;-) Wenn man sich viel mit Assembler beschaeftigt hat, sieht man das bestimmt anders. Aus dieser Sicht ist z.B. eine Funktionsdeklaration mit nur einem Rueckgabewert obskur. Da liegt eher eine Funktionsdeklaration nahe, die Eingabe, Ein-/Ausgabe und Ausgabewerte hat. So eine Sprache wuerde ich mir mal naeher ansehen. :-) > Sind diese Sachen von irgendeiner Sprache, die als Basis herhalten > mußte, geklaut, oder ist das alles nur so gemacht, damit's halt anders > ist? Gute Frage. Wenn man sich den Rest ansieht, schaut's auch nicht so aus als waere die Sprache 2009 entstanden, sondern eher 1979. -1 und EINVAL als Rueckgaebewerte, errno und Filedeskriptoren... kein OO, eher ein duenner, funktionaler Layer auf Posix.
> Es ist definitiv schlechter lesbar. Unterhalte dich mal mit einem > Lingusiten ueber sowas. Ich hab's gemacht und das kann interessante > Erkenntnisse mit sich bringen - und den eigenen Stil wirklich > verbessern. Ich finde es auch schlechter lesbar, aber würde diese Meinung nicht als "definitiv" ansehen. >>> func, ret, err - heftige Verwendung von Abkuerzungen sind leider >>> ueberall ueblich. Vieleicht um sich vom Laien abzugrenzen? >> Wo ist da das Problem? "return_value" wäre deutlich länger und enthält >> genau gar keine Zusatzinformation, denn man weiß auch so sofort, was >> "ret" ist. > > Dann koennte man auch f, r und e nehmen. Lernt man ja, wenn man die > Sprache lernt. Nein, denn was hier "func", "ret" und "err" bedeuten, ist offensichtlich, im Gegensatz zu "f", "r" und "e". > Sinkt die Produktivitaet so sehr, wenn man die Namen ausschreibt? Kommt drauf an, wie oft man sie schreiben muß. Meiner Meinung nach steigt die Lesbarkeit nicht, dafür aber die Wahrscheinlichkeit, einen Tippfehler zu machen, der einen dann nochmal einen zusätzlichen editier-/compiler-Vorgang kostet. > Absaetze strukturieren den Code besser und erhoehen die Lesbarkeit. Bei so kurzem Code? Naja, ich würde da auch welche machen, aber so viel Unterschied macht's in diesem Fall nicht, da schon durch die Blöcke eine Unterteilung leicht erkennbar wird. > Manerkennt leichter direkt zusammenhaengende Codebloecke. Erst neulich > wieder auf der Arbeit gehabt: 300 Zeilen Code ohne eine Leerzeile. Auf > den ersten Blick sieht man nur ein Meer von Buchstaben. Das ist klar. > Auch wichtig: In der Schriftsprache ist zwischen zwei Worten ein > Leerzeichen. Das Gehirn ist (wenn man lesen kann) darauf trainiert, > Wortanfaenge am Leerzeichen zu erkennen.Deswegen ist es klug, das bei > Code auch so zu halten. Also kommt vor jedes Wort ein Leerzeichen. Außer bei öffnenden Klammern. Da macht man auch in der Schriftsprache keine Leerzeichen vor das Wort. > Wir koennen darueber streiten, ob vor die runde Klammer bei Funktionen > auch eins sollte. Davor finde ich es zumindest besser, als dahinter. > 50 function ( file *File) Read( b []byte) ( ret int, err os.Error) Das finde ich nicht besonders schön. Dadurch, daß nach einer öffnenden Klammer ein Leerzeichen kommt, vor einer schließenden aber nicht, sieht es sehr asymmetrisch/holperig aus. Und man erkennt die Trennung der einzelnen Teile nicht mehr so gut, z.B. bei dem Teil am Schluß. Das ist ein Block, und der wird durch die allein "im Wald" stehende öffnende Klammer irgendwie auseinander gerissen. Ich würde das eher so bevorzugen: 50 function (file *File) Read (b[] byte) (ret int, err os.Error) >>> if ohne runde Klammern mag syntaktisch fuer diese Sprache einen Sinn >>> ergeben, die Lesbarkeit erhoeht es sicher nicht. >> Ich glaube, das liegt nur daran, daß es für einen C-Programmierer >> ungewohnt aussieht. > > Mit den runden Klammern erfasst man auf einen Blick, von wo bis wo das >"Argument" fuer das if geht. Das erhoeht die Lesbarkeit durchaus. Das setzt aber voraus, daß die öffnende Klammer auch an diesem "Argument" hängt und nicht am if, also: 52 if (file == nil) Bei deiner Variante bringt die öffnende Klammer von der Lesbarkeit her gar nichts, und wo das "Argument" aufhört, sieht man daran, daß die Zeile zu ende ist, also bringt auch die schließende Klammer nichts.
Peter Stegemann (pst) schrieb am 10.01.2010 um 16:34 Uhr: >Stefan Salewski schrieb: >[...] >Blah blah. >Alles kein Problem. Fordert halt vieleicht etwas mehr Disziplin als in >Modula. Natürlich ist das mit C kein Problem -- mit Assembler erst recht nicht. Aber es soll Leute geben, die nach eleganteren, sicheren, schöneren, einfacherten, besser portierbaren, ... Sprachen suchen. Mit Verlaub, wer zwischen Modula und C keine Unterschiede sieht (ok, Du hast VORTEILE geschrieben), der hat nicht besonders gut hingesehen.
Autor: Peter Stegemann (pst) Datum: 10.01.2010 17:02 >Es ist definitiv schlechter lesbar. Unterhalte >dich mal mit einem Lingusiten ueber sowas. Mit solchen Aussagen sollte man auch etwas zurückhaltender sein. Der Mensch ist stark durch seine bisherigen Erfahrungen geprägt. Da gibt es in unterschiedlichen Kulturen und Generationen deutliche Unterschiede.
Peter Stegemann schrieb: >> - Die Sprache ist im ICFP-Contest die "Programming Language of Choice >> for Discriminating Hackers" geworden. > > Ausschlusskriterium ;-) 2007 war's bspw. C++, ein paar mal zuvor auch schon. > Persoenlich verwende ich heute C++ am meissten. Fuer mich die > flexibelste Sprache, ... Upps ;-) >> Ganz klar ist keines dieser Kriterien ein Garant für eine wirklich gute >> Sprache, aber irgendwie muss man sich ja in der Vielfalt zurechtfinden. > > Nur, wenn man Lust auf neue Spielzeuge hat. :-) Man kann ja ziemlich schnell alle so genannten esoterischen Programmier- sprachen wegfiltern, dann bleiben aber immer noch viel zu viele übrig. Man kann stärker filtern und nur diejenigen betrachten, die mindestens einen zweistelligen Prozentanteil an der weltweit entwickelten Software ausmachen. Dann bleibt eben der Mainstream: C, C++, Java und PHP, viel- leicht noch Perl, Python, Ruby und C#. Seine favorisierte Sprache nur aus diesen auszuwählen ist zwar legitim und sicher oft auch sinnvoll, hat aber mit einer Auswahl nach den besten Spracheigenschaften, wie du oben vorgeschlagen hast ( > wenn die Sprache gut ist, sollte sie durch ihre Eigenschaften > ueberzeugen koennen, nicht durch ihren Erfinder. ), nicht mehr viel zu tun. > Wie du siehst, habe ich wenig Interesse daran, Sprachen zum > Selbstzweck zu lernen. Da muss ich schon einen Vorteil fuer mich sehen > - und das tue ich sehr oft nicht. Mir geht es genau so. Aber vielleicht sehe ich im Vergleich zu dir mehr Verbesserungspotenzial bei den aktuellen Mainstream-Sprachen, so dass sich aus meiner Sicht ein etwas schärferer Blick auf die aktuelle Ent- wicklung in diesem Bereich lohnt. Ich selber beschäftige mich beruflich und auch hobbymäßig viel mit Steuerungsaufgaben und programmiere deswegen hauptsächlich in C (für kleine Prozessoren) und C++ (für große Prozessoren), weil das derzeit außer Assembler so ziemlich die einzigen Sprachen sind, die hardwarenahe und echtzeittaugliche Programmierung ermöglichen. Daneben verwende ich Python für alles, was nicht hardwarenah sein muss und wo die Ausfüh- rungsgeschwindigkeit eine untergeordnete Rolle spielt, insbesondere auch für Anwendungen, die nach kurzer Zeit wieder weggeschmissen werden. Dabei fällt mir immer wieder auf, dass man viele Probleme in Python so elegant, durchsichtig und kurz formulieren kann, dass ich mich danach mit C++ wie an Krücken und mit schmutziger Brille fühle. Aber alles in Python zu machen, geht halt nicht, und auch Python hat einige Macken. Deswegen halte (bisher vergeblich) Ausschau nach zwei weiteren Sprachen: Die erste ist zwischen C++ und Python angesiedelt. Ihre Schwerpunkte sind die hardwarenahe Programmierung und eine hohe Ausführungsgeschwin- digkeit. Sie bietet aber gegenüber C++ zusätzliche Features, die es ähnlich (aber nicht notwendigerweise ganz so gut) wie in Python ermög- lichen, mit weniger Code mehr auszusagen. Das verringert nicht nur die Tipparbeit, sondern steigert vor allem die Entwicklungsgeschwindigkeit und die Wartbarkeit. Natürlich muss die Sprache auf unterschiedlichen Hardwareplattformen einsetzbar sein. Ein Kandidat, der zumindest in diese Richtung zielt, ist D. Je nachdem, wie sich Go weiterentwickelt, könnte aber auch dieses in Frage kommen. Die zweite Sprache ist oberhalb von Python angesiedelt. Sie liegt wesentlich näher beim Programmierer als bei der Hardware, bietet also einen sehr hohen Abstraktionsgrad. Da es mir nicht schwer fällt, in mathematischen Strukturen zu denken, darf die Sprache gerne deklarativ sein. Kurze Entwicklungszeiten sind hier wichtiger als kurze Ausfüh- rungszeiten, wobei es trotzdem schön wäre, wenn die Ausführungsgeschwin- digkeit mindestens ein Fünftel von derjenigen von C++ wäre. Die Sprache sollte auf unterschiedlichen Betriebssystemen (Linux, Windows, OS-X) einsetzbar sein. Nach meinen bisherigen Erfahrungen werde ich hier am ehesten im Lager der Funktionalsprachen fündig. Haskell¹ ist hier einer der Kandidaten und mittlerweile nicht einmal mehr so arg exotisch. Ich stecke zugegebenermaßen einige Freizeit in diese Suche. Das ist aber kein Selbstzweck, sondern die Suche nach Fortschritt, der ohne Investi- tion nicht möglich ist :) >> Meinst du die Beispiele aus dem Tutorial? Wenn ja, was findest du daran >> hingerotzt? Die Syntax an sich, oder die Art und Weise, wie der Code >> formatiert wurde? > > Beides. Guck dir zum Beispiel mal das hier an: > ... Die Mängel die du danach nennst, sind in meinen Augen Oberflächlichkei- ten und Geschmacksachen, über die es sich nicht zu streiten lohnt. Sie haben mit der Qualität der Programmiersprache an sich wenig zu tun. ¹) Obwohl ich die Syntax nicht als das wichtigste Kriterium bei der Bewertung von Programmierpsrachen sehe: Die Syntax von Haskell (insbesondere der neueren Versionen) ist einfach megagenial!
Ist das der Wettbewerb "Sprachen für Weicheier"? LISP ist das einzig wahre, ihr Memmen!
yalu schrieb: > Die Mängel die du danach nennst, sind in meinen Augen Oberflächlichkei- > ten und Geschmacksachen, über die es sich nicht zu streiten lohnt. Sie > haben mit der Qualität der Programmiersprache an sich wenig zu tun. Nein, mit der Qualitaet der Programmiersprache nicht, aber mit der Qualitaet der Programme. Und diese Erkenntnis setzt sich leider nicht durch. Man muesste sich nur mal ueberlegen, Buecher wuerden mit dieser Einstellung verfasst - dann wuerde gar keiner mehr lesen. Das ist heute leider so wie mit den 5ern in Mathe, mit denen man angeben kann - kann ein Entwickler seinen eigenen Code nach ein paar Jahren nicht mehr lesen, ist das eine lustige Anektode, die von jedem als normal angesehen wird.
Peter Stegemann schrieb: > yalu schrieb: > >> Die Mängel die du danach nennst, sind in meinen Augen Oberflächlichkei- >> ten und Geschmacksachen, über die es sich nicht zu streiten lohnt. Sie >> haben mit der Qualität der Programmiersprache an sich wenig zu tun. > > Nein, mit der Qualitaet der Programmiersprache nicht, aber mit der > Qualitaet der Programme. Also ich habe wirklich überhaupt keine Probleme beim Lesen der Codebeispiele. Kann es sein, dass du selten Code on anderen Leuten (von Kollegen, aus dem Netz usw.) liest? Wo jemand die geschweiften Klammern hinsetzt, ist mir völlig egal, solange er die Einrückungen richtig und konsequent macht. Was abgekürzte Schlüsselwörter und Identifier betrifft: Es gibt für mich, auch ohne dass ich den Code gelesen hätte, keinen Zweifel wofür die Abkürzungen func, ret und err stehen. Auch die ganz kurzen Variablennamen (b, r und e) sind in diesm Fall ok, weil aus dem Kontext (der maximal 5 Zeilen lang ist) sofort erkennbar ist, wofür sie stehen. Generell finde ich es sogar guten Stil, sich bei der Länge der Variablennamen an der Größe des Gültigkeitbereichs der Variable zu orientieren.
yalu schrieb: > Also ich habe wirklich überhaupt keine Probleme beim Lesen der > Codebeispiele. > Kann es sein, dass du selten Code on anderen Leuten (von Kollegen, aus > dem Netz usw.) liest? Das ist mein taegliches Brot. Und ich muss auch taeglich komplexe Fehler darin suchen. Kann es sein, dass du das hoechstens zum Spass machst?
Peter Stegemann schrieb: > Das ist mein taegliches Brot. Und ich muss auch taeglich komplexe Fehler > darin suchen. Kann es sein, dass du das hoechstens zum Spass machst? Nicht nur, ich nehme auch Geld dafür. Ich mach's auch ziemlich oft und schon ziemlich lange, sonst hätte ich mich an die unterschiedlichen Stile der einzelnen Programmierer nicht gewöhnen können. Manchmal mach ich's auch nur für Geld. Dann kann es schon einmal passieren, dass ich mich über einen Programmierstil ärgere, den ich vorher noch als akzeptabel empfunden habe. Im Extremfall kann das sogar jeden Stil betreffen, der nicht mein eigener ist ;-) Für das Anschauen des Go-Tutorials habe ich aber kein Geld bekommen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.