Weitverbreitete Programmiermythen...

Weitverbreitete Programmiermythen... (43 Beiträge, 735 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi !

Weil ich in einem anderen Thread drüber gestoßen bin - machen wir doch den allgemeinen... Ich beginne mal - plus der Erläuterung, warum's Mythen, net Fakten sind

Mythos: In Java/C# gibt's keine Pointer.
Dadurch wird eine beliebte Fehlerquelle vom Programmierer genommen - und Programme tendenziell schneller und sauberer fertig.

Nun ja... Leider falsch.
In Java und C# wurden Pointer mal umbenammst - in Referenzen...
Und nachdem man - sobald man Cachen will - sinnvollerweise auf weak references ausweicht, sieht's ja so aus:
1.) weak references mit null initialisieren
2.) vor jedem Zugriff checken, ob die Referenz net durch den GC null wurde
3.) notfalls Objekt instanzieren
.... Sieht verdächtig ähnlich nach umständlicher Pointerbehandlung aus

Mythos: Goto considered harmful.
Goto's sind ein Hinweis auf schlecht strukturierte Programme und sind zu vermeiden

Fakt ist vielmehr, daß Goto's (beziehungsweise deren Erweiterungen longjmp und setjmp wertvolle Tools sind - auf die man nicht verzichten sollte.

Angenommen, du bewegst dich tief unten in Subroutinen - besonders aktuell bei Rekursivem Code.
Natürlich kann man alles mit 150tausend Klammern lösen und jedes mal den Stackframe beim Return wiederherstellen lassen und sich nach oben durchhangeln... Stattdessen kann man eben das System mit einem einzigen longjmp entlasten. Sinnvoll eingesetzte Goto's sind wertvoll...

Ich werde trotzdem jedem Programmieranfänger sehr eindringlich einreden, daß gotos ein Unding schlechthin sind. Bis er mal so weit ist, daß gotos wirklich Sinn machen, wird er's ohnehin erkennen können.

Und am Anfang gibt's halt doch einige Konstrukte, wo gotos sehr verlockend und, auf lange Sicht gesehen, sehr problematisch sind. Insgesamt sind die Situationen, wo ein goto mehr Sinn macht als den Code anders zu strukturieren oder das Problem über Exception Handling zu lösen, eher selten.

________________________________________________________________________
There's a typo in the Bible.
It should read "The geek shall inherit the earth".

Hmmm... Dachte ich mir doch gleich, daß setjmp/longjmp net gerne geschluckt wird

Ich glaube aber, daß wir uns da alle in was verrannt haben.
Ich vermute mal, daß viele von uns (zumindest aber ich)
- mit Basic/Asse/sonstigem Spaghetti-Code begonnen
- die Programme zwar funktionierten, wir die aber nie wieder angreifen wollten
- Erweiterungen ziemlich unmöglilch bis absurd wurden
- Prozedurale Sprachen uns ein anderes Herangehen an Probs ermöglichten
- und wir alle brav aus aller Fachliteratur lernten, daß goto's crappy sind.

Ich dachte bis vor wenigen Jahren genauso... Bis ich mir "Advanced Programming in the Unix Environment" vom Stevens reingezogen habe - und wie alle seiner Bücher betrachte ich auch das als eine Bibel... Siehe da, er brach eine Lanze für setjmp/longjmp - und er hat bei genauerer Betrachtung absolut Recht.

Also ich persönlich habe mich des öfteren bei Standard-Anfängerspielen gefragt (zB einem Othello-Spiel nach min/max-Algo), wieso andere Programme massiv flotter waren... Nun ist's mir klar

jmp's werden sehr selten verwendet - eben [auch] weil wir es uns alle so einlernten. Bei einem Code-Review meiner Sourcen nach Lesen des Buches fand ich vieles, was sich einfacher, sinnvoller und Ressourcenschonender via setjmp/longjmp lösen ließ... und wirklich spürbar performanter, nicht nur meßbar.

EDIT:
Das "Einfacher" streich ich mal... Zumindest Lesbarer ist [für mich] "sauberer" prozeduraler Code... Kann aber auch schlichte Gewöhnungssache sein.

28.03.2006, 15:40 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Falsches Forum.

Auch wennst noch so klug********* willst, hier wirst net wirklich auf Gehör stoßen, denn 99% der User hier interessiert das Nüsse.

EDIT:

Student: Wäre das z.B. ein Thema für eine Dissertation?
Vortragender: Wenn Sie dieses Problem lösen, können Sie die Abkürzung über den Nobelpreis nehmen.

28.03.2006, 15:40 Uhr - Editiert von Somnatic, alte Version: hier

