Programmiersprche lernen, wie lange?

[Tom]

Hello,

ich habe ein paar Einschätzungen abzugeben, wie lange man in der Praxis braucht, um eine Programmiersprache oder auch den Umgang mit einem komplexeren Programm für den realen Broterwerb zu erlernen.

Mir klingt da immer der Satz im Ohr "...ich kann mich ziemlich schnell in neue Programme einarbeiten ..."

Die Seminare, die ich damals in Unkenntnis der Wirklichkeit an solche Leute vergeben habe, sind dann aber meistens in die Hose gegangen. Mit Programmiersprachen (selbst mit HTML) wird es wohl änlich aussehen, oder?

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

• C
• C++
• ...
• Perl
• PHP
• ..

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ludger]

Hi,

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

20 Jahre, allerdings nur drei Jahre davon habe ich professionell programmiert. Lustigerweise hat man, wenn man eine Sprache gelernt hat, gleich alle Sprachen gelernt. OK, man "sitzt" dann anfangs noch verstaerkt in der Hilfe, wenn man die Architektur eines Programms festlegen will bzw. wenn man Schluesselwoerter, Module und so kennenlernen muss, aber Programmiersprachen machen alle dasselbe, sie stellen eine Schicht bereit Code zu erstellen, der irgendwann in Maschinencode umgesetzt Daten manipuliert.

Vielleicht sollte man gleich an dieser Stelle ueber das Wesen von Daten meditieren?

Gruss,
Ludger

[derletztekick]

Hallo,

Ich kann eigentlich keine Prog-sprache richtig. Angefangen habe ich mit basic auf einem KC854 (falls das noch einem was sagt). In der Schule hatte ich Pascal und beim Studium letztlich ein wenig Java.

Bei allen drein habe ich ein paar Grundkenntnisse gelernt, die ich behalten habe und für meine kleinen Sachen auch ausreichen.

Ich kann mit Java eine Datei einlesen, sie auswerten und wieder ausgeben (Konsole). Ich habe verstanden wie schleifen Funktionieren, kann Felder ansprechen usw. also das grundlegende.

Nun habe ich mich in PHP versucht und es reichte wieder aus, um was zu machen.

Dabei ertappe ich mich aber auch immer wieder, jede Kleinigkeit selbst zu schreiben.

Bsp: ich wollte ein Gästebuch haben, das nach "Überlangen Wörtern" ein Leerzeichen einfügt. Kein Problem: Den Text in ein Array eingelesen, jedes Wort in einer Schleife überprüft und, wenn es zu lang war, in einer weiteren Schleife ein (oder mehrere, je nachdem) Leerzeichen hinzugefügt.

Einen Monat später dann beim stöbern auf selfphp: wordwrap gefunden. Zeigte mir also wieder, das ich keine Sprache kann.

Somit kann ich mir auch nur schwer vorstellen, dass einer eine Sprache in 2-3 Monaten lernen kann...

Mit freundlichem Gruß
Micha

[Jörg Lorenz]

Hi Micha,

Ich kann eigentlich keine Prog-sprache richtig. Angefangen habe ich mit basic auf einem KC854 (falls das noch einem was sagt).

Das waren noch Zeiten - nachmittags die Programme vom Radio aus auf Tonbandkassette aufnehmen ...

Viele Grüße

Jörg

[Thomas Meinike]

Hallo,

Angefangen habe ich mit basic auf einem KC854 (falls das noch einem was sagt).

Klar doch, bei mir war es 1987 der KC 85/3. Wir hatten woechentlich 90 Minuten Rechnerzeit und schafften es kaum, zu den Uebungen die handschriftlich erstellten BASIC-Quelltexte (meistens aus dem Bereich Thermodynamik) einzutippen, die der Dozent dann am Ende des jeweiligen Seminars via Geracord-Kassettenrecorder auf ORWO-K60-Chromdioxid HiFi-Kassetten (EVP 30 Mark) speicherte und sich dann zur Kontrolle anhoerte ;-).

Danach kam die PASCAL-Zeit auf AC 7150 und ATARI 800XL und vieles mehr. Wichtig ist aus meiner Sicht vor allem algorithmisches Arbeiten, da ist die konkrete Sprache schon fast sekundaer.

MfG, Thomas

[Tom]

Hello,

da gebe ich Dir Recht.
Aber was die Kenntnisse im Funktionsumfang betrifft, gibt es nur eins:

Funktionen-Quiz

Verschaff Dir eine (alphabetische) Liste aller unterstützter Funktionen und dann erkläre sie. Schriftlich und mit Anwendungsbeispiel. Wenn Du nicht weiterweißt, schau ins Manual, wenn das immer noch nicht hilft, poste in einem Forum.

Wenn Du mit weniger als 30% Nachschlagen (ausgenommen Reihenfolge von Argumenten) auskommst, dann bist Du sehr gut!

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[HoRnominatoR]

auch wenn es schon ein wenig her ist...

Bsp: ich wollte ein Gästebuch haben, das nach "Überlangen Wörtern" ein Leerzeichen einfügt. Kein Problem: Den Text in ein Array eingelesen, jedes Wort in einer Schleife überprüft und, wenn es zu lang war, in einer weiteren Schleife ein (oder mehrere, je nachdem) Leerzeichen hinzugefügt.

Einen Monat später dann beim stöbern auf selfphp: wordwrap gefunden. Zeigte mir also wieder, das ich keine Sprache kann.

Somit kann ich mir auch nur schwer vorstellen, dass einer eine Sprache in 2-3 Monaten lernen kann...

an der stelle wuerde ich sagen, genau soetwas macht es aus, eine programmiersprache erlernt zu haben - sich bei bedarf beliebige funktion selbst schreiben zu koennen. ob du weisst, dass es diese vielleicht schon gibt, sagt nur aus, in wie weit du das manual auswendig gelernt hast, jedoch nicht, ob du mit einer sprache umgehen kannst. mir ging es auch so - bis vor ein paar wochen habe ich nicht gewusst, dass es schone eine funktion zum aufrunden von integern gibt, auch wenn ich schon seit 2 jahren mit PHP arbeite. ueber ein jahr lang habe ich dafuer eine eigene funktion benutzt.

[FrankaD]

hallo Tom,

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

also es kommt m.m. immer auf die anwendung an. wenn man von etwas begeistert ist und es ständig benutzt, geht es sehr fix. macht man es, weil man muss und das vielleicht nur für ein projekt, dann fehlt der anreiz und es wird nur halb gemacht.

an meine anfänge in html kann ich mich noch gut erinnern. wir hatten damals an der uni einen englischlehrer, der uns html in verbindung mit englisch beibrachte, war ca. 1995. es hat viel spass gemacht und ich hab nächtelang gesessen und gebastelt (selfhtml hat mir dabei gute dienste erwiesen!). da war natürlich das wissen fix im kopf.

F.

[Florian]

Hmm mal meine Meinung dazu

Es ist ein guter Unterschied, ob du eine imperative oder eine objektorientierte Sprache lernen willst.

Erstere lernen bereits viele kiddies mit 15/16 recht flüssig. Will mich hier auch mal dazuzählen - zwar kommt bei denen meistens nicht schön zu lesender code heraus aber immerhin die programme klappen meistens. Wenn du dich im Bereich Webdesign spezialisieren willst, reichen diese Sprachen in der Regel auch aus.
Tipp: Buch kaufen und 2 Wochen mal hinhocken - entweder es flutscht nach der zeit oder nicht - dann wäre programmierer aber wohl eh nicht das worauf du dich spezialisieren solltest. Anspruchsvolle Lösungen sind natürlich sehr viel zeitaufwendiger.
Beispiele:

• C, PHP, ActionScript (bieten beide auch OO aber IMHO sinds doch imperative Sprachen)

Objektorienterte Sprachen sind für den Einsteiger sehr viel schwerer zu erlernen und im Webdesign auch nicht nötig - wenn auch oft sauberer, ausser du willst auf Java-Programme gehen, und dort chats etc. schreiben.

was HTML angeht - das ist keine Programmiersprache. Geh hier das Tutorial mal durch, nimm dir ne Woche Zeit, dann sollte das zu 95% passen. Dann hol dir ein php-Buch, und in spätestens einem Monat ist deine Frage beantwortet.

[Florian]

Bis man eine Sprache allerdings perfekt kann, vergehen Jahre. Die ersten 90% sind schnell gelernt, die restlichen 10% dauern vielleicht 20x so lange.

Und wenn du mal eine sprache kannst, lernst du ne andere in ein paar tagen dazu => wieder auf die 90%

[Tom]

Hello,

Bis man eine Sprache allerdings perfekt kann, vergehen Jahre. Die ersten 90% sind schnell gelernt, die restlichen 10% dauern vielleicht 20x so lange.

Und wenn du mal eine sprache kannst, lernst du ne andere in ein paar tagen dazu => wieder auf die 90%

Das ist gut gesagt.
So habe ich das bisher noch gar nicht gesehen. Aber es stimmt.
Leider reichen in einem Programm schon wenige Promille Fehler, die aus der Unkenntnis der 10% stammen, um das Ding unbrauchbar zu machen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Fabian Transchel]

Hi,

was HTML angeht - das ist keine Programmiersprache. Geh hier das Tutorial mal durch, nimm dir ne Woche Zeit, dann sollte das zu 95% passen. Dann hol dir ein php-Buch, und in spätestens einem Monat ist deine Frage beantwortet.

Du kennst den Tom ja vielleicht nicht so gut - aber bei der Aussage habe ich mich echt wegeschmissen. Keiner hat hier jemals so ehrlich einem Regular ein Tutorial verschrieben :)

Grüße aus Barsinghausen,
Fabian

[Dennis]

Hi Florian,

was HTML angeht - das ist keine Programmiersprache. Geh hier das Tutorial mal durch, nimm dir ne Woche Zeit, dann sollte das zu 95% passen. Dann hol dir ein php-Buch, und in spätestens einem Monat ist deine Frage beantwortet.

LOL, lange nicht mehr so gelacht ;-)

MfG, Dennis.

[Eternius]

Moin,

ich behaupte jetzt mal, dass es einfach ist, eine Programmiersprache zu erlernen, wenn man erst mal die ganzen Programmierkonzepte verstanden hat, wie z.B. verkettete Liste oder hashing usw.

Danach ist eigentlich nur die Frage, ob die zu lernende Programmiersprache diese Mechanismen bietet, und wenn nicht, Alternativen.

• C

dank scheiss Pascal hab ich mich damit sehr schwer getan

• C++

das blöde objekt geraffel obendrauf ging aber wieder schnell.

• ...

diese programmiersprache kenn ich jetzt nett.

• Perl

man lernt nie aus ;)

• PHP

gar nicht.

js + vbs + vb + wmi + wsh
naja das ganze windows geraffel, so wie ich es eben brauchte

shellskripte
wow, echt lange. Zumal man mit Shellskripten auch (fast) alles das hinkriegt, was man fürs Web mit Perl oder PHP machen kann und das Shellskript meist auch noch schneller ist. (mir ist der link zu einem vergleichstest entfallen)

also, am einfachsten hab ich immer gelernt mit einem _konkreten_ problem, dass es zu lösen gab. Nicht ohne theorie, aber auch nicht ohne viel Praxis und selber machen.

gruss

[Der Martin]

Hallo,

ich behaupte jetzt mal, dass es einfach ist, eine Programmiersprache zu erlernen, wenn man erst mal die ganzen Programmierkonzepte verstanden hat

Das sehe ich auch so.

• C
  dank scheiss Pascal hab ich mich damit sehr schwer getan

Diese Einschätzung überrascht mich. Mir ging's damals eher umgekehrt. Okay, im Teenie-Alter habe ich schon mit BASIC rumgespielt, aber die erste ernsthafte Programmiersprache war dann Pascal, das ist auch IMHO eine hervorragende Sprache für den Einstieg. Es vermittelt Grundlagen, und man gewöhnt sich (zwangsläufig) eine gewisse Ordnung und Disziplin an.
Als ich dann später C dazu gelernt habe, fiel mir das sehr leicht, weil es in den Grundzügen dem Pascal sehr ähnlich ist.

• C++
  das blöde objekt geraffel obendrauf ging aber wieder schnell.

Hmm, ich mag's net, und deshalb tu ich mich heute noch schwer mit C++. Wenn's sein muss, komme ich damit zurecht, aber ich würde es nicht freiwilig wählen. Bei einer konkreten Problemstellung ertappe ich mich ab und zu, wie ich objektorientierte Ansätze mit normalem C nachbilde. Das fällt mir dann wesentlich leichter.

• Perl
  man lernt nie aus ;)

Stimmt. Vielleicht sollte ich mich damit auch mal beschäftigen...?

• PHP
  gar nicht.

Durch die Ähnlichkeit mit C konnte ich mir PHP wiederum in etwa zwei Wochen aneignen. Jedenfalls die 90%, die Florian schon angesprochen hat.

also, am einfachsten hab ich immer gelernt mit einem _konkreten_ problem, dass es zu lösen gab. Nicht ohne theorie, aber auch nicht ohne viel Praxis und selber machen.

Guter Ansatz, finde ich. Es gibt Leute, die können sich ein Buch zur Hand nehmen, arbeiten das auf dem Trockenen durch und haben dann wirklich begriffen, wie's geht. Aber das ist wohl die Ausnahme. Mir sagt z.B. ein konkretes Code-Beispiel auch mehr als eine formale Syntax-Beschreibung.

So long,

Martin

[Lastaffair]

Hallo Martin,

Guter Ansatz, finde ich. Es gibt Leute, die können sich ein Buch zur Hand nehmen, arbeiten das auf dem Trockenen durch und haben dann wirklich begriffen, wie's geht. Aber das ist wohl die Ausnahme. Mir sagt z.B. ein konkretes Code-Beispiel auch mehr als eine formale Syntax-Beschreibung.

hmm was für ein Buch wurdest du denn zu PHP empfehlen? Und kennst du zufällig auch eine Seite wo man Schritt für Schritt PHP lernen kann also so in etwas wie durch Tutorials oder so? Ach ja dads gleiche gilt dann auch noch für Perl, denn wie in einem anderen Beitrag schon geschrieben lerne ich das gerade....

Gruß Lastaffair

[Dennis]

Hi Lastaffair,

Und kennst du zufällig auch eine Seite wo man Schritt für Schritt PHP lernen kann also so in etwas wie durch Tutorials oder so?

Also ich habe eigentlich PHP als erste richtige Programmiersprache gelernt (also die bereits angesprochenen 90% ;-), mal abgesehen von Javascript. Insebesondere http://tut.php-q.net/ hat mir da geholfen, um einerseits erst mal die Client-Server-Kommunikation zu verstehen, aber auch um dann mit MySQL zu arbeiten.

MfG, Dennis.

[Tom]

Hello,

Also ich habe eigentlich PHP als erste richtige Programmiersprache gelernt (also die bereits angesprochenen 90% ;-), mal abgesehen von Javascript. Insebesondere http://tut.php-q.net/ hat mir da geholfen, um einerseits erst mal die Client-Server-Kommunikation zu verstehen, aber auch um dann mit MySQL zu arbeiten.

Das ist auch eins der wenigen Tutorials, das immer besser wird und den Anfänger auch abzuholen versteht.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

Hallo,

hmm was für ein Buch wurdest du denn zu PHP empfehlen?

Hmmm, ich hab zwei zu Hause liegen, die ich für gut halte, und die beide irgendwas in der Größenordnung 20..25 EUR gekostet haben. Eins hat einen roten, das andere einen dunkelblauen Einband. ;)
Aber frag mich jetzt nicht nach Titel oder gar Verlag... Wenn's dir dann noch wichtig ist, kann ich dir die Info heute abend nachreichen, wenn ich wieder zu Hause bin.

Ciao,

Martin

[Tom]

Hello,

Diese Einschätzung überrascht mich. Mir ging's damals eher umgekehrt. Okay, im Teenie-Alter habe ich schon mit BASIC rumgespielt, aber die erste ernsthafte Programmiersprache war dann Pascal, das ist auch IMHO eine hervorragende Sprache für den Einstieg. Es vermittelt Grundlagen, und man gewöhnt sich (zwangsläufig) eine gewisse Ordnung und Disziplin an.

Ich bin mit Pascal und embedded Assembler damals so tief in die DOS-Systemarchitektur eingestiegen, dass ich bei C später echte Schwierigkeiten hatte, das nachzuvollziehen. C macht viele Dinge leider auf eigene Weise auch mit eigenen Fehlern und gibt Möglichkeiten der Systemarchitektur nicht weiter. Ob man das nun als Abstraktionsversuch oder als Ungeschicklichkeit bezeichen will, soll dahingestellt bleiben.

Ich habe jedenfalls für die AS400 auf Pascal für OS400 sehr schnell ähnliche Ergebnisse erzielen können, wie mit Pascal auf DOS (mit DPMI 16MByte). Mit C ist mir das nicht gelungen, weil es eben scheinbar keine Abstraktionsschicht war, sondern eine Bastelschicht.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

Hallo Tom,

Ich bin mit Pascal und embedded Assembler damals so tief in die DOS-Systemarchitektur eingestiegen, ...

Ich auch. Mit dem Borland Pascal-Compiler, vermute ich?
Der war auch IMHO unübertroffen, wenn es um die Erzeugung von optimiertem Code ging. Ich hab mir manches Mal den vom Compiler erzeugten Code angeschaut und nur _selten_ eine Stelle gefunden, wo man es in Assembler "von Hand" hätte effizienter machen können.
Trotzdem habe ich auch oft inline-Assembler mit eingestreut, z.B. um mal eben eine BIOS- oder DOS-Funktion aufzurufen, oder auch um einfache arithmetisch-logische Operationen durchzuführen, die Pascal nicht direkt kann/konnte.

dass ich bei C später echte Schwierigkeiten hatte, das nachzuvollziehen.

Hier trennen sich unsere Erfahrungen. Der einzige Punkt ist, dass die C-Compiler meistens etwas starrer sind, wenn es um Aufrufmechanismen, Stack-Handling und so geht. Da könnte man "zu Fuß" manches einfacher machen.

C macht viele Dinge leider auf eigene Weise auch mit eigenen Fehlern und gibt Möglichkeiten der Systemarchitektur nicht weiter.

Ach ja? Dass jeder Compiler potentiell fehlerhaft ist, dürfte klar sein. Aber ich hatte eigentlich immer den angenehmen Eindruck, mit C sehr systemnah zu programmieren.

[...] weil es eben scheinbar keine Abstraktionsschicht war, sondern eine Bastelschicht.

Ich bin der Ansicht, C soll auch nichts abstrahieren, sondern einen Weg bieten, so maschinennah wie möglich programmieren zu können, ohne dabei auf die Vorzüge einer Hochsprache verzichten zu müssen.

Die Abstraktion ist dann IMHO Sache des Programmierers, der sein Projekt in Module oder Schichten aufteilt, die von der Applikations- bis zur Betriebssystem- oder Maschinenebene zunehmend plattformspezifisch sind.

So long,

Martin

[Tom]

Hello,

dass ich bei C später echte Schwierigkeiten hatte, das nachzuvollziehen.

Hier trennen sich unsere Erfahrungen. Der einzige Punkt ist, dass die C-Compiler meistens etwas starrer sind, wenn es um Aufrufmechanismen, Stack-Handling und so geht. Da könnte man "zu Fuß" manches einfacher machen.

C macht viele Dinge leider auf eigene Weise auch mit eigenen Fehlern und gibt Möglichkeiten der Systemarchitektur nicht weiter.

Ach ja? Dass jeder Compiler potentiell fehlerhaft ist, dürfte klar sein. Aber ich hatte eigentlich immer den angenehmen Eindruck, mit C sehr systemnah zu programmieren.

Ich habe damals netzwerkfähige Programme entwickelt. Obwohl viele Andere der Meinung waren, dass ein Programm "netzwerkfähig" war, wenn man es von einer Netzwerkressource auf die WS laden konnte, war ich am Zeitverhalten und dem konkurrierenden Betrieb interessiert. Mit Pascal ging das alles transparent umzusetzen, mit C leider nicht, weil schon beim FileOpen nicht auf die OS-Schicht weitergeleitet wird, sondern ein vollkommen eigenes Modell verfolgt wird. Und das wird nicht über Variablen sondern über Konstanten umgestezt

fopen('filename','konstante_fuer_den_Modus')

Pascal übergibt hier den Filemode als Variable.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

n'Abend,

Obwohl viele Andere der Meinung waren, dass ein Programm "netzwerkfähig" war, wenn man es von einer Netzwerkressource auf die WS laden konnte, ...

*LOL*
Und "echtzeitfähig" bedeutete dann wahrscheinlich, dass diese Leute echt Zeit gebraucht haben, die Programme zu verstehen?  ;)

[...] sondern ein vollkommen eigenes Modell verfolgt wird. Und das wird nicht über Variablen sondern über Konstanten umgestezt
  fopen('filename','konstante_fuer_den_Modus')
Pascal übergibt hier den Filemode als Variable.

Das verstehe ich jetzt nicht ganz, denn C kennt eigentlich keine Konstanten in dem Sinn. Jeder Parameter einer Funktion kann ebensogut als Variable übergeben werden; durch das implizite Call-By-Value-Prinzip wird eh eine Kopie des Variablenwerts übergeben. Deshalb müsste dieser Code-Schnipsel problemlos funktionieren:

FILE *f;
 char fm[] = "w+";

f = fopen("filename", fm);

Abgesehen davon habe ich, wenn ich wirklich systemnahen Code schreiben wollte oder musste, sowieso nicht ndie stdio benutzt, sondern -um das Beispiel DOS aufzugreifen- die guten alten INT 21h-Aufrufe direkt mit inline-Assembler codiert.
Denn eines ist klar: Auch wenn die Standardbibliotheken (das Wort sagt es ja schon) standardisiert sein sollten, bringen sie doch je nach Implementierung immer kleine Variationen ins Spiel. Und einen gewissen Overhead sowieso, der möglicherweise stört, wenn man das letzte Bisschen Performance rausholen möchte.

So long,

Martin

[Tom]

Hello,

FILE *f;
char fm[] = "w+";

f = fopen("filename", fm);

Ich meinte das andersherum.

C interpretiert das "w+" und setzt es in einen eigenen Algorithmus um
Pascal reicht die Variable "Filemode" über einen Handler (OS-abhängig) direkt an das OS weiter, sofern das zulässig und sinnvoll ist. Da aber die meisten OS-Entwickler voneinander abgguckt haben und das selten vollständig neu entwickelt haben, die Filemodes meistens gleich. Nur C meint, hier ein eigenes Süppchen kochen zu müssen.

Wenn es damit eine echte Abstraktionsschicht einführen würde, wäre das sogar richtig. Aber eine Abstraktionsschicht darf nicht _wesentliche_ Fähigkeiten einer tieferen Schicht einfach unterschlagen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ole]

hi

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

Naja, was heißt schon wirklich vertraut? :)
Ich definiere das mal für mich so:

1. Man weiss was die Sprache kann
2. Das meiste kann man selber umsetzen
3. Wenn man nciht mehr weiter weiß, weiß man wo man nachschlagen muß :)

HTML + CSS - 2-4 Monate
ColdFusion - 3-6 Monate

so long
ole
(8-)>

[Ludger]

Hi,

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

[...]

HTML + CSS - 2-4 Monate
ColdFusion - 3-6 Monate

Du hast ASP und XML vergessen.   ;-)

Gruss,
Ludger

[Ole]

hi

Du hast ASP und XML vergessen.   ;-)

wie kommt du darauf?

so long
ole
(8-)>

[Der Martin]

Hallo,

du hast Stufe 4 vergessen:

3. Wenn man nicht mehr weiter weiß, weiß man wo man nachschlagen muß :)
4. Wenn man nicht mehr weiter weiß, weiß man auch nicht mehr, wo man nachschlagen könnte

So geht's mir nämlich stellenweise(!) mit dem Windows-API.

tschüss,

Martin

[Ludger]

Hi,

So geht's mir nämlich stellenweise(!) mit dem Windows-API.

was veranlasst Dich Funktionen der Windows-API zu nutzen?

Gruss,
Ludger

[Der Martin]

So geht's mir nämlich stellenweise(!) mit dem Windows-API.

was veranlasst Dich Funktionen der Windows-API zu nutzen?

Das Ziel, effiziente und kompakte Applikationen für eben diese Plattform zu schreiben.
Was sonst?

Ciao,

Martin

[Ludger]

Hi,

So geht's mir nämlich stellenweise(!) mit dem Windows-API.

was veranlasst Dich Funktionen der Windows-API zu nutzen?

Das Ziel, effiziente und kompakte Applikationen für eben diese Plattform zu schreiben.
Was sonst?

huestl, ja dann viel Glueck?

Gruss,
Ludger

[Ole]

hi

was veranlasst Dich Funktionen der Windows-API zu nutzen?

Naja, bei mir ist es die Automatisierung von Vorgängen auf unserem Server, die mich dazu zwingt.

so long
Ole
(8-)>

[Lastaffair]

Hallo Tom,

mich wurde mal interesieren wie lange du gebraucht hast um das alles zu lernen bzw. mit was arbeitest du denn immer so?

Ich selber lerne gerade PHP und Perl :-)

Gruß Lastaffair

[Tom]

Hello,

mich wurde mal interesieren wie lange du gebraucht hast um das alles zu lernen bzw. mit was arbeitest du denn immer so?

Oh, ziemlich lange, wenn das Gegenteil dazu lautet "wenige Stunden".

Vorausgegangen ist die Boolesche Algebra mit Relais. Da war ich mal Spitze.

Angefangen hat es dann mit Basic und einm PET von Commodore, das war aber im Praktikum bei Siemens und es gab weder Handbuch noch jemanden, der Lust hatte, mir was zu erklären. So macht Lernen Spaß :-((

Die erste Sprache, die ich wirklich gelernt habe, war Algol60

Dann kam Fortran (ich weiß kein Stück mehr davon)

Dann dBase Datenbank im Selbststudium
Dann Assembler
Dann Pascal
Diverse Datenbankdialekte
Dann C
Dann C++ (bin ich aber eingerostet. Hat sich viel getan seitdem)
Na und ein paar Gehversuche in PERL bis ich zu PHP kam.
Das hat aber genaugenommen vier Jahre in Anspruch genommen, wirklich die meisten kleinen "Schweinereien" zu verstehen und selber umsetzen zu können.

... to be continued ...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Lastaffair]

Hallo Tom,

mensch dann kannst du echt viel * neudisch schauen tu * joa und mit was arbeitest du nun am meisten? Ich nehmen mal an Perl und PHP oder?

Gruß Lastaffair

[Tom]

Hello,

mensch dann kannst du echt viel * neudisch schauen tu * joa und mit was arbeitest du nun am meisten? Ich nehmen mal an Perl und PHP oder?

Nein, ich kann viel zu wenig. *schnüff*
Und mit PERL kann ich bislang nur spielen. Da fehlt mir noch der professionelle Level.
Schlimm ist nur, wenn man ein paar Tage mit ganz anderen Dingen beschäftigt ist, dann ist man ruck zuck wieder draußen.

Ich muss mich nun langsam mal wieder mit PHP in Bezug auf Informix beschäftigen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[dedlfix]

mensch dann kannst du echt viel * neudisch schauen tu * joa

Dafür siehst du bestimmt auch noch jung und hübsch aus. "Uns" sieht man die Erfahrung und Reife auch körperlich an. :-)

[Tom]

Hello,

Dafür siehst du bestimmt auch noch jung und hübsch aus. "Uns" sieht man die Erfahrung und Reife auch körperlich an. :-)

Ist was dran... zumindest ein Bauch ;-))

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[e7]

Hi,

• HTML

Keine Programmiersprache, ich erwähn sie aber trotzdem mal weil du HTML schon in einer Klammer nanntest.
Ich denke HTML ist relativ einfach, das kapieren sogar die größten Idioten (Zitat sinngemäß: "HTML? Kann ich, das ist das wo man Links machen kann"). Ob das ganze Standardkonform ist, ist ne andere Frage, und Design existiert sowieso nicht (von zahlreichen <font color= mal abgesehen)...

• ..

Ich setz hier einfach mal "Visual Basic" ein.

Einfachere Programme hab ich nach 1 - 2 Jahren zusammengebastelt. Am Anfang hab ich gar nix kapiert - irgendwie konnte mir das blöde Buch (VB für Dummys) nicht erklären, dass man für den Zugriff auf Funktionen von Objekten einen . zwischen Objekt und Funktionsname setzen muss...

So was ging:
Left = 10
Windowstate = 2
Msgbox "Hallo"

Wenn es aber darum ging, einen Button zu verschieben, war's aus, das hat das Buch irgendwie verschwiegen dass man da Name + Punkt davor setzen muss... Aber sonst kann man eigentlich mit Nachschlagen recht viel bauen....

• PHP

Da ich das Grundprinzip des Programmierens damals schon von VB her kannte, hab ich zu PHP zwei Bücher durchgelesen und sofort losgetippt - und es kam auch eine recht fehlerfreie Seite raus... PHP ist im Grunde rotzeinfach (einfacher als VB), und wenn man eh schon programmieren kann, ist das in wenigen Stunden erklärt/gelernt.

E7

[Tom]

Hello,

Da ich das Grundprinzip des Programmierens damals schon von VB her kannte, hab ich zu PHP zwei Bücher durchgelesen und sofort losgetippt - und es kam auch eine recht fehlerfreie Seite raus... PHP ist im Grunde rotzeinfach (einfacher als VB), und wenn man eh schon programmieren kann, ist das in wenigen Stunden erklärt/gelernt.

*ähem*
meintest Du wirklich "ein paar Stunden"?

Dann muss Dir aber das gesamte Konzept der verbindungslosen Client-Server Architektur, verkettete Listen (Arrays), Filezugriffe, Locking etc uach schon vertraut gewesen sein.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[e7]

Hi,

meintest Du wirklich "ein paar Stunden"?

naja, halt vorher noch die Bücher durchlesen, das dauert natürlich etwas länger, aber im Grunde hab ich damals mit PHP imho nach ein paar Stunden schon was recht nützliches zusammengebracht...

Dann muss Dir aber das gesamte Konzept der verbindungslosen Client-Server Architektur,

Mmhh... Eigentlich brauch ich meistens nur eine simple HTML-Seite als Ausgabe

verkettete Listen (Arrays),
Filezugriffe,

gibt's ja in *Basic auch.

Ich denke, wenn jemand Visual Basic kann (nicht meint es zu können), ist PHP sehr schnell zu lernen - im Grunde ist es lediglich die andere Syntax sowie die anderen Funktionsnamen, was Probleme bereitet, aber sonst: Was soll man groß neulernen um einfache Dinge zu erledigen? Höchstens Klassen vielleicht und solche Dinge - braucht's am Anfang aber auch nicht unbedingt...

E7

[wahsaga]

hi,

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

"programmiersprachen sind wie frauen - kennst du eine, ..."

scherz beiseite, was ich damit sagen will:
grundsätzlich ist es m.E. erst mal wichtig, dass jemand wie ein programmierer _denken_ kann - logisches denkvermögen, verständnis für algorithmen, etc.

wie lange das dauert, schwer zu sagen - dürfte wohl individuell unterschiedlich sein.
meine ersten schritte hab ich damals autodidaktisch am C64 in basic gemacht, das handbuch genommen und losgelegt ... hat gleich von anfang an ganz gut funktioniert, vermutlich weil einfach genug interesse und faszination vorhanden war.

die derart einmal erworbenen kenntnisse und fähigkeiten dann auf eine andere programmiersprache zu "übertragen", algorithmen in deren andersartigen befehlsumfang abzubilden, etc. - das ist dann in meinen augen der eher einfachere teil.
(auch wenn ich zugebe, dass das jetzt eher verallgemeinernd ist, und natürlich auch stark von umfang und komplexität der neuen progammierspache abhängt.)

gruß,
wahsaga

[Dennis]

Hi wahsaga,

grundsätzlich ist es m.E. erst mal wichtig, dass jemand wie ein programmierer _denken_ kann - logisches denkvermögen, verständnis für algorithmen, etc.

Da möchte ich dir auf jeden Fall zustimmen. Ich programmiere nun ja seit knapp einem Jahr PHP und habe mir mittlerweile schon ein bisschen ein logisches Denkvermögen angeeignet.

Doch jetzt haben wir neulich in Informatik in der Schule mit VisualBasic angefangen. Was ist da gesehen habe, war schon fast erschreckend. Was da teilweise welche für Probleme haben, erst mal die logischen Abfolgen einer If-Abfrage, mit Elseif und Else auf die Reihe zu bringen... Geschweige denn Bedingungen mit AND bzw. OR logisch miteinander zu verknüpfen...

MfG, Dennis.

[Tom]

Hello,

Da möchte ich dir auf jeden Fall zustimmen. Ich programmiere nun ja seit knapp einem Jahr PHP und habe mir mittlerweile schon ein bisschen ein logisches Denkvermögen angeeignet.

Doch jetzt haben wir neulich in Informatik in der Schule mit VisualBasic angefangen. Was ist da gesehen habe, war schon fast erschreckend. Was da teilweise welche für Probleme haben, erst mal die logischen Abfolgen einer If-Abfrage, mit Elseif und Else auf die Reihe zu bringen... Geschweige denn Bedingungen mit AND bzw. OR logisch miteinander zu verknüpfen...

Aber Visual Basic ist nicht logisch, denn es ist von Billy the Gator.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Fabian Transchel]

Hi,

grundsätzlich ist es m.E. erst mal wichtig, dass jemand wie ein programmierer _denken_ kann - logisches denkvermögen, verständnis für algorithmen, etc.

Da möchte ich dir auf jeden Fall zustimmen. Ich programmiere nun ja seit knapp einem Jahr PHP und habe mir mittlerweile schon ein bisschen ein logisches Denkvermögen angeeignet.

Doch jetzt haben wir neulich in Informatik in der Schule mit VisualBasic angefangen. Was ist da gesehen habe, war schon fast erschreckend. Was da teilweise welche für Probleme haben, erst mal die logischen Abfolgen einer If-Abfrage, mit Elseif und Else auf die Reihe zu bringen... Geschweige denn Bedingungen mit AND bzw. OR logisch miteinander zu verknüpfen...

Oohhh ja. Ich hab in meinem Informatik-Kurs in der 11. Klasse Sachen (in Java) gesehen, da stehen mir heute (Abi: -3 Monate...) noch die Haare zu Berge, solche Schoten waren das. Da ist if()-Verschachteln noch schön gewesen.

Grüße aus Barsinghausen,
Fabian

[Tom]

Hello,

Oohhh ja. Ich hab in meinem Informatik-Kurs in der 11. Klasse Sachen (in Java) gesehen, da stehen mir heute (Abi: -3 Monate...) noch die Haare zu Berge, solche Schoten waren das. Da ist if()-Verschachteln noch schön gewesen.

Wie jetzt? Hast Du etwas die legendären "if-Schleifen" sehen dürfen?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Dennis]

Hi Tom,

Wie jetzt? Hast Du etwas die legendären "if-Schleifen" sehen dürfen?

hehe, in einer anderen Stufe machen sie gerade "HTML und Javascript". Dreimal darfst du raten, wie man denen erklärt hat, wie das HTML Grundgeerüst anfängt ;-)

MfG, Dennis.

[Fabian Transchel]

Hi,

Oohhh ja. Ich hab in meinem Informatik-Kurs in der 11. Klasse Sachen (in Java) gesehen, da stehen mir heute (Abi: -3 Monate...) noch die Haare zu Berge, solche Schoten waren das. Da ist if()-Verschachteln noch schön gewesen.

Wie jetzt? Hast Du etwas die legendären "if-Schleifen" sehen dürfen?

Du musst jetzt tapfer sein - das habe ich.

Grüße aus Barsinghausen,
Fab*duck*ian

[Bio]

Sup!

Das hängt davon ab, wie lange Du pro Tag damit arbeitest, welche Sprachen Du schon kannst und wie smart Du bist.

Gruesse,

Bio

[Tom]

Hello,

Das hängt davon ab, wie lange Du pro Tag damit arbeitest, welche Sprachen Du schon kannst und wie smart Du bist.

Du sollst mir aber nicht sagen, wie smart ich bin, sondern was DEINE Erfahrungen waren. Die ganz schlimmen musst Du ja nicht offenbaren ;-))

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Bio]

Sup!

Du sollst mir aber nicht sagen, wie smart ich bin, sondern was DEINE Erfahrungen waren. Die ganz schlimmen musst Du ja nicht offenbaren ;-))

Hmmm... zuerst habe ich Commodore V2.0 Basic für C64 gelernt. Das war natürlich einfach, weil man damit fast nichts machen konnte.
Allerdings konnte man damit eine Konto-Verwaltung oder einen Binär-Oktal-Hex-Umrechner schreiben.
Dann gab's die BASIC-AG in der Schule und GW-Basic (absolut super Sache das), damit haben wir dann sinnlose "Fangen" oder "Autorennen" Spiele geschrieben.
Zwischendurch hatte ich den Einfall, "Pascal" zu lernen, denn das sollte kompilierbar und schneller sein, aber mir gefielen die verkopften Sprachelemente nicht und der Compiler, der meinte, am Ende einer Zeile solle ein ";" stehen - da habe ich immer gedacht, wenn der Compiler das schon weiss, warum geht er mir dann auf den Sack damit?
Ich habe dann auf dem Atari ST mit Omikron-Basic weiterprogrammiert und mit GFA-Basic, was den grossen Vorteil hatte, dass Omikron-Basic und GFA-Basic Prozeduren und Funktionen und Sprungmarken hatten.
Man konnte damit sogar GEMDOS-Funktionen benutzen... Wahnsinn.
Schließlich hatte ich auch noch einen Amiga, aber das OS war ja im Vergleich mit TOS so grauenhaft und der Bildschirm so schlimm, dass ich da nichtmal viel programmiert habe, obwohl ich AMOS (eine Art Basic-Game-Construction-Kid) hatte.
Dann gab's PCs und QBasic und DOS-Batch-Befehle.... damals musste man ja immer viel in der Autoexec.bat rumschrauben, um die ganzen Speichermanager in den Griff zu kriegen, EMMS und XMMS, Himem und den ganzen Scheiss.
So gewappnet habe ich dann angefangen Informatik zu studieren, da lernte man dann Scheme, einen LISP-Dialekt (LISP soll ziemlich rocken, wenn man es wirklich kann), und dann C (C rockt auf jeden Fall). Sonst nichts eigentlich, aber wer C kann, der kann auch fast schon JavaScript, C++ und Java, wobei man sich bei C++ und Java in diesen OO-Kram eindenken muss, was aber noch relativ leicht geht, wenn man sich vorstellt, dass in den Objekten eigentlich auch nur Strukturen und Zeiger sind. Die höheren C++ und Java-Weihen blieben mir allerdings bislang verborgen, weil ich die noch nicht brauchte... C kann man aber in ein paar Monaten recht gut lernen, wenn man *muss*.
Perl habe ich mir selbst beigebracht, mit "Programming Perl" von Larry Wall geht das schon, dauert auch ein paar Monate. PHP ist dann auch kein Problem, wenngleich es irgendwo nervt, weil es nicht so verdammt cool wie Perl ist.

Gruesse,

Bio

[Tom]

Hello Bio,

Perl habe ich mir selbst beigebracht, mit "Programming Perl" von Larry Wall geht das schon, dauert auch ein paar Monate. PHP ist dann auch kein Problem, wenngleich es irgendwo nervt, weil es nicht so verdammt cool wie Perl ist.

Das war wieder echte "Biologie". Danke!

Also dauert es schon ein wenig, bis man mit sich selbt und er Welt zufrieden sein kann. Und inzwischen denke ich, dass man eine Programmiersprache erst dann "kann", wenn man ihre Genzen erkannt und gelegentlich gesprengt hat.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[mikey]

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

in einer Sprache programmieren zu können und 90% der gestellten Anforderungen ohne größere Probleme umzusetzen, hat so gar nichts mit der genauen Kenntnis der Sprache zu tun, dafür reichen auch gute Quellen und halbwegs logisches Denkvermögen

wie schon weiter unten gesagt, für die magischen 10% - also auch das Wissen um die Funktionsweise des Compilers, vielleicht bis runter auf Maschinencodeebene - braucht man nicht unbedingt viele Jahre, aber viel Erfahrung

Beispiel - Cobol (I 85er)

ziemliche simple Sprache, aber in Verbindung mit Großrechner (TSO, CICS + DB2) und den naturgegebenen Spezialitäten der Entwicklungsumgebungen brauchts selbst hier mind. 5 Jahre bis man für jede Anforderung aus dem FF die optimale Lösung liefern kann

grds. würd ich - wie wahsaga schrieb - das logisch analytische Denkvermögen als größtes Hürde betrachten, der 2. große Schritt ist dann der in die Welt von oo

Was html und css angeht,

da würd ich ebenfalls Jahre veranschlagen - und ständiges Lernen - weil Syntax und co. SEHR einfach sind, aber alle Browserprobleme in Kombination und die entsprechenden Lösungen....das dauert

für erfolgreichere Seminare,

empfehle ich dir mal ein Seminar bei Integrata, die schaffen es meiner Meinung nach sehr gut, selbst den grünsten Anfängern das nötige Rüstzeug zu geben

[Eternius]

Hallo,

die 3. grösse Hürde ist ooad bei grossen systemen, damit nicht solche Projekte wie Mautsystem o.ä. zustande kommen, die einfach nicht funktionieren.
und 4. ist das "silver bullet" das durch geschickte Planung manchmal unter kontrolle zu bringen ist.
und 5. die allgemeinbildung der Programmierer: siehe Hartz IV (sprich HIV) => wie werden Kontonummern aufgefüllt, oder Metrische Systeme (siehe Raketenbau vor x Jahren Newton und Pfund).

gruss

[fastix®]

Moin!

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

Prinzipiell lernt man nie aus.

BASIC (ich meine sowas wie C64-BASIC... 1/2 Jahr) Das war aber meine erste Sprache.

• Perl

1 Jahr nebenbei oder zwei Projekte

• PHP

1/4 Jahr nebenbei oder ein fettes Projekt (das gibt es noch zu bestaunen)
Javascript
      1/4 Jahr nebenbei

Java: ein paar Stunden innerhalb weniger Wochen:) - im Ernst. Die beiden Einsteiger- Seminare, die ich als Trainer hielt, sind gut gelaufen. Ich möchte aber nicht behaupten, dass ich es kann.

Bei den Zeitangaben ist folgendes problematisch: Kann man schon was ähnliches und muss praktisch nur eine neue Syntax lernen (Perl-> PHP) oder kann man noch gar nichts in der Richtung.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix®

[srob]

Hallo Tom,

ich wüßte gar nicht, wie das "Können" einer Programmiersprache zu definieren sei, das ist wohl auch aus einigen der bisher eingetrudelten Antworten auf Deine Frage herauszulesen. Mit dem Problem schlagen sich zahllose Arbeitgeber herum, die sich aus Zeugnissen, Zertifikaten und Selbstdarstellungen der Bewerber ein Bild machen sollen. Ich bin überzeugt, daß es in dieser Frage keine harten Kriterien zur Beurteilung gibt - besser: geben kann. Für mich wäre das Testen der Kandidaten mit einer komplexen Aufgabe die einzig richtige Methode zur Beurteilung des Könnens, was für das praktische Wirtschaftsleben nahezu unmöglich ist.

Einige Dinge gehen mir durch den Kopf, die die Frage nach einer wie auch immer definierten Könnerschaft - und damit auch die erforderliche Zeit, um etwas können zu können - merklich beeinflussen:

1. Erfahrungen aus bereits erlernten Sprachen und Systemen beschleunigen nachfolgende Lernphasen erheblich. Oder bewirken das genaue Gegenteil: ich denke da an Programmierer, die in prozeduralen Sprachen hervorragende Arbeit leisteten und dann OO-Systeme lernten. Schnelle Lernfortschritte. Gute Prüfungsergebnisse. Output in der beruflichen Anwendung: katastrophal; ich habe das so oft gesehen... Ein Gutteil unserer labilen Großsysteme geht sicherlich auf dieses Konto. Da scheint es an so etwas wie "Meta-Können" zu fehlen, im OO-Beispiel die Befähigung zu objektorientiertem Denken, Kenntnis, Verständnis und Anwendungsfähigkeit von Design Patterns und Systemarchitekturen, also von Dingen, die weit über die Beherrschung von semantischen und syntaktischen Eigenarten einer Sprache hinausgehen.

Allerdings gibt es auch Sprachen, die völlig anders "ticken" als der große Brei Pascal/C/C++/Basic. Da fällt mir meine völlige geistige Überforderung (anfänglich) beim Erlernen von Prolog ein. Oder, vor zwei Wochen erst, mein Versuch, mal eben auf die Schnelle für den XEmacs in LISP ein kleine rekursive Funktion zu schreiben, die Umlaute gegen ihre HTML-Entitäten austauscht. Bei aller Bescheidenheit halte ich große Stücke auf meine Fähigkeit, mir in küzester Zeit neue Systeme anzueignen; und da ich vor 15 Jahre mal mit LISP AutoCAD-Erweiterungen zur 3-D-Darstellung von Magnetfeldern entwickelt habe, dachte ich, das wird in einer Stunde erledigt sein. Denkste! Was für ein Waterloo - nach zweieinhalb Tagen in völliger Verzweiflung haben mich Hinweise aus dem Usenet erst auf den richtigen Weg gebracht...

2. Manche Sprachen haben einen enorm großen Sprachumfang. Als Beispiel ich selbst: das System, bei dem ich am meisten zu können glaube, ist Visual FoxPro, es verfügt über etwa 1.000 Funktionen und Objekte. Nur einen kleineren Teil davon kann ich direkt aus dem Kopf abrufen, spezielle, selten gebraucht Dinge muß ich nachschlagen (was in der Regel wenige Sekunden dauert). "Kann" ich FoxPro? Spielt der Anteil der auswendig verfügbaren Schlüsselwörter eine Rolle für meine Fähigkeit zur Bewältigung komplexer Aufgaben?

3. Das systemische Umfeld einer Sprache spielt häufig eine wichtige Rolle. Jemand, der im Alltag mit JavaScript umgeht, erlernt Flashs ActionScript in wenigen Stunden. Wenn er die Logik - und Unlogik - der Timelines und der diversen Objektbesonderheiten, die nichts mit der Sprache ActionScript zu tun haben, nicht beherrscht, bringt er mit Flash nichts zustande. Im Bezug auf mein FoxPro-Beispiel von oben ist die Qualität meines Outputs maßgeblich bestimmt durch mein Datenbankdesign und meine SQL-Fähigkeiten; alle Sprachkenntnisse allein wären nutzlos.

Zu dem Thema gibt es noch jede Menge zu sagen (etwa die Betrachtung komplexer Sprachelement wie z.B. die regulären Ausdrücke - wann spricht man da von "Können"?), das soll erst mal reichen - und Arbeit ist auch noch da!

hth Robert

[wahsaga]

hi,

[...] Visual FoxPro, es verfügt über etwa 1.000 Funktionen und Objekte. Nur einen kleineren Teil davon kann ich direkt aus dem Kopf abrufen, spezielle, selten gebraucht Dinge muß ich nachschlagen (was in der Regel wenige Sekunden dauert). "Kann" ich FoxPro? Spielt der Anteil der auswendig verfügbaren Schlüsselwörter eine Rolle für meine Fähigkeit zur Bewältigung komplexer Aufgaben?

von einem arzt erwarte ich auch nicht, dass er mir in komplexeren fällen nach schilderung der symptome immer sofort an den kopf wirft, "sie haben krankheit xy".
im gegenteil, wenn er _nicht_ ab und zu erst mal seinen pschyrembel oder wasweißich zu rate zieht, wäre das vielleicht sogar eher ein grund, an der qualität seiner diagnosen zu zweifeln ...

gruß,
wahsaga

[srob]

Hi,

von einem arzt erwarte ich auch nicht, dass er mir in komplexeren fällen nach schilderung der symptome immer sofort an den kopf wirft, "sie haben krankheit xy".
im gegenteil, wenn er _nicht_ ab und zu erst mal seinen pschyrembel oder wasweißich zu rate zieht, wäre das vielleicht sogar eher ein grund, an der qualität seiner diagnosen zu zweifeln ...

sag ich doch!

hth Robert

[Ludger]

Hi,

ich denke da an Programmierer, die in prozeduralen Sprachen hervorragende Arbeit leisteten und dann OO-Systeme lernten. Schnelle Lernfortschritte. Gute Prüfungsergebnisse. Output in der beruflichen Anwendung: katastrophal;

ich habe die Erfahrung gemacht, dass gute Programmierer, die gerne oder ausschliesslich "prozedural" programmieren, objektorientiert denken. (Und objektorientiert heisst ja letztlich nur Logik zum Manipulieren von Daten speziell, also sagen wir mal objekt- oder entitaetsgebunden, zu verwalten.)

Aber sonst stimmt alles!   ;-)

Gruss,
Ludger

[srob]

Hi,

ich habe die Erfahrung gemacht, dass gute Programmierer, die gerne oder ausschliesslich "prozedural" programmieren, objektorientiert denken.

da sehen meine Erfahrungen anders aus, genau in dem Punkt des "objektorientierten Denkens". Die OO-Paradigmen zu verstehen und hinprogrammieren zu können, ist eine Sache; eine reale Aufgabenstellung objektorientiert erfassen und modellieren zu können eine ganz andere[1]. Und damit bin ich wieder bei Toms Frage nach dem Können - C++ können und in C++ gute objektorientierte Software entwicklen zu können sind sehr verschiedene Dinge, und letzteres läßt sich kaum aus Zertifikaten und Zeugnissen herauslesen.

Aber sonst stimmt alles!   ;-)

Und das von dieser Kanzel - ich fühle mich geadelt!

hth Robert

[1] Und auch bezüglich dieser Fragestellung gibt es keine absoluten Kriterien... Es wird hier im Forum ja auch gelegentlich diskutiert, ob so etwas wie eine reine OO-Implementierung überhaupt denkbar und sinnvoll ist. Da stoße ich dann immer wieder auf Kurt Gödel: "Jedes formale System sprengt seine Axiome." Wie war!

[Ludger]

Hi,

ich habe die Erfahrung gemacht, dass gute Programmierer, die gerne oder ausschliesslich "prozedural" programmieren, objektorientiert denken.
da sehen meine Erfahrungen anders aus, genau in dem Punkt des "objektorientierten Denkens".

immerhin hattest Du am Rande die These aufgestellt, dass es "Programmierer, die in prozeduralen Sprachen hervorragende Arbeit leisteten" gibt. Diese denken also nach Deiner Erfahrung nicht objektorientiert. Nun, was machen die denn dann?

Ich kenne die auch, das sind Entwickler mit Produktwissen (d.h. die kennen bspw. Elemente ihrer Sprache und IDE in und auswendig) und mit wenig konzeptionellem Wissen. Aber sicherlich keine Programmierer, die "hervorragende Arbeit" leisten.

Da stoße ich dann immer wieder auf Kurt Gödel: "Jedes formale System sprengt seine Axiome." Wie war!

Gilt das wirklich auch fuer einfache System?

Gruss,
Ludger

[srob]

Hi,

immerhin hattest Du am Rande die These aufgestellt, dass es "Programmierer, die in prozeduralen Sprachen hervorragende Arbeit leisteten" gibt.

Es handelt sich nicht um eine These, sondern um Empirie.

Diese denken also nach Deiner Erfahrung nicht objektorientiert. Nun, was machen die denn dann?

Sie denken spaghetti. Sie denken tayloristisch.

Ich kenne die auch, das sind Entwickler mit Produktwissen (d.h. die kennen bspw. Elemente ihrer Sprache und IDE in und auswendig) und mit wenig konzeptionellem Wissen. Aber sicherlich keine Programmierer, die "hervorragende Arbeit" leisten.

Mit "prozeduralen Sprachen" meinte ich Sprachen, die keine OO-Konzepte implementieren. Ich bezweifle, daß der Versuch, objektorientierte Lösungsmodelle in derartigen Sprachen umzusetzen, zu optimalen Ergebnissen führt. Nicht-OO-Sprachen implizieren Nicht-OO-Problemanalysen und -Lösungsansätze, und sicherlich lassen sich mit solchen Konzepten gute Antworten auf reale Aufgabenstellungen geben. Und ich habe in meinem Leben einige Menschen kennengelernt, die ich in dieser Umgebung "hervorragende Arbeit" leisten sah. Objektorientierung an sich ist kein Qualitätsmerkmal, ist nicht gut oder besser qua Existenz. Meine Kernthese zu diesem Thema - gestützt durch langjährige Erfahrungen - bleibt: die Nutzung von OO-Systemen führt nicht automatisch zu objektorientierten Lösungsansätzen, und dann ist der Nutzungsvorteil eines solchen Ansatzes zweifelhaft. Um es mit Deinen Worten zu formulieren: viele OO-Entwickler können nicht objektorientiert denken.

Da stoße ich dann immer wieder auf Kurt Gödel: "Jedes formale System sprengt seine Axiome." Wie war!
Gilt das wirklich auch fuer einfache System?

Gödel spricht von "hinreichend mächtigen" Systemen. Ein objektorientiertes Softwaresystem (bzw. das Gesamtsystem Problemanalyse/Lösungsentwicklung/Implementierung) scheint mir von hinreichender Mächtigkeit zu sein. Wenn Du Dich im Informatikstudium (oder auf andere Weise) mit den theoretischen Grundlagen der objektorientierten Softwareentwicklung beschäftigt hast, bist Du sicher auf Unvollständigkeiten und Widersprüche gestossen, die eine vollständige, "reine" objektorientierte Lösung unmöglich machen. Oder Du hast in den entscheidenden Augenblicken geschlafen...

hth Robert

[Ludger]

Hallo Robert,

einerseits widerstrebt es mir natuerlich einem Menschen wie Dir zu widersprechen, aber anderseits werde ich dafuer ja mit Lerneffekten belohnt, also wird es nicht allzu dumm sein es zu tun. Also, nach dieser pflichtschuldigen Vorrede ...

Diese denken also nach Deiner Erfahrung nicht objektorientiert. Nun, was machen die denn dann?

Sie denken spaghetti. Sie denken tayloristisch.

Also, das sind Leute, die ich gerne auf UIs losjage bzw. losjagen wuerde. Allerdings erwarte ich dann dennoch keine "hervorragende" Arbeit.

Mit "prozeduralen Sprachen" meinte ich Sprachen, die keine OO-Konzepte implementieren.

Schon klar. (Vielleicht eine kleine Erklaerung, warum ich Programmierer "prozeduraler" Natur schaetze. Und zwar bin ich vor acht Jahren in eine Firma gekommen, die _ausschliesslich_ COBOL-Software im Einsatz hatte. Der Compiler incl. Maskengenerator hatte seit vermutlich 1985 kein Update erfahren und die Datenhaltung bestand aus Rudeln von Dateien incl. Indexdateien, sog. ISAM-Datenhaltung. Ich fand das anfaenglich sehr uncool bis ich irgendwann feststellte (ich habe aber natuerlich auch einige Uebel festgestellt), dass die ISAM-Datenhaltung eine ordentliche relationale war und die Datenzugriffe gut geschrieben waren und eigentlich alles "irgendwie" objektorientiert war (Ich schreibe "irgendwie", da ich mit der Entitaetenbildung bzw. Erkennung nicht superhappy war), was mir auch der Unternehmenschef, der das alles seit Ende der Siebziger zusammengebastelt hat (und damit gross wurde), durch Aussagen bestaetigte.)

Ich bezweifle, daß der Versuch, objektorientierte Lösungsmodelle in derartigen Sprachen umzusetzen, zu optimalen Ergebnissen führt.

Klar, nicht explizit OOP-faehige Sprachen machens da nicht leicht.

Nicht-OO-Sprachen implizieren Nicht-OO-Problemanalysen und -Lösungsansätze, und sicherlich lassen sich mit solchen Konzepten gute Antworten auf reale Aufgabenstellungen geben.

Erstens glaube ich das mit den Implikationen nicht so ganz und zweitens ist Realitaet ueberhaupt nur mit objektorientierten Vorgehensweisen in IT nachzugiessen.

Um es mit Deinen Worten zu formulieren: viele OO-Entwickler können nicht objektorientiert denken.

Hmm, gefaellt mir.

Gödel spricht von "hinreichend mächtigen" Systemen.

Mich taete interessieren, wann Systeme hinreichend komplex werden um "ihre Axiome" zu sprengen. (Hmm, koennte vielleicht auch ein wenig mit den Axiomen zusammenhaengen, merke ich mal schweinchenschlaumaessig an.) Ist das, aeeh, erforscht?

Gruss,
Ludger

[srob]

Hallo Ludger,

Also, das sind Leute, die ich gerne auf UIs losjage bzw. losjagen wuerde. Allerdings erwarte ich dann dennoch keine "hervorragende" Arbeit.

Verstehe ich nicht - wieso sollte es bei nicht objektorientierten Entwicklungen keine hervorragenden Arbeiten geben? Wenn ich eine Häufigkeitsverteilung der Einzelqualitäten aller Nicht-OO-Entwicklungen erstelle (die vielleicht gaußsch sein wird), so benenne ich eine kleines Segment der Verteilungskurve ganz rechts als "hervorragend".

Nicht-OO-Sprachen implizieren Nicht-OO-Problemanalysen und -Lösungsansätze, und sicherlich lassen sich mit solchen Konzepten gute Antworten auf reale Aufgabenstellungen geben.

Erstens glaube ich das mit den Implikationen nicht so ganz und zweitens ist Realitaet ueberhaupt nur mit objektorientierten Vorgehensweisen in IT nachzugiessen.

Das glaube ich nun wieder nicht. Ich würde eher unterstellen, daß OO-Methoden ihre Vorteile mehr aufseiten des Entwicklers haben, indem sie Zustände und Abläufe der Realität kongruenter auf das Softwaremodell abbilden, die Software besser verständlich und wartbarer, flexibler machen. Aber ganz bestimmt wirst Du praktisch jede Anwendung in Spaghetti (man beachte: ich versuche hier einen Begriff zu prägen!) zu einem performanteren und ressourcenschonenderen Ergebnis bringen können als mit OO-Systemen.

Um es mit Deinen Worten zu formulieren: viele OO-Entwickler können nicht objektorientiert denken.
Hmm, gefaellt mir.

Werden wir uns auf unsere alten Tage noch sympathisch?

Gödel spricht von "hinreichend mächtigen" Systemen.
Mich taete interessieren, wann Systeme hinreichend komplex werden um "ihre Axiome" zu sprengen. (Hmm, koennte vielleicht auch ein wenig mit den Axiomen zusammenhaengen, merke ich mal schweinchenschlaumaessig an.)

Es gibt vordergründig sehr einfache Systeme, die dem Komplexitätskriterium genügen; etwa das Epimenides-Paradoxon "Alle Kreter lügen" oder der Barbier von Korfu, der alle Männer rasiert, die sich nicht selber rasieren[1].

Ist das, aeeh, erforscht?

Da ist wohl schon sehr viel erforscht, aber nichts gelöst... Ich entsinne mich noch sehr gut, als ich meinen mathematisch-physikalischen Lebensgipfel erklommen hatte und zumindest den Anflug eines Gefühls hatte, die Maxwell'schen Gleichungen verstanden zu haben. Es dauerte nicht lange, bis ich auf eine Arbeit stieß, die für mich nachvollziehbar und unwiderlegbar darlegte, wie man mit mathematisch und physikalisch zulässigen Umformungen und Einsetzungen der vier Gleichungen auf ein Ergebnis à la "1 = 0" kommt. Da geriet etwas ins Wanken! Ich finde leider nicht mehr den Link zur Darstellung einer derartigen Rechnung. Ein glühender Anfechter der Widerspruchsfreiheit mathematisch-physikalischer Axiomensysteme ist der Münchner Ekkehard Friebe: http://www.ekkehard-friebe.de/Goedel94.htm.

In dem Zusammenhang immer wieder bewustseinserweiternd ist Hofstadters "Gödel, Escher, Bach", ebenso wie die Beschäftigung mit dem Scheitern von Bertrand Russells Lebenswerk und viele Arbeiten von Roger Penrose.

hth Robert

[1] Wer rasiert den Barbier?

[Ludger]

Hallo Robert,

Erstens glaube ich das mit den Implikationen nicht so ganz und zweitens ist Realitaet ueberhaupt nur mit objektorientierten Vorgehensweisen in IT nachzugiessen.

Das glaube ich nun wieder nicht. Ich würde eher unterstellen, daß OO-Methoden ihre Vorteile mehr aufseiten des Entwicklers haben, indem sie Zustände und Abläufe der Realität kongruenter auf das Softwaremodell abbilden, die Software besser verständlich und wartbarer, flexibler machen.

nur noch was zu diesem Punkt. Software bildet geschaeftslogisch relevante Sachverhalte der Realitaet ab (und ggf. Sachverhalte, die geschaeftslogisch relevant werden koennen), die Realitaet wird von den Menschen objektorientiert aufgenommen, die Folge sind immer objektorientierte Programme. So einfach ist da.   ;-)

Allerdings - um die Sache doch etwas komplizierter zu machen - steht die Nachbildung der Realitaet in der Realitaet selbst (was noch nicht so schlimm ist) und bestimmte Objekte gibt es irgendwann nur noch im IT-System. Das "System" wird somit empfundener Teil der Realitaet (vielleicht darf man auch "empfunden" weglassen?).

Kurzum, der (auch weiter oben angefuehrte) "geniale Progger" muss immer ein objektorientiertes Verstaendnis haben um Sachverhalte (wie der Name schon sagt) in IT nachgiessen zu koennen.

Gruss,
Ludger

[Tom]

Hello,

Mit "prozeduralen Sprachen" meinte ich Sprachen, die keine OO-Konzepte implementieren. Ich bezweifle, daß der Versuch, objektorientierte Lösungsmodelle in derartigen Sprachen umzusetzen, zu optimalen Ergebnissen führt.

OO habe ich schon 1981 unter Assembler programmiert.
Das nannte man damals nur noch nicht so und es war auch müßig, da es weder grafische Tools noch sonst irgendeine Unterstützung für die Auswahl und Kontrolle der Strukturen gab.
Aber ich denke, aus genau den Ideen die ich da hatte haben andere (aus ihren Ideen natürlich) die objektorientierte Programmierung entwickelt.

Irgendwo habe ich auch das Demo-Programm für die Ideen sicher noch.

Es sollte eine Kreuzung mit einer komplexen Ampelanlage abgebildet werden, über die verschiedene Fahrzeuge, Fußgänger, Bälle etc führen, gingen, trudelten. Jedem Objekt konnte sein Verhalten eingeprägt werden.

Das geilste war dann, dass mein Lernpartner und ich den Teilen auch noch Sounds beigebracht haben.
Da war mit den damilgen Mitteln der PIC-Programmierung (Soundkarten gab es ja noch nicht) wirklich nicht leicht. Das ging solange, bis der Prof (FH) dann sagte "also OK, wenn Sie diesen Lärm endlich abstellen, bekommen Sie beide eine Eins. Wenn es aber nicht mit einem einzigen Eingriff in Ihr Programm klappt, bekommen Sie einen Fünf, weil Sie so angegeben haben"
Wir haben unsere Eins bekommen!

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Ludger]

Hi,

Es sollte eine Kreuzung mit einer komplexen Ampelanlage abgebildet werden, über die verschiedene Fahrzeuge, Fußgänger, Bälle etc führen, gingen, trudelten. Jedem Objekt konnte sein Verhalten eingeprägt werden.

Du hast also Frogger programmiert??

Gruss,
Ludger

[ute]

hi tom,

na du musst wohl jedenfalls noch etwas üben

http://www.sankt-andreasberg.com/cgi-bin/veran-zeitraum.pl?tag=02 &monat=02 &jahr=2005 &bistag=31&bismonat=02 &bisjahr=2005

und dann noch einen schönen 31sten februar

wünscht dir ute
(heute bei chris)

[Tom]

Hello Ute,

mal wieder im Lande?

na du musst wohl jedenfalls noch etwas üben

Wie kommst Du darauf?

http://www.sankt-andreasberg.com/cgi-bin/veran-zeitraum.pl?tag=02 &monat=02 &jahr=2005 &bistag=31&bismonat=02 &bisjahr=2005

Schau doch mal in den DENIC. Die Seite ist nicht von mir. Da müsste ich mich ja schämen.
Und dass nicht gut genug PERL für produktive Anwendungen kann, habe ich ja schon gesagt.
Aber da scheint es ja auch noch andere zu geben *grins*

und dann noch einen schönen 31sten februar

Den werde ich haben, denke ich. Ich habe jedenfalls köstlich übe Deinen Link gelacht.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Eternius]

Hallo Tim,

Und dass nicht gut genug PERL für produktive Anwendungen kann, habe ich ja

1.12: What's the difference between "perl" and "Perl"?

One bit. Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to
signify the language proper and "perl" the implementation of it, i.e.
the current interpreter. Hence Tom's quip that "Nothing but perl can
parse Perl." You may or may not choose to follow this usage. For
example, parallelism means "awk and perl" and "Python and Perl" look OK,
while "awk and Perl" and "Python and perl" do not. But never write
"PERL", because perl is not an acronym, apocryphal folklore and
post-facto expansions notwithstanding.

http://faq.perl.org/perlfaq1.html#What_s_the_differenc

gruss

[Fabian Transchel]

Hi,

ich habe ein paar Einschätzungen abzugeben, wie lange man in der Praxis braucht, um eine Programmiersprache oder auch den Umgang mit einem komplexeren Programm für den realen Broterwerb zu erlernen.

Mir klingt da immer der Satz im Ohr "...ich kann mich ziemlich schnell in neue Programme einarbeiten ..."

Jepp. Wer soetwas sagt, der hat meistens die Realita der IT nicht begriffen. Wenn hingegen verlautet wird, dass "man" sich in neuen Interfaces schnell zurechtfindet, dann ist das was anderes. Das geht mir Trial'n'Error viel besser als bei "Programmen".

Die Seminare, die ich damals in Unkenntnis der Wirklichkeit an solche Leute vergeben habe, sind dann aber meistens in die Hose gegangen. Mit Programmiersprachen (selbst mit HTML) wird es wohl änlich aussehen, oder?

Ich denke, obwohl ich das meiner geringen Erfahrungen damit besser ließe, ja.

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

• C

Ceh? Muss ich mal machen, ja. Es reicht um Patches in Sourcen manuell einspielen zu können, wenn mal eine Linux-Box Totalschaden hat.

• C++

Das hab ich mir vorgenommen. Ich hab einfach keine Zeit für sowas ^-^
Hab im Selbststudium von KDE-Sourcen auch schon Hello World gepackt.
Ich glaube hier hängt viel daran, dass ich mal wirklich den Bedarf zu einem kleinen, nichtexistenten ergonomischen Tool brauche, das man eben am besten selbst schreibt.

• Perl

Naja, lesen geht, schreiben eher ungern.

• PHP

3 Wochen. Das waren die witzigsten Osterferien meines Lebens. Das resultierte "Gästebuch"[1] ist heute noch im Giftschrank.

[1] Daran habe ich ausnahmslos alle PHP 4.0.2-Funktionen ausprobiert die es gab. Mit dem Ergebnis, das die Ausgabe eines Administrations-Input-Feld länger berechnet wird als ein Half-Life²-Frame.

• Java

Bis jetzt zweieinhalb Jahre. Das liegt aber daran, dass wir in der Schule immer nur das gelernt haben, was grade zur Lösung führt, und nicht das, was zum besten Algorithmus führt. Und seit dem Ende des Informatikkurses hatte ich keine Not, etwas anderes damit zu machen.

Grüße aus Barsinghausen,
Fabian

[Michael der Zweite]

Hallo

Es ist sehr schwierig, eine wirkliche Zeitangabe abzugeben, da man oftmals eine Programmiersprache nicht in einem Zug lernt, immer wieder damit in Kontakt kommt und dann - Learning-by-Doing - die Sprache immer bessr kann. Typisches Beispiel hier sind vielleicht die Websprachen: Man hat mal die Idee, eine Webseite zu machen, lernt ein bisschen HTML. Eines Tages sieht man per Zufall, dass es da so etwas wie Javascript gibt, womit man lustige Effekte basteln kann. Man lernt ein bisschen JS, vielleicht nur zum Anpassen eines Skripts. Später kommt vielleicht der Wunsch dazu, eine Abstimmung zu basteln. Der Kollege meint, man solle vielleicht mit PHP etwas versuchen, er habe ein Skript dafür... etc. Was ich damit Aussagen will: Wenn man sich mit der Materie befasst, lernt man nicht einfach Programmiersprache X mit Buch "Jetzt lerne ich X".

Am geradlinigsten habe ich Java gelernt. Da ich vorhin schon die Grundzüge des Programmierens kannte, habe ich mir die Grundzüge mal eben an einem Wochenende beigebracht. Ich konnte dann Variabeln, Schleifen, Arrays, Objekte etc. erstellen. Bald schon kamen auch AWT, IO und Multithreading etc. dazu. Ich hatte mir die Sprache also in höchstens einem Monat beigebracht. Bis ich aber all die Konzepte umfassend verstand und Java wirklich schnell und effizient nutzen konnte, verging nochmals ein gutes Jahr. Und noch heute entdecke ich laufend neue Sachen. Zusamenfassend sage ich: 3 Jahre für einen angefressenen Hobby-Programmierer, für den Java die 1. Programmiersprache ist.

Gruss

Michael

[Thomas J.S.]

Hallo,

Wie sind Eure persönlichen Erinnerungen, wie lange ihr gebarucht habt, um mit der Sprache wirklich vertraut zu sein?

• C
• C++
• ...
• Perl
• PHP
• ..

Ist XSL eine Programmiersprache? Programmiert man im XSL?

Grüße
Thomas

[Tom]

Hello,

Ist XSL eine Programmiersprache? Programmiert man im XSL?

Das ist mir in diesem Falle egal. Codieren musst Du auf jeden Fall und dazu muss man auch die Auswirkungen kennen. Macht man das noch "zu Fuß?" Ist doch bei HTML die gleiche Frage.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Thomas J.S.]

Hallo,

Ist XSL eine Programmiersprache? Programmiert man im XSL?

Das ist mir in diesem Falle egal. Codieren musst Du auf jeden Fall und dazu muss man auch die Auswirkungen kennen. Macht man das noch "zu Fuß?" Ist doch bei HTML die gleiche Frage.

Es kann so gesehen bei jeder Sprache gefragt werden ob man es noch "zu Fuß" macht oder Tools verwendet. ;-)
Bei HTML ist es leicht, denn  (die Elemente können wir jetzt beiseite lassen), die Möglichkeiten bei Attributen sind begrenzt.
Für XSL habe ich noch keinen Tool gesehen der selbstständig komplexe Abfragen zusammenstellen kann, also mache ich das Codieren "zu Fuß" ;-).

Der Knakpunt in meinen Augen ist, dass man eigentlich in (fast?) jeder Sprache schnell erste, kleinere Erfolge haben kann, aber wenn man den Umfang der Sprache nicht kennt, kommt man auch sehr schnell an die eigene Grenzen. (Wenn man nicht weiss, dass es diese oder jene Funktion etc. gibt und wofür sie gut ist, wird man auch nicht daran denken diese für die Lösung eines Problems einsetzen zu wollen.)

Das geht also in die Richtung deines Funktionen-Quiz.
So gesehen, brauchte ich für XSL/T grob geschätzt so um 3/4 bis ein Jahr herum, inkl. schnuppern, experimentieren bis dann zum täglichen Arbeit damit.
Und trotzdem lernt man nie aus ;-)

Grüße
Thomas

[Tom]

Hello,

Das geht also in die Richtung deines Funktionen-Quiz.
So gesehen, brauchte ich für XSL/T grob geschätzt so um 3/4 bis ein Jahr herum, inkl. schnuppern, experimentieren bis dann zum täglichen Arbeit damit.

Das werde ich also mal für die wesentlichen Anforderungsprofile definieren.

Allerdings funktioniert das "Funktionen-Quiz" nur bis zu den imperativen oder funktionalen Sprachen gut. Bei Objektorientierten Sprachen kommt die nächste Verstehensschicht dazu. Man muss schließlich auch erstmal akzeptieren lernen, dass man sich immer innerhalb des Objektmodells zu bewegen hat und jede auch unsinnige Sortierung/Hierarchisierung des Modells akzeptieren muss.

Das war wohl das, was mich in Pascal/embedded Assembler so begeistert hat. Es war alles enorm sauber soriert und wenn einem eine Lösung nicht gepasst hat, hat man eben ein eigenes Modul (immer nur auf ein OS bezogen) eingesetzt.

Als ich meine "Fensterverwaltung mit Shared Memory für DOS-Systeme" fast fertig hatte, kam Windows auf den Markt und alle haben gerufen "es lohnt sich nicht mehr, das fertig zu machen". Es hätte sich noch ca. sechs Jahre gelohnt.

Und trotzdem lernt man nie aus ;-)

Das ist unbestritten, zumindest von mir!

Wenn also jetzt ein "Mediengestalter" mit einem schönen neuen Auto vorfährt und mir erzählt, dass er eher grafisch talentiert ist, aber naturlich auch Webprogrammierung kann, dann lege ich ihm das "Funktionenquiz" für PHP vor. Nur was mache ich bei PERL, Python, ColdFusion, ...?

Das kann ich ja selber nicht, um "Prüfungsaufgaben" zu definieren.

Und wenn nun ein "CK" kommt, der auch ins innere der Module geschaut hat, wie lange kann ich da mithalten? Schließlich gibt er auch irgendwann auf (oder muckelt), aber wirklich beweisen kann ich das nicht. Denn Sein Wissen ist garantiert besser als meins, nur kann (und will) er es eben dann genau in diesem Moment nicht zugeben, dass er da auch noch nicht so genau Bescheid weiß...

[Ich hoffe nur, dass ich ihm jetzt nicht wieder auf den Fuß getreten habe]

Wichtig für mich ist dabei: Wie kann ich den Bewerber wirklich beurteilen, ohne ihm Unrecht zu tun? Vielleicht fallen tatsächlich auch sehr viele Sozialkompetenzen in die Bewertung? Was nützt mir ein Mitarbeiter, der zwar sehr viel weiß, aber zu arrognat ist, es für das geminsame Wohl einzusetzen?

Und nun soll ich dieses Urteil auch noch im Namen und zum Wohle eines Dritten sprechen...

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Thomas J.S.]

Hallo,

Allerdings funktioniert das "Funktionen-Quiz" nur bis zu den imperativen oder funktionalen Sprachen gut.

XSL ist aber eine deklarative Sprache ;-)

»»Bei Objektorientierten Sprachen kommt die nächste Verstehensschicht dazu. Man muss schließlich auch erstmal akzeptieren lernen, dass man sich immer innerhalb des Objektmodells zu bewegen hat und jede auch unsinnige Sortierung/Hierarchisierung des Modells akzeptieren muss.

Das ist z.B für viele Programmierer bei XML/XSL eine echte Hürde, weil man sich bei XML/XSL immer in einer Baumstruktur befindet. Typische vom "Programmieren-Denken" gewohte Frage: "wie mache ich eine for-Schleife mit XSL?".

Das war wohl das, was mich in Pascal/embedded Assembler so begeistert hat. Es war alles enorm sauber soriert [...]

Das mag ich bei XSL besonders. ;-)

Wichtig für mich ist dabei: Wie kann ich den Bewerber wirklich beurteilen, ohne ihm Unrecht zu tun? Vielleicht fallen tatsächlich auch sehr viele Sozialkompetenzen in die Bewertung? Was nützt mir ein Mitarbeiter, der zwar sehr viel weiß, aber zu arrognat ist, es für das geminsame Wohl einzusetzen?

Und nun soll ich dieses Urteil auch noch im Namen und zum Wohle eines Dritten sprechen...

Ich habe einmal einen Fragebogen für Bewerber im XML bereich zusammengestellt, es gab darin zwei oder drei echt "miese" Fragen, da konnten wir z.B sehen wie weit die praktische Erfahrung mit der Materie vom theoretischen Wissen über dieselbe entfernt ist, aber man kann die sozialen Komponenten und Kompetenzen nicht oder kaum bei einer Bewerbungschreiben bzw. bei einem Bewerbungsgespräch wirklich ausreichend beurteilen (oder du brauchst wirklich sehr gute Menschenkenntnisse).

Grüße
Thomas

[Ludger]

Hi,

Ist XSL eine Programmiersprache? Programmiert man im XSL?

Mr.Check wuerde "ja" sagen, oder?
http://app.mr-check.de/a31db05310e9661a316a6a618b708208/v2.0/Mrcheck.php?CID=tanto1&SB=Programmiersprache

(Ich jedenfalls wuerde "ja" sagen, trotz "SL" oder "SLT". Es hoert sich doch auch solid an XML-validen Programmcode zu erzeugen und diesen ggf. gegen ein Schema zu parsen.)

Gruss,
Ludger

[Thomas J.S.]

Hallo,

Ist XSL eine Programmiersprache? Programmiert man im XSL?

Mr.Check wuerde "ja" sagen, oder?
http://app.mr-check.de/a31db05310e9661a316a6a618b708208/v2.0/Mrcheck.php?CID=tanto1&SB=Programmiersprache

(Ich jedenfalls wuerde "ja" sagen, trotz "SL" oder "SLT". Es hoert sich doch auch solid an XML-validen Programmcode zu erzeugen und diesen ggf. gegen ein Schema zu parsen.)

M.m.n ist es bei XSLT weniger die (XML-) Validität des Codes - das ist recht leicht - worauf es ankommt, sondern eher der Einsat der XSLT/XPath funktionen und vor allem ein Verständnis für eine bestimmte Art von Logik. D.h die formalen Anforderugen einer Sprache hat man bald darauf, was nachher kommt ist das Spannede ;-)

Grüße
Thomas

[Thomas Meinike]

Hallo,

Ist XSL eine Programmiersprache? Programmiert man im XSL?

Aus dieser Sicht schon: Turing-Vollständigkeit von XSLT (PDF).

MfG, Thomas

[Thomas J.S.]

Hallo Thomas,

Ist XSL eine Programmiersprache? Programmiert man im XSL?

Aus dieser Sicht schon: Turing-Vollständigkeit von XSLT (PDF).

Mist! Dann bin ich ein Programmierer!
Und ich versuche seit Jahren das zu leugnen ;-)

Grüße
Thomas

[Chräcker Heller]

Hallo,

das kann man (wie ja auch schon aus den anderen postings zu lesen) "eben" nicht sagen.

Beispiel: nachdem ich ein PHP-für-doofe Buch aus dem RoRoRo-verlag (aber gar nicht sooo schlecht) auf dem Klo durchgeblättert habe, war ich der Meinung, das ich jede x-beliebige Aufgabe in den Grundzügen innerhalb eines konzentreirten Nachmittages lösen könne. (Vorausgesetzt, die Tipparbeit übersteigt nicht die Zeit) - Dieser Meinung bin ich heute nach ein paar Wochen immer noch ;-) (Ich muß nur die Aufgabe selber verstehen ;-))))

Dabei muß man aber (um mich weiter als Beispiel anzuführen) mit einfliessen lassen, das die Resultate weder "elegant" noch in der Nutzung der Sprachelemente immer "zeitgemäß" (und damit auch nicht immer "sicher") ist. Dazu fehlt dann eben die Erfahrung.

Also "kann ich es" oder eben doch nicht? Und wenn "doch nicht", ab wann könnte ich es?

Ich weiß ja noch nicht mal, ob ich JavaScript kann. Ich sag ja "nein", Elya hat mich dann mal "eitel" beschimpft. (Was grundsätzlich allerdings immer bei mir past....)

Zweiter Punkt beim PHP-Beispiel: ich habe  PHP nur deswegen so schnell "überblickt", weil ich seit ca 20 Jahren mich mit "Deppen"-Programmiersprachen beschäftige. (Vom VC-20 Basic über GFA-Basic über das wundervolle AMOS-Basic zu Visual-Basic, sowie diverse Script und Makrosprachen zwischen dBase-2 und Amipro...) - Also habe ich 20 Jahre gebraucht, um PHP zu lernen.

--

Java wiederum habe ich auch nach drei Monaten programmierei trotz Ergebnisse auch im Ansatz nicht begriffen. (bzw: gerade den Ansatz habe ich nie begriffen...) So schätze ich mich auch bei Programmen ein. Die Handelsüblichen Programme würde ich alle schnell "handhaben" können, so das man mich schnell damit alleine "spielen" lassen könnte. (Richtig gut kann man komplexere Programme ja erst nach Monaten bis Jahren beherschen....) - Wenn es um komplexere Datenbanksysteme (zBsp.) gehen würde (da bin ich bei dBase-2 stehen geblieben) oder um die ganzen mystischen Serversachen, die mich CK gegenüber immer erschauern lassen, bräuchte es vielleicht ein paar Seminarstunden mehr... Wie jemand schon schrieb: nicht die bedienung macht die meisten Schwierigkeiten, sondern die mit einem Programm zu bewältigenden Aufgaben muß man verstehen....

Fazit: man kann es einfach nicht pauschal sagen.

Chräcker

[Elya]

Hallo Chräcker,

Ich weiß ja noch nicht mal, ob ich JavaScript kann. Ich sag ja "nein", Elya hat mich dann mal "eitel" beschimpft.

Ich fahr nie nie wieder acht Stunden mit Dir im Auto, wenn Du noch nach Monaten jedes Wort meiner Dauerbetextung so auf die Goldwaage legst, nie nicht wieder! (Womöglich ist das aber gar keine Drohung für Dich... ;-))

Gruß aus Köln-Ehrenfeld,

Elya

[Chräcker Heller]

Hallo,

wenn Du noch nach Monaten

es war auf der Ausweichstrecke (wegen der Autobahnsperrung), rechts war hinter einem Mäuerchen ein Bach, links ein Waldhang, kurz danach überquerten wir den Bach um ihn dann links liegen zu lassen, die Uhr zeigte.... usw usw - Du siehst, wenn man wie ich sonst nichts im Kopf hat ;-)

(Womöglich ist das aber gar keine Drohung für Dich... ;-))

Ne, weil ich nie nicht doppelte Verneinungen kenne. (Genaugenommen war das bei Dir eine vierfache Verneinung ;-))))

bis hoffentlich nicht erst bei der nächsten Autofahrt...

Chräcker

[Elya]

Hallo Chräcker,

es war auf der Ausweichstrecke (wegen der Autobahnsperrung), rechts war hinter einem Mäuerchen ein Bach, links ein Waldhang,

und wir standen gerade vor einer Baustellenampel ;-)

bis hoffentlich nicht erst bei der nächsten Autofahrt...

Stimmt, es steht noch ein Frühstück in Köln aus!

Gruß aus Köln-Ehrenfeld,

Elya

[dedlfix]

• ..

Brainfuck kann man ziemlich schnell lernen. Es besteht aus genau 8 Befehlen, und jeder Befehl praktischerweise aus einem Zeichen. Somit sind die Quelltexte auch recht kompakt.

Ich hab's jedoch nie angefangen, da es verständlicherweise keine umfangreiche Funktionsbibliothek gibt. Außerdem ist es leichter ein Brainfuck-Programm neu zu schreiben als ein bestehendes zu lesen.

Noch etwas schwerer zu lesen ist Whitespace.

:-)

[Tom]

Hello,

Brainfuck kann man ziemlich schnell lernen. Es besteht aus genau 8 Befehlen, und jeder Befehl praktischerweise aus einem Zeichen. Somit sind die Quelltexte auch recht kompakt.

Intersssante Sache. Aber als "Sprache" würde ich das nicht bezeichnen, noch nicht einmal als Mnemonischen Code. Es sind einfach Befehle, die angereiht sicher ganz spannende Ergebnisse erzeugen können. Genauso würde ich die "Kurzschreibweise" von C nicht mehr als (Hoch-)Sprache bezeichnen.

Das liebe ich an Pascal bis heute. Die verwendeten Bezeichner sind (selbst für Englisch-Laien) leicht merkbar und führen selten zu Missverständnissen.

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

n'Abend,

Genauso würde ich die "Kurzschreibweise" von C nicht mehr als (Hoch-)Sprache bezeichnen.

Kurzschreibweise von C?
Was darf ich mir darunter vorstellen?
Klär uns bitte auf...

Martin

[Tom]

Hello,

Genauso würde ich die "Kurzschreibweise" von C nicht mehr als (Hoch-)Sprache bezeichnen.

Kurzschreibweise von C?

Wie würdest Du denn z.B.

$a = $a + 1;          ( oder eben  a = a + 1; )

kürzer schreiben?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Der Martin]

Moin!

Wie würdest Du denn z.B.

$a = $a + 1;          ( oder eben  a = a + 1; )

kürzer schreiben?

Ach, du redest von diesen praktischen Dingen!
Dann hab ich dich missverstanden. Der Increment- oder Decrement-Operator ist ja, genauso wie die zusammengesetzten Operatoren += und seine Verwandten, ganz normales, reguläres C.

Aber solche Kleinigkeiten, also dass man elementare Operationen auch einfach formulieren kann, machen C doch so verdammt effizient und mächtig. Ich finde übrigens auch, dass z.B.
 k -= 3;
den Gedanken hinter der Anweisung klarer rüberbringt als
 k = k-3;
in der konventionellen langen Form, auch wenn es bei diesem einfachen Beispiel nicht so deutlich auffällt.
Aber das ist wahrscheinlich auch zum großen Teil Gewohnheitssache.

Schönes Wochenende,

Martin

[Tom]

Hello,

$a = $a + 1;          ( oder eben  a = a + 1; )

kürzer schreiben?

Ach, du redest von diesen praktischen Dingen!

Es gibt aber auch echt chaotische Konstruktionen, die ein Programm dann schwer lesbar machen.

Und wieviele scheitern schon am Unterschied zwischen ++i und i++ (vereinfacht ausgedrückt).

Harzliche Grüße aus http://www.annerschbarrich.de

Tom

[Mathias Bigge]

Hi Tom,

als unechter Progger habe ich mich vor Jahren ernsthaft und länger mit zwei Programmiersprachen beschäftigt, mit Turbo-Pascal und Clipper, einer damals ziemlich effizienten Datenbanksprache. Seitdem habe ich immer mal wieder kleinere Projekte hingeschustert in diversen Sprachen, vor Jahren mit einem CA-Tool zur Entwicklung von Windows-Oberflächen für SQL, mit Perl und JS z.B. Um richtig Geld damit zu verdienen, bin ich zu schlecht, vor allem zu langsam. Gott sei Dank habe ich eh fast alles vergessen....

Als Seiteneinsteiger habe ich meine Möglichkeiten und Grenzen erkennen gelernt:

• Viele Proggerprobleme sind eher mathematischer Natur oder erfordern die Kenntnis spezieller Verfahren und Algorithmen, die mit der konkreten Programmiersprache wenig zu tun haben. Daher sind Seiteneinsteigern Grenzen gesetzt.

• Wirklich flüssig und effektiv mit einer Sprache umzugehen, habe ich nur durch den Druck konkreter größerer Projekte gelernt, nie durch Trockenschwimmen.

• Programmieren ist in einigen Aspekten schwerer geworden, in vielen anderen leichter. Mit Access ein Userinterface hinzuhauen, dauert ein paar Minuten, während etwas Vergleichbares früher eine Sauarbeit war.

• Die Maschinen haben heute ausreichend Reserven, dass man auch mit ineffektiven Methoden zum Ziel kommen kann, was früher herrlich scheiterte.

• In einigen grafischen Entwicklungsumgebungen bewegt man sich auf dünnem Eis. Blitzschnell hat man sich ein paar Fenster und Elemente zusammenklickt und dabei, ohne nachzudenken, pfundweise Code generiert. Wenn man dann wirklich in die Feinheiten eingreifen will, steht man plötzlich vor einem Wust an Komplexität.

• Wirkliche Progger müssen endlose Stunden vor der Kiste hocken und allem anderen den Rücken kehren, zahlen also einen recht hohen Preis. Überhaupt ist Proggertätigkeit oft - für mich - langweilig, wenn das Grundkonzept steht, und man nur noch die harte Fummelarbeit leisten muss, um das Ganze zu realisieren.

• Bei der Fehlersuche braucht man manchmal eine schier unglaubliche Geduld und Hartnäckigkeit.

• Die User haben immer was zu meckern oder finden Möglichkeiten, Fehler zu machen, die man kaum für möglich hält.

• Ab einer gewissen Projektgröße ist kontinuierliche Arbeit erforderlich, um den Überblick zu behalten, wenn man nicht extrem systematisch und genau arbeitet. Nach längeren Pausen bereut man meist jede fehlende Ordnung und vor allem vernünftig gewählte Bezeichnungen, gute Kommentare und grafische Darstellung der Zusammenhänge.

Viele Grüße
Mathias Bigge

[Ludger]

Hi,

als unechter Progger habe ich mich [...]
Als Seiteneinsteiger habe ich meine Möglichkeiten und Grenzen erkennen gelernt:

• Ab einer gewissen Projektgröße ist kontinuierliche Arbeit erforderlich, um den Überblick zu behalten, [...]

ich halte uebrigens auch Leute wie bspw. den Franz Muentefering fuer geeignet Softwareprojekte erfolgreich zu leiten.

Man muss halt nur verstehen, um was es geht.   ;-)

Gerade Seiteneinsteiger haetten da eigentlich gewisse Vorteile, oder? Haengt allerdings mit dem Grad der Verglatzung zusammen.  ;-)

Und IT ist zu einem Grossteil Organisation.

Gruss,
Ludger

[Mathias Bigge]

Hi Ludger,

ich halte uebrigens auch Leute wie bspw. den Franz Muentefering fuer geeignet Softwareprojekte erfolgreich zu leiten.
Man muss halt nur verstehen, um was es geht.   ;-)

Das ist ja in fast allen unternehmerischen Leitungsfunktionen der Fall, ob selbständig oder im Betrieb.

Gerade Seiteneinsteiger haetten da eigentlich gewisse Vorteile, oder? Haengt allerdings mit dem Grad der Verglatzung zusammen.  ;-)

Es ist ganz interessant, welche Vor- und Nachteile "Seiteneinsteiger" - die Definition ist für mich teilweise unklar - mitbringen. Ich sehe das umgekehrt im Bildungsbereich, wo immer häufiger Naturwissenschaftler und Ingenieure als Seiteneinsteiger eingesetzt werden - und oft scheitern, obwohl sie natürlich etwas mitbringen, nämlich konkrete Arbeitserfahrung und fundiertes Praxiswissen. Um konkret Möglichkeiten und Grenzen zu beurteilen, müsste man genauer definieren, welche Kenntnisse, Eigenschaften und Weiterbildung erforderlich sind, damit ein Seiteneinstieg zum Erfolg wird.

Und IT ist zu einem Grossteil Organisation.

Ich würde Dir zustimmen, dass Planung und Organisation wesentliche Aspekte sind, man braucht aber auch "geniale" Progger, die die konkreten Schwierigkeiten bewältigen, und Kaufleute mit IT-Kenntnissen, um realistische Kalkulationen zu erarbeiten, etwas, das im IT-Bereich meiner Erfahrung nach besonders schwierig ist. Oft wird der Zeitaufwand unterschätzt, teilweise natürlich bewusst, um ein konkurrenzfähiges Angebot unterbreiten zu können.

Viele Grüße
Mathias Bigge

[Ludger]

Hi,

Und IT ist zu einem Grossteil Organisation.
Ich würde Dir zustimmen, dass Planung und Organisation wesentliche Aspekte sind, man braucht aber auch "geniale" Progger, die die konkreten Schwierigkeiten bewältigen,

Vorsicht vor genialen Proggern!   :-)

Gruss,
Ludger

[LanX]

Hi

Grundsätzlich hängt es davon ab wieviele man schon beherscht und wie intensiv man sie nutzen muss.

Und es kommt auf die Sprache an:

68000er Assembler hatte ich mir in 3 Tagen angetan und am Ende der Woche ein Modul abgeliefert das auch gleich in die Distribution kam.

Warum so schnell?

1. Vorkenntnisse: Schon als 13 Jähriger hatte ich nen Volkshochschulkurs zum  6502 Assembler besucht, da war der C64 noch nicht mal raus und die viele Leute schrieben Komputer noch mit K. Und der Motorolacode war im Vergleich zu dem alten Hack so eine komfortable Hochsprache, das ging flüssig. (vor dem Intelassembler wiederum gruselts mir immer noch)

2. Druck: Die Atarimesse stand an und es musste noch ganz schnell ein Grafikformat unterstützt werden, damit man auch exportieren und drucken konnte. Da schläft man nur 4h pro Nacht und debugt den Code auch mal telefonisch.

Nun das andere Extrem:

Ich arbeite seit 5 Jahren sporadisch mit Perl und kann es eigentlich immer noch nicht! Ich meine die Programme laufen und es sind schon tausende Zeilen, aber der Code ist nach kurzem Wegschauen bereits sooo grausam, da kann jmd die Sprache nicht gut beherscht haben... ;)

Und kaum hab ich ne Runde Javascript gehackt, versuche ich wieder Strings mit + zu verbinden... oder etwas bash
 gescriptet und wieder vergisst man die ;

Tschau
  rolf

[Ludger]

Hi,

2. Druck: Die Atarimesse stand an und es musste noch ganz schnell ein Grafikformat unterstützt werden, damit man auch exportieren und drucken konnte. Da schläft man nur 4h pro Nacht und debugt den Code auch mal telefonisch.

soso. Du bist doch Mathematiker und muesstest eigentlich wissen, um was es geht beim Programmieren und so.

Ich arbeite seit 5 Jahren sporadisch mit Perl und kann es eigentlich immer noch nicht! Ich meine die Programme laufen und es sind schon tausende Zeilen, aber der Code ist nach kurzem Wegschauen bereits sooo grausam, da kann jmd die Sprache nicht gut beherscht haben... ;)

Ja, gbts einen besonderen Grund dafuer?

Software entwickeln ist eine ingenieursmaessig zu vollrichtende Taetigkeit, stimmts?

Gruss,
Ludger

[lanx²]

Hi,

soso. Du bist doch Mathematiker und muesstest eigentlich wissen, um was es geht beim Programmieren und so.

Hä, wieso???

...im übrigen war ich im 2. Semester kaum fertiger Mathematiker!

Ja, gbts einen besonderen Grund dafuer?

klar _Perl_! >:)

Software entwickeln ist eine ingenieursmaessig zu vollrichtende Taetigkeit, stimmts?

grosse projekte ja, algorithmen nein!

tschau
  rolf

[Ludger]

Hi,

Software entwickeln ist eine ingenieursmaessig zu vollrichtende Taetigkeit, stimmts?

grosse projekte ja, algorithmen nein!

na, und wie werden Algorythmen entwickelt?

Gruss,
Ludger

[lanx²]

Hi,

Software entwickeln ist eine ingenieursmaessig zu vollrichtende Taetigkeit, stimmts?

grosse projekte ja, algorithmen nein!

na, und wie werden Algorythmen entwickelt?

na, wenn man das in wenige Worten fassen könnte, dann könnten es die Ingenieure ja auch ;)

Definiere bitte "ingenieursmaessig zu vollrichtende Taetigkeit"

ciao
 rolf