Programmieren lernen, bzw. reinschnuppern

[kuddlmuddl]

https://www.codewars.com/
finde ich besser als Proj Euler für Leute, die Programmieren lernen/mögen. Es legt den Fokus mehr aufs Programmieren und weniger auf die Mathematik.

 

[andy_m4]

https://www.codewars.com/

Macht einen netten Eindruck.
Leider kann man die Aufgaben nicht einfach mal querlesen um sich einen Eindruck zu verschaffen. Man muss sich zunächst anmelden.

 

[sh.]

aus aktuellem Anlass, was haltet ihr von Ruby und seinem Framework Ruby on Rails? Die Syntax finde ich mal mega genial

Irgendwie kommt mir Ruby wie ein Underdog vor aber irgendwie wird immer davon geschwärmt. Wie sind eure Erfahrungen mit Ruby? Falls es welche gibt.

 

[###Zaunpfahl###]

@sh. soweit ich mir da Wikipedia ein bisschen angeguckt hab würde ich behaupten das das für Anfänger auch ziemlich gut geeignet ist um einfach reinzukommen und Ergebnisse zu bekommen.
Das kleine Problem mit den nicht Mainstream Sprachen ist das es von allem weniger gibt.

 

[andy_m4]

aus aktuellem Anlass, was haltet ihr von Ruby und seinem Framework Ruby on Rails?

Nur so vorweg. Ich hab selbst schon was mit Rails gemacht und bilde mir deshalb ein dazu was sagen zu können. :-)

Es ist halt ein relativ angenehmes Web-Framework (wobei viele Sachen die Rails populär gemacht haben inzwischen auch in andere Frameworks Einzug gefunden haben) und Ruby ist auch eine recht elegante Sprache (so ein bisschen wie Python aber ohne diese Python-Unschönheiten wie "objektlose" Funktionen usw.).
Die Rails-Community war (wie es heute ist, weiß ich nicht mehr) auch immer rege was den Gebrauch von neuem Kram anging (die hatten seinerzeit früh Ajax und Co ins Framework integriert.

Es gibt aber auch (wie bei allem) eine ABER-Seite :-)

Weil man eben auch recht schnell neue Techniken adaptiert, änderte sich auch ständig irgendwas im Framework. Das führt dazu, das man Bestands-Applikationen immer wieder mal anpassen muss und erworbenes Wissen ziemlich schnell altert.

Ruby und Ruby on Rails ist jetzt nicht unbedingt die schnellste Sprache (und das schnellste Framework) und skaliert auch nicht wirklich gut (sprich: mehr Hardware draufwerfen hilft nur bedingt). Für wenig frequentierte Webseiten wird das nicht zum Problem werden. Wenns mehr wird aber durchaus. Das hatte Twitter auch mal "leidvoll" erfahren müssen. Die hatten auch mit Rails begonnen, wurden dann dummerweise populär und mussten dann ihre alte Rails-Lösung wegwerfen und (mit Java/Scala) neu machen.

Ein weiteres Problem ist, das Ruby on Rails Entwicklung nur auf Mac und Linux wirklich gut funktionieren. Auf Windows weniger. Gut. Ich persönlich halte es eh für keine gute Idee unter Windows zu programmieren wenn man nicht gerade Windows-Programme schreibt, aber es gibt ja Leute die machen das. :-)
Und dann sollte man das halt wissen, das man evtl. hier und da mal ein wenig frickeln muss.

 

[BeBur]

Für wenig frequentierte Webseiten wird das nicht zum Problem werden. Wenns mehr wird aber durchaus. Das hatte Twitter auch mal "leidvoll" erfahren müssen. Die hatten auch mit Rails begonnen, wurden dann dummerweise populär und mussten dann ihre alte Rails-Lösung wegwerfen und (mit Java/Scala) neu machen.

Ja das ist wirklich das Hauptproblem, man hat 10.000.000+ User und kann deswegen sein Ruby in Rails nicht mehr ordentlich skalieren. Auf dieses Nadelöhr bin ich auch bei jedem dritten Rails Projekt gestoßen, aber ich kann dir versichern, das ist nun schon zehn Jahre her, mittlerweile kannst du besser skalieren, aber schreibe mir ruhig eine wütende Nachricht wenn dann bei dir bei 100.000.000 Nutzen Rails dicht macht. #alltagsprobleme

