Ich glaube Programmieren kann ich vergessen :(

[THUNDERDOMER]

Ich habe viele Informationen gelesen und ich müsste es festellen, dass ohne Mathematik das Programmieren vergessen kann.

In der Schule war ich Außenseiter und beschäftigte viel mit Computer und Fachwissen sowie viel mit Visual Basic ausprobiert und gebastelt. Schulfächer hatte ich nie interessiert, besonders Hassfach Mathe, Deutsch und Schulsport. :(

Tja? Ich kann bis heute keinen Mathematik, ausser ich erstelle Chaos bei Mandelbrot und Grafik erstellen.

Und Programmieren wie Java oder c++ kann ich nichts mal anfangen, da Virtuelle Elemente dafür nichts da ist wie das Visual Basic. Nun bin ich bal 27 und wollte schon immer Programmierer werden. Ich depp, hätte ich früher mehr meine Hassfach Mathe lernen sollen, hätte ich schon heute gekonnt.

Nun ist es einfach viel zu Spät und ich kann nur noch HTML, Visual Basic einfache Programme und JavaScript scripten. Ich bin traurig, dass ich programmieren lernen aufgeben muss wegen mangels Mathematik :(

Ich muss meine Hobby weiter beschäftigen: Bildverarbeitung und wieder Computer spielen.

[Matrix316]

Man braucht eigentlich nicht zwingend Mathematik. Das braucht man nur bei mathematischen Problemen.

Und Visual Basic ist ja auch schon programmieren. Oder Javascript. Ich finde sogar Javascript wesentlich umständlicher und schwerer als z.B. .NET Anwendungen mit C# oder so. Ganz einfach, weil die Visual Studio IDE dafür optimiert ist, während Javascript eher programmieren ins blaue ist. ;)

[thomas62]

zum lernen ist es nie zu spät. Versuche doch mal zu lernen und zu Programmieren . Da wird es doch bestimmt Beispielprogramme geben wo jede Zeile auch so erklärt wird das sie ein Laie verstehen und beherrschen kann.

Hatte ich früher auch mit dem AMIGA und SECA Assembler , das waren für mich auch Böhmische Dörfer. Aber irgendwann steigt man dahinter und gut ist.

mfg

[Zephyroth]

Was ist mit embedded Programmierung? Das ist das was ich zur Zeit mache. Die Mathematik hält sich in Grenzen (klar, die vier Grundrechnungsarten sollte man schon beherrschen), die Problemstellungen und Herausforderungen liegen ganz wo anders...

Grüße,
Zeph

[Gohan]

Was willst du denn genau programmieren? Wenn es um aufwendige Simulationen geht, ist es natürlich klar, dass man um Mathematik nicht herum kommt.

Aber einfach Anwendungsapplikationen, wie z.B. das Erfassen und Ausgeben von Daten erfordern relativ wenig bis gar keine Mathematik Kenntnisse. Am Häufigsten sind mir bisher + und - untergekommen, was aber jeder halbwegs beherrschen sollte, auch wenn man kein Mathematikgenie ist.

Was meinst du denn mit "Virtuelle Elemente"?

[THUNDERDOMER]

Was willst du denn genau programmieren? Wenn es um aufwendige Simulationen geht, ist es natürlich klar, dass man um Mathematik nicht herum kommt.

Aber einfach Anwendungsapplikationen, wie z.B. das Erfassen und Ausgeben von Daten erfordern relativ wenig bis gar keine Mathematik Kenntnisse. Am Häufigsten sind mir bisher + und - untergekommen, was aber jeder halbwegs beherrschen sollte, auch wenn man kein Mathematikgenie ist.

Was meinst du denn mit "Virtuelle Elemente"?

Das sind zb. Fenster, Buttons, Text usw erst mal Grund aufbauen und dann reinprogrammieren.

Ich möchte einfach reine Anwendungen programmieren, die Aufgaben erledigt wird oder 2D Spiele.

[lumines]

Ich möchte einfach reine Anwendungen programmieren

Und was sollen die Anwendungen genau machen?

[SaschaW]

Man kann auch gut ohne tiefgründige Mathekenntnisse programmieren. Ich selber hab mit ungefähr 8 Jahren auf nem C64 angefangen meine ersten Spiele zu programmieren (ist jetzt 22 Jahre her) und wirklich Mathe habe ich erst gebraucht als ich vor einigen Jahren aufm PC mit OpenGL und Co. angefangen hab. Und die für dieses Gebiet relevanten Sachen (Matrizen, Vektoren, Quaternionen, etc.) hatte ich nie in der Schule.

Hab mich dann halt mal ein paar Wochen vor den Rechner geklemmt, Tutorials und Artikel dazu gelesen und schon gingen mir Matrizen- und Vektoroperationen flüssig von der Hand. Ging mit OpenGL genauso. Da hatt ich anfangs auch keinen Plan von, hab mich aber mit Redbook und Co. eingearbeitet, und inzwischen schaffen es meine eigenen Spiele z.b. sogar auf die c't' :)

Die Thematik ist garnicht so schwer wie viele sich das vorstellen, und v.a. auch schnell und einfach erlernbar. Zudem ists halt in der 3D-Welt extrem nützlich wenn man mit Matrizen und Co. umgehen kann, und wenn man Physik (Kollisionserkennung etc.) machen will kommt man eh nicht drum herum.

Also nicht schon vorher aufgeben, sondern evtl. mal ein paar Wochen nur mit genau dem Thema beschäftigen. Wir haben dazu in unserem Wiki z.B. ein paar gute Artikel in denen solche Sachen v.a. auf Spieleprogrammierung in 3D bezogen erklärt werden (findest du http://wiki.delphigl.com/index.php/Tutorial#Mathematisches (http://wiki.delphigl.com/index.php/Tutorial)).

Man muss fürs Proggen allgemein (wenn man Spiele entwickeln will noch mehr) halt ne gewisse Grundhaltung mitbringen, zu der auch gehört dass man sich mal ein paar Wochen mit Dingen beschäftigt die einem evtl. nicht so toll gefallen, aber von Nöten sind.

[Gohan]

Das sind zb. Fenster, Buttons, Text usw erst mal Grund aufbauen und dann reinprogrammieren.

Ich möchte einfach reine Anwendungen programmieren, die Aufgaben erledigt wird oder 2D Spiele.

Da ist doch visual basic gar nicht mal so verkehrt. Alternativ kannst du auch C# zusammen mit dem .NET Framework verwenden, ich denke da ganz stark an Windows Forms.

Bei 2D Spielen wird die Sache leider ein wenig komplizierter, da hier, je nach Komplexität, schon etwas mehr Mathematik zum Einsatz kommen kann/muss. Ich habe mal ein einfaches Pong Spiel in Java implementiert, wirklich nichts großes. Das einzige, was ich Mathematisch beachten musste war, wann und wo der Ball den Schläger oder den Spielrand trifft. Das erforderte nicht mehr als die Addition und Subtraktion verschiedener Werte.

[Monger]

Es gibt nicht DAS programmieren! Es gibt keine scharfe Grenze zwischen einem Benutzer der sich seine Formeln in Excel zurecht strickt, und jemandem der Anwendungsentwickung betreibt. "Programmieren" ist kein alleinstehendes Talent, sondern eine Frage wie gut man seine Tools beherrscht.

Ich persönlich fühle mich z.B. mit C#, Java und VB.Net sehr wohl, hätte aber ernsthafte Probleme mit einem Shell Skript. Ich täte mir im übrigen auch mit C++ heute ziemlich schwer, weil die Zeigerarithmetik einfach nicht in meinem Kopf hängen bleiben will. Ich könnte z.B. ohne mich reinzuarbeiten keinen Serienbrief in Word erstellen - einfach weil ich sowas nicht brauche, und mich nie damit beschäftigt habe.
Ich hab auch von Mathe keine Ahnung: mehr als die vier Grundrechenarten brauche ich zum Programmieren eigentlich nie.

Zumindest bei den modernen Hochsprachen ist zumindest mein Eindruck, dass man tatsächlich mehr Deutsch (bzw. Englisch) als Mathe braucht. Ein guter Fachartikel erfordert eigentlich ganz ähnliche Talente wie guter Programmcode: klare Strukturierung, wenig Redundanz, je einfacher und klarer formuliert, desto besser.

[Matrix316]

Ich finde auch, dass Excel Formeln teils komplizierter sein können als normale Funktionen und Methoden und Klassen programmieren. So ein S-Verweis ist nicht unbedingt trivial. Dagegen sowas wie

public void HelloWorld(string sValue)
{
labelX.Text = sValue;
}

geht doch locker von der Hand. :D

[THUNDERDOMER]

Lohnt sich erst mal wieder mit Visual Basic 2010 anzufangen und einen guten Buch zulegen und lernen? Oder andere Programmiersprache besser anfangen?

[Monger]

Lohnt sich erst mal wieder mit Visual Basic 2010 anzufangen und einen guten Buch zulegen und lernen? Oder andere Programmiersprache besser anfangen?
Gegen VB 2010 ist überhaupt nix einzuwenden. Featuremäßig ist die Sprache C# ebenbürtig, damit geht also alles was das .NET Framework hergibt. Ich programmiere selbst damit auf Arbeit.

[redfalcon]

Der Vorteil von C# (gegenüber VB .NET) liegt aber mMn bei der besseren Transferierbarkeit auf andere Sprachen. Wer C# halbwegs beherrscht, kann auch Java und andere Sprachen mit ähnlicher Syntax eher verstehen. Wenn ich jetzt anfangen müsste VB zu programmieren, würde mir die Umgewöhnung eher schwer fallen glaube ich.

[THUNDERDOMER]

Der Vorteil von C# (gegenüber VB .NET) liegt aber mMn bei der besseren Transferierbarkeit auf andere Sprachen. Wer C# halbwegs beherrscht, kann auch Java und andere Sprachen mit ähnlicher Syntax eher verstehen. Wenn ich jetzt anfangen müsste VB zu programmieren, würde mir die Umgewöhnung eher schwer fallen glaube ich.


Achso. Lohnt sich C# besser anzufangen als Visual Basic? Was ist der großes Nachteil bei Visual Basic? Gibt es keine Anwendungrn, die Visual Basic programmiert ist?

[redfalcon]

Achso. Lohnt sich C# besser anzufangen als Visual Basic? Was ist der großes Nachteil bei Visual Basic? Gibt es keine Anwendungrn, die Visual Basic programmiert ist?

Ich kenne VB nicht großartig, da Monger ja aber damit arbeitet, wird es wohl Anwendungen dafür geben ;)
Fenster, Buttons, Text usw. kannst du mit beiden Sprachen erstellen, du müsstest entscheiden, was für dich verständlicher ist.

Ob dir sowas lieber ist (C#, Java...)


for (int i = 0; i <= variable - 1; i++) {
// mach irgendwas
}



oder sowas (VB):


For i = 0 To variable - 1
' mach irgendwas
Next i

[Marscel]

Achso. Lohnt sich C# besser anzufangen als Visual Basic? Was ist der großes Nachteil bei Visual Basic? Gibt es keine Anwendungrn, die Visual Basic programmiert ist?

Da du dich eh im .NET-Framework mit beiden Sachen bewegst, ist die Frage des Könnens hinfällig.

Syntaktisch ist man - wie schon gesagt - mit C# etwas im Vorteil. Der Übergang von C# zu ggf. Java, C++, PHP und solchen gängigen Sprachen ist nicht allzu groß. Und nach meinem persönlichen Geschmack kriegt man beim Lesen von C# deutlich weniger Motivationseinbrüche als bei VB.

[THUNDERDOMER]

Ich kenne VB nicht großartig, da Monger ja aber damit arbeitet, wird es wohl Anwendungen dafür geben ;)
Fenster, Buttons, Text usw. kannst du mit beiden Sprachen erstellen, du müsstest entscheiden, was für dich verständlicher ist.

Ob dir sowas lieber ist (C#, Java...)


for (int i = 0; i <= variable - 1; i++) {
// mach irgendwas
}



oder sowas (VB):


For i = 0 To variable - 1
' mach irgendwas
Next i


Ist ja ein Unterschied. Muss ich mal Virtual Studio 2010 runterladen und Virtual c# installieren und genauer anschauen. Hab nur alte 2005.

Edit: Kann ich jetzt die Vergleiche anschauen: http://www.dotnetframework.de/DOTNET/Artikel/DOTNET_VB_CSHAR_Comparison.aspx

[Monger]

Der Vorteil von C# (gegenüber VB .NET) liegt aber mMn bei der besseren Transferierbarkeit auf andere Sprachen.
Das ist richtig. Microsoft hat sich da von der Syntax von C++ inspirieren lassen, gut gemixt mit etwas Java...

Leider heißt das auch, dass auch viel syntaktischer Ballast mitgeschleppt wurde. Für meinen Geschmack sieht C# für mich oft genug nach Klammerwald aus. Und weil die C++ Veteranen gewohnt sind ihren Code zu kompilen bevor sie Fehlermeldungen kriegen, gibt es auch kein automatisches Differenzcompile wie in VB.NET.

VB.NET hat seine Wurzeln mehr in den dynamischen Sprachen (wie z.B. Ruby), deshalb werden da seltener explizite Typen deklariert. C# kennt das seit .NET 3.5 auch, allerdings mMn wirkt es aufgesetzt.

VB.NET kennt auch ein paar nette Features mit denen C# sich schwer tut, wie z.B. XML Literale. Dafür muss ich zugestehen, dass in C# schlicht der Editor besser ist, z.B. was Refactoring angeht.


Summa summarum schenken sich die beiden Sprachen heute nicht mehr viel. Ein Einsteiger wird so oder so kein Feature vermissen. Ich persönlich finde VB einfach schön, weil es (spätestens seit 3.5) eine ziemlich schnörkellose und klare Syntax hat.

[Monger]

Edit: Kann ich jetzt die Vergleiche anschauen: http://www.dotnetframework.de/DOTNET/Artikel/DOTNET_VB_CSHAR_Comparison.aspx

Hier noch ein etwas ausführlicherer Syntax-Vergleich:
http://www.harding.edu/fmccown/vbnet_csharp_comparison.html

Beide Seiten kranken allerdings daran, dass mit 3.5 sich die VB Syntax doch sehr gewandelt hat. Die Codebeispiele würde man heute anders schreiben.

[THUNDERDOMER]

Achso, ich hab ja nur beispiele drangedacht. Ich schau mal rein.

[PatkIllA]

VB.NET hat seine Wurzeln mehr in den dynamischen Sprachen (wie z.B. Ruby), deshalb werden da seltener explizite Typen deklariert. C# kennt das seit .NET 3.5 auch, allerdings mMn wirkt es aufgesetzt.Das var Schlüsselwort hat technisch gar nichts mit dynamischen Sprachen zu tun.
Ich bin eigentlich immer froh, wenn man direkt aus dem Code sehen kann was da in der Variable drin steckt. Refactoring kann man sonst auch praktisch vergessen.

@Topic
direkt Mathe was über die Grundrechenarten hinaus geht brauche ich auch eher selten. Was auf jeden Fall vorhanden sein sollte ist das logische Denken und Abstraktionsvermögen.

[Monger]

Das var Schlüsselwort hat technisch gar nichts mit dynamischen Sprachen zu tun.

Ist das etwa nur Type Infer?

VB kennt aber definitiv dynamische Typen. Das wird ganz gerne bei COM Aufrufen gemacht.

[PatkIllA]

Ist das etwa nur Type Infer?

VB kennt aber definitiv dynamische Typen. Das wird ganz gerne bei COM Aufrufen gemacht.
Bei var versucht der Compiler zur Compilezeit den Typ zu bestimmen. (ist also type inference).
Ist halt schneller zu schreiben und an manchen Stellen auch besser zu lesen als ellenlange Klassennamen.

Seit 4.0 gibt es auch dynamic. Hauptsächlich für COM Aufrufe.

[Matrix316]

Ich finde C# gerade wegen der Klammern besser als VB. Bei letzterem weiß man manchmal garnet wo was anfängt und aufhört. ;)

[THUNDERDOMER]

Was bedeutet diese komische Klammern genau? Ist das wie zb. Sub zu End Sub und If zu End If usw? Also wie <></>?

[PatkIllA]

Was bedeutet diese komische Klammern genau? Ist das wie zb. Sub zu End Sub und If zu End If usw? Also wie <></>?
Im Prinzip schon. Allgemein werden damit Blöcke gekennzeichnet.
Also auch der Inhalt von Schleifen und man kann man einfach so einen Block aufmachen. Damit kann man dann auch innerhalb einer Methode Blöcke kennzeichnen. Das wirkt sich auch auf den Scope von Variablen aus.

[ENKORE]

Hm komisch also für meine Basteleien brauche ich meistens recht viel Mathe. Viele kleinere Programme sind meistens nur Sandkisten für irgendwelche Formeln, sprich IO, Schleifen, Parametereingabe um eine oder mehrere Formeln drumrum.
Allerdings gibts auch sehr viele Bereiche wo man wenig Mathematik braucht, z.B. {DBMS, alles fernab von Spielen, allg. GUI-Anwendungen, alles etwas weiter weg von Algorithmen} => Sprich: Datenabfrage und -anzeige, im Allgemeinen.

Retrospektive auf den Post: Ganz schön wirr! Vielleicht hilft es aber trotzdem ;)

[Matrix316]

Ist halt alles Situationsbedingt. Braucht man fürs normale Schreiben Mathematik Kenntnisse?? Wenn man Mathematische Probleme aufschreiben und Analysieren will, dann schon! ;)

[Ectoplasma]

Allerdings gibts auch sehr viele Bereiche wo man wenig Mathematik braucht, z.B. {DBMS, ...}


Mengenlehre? Ich glaube es gibt in der Informatik kaum einen anderen Bereich der Mathematik, der wichtiger ist als Mengenlehre. Letztendlich ist alles irgenwie Mathematik, es fällt nur nicht so sehr auf im täglichen Gebrauch. Das man es beim Schreiben von Programmen direkt mit mathematischen Formeln zu bekommt, ist aber eher eine große Ausnahme.

[THUNDERDOMER]

Verflixt { } ist mühsam zu tippen, sind jede Zahlentaste immer 3. Reihe belegt. Wieso hat nicht die Idee beigebracht, diesen ( ) häufiger zu nutzen?

Gibt es einen Trick, einfach und schnell { } zu eingeben ohne Fingerqual? Oder muss ich das drangewöhnen? ;)

[Baalzamon]

Gibt es einen Trick, einfach und schnell { } zu eingeben ohne Fingerqual? Oder muss ich das drangewöhnen? ;)
Amerikanisches Tastaturlayout. ;)

[THUNDERDOMER]

öch, mein 10-Fingerblindschreiben sind aber QWERTZ einprogrammiert worden. :(

Bekomme neue Qual: Y und Z dauernd vertippt X-D

[Exxtreme]

An diese Klammern gewöhnt man sich. Am Anfang habe ich auch geflucht. ;)

[Monger]

In VB hab ich das Problem erst gar nicht! :ugly:

[Gast]

Mein IDE macht zumindest die schließende Klammer automatisch dazu - spart schonmal die Hälfte an Tipparbeit ein.
Ansonsten: Gewöhnungssache. Ich finde es dient der Übersicht. Wenn ich Code lesen muss der ohne Klammern auskommt kenn ich mich regelmäßig nicht aus...

[patermatrix]

Verflixt { } ist mühsam zu tippen, sind jede Zahlentaste immer 3. Reihe belegt. Wieso hat nicht die Idee beigebracht, diesen ( ) häufiger zu nutzen?
Die () brauchst du auch genügend häufig. Alle drei Klammerarten (), {} und [] haben ihre eigene Bedeutung (je nach Sprache), aber wie gesagt:
An diese Klammern gewöhnt man sich.

Ansonsten kannst du dir mal Python (http://en.wikipedia.org/wiki/Python_%28programming_language%29)ansehen, das verwendet nur Whitespaces :cool:

[Mr.Freemind]

@TS

Ich glaube du solltest dir erstmal ein wenig Fachliteratur reinziehen um überhaupt ansatzweise mal den Sinn vom Syntax und Semantik zu verstehen. Das hat alles so seinen Sinn wie es die Sprache handhabt.

Finde dich damit ab oder lass es sein, es gibt ja auch verschiedene Stilarten wie der Code schlußendlich formatiert wird(K&R, Whitesmith-Stil, Allman-Stil usw usf). In einer IDE (z.B. Eclipse) kann man in den Formatierungsoptionen die Stilart auswählen bzw. seine eigene definieren und schwups wird der getippte Code automatisch angepasst. Und spätestens bei großen oder ausschwiefenden Methoden (nicht schön, aber kann ja mal passieren) wirst du über jede Klammer glücklich sein.

EDITH1 sagt: Und wenn wir schon bei den Stilarten sind, gewöhn dir gleich am Anfang an deinen Code zu kommentieren, auch wenn er nur für dich gedacht ist. Nach ein paar Wochen denkt man nämlich manchmal nur noch WTF hab ich da gemacht!

[Monger]

EDITH1 sagt: Und wenn wir schon bei den Stilarten sind, gewöhn dir gleich am Anfang an deinen Code zu kommentieren, auch wenn er nur für dich gedacht ist. Nach ein paar Wochen denkt man nämlich manchmal nur noch WTF hab ich da gemacht!
[Klugscheiß]
Für einen Anfänger ist das okay, aber Code Kommentare zählen schon lange nicht mehr zum guten Stil!

Die öffentliche API sollte dokumentiert sein, aber davon abgesehen sollte Code eigentlich selbstbeschreibend sein.
Deshalb: bitte vorsichtig mit solchen Empfehlungen sein.
[/Klugscheiß]

[Mr.Freemind]

[Klugscheiß]
Für einen Anfänger ist das okay, aber Code Kommentare zählen schon lange nicht mehr zum guten Stil!

Die öffentliche API sollte dokumentiert sein, aber davon abgesehen sollte Code eigentlich selbstbeschreibend sein.
Deshalb: bitte vorsichtig mit solchen Empfehlungen sein.
[/Klugscheiß]

Ja, genau für den Anfang ist es gut mit Kommentaren zu arbeiten, allerdings später bei größeren Projekten wird bei Java (z.B. JavaDoc) oder bei C usw. (z.B. Doxygen) sehr gerne gesehen und es hat definitiv seinen Nutzen!

Es gibt nämlich auch sehr schöne Themengebiete wo es eben nicht gleich ersichtlich ist was der Programmierer gemacht hat besonders wenn mehrere Menschen an einem Prjekt "fuschen" :wink: Aber ansonsten gebe ich dir da recht.

Bzw. ist es nie falsch jemanden zu empfehlen mit Struktur zu programmieren (empfiehlt sich besonders bei OO), aber wenn es das Ziel ist wilden am besten noch Spaghetticode zu erzeugen, dann bitte los.

[Gnafoo]

[Klugscheiß]
Für einen Anfänger ist das okay, aber Code Kommentare zählen schon lange nicht mehr zum guten Stil!

Die öffentliche API sollte dokumentiert sein, aber davon abgesehen sollte Code eigentlich selbstbeschreibend sein.
Deshalb: bitte vorsichtig mit solchen Empfehlungen sein.
[/Klugscheiß]

Es kommt wie immer darauf an. Natürlich ist man im Allgemeinen bestrebt, Methoden auf genau eine Aufgabe zu beschränken, die sich dann außerhalb der Funktion beschreiben lässt, bei ansonsten selbstbeschreibenden Code. Häufig braucht man dann auch nicht mehr Kommentare. Aber gerade bei komplexeren Algorithmen kann es durchaus sinnvoll sein, innerhalb der Funktion mit Kommentaren das „warum“ zu beschreiben. Vermeiden sollte man dabei natürlich Kommentare, die nichts anderes sagen als der Code selber.

Imho lässt sich nämlich nicht alles sinnvoll über die API-Dokumentation abdecken (selbst wenn man private Methoden dazu zählt), schon alleine weil dem Nutzer der API diese ganzen Interna egal sein können. Diese sind aber unter Umständen für jemanden, der am Code etwas ändern muss sehr wohl relevant und nicht immer offensichtlich (gerade bei irgendwelchen abgefahrenen mathematischen Tricks etc.). Das als pauschal als schlechten Stil zu bezeichnen halte ich daher für ebenso falsch. Der richtige Kompromiss macht es.

[Mr.Freemind]

So sieht es nämlich aus. Gerade wenn es um so feine Sachen wie Systemnahe Programmierung (Low Level) geht. Solche Sachen schreien förmlich nach einer gescheiten Dokumentation.

[Ectoplasma]

Es kommt wie immer darauf an.

Ack. Man darf auch nicht vergessen, dass ein Stück Code oft ein fachliches Problem löst. Man implementiert ja schließlich nicht immer nur bekannte Algorithmen oder irgendwelche global galaktischen Bibliotheken, sondern eben auch ganz spezielle, auf einen Kunden zugeschnittene Dinge. Hier kann es durchaus sinnvoll sein, inline Kommentare zu schreiben, um z.B. zu beschreiben, in welchem Kontext der gerade vorliegende Code eine Aufgabe erledigt oder um welchen CR es sich handelt.

[Monger]

... Diese sind aber unter Umständen für jemanden, der am Code etwas ändern muss sehr wohl relevant und nicht immer offensichtlich (gerade bei irgendwelchen abgefahrenen mathematischen Tricks etc.). Das als pauschal als schlechten Stil zu bezeichnen halte ich daher für ebenso falsch. Der richtige Kompromiss macht es.
Man darf halt erst Regeln brechen, wenn man sie verstanden hat. Es gibt auch Situationen wo man "schlechten" Code schreiben darf, aber dann muss man sich bewusst sein, warum man das tut, und was für Folgen man sich damit einhandelt.

Was die Dokumentation des "warum" angeht: das läuft bei uns z.B. großteils über die Kommentare unserer Quellverwaltung. So erkennt man eben auch nicht nur den Ist-Zustand, sondern wie man dort hingekommen ist. Damit lässt sich dann auch präzise sagen, welche Zeilen von wem wann zu welchem Zweck eingefügt/gelöscht/verändert wurden.


Ich schreib ja auch Kommentare mitten im Code, so ist es ja nicht. Aber selten, und in aller Regel nur um bestimmte Code Segmente zu "flaggen" (z.B. Workarounds).
Algorithmen die dermaßen komplex sind, dass sie trotz guter Strukturierung und Benennung immer noch unverständlich sind, sind nunmal die absolute Ausnahme, und nicht etwa die Regel.

Kommentare verleiten einen schnell zur Bequemlichkeit. Damit bewahrt man sich gerne vor der qualvollen Aufgabe eines sinnvollen Refactoring. Weil zwischen Code der einfach nur funktioniert, und Code der auch robust und verständlich ist, liegt meistens viel Arbeit.

[THUNDERDOMER]

Wer kann euch einen für mich mal einen HelloWorld Projekt geben? Ich möchte erstmal Visual C# richtig kennenlernen. Hello World unter Visual Basic kann ich schon. Habe Visual C# Express installiert.

Das gutes Buch über Visual C# bekomme ich erst leider nächste Woche. Und zwar ein gutes für Einsteiger!

[redfalcon]

Wer kann euch einen für mich mal einen HelloWorld Projekt geben? Ich möchte erstmal Visual C# richtig kennenlernen. Hello World unter Visual Basic kann ich schon. Habe Visual C# Express installiert.

Das gutes Buch über Visual C# bekomme ich erst leider nächste Woche. Und zwar ein gutes für Einsteiger!

Das Openbook von Galileocomputing könnte noch helfen:
http://openbook.galileocomputing.de/visual_csharp_2010/

Ansonsten Hello World in C#, man muss ein "Befehlszeilenprojekt" (oder so) erstellen:


using System;

class Program {
static void Main(string[] args) {
Console.WriteLine("Hello World");

//Konsole offenlassen und auf Tastendruck warten
Console.Read();
}
}


Wobei das Grundgerüst ja automatisch erstellt wird, man brauch eigentlich nur die beiden Zeilen mit "Console" hinzufügen.

[PatkIllA]

Wer kann euch einen für mich mal einen HelloWorld Projekt geben? Zum Programmieren gehört auch eine Suchmaschine bedienen zu können und auch englische Treffer zu verstehen.

[THUNDERDOMER]

Ich habe noch eine Verwirrspiel:

Was ist unterschied zwischen Visual C# Express und Professional? Kostet es was bei Professional? :confused:

[Exxtreme]

Ich habe noch eine Verwirrspiel:

Was ist unterschied zwischen Visual C# Express und Professional? Kostet es was bei Professional? :confused:
Professional kostet und das nicht wenig.

Die Unterschiede sind relativ groß aber das meiste betrifft die Programmierung im Team. Sprich, die Professional-Variante hat viel mehr Funktionen damit mehrere Programmierer zusammen an einem Projekt was machen und das kann dann viel besser koordiniert werden.


Zum Programmieren lernen reicht die Express-Variante dicke. :)

