Welche Programmiersprache für Anfänger ?

Also ich würde für jemanden, der noch nie zuvor irgendwas programmiert hat, eine Sprache empfehlen, die nicht strikt objektorientiert ist. Warum?

Wenn ich bis jetzt Leuten helfen musste Java zu verstehen (ich habe das Gefühl das mittlerweile JEDER Studiengang einmal einen Java-Kurs bekommt), hatten diese mit dem OO so ihre Probleme. Ein Vergleich:

print "Hello World!"

vs.

class HelloWorldApp {
public static void main(String[] args) {
System.out.println("Hello World!");
}
}

Bei dem 1. (Python) versteht man es relativ schnell: "ok, der Computer ließt die Anweisung und führt sie aus". Das OO ist jedoch noch eine zusätzliche "Last", die man zusätzlich neben der eigentlich Programmlogik und Syntax noch verstehen muss. ("Warum muss man da eine Klasse machen?", "Was ist das static?" etc).

Also ich empfehle erstmal mit Python oder ähnlichem anzufangen, um sie wirklich auf Programmabläufe (Algorithmus) konzentrieren zu können.
 
Poke646 schrieb:
Ich wollte lediglich zum Ausdruck bringen, auch wenn es in vielen fällen zutrifft, dass ein Intepreter kein hartes (notwendiges) Merkmal für eine Skriptsprache ist. Wenn man Kategorien aufstellt und Python und PHP in die Kategorie Skriptsprache steckt, dann ist das Gegenstück dazu nicht die Kategorie "Compilersprache" wie oben angedeutet wurde.

Du hast recht, IMO zeigt das aber vor allem, dass der Begriff "Skriptsprache" heutzutage falsch verwendet wird - nämlich eben im Sinn von "interpretierte Sprache". Dabei bezeichnet "Skriptsprache" ja eigentlich Sprachen, die nicht zur Entwicklung vollwertiger Anwendungen gedacht sind, sondern zum schnellen Schreiben von Miniprogrammen.

PHP fällt aber gerade nicht in diese Kategorie. Man kann zwar durchaus damit skripten, aber weitaus häufiger wird PHP tatsächlich zur Entwicklung ausgewachsener (Web-)Anwendungen verwendet. Python ist schon häufig als Skriptsprache im Einsatz, kann aber ebensogut für größere Projekte verwendet werden. Eine "reinrassige" Skriptsprache zu finden, ist gar nicht so einfach, wenn man mal von Shell-Skripting wie bash und Powershell absieht.
 
Der Punkt ist in dem Fall denk ich dass sich die früheren Skriptsprachen inzwischen derart weiterentwickelt haben das sie inzwischen vollwertig alles erfüllen können. Ein PHP aus den Anfangszeiten kann man sicherlich nicht mit dem vergleichen was man jetzt hat, auch Perl hat sich weiterentwickelt. Von daher findet man kaum noch Sprachen die auf deiesem Niveu geblieben sind... JScript und VBScript fallen mir da ein
 
Auch JS kansnt du da getrost streichen. Schau dir doch nur mal Node.JS an: mit ner V8-Engine als Interpreter lassen sich hier mal eben eventgesteuerte Webserver realisieren, die für hochparallele Aufgaben jeden der klassischen Webserver in die Tasche stecken.

Tatsächlich wäre JS gar keine SO verkehrte Sprache als Einstieg.
 
JScript != JavaScript. Aber JScript ist trotzdem ein gutes Beispiel, warum es eigentlich quatsch ist, anhand der Ausführungstechnologie in Skript- oder nicht-Skriptsprache zu unterscheiden, denn keiner würde auf die Idee kommen, JScript.NET nicht weiterhin als Skriptsprache zu bezeichnen. Oder Groovy, tituliert sich offiziell als Skritpsprache und läuft in der JVM.

Es gibt wohl keine Wasserfeste Definition einer Skriptsprache, und falls es die gäbe, dann hätte sie sich im Laufe der Jahre doch arg wandeln müssen. Was man nach modernem Verständnis darunter versteht ist imho eine Sprache mit dynamischer oder schwacher Typisierung, impliziten Variablendeklarationen und einem Garbage-Collection Mechanismus, oftmals interpretiert.
 
Die Trennung zwischen JavaScript und JScript ist gar nicht so einfach da der IE die JScript Engine benutzt (zumindest früher, ist aber glaub ich immer noch so)... aber ich muss zugeben das ich in dem Moment nur an den Scripting Host gedacht hab, da ich dort ab und an mit JScript arbeite um mir kleine Hilfsprogramme zu bauen (geht schneller als mit C#, einfacher als mit CMD und läuft im Gegensatz zu Python auf jedem Windows-PC ohne extra Interpreter)

PS: ja ich weiß das es einen Python Compiler gibt ;-)
 
Daaron schrieb:
Schau dir doch nur mal Node.JS an: mit ner V8-Engine als Interpreter

