Was muss ein guter Programmierer können?

[Cpp_Junky]

Ich finde es ist gar nicht mal so wichtig, das man eine Sprache top beherrscht und der super-Mathematiker ist.
Ein Programmierer muss eigentlich nur wissen, wie
a) Computer und OS im Detail funktionieren
b) Programmiersprachen funktionieren
c) Wie man Problemstellungen und Anforderungen analysiert

Der Programmierer muss die verschiedensten Werkzeuge (Programmiersprachen, Script-Sprachen, Datenbanken etc) je nach Problemstellung, nach kürzester Zeit instiktiv erlenen können.
Und er muss die Problemstellung verstehen und mit den benötigten Werkzeugen schnell und kompentent lösen.

[volkard]

Cpp_Junky schrieb:

Ich finde es ist gar nicht mal so wichtig, das man eine Sprache top beherrscht und der super-Mathematiker ist.

find ich auch. ich meine, die schwächste fähigkeit bestimmt, wie gut man ist.

Cpp_Junky schrieb:

Ein Programmierer muss eigentlich nur wissen, wie

reingefallen!
das "nur" war falsch. also ganz ohne die anderen fähigkeiten gehts doch nicht.

[dreaddy]

Ein "paar mal" ist sicher nicht 50000000 mal so schnell wies geht läuft sondern ich sag mal bei irgendeiner Berechnung die alle 5 Minuten einmal läuft wird das ganze jedesmal 20 mal benutzt...
Das kommt bei mir wesentlich öfter vor als das ich eine Funktion baue die 90% der Zeit braucht...

Aber vorallem geht es ja nicht ums tippen sondern ums ausdenken...

Wenn ich es spontan weiss werde ich natürlich die schnellere Version gleich benutzen, aber hast du alle mathematischen Formeln die irgendwann mal Sinn machen können beim programmieren abrufbar im Kopf?
Wenn ich aber erst 20 Minuten eine Rückblende in Mathezeiten machen muss und eventuell auch nochmal google bemühen muss um eine Version die 1 statt 10 Millisekunden braucht zu bauen mache ich das nur wenn ich was lernen will oder es Sinn macht.. und das ist halt nicht der Fall wenn ganz oben genannter Fall auftritt, was er in 90% aller Fälle macht.

Es ist ja auch nicht meistens sowas einfaches wie oben sondern eine Kombination aus der obigen Funktion mit "jedes 100rte mal +10, wenn n durch 10 teilbar dann noch aktuelle Zeit dazurechnen uswusw" also etwas wo man länger für braucht bis man es mathematisch ausgealygorythmust und damit um einiges beschleunigt hat.

Aber eigentlich meinte ich mit mathematischen Kentnissen auch garnicht sowas(auch wenn man es nur bei 1% seiner Funktionen braucht ist es nicht unwichtig, ob man seine Funktionen jetzt immer optimieren sollte oder nur wenn es sinnvoll erscheint ist eine andere Frage die auch was mit Terminen zu tun hat) sondern vielmehr das was einem die meiste Zeit in der Schule beigebracht wurde.
Davon hab ich nämlich noch nicht mehr als den 3 Satz gebraucht.
In der Berufsschule war das schon intressanter, aber bis auf die Zahlensysteme und wie man damit rechnet sowie ein paar Kleinigkeiten hab ich da auch noch nicht viel von gebraucht...

Und was ich arbeite:
Neben einem umfangreichen Borland C++ Builder Projekt das ich grad entwickel daddel ich meist auf einer 25 mhz selbstgebauten embedded Kiste via GNU Compiler rum... und die macht wirklich sehr komplizierte Berechnungen... und da merkt man im Vergleich zum PC auch wenn eine Funktion mal zu langsam ist .

[volkard]

dreaddy schrieb:

Wenn ich es spontan weiss werde ich natürlich die schnellere Version gleich benutzen, aber hast du alle mathematischen Formeln die irgendwann mal Sinn machen können beim programmieren abrufbar im Kopf?

alle? wohl kaum.
aber ich seh mit recht guter trefferquote, ob was in O(1) oder in O(n) zu lösen ist. und wenn da ein O(1) winkt, denk ich immer auch mal drüber nach, wie das zu implementieren wäre. lieber vorher freiwillig ne minute lang nachgedacht, als später, weil einen das umkippende programm dazu zwingt, umzudenken.

