Welche Programmiersprache lernen / Buchempfhelung

Im Grunde spielt es keine wirkliche Rolle, mit welcher Sprache man das Programmieren lernt, weil sich, anders, als noch vor 20 Jahren, in Minuten eine Einführung mit Beispielen im Web findet. Mitte der 1990er war ich hingegen mit meinem C64 ohne Bücher ganz schön aufgeschmissen...

Im Thread wurden ja bereits einige Sprachen und Bücher genannt, die alle für diesen Zweck in Ordnung sind. Ohne bestimmte Reihenfolge empfehle ich C, Python 3 und Lua.

Als erstes Projekt macht sich ein Roguelike gut, das lässt sich in jeder Sprache umsetzen.
 
Moin,

zu Pascal bin ich tatsächlich die letzten Jahre wieder zurückgekommen (das Leben zieht doch immer wieder Kreise :D ): ich betreue ein größeres Programm in der Firma, das in Delphi realisiert wurde. Delphi (Nachfolger von Turbo Pascal) wird von Embarcadero vertrieben - und ist leider - von der Community Edition abgesehen - nicht ganz billig - uuuuunnddd natürlich nur für Windows erhältlich. Grmpf.

Wir sind hier in einem BSD-Forum. Trotzdem, unter Linux nutze ich Lazarus als IDE für den FPC (free pascal compiler) - zu BSD kann ich leider wenig sagen, da ich momentan nur ein FreeBSD in einer VM betreibe; Pakete dafür gibt es jedenfalls(*) und testweise hab ich die auch mal installiert- geht, lässt sich starten.

Lazarus kann unter vielen Aspekten mit Delphi mithalten; ganz kompatibel ist es aber nicht. Der FPC ist eine Implementierung von Object Pascal.

Mein Tipp: mal ansehen.

Ciao,
Photor



(*) es gibt auch eine Methode, Lazarus auch direkt von der Home-Page zu installieren
 
...anders, als noch vor 20 Jahren, in Minuten eine Einführung mit Beispielen im Web findet. Mitte der 1990er war ich hingegen mit meinem C64 ohne Bücher ganz schön aufgeschmissen...

Genau darin sehe ich eine Gefahr für das "richtige lernen" - da man sich ja eh alles immer irgendwie online zusammensuchen kann, bleibt der Eigenanteil am lernen aus... Die Fachbücher damals hatte man quasi eingeatmet - da ja nix anderes ging, ausser, sich mit Gleichgesinnten auszutauschen, sofern es denn welche in erreichbarer Nähe gab; BTX/Online/Akustikkoppler war damals nicht bei jedem gang und gäbe, da unbezahlbar usw...

Heutzutage ertappe ich mich auch oft dabei, ein Fachbuch eher als .pdf oder ebook aufm Tablet zu haben, anstatt im Bücherregal...

Für den OP als Buchempfehlung hätte ich da nach Durchsicht des Regals dann auch noch (bin sehr C-lastig, wie ich grad selber feststellen musste):

Teach yourself C in 21 days, Aitken & Jones, SAMS publishing

The Indispensable Guide to C, Paul Davies, Addison-Wesley
 
"Einführung in die Informatik", H.P. Gumm/M. Sommer
"Clean Code" Robert C. Martin

Also "Clean Code" habe ich als pdf gefunden und überflogen. Doch wie der Titel schon sagt, geht es mehr darum, "sauber" zu programmieren, wie anhand von vielen Beispielen erklärt wird. Es ist auch eine philosophische Einführung in das "saubere" Programmieren. Was ich suche ist aber mehr etwas zum graphischen Entwurf einer Skizze mit Bleistift und Papier, zum ersten allgemeinen und methodischen Vorgehen, um ein Problem/Konzept zunächst mal optisch darzustellen, also Kästen, Pfeile, und sich dann zu veranschaulichen, wo man dann "if", "while" oder sonstige Loops einbauen würde. Anhand von praktischen Beispielen. Ich weiß nicht, ob es sowas überhaupt gibt, oder ob in der Lehre im Allgemeinen, sei es an der Uni oder sonst wo, gleich mit einer Sprache begonnen wird (z.B. php) und man dann gleich einfach so mit if..else, while, case, for, etc anfängt.
 
Daher sollte man sich nicht so sehr an der Sprache festklammern, stattdessen besser an dem Problem, welches man lösen möchte. Wer Microcontroller programmiert, kommt beispielsweise um C kaum herum. Wer Dinge automatisieren möchte, wird praktisch zwingend zu Python greifen müssen. Und so weiter.

Zur Vermeidung der Paralyse durch Analyse würde ich auch mit einer lebendigen Sprache einfach anfangen. Wer sowieso in BSDForen.de unterwegs ist, dem lege ich gerne Python nahe.

Wenn es um berufliches Fortkommen geht, ist die Sprache dann auch nur ein Element. Wichtiger ist es, zumindest Teile des um die Sprache herum bestehenden Technologiestacks zu gut beherrschen.

Der Technologiestack ist in der Praxis oftmals gefühlt auch größer als die Sprache selbst. :)

Ich mache Beruflich vor allem klassische Systemadministration und habe da bislang nur sehr wenig Programmieren müssen, das wenige aus meiner Ausbildungszeit ist lange verschwommen.

Die klassische Systemadministration schrumpft (nicht nur) in meinem Bereich zugunsten von DevOps. Ich glaube, als Systemadministrator kommt man auf Dauer nicht um ein Mindestmaß an Programmierung herum, aber das ist ein Thema für einen anderen Thread.

Ich bin nicht auf die Idee gekommen, Pascal zu empfehlen, weil ich nicht genau weiß, wo man da heute ansetzen kann.

Ich würde heute auch unter keinen Umständen Pascal empfehlen. Die Sprache ist zwar recht schön, hat aber enorme Nachteile:
  • Sobald man den Einsteiger-Level verlässt, fällt einem der eklatante Mangel an Bibliotheken für zeitgenössische Themengebiete auf die Füße.
  • Falls man seine Lebensunterhalt teilweise oder ganz mit IT bestreiten möchte, ist man mit populären Sprachen deutlich besser aufgehoben.
  • Es gibt für Pascal nur schrumpfende Online-Communites und kaum noch Offline-Events. Wer nicht gerade in Tuntenhausen wohnt, wird in seiner Umgebung Meetups, Barcamps, eine Softwerkskammer o.ä. rund um etablierte und zukunftsweisende Sprachen sowie deren Technologiestacks finden. Ich kann den Besuch solcher Events nur wärmstens empfehlen - Pascal als Thema ist dort aber ziemlich unterrepräsentiert.
 
... mehr etwas zum graphischen Entwurf einer Skizze mit Bleistift und Papier, zum ersten allgemeinen und methodischen Vorgehen, um ein Problem/Konzept zunächst mal optisch darzustellen, also Kästen, Pfeile, und sich dann zu veranschaulichen, wo man dann "if", "while" oder sonstige Loops einbauen würde ...

Du meinst sowas wie PAP - Programmablaufplan? Dafür gibts sogar ne DIN / ISO: DIN 66001, ISO 5807, oder auch Nassi-Shneiderman-Diagramm, DIN 66261

Auch dafür musst du dein Problem in kleine Häppchen zerlegen (gedanklich, oder auf Papier) und dann den Lösungsweg in diese einzelnen Schritte zerlegt aufmalen - idealerweise unter Einhaltung der genormten Symbole. Es gibt auch Programme dafür - PAP-Designer sei nur einer davon.
Heutzutage ist das bei derartig komplexen Thematiken aber eher schon wieder etwas aus der Zeit gefallen. Zu heutigen komplexen Programmen oder Programm-Suites existiert vermutlich in den wenigsten Fällen noch ein solches Diagramm - allenfalls zu Unterprogrammen/-funktionen/-themen.

Im o.g. genannten Buch "Einführung in die Informatik" wird zumindest in Kap. 2 auf die Programmierung an sich eingegangen, allerdings alles halt sehr kurz gehalten, jeder liest Bücher auch anders und zieht sich mehr oder weniger Info raus, bzw kann das gelesene umsetzen.

- Anstatt eines PAP könntest du z.B. auch eine Problemlösung in normaler Sprache oder Pseudocode hinschreiben, hatte ich manchmal gemacht, hilft ungemein (mir zumindest);
Also z.B.:
Nimm ZahlA
Multipliziere mit x
Dividiere durch Wurzel2
usw.

- Fang klein an, und stell dir kleine Aufgaben; gib z.B. erstmal alle Zahlen von 0 - 9 und Buchstaben von A-Z u. a-z aus; dann in umgekehrter Reihenfolge, dann Aa1Bb2 usw; steigere dich dann, z.B. mit dem Ersetzen von Zeichen nach einem Bestimmten Schema (A=T, F=Y usw) und schreibe ein Programm, welches einen Text wandelt;

- Programmiere einen rudimentären Taschenrechner (nimm 2 Ganzzahlen und die Verarbeitungsvorschrift, also +, -, *, / und verarbeite es im Programm zum Ergebnis, gib dieses aus)

- Programmiere einen FizzBuzz :D

-- und so steigerst du dich jeden Tag;

Wenn du dann mal nen 3D-Mandelbrot-Generator mit Echtzeit-"Mausflug" und GUI programmiert hast, sagst nochmal Bescheid :D

Teilweise enthalten die genannten Lehrbücher zu den jeweiligen Sprachen auch Beispielaufgaben bzw ist das Internet deine Quelle

Als ganz nett empfand ich z.B. auch die Videos in YT, von The Coding Train, speziell die in "Processing".

@Azazyel - wie kommst du genau auf Tuntenhausen?? Da bin ich fast 20 Jahre aufm Weg zur Arbeit durchgefahren :D
 
Wer sowieso in BSDForen.de unterwegs ist, dem lege ich gerne Python nahe.

Python hat außerdem den (nicht nur) für Anfänger großen Vorteil, dass der Interpreter verständliche Fehlermeldungen ausgibt und es recht wenig Fallstricke gibt. Ganz anders als z.B. C, wo schon so mancher Anfänger an für ihn unerklärlichen Segmentation Faults oder noch schöner Bus Error verzweifelt ist...

Auch dafür musst du dein Problem in kleine Häppchen zerlegen (gedanklich, oder auf Papier) und dann den Lösungsweg in diese einzelnen Schritte zerlegt aufmalen - idealerweise unter Einhaltung der genormten Symbole. Es gibt auch Programme dafür - PAP-Designer sei nur einer davon.
Heutzutage ist das bei derartig komplexen Thematiken aber eher schon wieder etwas aus der Zeit gefallen. Zu heutigen komplexen Programmen oder Programm-Suites existiert vermutlich in den wenigsten Fällen noch ein solches Diagramm - allenfalls zu Unterprogrammen/-funktionen/-themen.

Ich kann da noch den Tipp zu geben, auch bei kleinen, privaten Basteleien etwas "agil" zu denken. Wenn ich ein kleines Programm schreibe, habe ich natürlich irgendwo einen großen Plan im Kopf. Aber beim Schreiben selbst, gehe ich trotzdem in kleinen, interativen Schritten vor. Bei jedem meiner Projekte ist der erste Commit ein Hello World in der jeweiligen Sprache, also so ziemlich das minimal mögliche Programm, dazu eine Basiskonfiguration für das Build System und so weiter. Wenn es Kommandozeilenoptionen gibt, baue ich z.B. im nächsten Schritt einen entsprechenden Parser ein. Dann schön Schrittweise die Funktionalität für die einzelnen Optionen. Wenn ich Verbesserungsmöglichkeiten am schon vorhandenen Code sehe, refactore ich ihn entsprechend. Und so weiter.
Das hat den Vorteil, dass man sich jeweils nur mit einem kleinen Teilproblem beschäftigen muss. Das Risiko, dass man den Überblick verliert, ist dadurch viel kleiner. Durch die feingranularen Commits kann man Bugs viel besser nachvollziehen. Und man hat viele Punkte, an denen man seine Arbeit unterbrechen kann.
 
Programmiersprachen zu lernen, nur um zu lernen - dazu konnte ich mich nie aufraffen. Für mich stand immer eine konkrete Aufgabe da, die ich bearbeiten wollte und für die ich mich in eine neue Sprache eingearbeitet hab. Oder zumindest soweit, dass ich meine Aufgabe lösen konnte. In 2000 war es PHP, weil wir eine bestimmte Webanwendung bauen wollten und der LAMP-Stack damals ganz klar mit P wie PHP buchstabiert wurde. Später mit zunehmender Nutzung von FreeBSD kam klassische (Bourne) Shell dazu. Und letztes Jahr Ruby, weil ich zunehmend mit dem www/h2o Webserver arbeite, der das Subset MRuby als Skriptsprache von Haus aus mitbringt (damit kann man tolle Konfigurationen bauen, bei denen man sich in Nginx einen abbrechen würde). Weil heute im Web leider kaum noch etwas ohne JavaScript geht - im Frontend genauso wie im Backend (Node.js) - werde ich mich wohl auch damit demnächst mehr beschäftigen müssen.

Die Aufgabenstellung würde jedenfalls immer meine Wahl der zu lernenden Programmiersprache beeinflussen:

Für kleine Utilities: Shell oder Python - das wäre also meine Empfehlung an den OP.
Für "irgendwas Web": PHP und/oder JavaScript
Für etwas, was potenziell nah am OS ist: C
 
Hmm, das ist aber eine zweischneidige Sache. Natürlich ist es effizient, Programmieren quasi "begleitend" zu lernen, wenn man ein konkretes Problem hat, das man lösen möchte. Für den allerersten Anfang würde ich das aber gerade nicht empfehlen, da man in gewisse Fallen tappen kann. Erstens hat es durchaus einen Grund, dass viele Lehrbücher mit äußerst simplen "Modellproblemen" starten. Wenn man sich gleich auf ein "real world" Problem stürzt besteht die Gefahr, dass man (weil noch zu viele Grundlagen fehlen) Murks programmiert. Man sucht sich dann Häppchen in Blogs, auf Stackoverflow, usw, die so ungefähr passen und bastelt zusammen, ohne es wirklich zu durchblicken -- dabei kommt in der Regel kein guter Code heraus. Die zweite große Gefahr ist die Wahl weniger gut geeigneter Tools. Was das angeht ist PHP für mich ein sehr gutes Beispiel. Auch ich bin da "vorbeigekommen", es hat mich beim Lernen aber wohl eher gebremst. PHP ist leider geradezu darauf ausgelegt, einfachere Dinge irgendwie zusammenwursteln zu können. Bei Sprachdesign und Laufzeitbibliothek hat man sich weniger Mühe gegeben, es wimmelt nur so von Inkonsistenzen. Sich daran zu gewöhnen ist fürs Lernen eher schlecht.

Wenn man gewisse Grundlagen schon hat ist es dagegen IMHO der perfekte Weg, neues zu lernen. Man sollte einfach nur nicht den zweiten Schritt vor dem ersten tun. Noch ein paar konkrete Anmerkungen:

Ruby, weil ich zunehmend mit dem www/h2o Webserver arbeite, der das Subset MRuby als Skriptsprache von Haus aus mitbringt (damit kann man tolle Konfigurationen bauen, bei denen man sich in Nginx einen abbrechen würde)
Nunja, diesen Webserver kenne ich jetzt nicht, aber ich habe mal hervorgehoben, was für mich hier eine kleine Warnlampe ist. Ich zitiere dazu frei einen ziemlich fähigen Berater, den wir vor kurzem im Haus hatten, zum Hype von konfigurierbaren und "customizable" Plattformen: "Jede Konfigurationssprache, wenn man immer mehr damit tun können will, wird irgendwann Turing-vollständig. Man programmiert dann anstatt zu konfigurieren, nur leider in einer denkbar miesen Programmiersprache".

Weil heute im Web leider kaum noch etwas ohne JavaScript geht - im Frontend genauso wie im Backend (Node.js)
Von Javascript würde ich jedem Anfänger dringend abraten. Erstens beobachten wir hier clientseitig gerade eine Entwicklung, die zu ziemlich schlechten Architekturen führt (indem die Vorteile der Web-Architektur einfach weggeworfen werden, wie z.B. Zustandslosigkeit, leichte Integrierbarkeit über Links, usw) -- der Trend geht dahin, jeden "Mist" als "SPA" zu entwerfen, mit Angular, React und wie sie alle heißen. Dabei funktioniert Javascript am besten so, wie es ursprünglich gedacht war: zur clientseitigen Anreicherung einer Webanwendung.[1] Zweitens ist Javascript eine recht spezielle Sprache, und wird von vielen gar nicht richtig verstanden. Zwar hat der neueste ECMAScript Standard keywords wie "class" eingeführt, trotzdem gibt es eigentlich keine Klassen in Javascript -- die Objektorientierung funktioniert hier mit "Prototypes", was ein völlig anderer Ansatz ist als man es normalerweise kennt. Wirklich gutes Javascript kann man nur schreiben, wenn man das verstanden hat.

Das soll jetzt nicht heißen, dass ein Anfänger, der eine Webanwendung entwickeln will, auf keinen Fall den Client mit etwas simplem JavaScript aufhübschen sollte --- sowas geht natürlich immer. Aber die Entwicklung von komplexen UI-Komponenten, oder gar einer SPA (in den wenigen Fällen, in denen das Sinn ergeben könnte, z.B. bei so etwas wie google maps, was definitiv nichts mehr mit einer Webanwendung zu tun hat), sollte man besser vertagen, bis man genug Programmiererfahrung hat.

Bleibt die Frage, ob es sinnvoll ist, Javascript im Backend zu verwenden (also node.js). Dazu kann ich jetzt wenig sagen, weil ich es nie getestet habe. Vielleicht kann man damit ganz gut arbeiten, allerdings würde ich aus oben genannten Gründen Anfängern davon abraten. Es gibt viele Sprachen, die einfacher zu lernen sind, und durchaus geeignet sind für Backends von Webanwendungen. Nur als EIN Beispiel, wir verwenden bei der Arbeit C# mit .NET Core und AspNetCore MVC. Ruby wird viel benutzt und offenbar mit Erfolg. Java ist eher mit Vorsicht zu genießen. PHP -- siehe oben, IMHO Finger weg....

---
[1] bin hier vielleicht etwas vom Threadthema abgekommen, sorry ... falls es dennoch jemanden interessiert, das hier halte ich für eine sehr gute Sammlung von Empfehlungen zur Architektur von Webanwendungen: https://roca-style.org/ -- mit "progressive enhancement" steckt da auch DIE Antwort auf die Behauptung drin, im Web gehe nichts mehr ohne Javascript
 
Nunja, diesen Webserver kenne ich jetzt nicht, aber ich habe mal hervorgehoben, was für mich hier eine kleine Warnlampe ist. Ich zitiere dazu frei einen ziemlich fähigen Berater, den wir vor kurzem im Haus hatten, zum Hype von konfigurierbaren und "customizable" Plattformen: "Jede Konfigurationssprache, wenn man immer mehr damit tun können will, wird irgendwann Turing-vollständig. Man programmiert dann anstatt zu konfigurieren, nur leider in einer denkbar miesen Programmiersprache".
Ganz kurz dazu: MRuby ist nichts, was sich die H2O Entwickler ausgedacht haben, sondern eine mittlerweile ganz gut eingeführte Ruby Version für embedded Systeme. Das ist schon recht mächtig, versucht aber wg. des Fokus auf embedded auch etliches zu vermeiden. Ich finde das nicht dumm, weil man den Resourcenbedarf eines Webservers ja gering halten will. Aber gut, man wird sehen, wo es hin geht. Vielleicht gebe ich Dir in ein paar Jahren recht.


mit "progressive enhancement" steckt da auch DIE Antwort auf die Behauptung drin, im Web gehe nichts mehr ohne Javascript
Oh, da bin ich voll auf Deiner Seite. Eine vernünftige und accessible Webseite muss erstmal vernünftiges HTML bringen. Das kann man dann mit CSS und JS enhancen. Aber gerade im Bereich Accessibility sehe ich, dass selbst die eingefleischtesten Verfechter von sauberen HTML immer öfter zu JavaScript-Ergänzungen raten, um möglichst viele NutzerInnen zu bedienen mit ihren jeweiligen Schwierigkeiten (von Keyboard-Bedienung, über Seh- oder Leseschwächen etc.). Und für die Generierung von Webseiten bzw. um CSS und Javascript-Pakete zu erstellen, kommst Du um Node.js und NPM praktisch nicht mehr herum. Beispiel: Bis vor kurzem gab Google nach Hinweise, wie man mit ImageMagick Bilder optimal fürs Web komprimieren kann. Heute werden nur noch JavaScript-basierte Lösungen oder Online Services empfohlen. Und das ist an allen Ecken und Enden so... Selbst die PHP-Bastion WordPress hat mit seinem noch recht neuen Block-Editor "Gutenberg" voll auf JS gesetzt. Man kann noch hintenrum mit PHP Blöcke entwickeln - aber ob das noch lange Bestand haben wird, ist nicht mehr sicher. Daher: Wer sich für Web interessiert, muss sich (auch) in JavaScript einarbeiten - ob sie will oder nicht.
 
... Ada, Assembler, BASIC, C(++), FORTRAN, Java, LISP, Python, Shell-Skript, uvm... du hast die Wahl.

Für eigentlich (so ziemlich) alle gibts Bücher oder im Inet Informationen.
Probleme in einzelne Teilprobleme zu zerlegen - da kann man gut mit gesundem Menschenverstand loslegen.

Ich bin den Weg BASIC (1987, Schneider CPC) -> Assembler (Z80, 68000, 8086) -> Siemens Simatic S5 -> C -> Fortran -> Python -> Ada (heute) gegangen und würd es heute vermutlich wieder so machen (ok, die 8- und 16-Bitter sowie die alte Simatic weglassen), aber es spricht nichts dagegen, z.B. heute auch mal mit (Free)BASIC oder C anzufangen, um mal die Grundlagen zu verstehen und erste (Miß)Erfolge zu erfahren;
Ich hatte zwar hier und da formale Programmierausbildung (bezogen auf die eine oder andere o.g. Sprache) genossen, jedoch keine "Informatik" im eigentlichen Sinne - ich würde mich auch nicht als Programmierer bezeichnen, aber meine Programmier_Kenntnisse_ haben im Berufsleben bislang immer ausgereicht.

In Linux und den *BSD ist der Einstieg in C kinderleicht - zumindest leichter als mit Windows wie ich persönlich meine, keiner muss einem gross was zeigen, in C kann man sich an einem Nachmittag im Internet einlesen und erste Compilate erstellen.

Ggf kannst du auch einen Programmierkurs mitmachen?

Leg einfach los und programmiere einfach mal was, Schritt für Schritt - und du wirst besser werden
(frei nach dem Zitat "mache tausende und abertausende Fotos - und du wirst besser werden" - von Ansel Adams?).
 
Und welcher Editor ist zum Programmieren unter FreeBSD zu empfehlen? Ich nutze bluefish, ich denke, der ist nicht schlecht. Allgemein bekannt ist auch sublime, aber der funktioniert unter FreeBSD wohl nur unter linux-emu, was ich etwas eigenartig finde. Viele eher unter Linux bekannte Editoren scheint es für FreeBSD nicht zu geben...
 
Und welcher Editor ist zum Programmieren unter FreeBSD zu empfehlen? Ich nutze bluefish, ich denke, der ist nicht schlecht. Allgemein bekannt ist auch sublime, aber der funktioniert unter FreeBSD wohl nur unter linux-emu, was ich etwas eigenartig finde. Viele eher unter Linux bekannte Editoren scheint es für FreeBSD nicht zu geben...

Abseits der kommerziellen Königsklasse ist Visual Studio Code momentan aus guten Gründen der Code-Editor der Wahl.

Sobald dieser letzte Issue beseitigt ist, sollte auch derzeitnahen Aufnahme in den offiziellen FreeBSD-Ports-Tree nichts mehr entgegenstehen.
 
Ich wusste gar nicht, dass Notepad++ im Ranking so hoch steht. Also da gefällt mir Bluefish wirklich besser, welches dort überhaupt nicht aufgeführt ist. Hingegein steht sublime auch nicht schlecht. Warum gibt es das nicht nativ für FreeBSD, sondern nur mit Linux-Emu?

Aber mal eine andere Frage: Gibt es irgendetwas, womit sich php-scripts auf Fehler untersuchen lassen? Wenn es einfach nicht funktioniert und man nur eine weiße Webseite im Browser ohne Fehlermeldung bekommt, hilft das nicht weiter...
 
@cabriofahrer Das geht mit Atom und VisualStudioCode recht gut. Ich glaub die extension heißt php debug bei beiden Programmen.
Ansonsten einfach die Fehler in eine Datei schreiben lassen. Natürlich den Dateiort auf dem Webserver vor fremden Zugriffen schützen.
Fehlerausgaben sind auf php.net gut beschrieben.
 
Wie geht das? Und Atom und VisualStudioCode gibt es für FreeBSD nicht.
Über die php.ini. Die meisten Webspace Anbieter erlauben meistens die parameter anzupassen.

https://www.php.net/manual/de/errorfunc.configuration.php#ini.error-log

Ansonsten gibt es auch parameter, die den Fehler direkt im Browserfenster anzeigt. Ist natürlich für eine Produktiv laufende Seite nicht zu empfehlen...
Aber wie schon gesagt, einfach PHP Dokumentation lesen (https://www.php.net/docs.php).

Zum Thema Atom und VSCode (https://github.com/tagattie/FreeBSD-VSCode) ggf. selber bauen. Electron gibt es als Paket.
 
Editordiskussionen sind sowas von 1990. Seitdem es das Language Server Protocol gibt, kann man praktisch jedem Editor sehr gutes Verständnis jeder erdenklichen Programmiersprache beipulen...
 
Im Prinzip solltest du dir merken das eine Programmiersprache nur ein Werkzeug ist und wenn du eine Schraube in die Holzwand bekommen willst kannst du den Schraubendreher oder den Hammer nehmen. Beides bekommt die Schraube in die Wand, nur nicht beides ist die beste Idee. Du kannst z.B Webentwicklung mit PHP, Java(Script) Serverseitig realisieren, du kannst es aber auch mit C++ oder BASIC tun. Wenn du eine Neigung zur Perversion hast sogar mit Assembler.

Was ich eigentlich sagen will ist das du dir überlegst was dein Programm können muss und wo die Schwerpunkte liegen, dann wählst du darauf basierend die richtige Sprache aus. Vom Grundsatz sind alle Sprachen recht ähnlich zumindest was die Logik betrifft. Es macht zum Beispiel Sinn Bedingungen und Anweisungen, mathematische Funktionen, Variablen erst einmal in BASIC zu testen anstatt gleich in einer komplexeren Sprache wo ein einfaches Hallo Welt Programm mal 10 Zeilen Code hat. Wenn du wirklich mal reinschnuppern willst dann schau dir z.B mal PureBasic an, gibt es kostenlos zum testen. Auch wenn es Basic ist nutzen selbst Firmen das ganze da es speziell ist. Die Entwickler sind Assembler Nerds und der Compiler übersetzt den simplen Basic Code in sehr optimierten Assembler und somit fällt der Interpret auch gleich weg. Damit lassen sich auch sehr gut Spiele programmieren. Versuche doch mal ein Snake oder Tetris ;)
 
Es ist keine Schande, einen Algo bzw ein "Vorgehen" erstmal in ner Sprache auszuprobieren, welche man gut kann und erst dann die Implementierung in der Sprache zu vollziehen, welche man verwenden muss - sei es aus Projektvorgabe oder anderen Gründen.

Ich bin der Überzeugung, dass es Programmierer gibt, die dafür auch heute noch BASIC nehmen... :D
 
hi
Welche Sprachen nutzt Ihr zum Programmieren / wollt Ihr lernen ?
Keine mehr. Auch wenn ich finde, dass es gut ist sich andere Sprachen anzusehen, sollte man da auch in die Tiefe gehen, sie verstehen und zwar nicht nur Syntax und andere oberflächliche Dinge. Es bringt einem nicht viel eine weitere Sprache nur oberflächlich zu verstehen. Das führt dann zu dem altbekannten "X ist besser als Y, weil.."-Flamewars.

Ich würde jedem empfehlen mehrere Sprachen zu lernen, den Horizont zu erweitern. Allerdings würde ich auch jedem empfehlen das mit dem Lernen auch richtig durchzuziehen. Das heißt zu verstehen warum die Dinge so und so designed wurden, was Vor- und Nachteile sind und zwar auf einem Niveau wo man nicht ständig damit hadert, dass das nicht die bevorzugte Programmiersprache ist. Auch wenn das nicht immer stimmen mag ist ein gutes Indiz dafür, dass man eine Sprache nicht richtig versteht die Ansicht, dass et was "komisch" ist meist auf ein mangelndes Verständnis der Sprache zurückzuführen. Das ist schwierig und kann frustrierend sein. Wenn man eine Sprache gut genug beherrscht um produktiv darin zu programmieren und das meiste geradezu intuitiv funktioniert, dann eine andere Sprache nimmt, wo Dinge anders funktionieren ist bei vielen Leuten die Reaktion sie komisch, schlecht, hier und da als unterlegen zu empfinden, etc. Klar kann es Fehldesigns geben, aber wenn man gerade mal ein paar Wochen oder Monate mit einer Sprache am Rücken hat ist die Chance da was nicht zu sehen, warum das so und so ist eine größere. Also als Tipp: Die Arroganz von der Warte eines Fanboys einer anderen Sprache am Besten zumindest initial sein lassen. Das macht einen nämlich zu einem wesentlich besseren Programmierer.

Ich denke jetzt ist es an der Zeit sich eine Programmiersprache anzueignen, Python finde ich interessant wobei man mit Java Kenntnissen vllt. eher im Job voran
Das stimmt so nicht. Ob du Java oder Python nimmst spielt im großen und Ganzen keine Rolle. Wahrscheinlich hast du im Enterprise-Bereich ein wenig mehr Java und derzeit ein wenig mehr Python im Machine Learning Bereich. Allerdings halte ich die Aussage, dass eine Programmiersprache (wenn's nicht grad was wie Brainfuck ist) zu einer besseren Karriere führt für Unfug, der sich in der Realität kaum halten lässt. Du wirst auch für Erlang in großen und kleinen Firmen einen Job finden, genau so wie für PHP, Ruby, Go, oder Rust. Außerdem hast du den Effekt, dass für weniger weit verbreitete Sprachen Unternehmen ebenfalls eine kleinere Auswahl an freien Programmieren am Markt haben.

Es gibt zwar Bereiche wo es einschlägige Sprachen gibt (R zum Beispiel), aber das weißt du dann ohnehin und ich glaube davon sprichst du ganz generell.

Wenn's eine kleine Community ist gehst du auf's nächste Meetup oder Event und wenn du willst mit einem Job wieder raus. Mit vielleicht der Ausnahme von COBOL hat auch die Wahl der Sprache mittlerweile nicht mehr sonderlich viel mit der Bezahlung zu tun. Da ist vieles einfach eine durch Gefühle geleitete falsche Vorstellung.

Zum Thema lernen: Ich finde offizielle Dokumentation wird stark unterschätzt. Auch Code von Profis zu lesen. Sowohl bei schlechten Büchern als auch durch lesen von eher schlechten Code kann man sich leider schnell ungute Angewohnheiten aneignen. In vielen Fällen macht das Verstehen und Lesen der Standard-Library der Sprache sehr viel Sinn.
 
Zuletzt bearbeitet:
Zurück
Oben