Rails ist seit Jahren sehr stabil, da ändert sich kaum noch was an den wesentlichen Funktionen, es wird eher hinzu gefügt.

Zu Windows kann ich nichts sagen, würde vermuten so wie Python/Django und anderes auch.
Ist jedenfalls ein ziemlich cooles Framework ;-).

Ergänzung (24. April 2021)

Irgendwie kommt mir Ruby wie ein Underdog vor aber irgendwie wird immer davon geschwärmt. Wie sind eure Erfahrungen mit Ruby? Falls es welche gibt.

RoR war um 2010 der Platzhirsch, weil die sehr viel richtig gemacht haben, unter anderem sinnvolle defaults, die man aber schmerzfrei überschreiben kann. "Convention over Configuration". Das ist sehr geil. Aber Web-Frameworks sind immer nur kurze Zeit "Hip", Rails kam dann etwas aus der Mode zugunsten von Javascript-Frameworks bzw. ClientSide zentrierte Frameworks. Das ändert nichts daran, dass RoR weiterhin eine hohe Verbreitung hat und dass das ein vorzügliches Framework ist.

Die Sprache Ruby ist mein absoluter Favorit, ich hab in ca. 5-8 weiteren Sprachen schon ernsthaft programmiert und Ruby "just works", semantisch und syntaktisch und harmoniert extrem gut mit Rails. Was einigen oft nicht so gut gefällt und das kann ich gut verstehen ist, dass Ruby bzw. Rails oft mehrere Wege anbietet, ein Ziel zu erreichen und das kann manchmal verwirrend sein, weil man sich erst daran gewöhnen muss, was jeweils der "idiomatische Weg" ist.

 

[sh.]

@BeBur
Vielen Dank für deine Einschätzung
Hast du vielleicht empfehlenswerte Lektüre zum Thema Ruby und/oder Rails? Bücher oder Tutorials? Müssen oder sollten nicht für absolute Anfänger sein und natürlich auch gerne in Englisch.

 

[BeBur]

Zwei recht bekannte Ressourcen sind/waren gorails und railstutorial.
https://gorails.com hat nen Haufen guter Videos, aber keinen Einsteigerkurs, soweit ich sehe, jedenfalls nicht kostenfrei. Früher war mehr kostenfrei, also wenn die da was gegen Geld haben für Einsteiger, dann ist das vermutlich recht gut.

Was stets empfohlen worden ist und offenbar immer noch auf dem aktuellen Stand gehalten wird ist https://www.railstutorial.org/book Das ist ein komplettes Buch, als Online-Ausgabe kostenfrei, das alle Themen abdeckt und auch über Deployment spricht und wie man Tests schreibt etc. und man baut sich da im Prinzip seine eigene kleine Application im Laufe des Buches, alles sehr praxisnah und gut gemacht.
Also wenn du die Ruhe hast für ein Buch und auch viel lesen willst und auch nicht davor zurückschreckst, dass auch das 'drum herum' was dazu gehört bei einer Web-App besprochen wird: Das Ding ist ziemlich gut und wäre meine erste Wahl für jeden.
Ich hab gesehen, der hat mitlerweile wohl auch Kurse u.ä., also ich kenne nur das kostenlose Buch aber ich kann mir vorstellen, dass es sich drastisch lohnt seine Kurse o.ä. einzukaufen.

Aktuell gibt es Rails 6.x, Rails 5.x war jetzt nicht so schrecklich anders, also wenn du da was findest dann geht das denke ich immer noch gut klar.


Je nachdem was du machen willst, da dir Ruby ja nun schon gefällt (verständlich ), kannst du auch einfach erstmal 'nur' Ruby lernen, das ist eine durchaus interessante Sprache in Hinblick auf einige Dinge (in dem Sinne von: Da kann man einiges mitnehmen und lernen für die eigenen generellen Programmier-Skills). Kenne jetzt deinen Hintergrund nicht, aber wenn du eher kompilierte bzw. statisch/stark typisierte Sprachen kennst (C, C++, Java sind die am weitesten bekannten Vertreter), dann ist Ruby ein sehr interessanter alternativer Ansatz.


Beispiele für Unternehmen, die immer noch und weiterhin Ruby on Rails als (soweit ich weiß) wesentliches Fundament in ihrem Tech-Stack haben: Airbnb, Github, Basecamp, Shopify.

 