Nein, das mußte sein:

1.) Da in einem anderen Thread hier jemand erklärte, daß C# viel besser als C++ sei, weil es keine Pointer gäbe

2.) Wenn nicht hier klugshicen, wo dann ?
3.) Hoffte ich auf andere begeisterte Gehirnonanierer, die ebenfalls ein paar Coder-Mythen beistellen

EDIT: Das verbleibende eine Prozent der User, die's interessieren könnte... Sowenig wären das gar nicht, und Dich hätt' ich in Verdacht *gg*

28.03.2006, 15:43 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Ui, eine Diskussion "Programmiersprache A ist besser als Sprache B" ist ungefähr genauso sinnvoll wie "Englisch ist besser als Französisch".
Hmmm .. klug*PIEP* .. wo isn das gern gesehen ... in der Unix Welt

Was ich net ganz verstehe: Du willst cachen, gut. Du klaust dir das Objekt und nutzt es eigentlich über seinen (eigentlich gedachten) Lifecycle hinweg. Wenn der GC zuschlägt, erstellst du es dir neu. Wo ist der Unterschied zu einem static Konstrukt in Java? Die Daten stehen dir ja wenn du es neu erstellen musst auch nicht mehr so zur Verfügung, wie sie es im ersten Object waren?

Student: Wäre das z.B. ein Thema für eine Dissertation?
Vortragender: Wenn Sie dieses Problem lösen, können Sie die Abkürzung über den Nobelpreis nehmen.

Schau an, da hat einer eine sehr frühe Java-Version (vor 1.2)

Die Idee ist folgende - und sie macht Sinn:
In deinem Programm hast du einige Klassen, die du einfach fix brauchst - auf die darfst du nicht verzichten - sie werden wie bisher behandelt. Wenn eine Referenz drauf ist, leben sie (außer natürlich reinen zirkulären klassen, die nicht mehr erreichbar sind und bla...)

Du hast jetzt aber auch oft Daten (Zwischenergebnisse, Werte aus der DB, ...), die du zwischenspeichern willst. Wenn dein Speicher allerdings knapp wird, soll nicht dein Prozeß sterben - sondern nur automatisch die gecachten Objekte gelöscht werden, die du wieder erzeugen könntest...

An sich eine sehr praktische Lösung. Du füllst Memory, solange es da ist - und wenn keines mehr verfügbar ist, werden vom GC die LRU-Objekte mit weak-References freigegeben... So wie es sein soll...

Nur mußt du halt wieder genauso wie mit Pointern coden... Nur bei Pointern bestimmst selber dreigaben, wärend in einer Sandbox der GC jederzeit zuschlagen kann - und Du daher bei jedem Zugriff prüfen mußt...

Bezüglich goto: Das musst du Anfängern eintrichtern! Immer und immer wieder! Weil man damit einfach extrem viel pfuschen kann, und sie dann inflationär eingesetzt werden. Wenn jemand gut genug ist, dass er diese Möglichkeiten wirklich nur dann einsetzt, wenn sie die sinnvollste Lösung sind, dann soll er es von mir aus machen.

Suche im Forum
Forums-FAQ
Kino 2006
Täglich frische Sudokus

Also mir persönlich ist es wirklich viele Jahre lang so gegangen, daß ich niemals ein goto verwendet habe... "weil man es nicht so macht".

Es war mir auch wurscht, wenn man dadurch zigfach vernestete Klammerebenen hatte - und über longjmp's bin ich - zu meiner Schande - überhaupt erst seeehr spät gestolpert.

Für mich war "kein goto" einfach ein Paradigma, eine Grundregel, über die ich nicht einmal mehr nachdachte... Ging es Dir nicht ähnlich ?

Wobei Du natürlich nach wie vor Recht hast, daß ich es Anfängern ausreden würde

zum Glück gibts Assembler, da braucht man das immer *g*

lg,

Eliot

"640kB is enough for everyone."

[x] privat

      GOTO 100
      WRITE (*,*) 'Hallo'
100  WRITE (*,*) 'Welt'
C  Ausgabe: Welt

      END

geil sind ja die goto anweisungen wo man 30 seiten im code runterspringt zu einer nichtsagenden zahl(weil nicht dokumentiert) und von dort wieder 30 seiten weiterspringt zu einer nichtsagenden zahl(weil nicht dokumentiert), der enwicklungsstop des programmes 1978 war und beim neu compilen das programm anders rechnet als früher. das know how von damals nicht mehr in der firma vorhanden ist um irgendwelche berechnungen nachvollziehen zu können die in dem ding geschehen. und das wollte die firma haben das es ein feriali verbessert. rofl.