[Walli]

@dreaddy
Also ich merk' auch auf meinen 2,4 GHz ganz gut wenn 'ne Funktion zu langsam ist. Meistens brauche ich den Code noch nicht einmal auszuführen um zu merken, dass ich Mist gebaut habe. Das optimieren dauert längst nicht so lange wie du sagst. Ist klar, dass es in einer Funktion die alle 2 Minuten mal aufgerufen wird für die Performance egal ist, ob ich an einer Stelle schreibe:

double A = GetB() * GetB() * GetB(); // langsam

oder

double b = GetB(), a = pow(b, 3); // schnell

Der User wird es nicht merken. Aber du solltest dir vielleicht überlegen ob es nicht auch einen guten Lerneffekt hat alles richtig zu machen. Ausserdem bleibt dein Code lesbarer wenn du die bessere Version nimmst.

[volkard]

MaSTaH schrieb:

double b = GetB(), a = pow(b, 3); // schnell

du bist sicher, daß du b nicht angelegt hast, um b*b*b statt pow(GetB(),3) machen zu dürfen?

[Kauz01]

denk ich immer auch mal drüber nach, wie das zu implementieren wäre. lieber vorher freiwillig ne minute lang nachgedacht, als später, weil einen das umkippende programm dazu zwingt, umzudenken.

Find ich im Prinzip auch. Trotzdem hat dreaddy nicht ganz unrecht. Ich kann meine Zeit benutzen, um mein Problem gut zu lösen, oder um Details gut zu lösen. Meist hat man nur eine begrenzte Menge Zeit.
Bei sehr zeitkritischen Anwendungen liegt natürlich mehr Gewicht auf solchen "Späßchen". Andererseits können solche "Kleinigkeiten" auch später noch ohne großen Aufwand optimiert werden. Wenn ich dagegen den Überblick verliere, krieg ich ganz schnell Probleme mit dem Gesamtaufbau, die mir die Performace gnadenlos in den Keller ziehen können. Designschwächen auszubessern ist nicht mehr so einfach.

[volkard]

Kauz01 schrieb:

denk ich immer auch mal drüber nach, wie das zu implementieren wäre. lieber vorher freiwillig ne minute lang nachgedacht, als später, weil einen das umkippende programm dazu zwingt, umzudenken.

Find ich im Prinzip auch. Trotzdem hat dreaddy nicht ganz unrecht. Ich kann meine Zeit benutzen, um mein Problem gut zu lösen, oder um Details gut zu lösen. Meist hat man nur eine begrenzte Menge Zeit.
Bei sehr zeitkritischen Anwendungen liegt natürlich mehr Gewicht auf solchen "Späßchen". Andererseits können solche "Kleinigkeiten" auch später noch ohne großen Aufwand optimiert werden. Wenn ich dagegen den Überblick verliere, krieg ich ganz schnell Probleme mit dem Gesamtaufbau, die mir die Performace gnadenlos in den Keller ziehen können. Designschwächen auszubessern ist nicht mehr so einfach.

bei der wahl designentscheidung richtig machen oder detailentscheidung richtig machen, ist sicher die designentscheidung viel wichtiger. aber das tat hier nicht die frage gewesen sein.

letztendlich ist Mastahs punkt am wichtigsten: "Aber du solltest dir vielleicht überlegen ob es nicht auch einen guten Lerneffekt hat alles richtig zu machen."
macht mans stets richtig oder versauchts wenigstens, gewohnt man sich das an, lernt viele tricks, die einem immer wieder helfen werden und so.
wenn man einfach nur schludert, wird aus einem nie was.

[Kauz01]

letztendlich ist Mastahs punkt am wichtigsten: "Aber du solltest dir vielleicht überlegen ob es nicht auch einen guten Lerneffekt hat alles richtig zu machen."
macht mans stets richtig oder versauchts wenigstens, gewohnt man sich das an, lernt viele tricks, die einem immer wieder helfen werden und so.
wenn man einfach nur schludert, wird aus einem nie was.

Dem stimm ich mal voll zu. Leider muss man manchmal schludern, weil nicht genug Zeit da ist. Sollte aber nicht einreißen

[Walli]

volkard schrieb:

MaSTaH schrieb:

double b = GetB(), a = pow(b, 3); // schnell

du bist sicher, daß du b nicht angelegt hast, um b*b*b statt pow(GetB(),3) machen zu dürfen?