[andy_m4]

Ja das ist wirklich das Hauptproblem, man hat 10.000.000+ User und kann deswegen sein Ruby in Rails nicht mehr ordentlich skalieren.

Klar ist das jetzt ein Extremszenario. Man sollte es aber dennoch beachten. Das Problem ist halt auch, Ruby und damit auch Rails ist schon von Haus aus recht langsam. Du kommst also (je nach eingesetzter Hardware) schon relativ "früh" in Performance-Probleme. Wenn es dann auch nicht gut skaliert, hast Du halt schnell ein Problem.

Wobei sich das nicht verallgemeinern lässt. Das kommt auf die ganz konkrete Anwendung drauf an die Du umsetzen willst. Für viele Szenarien ist das gar kein Problem. Für andere lässt sich damit gut umgehen.
Man sollte aber deshalb nicht so tun, als wäre das generell gar kein Problem. Jede Sprache/Framework/Technologie hat ihre Grenzen. Die sollte man dann auch benennen. Das ist ja auch keine Wertung oder so.
Aber wie bei jedem Werkzeug. Nur wenn man die Möglichkeiten und Grenzen kennt, kann man einschätzen ob man es einsetzt oder nicht.

Zugegebenermaßen: Um mal in die Entwickling von "Webapps" reinzukommen und damit rumzuspielen und von mir aus auch das ein oder andere kleine bis mittlere Projekt umzusetzen wird man üblicherweise mit keinen Grenzen auch nur annähernd in Kontakt kommen.

RoR war um 2010 der Platzhirsch, weil die sehr viel richtig gemacht haben, unter anderem sinnvolle defaults, die man aber schmerzfrei überschreiben kann. "Convention over Configuration". Das ist sehr geil.

Ruby on Rails funktioniert aber wirklich auch nur dann gut, wenn man es benutzt wie vorgesehen. So richtig flexibel ist es nicht bzw. wenn man viel ändern will, artet es auch schnell in Arbeit aus und seine eigentlichen Stärken gehen verloren.
Man sollte es also nicht zu verbasteln und wenn man gezwungen es zu verbasteln, dann ist Rails vielleicht doch nicht das geeignete Framework für das was man vorhat.

Die Sprache Ruby ist mein absoluter Favorit, ich hab in ca. 5-8 weiteren Sprachen schon ernsthaft programmiert und Ruby "just works", semantisch und syntaktisch

Gut. Wenn man von C++ oder Java kommt, dann macht Ruby natürlich einen angenehmen Eindruck. :-)
Von man von Smalltalk kommt, dann sieht die Sache schon etwas anders aus. :-)

aber wenn du eher kompilierte

Ob kompiliert oder interpretiert ist nicht zwangsläufig eine Eigenschaft der Sprache. Du kannst also ohne weiteres einen C-Interpreter schreiben oder auch ein Ruby-Compiler. :-)
Allerdings hat ein Compilerdurchlauf auch einen Vorteil. Die guckt "jemand" über den Code rüber. Das ergibt die Möglichkeit, das Fehler schon vor der eigentlichen Ausführung erkannt werden. Und an dem Punkt wirds interessant, weil einem unterschiedliche Sprachen auch unterschiedliche Möglichkeiten geben Fehler im Vorfeld zu erkennen.

Mir ist es ja immer lieber wenn ich möglichst viele Fehler schon vor Ablauf des Programms erkenne. Ohne das ich alles abtesten und jeden möglichen Codepfad auch wirklich durchlaufen muss.

statisch/stark typisierte Sprachen

Ich würde Ruby eher als dynamisch aber trotzdem stark typisiert bezeichnen.
Dynamisch, weil Du hast keine Variablendeklarationen u.ä.
Aber es ist trotzdem stark typisiert. Im Gegensatz zu C. Das ist zwar statisch typisiert aber die Typisierung ist schwach. Du kannst in C schreiben:

char ch = 'A';
int i = ch+5;

Ist völlig legal. Der Compiler meckert nicht. Und das obwohl ch einen völlig anderen Datentyp als i hat.
Ruby würde das nicht zulassen. Wenn Du in Ruby sowas wie

"A"+5

schreibst, würde der Dir einen TypeError geben und Dir explizite Typumwandlung nahelegen. :-)

 

[BeBur]

Ich denke die allgemeinen Ausführungen zu Sprachen müssen wir hier nicht vertiefen da würden wir nur die ganze Zeit über Dinge schreiben, die der andere bereits weiß. Ich bevorzuge letztendlich übrigens ebenso statisch und stark typisierte Sprachen, genau aus den von dir genannten Gründen ;-).

Das Problem ist halt auch, Ruby und damit auch Rails ist schon von Haus aus recht langsam. Du kommst also (je nach eingesetzter Hardware) schon relativ "früh" in Performance-Probleme. Wenn es dann auch nicht gut skaliert, hast Du halt schnell ein Problem.

Zugegebenermaßen: Um mal in die Entwickling von "Webapps" reinzukommen und damit rumzuspielen und von mir aus auch das ein oder andere kleine bis mittlere Projekt umzusetzen wird man üblicherweise mit keinen Grenzen auch nur annähernd in Kontakt kommen.

Nein, also das ist falsch. Dafür müsstest du schon Domänen-relevante Benchmarks (also WebApps) bzw. Belege liefern damit man das überhaupt sinnvoll diskutieren kann, dein einziger Beleg bisher ist diese Twitter-Anekdote gewesen, welche wie ich schon ausführte kein Beleg für diese Behauptung darstellt.

Ruby on Rails funktioniert aber wirklich auch nur dann gut, wenn man es benutzt wie vorgesehen. So richtig flexibel ist es nicht bzw. wenn man viel ändern will, artet es auch schnell in Arbeit aus und seine eigentlichen Stärken gehen verloren.
Man sollte es also nicht zu verbasteln und wenn man gezwungen es zu verbasteln, dann ist Rails vielleicht doch nicht das geeignete Framework für das was man vorhat.

Das ist ein vertretbarer Standpunkt den ich nicht teile. Um das auszudifferenzieren sollte man vermutlich konkreter werden. Es ist so, oder angenehmer formuliert: Meine Wahrnehmung ist immer so gewesen, man hat die Rails defaults und dadurch geht sehr viel automatisch und man muss nichts einstellen. Die Alternative besteht darin, die Defaults zu überschreiben, also zu konfigurieren und dann macht man nichts anderes als man "anderswo" (ist heute nicht mehr ganz so schlimm wie früher mal) sowieso die ganze Zeit machen muss.

Einzig das MVC nicht immer eine gute Wahl ist als Startpunkt und zu viel Kopplung impliziert, das mag zuweilen sein, da kann ich nur entgegen, dass die Vorteile von RoR groß genug sind, das auszugleichen bei entsprechenden Projekten.

 

[hi-tech]

@andy_m4 @BeBur
Interessante Sichtweisen. Hab selber nie professionell Webseiten gebaut, wenn dann nur für persönliche Zwecke und Just for fun. Wie ich finde aber mega spannendes Feld, da es sich so schnell weiter entwickelt, so wie die technische Leistungsfähigkeit es zulässt. Man denke an die statischen Seiten von damals und heute die dynamischen Inhalte und Funktionen. Nur Thema Sicherheit ist immer ein wenig lästig. Naja.

OnTopic:
Wollte nur mal den TE bekräftigen die Basics zu lernen.
Nach den ganzen Datentypen, Anweisungen, Operatoren kommen Methoden, Klassen und dann die Objektorientierung.
Danach noch so Sachen wie GUIs, Threads und dann meiner Meinung nach sehr wichtig die Patterns bzw. Entwursmuster verstehen / lernen.
Wenn das durch ist würde ich dann ein kleineres Projekt anfangen.

Was Webprogrammierung angeht würde ich klassisch mit HTML, PHP, CSS, Javascript, XML, ajax, json, SQL anfangen. Vielleicht noch in React oder Angular schnuppern.

Generell aber würde ich sagen, wenn man in Java die Entwurfsmuster einsetzen gelernt hat und schon kleinere Programme damit geschrieben hat, ggf. auch mit GUI, dann ist man schon so weit im Verständnis, dass man sich nicht unbedingt proaktiv weitere Sprachen anlernen muss.