Zitat:Ubi Pus, ibi evacua ("Wo Eiter ist, dort entleere ihn")

um auch was beizusteuern, weil ich mich da mal ein bissi reingelesen hab (ohne jetzt weit ins detail zu gehen, wollt einfach nur wissen wie's is

)

select count(1) ist schneller als select count(*)

Schwedenfilme? Schwedenfilme!

ich hoffe dass die 2te spalte eine indexspalte ist

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
FMD

welche 2te spalte??

Schwedenfilme? Schwedenfilme!

select(1)
=====^ diese

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
FMD

weiss immer noch nicht was das damit zum tun hat?!

Schwedenfilme? Schwedenfilme!

macht nix

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
FMD

na erklärs mir halt

Schwedenfilme? Schwedenfilme!

* in zusammenhang mit einer aggregatsfunktion NICHT zu benutzen nutzt dir nur etwas wenn die angegebene spalte einen index besitzt. indexe besitzen nen eigenen baum und können vom rdbms wesentlich schneller durchsucht werden.

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
FMD

Und wieder ein Mythos - denn das ist abhängig vom RDBMS

Nicht alle RDBMS können bei Aggregatfunktionen den Index nutzen... zB PostgreSQL konnte es lange nicht.

Dort galt, daß ein

SELECT MAX(id) FROM tabelle

weitaus langsamer war (Sequential Access) als ein

SELECT id FROM tabelle ORDER BY id DESC LIMIT 1

es gibt nur 10 arten von menschen. diejenigen die das binärsystem verstehen, und die die es nicht tun.
FMD

Yup - ist ein Punkt!!!

du müßtest mal deinen nick ändern, wenn du nicht 2000 postings gestern gemacht hast
glaubt dir keiner, dass du neukunde bist

Am schönsten ist WIEN im Rückspiegel

Also dass es in Java Pointer bzw. Referenzen gibt, dürfte ja relativ klar sein. Spätestens dann, wenn man seine erste NullPointerException bekommen hat... Dafür gibt es aber keine Pointerarithmetik und keine Unterscheidung zwischen Pointern und Referenzen...

Das Vergleichen ist das Ende des Glücks und der Anfang der Unzufriedenheit.

Søren Kierkegaard (1813 - 1855)

gähn .. programmieren für daus erste stunde

rennegade@gmx.at

Gratulation. Dein erstes Posting dem ich vorbehaltlos zustimmen kann

*duckrenn*

Ad Goto: Ein Freund von mir hats mal fundiert in Worte gefasst, siehe http://linuxpunk.org/goto.html .

Zu kreativer verwendung von goto und anderen Programmieralbträumen: http://thedailywtf.com/

Google-Pagerank-Abuseage:
mirror
random crap
slackware mirror

29.03.2006, 01:10 Uhr - Editiert von Robe, alte Version: hier

Fakt ist vielmehr, daß Goto's (beziehungsweise deren Erweiterungen longjmp und
setjmp wertvolle Tools sind - auf die man nicht verzichten sollte.

Angenommen, du bewegst dich tief unten in Subroutinen - besonders aktuell bei
Rekursivem Code.
Natürlich kann man alles mit 150tausend Klammern lösen und jedes mal den
Stackframe beim Return wiederherstellen lassen und sich nach oben
durchhangeln... Stattdessen kann man eben das System mit einem einzigen
longjmp entlasten. Sinnvoll eingesetzte Goto's sind wertvoll...

Das ist - mit einem Wort - Unsinn.

a) nachlesen, was TRO ist und wann ein Compiler das machen kann

b) nachlesen, wie unsauber longjmp() normalerweise implementiert ist und wo es überall Probleme bereiten kann ... In modernen Sprachen gibt es nicht ohne Grund try/catch usw.

Ein goto ist höchstens dann "wertvoll", wenn Code dadurch einfacher wird, das ist aber sehr selten der Fall (meistens ist es nur Denkfaulheit, die dazu führt).

mjy@geizhals.at

Warum sollten wir es Unternehmen mit Eigeninteresse erlauben, das Gleichgewicht der freiheitlichen Grundrechte aus dem Lot zu bringen und dabei die Rede- und Ausdrucksfreiheit, die freien Märkte, den wissenschaftlichen Fortschritt, die Verbraucherrechte, die Gesellschaftsstabilität und das Ende des materiellen und informationstechnischen Mangels aufs Spiel setzen? Weil jemand ein Lied klauen könnte? Das erscheint mir doch als ziemlich fadenscheinige Ausrede.
-- John Gilmore