[THUNDERDOMER]

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Console.WriteLine("Hallo Welt!");
char c;
do
{
c = (char) Console.Read();
if (c == 'd')
Console.WriteLine("Danke");
} while (c != 'q');
}
}
}

Mein erste Zeilen funktioniert es. Man ich brauch erst mal viiiiielll Übung... Weil ich mit Visual Basic gewohnt bin.

[Marscel]

Was ist unterschied zwischen Visual C# Express und Professional?

Die Professional unterstüzt meistens exklusiv - oder zumindest nicht ohne Rumgehacke - offizielle SDKs für andere Sachen.

[PHuV]

Mathe und Programmieren ist ein Mythos, der sich leider bis heute hält. Man glaubt halt, daß mathematisches und logisches Denken einhergeht, was aber rein praktisch nicht stimmt. Sei beruhigt, ich bin in Mathe schlecht, und programmiere trotzdem seit 17 Jahren beruflich. Die meisten Dinge sind eh Anwendungen, die mit Verwaltung und Produktion zu tun haben. Selbst beim Compilerbau ist ein gewisses Grundwissen erforderlich (z.B. Backus-Naur-Form), hat mit Mathe aber auch recht wenig zu tun.

Wichtig ist, daß Du Abläufe und Zusammenhänge verstehen kannst, und diese entsprechend in Code umwandeln kannst. Du muß lernen, Teilstrukturen in Form vom Modulen zu entwickeln. Wenn Du das mal begriffen hast, ist Programmieren nichts anderes als das Umsetzen von Anforderung in spezifische Anweisungen. Logisches und strukturiertes Denken ist hier wichtig. Ob Du dabei nun eine n-te-Ableitung eines Integral bilden kannst, ist hier unrelevant. Wenn Du irgend wann fit bist, ist sogar die Sprache relativ egal, mit der Du Dinge umsetzt. Funktionale Programmiersprachen arbeiten alle ähnlich. Nur die bei den objektorientierten Sprachen wird alles etwas komplizierter und komplexer, diese sind nicht so ganz trivial.

[huha]

Mathe und Programmieren ist ein Mythos, der sich leider bis heute hält.

Nö, ist es nicht. Kann man nun glauben oder nicht, aber beim Programmieren gilt, daß man nie zuviel Mathematikkenntnisse haben kann. Man merkt oft nicht, wo man die benötigt, aber wenn man die Sachen nicht hat, dann hängt man an Problemen und kommt zu nichts.

Man glaubt halt, daß mathematisches und logisches Denken einhergeht, was aber rein praktisch nicht stimmt.
Stimmt halt schon. Mathe ist ja nicht zwingend Rechnen, sondern auch das Erkennen von bestimmten Strukturen oder auch nur das Wissen um bestimmte Dinge, die man dann konkret nachschauen kann.

Sei beruhigt, ich bin in Mathe schlecht, und programmiere trotzdem seit 17 Jahren beruflich. Die meisten Dinge sind eh Anwendungen, die mit Verwaltung und Produktion zu tun haben.
Selbst dort wird entsprechendes Wissen benötigt. Du kannst natürlich alles einigermaßen punktuell lernen, was auch meist gut funktioniert (ich kenn's ja von mir), aber es ist trotzdem besser, wenn du Dinge von Grund auf verstehst, die du machst. Und dafür wird eben Mathe benötigt. Arbeitet man nun allein an einem Projekt, dann kann man dieses Wissen nicht aus der Arbeit an einem Projekt lernen und es sich erklären lassen, sondern man muß es eben haben, da man sonst nicht vernünftig weiterkommt.


Ob Du dabei nun eine n-te-Ableitung eines Integral bilden kannst, ist hier unrelevant.
Ja, aber man muß wissen, daß das, woran man arbeitet, ein Integral ist, es eine n-te Ableitung gibt und für was man das braucht. Sonst kann's einem nämlich passieren, daß man Probleme nicht vernünftig lösen kann und ewig und drei Tage damit verbringt, irgendeinen halbgaren Pfusch zu bauen.

Wenn Du irgend wann fit bist, ist sogar die Sprache relativ egal, mit der Du Dinge umsetzt.
Öh, nö. Es gibt verschiedene Sprachen, für deren Austausch man wenig Aufwand treiben muß, aber letztendlich kennt man "seine" Programmiersprache irgendwann so gut, daß man auch einfache Dinge oftmals lieber darin erledigt, auch wenn's anderswo geschickter wäre.
Sprachen, die radikal andere Konzepte verfolgen, kann man nicht mal eben so austauschen; es ist da sogar eher kontraproduktiv, wenn man bereits gut programmieren kann, da man ja bereits weiß, wie Dinge zu machen sind.
In funktionalen Programmiersprachen gibt's z.B. keine Schleifen. Selbstverständlich kriegt man auch eine wunderbare Zählschleife in Haskell hingefrickelt, aber das ist dann häßlich und wundervoll ineffizient, genauso wie das Ausrechnen der Fakultät einer Zahl per Rekursion in Java.

Funktionale Programmiersprachen arbeiten alle ähnlich.
Jein. Funktionale Programmiersprachen sind als Konstrukt schön durchentwickelt, da sie auf Grundlagen der theoretischen Informatik basieren und nicht, wie ihre imperativen Kollegen, auf der konkreten Computer-Technik. Bestimmte Sachen sind also ähnlich, aber das war's auch schon. Letztendlich basieren alle auf dem Lambda-Kalkül, aber in der Ausführung gibt es dermaßen große Unterschiede, daß man sich auch dort umgewöhnen muß. Dort sind dann ganz andere Dinge entscheidend, z.B. die Syntax und die damit einhergehende Lesbarkeit (manche Sprachen sind da (wirklich (großartig)) oder die Frage nach eager/lazy evaluation.
Wie man allerdings im Kontext funktionaler Programmierung davon reden kann, keine Mathematikkenntnisse zu benötigen, erschließt sich mir nicht so ganz. Da wünscht man sich gerne einen Mathematiker an seiner Seite, der einem die ganzen Sachen erstmal schön erklärt ;)

Nur die bei den objektorientierten Sprachen wird alles etwas komplizierter und komplexer, diese sind nicht so ganz trivial.
Objektorientierte Sprachen sind vom Konzept ziemlich einfach. Man kann auch sehr viele Beispiele zu verschiedenen Features objektorientierter Programmierung bauen, die verständlich sind und schnell auf andere Probleme übertragen werden können.
Und kompliziert und komplex wird es mit der Zeit bei jeder Sprache, das liegt eben leider in der Natur der Sache. ;)

-huha

[Exxtreme]

Naja, viel mehr als die Grundrechenarten, Hoch rechnen/Wurzel ziehen und bissl Mengenlehre braucht man kaum. Braucht man mehr dann ist das meist schon sehr spezielle Programmierung ala 3D-Grafik, Verschlüsselung etc.

[Matrix316]

Was noch wichtig sein kann sind logische Operatoren bzw. boolsche Algebra. Und, Oder, Größer, kleiner etc.. Das ist eigentlich fast schon das wichtigste an Mathematik was man beim Programmieren braucht. Also wenn man bei einer If Abfrage zwei Sachen vergleicht, wann ist die Bedingung insgesamt erfüllt?

[Mr.Freemind]

Mathematik ist ein Teilgebiet der Informatik, Programmieren und Programmiermethodik ein Teil der Informatik. Die ganzen Teilgebiete gehören nun zusammen. Wer es nicht wahrhaben will, dem ist nicht mehr zu helfen.

Klar muss man nicht jedes Teilgebiet der Mathematik beherrschen um zu programmieren, logisches Denken gehört allerdings schon dazu und Mathe schult dieses nun mal(nicht schön aber Faktum).

Algorithmen sind ein zentrales Thema in der Mathematik sowie in der Informatik. Lineare Algebra ist die Essenz der Computer Graphik und der Robotik, die Analysis und Numerik wird zur Verschlüsselung benötigt (Faktorisierung) ,dann haben wir noch die boolesche Algebra oder die Formalen Sprachen und noch sehr viel mehr.... Man muss diese Verfahren nicht aus dem „FF“ beherrschen, aber man wird im Laufe seines Informatikerlebens nicht daran vorbei kommen.

In der Mathematik löse ich Probleme mit Algorithmen sowie in der Informatik. BTW, es gibt nichts besseres um die Rekursion zu verstehen als die Implementierung mathematischer Algorithmen.

Wer behauptet die Mathematik und die Informatik (in diesem Fall Programmieren) sind divergent, liegt grundlegend falsch.

[Monger]

Mathe und Programmieren ist ein Mythos, der sich leider bis heute hält. Man glaubt halt, daß mathematisches und logisches Denken einhergeht, was aber rein praktisch nicht stimmt.

Der mMn größte Irrtum ist, dass Programmieren etwas mit Logik zu tun hat.

Das fängt bei der Syntax an, die nunmal historisch gewachsen ist, und ihre ganz eigene Philosophie transportiert: sei es C++ (Red Pill statt Blue Pill), Java (ALLES ist ein Objekt!), oder Python (Klammern sind doof!).

Das geht weiter bei Frameworks, die nunmal auch ein Kind ihrer Zeit sind. Ich erinner mich noch an die Zeiten von Java, wo versucht wurde GUIs multithreaded zu rendern - schließlich wollte man vollständig multithreading-fähig sein.

Oder eben Programmierparadigmen wie AOP, die eine zeitlang mal unglaublich gehypt wurde, und immer noch keine besondere Rolle spielt. Dafür sind funktionale Sprachfeatures gerade mal wieder unglaublich populär.

Spätestens auf Projektebene driftet es dann ins Religiöse ab. Test driven design ist grad mal wieder out, SCRUM ist derzeit das Buzzword schlechthin (wobei da natürlich viel wahres drin steckt).

Aber der gesamte Softwareentwicklungsprozess ist eben mehr Kunst als Wissenschaft, weil es eben unzählige Lösungswege gibt, jeder davon sich in jedem neuen Projekt wieder neu auswirkt, und die Wirkung selten klar nachweisbar ist (bis auf ganz GANZ elementare Algorithmen. Die sind nach 30 Jahren einigermaßen gut erforscht).

Dazu kommt noch, dass Code nicht nur funktionieren muss. Er ändert sich ständig, geht durch viele Hände, bekommt über den Lebenszyklus hinweg immer wieder neue Bedeutung. Code ist nunmal so lange kontextfrei bis ihn jemand benutzt. So wie die Bibel so oder so gelesen werden kann, je nachdem wem sie gerade in die Hände fällt, so bekommt auch Code je nach Nutzerverhalten eine neue Bedeutung.


Das sind alles Aspekte, die mehr in die Geisteswissenschaften fallen. Wirklich mathematisch erfassbar ist mMn nur die allerunterste Ebene.

[Mr.Freemind]

Bei vielen Sachen gehen wir konform allerdings sehe ich folgende Sachen anders:

Der mMn größte Irrtum ist, dass Programmieren etwas mit Logik zu tun hat..

Das ist deine Meinung und wird sicherlich nicht von vielen geteilt.



Das sind alles Aspekte, die mehr in die Geisteswissenschaften fallen. Wirklich mathematisch erfassbar ist mMn nur die allerunterste Ebene.

Könntest du "unterste Ebene" mal bitte definieren?

[Monger]

Könntest du "unterste Ebene" mal bitte definieren?
"Unterste Ebene" ist eigentlich quatsch. Das wäre für mich die Syntax - und die ist schon wieder höchst subjektiv. Ich dachte da jetzt an ganz elementare Datenstrukturen und Algorithmen: Bäume, Listen, Rekursionen, Sortieralgorithmen... die sind gut erforscht, und da kann man auch relativ genau sagen, wo ihre Stärken und Schwächen liegen.

[Mr.Freemind]

Gut, dann sind wir auch da einer Meinung :wink: Denn ich wüsste nicht wie man generisch programmieren könnte ohne einen Ansatz von Logik, besonders wenn man sich sowas selbst basteln will.

[Marscel]

Der mMn größte Irrtum ist, dass Programmieren etwas mit Logik zu tun hat.

Jedem if, jeder Reihenfolge von Anweisungen liegt eine Logik zu Grunde.

[Monger]

Jedem if, jeder Reihenfolge von Anweisungen liegt eine Logik zu Grunde.
Das kannst du über deutsche Grammatik auch sagen. Kommaregeln und Satzbau sind ganz klar definiert.

Es gibt sogar dramaturgische "Best Practices" (also Pattern), die jeder gute Autor kennen sollte. Aber es gibt keinen Königsweg zu einem guten Roman.

[Mr.Freemind]

Das kannst du über deutsche Grammatik auch sagen. Kommaregeln und Satzbau sind ganz klar definiert.

Es gibt sogar dramaturgische "Best Practices" (also Pattern), die jeder gute Autor kennen sollte. Aber es gibt keinen Königsweg zu einem guten Roman.

Leider nicht richtig, eine natürliche Sprache wird im Wesentlichen durch sprachliche Sätze charakterisiert, die von Menschen geäußert werden, wobei man grammatikalische Korrektheit und sinnvollen Gebrauch voraussetzt. Natürliche Sprachen sind zu komplex und können nicht vollständig durch ein allgemein gültiges Regelwerk beschrieben werden.

Wir haben zwar heute gute Regelwerke für die "Syntax" von einzelnen Sätzen aber die Bedeutung (Semantik) eines Satzes/Textes läßt sich nur ansatzweise mit formalen Sprachen Methoden erfassen.

siehe Chomsky Hierarchie (http://de.wikipedia.org/wiki/Chomsky-Hierarchie)

Zitat daraus:

Obwohl Chomsky seine Forschungen mit dem Ziel verfolgte, eine mathematische Beschreibung der natürlichen Sprachen zu finden, ist bis heute der Nachweis einer korrekten und vollständigen formalen Grammatik für keine natürliche Sprache gelungen. Das Problem besteht u.a. im Zusammenspiel der verschiedenen Grammatikteile, die jeweils einzelne sprachliche Phänomene modellieren. Beim praktischen Einsatz formaler Grammatiken in der Computerlinguistik kommen Mehrdeutigkeiten auf verschiedenen Ebenen der Sprachbetrachtung hinzu; diese müssen (z.B. in der maschinellen Übersetzung) anhand des Kontextes aufgelöst werden.

[PHuV]

Der mMn größte Irrtum ist, dass Programmieren etwas mit Logik zu tun hat.
:
Das sind alles Aspekte, die mehr in die Geisteswissenschaften fallen. Wirklich mathematisch erfassbar ist mMn nur die allerunterste Ebene.

Sagen wir es mal so, Deine weiterführende Kritik ist berechtigt. Allein was mittlerweile alles in Java mit zig Klassen so reingepackt wurde, blickt wirklich keine Sau mehr durch, was wo nun wie verwendet werden soll.

Aber, denoch brauchst Du für das Verfassen von genauen Anweisungen ein Verständnis von Logik. Wenn man nicht weiß, was auf welchem Befehl folgt, könnte man nicht programmieren. Beim Kochen kann ruhig man was schiefgehen, da schmeckt es halt nicht, oder es ist verkocht, falsch gewürzt. Beim Programmieren hat es doch schon gravierendere Folgen, die gnädigste ist noch, wenn Dein Programm überhaupt funktioniert.

@huha

Ich kann Deine Position nachvollziehen, nur ist das IMHO eine rein akademische Betrachtungsweise. Nach 17 Jahren Berufserfahrung kann ich diese Betrachtungsweise nicht teilen. Man braucht ein gewisses Verständnis, richtig. Aber ob diese nun mit Mathematik korreliert, bezweifle ich. Nach der Aussage müßte auch jeder Mathematiker ein sehr guter Schachspieler sein, was aber in der Realität nicht zutrifft.

Man darf nicht vergessen, wo heute die meisten Dinge verwendet werden, in der Anwendung für die Wirtschaft. Da sind ganz andere Dinge wichtig als reine mathematischen Kenntnisse. Ich bin immer wieder überrascht, wie wenig Leute von der Uni wissen, wieso gewisse Abläufe in der Softwareentwicklung geplant werden müssen. Du hast recht, es ist immer gut, wenn man etwas tiefer Bescheid weißt. Nur nützten Dir die mathematischen Kenntnisse rein gar nichts, wenn Du Anwendungen schreiben mußt, die Bedürfnisse für eine Produktionsplanung erfüllen müssen. Und sag jetzt nicht, das sei trivial, das ist es nicht. ;)

Dieses Bild trifft es leider zu gut auf den Punkt:

http://s1.directupload.net/images/110331/5keoiifw.png

[huha]

Naja, viel mehr als die Grundrechenarten, Hoch rechnen/Wurzel ziehen und bissl Mengenlehre braucht man kaum. Braucht man mehr dann ist das meist schon sehr spezielle Programmierung ala 3D-Grafik, Verschlüsselung etc.

Nö, ist es nicht. Sorry, aber selbst für vergleichsweise einfache Aufgaben benötigt man zumindest das mathematische Wissen, wie bestimmte Dinge grob funktionieren, damit man's irgendwo nachschauen kann.
Man kriegt das natürlich alles irgendwie hingefrickelt, aber das ist dann nicht sonderlich brauchbar.

Selbst für sehr einfache Visualisierung von Daten sollte man bereits wissen, was trigonometrische Funktionen so machen, welche für was benötigt wird und wie man den Abstand zwischen Linien und Punkten bestimmt. Ich vermute einfach mal, daß das problematisch ist, wenn man wirklich absolut keine Idee hat, daß man das irgendwann mal brauchen wird.

Aber, denoch brauchst Du für das Verfassen von genauen Anweisungen ein Verständnis von Logik. Wenn man nicht weiß, was auf welchem Befehl folgt, könnte man nicht programmieren. Beim Kochen kann ruhig man was schiefgehen, da schmeckt es halt nicht, oder es ist verkocht, falsch gewürzt. Beim Programmieren hat es doch schon gravierendere Folgen, die gnädigste ist noch, wenn Dein Programm überhaupt funktioniert.
Es gibt ja viele Möglichkeiten, Dinge zu programmieren. Einfach bestimmte Abfolgen zu bauen hat jetzt nicht unbedingt viel mit Logik im Sinne der mathematischen Logik zu tun, aber man sollte zumindest ein gutes Vorstellungsvermögen haben, wie sich die Aktionen aufeinander auswirken und in welcher Reihenfolge sie deshalb auszuführen sind. Das ist aber nichts, das man mit einer mehr oder weniger umfangreichen mathematischen Ausbildung mal eben so hinkriegen würde, da gehört hauptsächlich Erfahrung dazu.

@huha
Ich kann Deine Position nachvollziehen, nur ist das IMHO eine rein akademische Betrachtungsweise.
Ich nehme mir in diesem Thread heraus, über Programmierung diskutieren zu können und nicht über Softwareentwicklung. Softwareentwicklung hat mit Programmierung erstmal nichts zu tun und es lassen sich auch kaum Fähigkeiten aus der Programmierung anwenden, um Softwareentwicklungsprozesse zu planen.

Aber: Wir reden in diesem konkreten Thread ja bisher (zumindest ging ich davon aus) darüber, daß hauptsächlich privat programmiert wird. Da macht man keine Software-Entwicklung, außer eben, man ist masochistisch veranlagt oder hat zuviel Zeit, sondern man plant die Sache ganz kurz und programmiert dann.

Nach 17 Jahren Berufserfahrung kann ich diese Betrachtungsweise nicht teilen. Man braucht ein gewisses Verständnis, richtig. Aber ob diese nun mit Mathematik korreliert, bezweifle ich. Nach der Aussage müßte auch jeder Mathematiker ein sehr guter Schachspieler sein, was aber in der Realität nicht zutrifft.
Erfahrung kann Verständnis zwar nicht ersetzen, muß sie aber auch nicht. Oftmals ist große Erfahrung mit nur minimalem bzw. komplett ohne tiefgreifendes Verständnis besser als Verständnis ohne oder nur mit minimaler Erfahrung.
Wenn man immer ähnliche Dinge macht, gewinnt man natürlich an Erfahrung, verpaßt aber gegebenenfalls Parallelen zu anderen Projekten oder Möglichkeiten, Dinge anders, besser zu gestalten. Ohne Erfahrung hat man allerdings auch mit Verständnis keinen Blick dafür, was wie sinnvoll anzuwenden ist. Man benötigt also beides.

Gerade beim Programmieren halte ich es für wichtig, zuerst Erfahrung mit der Programmiersprache i.a. aufzubauen. Daher halte ich Aussagen, alle Programmiersprachen würden sich ähneln, auch für sinnlos, da sie zwar nicht unbedingt falsch ist, jedoch in der Praxis kaum relevant, weil man zum vernünftigen Einsatz einer Programmiersprache genug Erfahrung damit benötigt. Die gibt's nicht gratis, sondern ist Ergebnis der langwierigen Beschäftigung damit.
Erfahrung läßt sich andererseits aber auch besser nutzen, wenn man Dinge versteht, ohne erfahren darin zu sein. Verstehe ich Datenstrukturen, kann ich zwar trotzdem immer noch die benutzen, die mir von der Programmiersprache gegeben werden, aber ich kann mir ggf., wenn ich eine entsprechend abenteuerliche benötige, sowas einfach bauen.

Bei Hobbyprojekten halte ich ein möglichst großes Wissen fernab des konkreten Programmierproblems für absolut essentiell, um irgendwas hinzukriegen. Bei größeren Sachen gibt's üblicherweise die Leute, die sich mit bestimmten Aspekten besonders gut auskennen, die man als "Normalsterblicher" einfach nur benutzt, aber hobbymäßig muß man sich die Sachen oftmals selber erkämpfen und das geht nunmal nicht, wenn man bestimmte Grundlagen nicht kennt oder Zusammenhänge einfach nicht sieht. Und genau für sowas braucht man einfach Mathe. Damit man's mal gesehen hat.

Man darf nicht vergessen, wo heute die meisten Dinge verwendet werden, in der Anwendung für die Wirtschaft. Da sind ganz andere Dinge wichtig als reine mathematischen Kenntnisse.
Naja, Softwareentwicklung für Großprojekte ist stark abgegrenzt. Du mußt andere Codeteile nur benutzen und nicht verstehen, deshalb gibt's ja die externen Schnittstellen. Wie und warum das funktioniert, hat dich nicht zu interessieren ;). Selbst wenn du durch anderes Wissen weißt, daß man bestimmte Dinge z.B. über ein mathematisches Konstrukt abkürzen könnte, kannst du das nicht implementieren, wenn die verfügbaren Interfaces dafür nicht geeignet sind. So ist das dann eben, üblicherweise hat man aber auch die Experten an genau den Stellen, an denen sie auch benötigt werden. Bei Kleinprojekten kann man sich sowas einfach nicht zu 100% leisten, wobei es bereits bei zwei Leuten anfängt, so zu sein.

Ich bin immer wieder überrascht, wie wenig Leute von der Uni wissen, wieso gewisse Abläufe in der Softwareentwicklung geplant werden müssen.
Warum soll man da überrascht sein? Softwareentwicklungsplanung und -prozeßmanagement ist ziemlich langweilig, darauf hat eigentlich niemand Lust.

Du hast recht, es ist immer gut, wenn man etwas tiefer Bescheid weißt. Nur nützten Dir die mathematischen Kenntnisse rein gar nichts, wenn Du Anwendungen schreiben mußt, die Bedürfnisse für eine Produktionsplanung erfüllen müssen. Und sag jetzt nicht, das sei trivial, das ist es nicht. ;)
Ich habe nur ein relativ beschränktes Mathematikwissen, aber selbst das hilft mir ständig weiter. Die meisten meiner Projekte sind aber auch natürlich nur meine Projekte, ich muß also alles machen. Und spätestens dann, wenn man Daten verarbeiten, ein- oder ausgeben will, ist es vorbei mit den vier Grundrechenarten. ;)

-huha

[Ectoplasma]

Nö, ist es nicht. Sorry, aber selbst für vergleichsweise einfache Aufgaben benötigt man zumindest das mathematische Wissen, wie bestimmte Dinge grob funktionieren, damit man's irgendwo nachschauen kann.
-huha

Hmm, sagen wir mal, dass man den mathematischen Hintergrund in der Regel nicht bewusst wahrnimmt.

Ansonsten kommst du mir so vor, als wolltest du hier deine Meinung mit aller Macht hinein pressen.

[Mr.Freemind]

Hmm, sagen wir mal, dass man den mathematischen Hintergrund in der Regel nicht bewusst wahrnimmt.

Ansonsten kommst du mir so vor, als wolltest du hier deine Meinung mit aller Macht hinein pressen.

Nein seine Meinung, ist in der Hinsicht völlig korrekt. Da gibt es nichts "hineinzupressen" weil es einfach so ist.

[Ectoplasma]

Die ursprüngliche Fragestellung des TS rückt immer weiter in den Hintergrund. Im übrigen habe ich informatik studiert und weiss selbst, wieviel Anteil die Mathematik in der Programmierung hat.

Es gibt hier eben Leute, die die Meinung vertreten, dass man auch ohne große mathematische Kenntnisse programmieren lernen kann und ich bin ebenfalls dieser Meinung.

[Gast]

Gut, dann sind wir auch da einer Meinung :wink: Denn ich wüsste nicht wie man generisch programmieren könnte ohne einen Ansatz von Logik, besonders wenn man sich sowas selbst basteln will.
Full Ack.

Sobald man etwas machen will was über "legospielen" hinausgeht (also das zusammenfügen von vorgefertiger Funktionalität -> Legosteine, und das bloße reagieren auf Bedienelemente -> wenn drück knopf a mach aktion b) kommt man um diese Dinge nicht herum. Und dieser Punkt ist ziemlich schnell erreicht, denn so ziemlich jedes Projekt hat im Kern irgendeine neue Idee. Warum würde man es sonst machen wenn es eh schon exisitiert?

[Mr.Freemind]

Die ursprüngliche Fragestellung des TS rückt immer weiter in den Hintergrund. Im übrigen habe ich informatik studiert und weiss selbst, wieviel Anteil die Mathematik in der Programmierung hat.

Es gibt hier eben Leute, die die Meinung vertreten, dass man auch ohne große mathematische Kenntnisse programmieren lernen kann und ich bin ebenfalls dieser Meinung.

Und ich habe es im übrigen auch studiert :rolleyes: und sehe diesen Punkt halt völlig anders.

@Gast

so sieht es aus!

[Monger]

Selbst für sehr einfache Visualisierung von Daten sollte man bereits wissen, was trigonometrische Funktionen so machen, welche für was benötigt wird und wie man den Abstand zwischen Linien und Punkten bestimmt.

Ausgerechnet Visualisierung ist ja ein SEHR spezielles Thema. Der weitaus größte aller Entwickler wird Frameworks à la Windows Forms benutzen, und nie in die Verlegenheit kommen sich selbst das Rendering zurechtzustricken.


Du argumentierst viel mit "Erfahrung", als ob das ein eigenstehendes Talent wäre. Benenn doch mal konkret, was da drunter fällt. Natürlich hilft es beim Programmieren, wenn man was von Mathe versteht... aber es hilft auch, was von Biologie, Philosophie, Psychologie, Kunst und Germanistik zu verstehen.


Was ich eigentlich die ganz Zeit versuche zu sagen, ist folgendes:
ich höre regelmäßig die Behauptung: "Wenn du programmieren willst, musst du Mathe können!"
Das ist nicht ganz falsch, aber eben nur die halbe Wahrheit. Je weiter sich die Hochsprachen entwickeln, je komplexer die Softwareanwendungen werden, desto irrelevanter wird der technische Hintergrund.

Ich würde mir deshalb nicht nur Physiker, Elektrotechniker und Mathematiker als Programmierer wünschen, sondern mehr Geisteswissenschaftler. Denn - wie gesagt - letztendlich ist Programmieren mehr Kunst als Wissenschaft.

[Gast]

so ein quark..

[RLZ]

Kann man ein Haus bauen ohne dass jemand mit Ingenieursstudium dabei ist?
Klar. Ne Holzhütte kriegt (fast) jeder zusammengezimmert.

Wird das Haus größer, braucht man auch mehr Leute, die etwas von den Grundlagen wie Statik verstehen. Trotzdem kann an der Baustelle auch noch jemand effektiv helfen, der nicht mal lesen kann. Auch brauch der Gärtner nichts von der Verkabelung im Haus zu verstehen.

Genauso braucht jemand in gewissen Aufgabenbereichen keine große Mathematik oder Logikgrundlagen um zu programmieren. Wird das Projekt aber größer und komplizierter, braucht man jemanden dafür. Ansonsten wird einem irgendwann alles zusammenstürzen. Trotzdem kann man auch bei Großprojekten Leute mit Schwächen in diesen Bereichen gut brauchen.

[Ectoplasma]

Und ich habe es im übrigen auch studiert :rolleyes: und sehe diesen Punkt halt völlig anders.

@Gast

so sieht es aus!

Du weisst, dass man für ein "Hello World" nicht unbedingt Mathe braucht.
Das kann man nun weiterspinnen. Die Frage ist, wo man die Grenze ziehen will, wann Mathe unabdingbar ist. Ich bin der Meinung, dass diese Frage sehr von der Aufgabenstellung abhängt. Ein bischen Verständiss für Logik im Allgemeinen zu entwickeln, ist meist auch keine große Hürde. Ich glaube auch, dass bei dem Begriff Mathe, unterschiedliche Vorstellungen vorherschen, was davon in der Informatik gebraucht wird und was nicht.

Von welcher Art von Mathe sprichst du denn so im Speziellen? Und dann erkläre mir doch nochmal, ob das Erlernen eine Hürde darstellt.

[Mr.Freemind]

Es geht nicht um ein "Hello World" :rolleyes:, ich beziehe mich auf Mathematik weil es logisches Denken schult (ja das ist so!) und ich bitte darum, dass man paar Zeilen 0815 Code nicht als programmieren bezeichnet:freak:.

Ich möchte wissen, wie jemand Probleme lösen will ohne jeglichen Ansatz vom logischen Denken (Generics etc. pp. alles schon zig mal hier aufgezählt) und wenn wir dann zu Mathe spezifischen Problemen kommen ist dann endgültig schluss. Und wenn wir schon dabei sind, öfters wird ja Java als leicht zu erlernen hier angeben, ich denke Leute die das behaupten sind Kilometerweit von der OO weg, bei schöner OO werden einem schön die Gehirnzellen gebraten.

Dein "Hello World" Beispiel läßt mich erhlich gesagt erschrecken (Wirtschaftsinformatiker?). Erst wird hier die Dokumentation von Code als sinnlos betitelt nun ist man Programmierer wenn man das "Hello World" drauf hat. Was ist das nächste? HTML ist auch eine Programmiersprache oder wie? :eek:

[Monger]

Kann man ein Haus bauen ohne dass jemand mit Ingenieursstudium dabei ist?
Klar. Ne Holzhütte kriegt (fast) jeder zusammengezimmert.

Schönes Beispiel!

Die wichtigste Person beim Hausbau ist nicht etwa der Statiker oder der Maurer, sondern der Architekt.

[THUNDERDOMER]

Hello World geht es um darum, erst mal den Programmiersprache zu kennenlernen. Da braucht man ja auch keinen Mathematik oder Logik.

Ein guten Buch bekomme ich erst nächste Woche.

[Mr.Freemind]

Wenn man nicht programmiern kann, dann kann man auch kein Software Engineering betreiben (Konzept, Anforderungsanalyse, Aktivitätsdiagramme, Klassendiagramme oder Sequenzdiagramm usw usf.).

[Tiamat]

Programmieren ist Mathematik zum Anfassen :D.

[Mr.Freemind]

Nicht umsonst war der Name des Studienfaches Informatik mal angewandte Mathematik bzw. ist es auf manchen Unis heute noch.

[Matrix316]

Es kommt immer drauf an, in welchem Fachgebiet man programmiert.

Wenn ich eine (Web-)Anwendung mache wo jemand Text eingibt und rausliest, brauch ich keine Integralrechnung um Textboxen zu füllen und um Daten in der Datenbank abzuspeichern und rauszulesen.

[Ectoplasma]

Es geht nicht um ein "Hello World" :rolleyes:

Leute wie du regen mich echt auf. Warum wußte ich nur, dass du dich an dem "Hello World" aufhängst und den Rest dahinter nicht verstehst. Deine Rolleyes sind ebenfalls nervig und nicht zielführend. Wie bei einem kleinen Kind ist das. Und wieso kommst du auf Wirtschaftsinformatiker? Mein Fachgebiet heißt Softwaretechnik. Ich mache seit 18 Jahren nichts anderes als OO Entwicklung und damit meine ich nicht nur deren Benutzung, sondern das Entwickeln von Bibliotheken mit C++ und mit Java.

Im Übrigen habe ich etwas zu huha geschrieben. Da brauchst du dich nicht hier so aufzuplustern wie ein Gockel. Ließ mal lieber nochmal richtig, was ich geschrieben habe und ließ bitte über den "Hello World" Satz hinaus.

[Mr.Freemind]

@Ectoplasma

Zitat:
Zitat von Mr.Freemind
Und ich habe es im übrigen auch studiert und sehe diesen Punkt halt völlig anders.

@Gast

so sieht es aus!

Du weisst, dass man für ein "Hello World" nicht unbedingt Mathe braucht.............



Erstens du hast mich zitiert, dann antworte ich auch darauf, ich habe den Rest verstanden aber wenn du ein "Hello World" als Beispiel aufzählst um zu belegen das Mathematik beim programmieren obsolet ist, dann gehe ich auch darauf ein. Ob ich dich aufrege oder nicht tangiert mich nicht, aufplustern tue ich mich auch nicht du betest doch in jedem Post deine Referenzen runter nicht ich.

Nun btt, ich betrachte das mit der Mathematik als ganzes, was einen den Einstieg einerseits immens erleichtern (Verständins von komplexen Zusammenhängen, Boolesche Algebra etc.pp (alles schon zig mal erwähnt)) kann und nicht das runterprogrammieren von mathematischen Zusammenhängen.

Allerdings spätestens wenn man an mathematische Themengebiete kommt (Computer Graphik als Beispiel) benötigt man schon mehr als ich kenne das von "Hörensagen" dann wird es nämlich sehr knifflig (nicht schön aber ist halt so).

Edith1: Nimm mal die persönliche Würze raus

[Matrix316]

Allerdings spätestens wenn man an mathematische Themengebiete kommt (Computer Graphik als Beispiel) benötigt man schon mehr als ich kenne das von "Hörensagen" dann wird es nämlich sehr knifflig (nicht schön aber ist halt so).

Aber das ist doch nur eine spezielle Anwendung und hat nicht direkt damit was zu tun, ob man programmieren kann.

Klar, wenn ich ein Buch über Physik schreiben will, muss ich nicht nur schreiben können, sondern auch Mathematik beherrschen.

Aber wenn ich ein Buch über Kunstgeschichte schreiben will, reicht es schreiben zu können und da brauche ich keine Integralrechnung...

[Mr.Freemind]

Das war ein Themengebiet exemplarisch, glaub mir wenn man einmal von dem Standardzeugs weg kommt, sei es auch nur Systemnah hat man es genug damit zu tun wohl oder übel. Mathematik ist sicherlich nicht der heilige Gral für die Programmierung aber schult ungemein siehe Generics...........

[Ectoplasma]

@Mr.Freemind

ich habe lediglich einmal geschrieben, dass ich es studiert habe, um Dikussionen wer wo den Längeren hat, vermeiden wollte. Das ist auch schon alles was dahinter steckt. Ich wollte keinen damit Unkenntnis unterstellen. Falls das so rüber gekommen ist dann sorry.

Und nochmal. Der Satz war die Einleitung zum Thema, "wo ziehe ich die Grenze". Das war keine böse Anmache oder Unterstellung, dass du keine Ahnung hast, sondern eine Einleitung. Auch hierfür sorry, falls das anders rübergekommen sein sollte.

[Frucht-Tiger]

Aber um noch mal einigermaßen den Weg zurück zum Threadthema zu finden:

Braucht man ein Händchen für Mathe um erfolreich programmieren zu können?

IMHO nicht, Programmieren ist ein Teamsport und man kann alleine unmöglich alle Skillz abdecken. Nützlich ist es sicherlich, aber werden dich z.B. sehr gute soziale Fähigkeiten als Programmierer erheblich weiter bringen, als die super Mathe Skills.

[PatkIllA]

Nicht umsonst war der Name des Studienfaches Informatik mal angewandte Mathematik bzw. ist es auf manchen Unis heute noch.
Nicht umsonst gibt es den Ausbildungsberuf Fachinformatiker Anwendungsentwicklung und ist Programmieren beim Informatikstudium eher ein Nebenthema.

[Mr.Freemind]

Ja richtig, aber es kommt auch generell auf den Studiengang und Curriculum an bzw. dann auf die Vertiefungen.

[Gast]

@TS: Falls du auch nur entfernt etwas machen willst was mit deinem Hobby Bildverarbeitung zu tun hat ist Mathematik absolut notwendig. Aber lass dich nicht abschrecken, es ist nie zu spät etwas nachzulernen :)

[THUNDERDOMER]

Mit meinem baldigen Alter 27 kann man noch Mathematik lernen? :confused:

[Tiamat]

Mal Spaß beiseite, Programmieren ist im Prinzip beliebig komplex.

Man kann durch Kenntnisse von alltagsbenötigten Algorithmen und Datenstrukturen und deren Umgang schon ne Menge machen.
Wenn man noch Ahnung von Objektorientierung hat, umso mehr.
Im Endeffekt ist das doch alles mathematisch, auch wenn man vieles dabei vielleicht nicht explizit als Mathe bezeichnen würde.
Aber das is im Endeffekt auch nur eine Teilmenge aller Möglichkeiten.

Und wieviel Mathe man tatsächlich braucht, hängt ganz vom Projekt und der Sparte ab, in der man arbeitet. Das lässt sich pauschal gar net beantworten.

[Monger]

Im Endeffekt ist das doch alles mathematisch, auch wenn man vieles dabei vielleicht nicht explizit als Mathe bezeichnen würde.
Hängt natürlich alles irgendwie zusammen. Informatik ist ein Fachbereich der Mathematik, und viele Bereiche dort (Aussagenlogik z.B.) stammen eigentlich aus der Philosophie.

Vorallem die objektorientierte Programmierung hat viele Konzepte über die Sokrates auch viel zu sagen hatte: was ist genau eigentlich ein "Ding"? Wo hört es auf, wo fängt es an? Was kommt zuerst: die Idee eines Objekts, oder das Objekt selbst?

[Gast]

Mit meinem baldigen Alter 27 kann man noch Mathematik lernen? :confused:
Ja wieso denn nicht? Ich sehe nichts was dagegen spräche...

[huha]

Hmm, sagen wir mal, dass man den mathematischen Hintergrund in der Regel nicht bewusst wahrnimmt.
Sicherlich. Das Problem ist aber auch, daß man oft an Aufgaben scheitert und nicht weiß, warum. Wenn man dann viel mehr Mathematik gemacht hat, gehen solche Sachen plötzlich leicht, weil man mit einem ganz anderen Ansatz rangehen kann und auch besser weiß, wo man welche Dinge nachschauen muß.

Ansonsten kommst du mir so vor, als wolltest du hier deine Meinung mit aller Macht hinein pressen.
Will ich eigentlich nicht. Mir ist es ja auch egal, ob jemand nun etwas Ahnung von Mathematik hat oder nicht, aber: Hat man Ahnung davon, erleichtert es das Programmieren immens. Und zwar hauptsächlich deshalb, weil man verschiedene Möglichkeiten erlernt, Probleme i.a. anzugehen und natürlich auch deshalb, weil man Einiges bereits gesehen hat und sich dann ggf. daran erinnert, daß es da etwas gibt, das nun ganz praktisch wäre (und das dann natürlich irgendwo nachschaut, denn sicherlich vergißt man das recht schnell wieder, wenn man's nicht ständig benötigt. Aber man hat immer noch im Hinterkopf, daß bestimmte Dinge lösbar sind)


Es gibt hier eben Leute, die die Meinung vertreten, dass man auch ohne große mathematische Kenntnisse programmieren lernen kann und ich bin ebenfalls dieser Meinung.
Klar kann man das, dann lernt man aber hauptsächlich eine Programmiersprache. Ich denke mal, daß jeder, der als Kind oder Jugendlicher damit anfängt, auf keinen Fall die notwendigen Mathematikkenntnisse hat, um bestimmte Dinge richtig zu verstehen. Man kriegt ohne diese Kenntnisse schon extrem viel hin, aber wenn es darum geht, bestimmte Probleme zu lösen, muß man sich eben kreative Lösungen einfallen lassen, die leider gezwungenermaßen meist ziemlich schlecht sind und nur so halb funktionieren.

Mathematikkenntnisse sind eben dann interessant, wenn man Dinge besser verstehen will und sich auch ggf. seine eigenen Algorithmen stricken. Für Anfänger ist es sowieso geschickt, zuerst eine konkrete Programmiersprache zu lernen, aber mit mehr Verständnis für die Grundlagen, die Hintergedanken geht das Erlernen anderer Programmiersprachen und das Übertragen des Wissens einfach wesentlich leichter.

Ausgerechnet Visualisierung ist ja ein SEHR spezielles Thema. Der weitaus größte aller Entwickler wird Frameworks à la Windows Forms benutzen, und nie in die Verlegenheit kommen sich selbst das Rendering zurechtzustricken.
Ich kenne Windows Forms jetzt nicht, aber zeichne nur mal eine Linie zwischen zwei Punkten und schreibe einen Text neben die Linie. Und zwar so, daß dieser zwar möglichst nahe bei der Linie ist, sie aber nicht überschneidet.
Ich hätte sowas früher nicht vernünftig hingekriegt. Jetzt fallen mir nahezu unendlich viele Möglichkeiten ein, das elegant zu lösen. ;) Und zwar nicht, weil ich so viel Erfahrung habe, weil ich sowas ständig mache, sondern eben, weil ich mittlerweile einfach viel mehr Mathematik gesehen und auch gemacht habe (wenngleich ich eigentlich total wenig kann und wenig Ahnung habe).
Auch vergleichsweise "einfache" Dinge erfordern doch auch in der konkreten Anwendung mehr Mathematik. Verständnis für mathematische Vorgehensweisen oder Prinzipien sind zwar für die konkrete Lösung eines Problems oftmals nicht entscheidend, helfen aber, die Programmiersprache besser zu benutzen und Programme insgesamt besser zu entwerfen und zu programmieren.

Du argumentierst viel mit "Erfahrung", als ob das ein eigenstehendes Talent wäre. Benenn doch mal konkret, was da drunter fällt. Natürlich hilft es beim Programmieren, wenn man was von Mathe versteht... aber es hilft auch, was von Biologie, Philosophie, Psychologie, Kunst und Germanistik zu verstehen.
Erfahrung sorgt dafür, daß man in Dingen gut wird, die man nicht versteht.
Das Problem dabei ist nur, daß man die Dinge, die man kann und in denen man gut ist, nur auf sehr ähnliche Probleme anwenden kann, auch wenn die dahinterstehende mathematische Basis für weitaus mehr Probleme gültig ist und dann auch entsprechend benutzt werden könnte.
Man kann dir natürlich zeigen, wie du beispielsweise ein Integral über eine Halbkugel löst. Dafür mußt du überhaupt nicht verstehen, was ein Integral eigentlich ist, wie man auf bestimmte Dinge kommt uswusf., sondern einfach nur Zeug einsetzen, zack, fertig. Wenn es kein Integral mehr über eine Halbkugel ist, bekommst du ggf. ein Problem. Wenn die Werte auf der Halbkugel diskret sind, siehst du auch nicht, da du nicht weißt, was ein Integral eigentlich ist, daß man es durch eine entsprechend gestaltete einfache Aufsummierung ersetzen kann (die natürlich um Größenordnungen schneller ist) uswusf.
Es ist insgesamt nicht so leicht, konkrete Beispiele zu finden, weil man nicht zwischen keine-Ahnung-von-Mathe und ein-wenig-Ahnung-von-Mathe umschalten kann, um festzustellen, welche Dinge man plötzlich nicht mehr ordentlich lösen kann und welche schon.

Und genau deshalb ist es meines Erachtens nach doch ein gewaltiger Unterschied, ob man Kenntnisse in einigen Bereichen der Mathematik hat, oder ob man Psychologe ist. Programme und Algorithmen basieren nun einmal auf mathematischen Grundsätzen und wenig auf denen der Psychologie. Selbstverständlich werden Psychologen darauf achten, daß Programm-Meldungen verständlich sind und die Benutzerführung intuitiv und logisch. Selbstverständlich wird es dadurch auch ein besseres Programm. Aber: Man rennt ohne Ahnung von Psychologie nicht ständig gegen Wände, wie das der Fall ohne Ahnung von Mathematik ist.

Was ich eigentlich die ganz Zeit versuche zu sagen, ist folgendes:
ich höre regelmäßig die Behauptung: "Wenn du programmieren willst, musst du Mathe können!"
Müssen nicht, aber ich behaupte einfach mal, daß man nichts vernünftig hinkriegt, wenn man zumindest keine grobe Ahnung von manchen Sachen hat.

Das ist nicht ganz falsch, aber eben nur die halbe Wahrheit. Je weiter sich die Hochsprachen entwickeln, je komplexer die Softwareanwendungen werden, desto irrelevanter wird der technische Hintergrund.
Da widersprech ich dir und behaupte exakt das Gegenteil:
Je weiter sich Programmiersprachen von den technischen Gegebenheiten, also der relativ direkten Umsetzung der Hardware, entfernen, umso relevanter werden die Prinzipien, die dahinter stehen, die eben großteils mathematisch sind.
Computer-Hardware ist möglichst simpel aufgebaut. Assembler-Algorithmen sind schön zerstückelt und benutzen nur extrem einfache Operationen. Selbst dafür braucht man schon ordentlich Mathematikwissen (hauptsächlich in der Numerik, damit man sich nicht versehentlich durch ungünstige Berechnungsreihenfolgen seine Daten ruiniert), aber im Prinzip sind die Dinge doch sehr technisch und an der Hardware orientiert. Funktionale Programmierung ist davon völlig abgehoben. Ich behaupte einfach mal, daß higher-order functions nicht so "intuitiv" und "un-mathematisch" zu erklären sind wie beispielsweise Methoden in Java. Für higher-order functions benötigt man nämlich ein richtiges Verständnis des Funktionsbegriffes, für Methoden in Java nicht.
(Ich kann higher-order functions natürlich auch an Alltagsgegebenheiten erklären, aber man muß eben richtig nachdenken und die Erklärung dann auch gut formulieren, damit es verständlich wird.)

Ich würde mir deshalb nicht nur Physiker, Elektrotechniker und Mathematiker als Programmierer wünschen, sondern mehr Geisteswissenschaftler. Denn - wie gesagt - letztendlich ist Programmieren mehr Kunst als Wissenschaft.
Eine Wissenschaft ist Programmieren nicht, dafür fehlen alle Eigenschaften einer Wissenschaft.
Trotzdem ist es gut, Naturwissenschaftler als Programmierer zu haben, weil es einfach hilft, bestimmte konkrete Vorgehensweisen zu haben, wie an Probleme heranzugehen ist. Ich weiß nicht, inwiefern das bei Geisteswissenschaftlern anders ist, könnte es mir aber durchaus vorstellen.

Du weisst, dass man für ein "Hello World" nicht unbedingt Mathe braucht.
Das kann man nun weiterspinnen. Die Frage ist, wo man die Grenze ziehen will, wann Mathe unabdingbar ist.
Unabdingbar wird Mathematik erst sehr spät, aber es hilft einfach schon nach sehr kurzer Zeit ungemein.

Ich bin der Meinung, dass diese Frage sehr von der Aufgabenstellung abhängt. Ein bischen Verständiss für Logik im Allgemeinen zu entwickeln, ist meist auch keine große Hürde. Ich glaube auch, dass bei dem Begriff Mathe, unterschiedliche Vorstellungen vorherschen, was davon in der Informatik gebraucht wird und was nicht.
Im Prinzip kann man ja alles irgendwo gebrauchen. Ein bißchen Logik kann nie schaden (wobei man es eigentlich auch nicht braucht, weil man das wirklich "intiutiv" oder anhand von Beispielen gut verstehen kann). Eine Einführung in bestimmte Probleme der Numerik sollte eigentlich in jedem Programmierbuch stehen und für jeden Programmierer verpflichtend werden (wird leider fast nie gemacht; ein großer Fehler!). Ansonsten sollte man vielleicht noch etwas Ahnung von Grundkonzepten der linearen Algebra haben. Und dann noch, gerade für (auch sehr einfache) Visualisierung: Einen gewissen Grundstock an Geometrie/Trigonometrie.
Damit kann man dann die Dinge, die immer mal wieder aufkommen, ganz passabel lösen.
Im Prinzip braucht man aber so viel wie möglich, damit man einfach auch lernt, bestimmte Dinge zu verstehen. Auch ohne die konkrete Anwendung ist das fast wichtiger. Ich würde da eher empfehlen, in die Breite zu gehen und nur wenige Dinge wirklich intensiv zu machen.

Von welcher Art von Mathe sprichst du denn so im Speziellen? Und dann erkläre mir doch nochmal, ob das Erlernen eine Hürde darstellt.
Ich glaube, das kommt ganz darauf an, was man macht. Für einen Job als Programmierer an irgendeinem großen Projekt benötigt man sicher kein großartiges Verständnis für Mathematik. Es hilft aber eben, wenn es darum geht, eigene Dinge umzusetzen, bei denen man eben nicht die Leute fragen kann, die das die ganze Zeit machen. Und es hilft auch dabei, das Wissen besser auf andere Bereiche zu übertragen.
Ob es eine Hürde darstellt, kommt wohl ganz darauf an, wie man lernt, wieviel Zeit man hat, wieviel Interesse man daran hat etc.--kann ich einfach nicht beurteilen. Im Prinzip bräuchte man jemanden, der einem die Dinge erklärt; nicht zu formell, aber auch nicht zu wischiwaschi. Keine Ahnung, ob's sowas gibt.

Es kommt immer drauf an, in welchem Fachgebiet man programmiert.

Wenn ich eine (Web-)Anwendung mache wo jemand Text eingibt und rausliest, brauch ich keine Integralrechnung um Textboxen zu füllen und um Daten in der Datenbank abzuspeichern und rauszulesen.
Auch da brauchst du Mathe! Das ganze Datenbankdesign und der Entwurf der Abfragen basiert ja auf mathematischen Prinzipien. Man kann von einer mathematischen Schreibweise einer Datenbank-Abfrage ziemlich schön die SQL-Abfrage bauen. Außerdem kann man Datenbanken auch gleich Zeug berechnen lassen oder andere Späße damit treiben (n.b. ich bin kein Datenbank-Mensch, kann damit wenig anfangen). Klar, für einfache Anwendungen benötigt man kein Datenbank-Design und keine komplizierten Abfragen, aber man dringt manchmal unbeabsichtigt in Gebiete vor, in denen es schon geschickt wäre, bestimmte mathematische Grundlagen von Datenbanken zu verstehen.

Aber um noch mal einigermaßen den Weg zurück zum Threadthema zu finden:

Braucht man ein Händchen für Mathe um erfolreich programmieren zu können?

IMHO nicht, Programmieren ist ein Teamsport und man kann alleine unmöglich alle Skillz abdecken. Nützlich ist es sicherlich, aber werden dich z.B. sehr gute soziale Fähigkeiten als Programmierer erheblich weiter bringen, als die super Mathe Skills.

Programmieren ist kein Teamsport. Es ist oftmals geschickt oder notwendig, daß man Dinge aufteilt, aber man kann auch allein wunderbar programmieren.
Und ich glaube nicht, daß man unbedingt besonders viel Ahnung von Mathematik benötigt, um programmieren zu können. Aber man kann einfach wesentlich besser programmieren, wenn man auch nur geringe Ahnung von Mathematik hat.

Nicht umsonst gibt es den Ausbildungsberuf Fachinformatiker Anwendungsentwicklung und ist Programmieren beim Informatikstudium eher ein Nebenthema.
Ich halte Programmieren für durchaus wichtig, da man so ein deutlich besseres Verständnis für bestimmte Dinge erhält. Einfach nur als Übung, schrecklich unoptimiert und lahm, aber so sieht man dann einfach, wie bestimmte Dinge prinzipiell funktionieren.
Ich habe keine Ahnung von der Ausbildung zum Fachinformatiker, kann daher also auch nicht sagen, was man da lernt oder auch nicht, aber ich vermute mal, daß man sich dort auf sehr konkrete Dinge beschränkt.

Mit meinem baldigen Alter 27 kann man noch Mathematik lernen? :confused:
Klar. Ich weiß leider nur nicht, ob es dazu Bücher in der Art gibt, wie ich mir das so vorstelle. :freak:

Hängt natürlich alles irgendwie zusammen. Informatik ist ein Fachbereich der Mathematik, und viele Bereiche dort (Aussagenlogik z.B.) stammen eigentlich aus der Philosophie.
Man merkt eben oft nicht, wo man überall besser zurechtkommt, weil man Mathematikkenntnisse hat.

Vorallem die objektorientierte Programmierung hat viele Konzepte über die Sokrates auch viel zu sagen hatte: was ist genau eigentlich ein "Ding"? Wo hört es auf, wo fängt es an? Was kommt zuerst: die Idee eines Objekts, oder das Objekt selbst?
In der OOP ja üblicherweise die Idee des Objekts. ;)

-huha

[Monger]

Ich kenne Windows Forms jetzt nicht, aber zeichne nur mal eine Linie zwischen zwei Punkten und schreibe einen Text neben die Linie. Und zwar so, daß dieser zwar möglichst nahe bei der Linie ist, sie aber nicht überschneidet.
Ich hätte sowas früher nicht vernünftig hingekriegt. Jetzt fallen mir nahezu unendlich viele Möglichkeiten ein, das elegant zu lösen. ;)

Sowas lasse ich einen Layout Manager machen! :ugly:
Das ist jetzt gerade ein Beispiel, was sich mit einem GUI Editor mit zwei Handgriffen erschlagen lässt. Sowas implementiere ich doch nicht selber.


Man kann dir natürlich zeigen, wie du beispielsweise ein Integral über eine Halbkugel löst.

Was genau machst du eigentlich? Das muss ein sehr spezielles Feld sein, weil - ich wiederhole mich - ich hab in der Praxis bisher nie mehr als die vier Grundrechenarten gebraucht, geschweige denn ein Integral.


Und genau deshalb ist es meines Erachtens nach doch ein gewaltiger Unterschied, ob man Kenntnisse in einigen Bereichen der Mathematik hat, oder ob man Psychologe ist. Programme und Algorithmen basieren nun einmal auf mathematischen Grundsätzen und wenig auf denen der Psychologie.

Programme sind für Menschen da, um menschliche Probleme zu lösen, und sie werden von Menschen geschrieben. Kein Wunder also, dass Software von menschlichen Denkstrukturen geprägt ist. Gerade die objektorientierte Programmierung dient nunmal dazu, sich der menschlichen Denkweise (d.h. abstrahieren, kategorisieren, assoziieren) anzunähern. Und ich spreche hier ganz explizit nicht von der GUI (die selbstverständlich auch menschen-kompatibel sein muss), sondern von der Programmlogik.


Da widersprech ich dir und behaupte exakt das Gegenteil:
Je weiter sich Programmiersprachen von den technischen Gegebenheiten, also der relativ direkten Umsetzung der Hardware, entfernen, umso relevanter werden die Prinzipien, die dahinter stehen, die eben großteils mathematisch sind.

Du musst keinen Toaster bauen können, um ihn selbst zu benutzen. Du musst auch seinen inneren Aufbau nicht kennen, um über ihn reden zu können.

Objektorientierte Programmierung dreht sich um Abstraktion. Sprich: ich behandele eine Menge von Code als eine Einheit, und gebe ihr einen Namen. Das kennt man auch aus der Mathematik: man ersetzt eine Formel durch ein Symbol. Pi = 3,14 . Du redest vorallem über die rechte Seite.

Ich sage aber: die Implementierung ist im Endeffekt trivial. Das kann jeder. Manche brauchen länger, manche kürzer. Und wenn man überhaupt nicht zurechtkommt, fragt man jemanden der sich damit auskennt.

Die linke Seite der Gleichung ist viel interessanter. Einerseits geht es darum, bestehende Begriffe zu verstehen und anwenden zu können(was ist ein String? Was ist eine DataGridView?), und andererseits eigene Symbole einzuführen.
Das ist eigentlich ein linguistisches Problem: erst muss man eine gemeinsame Sprache entwickeln, um in der dann Probleme formulieren zu können. Wenn erstmal allen Beteiligten klar ist was das Problem ist, ist meistens die Lösung davon eher trivial.

Das merkt man auch daran, dass in den Hochsprachen allmählich die ganz elementaren Datentypen verschwinden. Wer z.B. heute mit .NET anfängt, wird möglicherweise nie mit Arrays in Berührung kommen, und selten mehr von den elementaren Datentypen sehen als int und bool. Jede Sprache ist nunmal im Fluss, und entwickelt sich weiter.

Wenn es darum geht jemanden zu haben der die richtigen Worte für etwas findet, und ein Problem mit klaren, für jeden verständlichen, strukturierten Sätzen beschreibt, ist ein Mathematiker nicht unbedingt die erste Wahl! ;-)

[pest]

Für meine (Forschungs-)Projekte brauche ich ständig Mathe. Das fängt beim numerischen Lösen irgendwelcher PDGL an und hört bei Optimierungsalgorithmen auf.
Klar gibts da auch genügend Bibliotheken, aber ich mache das lieber selbst :freak:

Kenntnisse über die verwendete Programmiersprache setze ich da vorraus,
und Objektorientierung ist ein willkommenes Hilfsmittel und sollte jeder beherrschen.

Wenn ich allerdings lese wieviele hier anscheinend beruflich programmieren und wie wenig Mathe man da benötigt, bin ich ganz froh, das Informatikstudium abgebrochen zu haben :D

Nur ein Beispiel, für meine BA-Arbeit musste ich Normalverteilte Zufallszahlen erzeugen, das ist zumindest eine recht oft geforderte Eigenschaft. Wie macht man das, wenn man keinen Schimmer hat? Bibliotheksfunktionen nehmen?

[maximAL]

Nicht umsonst war der Name des Studienfaches Informatik mal angewandte Mathematik bzw. ist es auf manchen Unis heute noch.
Also das will ich doch mal schwer bezweifeln. Letztendlich stammt vorallem die theoretische Informatik aus der Mathematik. Die technische Informatik kommt eher aus der E-Technik und in der praktischen Informatik habe sich eine Menge eigene Disziplinen wie Software Engineering etc. entwickelt.

Nicht umsonst gibt es den Ausbildungsberuf Fachinformatiker Anwendungsentwicklung und ist Programmieren beim Informatikstudium eher ein Nebenthema.
Komischerweise sagen die Fachinformatiker, die ich kenne, dass keiner Fachinformatiker braucht. Ich hab auch noch keinen als Software Entwickler gesehen, höchstens FISIs etc. als Admins.

[Mr.Freemind]

Also das will ich doch mal schwer bezweifeln. Letztendlich stammt vorallem die theoretische Informatik aus der Mathematik. Die technische Informatik kommt eher aus der E-Technik und in der praktischen Informatik habe sich eine Menge eigene Disziplinen wie Software Engineering etc. entwickelt.


Komischerweise sagen die Fachinformatiker, die ich kenne, dass keiner Fachinformatiker braucht. Ich hab auch noch keinen als Software Entwickler gesehen, höchstens FISIs etc. als Admins.

Dann Zweifel du mal weiter.Es ist leider Fakt das aus dem Fach angwandte Mathematik das Fach Informatik geworden ist, klaro sind Einflüsse aus anderen Fächern mit dabei und es ist nicht 1 zu 1 so umgesetzt aber es ist nun mal daraus entstanden. Ein Blick in die Geschichte des Studiengangs Informatik auf diversen Universitäten zeigt dies auch auf,kannst ja gerne mal nachsehen.

Damals als ich angefangen habe wurde in der Einführungsveranstaltung noch strikt darauf hingewiesen, dass man das Nachfolgefach von aM studiert und deshalb um die wunderschöne Mathematik nicht herumkommt uiiiiii waren die Gesichter aufeinmal ganz traurig.

[maximAL]

Dann Zweifel du mal weiter.Es ist leider Fakt das aus dem Fach angwandte Mathematik das Fach Informatik geworden ist, klaro sind Einflüsse aus anderen Fächern mit dabei und es ist nicht 1 zu 1 so umgesetzt aber es ist nun mal daraus entstanden. Ein Blick in die Geschichte des Studiengangs Informatik auf diversen Universitäten zeigt dies auch auf,kannst ja gerne mal nachsehen.

Damals als ich angefangen habe wurde in der Einführungsveranstaltung noch strikt darauf hingewiesen, dass man das Nachfolgefach von aM studiert und deshalb um die wunderschöne Mathematik nicht herumkommt uiiiiii waren die Gesichter aufeinmal ganz traurig.
Schön dass das bei euch so war, an anderen Universitäten sind Informatikstudiengänge aus verschiedenen Ingenieursdisziplinen entstanden.
Kannst mir natürlich gern die "offizielle" Geschichte der Informatik zeigen.

[Mr.Freemind]

Schön dass das bei euch so war, an anderen Universitäten sind Informatikstudiengänge aus verschiedenen Ingenieursdisziplinen entstanden.
Kannst mir natürlich gern die "offizielle" Geschichte der Informatik zeigen.

Was habe ich geschrieben?

Das viele Themengebiete eingeflossen sind aber der direkte Nachfolger von aM auf sehr vielen Hochschulen Informatik ist (das ist ein
Fakt und nicht meine Phantasie ergo gibt es da nichts zu diskutieren). Echt teilweise unglaublich,wie hier einfach Fakten und Tatsachen ignoriert bzw vollends falsch dargestellt werden.

Nochmals: Es sind sehr viele andere Teilbereiche eingeflossen aber das ndert nichts an der Tatsache, dass Informatik meist der Nachfolger von aM ist.

[Coda]

Was den Punkt angeht hat Mr.Freemind recht, da brauchen wir wirklich nicht zu diskutieren. Informatik an den Unis ist sehr viel Mathematik.

Ich bin aber der Meinung, dass man zum Programmieren nicht unbedingt Mathe braucht, solange man mit dem Leben kann was einem der gegebene Baukasten zur Verfügung stellt. Wenn man allerdings an dessen Wände stößt hat man größtenteils Pech gehabt.

[maximAL]

Was den Punkt angeht hat Mr.Freemind recht, da brauchen wir wirklich nicht zu diskutieren. Informatik an den Unis ist sehr viel Mathematik.
Das Informatik sehr viel Mathe enthält (so wie jedes MINT-Fach) macht es nicht automatisch zum "Nachfolger" von Angewandter Mathematik - zumal es den Studiengang immernoch gibt. Und so manche Hochschule wird Informatik anbieten ohne je angewandte Mathematik angeboten zu haben.

Aber eigentlich ist es mir zu blöd darüber zu diskutieren. Wenn ihr glauben wollt, das angewandte Mathematik irgendwann einfach in Informatik umbenannt wurde - bitteschön.

[Coda]

Das behaupte ich nicht, und wollte ich damit auch nicht sagen.

[Gast]

Klar geht das ohne Mathe, man kann ja auch bitshiften ^^

[Matrix316]

[...]
Auch da brauchst du Mathe! Das ganze Datenbankdesign und der Entwurf der Abfragen basiert ja auf mathematischen Prinzipien. Man kann von einer mathematischen Schreibweise einer Datenbank-Abfrage ziemlich schön die SQL-Abfrage bauen. Außerdem kann man Datenbanken auch gleich Zeug berechnen lassen oder andere Späße damit treiben (n.b. ich bin kein Datenbank-Mensch, kann damit wenig anfangen). Klar, für einfache Anwendungen benötigt man kein Datenbank-Design und keine komplizierten Abfragen, aber man dringt manchmal unbeabsichtigt in Gebiete vor, in denen es schon geschickt wäre, bestimmte mathematische Grundlagen von Datenbanken zu verstehen.

-huha
[...]


It depends. ;)

Um einfache Datensätze abzufragen reicht select * from Tabelle where ID = 5. Oder um was zu aktualisieren update tabelle set feldx = 'Hallo' where ID = 6.

Klar, man sollte wissen was eine Zahl ist und was größer und kleiner heißt oder klar, kann man auch wenn man will bei der Abfrage rechnen, aber man braucht keinen Leistungskurs Mathe besucht zu haben um SQL Abfragen zu formulieren.

Und es kommt natürlich auf das Problem an, was man bearbeiten will. Die SQL Syntax oder Datenbanken allgemein, finde ich jetzt nicht unbedingt mathematisch. Eine SQL Tabelle ist auch nur ein Excel Sheet wo Zahlen, Worte und vielleicht auch Daten drinnen stehen.

Natürlich kann man es für Mathematische zwecke verwenden (wie auch immer ;)), aber ich würde nicht sagen, dass man Mathematik als Grundlage für Programmieren oder DB Abfragen braucht.

Allerdings arbeite ich z.B. seit 4 Jahren mit Datenbanken und merke vielleicht nicht mehr dass die Abfragen irgendwie mathematisch sind. ;) Ist ein Inner Join Mathematik? Ist ein Case/When Mathematik? Ist eine For Schleife Mathematik? Ist ein do/While Mathematik? Hmmm...:uponder:

Vielleicht liegts auch am eher technischen Studium, wo ganz andere Sachen gerechnet wurden, als dass das was man vielleicht für Programmieren und SQL Abfragen an Mathematik vielleicht braucht.

[pest]

Ist ein Inner Join Mathematik? Ist ein Case/When Mathematik? Ist eine For Schleife Mathematik? Ist ein do/While Mathematik? Hmmm...:uponder:

Selbstverfreilich, ein Join ist ein Kreuzprodukt ;(

[Coda]

Vor allem basiert SQL sogar direkt auf der relationalen Algebra. Die ganzen Optimierungsstrategien der Datenbanken wurden damit formal entwickelt.

Aber auch so ist es vorteilhaft sich mal damit beschäftigt zu haben. Auch die Schema-Normalformen sind für ein gutes Datenbankdesign essentiell.

[BeeRockxs]

Um Normalformen etc. zu verstehen braucht man aber keine großen Mathematik-Kenntnisse.
Ebensowening zum schreiben von SQL Statements.

[Coda]

Keine großen Mathematik-Kenntnisse? Zumindest so wie das normal aufgeschreiben wird braucht man dafür zumindest etwas Mengentheorie, und die lernt man nichtmal am Gymnasium.

Und nur weil man beim Schreiben von SQL-Statements nicht dran denkt, heißt das noch lange nicht, dass das nichts anderes als angewandte relationale Algebra ist.

[Matrix316]

Das mein ich ja. Ich muss nicht wissen, dass Join ein Kreuzprodukt und damit Mathematik ist. Man muss nur wissen was dabei rauskommt. ;)

[Gast]

Sowas lasse ich einen Layout Manager machen! :ugly:
Das ist jetzt gerade ein Beispiel, was sich mit einem GUI Editor mit zwei Handgriffen erschlagen lässt. Sowas implementiere ich doch nicht selber.

Und was machst du wenn dein GUI Editor das nicht kann? Wenn ers kann, schön, trotzdem wirst du früher oder später irgendeine spezielle Anforderung haben die er nicht kann. dann heißt es selber programmieren.

Du musst keinen Toaster bauen können, um ihn selbst zu benutzen. Du musst auch seinen inneren Aufbau nicht kennen, um über ihn reden zu können.

Die Programmierer sind in dieser Analogie aber genau die Leute die die Toaster bauen!

Ich sage aber: die Implementierung ist im Endeffekt trivial. Das kann jeder. Manche brauchen länger, manche kürzer. Und wenn man überhaupt nicht zurechtkommt, fragt man jemanden der sich damit auskennt.
[...]
Das ist eigentlich ein linguistisches Problem: erst muss man eine gemeinsame Sprache entwickeln, um in der dann Probleme formulieren zu können. Wenn erstmal allen Beteiligten klar ist was das Problem ist, ist meistens die Lösung davon eher trivial.

Dann ist das Problem schon von jemand anderem gelöst worden und die "Programmierarbeit" beschränkt sich darauf die vorhandenen Legosteine richtig zusammenzusetzen. Das Resultat wird eine Anwendung sein die ein Problem löst für das es schon eine Lösung gibt, nämlich von demjenigen der die "Legosteine" ursprünglich programmiert hat. Sprich ein weiteres Paint, ftpClient, mp3Player etc etc. Das ist nicht wirklich interessant.

Wenn es darum geht jemanden zu haben der die richtigen Worte für etwas findet, und ein Problem mit klaren, für jeden verständlichen, strukturierten Sätzen beschreibt, ist ein Mathematiker nicht unbedingt die erste Wahl! ;-)
Ein Problem beschreiben kann man bald einmal. Der interessante Punkt ist wie man das Problem löst, das ist das womit sich Programmierer beschäftigen. Sie lösen Probleme. Und hierfür sind Mathematiker genau die richtigen Leute.


Das mein ich ja. Ich muss nicht wissen, dass Join ein Kreuzprodukt und damit Mathematik ist. Man muss nur wissen was dabei rauskommt.
Dann wirst du vermutlich selten etwas neues und interessantes machen können. Legosteine auf verschiedene Arten zusammensetzen ist irgendwann langweilig. Niemand braucht einen 146. mp3Player, ftpClient, wasauchimmer.

[pest]

Das mein ich ja. Ich muss nicht wissen, dass Join ein Kreuzprodukt und damit Mathematik ist. Man muss nur wissen was dabei rauskommt. ;)

In einem gewissen Rahmen kann ich dich verstehen, schließlich bietet die Mathematik Möglichkeiten selbst das kleine 1*1 auseinanderzunehmen bis du nichts mehr verstehst.

Trotzdem zeugt dein Argument von großer Überheblichkeit, ja sogar fast Dummheit.
Sicher schafft es ein Affe neben "x^n" ein "n*x^(n-1)" zu schreiben. Er hat keine Ahnung was er da macht, er macht es zweifelsfrei richtig...aber naja...es ist immer noch ein Affe

[Captian Sheridan]

Keine großen Mathematik-Kenntnisse? Zumindest so wie das normal aufgeschreiben wird braucht man dafür zumindest etwas Mengentheorie, und die lernt man nichtmal am Gymnasium.

Wie Mengen aufgeschrieben werden, lernt man eigentlich nebenbei.
Spezieller Überblick über Mengen wird entweder nebenbei bei Funktion("Relationen")
oder spätestens in der 12.Klasse gemacht.

Stand G9 Bayrisches Gymnasium, Bei G8 keine Ahnung.

Mathematiker, die Datenbanken erklären, grauenhaft. Ideal zur Abschreckung.
Normalformen kann man auch normal erklären.

Datenbankdesign ist mehr Abwägungssache, welche Information braucht man,
und welchen Preis zahlt man dafür (Performance).
quot homines, tot sententiae.

Eine sehr unscharfe Sache, man sollte Latein/Altgriechisch übersetzten geübt haben,
sonst ist man zu unflexibel für sowas. :biggrin:
Ohne den Latein/Altgriechisch Unterricht könnte ich das nicht.
Der Mathematik-Unterricht am Gymnasium/Uni hat da vollkommen versagt.

Wenn Mathematik so wichtig für Programmieren wäre, warum gibt es dann so viele
Hobby-Programmierer und viele komplett Fach fremde.

@THUNDERDOMER & On topic.

deutlich wichtiger als Mathe, anderen vorhandenen Quellcode studieren, anpassen;
sich mit dem Teil des .NetFramework zu beschäftigen, den man braucht;
Wo findet man Hilfe/an was genau hakt es; Debuggen, Debuggen
Kurz: was ist das Problem und wie löse ich es auch mit Hilfe "anderer".

Zu guter Letzt ganz wichtig Englisch-Kenntnisse in Zeiten von Google :)

Zum Thema 2D System.Drawing.Drawing2D ist dein Freund (benutzt GDI+)

da sollten man die math. Begriffe kennen.

[pest]

entweder nebenbei bei Funktion("Relationen")


Eine Relation ist nicht unbedingt eine Funktion.



Wenn Mathematik so wichtig für Programmieren wäre, warum gibt es dann so viele
Hobby-Programmierer und viele komplett Fach fremde.


Weil nunmal 90% der Programme Klicki-Bunti sind. Hobby-Programmierer die 3D-Engines schreiben, MP3-Codecs oder dergleichen sind rar.
Heutzutage gibt es ja fast schon "alles". Da kann man einen dressierten Bären dransetzen der die Module zusammenklickt.

Ich kann sogar aus eigener Erfahrung sagen dass man mit entsprechenden Modulen und Beispielen recht ansehnliche Programme basteln kann, ohne sie wirklich zu verstehen.

[Ectoplasma]

Keine großen Mathematik-Kenntnisse? Zumindest so wie das normal aufgeschreiben wird braucht man dafür zumindest etwas Mengentheorie, und die lernt man nichtmal am Gymnasium.

In Hamburg wurde das 1974 in den Grundschulen eingeführt. Allerdings natürlich nur in einem minimalen Rahmen.



Ich will hier mal minimal Mathe in die Diskussion reinbringen.

Worum geht es bei Programmiersprachen? Es geht um das Thema Berechnbarkeit. Was steckt dahinter? Ich zitiere einmal aus dem Wiki:


Der Definitionsbereich der Funktion ist die Menge der Eingaben, für die der Algorithmus überhaupt eine Ausgabe produziert. Wenn der Algorithmus nicht terminiert, dann liegt die Eingabe nicht im Definitionsbereich.


Dabei stößt man auch auf Themen wie dem Lambda-Kalkül und der Turingmaschine. Sind diese beiden Themen wichtig für eine Programmiersprache? Nein sind sie nicht, da alle drei Themen gleichberechtigt sind. Trotzdem wird man im Studium damit konfrontiert. Damit hat man zwar ein gutes Hintergrundwissen, aber anwenden wird man niemals eines dieser Themen.

Wie siehts mit Mengenlehre aus? Sehe ich persönlich als das wichtigste Thema an. Aus meiner sicht ist es sogar eines der unabdingbaren Themen, die man beherrschen sollte.

Was ist mit dem Thema Kalküle? Ja könnte helfen. Das ist aber eines der Themen, die man nicht bewußt wahrnimmt. Man wendet es an, ohne sich groß gedanken zu machen. Vielleicht sollte man aber mal gelesen haben, worum es dabei geht.

Im Übrigen sehe ich es so, dass vorallem im OO Bereich sehr viel Semantik vorhanden ist. Ein semantisches OO Modell ist eine abstrakte, formale Beschreibung der wahrgenommenen Welt, z.B. in einem Projekt. Die Modellierung hat viel weniger mit Mathe zu tun, sondern ist eher ein rein kreativer Prozess. Die Kunst dabei ist es, sich auf das Wesentliche zu beschränken. Man muss Übung darin haben, wichtige von unwichtigen Informationen trennen zu können, um aus diesen ein verständliches Modell erstellen zu können, welches ein gegebenes Problem auch wirklich abbildet. Da kannst du noch so toll in Mathe sein, die nützt dir in solchen Fällen nur bedingt etwas.

[Monger]

Dann ist das Problem schon von jemand anderem gelöst worden und die "Programmierarbeit" beschränkt sich darauf die vorhandenen Legosteine richtig zusammenzusetzen. Das Resultat wird eine Anwendung sein die ein Problem löst für das es schon eine Lösung gibt, nämlich von demjenigen der die "Legosteine" ursprünglich programmiert hat.

JEDER Programmierer setzt im Endeffekt nur vorgefertigte Puzzle Steine zusammen. Der kleinste Puzzlestein einer Sprache ist die Syntax - auch die hat mal jemand programmiert, und weder brauchen die Programmierer zu wissen wie genau die Syntax funktioniert, noch hat der Entwickler der Syntax eine vollständige Vorstellung davon, was man mit seinen Puzzlesteinen alles tun kann.

Das selbe gilt selbstverständlich für Frameworks, aber eben auch für Code den man selber schreibt.


Ein Problem beschreiben kann man bald einmal. Der interessante Punkt ist wie man das Problem löst, das ist das womit sich Programmierer beschäftigen.

Siehe oben. Du unterschätzst dramatisch, wie komplex die Beschreibung eines Problems sein kann. Das ist ja nunmal auch der Kernpunkt jedes modernen Entwicklungsprozesses: dass man am Entwicklungsanfang relativ wenig Ahnung davon hat, was man zum Ende eigentlich haben möchte.
Wüsste man das, könnte man den Code einfach runterschreiben, und wäre fertig. Das funktioniert aber weder im großen noch im kleinen Maßstab.
In der Realität schreibt man eher jede Codezeile mindestens zweimal.

[Tiamat]

Naja, das ist doch eher so, dass man im Studium auch theoretische Informatik kennenlernt. Automaten und formale Sprachen, die quasi die Grundlage für den Entwurf von Programmiersprachen und Compiler sind.
Und jede gute Theo. Informatikvorlesung wird ihren grundsätzliche Gliederung an der Chomsky-Hierarchie orientieren, wo man irgendwann auch Typ-0 Sprachen begegnet, wo wiederum der Turingautomat eine Rolle spielt.

[Gast]

JEDER Programmierer setzt im Endeffekt nur vorgefertigte Puzzle Steine zusammen. Der kleinste Puzzlestein einer Sprache ist die Syntax - auch die hat mal jemand programmiert, und weder brauchen die Programmierer zu wissen wie genau die Syntax funktioniert, noch hat der Entwickler der Syntax eine vollständige Vorstellung davon, was man mit seinen Puzzlesteinen alles tun kann.

Das gilt für jede Sprache (Deutsch, Englisch, C++, Latein, Spanisch, Ruby...) und ist päzise nicht das worauf ich hinaus wollte.

Das selbe gilt selbstverständlich für Frameworks, aber eben auch für Code den man selber schreibt.

Hier bin ich entschieden andere Meinung. Die Legosteine eines Frameworks und die Legosteine aus denen die Sprache an sich besteht, und die du hier als gleichweritg hinstellst, sind für mich 2 grundlegend verschiedene Dinge.

Aufgabe: Ein Bild mit einem Gausskern filtern.
Lösungsweg Matlab:

I_filtered = imfilter(I,kernel);

Lösungsweg C++:
Filterung implementieren. Das ist die Formel mit den Doppelsummen. Die muss man erst einmal verstehen, sonst kann man das Problem nicht lösen.

Klar worin der Unterschied besteht?

Siehe oben. Du unterschätzst dramatisch, wie komplex die Beschreibung eines Problems sein kann. Das ist ja nunmal auch der Kernpunkt jedes modernen Entwicklungsprozesses: dass man am Entwicklungsanfang relativ wenig Ahnung davon hat, was man zum Ende eigentlich haben möchte.
Wüsste man das, könnte man den Code einfach runterschreiben, und wäre fertig. Das funktioniert aber weder im großen noch im kleinen Maßstab.
In der Realität schreibt man eher jede Codezeile mindestens zweimal.
Was du beschreibst sind die Schwierigkeiten des Design. Ich will ja nicht bestreiten dass das ebenfalls schwierig ist, und du hast sicher recht wenn du sagst dass man am Anfang oft nicht weiß was man am Schluss haben möchte. Das ganze hat nur mit der eigentlichen Programmierung wenig zu tun. Das siehst du daran dass du die beiden Prozesse nahezu vollständig voneinander trennen kannst: Die Anforderungen werden in Amerika spezifiziert, der Code wird in Indien geschrieben.
Für die Programmierung (darum geht es hier nämlich) wird quasi vorausgesetzt dass das Problem klar ist (was soll man denn sonst programmieren wenn man nichtmal weiß was), die Programmierarbeit besteht dann darin das Problem zu lösen.
Probleme sind meist recht einfach zu beschreiben. Das muss so sein weil es sollen ja Probleme gelöst werden die einen allgemeinen Nutzen haben, und das geht nur wenn das Problem in einfachen Worten gestellt werden kann sodass selbst ein Kind es versteht. Wenn du dir überlegst welche Problemem ein typischers Computerprgoramm löst dann trifft das auf die meisten zu.

Ich möchte mit dem ich ein Bild um 50% verkleinern/vergrößern kann.
Ich möchte ein Programm mit dem 2 Leute an verschiedenen Rechnern sich mithilfe eines Mikrofons übers Internet unterhalten können.
Ich möchte ein Programm, dass eine Aufnahme von 3 Leuten die gleichzeitig reden (man versteht nichts weil alles durcheinander geht) in 3 einzelne Aufnahmen aufteilen kann sodass man alles versteht.
Ich möchte ein Programm das den optischen Fluss aus einem Video berechnen kann.
Ich möchte ein Programm dass eine Musikdatei auf ein Zehntel ihrer Größe komprimiert ohne das der Benutzer einen Unterschied hört.

Die Probleme sind einfach. Nach deiner Ansicht wäre es also kein Problem "den Code einfach runterzuschreiben und fertig". Probier das mal...

[Monger]

Was du beschreibst sind die Schwierigkeiten des Design.
[...]
Das ganze hat nur mit der eigentlichen Programmierung wenig zu tun. Das siehst du daran dass du die beiden Prozesse nahezu vollständig voneinander trennen kannst: Die Anforderungen werden in Amerika spezifiziert, der Code wird in Indien geschrieben.

Das ist ein Irrtum, den wir auch gerade auf Arbeit auf sehr schmerzhafte Weise ausbaden müssen...
Der Implementierungsaufwand wird gnadenlos überschätzt. Der macht nichtmal 10% der Arbeit aus. In Wahrheit sind selbst so scheinbar triviale Aufgaben wie Algorithmen eigentlich eine Frage des Designs, und nicht der Implementierung. Aber das lässt sich auch an deinen Beispielen zeigen...


Ich möchte mit dem ich ein Bild um 50% verkleinern/vergrößern kann.

Soll das Bild gleichmäßig skaliert werden? Soll 50% der X und Y Achse gekürzt werden, oder soll die Fläche um 50% reduziert werden? Was, wenn das Seitenverhältnis eben nicht ohne Rest durch 50% teilbar ist? Soll NUR um 50% geteilt werden, oder willst du auch mal durch 30% teilen? Eventuell sogar vergrößern?


Ich möchte ein Programm mit dem 2 Leute an verschiedenen Rechnern sich mithilfe eines Mikrofons übers Internet unterhalten können.

Soll das Mikrofon ständig aktiv sein, oder Push to Talk? Wie gut soll die Tonqualität sein? Sprechen die Personen abwechselnd (Walkie-Talkie), oder sollen sie gleichzeitig sprechen können?


Ich könnte jetzt so endlos fortfahren, aber: wie die Beispiele hier zeigen, weißt du als Kunde eben oftmals gar nicht, was du eigentlich willst, und was die Konsequenzen daraus sind. Wenn man all diese Fragen durchgekaut hat, hat man gleichzeitig eine ziemlich präzise Vorstellung davon, wie etwas implementiert sein muss. Natürlich könnte sich der Entwickler diese Fragen auch selbst beantworten, und irgendeine Lösung implementieren... das ist dann leider auch was oftmals passiert. Hintendran hat man dann ein lauffähiges Programm, was nur leider nicht tut was es soll.
Syntaktisch fehlerfreien Code schreiben kann jeder. Code schreiben der tatsächlich etwas nützliches tut... das kann nicht jeder.

Um nochmal auf das Beispiel mit der Bildskalierung zu kommen: das erfordert natürlich etwas Forschungsarbeit. Irgendjemand muss sich mal zu irgendeinem Zeitpunkt mit Bildverarbeitung beschäftigt haben, und z.B. sagen können was für Interpolationsfilter es gibt, und welche Vor- und Nachteile sie haben.
Nur: das muss nicht unbedingt der Programmierer sein. Diese Expertise hat oft genug der Kunde, weil der hat ja offenbar ein professionelles Interesse an Bildverarbeitung. Alles was der Programmierer tun muss, ist dieses Fachwissen in etwas zu übersetzen womit der Computer was anfangen kann.

Um den Bogen dann wieder zur Mathematik zu schlagen: so ist es halt auch dort. Wenn mein Kunde gerne eine digitale Steuererklärung machen möchte, muss ich mich erstmal mit jemandem zusammen setzen der mir präzise erklären kann wie sich so ein Formular aufbaut. Wenn ich Lernsoftware schreiben soll, muss ich mich erstmal mit einem Pädagogen unterhalten. Wenn ich irgendwelche Quartalsberichte visualisieren will, sollte ich mich einerseits mit einem Mathematiker unterhalten, und andererseits mit einem Präsentationstechniker.

Wie gesagt: Programmieren ist eigentlich ein linguistisches Problem. Es dreht sich alles um das Finden einer gemeinsamen Sprache, um damit Probleme zu lösen.

[Coda]

triviale Aufgaben wie Algorithmen
;D

[Ectoplasma]

Probleme sind meist recht einfach zu beschreiben. Das muss so sein weil es sollen ja Probleme gelöst werden die einen allgemeinen Nutzen haben, und das geht nur wenn das Problem in einfachen Worten gestellt werden kann sodass selbst ein Kind es versteht.

Das ist eine komplett falsche Annahme, die vorallem häufig der Kunde hat. Ein Problem aufzuschreiben ist leicht. Aber hat man dabei alles berücksichtigt? Versteht mich der andere? Meinen wir wirklich das Gleiche? Wie sieht es mit der Spezifikation aus? Reicht der Deteilgrad? Jedes Problem hat einen Kontext, der u.U. auch aufgeschrieben werden muss, weil der Auftraggeber und der Umsetzer nicht das gleiche Fachwissen haben. Das läßt sich ewig weiterspinnen.

[airbag]

....
Wenn Mathematik so wichtig für Programmieren wäre, warum gibt es dann so viele
Hobby-Programmierer und viele komplett Fach fremde.



Sehe ich eigentlich auch so. Immerhin muss man um Programmieren zu können nicht wissen wie eine Sprache aufgebaut ist.
(hier fangen dann formale Grundlagen der Informatik an - was Mathe ist )
Dann fängt unteranderem aber schon die Unterscheidung zwischen Programmierung und Softwareentwicklung an.

[THEaaron]

Bei uns an der FH geht fast alles was in Programmierung gemacht wird mit Mathematik Hand in Hand. In den Fächern Einführung in die Informatik wurde eigentlich alles mit Mathematik verbunden. Finde ich aber auch gut so, da sich viele Probleme einfach sehr schön anhand bestimmter mathematischer Probleme zeigen und lösen lassen.

Bei Rekursion gab es dann z.B. Fibonacci und die Türme von Hanoi.

In den darauf folgenden Programmierkursen verschwand der mathematische Anteil danach allerdings wieder komplett. Nun geht es mehr um Design Patterns und co.

Zum Glück kann ich im 5. Semester gescheite Kurse belegen und steige dann in numerische Algorithmen und Computergraphik ein.

Trotz der ganzen Mathematik und der Zahlenschleuderei muss ich sagen, ob man Mathematik braucht hängt von dem ab was man realisieren möchte, und vor allem wie effizient man das ganze lösen möchte.

Mathe ist kein absolute must-have, erweitert das Feld der potentiellen Einsatzgebiete eines Programmiers jedoch enorm.

[airbag]

Bei uns an der FH geht fast alles was in Programmierung gemacht wird mit Mathematik Hand in Hand. In den Fächern Einführung in die Informatik wurde eigentlich alles mit Mathematik verbunden. Finde ich aber auch gut so, da sich viele Probleme einfach sehr schön anhand bestimmter mathematischer Probleme zeigen und lösen lassen.

Bei Rekursion gab es dann z.B. Fibonacci und die Türme von Hanoi.

In den darauf folgenden Programmierkursen verschwand der mathematische Anteil danach allerdings wieder komplett. Nun geht es mehr um Design Patterns und co.

Bei mir auch. Aber gerade die simplem Sachen, wie die Fibanoccifolge dienen doch eher die Umsetzung von Rekursion und Schleifen zu veranstaulichen.

Gerade in den Grundlagenmodulen geht es eigentlich eher um allgemeingültige Konzepte, die man anhand von bestimmten Programmiersprachen näher bringt.

Und da ist Mathe sicherlich immer dabei, aber dann nicht unbedingt auf dem Niveau, wie in den reinen Matheveranstaltungen. Siehe Analysis mit Konvergenz und Asymptotik und vergleiche mit Effizienz-/Komplexitätsberechnungen eines Algorithmus.

[Matrix316]

Ich sags nochmal anders:

Man braucht keine Mathe um programmieren zu können.

Aber man braucht Mathe um Mathematische probleme programmiertechnisch umsetzen zu können.

Sicher, hier und da braucht man auch mathematische Ansätze um etwas besser programmieren zu können, aber dafür reicht es bei google nachzufragen. ;)

Aber Programmiersprachen an sich haben mit Mathematik nicht unbedingt was zu tun. Variablen deklarieren/definieren, Structs, Klassen, Funktionen/Methoden, Arrays.... (ok, bei Arrays vielleicht wegen Matrizen und so ;)), aber sagen wir mal so: Man kann programmiersprachen lernen, ohne Mathematik studiert zu haben.

Im TI Studium hatten wir z.B. 3 Semester Mathematik und 3 Semester Informationsverarbeitung (was programmieren beinhaltete). Und die beiden Fächer überschnitten sich so gut wie garnicht.

[Gast]

Das ist ein Irrtum, den wir auch gerade auf Arbeit auf sehr schmerzhafte Weise ausbaden müssen...
Der Implementierungsaufwand wird gnadenlos überschätzt. Der macht nichtmal 10% der Arbeit aus.
Davon schrieb ich doch gar nichts...

Ich meinte dass du über Schwierigkeiten des Design schreibst, über Probleme die man wohl unter dem Oberbegriff "Softwareentwicklung" zusammenfassen könnte. Da geht es dann eben um Entwicklungsprozesse usw.

Aber das ist nicht das was ich unter Programmieren verstehe.

In Wahrheit sind selbst so scheinbar triviale Aufgaben wie Algorithmen eigentlich eine Frage des Designs, und nicht der Implementierung. Aber das lässt sich auch an deinen Beispielen zeigen...

Seriously? Oder auf deutsch: Echt jetzt?


Soll das Bild gleichmäßig skaliert werden? Soll 50% der X und Y Achse gekürzt werden, oder soll die Fläche um 50% reduziert werden? Was, wenn das Seitenverhältnis eben nicht ohne Rest durch 50% teilbar ist? Soll NUR um 50% geteilt werden, oder willst du auch mal durch 30% teilen? Eventuell sogar vergrößern?

Unabhängig davon wie jede dieser Fragen beantwortet wird, der Programmierer wird sich mit Bildskalierung auseinandersetzen müssen. Oder anders ausgedrückt: Dass sich der Programmierer mit Interpolation, Filter usw (->Mathematik!) aukennt ist die Voraussetzung. Wenn das nicht gegeben ist dann nützt es auch nichts wenn alle diese Fragen genauestens spezifiziert sind weil die Spezifikation nicht umgesetzt werden kann.


Soll das Mikrofon ständig aktiv sein, oder Push to Talk? Wie gut soll die Tonqualität sein? Sprechen die Personen abwechselnd (Walkie-Talkie), oder sollen sie gleichzeitig sprechen können?

S. oben. Solange man nicht weiß wie man ein Signal abtastet, komprimiert, in Pakete zerteilt und übers Netz schickt (->Mathematik!) nützt mir die genaueste Spezifiaktion nichts. Du setzt einfach voraus dass es für so ziemlich alles bereits einen fertigen "Legostein" gibt den du verwenden kannst.


Ich könnte jetzt so endlos fortfahren, aber: wie die Beispiele hier zeigen, weißt du als Kunde eben oftmals gar nicht, was du eigentlich willst, und was die Konsequenzen daraus sind. Wenn man all diese Fragen durchgekaut hat, hat man gleichzeitig eine ziemlich präzise Vorstellung davon, wie etwas implementiert sein muss. Natürlich könnte sich der Entwickler diese Fragen auch selbst beantworten, und irgendeine Lösung implementieren... das ist dann leider auch was oftmals passiert. Hintendran hat man dann ein lauffähiges Programm, was nur leider nicht tut was es soll.
Syntaktisch fehlerfreien Code schreiben kann jeder. Code schreiben der tatsächlich etwas nützliches tut... das kann nicht jeder.

Um nochmal auf das Beispiel mit der Bildskalierung zu kommen: das erfordert natürlich etwas Forschungsarbeit. Irgendjemand muss sich mal zu irgendeinem Zeitpunkt mit Bildverarbeitung beschäftigt haben, und z.B. sagen können was für Interpolationsfilter es gibt, und welche Vor- und Nachteile sie haben.
Nur: das muss nicht unbedingt der Programmierer sein. Diese Expertise hat oft genug der Kunde, weil der hat ja offenbar ein professionelles Interesse an Bildverarbeitung. Alles was der Programmierer tun muss, ist dieses Fachwissen in etwas zu übersetzen womit der Computer was anfangen kann.

Wir haben einfach unterschiedliche Vorstellungen von dem was Programmieren bedeutet. Ich hab mal den für mich relevanten Teil hervorgehoben. Das verstehe ich darunter ein Problem zu lösen.
Alles andere ist grob gesagt eben nur Legosteine richtig zusammenzusetzen.


Um den Bogen dann wieder zur Mathematik zu schlagen: so ist es halt auch dort. Wenn mein Kunde gerne eine digitale Steuererklärung machen möchte, muss ich mich erstmal mit jemandem zusammen setzen der mir präzise erklären kann wie sich so ein Formular aufbaut. Wenn ich Lernsoftware schreiben soll, muss ich mich erstmal mit einem Pädagogen unterhalten. Wenn ich irgendwelche Quartalsberichte visualisieren will, sollte ich mich einerseits mit einem Mathematiker unterhalten, und andererseits mit einem Präsentationstechniker.

Wie gesagt: Programmieren ist eigentlich ein linguistisches Problem. Es dreht sich alles um das Finden einer gemeinsamen Sprache, um damit Probleme zu lösen.
Ich sehe das anders. Vom Blickpunkt der Softwareentwicklung ist es richtig was du sagst. Du setzt voraus dass die "Problemlösung" einfach vorhanden ist, und das drumherum (Spezifikation, was will der Kunde, eben der ganze Entwicklungsprozess) ist das schwierige. Hat sicher was für sich.

Ich meine die Problemlösung, die du so salopp voraussetzt ist die eigentliche Herausforderung. Dort geht es nämlich darum neue und interessante Dinge zu tun. Dort werden neue Methoden entwickelt. Dort sind die klugen Köpfe zuhause die all das entwickeln was du dann als "Legostein" in deinem Projekt verwenden kannst. Das verstehe ich unter programmieren.

[Gast]

Aber man braucht Mathe um Mathematische probleme programmiertechnisch umsetzen zu können.

Sicher, hier und da braucht man auch mathematische Ansätze um etwas besser programmieren zu können, aber dafür reicht es bei google nachzufragen. ;)
Guter Punkt: Alle Probleme die man mit dem Computer lösen kann/möchte sind aus Prinzip mathematisch. Einfach deshalb weil der Computer mit Zahlen rechnet. Was anderes geht nicht.

[Matrix316]

Guter Punkt: Alle Probleme die man mit dem Computer lösen kann/möchte sind aus Prinzip mathematisch. Einfach deshalb weil der Computer mit Zahlen rechnet. Was anderes geht nicht.
Seltsam, dass ich Web Anwendungen programmiere mit C# und SQL und da wird nur sehr sehr sehr wenig so richtig berechnet. Vielleicht mal was geteilt oder addiert, aber eine Funktion kann mehr als nur Zahlenberechnen. Zum Beispiel Text den man in Textboxen und Grids eingibt in eine Email packen und diese versenden. Wo wird da was berechnet?

Natürlich sinds intern alles 1en und 0en und hin und her, aber davon merkt man als Programmierer (in VS) normalerweise nix.

Mathematik kann, muss aber nicht nötig sein. Eine string Variable hat mit Mathe z.B. garnichts zu tun. (für den Programmierer jedenfalls) ;D

[Monger]

Wir haben einfach unterschiedliche Vorstellungen von dem was Programmieren bedeutet. Ich hab mal den für mich relevanten Teil hervorgehoben. Das verstehe ich darunter ein Problem zu lösen.
Alles andere ist grob gesagt eben nur Legosteine richtig zusammenzusetzen.

Ich sags noch einmal: in der Realität wird das selten vom Programmierer gemacht. Die Leute die solche Form von Problemen lösen, haben nicht selten überhaupt nix mit Computern zu tun.

Die Aussagenlogik z.B. ist 2500 Jahre alt, die darauf aufbauenden Logikgatter sind mittlerweile auch knapp 200 Jahre alt, viele der heute bekannten Sortieralgorithmen sind auch weit älter als jeder Computer.

Ich will damit auch nicht die Bedeutung der klassischen Informatik kleinreden (die eben ursprünglich NICHTS mit Computern zu tun hatte, die nur mit Aufblühen der Digitaltechnik extrem populär wurde). Ohne diese Grundlagenforschung gäbe es heute keine Softwareindustrie.
Aber: Informatik ist heute mMn keine Grundlage mehr fürs Programmieren. Gott sei dank, sonst hätten wir da ein ernsthaftes Personalproblem. Andersrum ist ein guter Programmierer nicht auch automatisch ein guter Informatiker.

[Coda]

Andersrum ist ein guter Programmierer nicht auch automatisch ein guter Informatiker.
Das hättest du vielleicht gerne. Du redest wie ein Blinder von Farbe.

[PatkIllA]

Was den Punkt angeht hat Mr.Freemind recht, da brauchen wir wirklich nicht zu diskutieren. Informatik an den Unis ist sehr viel Mathematik.Ich fand das jetzt gar nicht so schlimm. Zumindest das was zum Durchkommen brauchte...

[Tesseract]

Informatik ist heute mMn keine Grundlage mehr fürs Programmieren.
was meinst du mit "informatik"? viele konzepte aus der informatik, von komplexitätstheorie über klassische logik bishin zu theoretischen grundlagen von typhierarchien etc. sind einfach voraussetzung. ohne zumindest die grundlagen dafür zu haben ist man kein programmierer.

[Gauron Kampeck]

Ich bin aber der Meinung, dass man zum Programmieren nicht unbedingt Mathe braucht, solange man mit dem Leben kann was einem der gegebene Baukasten zur Verfügung stellt. Wenn man allerdings an dessen Wände stößt hat man größtenteils Pech gehabt.
Ich glaube, dieser Abschnitt fasst den Nutzen der Mathematik für die Programmierung am besten zusammen.

Darüber hinaus ist der Anteil der Programmierkunst, der hier als Geisteswissenschaft dargestellt wird, nichts anderes als Mathematik. Mathematik ist eine Geisteswissenschaft. Abstrahieren (Reduzieren von Systembestandteilen unter der Voraussetzung, dass das Systemverhalten äquivalent bleibt), Assoziieren (Definieren von Abbildungen), Kategorisieren (Bilden von Mengen) sind mathematische Aufgaben.

[Monger]

Das hättest du vielleicht gerne. Du redest wie ein Blinder von Farbe.
Fühlt sich da jemand persönlich angegriffen? ;)

Ist ja nicht so, dass ich nicht auch Informatik studiert hätte. Aber ich provoziere ja hier nicht aus Langeweile, sondern ich spreche aus Erfahrung. Gibt nunmal einen konkreten Grund, warum ich darauf so rumreite.


Darüber hinaus ist der Anteil der Programmierkunst, der hier als Geisteswissenschaft dargestellt wird, nichts anderes als Mathematik. Mathematik ist eine Geisteswissenschaft. Abstrahieren (Reduzieren von Systembestandteilen unter der Voraussetzung, dass das Systemverhalten äquivalent bleibt), Assoziieren (Definieren von Abbildungen), Kategorisieren (Bilden von Mengen) sind mathematische Aufgaben.
Musik ist auch nur Mathematik: Harmonielehre ist nunmal pure Mathematik.

Dieses "alles ist Mathematik" Argument halte ich aber für ziemlich sinnlos, weil das vielleicht im weitesten Sinne Teil der Mathematik sein mag, aber nunmal nicht Bestandteil eine Mathematik Studiums (oder gar des Schulstoffs) ist.
Natürlich ist Mathematik ein Grundpfeiler unseres Universums - deshalb sind wir noch lange nicht alle Mathematiker.

[Tesseract]

Musik ist auch nur Mathematik: Harmonielehre ist nunmal pure Mathematik.
im prinzip ja, aber schonmal versucht musik streng nach symmerie und anderen harmonischen gesichtspunkten zu machen? ist meistens ziemlich langweilig. das was die musik ausmacht sind dann die abweichungen dieser symmetrie. :wink:

[Matrix316]

Man kann zum Beispiel sogar Musik machen, ohne Noten lesen zu können. ;)

[petersenk]

Eben. Musik ist *nicht* Mathe. Sie mag vielleicht durch diese beschrieben werden, niemals aber begründet oder hergeleitet. Man kann Musik auch nicht mathematisch vergleichen, da es schlicht keine mathematisch musikalischen Grössen gibt. Insofern ist Musik alles andere und eben überhaupt nicht Mathematik.

In der Informatik schaut die Situation allerdings ganz anders aus, denn hier ist die Mathematik ein mächtiges, d.h. genauer, ein grundlegendes Instrument. Ohne Mathematik ist Informatik ein belangloses Ratespiel. Suchalgorithmen? Scheiss egal. Die tun's ja alle, ne? Allso ne runde bogus-sort oder wie jetzt? :freak:

Programmieren mag im Alltag ja auch mal trivial und öde sein, grundsätzlich ändert sich aber nix an der Tatsache, dass man ohne mathematisches Rüstzeug hilflos überfordert sein wird, sobald man ein Problem lösen sollte, dass nicht mehr einfach nur trivial ist. Ohne Mathematik kann man auf dem Gebiet kein Experte sein, d.h. man kann keinen guten Rat erteilen. Wie ist ein Problem zu packen? Aus welchen Gründen? Wenn man hier keine soliden Antworten liefern kann, dann ist man wohl eher "Tippse" als sonst was... ;)

Und auch wenn man heutzutags öfter auch nur noch mit Hochsprachen unterwegs ist, kann man einen "Programmierer" der keine Ahnung von bits, bytes und gates hat doch nicht ernst nehmen. Boolsche Algebra und so, ne. Überhaupt, wie bildet man eine analoge Welt digital ab? Was meint ihr wohl, was für ein Typ von Programmierer z.B. Preise für seinen Webshop als Gleitkommazahlen behandelt, um dann nicht zu verstehen, woher all die Fehler kommen? Und mit was für workarounds und hacks dann wohl darauf eingeprügelt wird? ;D

Fazit: Ohne Freude an der Mathematik wird das nix. Na, einen WTF nach dem andern eben. :biggrin:

[Gauron Kampeck]

Musik ist auch nur Mathematik: Harmonielehre ist nunmal pure Mathematik.

Dieses "alles ist Mathematik" Argument halte ich aber für ziemlich sinnlos, weil das vielleicht im weitesten Sinne Teil der Mathematik sein mag, aber nunmal nicht Bestandteil eine Mathematik Studiums (oder gar des Schulstoffs) ist.
Natürlich ist Mathematik ein Grundpfeiler unseres Universums - deshalb sind wir noch lange nicht alle Mathematiker
Wenn er aber die Mathematik hinter Harmonie und Dissonanz versteht, versteht er auch warum sich manche Musik "schön" und andere "unschön" anhört. Er versteht halt die Theorie hinter der Praxis.
Nunja, gute Musik macht er deswegen noch nicht, aber hier enden auch die Vergleiche zur Informatik: Während das Musikempfinden doch eine eher subjektive Angelegenheit ist, orientiert sich die Informatik an objektiven Kriterien, an 0 und 1, an Registern und formalen Grammatiken. Natürlich gibt es auch hier Trends und Strömungen, doch halten sie sich im Vergleich zur Musik doch in Grenzen und betreffen mehr Ebene der Metainformation des Codes. Über (Musik-)Geschmack lässt es sich doch besser streiten als über die Wahl von Graph-Algorithmen.;) Wer aber die Theorie von Abbildungen versteht, versteht es sinnvoller Daten zu assoziieren, wer die Sätze der Mengenlehre kennt, wird im Speziellen seine Kompositionen effizienter gestallten können.

[petersenk]

Wenn er aber die Mathematik hinter Harmonie und Dissonanz versteht, versteht er auch warum sich manche Musik "schön" und andere "unschön" anhört.
Nur, wenn in der Informatik etwas "unschön" ist, dann gibt es da auch gar keine Zweifel. Bockmist bleibt Bockmist. In der Musik hingegen ist Dissonanz nicht per Definition "unschön", ganz im Gegenteil ist Dissonanz gerade ein Stilmittel mit teils herrlich "schöner" Wirkung.

Er versteht halt die Theorie hinter der Praxis.
Das hingegen ist natürlich klar. Mathematik hilft immer und überall. Auch beim Musizieren. :wink:

Wer aber die Theorie von Abbildungen versteht, versteht es sinnvoller Daten zu assoziieren, wer die Sätze der Mengenlehre kennt, wird im Speziellen seine Kompositionen effizienter gestallten können.
Kurzum, wer von Mathematik keine Ahnung hat, sich aber dennoch Programmierer/Informatiker schimpft, hat doch sein Handwerk gar nie wirklich erlernt. Er ist somit zum Nachäffen verdammt. Eigenständiges Denken und Arbeiten ist dann halt eben nicht (ob dies dann nun konkrete Voraussetzung für Job A ist oder nicht, sei mal dahingestellt...).

[nalye]

Bzgl. Mathematik und Musik gibt es hier einen wunderbaren Podcast: http://mathcast.org/aktuell/splitter/splitter06.html

[Matrix316]

Naja, im Ausgangsposting heißt es ja: Man kann nichts mit c++ oder Java anfangen, weil man keine Mathematik kann, aber das stimmt so nicht.

Und Java und C++ ist genauso Visual wie Basic. Man muss nur eine IDE haben, die das unterstützt. C# ist zwar einfacher, aber um wirklich in programmieren reinzukommen, würde ich erstmal mit

c

anfangen.

Wenn man c verstanden hat, dann gibts kaum Grenzen. Wenn einem klar ist, dass eine Klasse auch nur ein großer struct mit Funktionen ist, dann braucht man auch keine Angst vor objektorientierter Programmierung zu haben. ;D

[Exxtreme]

Nahhh! Objektorientierte Programmierung ist schon wesentlich mehr als Strukturen mit Funktionen. Zumal man Letzteres auch schon in C haben kann mit bissl Aufwand.

Fies am Übergang von C nach C++ fand ich zu erkennen wann man eine Klasse ableiten MUSS und wann nicht. Das hat mich schon öfter auf einen falschen Pfad gelenkt da ich davon ausging, dass man die Klasse einfach mal so verwenden kann. :D

[Marscel]

Wenn man c verstanden hat, dann gibts kaum Grenzen. Wenn einem klar ist, dass eine Klasse auch nur ein großer struct mit Funktionen ist, dann braucht man auch keine Angst vor objektorientierter Programmierung zu haben. ;D

Bis du auf Templates stößt - nicht bloß das einfache Zeug wie irgendwelche Container. Dann kannst du auch jemanden, der mit OO auch schon sinnvolles angestellt, erstmal zum Stöhnen bringen.

Und aus aktuellem Anlass, da ich gerade einen Bug in OpenOffice suche, das macht schon an manchen Stellen Kopfschmerzen. Gerade ohne konsistente Dokumentation.

[PHuV]

Kurzum, wer von Mathematik keine Ahnung hat, sich aber dennoch Programmierer/Informatiker schimpft, hat doch sein Handwerk gar nie wirklich erlernt. Er ist somit zum Nachäffen verdammt. Eigenständiges Denken und Arbeiten ist dann halt eben nicht (ob dies dann nun konkrete Voraussetzung für Job A ist oder nicht, sei mal dahingestellt...).

Blödsinn! Erst mal die Frage, was man unter Mathematik versteht, oder wie umfangreich mathematisches Wissen vorhanden sein muß. Umrechnen in Zahlensystemen? Boolsche Algebra? Integralrechnung, rechnen mit komplexen Zahlen....? Zudem kenne ich eine Menge Leute, die heute sehr wohl erfolgreich in IT-Bereichen arbeiten, und nur geringe Kenntnisse von (komplexer) Mathematik haben.

Monger hat in dem Punkt recht, daß was an den Unis an Mathematik gelehrt wird, ist für die meisten geforderten Programmiertätigkeiten irrelevant. Und genau darum geht es hier. Wie umfangreich müssen mathematische Kenntnisse vorliegen? Ich habe in meiner ganzen Programmierkarriere nicht mit dem Konzept der Turing-Maschine, Gödelisierung oder Integralrechnung, geschweige den irrationale Zahlen arbeiten müssen. Auch habe ich bisher nirgendwo das Wissen um Diskrete Algebraische Strukturen (das heißt u.U. bei den Unis unterschiedlich) oder Logik und Berechnenbarkeit, wie ich es beispielsweise an der Uni lernen mußte, praktisch anwenden müssen.

Wenn ich heute die Schulaufgaben meiner Kinder sehen (Geometrie), da muß ich - ehrlich gesagt - auch erst mal wieder intensiv nachdenken mit Sinus, Cosinus, Logarithmus etc.:redface: Die meisten Programmierarbeiten (im Sinne von Anwendungsvolumen) sind heute eben konkrete Anwendungen für den Bereich Datenverarbeitung, Speicherung, Statistiken und Datenumwandlung/Konvertierung. Natürlich gibt es Spezialbereiche, in denen höhere Mathematik wichtig ist, aber die kann man heute an einer Hand abzählen. Schaut doch nur mal in die Stellenanzeigen von Stepstone oder Monster, da sind die meisten Anforderungen heute rein anwendungsbezogen.

Und nochmals, welche Art von Mathematik ist wichtig für das Programmieren? Machen wir doch mal eine Liste, was jeder für das allgemeine und alltägliche Programmieren erforderlich halten, ich mache mal einen Vorschlag:


Kenntnisse von Brüchen, Rechenregeln, Dreisatz, Geometrie, Binomische Formeln etc. (ich sehe sie mal als Grundkennrisse und als trivial an).
Beherrschung (mit Umrechnung, und Verständnis der Bedeutung) der verschiedenen Zahlensysteme: Binär, Oktal, Hex
Verständnis von Schaltungslogik und boolscher Algebra
Kenntnisse von Hashfunktion, Prüfsummen und Prüfziffern etc.
Grundkenntnisse von Statistik?

Jetzt fäng es schon an, kritisch zu werden

Kenntnisse von Matrizenrechnung?

Nun, gerade für Arrayverarbeitung halte ich es wichtig, das Prinzip dahinter zu verstehen, damit man komplexe Arrays (ab 2-3fach Arrays) anwenden kann. Aber die meisten Programmierer versuchen im Alltag schon eher, bis maximal 2-fach-Arrays zu gehen, und die 3-fachen zu vermeiden.

Wie gesagt, bedenkt bitte, daß es jetzt nicht um das Umsetzen von komplexen mathematischen Problemfeldern geht, sondern ganz simple Dinge wie I-O-Verarbeitung, Lesen und Schreiben, Speicherung von Daten, Verarbeiten und Sammeln von Daten, Stringverarbeitung, Zahlenverarbeitung.

Ich bitte um weiter Vorschläge und Hinweise.

[Tesseract]

Jetzt fäng es schon an, kritisch zu werden

Kenntnisse von Matrizenrechnung?


hängt halt davon ab was man machen will.
fürs 3d-rendering sind matrizen wichtiger als so ziemlich jedes andere feld der mathematik. ohne matrizen geht da einfach garnix.

[Gast]

Kenntnisse von Matrizenrechnung?


Signalverarbeitung. Computational Intelligence. Embedded Systems. Computer Grafik. Numerische Optimierung.
Und das sind alles riesige Gebiete. Alleine Signalverarbeitung geht von Handy über Akustik über Spracherkennung bis Biosignalverarbeitung in der Medizintechnik.
Bei allem was über Klickibunti bzw. die typischen Webanwendungen hinausgeht brauchst du Matrizenrechnung und meistens gleich noch Analysis, lineare Algebra und Statistik/Stochastik dazu. Und das ganze meistens nicht zu knapp.

[Ectoplasma]

Fies am Übergang von C nach C++ fand ich zu erkennen wann man eine Klasse ableiten MUSS und wann nicht.

Das Wort MUSS passt an dieser stelle schonmal gar nicht. Das ist nämlich der Beginn von schlechter Software. Es gibt zudem keine formalen Entscheidungskriterien für eine Ableitung. Ne sorry aber da würde ich an deiner Stelle nochmal nachlesen, wann eine Ableitung sinnvoll sein könnte. Ableitungen sind auf jeden Fall mit Vorsicht und Bedacht zu wählen.

[Ook!]

Lohnt sich erst mal wieder mit Visual Basic 2010 anzufangen und einen guten Buch zulegen und lernen? Oder andere Programmiersprache besser anfangen?

Mittlerweile sind alle aktuellen Programmiersprachen recht einsteigerfeindlich. Und das ist auch so gewollt. Der Gedanke, daß heute noch jemand wirklich programmieren lernt, wäre für viele Konzerne einfach zu schrecklich und eine ernste Bedrohung für jeden etablierten Standard. Die derzeit verfügbaren Programmiersprachen kommen nicht aus dem nichts, sondern stellen im Grunde eine Sammlung von Programmierwerkzeugen dar, auf die irgendjemand bereits ein Copyright hat. Und zwar nicht nur auf die Sprache, sondern auch auf alle deren Folge-Produkte. Das ist so ein bischen, als ob man ein Puzzle (aus Code) zusammenfügt... und anschließend darf man es nicht verkaufen, sonst wird man von Copyright-Anwälten zur Sau gemacht.

Falls dich das Thema 'Programmieren' wirklich interessiert, dann brauchst du dafür strenggenommen keinerlei mathematische Kenntnisse, die über die 4 Grundrechenarten hinausgehen. Warum solltest du mehr können als deine CPU? Denk da mal drüber nach. Das was du brauchst sind fundierte Hardwarekenntnisse und den zugehörigen Maschinencode. Ein guter Assembler kann hilfreich sein, ersetzt aber nicht die notwendigen Hardwareskills.

In erster Linie solltest du dich in Ruhe hinsetzen und überlegen, was genau dein Ziel ist: Möchtest du wirklich programmieren oder vielleicht doch bloß puzzeln? - 99,9% aller Leute, die sich heute für Programmierer (C++/Java/etc) halten, können in Wirklichkeit nur vorgefertigte Puzzlestücke aus vorhandenen DLLs zusammenfügen. Wenn ein Problem auftaucht, dann wird einfach solange rumgepuzzelt, bis man ein Stück Code entdeckt, welches besser in die Lücke paßt. Im Prinzip sind heute fast nur noch Puzzlespieler unterwegs. Manche von denen lösen Puzzles mit 1500 Teilen, andere beschränken sich zur Lösung eines Problems auf Puzzles mit 500 Teilen, wo die vorgefertigten Stücke dann entsprechend größer sind (und teils sogar Werbung enthalten). Die Krönung sind dann Programmiertools vom Kaliber eines Netobjects Fusion. Dort kann jeder Analphabet mittels Drag&Drop eine eigene Website aus vorgefertigten Elementen in unter 5 Minuten selbst erstellen. Das wirklich traurige daran: Diese Websites sehen in erschreckend vielen Fällen wesentlich besser aus und funktionieren sogar auch noch besser als das, was sich so mancher professionelle Java/Html-Programmierer in tagelanger Arbeit aus dem Hirn saugt.

Falls du wirklich programmieren möchtest, dann verschwende keine Zeit und installiere dir ein Linux und besorg dir dort einen freien Assembler. Vielleicht noch ein Buch über deine derzeitige Hardware. Das große Geheimnis vieler erfolgreicher Programierer ist, daß sie keine Bücher über Programmierung lesen, sondern über Hardware und Dateiformate. Bücher über Programmierung kaufen und lesen nur Puzzlespieler.

Am Ende zählt oft nur das Ergebnis. - Manche sind mit einem Programm aus vorgefertigten Puzzlestückchen zufrieden. Wie sieht es bei dir aus? Solange das nicht geklärt ist, kann man dir nicht wirklich hilfreiche Tips geben.

[Tesseract]

ich weiß ja nicht was du für eine seltsame vorstellung vom programmieren hast, aber das "puzzeln" wie du es nennst gehört da genau so dazu. und heute mit assembler statt einer hochsprache anzufangen halte ich für ziemlichen unsinn. damit kannst du kritischen code optimieren aber mit sicherheit keine ordentlichen projekte mit sinnvollem zeitaufwand fertig bekommen.
außerdem ist die komplette std von c++ und ein ganzer haufen guter libs frei für jeden. bei java ebenso.

[Exxtreme]

Mittlerweile sind alle aktuellen Programmiersprachen recht einsteigerfeindlich. Und das ist auch so gewollt. Der Gedanke, daß heute noch jemand wirklich programmieren lernt, wäre für viele Konzerne einfach zu schrecklich und eine ernste Bedrohung für jeden etablierten Standard. Die derzeit verfügbaren Programmiersprachen kommen nicht aus dem nichts, sondern stellen im Grunde eine Sammlung von Programmierwerkzeugen dar, auf die irgendjemand bereits ein Copyright hat. Und zwar nicht nur auf die Sprache, sondern auch auf alle deren Folge-Produkte. Das ist so ein bischen, als ob man ein Puzzle (aus Code) zusammenfügt... und anschließend darf man es nicht verkaufen, sonst wird man von Copyright-Anwälten zur Sau gemacht.
Das ist ein Horror-Märchen. Die GPL ist so eine virulente Lizenz, aber ansonsten ist mir sowas noch gar nicht untergekommen bei den gängigen Programmiersprachen und Werkzeugen.
In erster Linie solltest du dich in Ruhe hinsetzen und überlegen, was genau dein Ziel ist: Möchtest du wirklich programmieren oder vielleicht doch bloß puzzeln? - 99,9% aller Leute, die sich heute für Programmierer (C++/Java/etc) halten, können in Wirklichkeit nur vorgefertigte Puzzlestücke aus vorhandenen DLLs zusammenfügen. Wenn ein Problem auftaucht, dann wird einfach solange rumgepuzzelt, bis man ein Stück Code entdeckt, welches besser in die Lücke paßt. Im Prinzip sind heute fast nur noch Puzzlespieler unterwegs. Manche von denen lösen Puzzles mit 1500 Teilen, andere beschränken sich zur Lösung eines Problems auf Puzzles mit 500 Teilen, wo die vorgefertigten Stücke dann entsprechend größer sind (und teils sogar Werbung enthalten). Die Krönung sind dann Programmiertools vom Kaliber eines Netobjects Fusion. Dort kann jeder Analphabet mittels Drag&Drop eine eigene Website aus vorgefertigten Elementen in unter 5 Minuten selbst erstellen. Das wirklich traurige daran: Diese Websites sehen in erschreckend vielen Fällen wesentlich besser aus und funktionieren sogar auch noch besser als das, was sich so mancher professionelle Java/Html-Programmierer in tagelanger Arbeit aus dem Hirn saugt.
Mit vorgefertigten Puzzlestücken ist man erheblich produktiver als z.B. Buttons Pixel für Pixel selbst zu zeichnen. Ansonsten liest sich dieser Abschnitt schon sehr pseudo-elitär. Aber hey! Früher hat man Gepäck noch selbst getragen und nicht mit einem Wagen hinter sich her gezogen. Damals ... vor der Erfindung des Rades.
Falls du wirklich programmieren möchtest, dann verschwende keine Zeit und installiere dir ein Linux und besorg dir dort einen freien Assembler. Vielleicht noch ein Buch über deine derzeitige Hardware. Das große Geheimnis vieler erfolgreicher Programierer ist, daß sie keine Bücher über Programmierung lesen, sondern über Hardware und Dateiformate. Bücher über Programmierung kaufen und lesen nur Puzzlespieler.

Dummerweise bekommen die Puzzlespieler den nächsten Auftrag und nicht die Button-Zeichner.

[Tiamat]

Das Wort MUSS passt an dieser stelle schonmal gar nicht. Das ist nämlich der Beginn von schlechter Software. Es gibt zudem keine formalen Entscheidungskriterien für eine Ableitung. Ne sorry aber da würde ich an deiner Stelle nochmal nachlesen, wann eine Ableitung sinnvoll sein könnte. Ableitungen sind auf jeden Fall mit Vorsicht und Bedacht zu wählen.

Es muss von einer Klasse abgeleitet werden, wenn sie mindestens eine abstrakte Methode beinhaltet. Ein Interface muss auch implementiert werden, das man mit schlechter Software gar nix zu tun ^^

Was Assembler angeht. Man kann sich dort auch Libs angelegen, in denen man Subroutinen speichert. Bei genügend vielen Routinen kann man irgendwann auch komfortabel arbeiten, aber bis dahin hinkt man der Konkurrenz(Hochsprachenprogrammierer) gnadenlos hinterher und ob der das eigene Gefrickel dann besser läuft, als der mit O2 oder O3 optimierte Code des C/C++ Compiler wage ich auch schwer zu bezweifeln.

[huha]

Extrem systemnahe Programmierung heute auf x86 halte ich für reichlich sinnlos. x86 ist eine ziemlich überladene, gewachsene Architektur, die echt keinen Spaß macht. Wenn einen wirklich systemnahe Programmierung interessiert, sollte man sich mal im Bereich der RISC-Microcontroller umschauen, da gibt's teilweise wirklich schöne Maschinen und die dazugehörigen Assembler.

Ansonsten braucht man beliebig viel Wissen, um maschinennah zu programmieren. Erstens muß man natürlich alle wichtigen Standard-Algorithmen richtig gut kennen (und auch um deren Vor- und Nachteile wissen; üblicherweise vertraut man darauf, daß in der Standard-Library die richtigen ausgewählt werden--oftmals sind das jedoch Speicherfresser (schlecht für Rechner mit sehr wenig Speicher) oder schreiben recht viel (schlecht für sortieren von Daten im EEPROM/Flash)) und dann muß man die Eigenheiten der Maschine beachten. Gerade für Anfänger ist das relativ ungeeignet, da es teilweise arg abstruse Architekturen gibt.

Das Argument, man bräuchte für maschinennahe Programmierung keine Mathematikkenntnisse, ist allerdings völlig aus der Luft gegriffen. Gerade dort braucht man alles, weil man sich ja seinen gesamten Code schreiben darf. Wenn du dort mal irgendeine trigonometrische Funktion brauchst und nicht auf Standard-Libraries zurückgreifen willst (und trigonometrische Funktionen braucht man schneller als einem lieb ist), dann mußt du nicht nur genau wissen, wie schnell (Tabelle) und wie genau (große Tabelle mit Interpolation, Reihenentwicklung) du das Zeug brauchst, sondern auch, wie man dorthin kommt. Während der Hochsprachen-Programmierer also float foo = sin(bar) schreibt und damit alles erledigt ist (er muß natürlich schon wissen, was das bewirkt und für was er das in seinem Problem braucht, aber davon gehen wir mal aus, da es der maschinennahe Programmierer genauso wissen muß), muß sich der maschinennahe Programmierer erstmal überlegen, was der Sinus überhaupt ist ist dann entsprechende Routinen schreiben, um diesen zu berechnen. Hierbei muß er auf die Geschwindigkeit des Prozessors und die gewünschte Genauigkeit des Ergebniswertes Rücksicht nehmen sowie ebenfalls darauf achten, daß die Berechnungsschritte in numerisch sinnvollen Reihenfolgen erfolgen, um die Qualität des Ergebnisses nicht zu beeinträchtigen. Das ist nicht ganz trivial und erfordert viel umfangreichere Kenntnisse der Mathematik als das einfache Benutzen einer Funktion in einer Library. Dann muß man nämlich nur wissen, für was man die braucht (was natürlich ebenfalls ordentliche Mathematikkenntnisse voraussetzt), man muß sie aber nicht von Grund auf entwerfen und schreiben.

-huha

[Ectoplasma]

Es muss von einer Klasse abgeleitet werden, wenn sie mindestens eine abstrakte Methode beinhaltet. Ein Interface muss auch implementiert werden, das man mit schlechter Software gar nix zu tun ^^

Ich meinte das mehr aus semantischer Sicht. Eine Interface Implementierung ist übrigens keine klassische Ableitung. Einzig bei der abstrakten Klasse stimme ich dir zu.

[Tiamat]

Das Interface hab ich auch nur mit einbezogen, weil man da auch in der Pflicht steht, die vorgegebenen Methoden zu definieren.

[Gauron Kampeck]

Falls dich das Thema 'Programmieren' wirklich interessiert, dann brauchst du dafür strenggenommen keinerlei mathematische Kenntnisse, die über die 4 Grundrechenarten hinausgehen. Warum solltest du mehr können als deine CPU? Denk da mal drüber nach.
Ähm, weil du der CPU sagen musst, was sie tun soll?! Wie möchtest du denn eine Integration mit den mathematischen Kenntnissen der vier Grundrechenarten in die diskrete Welt eines Rechenwerks abbilden?
Auch der Rest deines Beitrags ist hanebüchener Unsinn. Was du völlig unzutreffend als "puzzeln" bezeichnest, ist nichts anders als das Nutzen verschiedener Abstraktionsebenen, also ein Standardvorgehen zur Komplexitätsreduktion, eine Notwendigkeit zur Konstruktion komplexer Systeme und damit Handwerkszeug jedes Entwicklers, sei es weil er sie verwendet oder weil er sie erschafft. Wer versucht komplexe informationstechnische Systeme (abseits von wirklich performancekritischen Abschnitten) in Assembler zu entwickeln, ist kein guter Programmierer. Selbst C stößt hier sehr schnell an seine Grenzen (ich darf mich aktuell mit dem Resultat einer solchen Entwicklung rumschlagen).

[THUNDERDOMER]

Ist das ein Buch von den Buchladen Thalia "Von Kopf bis Fuß - C#" für 49,95€ gut? Was anderes wie Dummies oder so gibt es nur C++ und Visual Basic :(

Habe keinerlei Erfahrung mit Büchern.

[PatkIllA]

Ist das ein Buch von den Buchladen Thalia "Von Kopf bis Fuß - C#" für 49,95€ gut? Was anderes wie Dummies oder so gibt es nur C++ und Visual Basic :(

Habe keinerlei Erfahrung mit Büchern.Die haben einen etwas ungewöhnlichen Stil.
Die sind auf jeden Fall dafür gemacht von vorne nach hinten durchzuarbeiten. Als Nachschlagewerk sind die völlig ungeeignet.

[Exxtreme]

Ist das ein Buch von den Buchladen Thalia "Von Kopf bis Fuß - C#" für 49,95€ gut? Was anderes wie Dummies oder so gibt es nur C++ und Visual Basic :(

Habe keinerlei Erfahrung mit Büchern.
http://www.amazon.de/C-von-Kopf-bis-Fu%C3%9F/dp/3897216523/ref=sr_1_6?ie=UTF8&qid=1302977945&sr=8-6


Die Bewertungen lesen sich gut. :)

[huha]

Ich würde da kurz probelesen, bevor ich mir das Buch kaufe. Der Stil ist ... ungewöhnlich. Manche können was damit anfangen, manche nicht. Die Üebrsetzungen der Serie sind von schwankender Qualität, wenn du aber keine literarischen Meisterwerke lesen mußt, um was zu lernen, tun's die auch.

-huha

[pest]

voraussetzt), man muß sie aber nicht von Grund auf entwerfen und schreiben.


nicht gleich übertreiben, ein


fldl [adresse]
fsin


machts auch, zumindest auf x86

[Matrix316]

Ist das ein Buch von den Buchladen Thalia "Von Kopf bis Fuß - C#" für 49,95€ gut? Was anderes wie Dummies oder so gibt es nur C++ und Visual Basic :(

Habe keinerlei Erfahrung mit Büchern.

Für C fand ich das hier garnet so schlecht. http://www.amazon.de/C-Programmieren-Anfang-Helmut-Erlenk%C3%B6tter/dp/3499600749/ref=sr_1_1?ie=UTF8&qid=1302982952&sr=8-1 Für C# reichte dann google. ;)

[PHuV]

Ist das ein Buch von den Buchladen Thalia "Von Kopf bis Fuß - C#" für 49,95€ gut? Was anderes wie Dummies oder so gibt es nur C++ und Visual Basic :(

Habe keinerlei Erfahrung mit Büchern.

Arbeite einfach mal stupide Seite für Seite so ein Buch durch. Nimm so ein Buch wie Java 2 in 21 Tagen oder sowas. Mache jede Woche ein Kapitel. Arbeite es gewissenhaft durch. Dann hast Du wenigstens mal einen ersten Einstieg.

[Mosher]

Kann ich auch empfehlen.

Java eignet sich schon ganz gut für den Einstieg, es gibt zahlreiche Dokumentationen im Netz und selbst grafische Anwendungen sind schnell programmiert.

Mit Mathematik kommst du bestimmt erst mal nicht großartig in Berührung, soviel ist sicher.
Da ich aus dem ersten Post irgendwas mit Fraktalen gelesen hab:

Mach dir doch ein Java-Applett, da folgendes kann:



Benutzereingaben:

-Fläche des Quadrats in pixel²
-Winkel des Dreiecks
-Rekursionsstufe
-Farbschema ("Traum in blau", "Dark", "psychedelic")

Funktionen:

zeichneBaum (abhängig von den Koordinaten des Quadrats und des gewählten Farbschemas wird ein Element des Fraktals gezeichnet)
zeichneBaumrek (Funktion, die sich selbst so oft aufruft, bis das zu zeichnende Objekt eine bestimmte Größe unterschreitet. Es werden die Koordinaten der Nachfolgeelemente errechnet und die Funktion zeichneBaum aufgerufen)




und schon haste ein kleines Applet, das dir einen Pythagorasbaum (http://de.wikipedia.org/wiki/Pythagorasbaum) in deinen vorbestimmten
Farben zeichnet. Wird zwar bestimmt mindestens eine Woche dauern, bis alles funktioniert, aber dann hast du schon mal vieles gelernt, was man für Java braucht.
Wenn dir der Baum zu langweilig ist, experimentier mit anderen Formen rum, die Grenzen sind quasi nicht vorhanden.

[Fairy]

Eine kurze Frage: Taugt das kostenlose C# 2010 Buch von Galileo Computing was für Anfänger?

Das letzte mal habe ich mich ca. 2003 mit Programmierung befasst. Leichte Kenntnisse habe ich bereits/noch in Basic, VB und C++. Ich möchte jetzt aber noch mal mit C# sauber und vernünftig einsteigen, am besten erst mal ohne Geld auszugeben. Das Buch würde ich weitestgehend lesen/durcharbeiten, probieren die Beispielprogramme zu verstehen und zu schreiben und auch zu probieren, eigene Programme zu schreiben.

[Marscel]

Eine kurze Frage: Taugt das kostenlose C# 2010 Buch von Galileo Computing was für Anfänger?

Für den absoluten Anfänger überhaupt nicht. Das Buch ist mehr für Leute, die was anderes draufhaben und wissen wollen, was in C# neu oder anders ist.

Versuchs einfach mal, wirst ja sehen, ob du mitkommst und was Fragen offen lässt.

[petersenk]

http://mitpress.mit.edu/sicp/

^^ Pflichtlektüre. Zudem eine Sprache wie Scheme/Racket gerade für Anfänger um Längen besser geeignet ist, als sowas wie Java. public static void main(String[] args)? WTF? Da ist man als Anfänger doch gleich erstmal total überfordert. Was man da für ein popeliges Hello World nicht bereits schon alles wissen und möglicherweise auch schon verstehen sollte... das geht ja auf keine Kuhhaut.
Arbeite SICP durch, da kann man sich auf das wesentliche konzentrieren, völlig befreit von all der Syntaxgrüze, tausend und zwei Bibliotheken und weiss der Geier was noch alles...

[huha]

Mit Mathematik kommst du bestimmt erst mal nicht großartig in Berührung, soviel ist sicher.
Vgl.:


Mach dir doch ein Java-Applett, da folgendes kann:


...


:ulol:
Das sind gleich dutzende konkrete Anwendungen von mathematischen Sachverhalten. Teilweise auch etwas fortgeschrittener, da man ja ordentlich Trigonometrie braucht.
Dann davon zu sprechen, daß man mit Mathematik sicher erstmal nicht großartig in Berührung kommt, ist geradezu zynisch.

Wird zwar bestimmt mindestens eine Woche dauern, bis alles funktioniert, aber dann hast du schon mal vieles gelernt, was man für Java braucht.
Es wird viel länger als eine Woche dauern, wenn man da nicht richtig schön systematisch und mit Ahnung rangeht. Ich bezweifle sogar, daß es überhaupt fertig wird, wenn man noch nicht allzu viel programmiert hat und demnach nicht weiß, wie man sich einem solchen Problem zu nähern hat.
Es ist ein schönes Projekt, wenn davon auszugehen ist, daß die mathematischen Grundlagen bekannt und trivial sind und man schon einige Sachen der Programmiersprache kennt, keine Frage. Aber ein Einsteiger-Projekt ist das auf keinen Fall.

http://mitpress.mit.edu/sicp/

^^ Pflichtlektüre. Zudem eine Sprache wie Scheme/Racket gerade für Anfänger um Längen besser geeignet ist, als sowas wie Java. public static void main(String[] args)? WTF? Da ist man als Anfänger doch gleich erstmal total überfordert. Was man da für ein popeliges Hello World nicht bereits schon alles wissen und möglicherweise auch schon verstehen sollte... das geht ja auf keine Kuhhaut.
Arbeite SICP durch, da kann man sich auf das wesentliche konzentrieren, völlig befreit von all der Syntaxgrüze, tausend und zwei Bibliotheken und weiss der Geier was noch alles...

Ich weiß nicht, ob man sich als Normalsterblicher ein Uni-Buch antun will, das auch noch mit Scheme arbeitet. Ich denke, daß gerade als Person, die kein Informatikstudium unternimmt, solche Bücher zuviele Grundlagen und zu wenig konkret in Projekte umsetzbare Informationen enthalten. Außerdem fehlt dann auch noch die begleitende Vorlesung dazu, was es nochmal schwieriger macht. Im Prinzip eine gute Idee, solange man genug Willen hat, sich wirklich durchzukämpfen und alles zu verstehen. Wenn einem die Sprache nicht liegt, dann kann das extrem anstrengend werden, daher würde ich es eher nicht empfehlen, solange nicht bekannt ist, wie es diesbezüglich aussieht.

-huha

[Ook!]

heute mit assembler statt einer hochsprache anzufangen halte ich für ziemlichen unsinn.
Nein das ist kein Unsinn. Wenn man bei Null anfängt (oder fast bei Null), dann sind alle Programmiersprachen gleich schwer zu erlernen. Um höhere Programmiersprachen später richtig einsetzen zu können, muß man die Grundlagen ebenfalls beherrschen. Ansonsten wird man kein Programmierer, sondern ein Puzzlespieler, der schauen muß, was im Karton geliefert wird, und der schon beim kleinsten Problemchen auf die Hilfe anderer angewiesen ist. C++ ...malen nach Zahlen... schaffen sie ihr eigenes Meisterwerk!! :ulol:


damit kannst du kritischen code optimieren aber mit sicherheit keine ordentlichen projekte mit sinnvollem zeitaufwand fertig bekommen.
Das ist alles eine Frage der Übung und der Erfahrung. Wenn man sein Gebiet beherrscht, dann ist man in Assembler mindestens genauso schnell unterwegs, weil man sich mit der Zeit seine eigenen Codemodule zusammenstellt. Diese verwendet man dann genauso wieder, wie manche Leute DLLs nutzen. Der Unterschied besteht darin, daß man bei Assembler zu jedem Zeitpunkt die Kontrolle über seinen Code behält. Wer darauf verzichtet, wird immer zurückgeworfen durch Fehler, die andere Leute gemacht haben, und durch unnützen Ballast, der für das Programm eigentlich nicht erforderlich wäre.

Aber vielleicht ist es wirklich keine gute Idee heute noch mit Assembler anzufangen... ...wenn ich heute nochmal bei Null anfangen müßte, würde ich wahrscheinlich so werden, wie viele der heutigen Jugendlichen: Antriebslos, demoralisiert, unmotiviert, desinteressiert, überfordert und aggressiv, weil die Zeiten, in denen man Spaß an Computer-Technik haben konnte, endgültig vorbei sind. Wenn ich ehrlich bin, würde ich eine Konsole zum Spielen haben und meine Zeit wieder ganz der Malerei widmen.

Mit vorgefertigten Puzzlestücken ist man erheblich produktiver als z.B. Buttons Pixel für Pixel selbst zu zeichnen.
Wenn man die Produktivität als oberste Priorität ansieht - sicherlich.

Aber hey! Früher hat man Gepäck noch selbst getragen und nicht mit einem Wagen hinter sich her gezogen. Damals ... vor der Erfindung des Rades.
Dein Vergleich hinkt. Es ist ja schön und gut, daß inzwischen jeder einen Trolley hat, um sein Gepäck zu transportieren. Aber was nutzt dir das, wenn das Ziel deiner Reise auf der anderen Seite einer großen Pfütze ist? Dann kannst du entweder wie alle anderen minutenlang außen drumrum latschen... oder du erinnerst dich noch daran, das man Gepäck zur Not auch tragen kann und hast noch die erforderlichen Muckis dazu. Damit wärst du dann deutlich schneller am Ziel. Es ist schön wenn man einen Trolley hat. Aber es ist unschön, wenn das dann auch schon alles ist.

Dummerweise bekommen die Puzzlespieler den nächsten Auftrag und nicht die Button-Zeichner.
Wenn man darauf angewiesen ist, den nächsten Auftrag anzunehmen. Es gibt Leute, die setzen sich eigene Ziele und verwirklichen eigene Projekte. ;)

Extrem systemnahe Programmierung heute auf x86 halte ich für reichlich sinnlos.
Manchmal geht es nicht nur um Geschwindigkeit. In vielen Fällen geht es schlicht um die Machbarkeit. Ein Beispiel aus der jüngeren Vergangenheit: Beantworte dir die Frage, ob ein C++ Programmierer, der nur einen 32-Bit-C-Compiler und ein 32-Bit-OS zur Verfügung hat, die vollen Funktionen einer 64-Bit-CPU nutzen kann. Dann ersetzt du im nächsten Schritt den C++ Programmierer durch einen Assembler-Programmierer und stellst die gleiche Frage nochmal. :biggrin:

Das Argument, man bräuchte für maschinennahe Programmierung keine Mathematikkenntnisse, ist allerdings völlig aus der Luft gegriffen.
(..)
Wenn du dort mal irgendeine trigonometrische Funktion brauchst
(..)

Das ist ein falscher Umkehrschluß. Zum einen war von 'keine Mathematikkenntnisse' nirgends die Rede und zum anderen: Selbstverständlich braucht man mathematische Kenntnisse, wenn man ein Programm entwickeln möchte, welches ein mathematisches Problem lösen soll. Je schwerwiegender der mathematische Aspekt ist, umso mehr Kenntnisse benötigt man. Genauso braucht man chemische Kentnisse, wenn man ein Programm entwickeln möchte, welches ein chemisches Problem lösen soll. Und wenn man ein Programm entwickeln soll, welches eine fertige Steuererklärung ausspuckt, dann braucht man steuerrechtliche Kenntnisse und keine 'Eins' in Mathematik. :biggrin:

Wieviel mathematische Kenntnisse braucht es, um ein Programm in Assembler zu schreiben, welches einen beliebigen Computer gezielt zum Absturz bringt? Oder ein Programm, welches eine gesperrte Funktion in einer Software freigibt? Oder ein Programm, welches einen Datensatz manipuliert, um dem User einen Vorteil zu verschaffen? Oder ein Programm, welches eine private Mail ganz ohne RSA so verschlüsselt, daß sie von keinem Unbefugten anschließend noch entschlüsselt werden kann? Im letzten Bereich ist der Einsatz mathematischer Kenntnisse und Methoden sogar eher kontraproduktiv. Da ist Phantasie gefragt... und die findet man überall - aber nur selten bei Mathematikern.

http://upload.wikimedia.org/wikipedia/commons/c/cd/Guru.gif

[Marscel]

Aber vielleicht ist es wirklich keine gute Idee heute noch mit Assembler anzufangen... ...wenn ich heute nochmal bei Null anfangen müßte, würde ich wahrscheinlich so werden, wie viele der heutigen Jugendlichen:

Also rein aus didaktischen Gründen würde ich das nicht machen. Wenn man einem nicht-Nerd Programmierkenntnisse vermitteln möchte, sodass er auch brauchbar wird, würde ich eher so vorgehen:

Als erstes: Ruby/Python/Javascript, schwache Typen, viele Methoden, brauchbare Syntax. Einfach, um ein Gefühl für Programmierung zu vermitteln, wie man prozedurale und objektorientierte Stile nutzen kann.

Maybe Haskell? kA, wie relevant das Zeug wird. Aber aus persönlicher Erfahrung tut man sich umso schwerer mit funktionaler Programmierung, je länger man anders gearbeitet hat.

Dann: C. Konfrontation mit Zeigern, strengen Typen, Stack und Heap. Bei mir hat das nämlich ganz viele Fragen aufgeworfen: WTF Zeiger? Geht doch auch ohne, siehe PHP ;D - warum Heap, warum Stack?

Woraufhin: Assembler/Reverse Engineering. Da stellen sich dann die ganzen Aha-Effekte ein und man erkennt, warum C so ist wie es ist und wozu der Zirkus. Damit kommt man auch dem Thema Compiler ein ganzes Stück näher.

Und dann: Hm, C++ ist ja immer noch eine komplexe, marktrelevante Sache. Und sonst kann man sich immer noch Richtung C# oder Java verdrücken. ;)

[Mosher]

:ulol:
Das sind gleich dutzende konkrete Anwendungen von mathematischen Sachverhalten. Teilweise auch etwas fortgeschrittener, da man ja ordentlich Trigonometrie braucht.
Dann davon zu sprechen, daß man mit Mathematik sicher erstmal nicht großartig in Berührung kommt, ist geradezu zynisch.
-huha

Na klar kommen da ein paar mathematische Zusammenhänge vor. Der Aufwand, diese zu erlernen hält sich bei meinem vorgeschlagenen Projekt allerdings sehr in Grenzen.

-Fläche eines Quadrats ausrechnen
-Fläche eines rechtwinkligen Dreiecks ausrechnen
-Eckpunkte des Dreiecks abhängig vom angegeben Winkel ausrechnen

Das war´s denke ich.

Ich betrachtete meinen Vorschlag eher als pädagogioschen Vorschlag:

-Der Threadstarter möchte gerne Programmieren lernen, fürchtet sich aber vor komplizierter Mathematik und unverständlichen Code

--> Zeig ihm ein Projekt, bei dem man mit - sagen wir mal - mittelschwerer Mathematik (Trigonometrie; zumindest anschaulich) ein klar strukturiertes Programm erstellt und als kleines Bonbon dafür am Ende sein eigenes hübsches Muster auf dem Bildschirm sieht. Kann man ausdrucken, als Wallpaper nehmen, Etc.

Schon klar, dass dies nicht gerade ein Einsteigerprojekt ist, aber es ist definitiv ein "Grundlagenprojekt"

Naja und mit dem Zeitaufwand hast du sicherlich recht. Eine Woche ist zu eng angesetzt (für den vollen Funktionsumfang), geben wir uns da keinen Illusionen hin.

[Monger]

Eine kurze Frage: Taugt das kostenlose C# 2010 Buch von Galileo Computing was für Anfänger?

Das ist eigentlich ein reines Referenzhandbuch. Da schlägt man nach wenn man etwas spezielles sucht, aber man ackert es nicht von vorne bis hinten durch.
Du lernst ja auch kein Französisch indem du ein Grammatikbuch durchliest. Das ist zur Ergänzung gedacht, aber nicht als Leitfaden.

Ich hatte mal ein C# Buch aus der Kopf bis Fuß (http://www.amazon.de/C-von-Kopf-bis-Fu%C3%9F/dp/3897218526/ref=sr_1_25?ie=UTF8&qid=1303029405&sr=8-25) Reihe. Richtet sich eher an Anfänger, Informationsdichte ist nicht allzu hoch... aber die Mischung aus Übungen, Denkaufgaben und Theorie hat mir ganz gut gefallen. Danach kann man zwar immer noch nicht programmieren, aber man hat so n bissl mehr Überblick, und kann sich dann themenspezifischere Bücher holen.

[Matrix316]

http://mitpress.mit.edu/sicp/

^^ Pflichtlektüre. Zudem eine Sprache wie Scheme/Racket gerade für Anfänger um Längen besser geeignet ist, als sowas wie Java. public static void main(String[] args)? WTF? Da ist man als Anfänger doch gleich erstmal total überfordert. Was man da für ein popeliges Hello World nicht bereits schon alles wissen und möglicherweise auch schon verstehen sollte... das geht ja auf keine Kuhhaut.
Arbeite SICP durch, da kann man sich auf das wesentliche konzentrieren, völlig befreit von all der Syntaxgrüze, tausend und zwei Bibliotheken und weiss der Geier was noch alles...

So ganz abstrakt anzufangen finde ich sogar schwerer, als direkt mit einer Sprache anzufangen. Klar, muss man dann einige Begriffe lernen. Zum Beispiel was heißt public? Private? Protected? Static? Was ist String[]? Was ist void? Aber dafür braucht man keine Mathematik, sondern das gehört einfach zu einer Programmiersprache dazu, die nicht Assembler oder so heißt. ;) Und das wird in den meisten Einsteigerprogrammierbüchern auch alles beschrieben.

Was noch hilfreich ist, neben einem Einsteigerbuch, ist eine Sprachreferenz.

[Exxtreme]

So ganz abstrakt anzufangen finde ich sogar schwerer, als direkt mit einer Sprache anzufangen. Klar, muss man dann einige Begriffe lernen. Zum Beispiel was heißt public? Private? Protected? Static? Was ist String[]? Was ist void? Aber dafür braucht man keine Mathematik, sondern das gehört einfach zu einer Programmiersprache dazu, die nicht Assembler oder so heißt. ;) Und das wird in den meisten Einsteigerprogrammierbüchern auch alles beschrieben.

Was noch hilfreich ist, neben einem Einsteigerbuch, ist eine Sprachreferenz.
http://javabuch.de/

Da ist auch die Sprachreferenz inkl. Konzepte von OO drinne.

[Tiamat]

Java ist eine Insel ist imho ein besseres Buch als dieses C# Openbook.
Mehr und bessere Erläuterungen und auch mehr Beispiele.

Java ist auch eine Insel (http://openbook.galileocomputing.de/javainsel/)

Generell gibt´s für Java gute Openbooks, da muss man sich echt kein Buch kaufen für den Einstieg.

[HüterDerToten]

Im letzten Bereich ist der Einsatz mathematischer Kenntnisse und Methoden sogar eher kontraproduktiv. Da ist Phantasie gefragt... und die findet man überall - aber nur selten bei Mathematikern.


Das würde ich so nicht stehen lassen. Ich finde Programmcode auch wesentlich lesbarer als Formeln und begreife viele Dinge erst, wenn ich sie ausprogrammiert sehe, das ändert aber nichts daran, dass man für beides logisches Denkvermögen braucht. Ein bisschen Mengenlehre und Logik schadet mit Sicherheit nicht, danach kommt man mit einfachster Arithmetik aber meistens aus, das stimmt sicher.

Und zur Fantasie: Hilbert hat mal geantwortet, als Studenten ihm sagten, dass ein anderer Student abgebrochen habe, um Schriftsteller zu werden: "Das ist gut so, denn zur Mathematik fehlte ihm die Fantasie." Hat er Recht mit. Mathematik ist vielleicht trocken, aber erfordert viel, viel Vorstellungsvermögen.

Hier, das würde ich zum Einstieg empfehlen, weil ich gerne Ergebnisse meiner Programmierarbeit sehe:

http://inventwithpython.com/

Python empfiehlt sich eh, finde ich, weil man einen Einblick in nahezu jedes Programmierparadigma hat. Ansonsten tendiere ich auch zu Java, automatische Garbage Collection hat was für sich.

[airbag]

Ich weiß nicht, ob man sich als Normalsterblicher ein Uni-Buch antun will, das auch noch mit Scheme arbeitet. Ich denke, daß gerade als Person, die kein Informatikstudium unternimmt, solche Bücher zuviele Grundlagen und zu wenig konkret in Projekte umsetzbare Informationen enthalten. Außerdem fehlt dann auch noch die begleitende Vorlesung dazu, was es nochmal schwieriger macht. Im Prinzip eine gute Idee, solange man genug Willen hat, sich wirklich durchzukämpfen und alles zu verstehen. Wenn einem die Sprache nicht liegt, dann kann das extrem anstrengend werden, daher würde ich es eher nicht empfehlen, solange nicht bekannt ist, wie es diesbezüglich aussieht.

-huha


Es gibt noch ein anderes zu Scheme/Racket, dass eher für Anfänger gedacht ist. Jedoch sind beide furchtbar zu lesen.

[Gauron Kampeck]

Manchmal geht es nicht nur um Geschwindigkeit. In vielen Fällen geht es schlicht um die Machbarkeit. Ein Beispiel aus der jüngeren Vergangenheit: Beantworte dir die Frage, ob ein C++ Programmierer, der nur einen 32-Bit-C-Compiler und ein 32-Bit-OS zur Verfügung hat, die vollen Funktionen einer 64-Bit-CPU nutzen kann. Dann ersetzt du im nächsten Schritt den C++ Programmierer durch einen Assembler-Programmierer und stellst die gleiche Frage nochmal. :biggrin:
Dann stelle ich halt bei dem 32-Bit-Compiler ein 64-Bit target ein und nehme ein 64-Bit-OS. Die notwendige Funktion am Betriebssystem vorbei wurschteln zu wollen, zeugt nicht von großen Assember-Fähigkeiten, sondern von der Unfähigkeit, die richtigen Werkzeuge zu suchen und die nötigen technologischen Randbedingungen zu formulieren. Das ist so, als wolle jemand mit einem Löffel ein Haus bauen - nämlich komplett verrückt.

[Gast]

Was macht der Assemblertyp eigentlich wenn das Programm dann ach von 32bit Ossen ausgeführt werden sollte ? Da bringen einem die 64bit Register nix..
Oder wenn man auf ne andere Arch portieren muss?
Oder wenn man ne Datenbank braucht?
Oder wenn ein OS ganz andere Sys-calls hat?
Oder wenn sich Instruktionen mit dem Arch-Update geändert haben.(Passiert bei ARM häufig). UND DAAAANNN ?

[Tesseract]

Das ist alles eine Frage der Übung und der Erfahrung. Wenn man sein Gebiet beherrscht, dann ist man in Assembler mindestens genauso schnell unterwegs, weil man sich mit der Zeit seine eigenen Codemodule zusammenstellt. Diese verwendet man dann genauso wieder, wie manche Leute DLLs nutzen. Der Unterschied besteht darin, daß man bei Assembler zu jedem Zeitpunkt die Kontrolle über seinen Code behält. Wer darauf verzichtet, wird immer zurückgeworfen durch Fehler, die andere Leute gemacht haben, und durch unnützen Ballast, der für das Programm eigentlich nicht erforderlich wäre.

nein, das ist keine frage der übung und erfahrung. das ist eine frage der abstraktion, modularität und machbarkeit. du kannst komplexere projekte an denen mehrere leute arbeiten nicht mit der "ich schreibe alles selbst und hab die kontrolle"-hobbymentalität durchziehen, erst recht nicht wenn das ganze halbwegs plattformunabhängig/portierbar sein soll.

[Demirug]

Das nennt sich „not invented here syndrom“. Darunter leiden oft die gute Softwareentwickler und noch viel mehr diejenigen die sich für Gottes Geschenk an die Informatik halten. Personen mit diesem Problem gehen grundsätzlich davon aus das nur sie in der Lage sind ein Problem auf die korrekte Art zu lösen. Alle bereits vorhandenen Lösungen dafür halten sie für fehlerhaft und ungenügend. Lässt man solche Leute einfach machen kann man sicher sein das jedes Projekt den Zeitrahmen sprengt wenn es denn überhaupt fertig wird.

[PatkIllA]

Das man da bis zum Assembler runtergeht dürfte dann wohl die Ausnahme sein.

Ich finde in der Praxis ist es viel wichtiger den Baukasten zu kennen und zu verstehen und die Kreativität zu haben die Teile zu einem neuem Bild zusammenzusetzen, um mal die Puzzle-Analogie aufzugreifen.

[Exxtreme]

Dein Vergleich hinkt. Es ist ja schön und gut, daß inzwischen jeder einen Trolley hat, um sein Gepäck zu transportieren. Aber was nutzt dir das, wenn das Ziel deiner Reise auf der anderen Seite einer großen Pfütze ist? Dann kannst du entweder wie alle anderen minutenlang außen drumrum latschen... oder du erinnerst dich noch daran, das man Gepäck zur Not auch tragen kann und hast noch die erforderlichen Muckis dazu. Damit wärst du dann deutlich schneller am Ziel. Es ist schön wenn man einen Trolley hat. Aber es ist unschön, wenn das dann auch schon alles ist.

Nö, ich nehme mir ein anderes Puzzle-Teil namens Brücke, stelle es über die Pfütze auf und fahre drüber. Und dann bin ich noch viel schneller als jemand, der das Zeug trägt.
Manchmal geht es nicht nur um Geschwindigkeit. In vielen Fällen geht es schlicht um die Machbarkeit. Ein Beispiel aus der jüngeren Vergangenheit: Beantworte dir die Frage, ob ein C++ Programmierer, der nur einen 32-Bit-C-Compiler und ein 32-Bit-OS zur Verfügung hat, die vollen Funktionen einer 64-Bit-CPU nutzen kann. Dann ersetzt du im nächsten Schritt den C++ Programmierer durch einen Assembler-Programmierer und stellst die gleiche Frage nochmal. :biggrin:

Hier stellt sich wiederum die Frage warum man ein Programm ausserhalb von Spezifikationen betreiben wollte? Produktiv kann man sowas auch nicht einsetzen da der Zustand des Programms niemals definiert wäre.

[petersenk]

Ach, meine Herren. Ook! ist doch offensichtlich nur (noch) am rumtrollen.
Lasst ma gut sein (bzw. auch weiterhin noch viel Vergnügen, ;D).

[Ook!]

Woraufhin: Assembler/Reverse Engineering. Da stellen sich dann die ganzen Aha-Effekte ein und man erkennt, warum C so ist wie es ist und wozu der Zirkus. Damit kommt man auch dem Thema Compiler ein ganzes Stück näher.
Das ist einer der Gründe, warum ich direkt mit Assembler anfangen würde. Ein Aha-Effekt ist nur die Folge eines Sachverhalts, den man zwar kannte, aber bis dato nicht begriffen hat.
Man muß ja kein Experte im Entwickeln von Maschinencode werden. Es genügt, wenn man die Arbeitsweise der Maschine begriffen hat und zur Not auch mal 'manuell' steuern kann. Bei Sprachen wie Java und C++ spielen Dinge wie vorhandene Hardware und verwendetes OS zunehmend keine Rolle mehr. Das ganze wird dann positiv als 'gute Portierbarkeit' bezeichnet. Meine Gegenthese dazu lautet: Code der auf unterschiedlichen Systemen beliebig portierbar ist, kann nur schlecht sein, weil er zwangsläufig die vorhandene Hardware in keinster Weise berücksichtigt/ausreizt.

Und zur Fantasie: Hilbert hat mal geantwortet, als Studenten ihm sagten, dass ein anderer Student abgebrochen habe, um Schriftsteller zu werden: "Das ist gut so, denn zur Mathematik fehlte ihm die Fantasie." Hat er Recht mit. Mathematik ist vielleicht trocken, aber erfordert viel, viel Vorstellungsvermögen.
Da erkennt man den typischen Mathematiker. Herr Hilbert hat eine möglicherweise wahre (aber zugleich völlig unbrauchbare) Antwort auf ein Problem entdeckt - und damit endet sein Interesse an der Sache. Daß es durchaus mehrere wahre/vertretbare Antworten auf eine Frage geben kann, dazu fehlt es ihm eben an jener Phantasie, von der er mehr zu besitzen glaubt, als tatsächlich der Fall zu sein scheint.
Ich glaube übrigens nicht, daß dieses Zitat von David Hilbert stammt. Das ist in meinen Augen einfach nur ein Running-Gag für Mathe-Erstsemester. Dort versuchen sich diejenigen, die es mal wieder besonders nötig haben, sich gegenüber anderen Wissenschaften abzugrenzen und in den Vordergrund zu spielen. Jeder möchte sein Fachgebiet schließlich gerne als die Perle unter den Wissenschaften verstanden wissen.

Die notwendige Funktion am Betriebssystem vorbei wurschteln zu wollen, zeugt nicht von großen Assember-Fähigkeiten, sondern von der Unfähigkeit, die richtigen Werkzeuge zu suchen und die nötigen technologischen Randbedingungen zu formulieren.
Ein Gewurschtel wird es nur, wenn man einen Puzzlespieler mit solch einer Aufgabe konfrontiert. Gute Assembler-Programmierer wissen oft sehr genau, was sie tun und wo sie hin wollen. Was die zum Programmieren 'richtigen' Werkzeuge sind, hängt dabei doch eher vom Fähigkeitsgrad des Programmierers ab. Es gibt Leute, denen muss man erst für $ 499,- eine Visual C++ Professional Lizenz kaufen... und man erhält 'schon' nach Stunden auf die Frage: 'IRQ 8?', ein Programm, welches einem über X Umwege durch den Aufruf einer Funktion im Rahmen einer Klasse aus einer Standardbibliothek die Uhrzeit verrät. Ein 'echter' Assembler-Programmierer schaut einfach auf seine Uhr und sagt: Es ist jetzt 00:36. ;)

du kannst komplexere projekte an denen mehrere leute arbeiten nicht mit der "ich schreibe alles selbst und hab die kontrolle"-hobbymentalität durchziehen, erst recht nicht wenn das ganze halbwegs plattformunabhängig/portierbar sein soll.
So ist es. Aber macht Aufgabenteilung wirklich Sinn, wenn man gut programmieren möchte? :freak: In meinen Augen macht Aufgabenteilung nur dann Sinn, wenn man Produktivität als oberste Priorität hat. Je schneller die Sache fertig wird, umso besser. Wozu einen DaVinci wochenlang an seiner Mona Lisa rumpinseln lassen, wenn nur ein Bild für die leere Wand benötigt wird? Wir heuern einfach ein Team von Patchwork-Experten an! - Nach stundenlangen Telefonkonferenzen malt dann jeder in wenigen Minuten ein einfarbiges 5x5 cm Stückchen... und anschließend kleben wir es zusammen. Voila! - Und wieder ein Meisterwerk in Vollendung, welches die Jahrtausende überdauern wird!

So würde die Mona Lisa heute möglicherweise aussehen, wenn sie von hochbezahlten Programmierern im einem herausragend gemanagten Team in Rekordzeit produziert worden wäre:

http://www.megamonalisa.com/artworks/megamonalisa_patchwork-art.jpg

Ein einzelner, unbezahlter Nerd hätte für so ein Projekt in Öl sicher Monate gebraucht:

http://www.megamonalisa.com/artworks/megamonalisa_nerdy-monda-lisa.jpg

Ich denke, man erkennt den Unterschied zwischen C++ und Assembler auf diesen Bildern auch ohne Brille. ;)

Ich will damit nicht sagen, daß Java/C++ generell schlechter ist als Assembler. Aber mit Assembler hat man -auch heute noch- ganz andere Möglichkeiten. Sicher gibt es auch Nachteile (wie von dir genannt). Aber die Vorteile überwiegen unter dem Strich imho deutlich.

[PHuV]

Das ist einer der Gründe, warum ich direkt mit Assembler anfangen würde. Ein Aha-Effekt ist nur die Folge eines Sachverhalts, den man zwar kannte, aber bis dato nicht begriffen hat.
Man muß ja kein Experte im Entwickeln von Maschinencode werden. Es genügt, wenn man die Arbeitsweise der Maschine begriffen hat und zur Not auch mal 'manuell' steuern kann. Bei Sprachen wie Java und C++ spielen Dinge wie vorhandene Hardware und verwendetes OS zunehmend keine Rolle mehr. Das ganze wird dann positiv als 'gute Portierbarkeit' bezeichnet. Meine Gegenthese dazu lautet: Code der auf unterschiedlichen Systemen beliebig portierbar ist, kann nur schlecht sein, weil er zwangsläufig die vorhandene Hardware in keinster Weise berücksichtigt/ausreizt.


So ein Quatsch! :rolleyes: Assembler war vielleicht früher mal ein wichtiges Kriterium, heute ist es nur noch ein Mittel für verkappte Nerd-Masochisten. Was willst Du den groß heute noch an der Hardware besonders ausnutzen? Dafür sind die Schnittstellen und APIs da, die sich um die korrekte und effiziente Umsetzung von Hochsprache für den jeweiligen Prozessor kümmern. Du hast in der Industrie und kommerziellen DV andere Ansprüche: Daten effizient und schnell zu verarbeiten. Zudem vergißt Du den Punkt, daß viele Prozessoren heute selbst dazu noch von Hause aus optimieren. Das der Code deshalb schlecht sein muß, ist genau so viel Unsinn. Gut geschriebene Software funktioniert universell, weil die meisten Prozessoren heute eh nach ähnlichen oder gleichen Prinzipien arbeiten. Gut, künftig wird Parallelisierung ein großes Thema werden - oder ist es bereits schon.

Portierbarkeit ist das wichtigste Feature heute überhaupt. Mag ja sein, daß die jeweiligen Prozessoren dann nicht zu 100% ausgereizt werden, aber das spielt nur marignal eine Rolle. Wichtig ist, daß Software zur Verfügung steht. Wenn Du alles nur mit Assembler machen würdest, würdest Du die Wartungskosten und Weiterentwicklung enorm in die Höhe treiben, das wäre kommerziell gar nicht machbar. Überleg mal eine Firefox oder Oracle DB oder MySQL in Assembler, das eine wäre der Todesstoß für Freeware bzw. OpenSource, das andere würde unbezahlbar für die kommerzielle SW-Entwickung. Für eine kleinere SW-Firma ist es schon einen Unterschied, ob man nur 1-2 Plattformen, oder 5-6 Plattformen oder mehr unterstützen kann. Ob Java ein Segen ist, ist diskussionswürdig, aber Portierbarkeit ist es definitiv. Überleg mal, wenn man für jede GK immer neu speziell in Assembler programmieren müßte, da könnten wir die ältere Spiele gar nicht mehr verwenden, genau so wenig wie Software.

[Tesseract]

Aber macht Aufgabenteilung wirklich Sinn, wenn man gut programmieren möchte?
die frage stellt sich überhaupt nicht weil es bei vielen projekten einfach eine notwendigkeit ist. da kannst du dich entscheiden ob du es in teamarbeit oder überhaupt nicht machst.
außerdem ist der performanceunterschied zwischen maschinencode und dem, was ein guter hochsprachencompiler erzeugt, nicht besonders groß, der unterschied in der portierbarkeit, wartbarkeit und wiederverwendbarkeit ist hingegen enorm.
und dein unsinniger vergleich mit der mona lisa hinkt nicht, der ist querschnittsgelähmt.

[Matrix316]

Also das erste Bild erinnert mich mehr an Assembler als das zweite. Hehe. :D

Ganz einfach, weil Assembler IMO eine ziemlich grobmotorische Sprache ist. Move dings. Mach das. Dann das. Spiele aus der Assemblerzeit, sehen ja auch noch nicht so ausgefeilt aus wie aktuelle Top Titel. Arbeitsteilung hin oder her. Das heißt ja auch nicht, dass die Grafik von einer Figur von 10 Leuten gleichzeitig gemacht wird, sondern einer macht die Grafik, der andere die Kollisionsabfrage, der nächste das etc..

[pest]

Assembler war vielleicht früher mal ein wichtiges Kriterium, heute ist es nur noch ein Mittel für verkappte Nerd-Masochisten. Was willst Du den groß heute noch an der Hardware besonders ausnutzen?

auto-vectorize wirds schon richten :rolleyes:

assembler ist für bestimmte aufgaben einfach unentbehrlich


Ganz einfach, weil Assembler IMO eine ziemlich grobmotorische Sprache ist. Move dings. Mach das. Dann das.

assembler ist keine sprache per se.
es ist eine direkte abbildung von maschinenbefehlen auf (von menschen) lesbare befehle.



Spiele aus der Assemblerzeit, sehen ja auch noch nicht so ausgefeilt aus wie aktuelle Top Titel.


was ist das denn für ein bescheidenes argument? :rolleyes:, und vor allem, was hat das mit assembler zu tun?

[Gast]

die frage stellt sich überhaupt nicht weil es bei vielen projekten einfach eine notwendigkeit ist. da kannst du dich entscheiden ob du es in teamarbeit oder überhaupt nicht machst.

Jetzt bleibt doch mal am Boden. Dieses ganze Zeug von wegen Teamarbeit, Wartbarkeit, Wiederverwendbarkeit usw. liegt doch von der Größenordnung her 2 Stufen über dem was für den TS interessant ist. Er möchte Programmieren lernen, und nicht bei Microsoft in die Entwicklung von Windows 8 einsteigen. Ja, dort sind diese Dinge wichtig. Nein, wenn es darum geht erstmal die Grundlagen zu verstehen sind sie nebensächlich. Von daher finde ich den Vorschlag mit Assembler gar nicht so daneben. Wenn man bei 0 anfängt ist Assembler tatsächlich nicht schwerer als Ruby, mit dem Vorteil dass man wesentlich mehr Verständnis mitbekommt.
Zu den Nachteilen von wegen Teamarbeit, Skalierung in größeren Projekten etc. - s. oben. Ist für den TS erstmal nicht/wenig relevant.

außerdem ist der performanceunterschied zwischen maschinencode und dem, was ein guter hochsprachencompiler erzeugt, nicht besonders groß, der unterschied in der portierbarkeit, wartbarkeit und wiederverwendbarkeit ist hingegen enorm.

Richtig.
Der Unterschied zwischen Machinencode und einer Hochsprache was das Verständnis für die grundlegenden Abläufe in einem Computer betrifft ist ebenfalls enorm. Und nu?

Spiele aus der Assemblerzeit, sehen ja auch noch nicht so ausgefeilt aus wie aktuelle Top Titel.

???
Erinner dich mal zarück als die Pixel/Vertexshader aufkamen. Was glaubst du wohl wie hat man die damals programmiert? Richtig, mit Assembler. Die "topaktuellen Titel" mit der besten Grafik waren die, bei denen die Shader in Assembler programmiert waren. Einfach weil es die einzige Möglichkeit war. Am Anfang gab es eben noch keine Hochsprachen zur Shaderprogrammierung.

[Matrix316]

[...]
Richtig.
Der Unterschied zwischen Machinencode und einer Hochsprache was das Verständnis für die grundlegenden Abläufe in einem Computer betrifft ist ebenfalls enorm. Und nu?

???
Erinner dich mal zarück als die Pixel/Vertexshader aufkamen. Was glaubst du wohl wie hat man die damals programmiert? Richtig, mit Assembler. Die "topaktuellen Titel" mit der besten Grafik waren die, bei denen die Shader in Assembler programmiert waren. Einfach weil es die einzige Möglichkeit war. Am Anfang gab es eben noch keine Hochsprachen zur Shaderprogrammierung.

1. Ist die Frage, ob man, um ein wenig zu Programmieren, wissen muss, was in den Registern etc. alles so intern abläuft?

2. Kann sein, aber wenn ich an Assembler und Spiele denke, dann eher an Amiga Titel oder so. ;)

Ich finde, wenn man Assembler lernt, ist das zwar nett, aber wenn man mit C++ oder Java oder C# weiter machen will, muss man komplett von vorne anfangen. Umgekehrt, wenn man C, C#, C++ oder Java lernt, kann man relativ einfach sich in alle anderen Hochsprachen einarbeiten.

[Marscel]

Ich finde, es macht durchaus Sinn, geringfügig etwas von der Hardwarefunktionsweise zu verstehen - auch wenn man sich nur in Java und .NET bewegt:

Man sollte z.B. wissen, warum man Rekursion vermeiden sollte - ich weiß aber nicht, was die gängigen VMs daraus machen. Aber wenn jemand, der als Programmierer arbeitet und sagt Rekursion ist die Lösung aller Dinge - dann soll der mal in C bei wenig Speicher und großen Datenmengen mit Quick- oder Merge-Sort sortieren.

Oder: warum gibt es Dinge wie Arrays, indizierte und verkettete Listen, Stacks als Container - und was sind deren Fähigkeiten und warum.

Dass man als PHP-Scripter damit nicht so viel zu tun haben wird, ist mir klar. Aber eigentlich sollte man als Programmierer so viel Flexibilität haben, dass man im Falle von C nicht gleich den Computer ermordet, weil man von der Hardware nun gar keine Ahnung hat.

[Monger]

Man sollte z.B. wissen, warum man Rekursion vermeiden sollte - ich weiß aber nicht, was die gängigen VMs daraus machen.

Eben. Das ist Quatsch. Wo welche Stacktiefe Probleme verursacht, ist hochgradig abhängig von Betriebssystem, Runtime, Compiler und natürlich Hardware. Nur weil in C eine Stacktiefe von X Probleme bereitet, bedeutet das noch lange nicht dass das in Java/whatever auch Probleme macht.


Das ist auch das zentrale Problem was ich mit der Empfehlung von Assembler habe: Assembler ist eben KEINE Untermenge von C, und C KEINE Untermenge von C# oder Java.
Was man für C gelernt hat, ist teilweise nicht nur irrelevant für höhere Sprachen, sondern sogar irreführend.

Für C Programmierer ist ein String z.B. üblicherweise ein Zeiger auf ein Char Array. Und natürlich nehmen sie an, dass ein Char ein Byte groß ist. Deshalb lässt sich die Länge eines Strings dadurch bestimmen, dass man von x bis zur Ende Kennung durch den Speicher läuft, und durch die Anzahl der Byte teilt.
Dass das in einer Hochsprache nicht nur nicht so ähnlich, sondern überhaupt nicht so implementiert ist, wird dabei gerne übersehen. Jede einzelne Grundannahme hier ist falsch.

Natürlich gibt es z.B. bestimmte Patterns und Algorithmen, die sich überall wiederfinden. Aber da der Kontext sich ändert, muss man die auch jedesmal neu betrachten. Wenn man nicht nur die Sprache, sondern gleich die Sprachfamilie wechselt (prozedural <-> OOP), sollte man NICHTS als gegeben annehmen.

[Marscel]

Dass das in einer Hochsprache nicht nur nicht so ähnlich, sondern überhaupt nicht so implementiert ist, wird dabei gerne übersehen.

Ich persönlich neige immer zu Paranoia, wenn ich lange mit C/C++ gearbeitet habe und dann plötzlich wieder bei C# bin und nicht weiß, was ich da eigentlich genau bewege. :D

Klar, jede Annahme was die Implementierung angeht, ist gefährlich. Ich wollte das Thema auch unter C-Fähigkeit sehen, die mir als Programmierer bisher immer über den Weg gelaufen ist, auch wenn ich sonst hauptsächlich mit 4GL-Kram/.NET/Java oder Webzeug zu tun hatte. Wofür dann Assembler- Rechnerarchitekturkenntnisse hilfreich sind.

[airbag]

So ein Quatsch! :rolleyes: Assembler war vielleicht früher mal ein wichtiges Kriterium, heute ist es nur noch ein Mittel für verkappte Nerd-Masochisten. .


Naja es gibt ja durchaus Leute, die meinen, dass man ohne mal hardwarenah programmiert zu haben nicht effezient programmieren kann.

Was für Masochisten wäre z.B. Brainfuck.:freak:

[Gauron Kampeck]

Ein Gewurschtel wird es nur, wenn man einen Puzzlespieler mit solch einer Aufgabe konfrontiert. Gute Assembler-Programmierer wissen oft sehr genau, was sie tun und wo sie hin wollen. Was die zum Programmieren 'richtigen' Werkzeuge sind, hängt dabei doch eher vom Fähigkeitsgrad des Programmierers ab.
Na dann los: Wie umgehe ich "elegant" meine elementarsten OS-Funktionen (Speichervirtualisierung, HAL, usw.) und greife mal ebenso auf das x64-Instruction-Set zu? Wie stellst du sicher, dass du weißt, was der Scheduler in der Zwischenzeit mit deinen Registern macht? Und dann portiere, dieses "elegante" gewurschtel bitte auf einen ARM9.

[Gauron Kampeck]

Naja es gibt ja durchaus Leute, die meinen, dass man ohne mal hardwarenah programmiert zu haben nicht effezient programmieren kann.
Derjenige, der effizient programmiert, programmiert schnell, angemessen, test- und wartbar. Nichts davon gilt für Assember.

[PHuV]

auto-vectorize wirds schon richten :rolleyes:

assembler ist für bestimmte aufgaben einfach unentbehrlich

Richtig, das bestreitet keiner, aber es ist nicht für den überwiegenden Teil der SW-Entwicklung erforderlich.

[airbag]

Derjenige, der effizient programmiert, programmiert schnell, angemessen, test- und wartbar. Nichts davon gilt für Assember.


Es war eher auf den Algorithmus bezogen den man schreibt.
Sprich keine Brutforcesachen mit exponentiellen Komplexität in allen Belangen.

edit:
Obwohl das auch in Hochsprachen mit der Zeit kommt.

[Gauron Kampeck]

Es war eher auf den Algorithmus bezogen den man schreibt.
Sprich keine Brutforcesachen mit exponentiellen Komplexität in allen Belangen.

edit:
Obwohl das auch in Hochsprachen mit der Zeit kommt.
Die Komplexitätsklasse ist aber nicht von der Hardwareabstraktion einer Sprache abhängig.

[Ook!]

Was für Masochisten wäre z.B. Brainfuck.:freak:

Ich bevorzuge Ook!

http://de.wikipedia.org/wiki/Ook!

;)

[Ook!]

Nachtrag:

Irgendjemand sollte sich mal darum kümmern, warum die automatische Umwandlung einer URL in diesem Forum versagt, wenn sie mit einem Ausrufezeichen endet.

http://de.wikipedia.org/wiki/Ook!

Alles muß man hier selber machen.

[airbag]

Die Komplexitätsklasse ist aber nicht von der Hardwareabstraktion einer Sprache abhängig.


Es ging auch eher um die Arbeitsweise die man dabei lernt. (wie gesagt es ist nicht meine Meinung, sondern die von einigen meiner Kommlitonen )
Aber letztendlich lernt man sowas auch wenn man sich mit verschiedenen Konzepten auseinandersetzt.

[Gast]

Man sollte z.B. wissen, warum man Rekursion vermeiden sollte - ich weiß aber nicht, was die gängigen VMs daraus machen.
Es wurde zwar schon zuvor erwähnt, aber dass sollte man nicht so stehen lassen.

Ja, Rekursion kann Probleme mit der Stacktiefe mit sich bringen, wenn man allerdings Endrekursion benutzt und die Sprache/VM diese unterstützt, ist das keinen deut schlechter als normale Iteration. Ansonsten hätten viele Funktionale Sprachen dicke Probleme.