Ab hier würde ich versuchen herauszufinden, was macht mir Spass und wo will ich hin. Möchte ich Hardwarenahe Anwendungen schreiben? Möchte ich Business Apps entwickeln? Mobile Apps, Game-Developing oder doch Webseiten? Jede Sparte ist ein Universum für sich. Man kann schwer alles lernen.
Dann einfach weitere Projekte raussuchen und zielgerichtet die dazu nötigen Technologien aneignen. Spass macht es natürlich wenn es für einen persönlich einen Nutzen hat.

Was Webentwicklung angeht wäre eine eigene Portfolio Website vielleicht ein super Start.
Hier paar Beispiele:
https://ejosue.com/
http://findmatthew.com/
https://jacekjeznach.com/
http://www.rleonardi.com/interactive-resume/ (das ist mega )

 

[andy_m4]

Ich bevorzuge letztendlich übrigens ebenso statisch und stark typisierte Sprachen, genau aus den von dir genannten Gründen ;-)

Wobei es ja durchaus auch Zwischenwege gibt wie z.B. Gradual-Typing, wo Du dann halt Dir aussuchen kannst, ob Du Typangaben hinterlegst oder nicht und auch typed und untyped Code mischen kannst. Der bekannteste Vertreter dürfte TypeScript sein, was ja im Prinzip getyptes Javascript ist.
Bei Python gibts inzwischen zumindest type-hints, die dann (maschinell) ausgewertet werden können.

Nein, also das ist falsch. Dafür müsstest du schon Domänen-relevante Benchmarks (also WebApps) bzw. Belege liefern damit man das überhaupt sinnvoll diskutieren kann

Ruby ist langsam also ist auch Rails langsam. Wobei "langsam" und "schnell" natürlich relative Begriffe sind. Oftmals recht es ja, wenn es "schnell genug" ist. Und bei einer typischen Rails-Applikation die überschaubare Business-Logik hat und im wesentlichen auf irgendeiner Datenbank rumkratzt ist das ja meist auch nicht wirklich ein Problem.

Und das Ruby langsam ist, ist wohl unstrittig. Ich hatte das tatsächlich mal vor Jahren bei einer Ruby-Applikation wo auch eine etwas umfangreichere Berechnung lief und das war dann zu langsam. Ich hab natürlich zunächst versucht es trotzdem hinzukriegen. Ruby konnte damals schon Native-Threads. Die Berechnung ließ sich gut parallelisieren. Das reichte aber immer noch hinten und vorne nicht. Auch mit JRuby auf die JVM zu gehen war zwar ganz gut, aber immer noch nicht gut genug. Also hab ich die entsprechende Routine in C implementiert. Das war deutlich schneller und hat dann letztlich auch gereicht.

Ich musste ja die Ruby-Applikation auch nicht wegwerfen oder so. Die entsprechende Routine wurde dann einfach über die C-Schnittstelle eingebunden und gut war.
Also selbst wenn Performance-Probleme auftreten, schließt das automatisch eine Technologie nicht völlig aus und mann kann da durchaus was machen.
Nur muss man es eben wissen. Und dann kann man auch was machen. Bringt ja nix den Kopf in den Sand zu stecken und sich immer wieder zu sagen "Ruby ist schnell genug". :-)

Anders ists ja bei Python/NumPy ja auch nicht. Python ist ja auch recht langsam. Also hat man die NumPy -Routinen im Wesentlichen C und Co implementiert. Benutzt wird es dann aber mit Python, was dann auch den wesentlich angenehmeren Zugang bietet als wenn man dafür auch C nehmen würde.

Das ist ein vertretbarer Standpunkt den ich nicht teile.

Wäre ja auch langweilig, wenn alle der gleichen Meinung wären. :-)
Es ist ja genau dann am Spannensten, wenn jemand nicht der gleichen Meinung ist und einem dann Dinge aus einem Blickwinkel schauen lässt, den man vorher gar nicht so auf dem Radar hatte.

Die Alternative besteht darin, die Defaults zu überschreiben, also zu konfigurieren und dann macht man nichts anderes als man "anderswo" (ist heute nicht mehr ganz so schlimm wie früher mal) sowieso die ganze Zeit machen muss.

Hab auch nie was anderes behauptet. :-)

Generell hat man ja zwei Möglichkeiten. Man kann ein Framework ultraflexibel machen (so im Stile vonm alten J2EE, worauf Du ja vermutlich auch anspielt). Das heißt wirklich jede Anwendung die Du damit bastelst bringt Overhead mit. Selbst ein 'Hello World' ist nicht unter 2 Stunden machbar :-)
Die Alternative ist ein spezialisiertes Framework. Spezielle Aufgaben hast Du damit fix erledigt. Allerdings kannst Du nicht jegliche Aufgabenstellung damit so fix lösen und bei Manchen Aufgaben steht die die Spezialisierung sogar im Weg.

Rails gehört eher zu Letzterem. Aber auch das ist keine Kritik, sondern eher ein Hinweis.
Gibt ja so immer die schönen Rails-Beispiele, wo Du dann mit relativ wenig Code coole WebApps basteln kannst. Das sollte aber nicht darüber hinwegtäuschen, das es halt auch Szenarien gibt wo das nicht so einfach funktioniert. Das muss ja alles keine dramatischen Folgen haben, aber man sollte es halt wissen.

Generell aber würde ich sagen, wenn man in Java die Entwurfsmuster einsetzen gelernt hat

Java ist ja berühmt-berüchtigt für so Entwurfsmuster. Kein Programm ohne irgendeine BlödsinnsFactory. :-)
Ja. Entwurfsmuster haben schon irgendwo ihre Berechtigung. Aber das sie in Java so präsent sind und vor allem wie sie da umgesetzt werden, liegt vor allem an den Unzulänglichkeiten von Java. Das kann man beispielsweise gut an solchen Sachen wie Singletons bestaunen. :-)

 

[hi-tech]

Naja Sinn und Anwendbarkeit kann man später immernoch diskutieren. Ich meine für den Lernenden ist es nicht schlecht ein paar der gängisten Konzepte zu vestehen. Zum Beispiel sollte man einen Observer / Listener schon programmieren können. Den braucht man nicht neu erfinden ^^

 

[RalphS]

Ob kompiliert oder interpretiert ist nicht zwangsläufig eine Eigenschaft der Sprache. Du kannst also ohne weiteres einen C-Interpreter schreiben

Erm, sorry aber das kann ich leider nicht unkommentiert stehenlassen.

Interpreter und Compiler sind natürlich nicht einfach austauschbar.
Kein interpreter der Welt wird mit Compilerdirektiven etwas anfangen können- dazu hätte es eines weiteren durchlaufs bedurft, den ein Interpreter aber nicht leisten kann- der kann nur Zeile für Zeile voranschreiten.
Linking fällt mit Interpretern ganz aus. Man bräuchte stattdessen einen Dynamic loader wie dl() und müßte alle externen Abhängigkeiten spätestens zur Laufzeit bereit stellen.

Interpretersprachen auf der anderen Seite können sicherlich kompiliert werden.
Aber dann hätte man eher einen fork der Sprache. Interoperability wäre nicht mehr gegeben- Script A könnte nicht mit Binary B Interagieren außer über vorher definierte Schnittstellen.

Das was wir grad hauptsächlich haben sind je nach Auslegung eher hybride oder eher Interpretersprachen.
Java ist interpretiert- dafür gibts die Jvm.
.Net ist hybrid. Teile sind nativ, aber keine Net Application ohne zugehörige Laufzeit, ebenso wie VB oder php.

Und wenn wir uns sowas wie py2exe angucken, werden wir feststellen, daß praktisch immer einfach ein Interpreter in eine Binary gesteckt und das/die Scripts einfach als payload angehängt werden.
Der Code selbst wird weiterhin interpretiert- er sieht nur anders aus, sei es pyo oder Pyc.

 

[andy_m4]

Interpreter und Compiler sind natürlich nicht einfach austauschbar.

Das hat so auch niemand behauptet.
Dennoch ist eine einfache Klassifizierung in "Interpretersprachen" und "Compilersprachen" eben nicht so ohne Weiteres möglich.
Du selbst belegst das durch Deine Ausführungen doch sogar.
Von daher nehme ich mal an, Du wolltest mir weniger widersprechen, sondern eher ergänzen (was Dein Eingangssatz ja auch nahelegt).

 

[DerDampflok]

Programmieren lernt man durch Programmieren. In der Regel fängt man mit einem einfachen Hello World Programm an und steigert sich dann nach und nach. Mit welcher Programmiersprache man dann beginnt, ist immer ein wenig Geschmackssache (wobei man häufig sowohl in der Schule als auch in der Uni mit Java beginnt).

Tutorials gibt es jedenfalls genug auf YouTube oder im Netz. Von A wie Angular bis Z wie Zonnon ist alles dabei.

 

[BeBur]

Anders ists ja bei Python/NumPy ja auch nicht. Python ist ja auch recht langsam. Also hat man die NumPy -Routinen im Wesentlichen C und Co implementiert. Benutzt wird es dann aber mit Python, was dann auch den wesentlich angenehmeren Zugang bietet als wenn man dafür auch C nehmen würde.

Auf deine letzten Ausführungen im zitierten Beitrag können wir uns durchaus einigen. Das Hauptproblem war sicherlich, dass wir sehr allgemein diskutiert haben und da ist natürlich für "schnell", "langsam" oder "wenig frequentiert" eine große Bandbreite an Interpretationsspielraum. Ruby und RoR sind keine "Spielzeugtechnologien" die nur für kleine Projekte und Mini-Websites taugen, darum ging es mir vornehmlich.

Interpretersprachen auf der anderen Seite können sicherlich kompiliert werden.
Aber dann hätte man eher einen fork der Sprache. Interoperability wäre nicht mehr gegeben- Script A könnte nicht mit Binary B Interagieren außer über vorher definierte Schnittstellen.

Python ist eine sehr schöne Fallstudie, welche Ansätze man sich diesbezüglich überlegen kann. Z.B. Cython, ein AOT Compiler mit besserer Performance und deutlich mehr Performance, wenn man die Cython-spezifische Spracherweiterungen / Python-Fork verwendet. Oder PyPy ein JIT Compiler für Python, als Drop-in Ersatz, also kein Fork.
Alle jeweils mit ihren eigenen Nachteilen, wie sie du auch schon genannt hast. Aber jedenfalls sind Menschen aus der Not heraus in den letzten Jahren ziemlich kreativ gewesen in dem Bereich .

 

[andy_m4]

Ruby und RoR sind keine "Spielzeugtechnologien" die nur für kleine Projekte und Mini-Websites taugen, darum ging es mir vornehmlich.

Nein. So war das auch nicht gemeint.
Man kann sogar große Projekte mit Rails angehen. Nur umso größer/komplexer das Problem wird, umso mehr muss man halt gucken ob alles passt oder ob man irgendwie in Probleme läuft und wenn man in Probleme läuft, ob man die dann beheben kann oder nicht.

Bei kleineren Projekten braucht man das eher nicht so. Da kann man fast immer zu seinem jeweiligen Lieblingsframework greifen und es wird hinreichend gut funktionieren.

Zu Python sag' ich lieber nix mehr. Da gibts immer Zoff, wenn ich versehentlich nicht richtig einrücke oder ein Tab dazwischen rutscht. :-)

 

[RalphS]

Programmieren lernt man durch Programmieren.

Ein immer wieder gern genannter Ansatz. Aber leider hochproblematisch.

Ändern wir das mal lieber um in: Programmieren lernt man durch das Haben von Problemstellungen, die man gerne lösen möchte. Kein Problem was es zu lösen gilt, ergo keine Applikation dafür und kein Ansporn eine zu bauen.

Gleichzeitig ist es leider so, daß man sich gerade auch als Autodidakt jede Menge Müll selbst beibringen kann, manchmal ist man da auch noch nicht mal selber dran schuld, sondern hatte einfach das zweifelhafte Vergnügen, just an der falschen Stelle die falsche Lektüre in die Hand zu bekommen.

Obendrauf bin ich mir aber definitiv nicht zu schade zuzugeben, daß 11 von 10 Dozenten die tatsächlich Programmieren "lehren" sollten (note: explizit NICHT Uni oä) dazu einfach nicht in der Lage waren, wenn man "in der Lage sein" über "hinterher kann ich in der Sprache selbst was zusammenbauen" definiert.


TLDR, um Theorie wird man nicht drumherumkommen; das muß jetzt nicht der letzte finale Schrei sein ob der exakten Umsetzung DIESES Designpatterns und jener Formatierung; ABER sowas wie "wer Code kopiert macht was falsch" oder "wie gestalte ich meinen Code so, daß er effizient läuft und ich hinterher trotzdem noch weiß was da passiert" und all die anderen kleinen und großen absoluten Basics der Programmierung... die kommen nicht aus einem selber heraus, weil man grad halt programmieren "wollte".