Und V8 wiederum ist kein Interpreter mehr, sondern bereits ein Compiler. Denn die V8-Engine kompiliert den JavaScript bei der Ausführung direkt in Maschinencode.

Generell gibt es heute wirklich kaum noch reine Interpreter, wie man sie vor Jahren mal definiert hatte.
 
Das fällt schon bald unter Haarspalterei... Diese Just-In-Time - Compiler interpretieren und kompilieren in einem Abwasch.

B2T: Es ist Wurst, welche Sprache man wählt, aber man fährt etwas entspannter mit einer, die nicht strikt auf Objektorientierung baut. Wenn es dazu noch gute Debugger gibt und man damit flexiblen Mumpitz anstellen kann... warum nicht?
 
JIT-Compiler sind die logische Weiterentwicklung von Interpretern, da sie sehr viel optimierungspotential bieten. Teilweise sind diese sogar den "echten" Compilern überlegen, da sie zur Laufzeit weiter optimieren können. Es entwicklet sich einfach alles weiter, von daher ist es schwierig an alten Begriffen wie "Skriptsprache" festzuhalten...
 
Diesen kleinen Vorteil erkaufen sich diese "JIT-Compiler" aber auch teuer. Zur laufzeit generierter Code wird immer durch das vorkompilieren verzögert. Natürlich ist dies im Vergleich zu einem anderen System erst ab dem 2. Lauf zu merken, jedoch merklich, da auch jedes Modul neu übersetzt wird. Außerdem ist er nur sehr Systemspezifisch ausgelegt, da du nur für eine Architektur direkt übersetzten lassen kannst.

Er ist nunmal nur eine weitere Möglichkeit neben Virtuellen Maschinen/Bytecode-Interpretern und die "bessere" Wahl ist immer Abhängig von dem Stück Software das du entwickeln willst.
Ein Programm das sich nur einmal täglich ändert, aber Millionen zugriffe hat, möchtest du nicht permanent neu interpretieren lassen und ein Programm dessen Module sich ständig wechseln willst du nicht permanent übersetzten.

Ein JIT ist da wirklich sinnvoll, wo du auf einem System, viele unterschiedliche Programme aus einem Kernsystem entstehen lässt. So etwas wie ein SAP System das dynamische Reports erzeugt. Der Kern ist vorkompiliert, aber die Module die sich die Daten aus dem Kern beziehen werden ständig neu generiert. Da gewinnt ein JIT enorm an Zeit. Das ist aber, wie du sicher auch erkennst, ein sehr kleines Aufgabenfeld.
 
ice-breaker schrieb:
Facebook hat einen neuen PHP-Compiler geschrieben, aber nicht alles nach C++ portiert. Das sind himmelweite Unterschiede, und neue effizientere Compiler werden immer geschrieben, das ist der Lauf der Dinge.

Falsch. Facebook hat ein Tool entwicklet, um den PHP-Code nach C++ zu transformieren, was dann mit GCC nativ kompiliert wird. Also gerade keinen Compiler. Die PHP-Runtime haben sie ebenfalls neu implementiert (und viele Extensions gleich mit).

Ziemlich interessanter Ansatz, um die Resourcen effizient zu nutzen. Sowohl was die Hardware anlangt, als auch hinsichtlich der Entwicklung und vor allem der Entwickler.
 
Man kann es auch so sehen: Java ist eine gute Wahl, weil es Eclipse gibt.

Natürlich kann man damit auch C oder andere Programme entwickelt, aber nicht so einfach.

PHP würde ich jedoch niemals empfehlen. Es ist und bleibt eine der schlechtesten Programmiersprachen. Wer damit anfängt, bringt sich selbst nur eine Menge blöde Dinge bei. Wer schon programmieren kann, der lacht über PHP und geht weiter. Wer Anfänger ist erkennt das nicht und glaubt am Ende, dass PHP ernst gemeint ist.
 
F_GXdx schrieb:
PHP würde ich jedoch niemals empfehlen. Es ist und bleibt eine der schlechtesten Programmiersprachen. Wer damit anfängt, bringt sich selbst nur eine Menge blöde Dinge bei. Wer schon programmieren kann, der lacht über PHP und geht weiter. Wer Anfänger ist erkennt das nicht und glaubt am Ende, dass PHP ernst gemeint ist.

Hm, so hab ich das nie wahrgenommen aber ich muss eins zugeben. In diesem Satz steckt doch etwas Wahrheit. Ich hab PHP immer umgangen und eine weit komplexere Methode gewählt was im Nachhinein sicherlich eine gute Wahl war. Es hat nie diesen Eindruck gemacht, es könnte die Anforderungen die ich an mein Programm stellen musste, auch erfüllen.

Auch diese verwässerte Typisierung wie in Perl lässt mich immer wieder schaudern vor schlechtem Code.

Es hat auch seine Vorteile durch die Plattformunabhängigkeit und dynamik... aber für mich haben mittlerweile andere PHP den Rang abgelaufen.
 
Man kann auch mit PHP guten Quelltext produzieren, nur ist es "schwieriger", da man nicht gezwungen wird. Für einen Anfänger ist oben drein noch das Problem, dass man im Internet viele sogenannte "lösungen" für Probleme findet, die aber von schlechter Quelltextqualität sind. Wenn man diese als Anfänger adaptiert, lernt man halt nicht guten PHP Quelltext zu produzieren....sondern nur etwas, was halt funktioniert (es gibt auch leute denen reicht das).
 
Bezahlen euch eure Auftraggeber dafür, dass der Code hübsch aussieht oder dafür, dass er tut, was er soll?

Du kannst außerdem auch in anderen Sprachen totale Grütze schreiben. Ich hab in C mal eine Kette von Pointer-Aufrufen geschrieben, die auf einem 19"-Monitor länger als der Darstellungsbereich war.
 
Daaron schrieb:
Bezahlen euch eure Auftraggeber dafür, dass der Code hübsch aussieht oder dafür, dass er tut, was er soll?

Du kannst außerdem auch in anderen Sprachen totale Grütze schreiben. Ich hab in C mal eine Kette von Pointer-Aufrufen geschrieben, die auf einem 19"-Monitor länger als der Darstellungsbereich war.

Ja, Code der Funktioniert ist das eine. Die andere Seite ist Professionalität. Code ist halt nicht nur an Funktionalität gebunden. Wenn er nicht lesbar, verständlich oder gar nicht erweiterbar ist, war deine Arbeit nicht gerade Wertvoll.

Ich Plane meine Software lieber vorher gut und lass mir Zeit bei der Programmierung, als sie nachher untergehen zu sehen.
 
Es geht bei der Quelltextqualität nicht (nur) ums aussehen... vieles was man an Beispielen für PHP findet ist einfach hoffnungslos falsch und am Ende wundert man sich warum einen der Server gehackt wurde. "Der Code funzt" ist einfach kein Qualitätskriterium wenn Überprüfungen, kontextsensitive Behandlung und Fehlerbehandlung fehlen... das ist dann ein Freifahrtschein für Scriptkiddies die sich mal mit SQL-Inhection, XSS und was auch immer austoben wollen.

Klar kann man solchen Mist auch in anderen Sprachen produzieren, aber es existieren wesentlich weniger solche Beispiele als frei verfügbarer Code im Web und meistens ist er dann auch mit entsprechenden Warnungen kommentiert. Aber bei PHP ist die "hauptsache es funzt" Fraktion recht groß und ziegt ihr Machwerk der Öffentlichkeit...
 
Das ist dann aber auch eine Frage der Ausbildung. Wenn deine Ausbilder dir nie erklärt haben, warum man "SELECT * FROM bla WHERE id='".$_GET['id']."'" nicht macht, dann ist dir einfach nicht mehr zu helfen.

Außerdem: "tut was es soll" bedeutet auch, dass es nicht noch etwas tut, dass es definitiv nicht soll. "tut was es soll" schließt Sicherheitslücken und andere Bugs explizit aus.
 
Der "Ausbilder" für viele Anfänger ist das Web... und wenn man dort eben viele solche Beispiele unkommentiert vorfindet dann ist das schlecht. Dennd er Anfänger kann das nicht selber bewereten dass da noch etwas fehlt, für ihn sieht es erst mal so aus als würde der Code das gewünschte machen. Dass dies nicht der Fall ist merkt er erst zu spät...

Deswegen schrieb ich ja auch nicht von "tut was es soll" sondern von "funzt" ;-)
 
@Daaron Das ist ja genau das was ich meine, du findest im Internet leider häufig solche "Lösungen". Ok, mittlerweile vielleicht auch nicht mehr, kann ich nicht sagen, da ich PHP schon lange nicht mehr gemacht habe.

Btw. diese Einstellung "tut was es soll" ist - meiner Meinung nach - eins der größten Probleme dieser Branche. Ich sehe Programmierung als Ingenieursarbeit (ok, heißt ja auch eigentlich Software engineering). Es gibt Verfahren und Methodiken zum ENTWURF einer Software. Dazu gehören ordentliches Requirements Engineering, Software-Architektur (z.b Patterns), UML Diagrame, Testspezifikation etc. Bevor ich also eine Software schreibe, plane ich sie erstmal (wie Highstorm). Durch solche Planung kann man dann nämlich auch schnell sehen, wo potentielle Sicherheitslöcher sind oder wo es Performance Probleme geben kann. Klar, ich kann mich auch einfach hinsetzen und das alles runterhacken, dann brauch ich nicht so viel Zeit und der Kunde spart Geld. Am Ende hat der Kunde etwas, was formal vllt funktioniert aber was qualitativ schlecht ist (schlecht wartbar, schlecht anpassbar, schlecht erweiterbar.....usw.).
 
Zurück
Oben