Ja, mir schwebte beides im Kopf rum. Hab dann wohl aus Unsicherheit welches schneller ist einen Mischmasch gemacht. Blödsinn .

[volkard]

Kauz01 schrieb:

Dem stimm ich mal voll zu. Leider muss man manchmal schludern, weil nicht genug Zeit da ist. Sollte aber nicht einreißen

klar.
und auch gepflegtes schludern kann man besser, wenn die trickkiste groß ist, weil man normalerweise versucht, nicht zu schludern.
(und manchmal muß man sogar vorher ne minute lang überlegen, wie man jetzt man besten schludert).
dauerzustand darf das natürlich nicht sein.
wir verlieren aber nicht aus den augen, daß n*(n-1)/2 schneller geschrieben, leichter zu lesen und schneller in der ausführung ist, als die schleife. es kann kein zeitbedingtes schludern sein, was einen daran hindert, es zu nehmen.

[Gregor]

volkard schrieb:

wir verlieren aber nicht aus den augen, daß n*(n-1)/2 schneller geschrieben, leichter zu lesen und schneller in der ausführung ist

...und das falsche Ergebnis liefert! SCNR!

dreaddy schrieb:

Und was ich arbeite:
Neben einem umfangreichen Borland C++ Builder Projekt das ich grad entwickel daddel ich meist auf einer 25 mhz selbstgebauten embedded Kiste via GNU Compiler rum... und die macht wirklich sehr komplizierte Berechnungen... und da merkt man im Vergleich zum PC auch wenn eine Funktion mal zu langsam ist .

Das meinte ich nicht. Mich hat interessiert, Welche Art von Software du programmierst, dass du so wenig Mathe benötigst.

dreaddy schrieb:

Wenn ich es spontan weiss werde ich natürlich die schnellere Version gleich benutzen, aber hast du alle mathematischen Formeln die irgendwann mal Sinn machen können beim programmieren abrufbar im Kopf?
Wenn ich aber erst 20 Minuten eine Rückblende in Mathezeiten machen muss und eventuell auch nochmal google bemühen muss

Naja, wenn du gut in Mathe bist, dann hast du auch viele Sachen einfach so drauf. Da mußt du dann nicht drüber nachdenken. Andererseits, wenn du schlecht in Mathe bist, dann kannst du über viele Dinge garnicht nachdenken, weil dir der Zugang fehlt. Da wird Google dann wahrscheinlich auch nicht weiterhelfen.

[Jester]

@Dreaddy: Das schlimme an der Funktion wie Du sie geschrieben hast, ist ja nicht, daß sie etwas länger braucht. Das blödeist, man kann damit die Laufzeit des Programms nicht mehr so gut vorhersagen. Die n*(n+1)/2-Variante braucht immer gleich lange, also O(1). Egal welche Zahl da reinkommt. Also ist die Ausfürhungszeit unabhängig von der Eingabe. Deine Variante hingegen hat Komplexität O(n), das heißt bei großen Zahlen braucht sie länger! Das macht die Laufzeit schlechter abschätzbar.
Außerdem halt ich n*(n+1)/2 für besser lesbar als die Schleifenversion!

[TorstenM]

Ich denke mal ein Programmierer sollte auch die Fähigkeit haben seinem Chef, einem Kunden, irgendjemandem klar zu machen , das sein Programm das beste ist und das er ohne ihn nicht mehr lange existieren kann
und vielleicht sogar programmieren können...

MfG Torsten

[dreaddy]

Gregor schrieb:

Das meinte ich nicht. Mich hat interessiert, Welche Art von Software du programmierst, dass du so wenig Mathe benötigst.

Was sind denn die Arten von Software?
Ich programmier eigentlich so ziemlich verschiedene Dinge, einmal Fütterungsautomaten bzw den dafür vorgesehenen Verwaltungsrechner(das war der mit den paar Mhz und reines Standard C++), dann eine reine Windowsanwendung mit VCL
,MySQLanbindung usw, diverse Tools für die Firma und noch ein paar andere Sachen.

Was ich nicht mache sind halt so komplizierte grafische Geschichten oder Anwendungen wo es verstärkt auf Geschwindigkeit ankommt(durchsuche gesamte Festplatte nach xxx oder so), aber die machen denkich die wenigsten.

Gregor schrieb:

