[Programmierung] Welche Programmiersprachen beherrscht ihr?
- Ersteller Vigor
- Erstellt am
little tyrolean
Elder Statesman (R.I.P.)
Neugierig biste garnicht... 
Aber gut: QBasic, Pascal, das war's dann schon...
Aber gut: QBasic, Pascal, das war's dann schon...
Du hättest lieber eine Mehrfachauswahl nehmen sollen. :devil
Aber ich kann eh nur eine. :angel Und zwar C++. Habe schon (relativ) viel Erfahrung aus der Schule. Früher habe ich mit Pascal ein bischen "rumprobiert", aber seit ich C++ beherrsche und besitze, nehme ich nur noch das.
Aber ich kann eh nur eine. :angel Und zwar C++. Habe schon (relativ) viel Erfahrung aus der Schule. Früher habe ich mit Pascal ein bischen "rumprobiert", aber seit ich C++ beherrsche und besitze, nehme ich nur noch das.
C/C++, Html, PHP, Basic. Aber von beherschen kann keine Rede sein. Von jedem nur soviel angeeignet,
um die Aufgaben zu erledigen, die ich gerade vorhatte. Im Moment bin ich dabei mich intensiver mit html
und php auseinanderzusetzen, schon allein deswegen um mein Board am laufen zu halten, und neue
Funktionen zu erarbeiten, und den Style zu verbessern.
um die Aufgaben zu erledigen, die ich gerade vorhatte. Im Moment bin ich dabei mich intensiver mit html
und php auseinanderzusetzen, schon allein deswegen um mein Board am laufen zu halten, und neue
Funktionen zu erarbeiten, und den Style zu verbessern.
SilverSurfer99
gehört zum Inventar
Hab mal für Basic abgestimmt (incl. Compiler). Ein bischen MS-Quick-C ist bei mir auch noch übrig geblieben.
Hier mit Ausflug in Sicherheit/Verschlüsselungstechnik.
Welche Sprachen fehlen:
-Batches, jawohl! mit solchen Scripten ist vieles möglich: Damit kann man problemlos ein sechszeiliges Win32bit-Script schreiben, das alle 26 Laufwerke ohne Systemabfrage putzt [*g* habe aber für mich bisher keinen Verwendungszweck dieses Programmierzieles gefunden].
-REXX - eine wirklich königliche Sprache aus dem Hause IBM, die inzwischen auch auf Win32bit (W9x,ME,NT4,W2k und XP) portiert wurde. Ist zwar eine Interpretersprache und damit nicht die schnellste [Compilate sind änderungsgeschützt und 3-10mal schneller], aber damit konnte ich zB. mal eine in der Literatur ungeklärte Frage überprüfen - gehen bei hohen Zahlen die Primzahlen aus?
Was wie Zahlenspinnerei klingt, hat einen realen Hintergrund: Die heute bevorzugte asymmetrische Verschlüsselungstechnik besteht aus zwei sehr hohen Primzahlen, so dass à la PGP/RSA niemand im eigenen Namen Nachrichten versenden kann, aber alle berechtigten Zweit-Schlüsselempfänger die Nachricht lesen bzw. auf Authenzität überprüfen können. Anwendungsbeispiele sind zB. elektronische Unterschriften.
Bei der symmetrischen Verschlüsselung besitzen beide Seiten den gleichen Schlüssel, Beispiel ist die PIN bei Geldautomatenkarten (DES-Algorythmus; auch Blowfish ist ein symmetrisches Verfahren). Der augenfällige Nachteil - es ist nicht sicher feststellbar, wer die Nachricht geschrieben hat. Der Vorteil ist eine hohe Sicherheit - schon 168bit Schlüssellänge reichen, um das BKA zur Verzweiflung zu bringen, für den gleichen Sicherheitsgrad muss man asymmetrisch mit 512bit Schlüssellänge nutzen.
Asymmetrische Verschlüsselung ist um ein Mehrfaches schneller als die symmetrische Verschlüsselung und daher für Massenübertragungen geeignet. Gesicherte Übertragungen für Firmen werden häufig zusätzlich mit symmetrischen Anmeldeverfahren kombiniert.
Asymmetrische Verfahren auf Basis zweier sehr großer Primzahlen lassen sich bis heute (im Gegensatz zu symmetrischen Verschlüsselungen) nicht mathematisch cracken, sondern nur mit BruteForce - auf deutsch ALLE KOMBINATIONEN durchprobieren, bis ein sinnvolles Ergebnis angezeigt wird. Meine Sicherheits-Besorgnis war jedoch, ob es auch im hohen Bereich noch genügend Primzahlen gibt. Jeder kennt die Primzahltabellen aus der Schule, bis 100 sind es sehr viele und bis 1000 wird es immer weniger.
Um beim Austesten der Dichte von Primzahlen von mathematischen aber für mich undurchschaubaren Lösungen wegzukommen, habe ich als Lösung das 'Sieb des Erathostenos' benutzt, das schon mit Commodore64-Basic in Schleifentechnik leicht zu lösen war. Mit REXX konnte ich das Problem (im Gegensatz zu Basic) als Zahlenfeld-Raster auf Bit-Ebene lösen, also ohne gigantische Mengen von irrsinnig langen Primzahlen speichern zu müssen.
Mein Ergebnis vor drei Jahren auf einem 486-Intel nach 8 Tagen Dauerjob war, dass die Primzahlen tatsächlich sehr schnell abnehmen, aber ab einer Milliarde bis in den getesteten Bereich 1Mrd.x1Mrd. sich mit zwei Primzahlen pro hundert Zahlen stabilisieren. Somit werden uns die hohen Primzahlen auch nicht ausgehen, wenn wegen gesteigerter Rechner- und damit Bruteforce-Kapazität die Schlüssellängen permanent erhöht werden müssen.
Kritische Anmerkung: Bisher haben die US-fundamentalischen Kreise (zB. NSA mit mehr als 40.000 Spionage-Mitarbeitern, natürlich "nur zum Schutz der freien Welt") den Export von US-Verschlüsselungsprogrammen mit erhöhten Schlüssellängen unter das Ausfuhrverbot gemäß Kriegswaffenkontrollgesetz gestellt. Als aktuelle Tendenz werden große Unternehmen von 'US-Partnerstaaten' unter Druck gesetzt, bei Einsatz von Verschlüsselungsprogrammen aus europäischen Quellen ohne NSA-Backdoor-Korrumpierung einen Teilschlüssel zu hinterlegen -natürlich nur für den nicht überprüfbaren Terrorfall-, andernfalls wäre mit Sanktionen zu rechnen! Die Sanktionen geschehen dann natürlich nicht offen, sondern über das Stornieren/Ausbleiben von Aufträgen von US-Firmen, die ihrerseits mit Rüstungsaufträgen 'entschädigt werden.' Aus den Lehren der Geschichte und dem aktuellen Geschehen kann man nur eine Schluss ziehen, nämlich dass die Welt der Mächtigen nie gerecht ist und meistens ziemlich kriegerisch bleiben wird. Bleibt wachsam.
Weiterführende Literatur zum Thema Verschlüsselungssicherheit: Bruce Schneier. Beim PGP-Verschlüsselungspionier Phil Zimmermann -nach mehr als 30 von der NSA angezettelten aber gewonnenen Prozessen müde geworden- hat sich NAI (zB. Virenprüfer MacAfee) NSA-gesponsort? geopfert, die PGP-Rechte vor drei Jahren aufzukaufen, um diese jetzige Backdoor-verdächtige und daher kaufmännisch erfolglos gewordene Lösung 'mangels Marktchancen' einzustampfen.
Hier mit Ausflug in Sicherheit/Verschlüsselungstechnik.
Welche Sprachen fehlen:
-Batches, jawohl! mit solchen Scripten ist vieles möglich: Damit kann man problemlos ein sechszeiliges Win32bit-Script schreiben, das alle 26 Laufwerke ohne Systemabfrage putzt [*g* habe aber für mich bisher keinen Verwendungszweck dieses Programmierzieles gefunden].
-REXX - eine wirklich königliche Sprache aus dem Hause IBM, die inzwischen auch auf Win32bit (W9x,ME,NT4,W2k und XP) portiert wurde. Ist zwar eine Interpretersprache und damit nicht die schnellste [Compilate sind änderungsgeschützt und 3-10mal schneller], aber damit konnte ich zB. mal eine in der Literatur ungeklärte Frage überprüfen - gehen bei hohen Zahlen die Primzahlen aus?
Was wie Zahlenspinnerei klingt, hat einen realen Hintergrund: Die heute bevorzugte asymmetrische Verschlüsselungstechnik besteht aus zwei sehr hohen Primzahlen, so dass à la PGP/RSA niemand im eigenen Namen Nachrichten versenden kann, aber alle berechtigten Zweit-Schlüsselempfänger die Nachricht lesen bzw. auf Authenzität überprüfen können. Anwendungsbeispiele sind zB. elektronische Unterschriften.
Bei der symmetrischen Verschlüsselung besitzen beide Seiten den gleichen Schlüssel, Beispiel ist die PIN bei Geldautomatenkarten (DES-Algorythmus; auch Blowfish ist ein symmetrisches Verfahren). Der augenfällige Nachteil - es ist nicht sicher feststellbar, wer die Nachricht geschrieben hat. Der Vorteil ist eine hohe Sicherheit - schon 168bit Schlüssellänge reichen, um das BKA zur Verzweiflung zu bringen, für den gleichen Sicherheitsgrad muss man asymmetrisch mit 512bit Schlüssellänge nutzen.
Asymmetrische Verschlüsselung ist um ein Mehrfaches schneller als die symmetrische Verschlüsselung und daher für Massenübertragungen geeignet. Gesicherte Übertragungen für Firmen werden häufig zusätzlich mit symmetrischen Anmeldeverfahren kombiniert.
Asymmetrische Verfahren auf Basis zweier sehr großer Primzahlen lassen sich bis heute (im Gegensatz zu symmetrischen Verschlüsselungen) nicht mathematisch cracken, sondern nur mit BruteForce - auf deutsch ALLE KOMBINATIONEN durchprobieren, bis ein sinnvolles Ergebnis angezeigt wird. Meine Sicherheits-Besorgnis war jedoch, ob es auch im hohen Bereich noch genügend Primzahlen gibt. Jeder kennt die Primzahltabellen aus der Schule, bis 100 sind es sehr viele und bis 1000 wird es immer weniger.
Um beim Austesten der Dichte von Primzahlen von mathematischen aber für mich undurchschaubaren Lösungen wegzukommen, habe ich als Lösung das 'Sieb des Erathostenos' benutzt, das schon mit Commodore64-Basic in Schleifentechnik leicht zu lösen war. Mit REXX konnte ich das Problem (im Gegensatz zu Basic) als Zahlenfeld-Raster auf Bit-Ebene lösen, also ohne gigantische Mengen von irrsinnig langen Primzahlen speichern zu müssen.
Mein Ergebnis vor drei Jahren auf einem 486-Intel nach 8 Tagen Dauerjob war, dass die Primzahlen tatsächlich sehr schnell abnehmen, aber ab einer Milliarde bis in den getesteten Bereich 1Mrd.x1Mrd. sich mit zwei Primzahlen pro hundert Zahlen stabilisieren. Somit werden uns die hohen Primzahlen auch nicht ausgehen, wenn wegen gesteigerter Rechner- und damit Bruteforce-Kapazität die Schlüssellängen permanent erhöht werden müssen.
Kritische Anmerkung: Bisher haben die US-fundamentalischen Kreise (zB. NSA mit mehr als 40.000 Spionage-Mitarbeitern, natürlich "nur zum Schutz der freien Welt") den Export von US-Verschlüsselungsprogrammen mit erhöhten Schlüssellängen unter das Ausfuhrverbot gemäß Kriegswaffenkontrollgesetz gestellt. Als aktuelle Tendenz werden große Unternehmen von 'US-Partnerstaaten' unter Druck gesetzt, bei Einsatz von Verschlüsselungsprogrammen aus europäischen Quellen ohne NSA-Backdoor-Korrumpierung einen Teilschlüssel zu hinterlegen -natürlich nur für den nicht überprüfbaren Terrorfall-, andernfalls wäre mit Sanktionen zu rechnen! Die Sanktionen geschehen dann natürlich nicht offen, sondern über das Stornieren/Ausbleiben von Aufträgen von US-Firmen, die ihrerseits mit Rüstungsaufträgen 'entschädigt werden.' Aus den Lehren der Geschichte und dem aktuellen Geschehen kann man nur eine Schluss ziehen, nämlich dass die Welt der Mächtigen nie gerecht ist und meistens ziemlich kriegerisch bleiben wird. Bleibt wachsam.
Weiterführende Literatur zum Thema Verschlüsselungssicherheit: Bruce Schneier. Beim PGP-Verschlüsselungspionier Phil Zimmermann -nach mehr als 30 von der NSA angezettelten aber gewonnenen Prozessen müde geworden- hat sich NAI (zB. Virenprüfer MacAfee) NSA-gesponsort? geopfert, die PGP-Rechte vor drei Jahren aufzukaufen, um diese jetzige Backdoor-verdächtige und daher kaufmännisch erfolglos gewordene Lösung 'mangels Marktchancen' einzustampfen.
SilverSurfer99
gehört zum Inventar
Alles OffTopic!
"Sag mal die Quelle deiner kleinen Autobiographie! Oder hast du das wirklich selber geschrieben?"
Genauer gesagt habe ich es miterlebt. Und da ich seit HP97/41, Commodore64, in 1983 IBM-XT (anfangs mit 0,064MB Hauptspeicher!).. bei Bits und Bytes geblieben bin mit Schwerpunkt IT-Sicherheit, auch mit Ausflügen zu den IBM-Mainframes, kommt so einiges zusammen.
Der letzte Hinweis "Als aktuelle Tendenz werden große Unternehmen von 'US-Partnerstaaten' unter Druck gesetzt, bei Einsatz von Verschlüsselungsprogrammen aus europäischen Quellen ohne NSA-Backdoor-Korrumpierung einen Teilschlüssel zu hinterlegen -natürlich nur für den nicht überprüfbaren Terrorfall-, andernfalls wäre mit Sanktionen zu rechnen!" stammt aus informellen Gesprächen bei einem deutschen Bankenseminar. Phil Zimmermann und seinen Mut habe ich mal vor dreieinhalb Jahren bei einem Vortrag im Berliner ICC bewundert.
Bruce Schneiers Buch "Angewandte Kryptographie" 844 S./addison-Wesley ist nebenbei ein höchst spannendes Buch, wer sich an der vielen Mathematik nicht stört. Und ziemlich praxisnah, wie am Beispiel DES-56bit abzulesen ist: Durch Internetzusammenschluss mehrerer Tausende PCs wurde diese Codierung vor drei Jahren mehrfach in wenigen Monaten durch Bruteforce gebrochen, weswegen die meisten europäischen Kreditinstitute seit gut zwei Jahren (zwangsweise durch die Aufsichtsbehörden!) Triple-DES mit 156bit für Geldautomaten-PINs einsetzen. Deswegen auch die Anmerkung mit dem Wachsam bleiben.
"Sag mal die Quelle deiner kleinen Autobiographie! Oder hast du das wirklich selber geschrieben?"
Genauer gesagt habe ich es miterlebt. Und da ich seit HP97/41, Commodore64, in 1983 IBM-XT (anfangs mit 0,064MB Hauptspeicher!).. bei Bits und Bytes geblieben bin mit Schwerpunkt IT-Sicherheit, auch mit Ausflügen zu den IBM-Mainframes, kommt so einiges zusammen.
Der letzte Hinweis "Als aktuelle Tendenz werden große Unternehmen von 'US-Partnerstaaten' unter Druck gesetzt, bei Einsatz von Verschlüsselungsprogrammen aus europäischen Quellen ohne NSA-Backdoor-Korrumpierung einen Teilschlüssel zu hinterlegen -natürlich nur für den nicht überprüfbaren Terrorfall-, andernfalls wäre mit Sanktionen zu rechnen!" stammt aus informellen Gesprächen bei einem deutschen Bankenseminar. Phil Zimmermann und seinen Mut habe ich mal vor dreieinhalb Jahren bei einem Vortrag im Berliner ICC bewundert.
Bruce Schneiers Buch "Angewandte Kryptographie" 844 S./addison-Wesley ist nebenbei ein höchst spannendes Buch, wer sich an der vielen Mathematik nicht stört. Und ziemlich praxisnah, wie am Beispiel DES-56bit abzulesen ist: Durch Internetzusammenschluss mehrerer Tausende PCs wurde diese Codierung vor drei Jahren mehrfach in wenigen Monaten durch Bruteforce gebrochen, weswegen die meisten europäischen Kreditinstitute seit gut zwei Jahren (zwangsweise durch die Aufsichtsbehörden!) Triple-DES mit 156bit für Geldautomaten-PINs einsetzen. Deswegen auch die Anmerkung mit dem Wachsam bleiben.
Kann von alle ein wenig aber nichts gescheit
Basic & Delphi am besten, wo bei ich unter Dosenzeit und früher mich mit TurboBasic beschäftigt habe.
C/C++ unter Amiga probiert.
Delphi jetzt am PC
Was fehlt ist JavaScript , wo ich mich ein wenig eingelesen habe , bei der Homepageerstellung
Basic & Delphi am besten, wo bei ich unter Dosenzeit und früher mich mit TurboBasic beschäftigt habe.
C/C++ unter Amiga probiert.
Delphi jetzt am PC
Was fehlt ist JavaScript , wo ich mich ein wenig eingelesen habe , bei der Homepageerstellung
Quetzalcoatl
chronische Wohlfühlitis
Ich hab mir jetzt nicht alles durchgelesen, aber HTML ist doch keine Programmiersrache, oder?
Das ist doch enfach nur ein Interpreter, nach dem Motto "Tu das hier hin". Keine Variablen, keine Kontsanten, keine Schleifen - keine Programmiersprache.
Ich weiss jetzt nicht genau was man mit PHP machen kann, aber das geht doch bestimmt in eine ähnliche Richtung.
Das ist doch enfach nur ein Interpreter, nach dem Motto "Tu das hier hin". Keine Variablen, keine Kontsanten, keine Schleifen - keine Programmiersprache.
Ich weiss jetzt nicht genau was man mit PHP machen kann, aber das geht doch bestimmt in eine ähnliche Richtung.
Ancient
Senior Member
öhm, jo, die Qualität der Abstimmung ist ein wenig mangelhaft, aber egal
Auf jeden Fall: HTML ist nun wirklich keine Programmier- oder wenigstens eine Scriptsprache, sondern schlicht und einfach eine Seitenbeschreibungssprache. Wer HTML kann, kann noch (leider oder Gott sei Dank - Ansichtssache!) noch lange nicht programmieren.
Dann hätten wir da noch Script-/Querysprachen, hier gehören JScript, VBScript (vor allem in ASP), Perl (aus der Unix-Ecke), PHP, Phyton aber auch Sprachen vor allem aus der DB-Ecke: SQL und immer öfter gerne gesehen das Trio XML/XTD/XPath (wobei letztere hier die Abfragesprache ist, die anderen beiden auch eher Markups).
Diese sind schon etwas schwieriger zu meistern als reines HTML, aber auch vom "Programmieren" würde ich hier (zumindest teilweise) eher bedingt reden. Aber auch gerade Perl und VBScript sind durchaus sehr mächtig, hier kann sich auch drüber streiten - ebenfalls Ansichtssache.
Beim Rest der übrigbleibt, kann man schon eher von "echten" Programmiersprachen reden. Im großen und ganzen sind heute die wichtigsten: C/C++ und Basic und eingeschränkt auch noch Java. Assembler (oder meinetwegen auch direkter Maschinencode) programmieren heute nur noch wenige Leutz, fast ausschließlich bei Hardware-nahen Programmen (zB. Treiber / Steuerunsprogrammen) oder aber bei enorm wichtigen speziellen Grafikfunktionen/Algorithmen.
Pascal und Delphi sind heute nicht mehr ganz so aktuell, neuere Projekte dürften wohl nur noch selten in diesen beiden Sprachen entwickelt werden. Schade eigentlich, weil Delphi ist/war durchaus sehr sehr nett.
Als Einstieg in die Programmiersprachen würde ich Basic empfehlen. Unter Windows heisst das VisualBasic (QBasic lassen wir mal weg, gell *g*) oder seit kurzem dann auch VB.NET. Wie dieses sehr gute Basic für AppleOS heisst weiss ich gerade nicht, ist aber jedenfalls supergeil!
Wer gleich mit .NET anfängt, sollte sich vielleicht auch direkt (dem sehr coolen, macht Laune!) C# widmen, ist allerdings in erster Linie- der Name täuscht - eine "JAVA"-Klon und hat mit diesem weit mehr gemein als mit C/C++.
Wer's gleich ein wenig härter mag sollte sich dann JAVA (für Cross-Platform Applikationen interessant und in Form von JAVABeans auch in kompilierten Webapplikationen) anschauen.
Tja, so das "Nonplusultra", was ich allerdings auch nicht jedem und auch nicht für alles, empfehlen würde bleibt dann halt C++ (nur das objektorierntierte würde ich als "modern" ansehen).
So, das war mein Senf.
Ich für meinen Teil komme über den folgenden Leidensweg:
- C64 (Basic und Maschinensprache)
- Atari ST (Basic und Assembler)
- Pascal (DOS)
- Turbopascal (Win)
- VisualBasic (Win)
- VB.NET / C# (Win.net)
Beherrschen tat (!) ich mal alle ganz ordentlich, aber wirklich Plan habe ich nur mit den aktuellen Sprachen mit denen ich auch arbeite, also nur letztere beiden. Davon abgesehen ist Maschinencode und Assemblercode sowieso Maschinenabhängig, man kann bei den heutigen x86ern sein Wissen aus antiken C64/C20/Atari/Amiga Zeiten eh eigentlich nicht mehr praktisch gebrauchen.
Derzeit "plage" ich mich (leider nur privat) ein wenig mit .NET rum, macht mir aber Spass. Allerdings fehlt hier das entsprechende Projekt um wirklich da mal "in Ruhe" einarbeiten zu können.
JAVA kenn ich ebenfalls nur aus privaten Spielereien, interessiert mich allerdings auch zugegebenerweise nicht sonderlich. Delphi hab ich irgendwie umgangen, da ich vorher auf VB umgesattelt bin - habs nie bereit!
Für C++ fehlte mir immer irgendwie die Zeit, leider, würde mich mal sehr interessieren. Vielleicht mit C++.NET, mal gucken.
So "nebenbei" bin ich (sozusagen zwangsweise) recht fit in HTML, JScript, VBScript (ASP), SQL, XML/XSL(XPATH)/XTD. Gerne etwas mehr würde ich mich PHP widmen, na ja, fehlt auch die Zeit zu.
Nun ja, soviel dazu, liest eh keiner, hehe.
Auf jeden Fall: HTML ist nun wirklich keine Programmier- oder wenigstens eine Scriptsprache, sondern schlicht und einfach eine Seitenbeschreibungssprache. Wer HTML kann, kann noch (leider oder Gott sei Dank - Ansichtssache!) noch lange nicht programmieren.
Dann hätten wir da noch Script-/Querysprachen, hier gehören JScript, VBScript (vor allem in ASP), Perl (aus der Unix-Ecke), PHP, Phyton aber auch Sprachen vor allem aus der DB-Ecke: SQL und immer öfter gerne gesehen das Trio XML/XTD/XPath (wobei letztere hier die Abfragesprache ist, die anderen beiden auch eher Markups).
Diese sind schon etwas schwieriger zu meistern als reines HTML, aber auch vom "Programmieren" würde ich hier (zumindest teilweise) eher bedingt reden. Aber auch gerade Perl und VBScript sind durchaus sehr mächtig, hier kann sich auch drüber streiten - ebenfalls Ansichtssache.
Beim Rest der übrigbleibt, kann man schon eher von "echten" Programmiersprachen reden. Im großen und ganzen sind heute die wichtigsten: C/C++ und Basic und eingeschränkt auch noch Java. Assembler (oder meinetwegen auch direkter Maschinencode) programmieren heute nur noch wenige Leutz, fast ausschließlich bei Hardware-nahen Programmen (zB. Treiber / Steuerunsprogrammen) oder aber bei enorm wichtigen speziellen Grafikfunktionen/Algorithmen.
Pascal und Delphi sind heute nicht mehr ganz so aktuell, neuere Projekte dürften wohl nur noch selten in diesen beiden Sprachen entwickelt werden. Schade eigentlich, weil Delphi ist/war durchaus sehr sehr nett.
Als Einstieg in die Programmiersprachen würde ich Basic empfehlen. Unter Windows heisst das VisualBasic (QBasic lassen wir mal weg, gell *g*) oder seit kurzem dann auch VB.NET. Wie dieses sehr gute Basic für AppleOS heisst weiss ich gerade nicht, ist aber jedenfalls supergeil!
Wer gleich mit .NET anfängt, sollte sich vielleicht auch direkt (dem sehr coolen, macht Laune!) C# widmen, ist allerdings in erster Linie- der Name täuscht - eine "JAVA"-Klon und hat mit diesem weit mehr gemein als mit C/C++.
Wer's gleich ein wenig härter mag sollte sich dann JAVA (für Cross-Platform Applikationen interessant und in Form von JAVABeans auch in kompilierten Webapplikationen) anschauen.
Tja, so das "Nonplusultra", was ich allerdings auch nicht jedem und auch nicht für alles, empfehlen würde bleibt dann halt C++ (nur das objektorierntierte würde ich als "modern" ansehen).
So, das war mein Senf.
Ich für meinen Teil komme über den folgenden Leidensweg:
- C64 (Basic und Maschinensprache)
- Atari ST (Basic und Assembler)
- Pascal (DOS)
- Turbopascal (Win)
- VisualBasic (Win)
- VB.NET / C# (Win.net)
Beherrschen tat (!) ich mal alle ganz ordentlich, aber wirklich Plan habe ich nur mit den aktuellen Sprachen mit denen ich auch arbeite, also nur letztere beiden. Davon abgesehen ist Maschinencode und Assemblercode sowieso Maschinenabhängig, man kann bei den heutigen x86ern sein Wissen aus antiken C64/C20/Atari/Amiga Zeiten eh eigentlich nicht mehr praktisch gebrauchen.
Derzeit "plage" ich mich (leider nur privat) ein wenig mit .NET rum, macht mir aber Spass. Allerdings fehlt hier das entsprechende Projekt um wirklich da mal "in Ruhe" einarbeiten zu können.
JAVA kenn ich ebenfalls nur aus privaten Spielereien, interessiert mich allerdings auch zugegebenerweise nicht sonderlich. Delphi hab ich irgendwie umgangen, da ich vorher auf VB umgesattelt bin - habs nie bereit!
Für C++ fehlte mir immer irgendwie die Zeit, leider, würde mich mal sehr interessieren. Vielleicht mit C++.NET, mal gucken.
So "nebenbei" bin ich (sozusagen zwangsweise) recht fit in HTML, JScript, VBScript (ASP), SQL, XML/XSL(XPATH)/XTD. Gerne etwas mehr würde ich mich PHP widmen, na ja, fehlt auch die Zeit zu.
Nun ja, soviel dazu, liest eh keiner, hehe.
D
Doc_Incredible
Gast
RE:
Moin,
will ich mich als neues Mitglied dieses Boards doch gleich ma anschließen.
Ich arbeite mit:
VB
VBScript
Ruby
Easybatch
WIL-Script
Für meine Zwecke reicht es völlig.
Wenn ich ein Tool brauche, dann ist es mit einer dieser Sprachen relativ schnell erstellt.
greetz
Doc I
Moin,
will ich mich als neues Mitglied dieses Boards doch gleich ma anschließen.
Ich arbeite mit:
VB
VBScript
Ruby
Easybatch
WIL-Script
Für meine Zwecke reicht es völlig.
Wenn ich ein Tool brauche, dann ist es mit einer dieser Sprachen relativ schnell erstellt.
greetz
Doc I
SilverSurfer99
gehört zum Inventar
@KWUAXX "traut man sich gar nix mehr hintendran zu schreiben!"
Das musst du positiv sehen, bestimmt merkt sich Supi die Spezialisten für ein neues Boardprojekt *g*
Da Mensch meist von Hause aus faul ist (sagen jedenfalls die Soziologen), wird entweder aus beruftlichen Gründen programmiert oder weil Lösungen nicht auf dem Markt vorhanden sind/gefunden werden. Wie schon mehrfach geschrieben, macht das Tüfteln zwar Spaß, ist aber auch Leidensweg.
@Ancient "Nun ja, soviel dazu, liest eh keiner, hehe." Also ich fand es faszinierend, bist du etwa auch mit TexAss den C64-Kopierschützern zuleibe gerückt?
@ALL - Entschuldigung, dass ich das Thema für einen Plausch überdehnt habe.
Das musst du positiv sehen, bestimmt merkt sich Supi die Spezialisten für ein neues Boardprojekt *g*
Da Mensch meist von Hause aus faul ist (sagen jedenfalls die Soziologen), wird entweder aus beruftlichen Gründen programmiert oder weil Lösungen nicht auf dem Markt vorhanden sind/gefunden werden. Wie schon mehrfach geschrieben, macht das Tüfteln zwar Spaß, ist aber auch Leidensweg.
@Ancient "Nun ja, soviel dazu, liest eh keiner, hehe." Also ich fand es faszinierend, bist du etwa auch mit TexAss den C64-Kopierschützern zuleibe gerückt?
@ALL - Entschuldigung, dass ich das Thema für einen Plausch überdehnt habe.