mikrocontroller.net

Forum: PC-Programmierung Installieren von Go


Autor: Daniel V. (volte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: min (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
google Go gogo go gaga

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_ru...

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).

Autor: Daniel V. (volte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Daniel V. (volte)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
irgendwie merkt man hier eine starke Abneigung gegen die Sprache.
Woher das?

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir ist es jedenfalls keine Abneigung.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ganz zu schweigen von dem traditionsreichen Spiel gleichen Namens

Autor: Henk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So wie ich das verstehe, ist diese "derzeit existente" GO!- Sprache eben 
jene von Google- Entwicklern.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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]"

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gerry E. (micky01)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :-)

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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-paradig...
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?

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-(

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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?

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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?

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: zwieblum (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das der Wettbewerb "Sprachen für Weicheier"?

LISP ist das einzig wahre, ihr Memmen!

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.