Naja, wenn du gut in Mathe bist, dann hast du auch viele Sachen einfach so drauf. Da mußt du dann nicht drüber nachdenken. Andererseits, wenn du schlecht in Mathe bist, dann kannst du über viele Dinge garnicht nachdenken, weil dir der Zugang fehlt. Da wird Google dann wahrscheinlich auch nicht weiterhelfen.

Wenn du Dinge mehrere Jahre nicht gebraucht hast dann vergisst du sie egal wie gut du darin warst...
Ich war auch mal gut in Bio, trotzdem hab das meiste wieder vergessen weil ich es die folgenden Jahre nie gebraucht hab.

[Jester]

Es geht ja nicht darum die Lösungen alle zu kennen. Aber man sollte wissen, daß sie existieren! Dann findet man das auch schnell. Aber wer nicht weiß, daß da so eine tolle Summenformel existiert, der wird auch nicht danach suchen. Zumindest die wenigsten werden das tun.
Es gibt halt Fälle, da kann man mit Mathe genau das Quentchen Performanz oder Genauigkeit oder was auch immer rausholen, das die Software dann vom Konkurrenzprodukt abhebt.

[Kauz01]

Es geht ja nicht darum die Lösungen alle zu kennen. Aber man sollte wissen, daß sie existieren! Dann findet man das auch schnell. Aber wer nicht weiß, daß da so eine tolle Summenformel existiert, der wird auch nicht danach suchen. Zumindest die wenigsten werden das tun.

Ich weiß zwar was du meinst, es stimmt aber trotzdem. Dinge die nicht verwendet werden, werden über die Zeit vergessen. So man Zeit hat, sollte man immer wieder mal auffrischen. Aber wer hat schon Zeit?

Es gibt halt Fälle, da kann man mit Mathe genau das Quentchen Performanz oder Genauigkeit oder was auch immer rausholen, das die Software dann vom Konkurrenzprodukt abhebt.

Sorry, aber das ist eine Schnaps-Idee, vor allem bei der Performance. Das Marketing ist da viel wichtiger. Frag mal Leute die mit SAP-Produkten arbeiten (müssen), was sie von der Performance halten (ich geb hier allerdings nicht meine eigenen Erfahrungen wieder). Die sind trotzdem noch gut am Markt.
Ich hab erst vor kurzem die Erfahrung gemacht, dass keinem unserer Kunden eine Performance-Steigerung um 20% aufgefallen ist. Mit einem "Quentchen" hast du da keine Chance.

[Jester]

*g* Dieses Quentchen von dem ich da spreche läßt sich nicht in % ausdrücken!
Es geht mir dabei um Laufzeitkomplexität. Zum Beispiel ein log n drücken oder von O(n^2) auf O(n logn) runterzukommen. (Wieviel Prozent bin ich denn dann schneller?)
Versuch Dich doch mal an der Polynommultiplikation.

MfG Jester

[Kauz01]

Ist mir schon klar, was du meinst. Ich kenn die Theorie. Bei mir tauchen aber nur relativ kleine "n" auf (keine Angst, sind schon optimiert, soweit möglich).Optimierungen kommen wegen der, im Vergleich, hohen Kosten für Datenzugriffe sehr schnell ins Hintertreffen. Ich hab auch nicht viele Möglichkeiten Optimierungen, die nicht O(1) sind, durchzuführen. Das ist halt die Praxis

[TheBigW]

Tja, zurück zum Thema

Das mathematisches Verständnis dazu gehört streitet ja hier an sich keiner ab. Aber es ist wohl sicher kaum so, das jeder gute Mathematiker auch automatisch ein guter Programmierer ist. Ich gehe (aufgrund der Ermangelung mathematischer Genialität) im Sektor Bildverarbeitung ganz oft den Weg einen Algo erst mal irgendwie zu implementieren, wenn er dann läuft kann man solche Sachen immer noch tunen.
Das erste mal bin ich damit auf die Nase gefallen, als ich bei der FFT einfach aus Faulheit eine Fouriertransformation (stupide nach Formel mit Schleifen)geproggt habe -> den Zeitlichen Faktor kann sich ja wohl jeder vorstellen :).

Man muß wohl selbst bei einem Programmierer sehr differnzieren. Bin gespannt, ob noch eine klare Anwort auf die gestellte Frage kommt. "Er muß programmieren könne" war schon ziemlich dicht dran :D.