1.) Was genau soll an longjmp unsauber implementiert sein ?
2.) try/catch hat nun mal gar nix mit jongjumps zu tun
3.) Natürlich bin ich als Entwickler immer denkfaul - drum setzte sich ja Perl durch
4.)

2) und mit catch/finally ???

werden die finally ausgeführ, beim "goto" ??

1.) Was genau soll an longjmp unsauber implementiert sein ?

Dachte ich mir, daß du dich damit nicht wirklich beschäftigt hast... longjmp() muß am Stack ziemlich herumfuhrwerken. Du kannst es dir ja mal disassemblieren. Im allgemeinen gilt:


       longjmp()  and  siglongjmp() make programs hard to understand and main-
       tain.  If possible an alternative should be used.

(aus der manpage)

2.) try/catch hat nun mal gar nix mit jongjumps zu tun

Exceptions sind die moderne Art, aus einer beliebigen Rekursionsebene zu einem vordefinierten Punkt zu springen (wo dann wohl Fehler behandelt werden sollen).
mjy@geizhals.at

Natürlich werkelt longjmp am Stack - das ist ja seine Funktion.
Tatsächlich allerdings weit effizienter als viele returns...

und try/catch hat IMHO echt nix mit longjmps zu tun - eher mit goto's

Wobei ein extrem kaskadiertes try/catch-Gschichterl auch mühsam sein kann...

longjmp macht also nicht immer Sinn - sinnlos ist es deswegen net

Was sagst du dazu ?

http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/04/22/118161.aspx

Wobei der Autor net gerade der kleine Unbekannte von nebenan ist...

Was sagst du dazu ?

Seine Meinung darf er behalten.

Wobei der Autor net gerade der kleine Unbekannte von nebenan ist...

"oldnewthing" sagt mir nichts, auf http://blogs.msdn.com/user/Profile.aspx?UserID=2905 steht auch nichts. Du als Fan wirst mir aber sicher verraten, welch großer C#-Guru das sein soll.

mjy@geizhals.at

Raymond Chen ist der Autor... Aber es ist ja nicht wichtig, /wer/ es schrieb sondern was er sagte... Exceptions /sind/ sauschwierig in der Verwendung - dem schließe ich mich an... Und nachdem ich alten Code von mir selbst gedanklich mit dem gebrachten durchging - habe ich da sicher einige Bugs drinnen...

Bei "normalem" Errorcode-Checking bin ich mir hingegen sicher, daß alles paßt...

Also ich werde in Zukunft Exceptions meiden wie die Pest

mit "es gibt keine pointer" ist halt nicht das gemeint was du schreibst...
das müsste heissen es gibt keine "untypisierten" pointer

natürlich gibts (es gibt NUR) referenzen auf objekte, diese können auch null sein
(eh klar)

nur kannst du daraus jetzt nicht "unsafe casts" machen
du kannst zu der referenz nicht einfach, 34 dazuzählen, in der "hoffnung" dass da dann das nächste objekt ist, ...

usw.

(zum goto sag ich bessern nix..., vorallem wenn es mit ausführungsgeschwindigkeit argumentiert wird...)

- Ausführungsgeschwindigkeitsunterschiede Longjmp/"normaler Weg" sind extrem
- wo ist nun der Unterschied, wenn ich meinen Array of objects habe zu C ? Da wie dort verwende ich dann mein objekt[12], oder ?

ad1: höchstens in ganzbestimmten sonderfällen, relevant (im vergleich zur restlichen ausführungszeit) und deshalb ist die "allgemeingültige regel" "longjmp ist gut" nicht zutreffend
(und diese sonderfälle lassen sich TEILWEISE sicher auch anders "lösen" z.b. rekursion ersetzen durch nicht rekursive funktionen...) also im endeffekt nochweniger fälle

ad2: so hab ich das nicht gemeint...

(sondern dass man zu einer ref auf ein object (z.b. objekt[1]) einfach integer 48 dazuzählen kann und dann das objekt[13] erhält (ob das da jetzt wirklich da ist oder auch nicht (weil array z.b. nur 9 elemente enthält,...)

und wenn nicht, passiert böses oder auch nicht (zufällig)

29.03.2006, 14:03 Uhr - Editiert von adhoc, alte Version: hier

ad ad1

longjmp /ist/ gut. Natürlich kannst Du immer ohne longjmp auskommen - nur macht das Vermeiden von longjmp net zwingend Sinn.

rekursionen... /sind/ auch gut.

Der Witz ist eben, daß es immer um den Einsatzzweck geht... Alles mit rekursionen zu vergewaltigen macht kaum Sinn...

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung