# Ausbildung in prozeduraler Sprache = Nachteil ?



## sunny-boy (28. Dez 2010)

Hallo zusammen,

Ich hab gerade meine Ausbildung zum Anwendungsentwickler angefangen, programiere aber schon länger v.a. in Java. Der Betrieb selber und auch die Ausbildung sind sehr gut. Jedoch arbeite ich nur mit einer prozeduralen Sprache. Jetzt stell ich mir die Frage, ob ich dadurch später einen Nachteil haben könnte.

Mfg

sunny-boy


----------



## MQue (28. Dez 2010)

Würd ich nicht sagen, es ist wichtig, dass du dich mit den Algorithmen beschäftigst und überhaupt programmierst, ab einer gewissen Erfahrung ist's dir dann auch egal was für Paradigmen dahinterstehen, das hat man dann innerhalb weniger Stunden.
Also einfach drauf los programmieren und nebenbei einiges übers programmieren lesen. 
lg


----------



## Munro24 (29. Dez 2010)

Was hält dich davon ab, dich auch weiterhin mit Java zu beschäftigen? 

In meinem Studium beschäftigen wir uns (bisher) beispielsweise nur mit Java, obwohl es noch so vieles anderes gibt, das sinnvoll wäre: xml, html, css, php, sql ... Als fertiger Wirtschaftsinformatiker sollte man das meiner Ansicht nach schon können, wird aber bei mir in der Uni höchstens beiläufig irgendwann mal behandelt. Trotzdem kann ich ja weiterhin an Internetseiten basteln und meine Fertigkeiten verbessern. 

In der Uni werden eben andere Schwerpunkte gesetzt. Sich auch auf anderen Gebieten auszukennen schadet aber trotzdem nicht.


----------



## Gast2 (29. Dez 2010)

sunny-boy hat gesagt.:


> Jedoch arbeite ich nur mit einer prozeduralen Sprache.



Welche denn?


----------



## sunny-boy (30. Dez 2010)

fassy hat gesagt.:


> Welche denn?



COBOL



			
				Munro24 hat gesagt.:
			
		

> Was hält dich davon ab, dich auch weiterhin mit Java zu beschäftigen?



Natürlich beschäftige ich mich weiter mit Java und verfolge nebenbei auch meine eigene Projekte. Nur ist es ein unterschied, ob ich mich mit einer Sache privat beschäftige oder beruflich.

Mfg

sunny-boy


----------



## Noctarius (30. Dez 2010)

sunny-boy hat gesagt.:


> Nur ist es ein unterschied, ob ich mich mit einer Sache privat beschäftige oder beruflich.



Stimmt meistens sind die Themen für einen selbst interessanter und damit steigert man sich mehr rein


----------



## maki (30. Dez 2010)

> COBOL


Wenn dir das Spass macht und du kein Problem damit hättest die nächsten x Jahre damit zu arbeiten, dann los.
Ansonsten suche dir etwas anderes.

Ich behaupte mal: Nichts von dem was du in COBOL lernst wirst du in anderen Sprachen verwenden können, ausser vielleicht in NATURAL, PL/1 oder ABAP.
COBOL ist halt ein Dinosaurier und ziemlich veraltet, damit bist du auf deiner Insel, wenn du dort glücklich bist ok, ansonsten nix wie weg


----------



## Gast2 (30. Dez 2010)

Im Bankenumfeld wird noch viel COBOL programmiert und auch händeringend nach Nachwuchs und fähigen Entwicklern gesucht. Ist halt die Frage ob das was für ihn ist. Einfach die ausbildung wechseln wird ja nicht so einfach sein.

Ich denke mal wenn er sich weiterhin privat mit Java auseinandersetzt und bei einer Bewerbung eigene Projekte und Engagement zeigen kann ist das mehr als so mancher der in der ausbildung Java gelernt hat.


----------



## homer65 (30. Dez 2010)

maki hat gesagt.:


> Ich behaupte mal: Nichts von dem was du in COBOL lernst wirst du in anderen Sprachen verwenden können, ausser vielleicht in NATURAL, PL/1 oder ABAP.



Dem möchte ich wiedersprechen.
Grundsätzliche Programmlogik wie Verzweigungen, Schleifen, Pogrammcalls usw. findet sich in allen Sprachen wieder.


----------



## Herr K. (1. Jan 2011)

Hallo sunny-boy,

Du hast gerade Deine Ausbildung angefangen, ich glaube das könnte wichtig für die Frage sein. Tatsächlich gibt es bei verschiedenen Ausbildungen Leute, die schon seit xx Jahren C, C++, C# und Java hoch und runter beten können. Die erzählen gerne was sie alles können und wie leicht das ist, jede Aufgabe in einer solchen (oder sehr ähnlichen) Sprache wird als trivial belächelt. Das gilt keineswegs pauschal für alle, die schon Programmiererfahrungen haben, klassischerweise hat man aber in jedem Ausbildungsjahrgang (auch an Unis) mindestens eine solche Person. 
Das große Problem ist nun, dass man Chancengleichheit möchte. Auch jmd. der noch nie vor einem Rechner saß sollte die Möglichkeit haben Informatik zu studieren oder sich als Fachinformatiker ausbilden zu lassen. Das Wort Informatik setzt sich aus Information und Mathematik zusammen, beides hat nicht direkt etwas mit einem PC zu tun (auch wenn Computer = Berechner natürlich ein Hilfsmittel ist, aber auch nicht mehr). 

Als ich mein Studium damals begonnen hatte, wurde uns Haskell gelehrt, eine funktionale Sprache. Nicht weil damals (2001) funktionale Sprachen schon der neue Trend waren, sondern nur weil ca. 2 von 200 Leuten schon mal was von der Sprache gehört hatten. Der Grund war einfach, dass man wollte dass alle bei 0 anfangen um eben möglichst keinen zu haben der andere auslacht weil die vermeintlich einfache Dinge nicht verstehen. 

Das Du also jetzt mit COBOL anfängst heißt wahrscheinlich nicht, dass ihr nicht irgendwann zu anderen Sprachen übergeht. Das Wichtige ist aber nicht die Programmiersprache, die ist nur Syntax, die lernst Du schnell. Ein Wechsel von Java nach C# ist (oder vice versa) ist nicht wirklich eine große Herausforderung und innerhalb von wenigen Tagen würdest sehr sicher in der Sprache sein. 

Wie schon gesagt wurde, das eigentlich wichtige ist ein viel grundlegenderes Verständnis für Algorithmen und Datenstrukturen. Wenn alle Welt die Objekt Orientierung lobt, dann heißt das noch lange nicht, dass das pauschal gültig ist. Es gibt verschiedene Techniken und Sprachen und die haben jeweils eigene Vor- und Nachteile. 

Das Ziel einer (guten) Ausbildung ist nicht Dir die Sprache A oder B beizubringen (dazu kannst Du Dir auch einfach ein Buch kaufen oder das Tutorial durchgehen). Vielmehr sollte Dir das Wissen vermittelt werden, wie Du lernst die Vor- und Nachteile zu erkennen um zu entscheiden für welche Zwecke sich dieses oder jedes Werkzeug eignet und wie man es verwendet. 

Um zum Beispiel der Objekt Orientierung zurück zu kommen, ob diese gut oder schlecht ist hängt halt schon davon ab was Du machen möchtest. Kennst Du nichts anderes, kannst Du auch nicht sagen dass OOP besser oder schlechter ist, denn die Relation fehlt. 
Für Dich ist es also schon jetzt ein Vorteil, dass ihr eine imperative Sprache lernt, da lernst Du schon die ersten Unterschiede zur OOP kennen, was ggf. auch Dein Verständnis von und für Java verbessert und sich positiv auswirkt. 

Das andere was Du lernen solltest ist, dass bestimmte Elemente auch ganz unabhängig vom Programmierparadigma gelten (z.B. dass man alles gleich richtig machen sollte, strukturiert vorgeht, sprechende Namen wählt, für andere Kommentiert usw.).


----------



## André Uhres (1. Jan 2011)

Hallo sunny-boy,

als ich anfing zu programmieren gab es noch kein Java. Nach über zwanzig Jahren prozeduraler Programmierung mit Assembler, Cobol, Pl/1 und RPGII habe ich den Umstieg auf Java geschafft. COBOL und Java parallel zu behandeln, wie in deinem Fall, ist wohl nicht so schwierig und meiner Meinung nach ein reizvoller Kontrast, der positive Lernimpulse geben kann.

Gruß,
André


----------



## sunny-boy (1. Jan 2011)

Hallo zusammen und ein frohes neues Jahr,

vielen Dank euch allen für eure Antworten. Ich denke, dass es wohl wirklich so ist, dass die Sprache eine untergeordnete Rolle spielt. Ich werde mich auch  weiterhin mit Java beschäftigen und hoffe hier einen guten Ort zum lernen gefunden zu haben.

Mfg

sunny-boy


----------



## maki (1. Jan 2011)

homer65 hat gesagt.:


> Dem möchte ich wiedersprechen.
> Grundsätzliche Programmlogik wie Verzweigungen, Schleifen, Pogrammcalls usw. findet sich in allen Sprachen wieder.


Ich sag mal so: Die 60er Jahre haben gerade angerufen, die wollen ihre Technologie zurück.

Deiner Beschreibung nach wäre der M$-BASIC Dialekt aus den 80er Jahren auch eine Alternative, was natürlich stimmt, da gibt es auch IF Abfragen und Schleifen 

Schon klar das es damit auch geht, aber moderne Praktiken (DI, TDD, etc. pp.) bleiben da eben aussen vor, von OO ganz zu schweigen.

Das muss man mögen, oder besser lieben, sonst wird man nicht glücklich, IMHO.


----------



## SlaterB (1. Jan 2011)

maki hat gesagt.:


> moderne Praktiken (DI, TDD, etc. pp.) bleiben da eben aussen vor, von OO ganz zu schweigen.


ersteres würde man in einer normalen Java-Ausbildung aber auch kaum hören,
so richtig interessant wird das doch erst in umgesetzten Projekten

in meiner Java-Firma ist das z.B. eher mau,
in langjährigen COBOL-Projekten kann dagegen doch auch viel interessantes passieren oder siehts da generell öde aus?


----------



## maki (1. Jan 2011)

Nur dass ich nicht falsch rüberkomme, will niemandem irgendetwas aus- oder einreden, muss jeder selber entscheiden.

Hab selber beruflich mit NATURAL angefangen in einem Projekt das teilweise aus PL/1 migriert wurde, selber davor mit C++ programmiert (MFC), empfand mich als fehlplaziert.
Anstatt der OO, Konstruktoren & Destruktoren, Designpatterns gab es zB. nicht mal Rekursion und einige andere Sachen die man als normal empfindet, weder NATURAL noch COBOL sind flexible allrounder, sondern Sprachen mit einem genauen Einssatzgebiet.

Die größte Abwechslung war als ich eine DLL schreiben durfte die aus NATURAL aufgerufen wird um das Acrobat Reader ActiveX Control zu starten & steuern.

Kann mir nicht vorstellen das es etwas neues gibt in COBOL in den letzten 20 Jahren, kann mich aber irren.

Den Vorteil wenn man mit Java anfängt, selbst Java ohne die neusten Buzzwords?
Dann kann man wenigstens schon Java und alles was direkt dazu gehört, muss nicht nochmals von 0 anfangen, die Gefhr zu einem Fachidioten für einen Dinaosaurier zu werden ist geringer (vorrausgesetzt wenn man Java nicht schon als Dinosaurier sieht, aber das ist ein anderes Thema ).

Wenn sunny-boy jetzt seine Ausbildung anfängt mit dem Ziel die nächsten 30 Jahre COBOL zu machen und er sich dabei wohl fühlt ist doch alles ok, hört sich für mich nicht danach an als ob er nochmals zu etwas anderem kommt während seiner Ausbildung, da sollte man schon wissen ob man dabei bleiben will, sonst lässt man es imho.


----------



## sunny-boy (1. Jan 2011)

SlaterB hat gesagt.:
			
		

> in langjährigen COBOL-Projekten kann dagegen doch auch viel interessantes passieren oder siehts da generell öde aus?



Ich entwickle und warte an einem ERP System. Das ist sicherlich sehr interessant. Ich denke, dass hier auch langfristig große Motivation da sein wird.

@maki

Ich kann deine Argumentation verstehen. Sie deckt sich mit meinen Fragen. Doch die Stelle wechseln kommt nicht in Frage. Eher die Frage in wieweit ich mich selber "aktuell" in Sachen Java, OOP u.a  halten möchte und wie ich das mache?


----------



## André Uhres (1. Jan 2011)

sunny-boy hat gesagt.:


> die Frage in wieweit ich mich selber "aktuell" in Sachen Java, OOP u.a  halten möchte und wie ich das mache?



Da gibt's wohl keine 36 Alternativen. Du musst nur programmieren. Wieweit du das machen kannst, hängt davon ab, wieviel Zeit du dafür einsetzen kannst und willst.

Gruß,
André


----------



## Herr K. (2. Jan 2011)

André Uhres hat gesagt.:


> Da gibt's wohl keine 36 Alternativen. Du musst nur programmieren. Wieweit du das machen kannst, hängt davon ab, wieviel Zeit du dafür einsetzen kannst und willst.



So stimmt das auch wieder nicht. Neben dem Programmieren gehört schon noch etwas mehr zum Umfeld. Um sich aktuell zu halten und auch ein wenig die Trends mitzubekommen solltest Du z.B. ruhig mal den einen oder anderen Feed abonnieren oder die zugehörigen Seiten aufrufen. Hier gibt es spezielle Channels (z.B. Heise Developer, Java Lobby, ZDNet Developer, uvm.) die ganz gerne mal eine Neuerung vorstellen. 
Hier kannst Du dann auch lernen, dass vieles neu und toll klingt und sich trotzdem

Für keines deiner Projekte (aktuell) eignet
Nicht für einen produktiven Einsatz eignet weil es doch nicht so toll ist oder einfach völlig undokumentiert
Auf den zweiten Blick doch nicht so toll ist wie gedacht

Das andere ist, dass Du im Arbeitsleben nie alleine arbeiten wirst. Klar, jeder hat so seine Aufgaben und nicht überall wird man Pairprogramming etabliert haben. Trotzdem ist ein Ein-Mann-Team eine Katastrophe für jedes Unternehmen, da man keinen Wissenstransfer vornehmen kann, die Person auch mal krank ist oder Urlaub hat usw. Und Teamarbeit unterscheidet sich deutlich von dem, was man alleine im stillen Kämmerlein schafft. 
Das wichtigste ist eben, dass man Kommunikation lernt. Das klingt etwas komisch, da wir uns alle schon mal unterhalten haben und genau darin liegt auch die Gefahr. Nur weil zwei Leute miteinander reden und denken dass sie genau wissen was der jeweils andere gesagt hat heißt das nicht, dass die irgendwas verstanden haben. Häufig verwenden zwei Menschen die gleiche Syntax, gehen aber von völlig unterschiedlichen Bedeutungen aus. Im Team findet man schnell den gemeinsamen Nenner, beim Kunden sieht das dann schon wieder anders aus. 
Hier gilt es entsprechend zu lernen, wie man Missverstädnisse minimiert. Dazu gehört, dass man sich möglichst immer eindeutig und einfach ausdrückt. Tolle Buzzwords sind da nahezu tabu, da die gerne völlig sinnfrei missbraucht werden. Kleine Annekdote, ich musste mal einen gerade fertigen Fachinformatiker betreuen, der auf meine Frage warum er seinen Code nicht eingerückt, strukturiert und kommentiert habe antwortete, dass er (ganz alleine) einfach Extreme Programming betreiben würde....

Das andere ist, dass man im Team vorausplanen muss. Wenn Du selber an einem Programm arbeitest, dann wirst Du den Code schon verstehen. Die Struktur ist Dir vertraut, es ist ja Deine. Kommentare schiebt man vielleicht mal auf, man weiß ja was man wo gemacht hat und hey, eine Änderung zieht halt mal viele weitere nach sich, aber ist ja alles nicht schlimm (so ging es mir in meinen jungen Jahren und erfahrungsgemäß gibt es das auch heute noch). 
In einem Team geht das alles nicht mehr. Man hat eher einen Styleguide, damit der Code bei jedem gleich aussieht (und möglichst auch um guten Stil zu erreichen und Fehlerquellen zu minimieren!). Nicht kommentiert heißt, dass jmd. anderes nicht weiß was da gemacht wird und viel schlimmer auch nicht warum (so geht es Dir aber auch, wenn Du Deinen Code nach 6 Monaten wiedersiehst). Und Änderungen können nicht mehr beliebig vorgenommen werden. Wenn der eine einen USB-Stecker und der andere eine FireWire-Buchse baut, dann wird das nicht zusammen passen. 