Mit was Glück gibt es Synergieeffekte durch Angucken fremden Codes. Aber den muß man auch verstehen. Und für jemanden der grad erst anfängt ist es jetzt nicht unbedingt erkennbar, WARUM der Code da so steht wie er da steht. Wie auch? Ob der Autor das vorm Schlafengehen hingerotzt hat oder ob das die absolute Quintessenz von einem Jahr Forschungsarbeit ist, das kann der noch uninformierte Leser nicht entscheiden.

Deshalb, ja, natürlich muß man erstmal etwas haben, was man überhaupt erstmal umsetzen will (siehe oben).
Aber man muß halt begleitend auch was lesen. Wenn man erfahrene Kollegen irgendwo hat, die man fragen kann, umso besser.

Anderenfalls riskiert man, daß man 10 Jahre oder so "vor sich hin programmiert hat" und wenn man das dann zu Geld machen will, indem man einen entsprechenden Job annimmt.... man ganz GANZ böse auf die Nase fällt.

 

[DerDampflok]

Ich stimme dir da voll und ganz zu, allerdings wird der Anfänger zunächst einmal mit einem Hello World anfangen und sich dann steigern, bis er irgendwann den Dreh raushat und verstanden hat, wie ein Computer "denkt" und wie man sein neu hinzugewonnenes Wissen ordnen und erweitern kann.

Ich erlebe es gerade selber in meiner Ausbildung. Zwei aus unserer Klasse, die die Prüfung jetzt zum 3. mal machen (normalerweise hätten sie schon beim 2. Anlauf die Schule verlassen müssen, weil es sich um eine schulische Ausbildung handelt, es gab nur wegen dem großen C eine Ausnahme) und nach wie vor die Grundlagen nicht verstanden haben. Dementsprechend sieht auch ihr Code aus und der Lehrer nickt das einfach ab und redet die Situation schön, wie neulich: Es sollte die Summe der Anzahl der Elemente aus drei Arraylisten gebildet und in einer Variable gespeichert werden, einer der beiden konnte es nicht, obwohl er schon seit vier Jahren dort herumgeistert. Dann kommen so lasche Sätze wie "Ach, das war nur eine Denkblokade... Wir zeigen Ihnen nur die Basics, den Rest müssen Sie selber lernen!" Dumm nur, wenn die "Basics" nur aus einfacher Konsolenprogrammierung und "Spieleprogrammierung" bestehen, wo wir nüchtern betrachtet nur Objekte in einer Liste speichern und sie auf Kollision mit anderen Objekten prüfen (das ist überhaupt nicht schwer und wir sitzen schon seit einem Jahr daran! Selbst der Rest der Klasse langweilt sich schon zu Tode bis auf die besagten beiden Herren). Nichts mit etwas anspruchsvollere Spielelogik oder der interessanten Mathematik, die da hinter steckt ("Das ist zu kompliziert, das unterrichten wir hier nicht!"), obwohl diese Ausbildung das (Fach)Abitur voraussetzt und es nur ganz einfache 2D Spiele sind In dem Fach Datenbanken (Webentwicklung mit PHP bzw. mysqli) werden nicht einmal einfache Prepared Statements erklärt, weil sie nach Aussage der Lehrerin ebenfalls zu kompliziert seien 🙃

Ich habe während dieser Ausbildung nebenbei als Angular Webentwickler in einem Betrieb gearbeitet, da liegen einfach Welten zwischen. Die Chefs haben mir die tollsten und interessantesten Sachen gezeigt und mir nebenbei auch viel Theoriewissen erklärt, während die Schule das Schleifen lässt mit dem allseits beliebten Satz "Das ist zu kompliziert, das verwirrt die Klasse nur!" obwohl die Klasse sich gerade selbst zu Tode langweilt, weil wir nur stumpfe Wiederholung machen. Aber für das Fach Fotografie ist Platz mit der Begründung "Sie sind ja Informatiker, Sie müssen auch fotografieren können!"

Recht hast du auch mit dem letzten Satz. Wenn die Herren dann in einem Softwarebetrieb kommen (was ich bei deren Code eher weniger glaube), fliegen die ziemlich feste auf die Nase.

Ach ja, es hilft auch, den eigenen Code zu reflektieren und zu hinterfragen und zu schauen, ob es nicht aus effizienter geht und man ihn trotzdem noch lesen kann.