Banthor schrieb:
Codeverschleierung ist in jeder Sprache möglich. Der Grad der Verschleierung ist überwiegend abhängig vom Können (bzw. Nichtkönnen) des Programmierers.
Die Sprache C selbst versteckt nichts. Man ist nicht einmal gezwungen die C-Runtime Library zu verwenden!
Man kann selbst printf usw. selbst schreiben.
Außnahme:
Betriebssystem/Compiler Funktionen dir zur Verfügung gestellt werden (VirtualAlloc, CreateWindow, OutputDebugString, ReadFile etc.)
Eigene verschleierung zähl ich nicht hier, da dies jedem selbst überlassen ist.
Ich rede hier nur von den Sprachen und deren Standard-Bibliotheken!
Banthor schrieb:
Wie kommst du darauf? Diese Sprachen selbst zwingen dich zu sehr wenig.
Selbst wenn das so wäre, dann würde ich das langfristig eher als Vorteil sehen, was den Programmierstil angeht. Wer nicht ein wenig Abstraktionsvermögen entwickelt mutiert langfristig zu einer Spagetticodefabrik.
Mehr Abstraktion erhöht die Fehlerquote sowie die Wartbarkeit!
- Debugge den Tomcat Datenbank-Pool Stack, wenn der Pool in nen Deadlock kommt
- Schau dir die implementierung von Containerfunktionen aus der std::library an
- Schau dir die implementierung von Containerfunktionen in boost an
- Schau dir komplexe Javascript Frameworks an, wie z.b. angularJs, jQuery
- Schau dir den ogre3D source an
Und nein ich sage nicht, das diese Dinge vollkommen schlecht oder abgrundtief Böse sind.
Einige sind tatsächlich ganz brauchbar, andere dafür eher weniger.
Banthor schrieb:
Ohne lesenden/schreibenden Speicherzugriff gibt es sehr wenige sinnvolle Programme. Natürlich kann ich mit all diesen Sprachen lesend und schreiben auf den Speicher zugreifen.
Was du mit "direkt" vermutlich meinst ist für Anfänger und selbst für Fortgeschrittene irrelevant. Wenn du nicht gerade bestimmte Arten von Treiber schreibst, wirst du seltenst echten direkten Zugriff auf Speicher bekommen, selbst mit C nicht. Denn der direkte Speicherzugriff von Anwendungen wird durch vielerlei Schutzmechanismen in CPU und Betriebssystem gerade eben nicht gestattet - typischerweise lebt jedes Programm in seiner eigenen heilen Speicherwelt.
Nein du kannst in Java, C#, JavaScript usw. keinen Speicher direkt manipulieren.
Das ist komplett abstrahiert, über die jeweiligen Basistypen und Bibliotheken inkl. Sicherheitskonzepte damit es überhaupt nicht möglich wird.
Man hat keinen Plan was dahinter passiert, welche und wieviele CPU-Instruktionen werden verwendet, wieviel Speicher wird dafür verwendet usw.
In C ist es anderst, das ganze Sprachkonstrukt ist darauf ausgelegt -> Du erzeugst Speicher, manipulierst ihn und gibst ihn wieder frei.
Das macht auch übrigens jegliche Art von Anwendung die du schreibst oder ausführst, egal in welcher Sprache geschrieben -> Das ist das Fundament auf das alle aufbauen.
Banthor schrieb:
In C ist nicht jeder Code von Dir. Spätestens wenn du IO machen willst wirst du entweder stdio oder etwas OS spezifisches nutzen und der Code ist dann nicht von Dir. In anderen Sprachen ist das auch nicht wesentlich anders, sobald man an Resourcen ranwill ist man auf das Betriebssystem und dessen API angewiesen.
Die Zeiten, wo wirklich jeder Code von einem selbst ist, sind schon lange vorbei und ich vermisse sie auch nicht wirklich.
Ja was das Betriebssystem dir gibt, darauf hast du keinen Einfluß.
Das ist auch vollkommen legitim diese zu verwenden.
Banthor schrieb:
Das kann man so stehen lassen, zumindest sollte den Kern eines Lernziels durch Fremdbibliotheken lösen lassen, weil sonst hat man nichts gelernt. Später ist es natürlich vollkommen in Ordnung, wenn man das Rad nicht ständig neu erfindet.
Es gibt kein einziges Rad in der Softwareentwicklung, eher zusammengesetzte Quader die wie Räder zusammengesteckt/geklebt werden inkl. kleine und große Löcher, so dass kleine Steinchen dran hängen bleiben.
Wie sich diese Räder drehen ist mir heutzutage immernoch ein Rätsel.
andy_m4 schrieb:
Die "negativen" Aspekte kann man aber auch als Vorteil sehen. Denn eigentlich ist ja genau das was eine Hochsprache auszeichnet. Abstrahieren. Sich von der da drunter befindenen Maschine zu lösen. Auch C tut das, wenngleich da der Layer vielleicht dünner ist als in anderen Sprachen. Trotzdem könnte jemand mit Fug & Recht auch die Meinung haben: "Vergiss C. Mach Assembler!"
Was zeichnet gerade C aus?
Ein anderer Aspekt ist halt die Schwierigkeit ansich die sich daraus ergibt. Früher waren ja die BASIC-Programmierer, später dann die VBA-Programmierer immer ein wenig belächelt. Ob zu Recht oder zu Unrecht, dass sei mal an der Stelle ausgeklammert. Fakt ist aber, so begrenzt ihre Möglichkeiten und Fähigkeiten vielleicht auch waren, so konnten sie sich immerhin selbst helfen und für sich Probleme lösen.
Wärst Du den Leuten mit C gekommen, hätte vermutlich nie einer mit programmieren angefangen. Die hätten es nicht auf die Reihe bekommen und schnell das Handtuch geworfen.
Insofern würde ich aus meiner Sicht den einfacheren Sprachen nicht ihre Berechtigung absprechen. Vielleicht sogar im Gegenteil. Vielleicht ist es ja eher angebracht zunächst einmal lernen algorithmisch zu denken. Was Schleifen sind. Was Verzweigungen sind. Was Variablen sind. usw.
C hat einfach mehr Hindernisse. Schon ein einfaches scanf kann schnell mal in ein Segmentation fault enden.
Du hast also gleich ganz viele Kriegsschauplätze zu bearbeiten. Vielleicht sogar unnötig viele.
Klar ist das schaffbar. Die ältere Generation musste es auch so schaffen, weil es halt nicht viel anderes gab. Die Frage ist aber, obs der beste Weg ist.
C hat auch seine Macken, aber weniger als andere Sprachen, da die Sprache viel zu einfach aufgebaut und daher verständlicher ist.
Allerdings mit Assembler wäre die Einstiegshürde viel zu Hoch, es dauert hier einfach zu lange bist du überhaupt mal was siehst.
Ich finde es gerade heutzutage sehr wichtig dass man die Kernkonzepte lernt und versteht, damit alles aufbauende viel verständlicher ist.
Viele heutzutage haben keinen Plan wie CPUs funktionieren: "Klasse X wirds schon richten, mir egal was dahinter steckt".
Wenn aber Klasse X mit all seinen Funktionsaufrufen sprunghaft 10 Sekunden anstatt 2 Sekunden brauch, dann kann es auf einmal schon relevant sein zu wissen was sich dahinter verbirgt: Wann und wieviele Reads werden gemacht, wieviele Takte werden benötigt etc.
Da wird dann schlichtweg nur der Algorythmus optimiert, parallelisiert und das wars -> Das Reicht dann für die meisten.
Warum das aber dann wirklich schneller oder langsamer ist, das wissen wirklich nur diejenigen die verstehen was CPUs machen, wie wichtig heutzutage Speicheroptimierte Strukturen sind.
Was sind Register, wozu sind Cachelines, was ist die typische Größe für eine Cacheline, was ist Alignment, wozu ist der L1/L2 Cache?
Wie löst man einen Cachemiss, Was macht mulps? Wozu ist compare and exchange? Wie ermittele ich die aktuelle CPU Zeit? - ohne OS-Funktionen zu verwenden?
andy_m4 schrieb:
Ich weiß nicht, ob Videos wirklich das Optimum sind. Ganz nett ist es z.B. für Beschreibungen, wo es darauf ankommt, wo man klicken muss etc. Fürs Programmieren lernen, wo man ja vielleicht auch mal 2 Seiten zurückschauen will weil da irgendwie ne Erklärung war, die man jetzt erst begriffen hat wo es ums einsetzen geht ist mit nem Video echt Asche.
Das ist bei jedem unterschiedlich, ich kann mit Bücher nur wenig Anfangen, da diese für mich max. als Nachschlagereferenz dienen und nicht um etwas zu lernen.
Videos sind tatsächlich ein gutes Medium um die Grundlagen zu lernen, sofern man sich das richtige Video rauspickt.
Ich kann jedem empfehlen mal das C Video von Eskil Steenberg anzuschauen -> Um mal über den eigenen Tellerrand hinauszusehen.
andy_m4 schrieb:
Aber ich würde nicht sagen, dass wenn man jetzt z.B. C kann, dass es dann einfach ist auf z.B. C# zu wechseln.
Eigentlich nicht, da man lediglich nur noch die Sprachunterschiede lernen muss:
- z.b. Das es kein wirkliches "Unsigned" in Java gibt
- Char in C# sowie in Java immer 16 bit sind anstatt 8 bit (Unicode / UTF16)
- Syntax ein wenig anderst, "begin" anstatt "{" oder keine Semicolons am ende der Anweisung, z.b. bei Basic/VB
- Typdeklarationen sind vielleicht anderst, "type : name" anstatt "name : type"
- Keine Klassen oder Funktionsdeklarationen oder Delphi (Java, C#, JavaScript etc.)
- Keine Vorwärtsdeklaration notwendig
- Operator oder Methodenüberladung
- Kein "malloc", dafür halt "new"
- Namespaces
- Der Einstiegspunkt in modernen Sprachen ist typischerweise static void main(string[] args) {} -> Außnahme Webservices
- Standard-Bibliotheken unterscheiden sich
- Bedingungen mal geklammert werden müsser und mal nicht
- usw.
andy_m4 schrieb:
Ja. Kann man meistern. Die Frage ist (ist ja auch oben schon angeklungen), warum?
Du würdest ja vermutlich auch nicht auf die Idee kommen die Festplatte selbst zu organisieren und stattdessen die Zuteilung der Sektoren etc. dem Betriebssystem/Dateisystemtreiber zu überlassen. Warum sollte ich das bei RAM anders handhaben? Also wenn scho, denn scho. :-)
Ganz Ehrlich? Wenn ich Zeit hätte würde ich das tun, zumindest einmal um all das zu verstehen was sich dahinter verbirgt.
Zu aller letzt:
Ihr diskutiert mit jemanden der über weit 20 Jahre schon programmiert, mit Basic und Delphi angefangen hat und
heute in vielen unterschiedlichen Sprachen programmiert (C#, C, C++, Java, JS, Python, PHP, Delphi), tagtäglich mit modernen Entwicklungsmuster zu tun hat und arbeitsbedingend laufend von einer Sprache zur anderen springen muss und beide Welten kennt: Low-Level sowie High-Level mit all ihren Entwicklungsmuster.
Ich schaue gern über den Tellerrand hinaus und tu ihn auch gern mal komplett auseinandernehmen oder neuerfinden.