Kurzum kann man hier wirklich viel lernen und sollte das auch tun. Und hier gibt es (zum Glück) auch gute Möglichkeiten. Meine Lieblingsempfehlung ist hier Sourceforge. Hier werden auch offen Helfer für bestimmte Projekte gesucht. Das erübrigt die (häufig gestellte) Frage was man für ein Projekt machen könnte. Man stellt nicht den x-millionsten MP3-Player oder Emailclient her, der ungenutzt auf einer Festplatte einstaubt, sondern ist in einem aktiven Projekt mit einer echten Motivation und sieht auch, dass das Produkt genutzt wird. Zudem lernt man mit einem (meist internationalen) Team zusammen zu arbeiten, was zudem die Qualität des Englisch steigern kann. Es gibt natürlich auch ganz analoge Alternativen, nur hat gerade SF auch eine Menge interessanter und Java-lastiger Projekte.
Natürlich heißt das nicht, dass Du nicht programmieren solltest, aber ein Projekt umfasst eben sehr viel mehr als nur das reinhacken von Code. Im Durschnitt spricht man von ca. 10-15 Zeilen Code pro Tag die ein Entwickler gemittelt über ein größeres Projekt erzeugt. Das ist jetzt keine Zahl die man auf die Goldwaage legen sollte, es ist halt nur ein Durchschnittswert, der etwas verdeutlichen soll: Entweder schreiben Entwickler im Alltag sehr langsam und überlegen sehr lange oder es gibt noch etwas anderes was einen nicht geringen Anteil einnimmt (oder beides, ist klar).


----------



## André Uhres (2. Jan 2011)

Herr K. hat gesagt.:


> So stimmt das auch wieder nicht. Neben dem Programmieren gehört schon noch etwas mehr zum Umfeld.



Unter "Programmierung" verstehe ich alle Tätigkeiten, die mit der Programmerstellung verbunden sind, insbesondere auch den konzeptionellen Entwurf. Oft sind der Entwurf und die Erstellung eines Programms nicht getrennt, das Programm entwickelt sich in diesen Fällen in enger Wechselwirkung mit dem Entwurf und umgekehrt. 

"Programmierung" bedeutet auch, dass die bereitgestellten Funktionen möglichst effizient genutzt werden, um nicht das Rad neu zu erfinden, wenn bestimmte Funktionen schon bereitgestellt werden (beispielsweise in Form von Bibliotheken). Das bedeutet für den Programmierer, in entsprechenden Dokumentationen die bereitgestellten Funktionen nachzuschlagen und einzusetzen. 

"Programmierung" bedeutet außerdem, wartbaren Programmtext zu erzeugen. Das heißt, dass die Strukturen, nach denen das Programm oder Programmmodul funktioniert, möglichst selbsterklärend sind, zudem aber auch durch Kommentare im Programmcode dokumentiert sind. Dies verlangt vor allem, dass der Programmierer sich nicht aufgrund der Anforderung, kurzen und effizienten Quelltext zu erzeugen, dazu verleiten lassen darf, Quelltext zu erzeugen, der zwar ein paar Programmzeilen spart, aber nur noch von ihm selbst verstanden werden kann. Ich erinnere an dieser Stelle an die Optimierungsregeln von Michael A. Jackson (britischer Computerwissenschaftler):
The First Rule of Program Optimization: Don't do it.
The Second Rule of Program Optimization (for experts only!): Don't do it yet.

Gruß,
André


----------



## schlingel (3. Jan 2011)

Das ist übrigens eine weit verbreitete Ansicht unter den Computerwissenschaftlern:



			
				Donald Knuth hat gesagt.:
			
		

> We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.



Und wie die vorherigen Poster schon geschrieben haben: Das wichtigste in der Praxis ist das Team-Work zu erlenen und meiner Meinung nach auch mit monolithischen Murks-Code fertig zu werden. IMHO erschließt sich Technologie dem Programmierer/Entwickler sowieso nur wenn er damit herumspielt, das kannst du auch zuhause. Die prof. Erfahrung sammelst du auch im Betrieb mit einem uralt Projekt. Hauptsache die Arbeitsatmosphäre stimmt und du bist glücklich mit der Arbeit.


----------

