|
|
|
|
|
| 34 Beiträge
Antworten
| 1.214 Beiträge
Zitat von Daelach im Beitrag #4
Sowas wie die NOP-Rutsche, Heap-Spraying usw. halte ich nicht für nebensächlich. Gerade wenn man Buffer Overflows ausnutzen will, läuft es doch auf Assembler raus.
So ein Blödsinn. Speicherüberläufe werden meist indirekt ausgelöst, indem man sich Schwächen von Software zunutze macht, die auf einer viel höheren Schicht aufsetzen. Assembler ist heute eher für die Microcontroller-Entwicklung interessant, aber doch nicht, wenn ich mir Zugang zu einem System verschaffen will (Von Chipkarten-Gedöns und anderer Exotik mal abgesehen).
Zitat von Daelach im Beitrag #4
Übrigens sind es insbesondere die Leute, die direkt mit objektorientierten Frameworks angefangen haben, auch diejenigen, die nicht verstehen, was unter der Haube abgeht,
Ja, als ob man das später nicht mehr lernen könnte.
Genauso bescheuert finde ich übrigens die verbreitete, gegenteilige Meinung, dass jeder, der nicht mit objektorientierter Programmierung angefangen hat, sein Denken für immer für diesen Ansatz verseucht hat. Vielleicht mag das ja auf irgendwelche Trottel alles zutreffen, aber wer Hacker werden will, sollte so flexibel sein, dass er mit jedem Paradigma umgehen könnte.
Zitat von Daelach im Beitrag #4
und die eben deswegen sowohl zu ineffizienten wie auch zu unsicherem Code neigen.
Totaler Quatsch. Effizienz ist ein algorithmisches Problem. Bei zeitkritischen oder rechenintensiven Anwendungen führe ich eh eine Komplexitätsanalyse durch. Um das vernünftig zu tun, sollte man studiert haben, weil das ist halt sehr mathematisch. Glücklicherweise war Effizienz noch nie so unwichtig wie heute. Früher ging es um jeden Taktschlag und jedes Kilobyte. Der moderne Ansatz ist, die Wartbarkeit in den Vordergrund zu stellen.
Und was die Codequalität angeht, kann man mit Assembler genauso einen Mist bauen wie mit jeder anderen Sprache auch. Entscheidend ist ein guter Lehrer und Talent. Nicht, womit man anfängt. Die Grundsätze guter Codequalität ändern sich ja nicht.
Zitat von Daelach im Beitrag #4
Am übelsten die "Java ist ein toller Einstieg"-Fraktion.
Weil man erst heldenhaft durch den Assembler-Schlamm gerobbt sein muss, bevor man ein ganzer Mann ist? Ich weiß immer nicht, was so mancher Laie an Assembler immer so elitär findet. Vielleicht, weil es anfangs etwas kryptisch aussieht? Ich habe Assembler nach Java gelernt und fand es kinderleicht. Auf jeden Fall leichter als Java. Aber eben auch sehr viel mechanischer, linearer und uneleganter.
Es hat auch schon seinen Grund, warum die meisten Hochschulen Java in den Grundlagen-Kursen benutzen.
zuletzt bearbeitet 28.04.2015 20:02 |
#7
von S_J •
| 455 Beiträge
RE: Kennt sich jemand mit C++ programmieren aus?
in Offtopic Forum 29.04.2015 12:37von S_J •
| 455 Beiträge
Zitat von Daelach im Beitrag #6
In welchem Studiengang? In Informatik? Ja nun, Informatik ist auch nicht Codierung, sondern hat völlig andere Schwerpunkte. Einen Informatiker würde ich nicht in die Implementierung eines Projektes setzen, dafür ist er normalerweise nicht qualifiziert, sondern den würde ich eher z.B. in der Validierung beschäftigen.
Waaah, jetzt merk ich's also erst, ich hab mit meinem Fremdsemester Informatik den falschen Kurs belegt
Da hammse uns auch mit Java gequält ...
Ganz blöde Frage dann mal: Wenn die Informatiker an der Uni die wirklichen Basics nicht lernen, woher bekommt man sie denn sonst? Lehrbücher, Ausbildung?
Sogar in meiner gymnasialen Oberstufe hat man sich mittels einfacher mathematischer Formeln mal an Assembler herangetastet. Das Schöne daran ist eben, dass man jeden einzelnen Schritt im Prinzip wirklich kennt und so weiter .. wurde uns da also schon als "die Basis" vermittelt, wenn auch mit dem Hinweis, dass man sich damit heutzutage praktisch nicht mehr befasse(n brauche). Ansonsten gab es allerdings viel grafische Oberfläche, einfach, weil es für eine spielerische Herangehensweise schon schön war, auch zu "sehen", ob und dass etwas passiert. Und um if-then-else zu trainieren, und ggf. auch einfache Zählschleifen, war eine Oberfläche, in der man kleine Auto-Images eine Straße herunterfahren lassen konnte, und Verkehrsampeln "umschalten" (bei mir gab es dann immer auch mal einen Crash mit Feuer und so :D) wirklich schon ganz lustig.
Ist halt alles weit weg von "echten" Anwendungen gewesen, und ich denke, das ist es dann auch, woran es scheitert. Klar ist das nett, wenn man mal nachlesen kann, wie man sich eine Mini-Anwendung schreibt, die Einem einen komplementären DNA-Strang ausgibt o.ä. Aber ich für meinen Teil lerne einfach auch deutlich besser, wenn ich irgendeinen Bedarf daran habe oder sehe, das Gelernte auch zu verwenden. Wie sich's für mich darstellt, sind die einen Sachen so simpel, dass man sie nicht wirklich braucht, und die Dinge, die mich interessieren würden, so kompliziert, dass es wohl aussichtslos ist, das zu lernen, ohne eine gehörige Portion Zeit und Energie zu investieren. Das muss man dann schon, wie so viele Dinge, wirklich wollen, wenn dabei etwas herauskommen soll.
Wenn ich Hacken wollte, würde ich mir erstmal einen Haufen Nerds zulegen, die das schon können :D Ich glaube, Computer zum Abstürzen zu bekommen muss nicht notwendigerweise schwer sein, wenn man sich ein paar Tricks aneignet. Aber "klares Denken" (sehr schön formuliert btw :D) sollte man wohl generell einigermaßen können, wenn man mit Maschinen kommunizieren möchte.
zuletzt bearbeitet 29.04.2015 12:42 |
Zitat von Daelach im Beitrag #6
Da man schwer sagen kann, wo genau die Ausführung losgehen wird, hat man die sog. NOP-Rutsche erfunden. Um zu begreifen, wie die funktioniert, braucht es dann aber natürlich Assembler.
Nein, man muss wissen wie die CPU arbeitet, dass es Register, Adressen und einen Stack gibt, der sich mit Nulloperationen aufblähen lässt usw.. Aber man muss ganz sicher nicht Assembler lernen. Man schleust ja keinen Assembler-Code ein, sondern bereits kompilierten Maschinencode. Ich habe ja auch Assembler gelernt, aber dadurch nichts Neues über die Arbeitsweise eines Computers erfahren, außer, dass es gut ist, dass man sich heute nicht mehr damit plagen muss. Allgemein finde ich, dass man sich so spezielle Sachen gezielt aneignen kann, wenn man sie mal brauchen sollte. Der NOP slide ist ein Klassiker, aber um ihn anwenden zu können, sollte man lieber gut in einer Hochsprache zuhause sein als in Assembler.
Assembler schadet aber natürlich nicht und ist sicher auch eine interessante Erfahrung. Dass man ihn aber braucht, um die Arbeitsweise des Computers zu verstehen, halte ich für übertrieben. Wer die Arbeit auf Prozessorebene verinnerlichen will, der soll damit rumspielen. Wer Besseres zu tun hat, der lässt es halt.
Zitat von Daelach im Beitrag #6
Längst nicht mehr, die Zeiten sind vorbei. Das macht man heute auch in C
Das kommt auf den Anwendungszweck an. Im Embedded Systems Bereich wird Effizienz nämlich wieder ziemlich wichtig und da kann es sich lohnen, kritische Passagen auf Assembler auszulagern. C bringt nun mal doch einen gewissen Overhead mit sich, der unnötig Leistung kosten kann. Ansonsten lieferst du hier aber ein schönes Beispiel für die gegenwärtige Entwicklung, dass Effizienz immer mehr an Wichtigkeit verliert.
Zitat von Daelach im Beitrag #6
In der Praxis findet das dann oftmals nicht wirklich statt. Genauso verfehlt halte ich es übrigens auch, wenn man Leute direkt mit C einsteigen läßt, nur weil das sehr verbreitet ist. Damit lernt man nie, wirklich strukturiert zu programmieren, und jede Menge Probleme bei an sich trivialen Umstellungen wie von 32 auf 64bit kommen daher, daß die Leute nie was anderes als die schlampige Denkweise gelernt haben, die C eben durchaus erlaubt.
Jede Programmiersprache erlaubt Schlampigkeiten; besonders übrigens die Scriptsprachen. Es hat aber auch seine Vorteile, z. B. mit Python zu beginnen. Ich bleibe dabei: Man kommt um einen guten Dozenten nicht herum. Dann ist es auch fast egal, mit welcher Sprache man beginnt. Die großen Schlampigkeiten fangen ja schon bei der Planung an. Wer schon die Software-Architektur vernünftig designt, Klassen- und Ablaufdiagramme anfertigt und die wichtigsten Algorithmen in Pseudocode verfasst, der wird mit der Implementierung die wenigsten Schwierigkeiten haben.
"Strukturiert programmieren" muss man ja auch im Kontext des verwendeten Paradigmas sehen. Wer an objektorientierte Programmierung so herangeht, wie er es bei der prozeduralen Programmierung gelernt hat, wird ganz sicher nicht "strukturiert programmieren".
Java halte ich für geeignet, weil es IMO den besten Kompromiss bietet.
Zitat von Daelach im Beitrag #6
Jede Menge zäher Java-Programme belegen das Gegenteil.
Das hat aber doch nichts mit effizienter/ineffizienter Programmierung zu tun, sondern damit, dass Java in der JVM läuft!
Die Performance verkackt meist an Algorithmen mit viel unnötiger Redundanz. Wie diese implementiert werden, hat dann eher einen Einfluss auf die Übersichtlichkeit, wenn man den Algorithmus wirklich vollständig und halbwegs minimal abbildet.
Zitat von Daelach im Beitrag #6
Falsch. Rate mal, wieso Steve Jobs seinerzeit Flash aus iOS geworfen hat - weil es nicht nur Sicherheitslücken en masse hat, sondern auch noch extrem ineffizient ist und deswegen die Akkulaufzeit dramatisch reduziert. Heutige Mobilgeräte haben keine Rechenkraft wie fette Desktop-x86er. Mach dieselbe Aufgabe mit dem halben Rechenaufwand, und Du hast auch nur den halben Energieaufwand, etwas vereinfacht gesagt.
Natürlich ist Effizienz für spezielle Fälle, wie Multimedia-Anwendungen, Spiele, medizinische Anwendungen, Embedded Systems usw. ungeheuer wichtig. In den aller meisten Fällen ist sie das aber nicht und man sollte die Prioritäten anders setzen.
Warum meinst du, werden heutzutage so häufig rekursive Aufrufe benutzt? Die kacken gegen iterative Alternativen völlig ab, aber sie sind eben übersichtlich. Man sieht sofort wie sie funktionieren und das erhöht die Wartbarkeit des Quellcodes. Bei der heutigen Rechenpower ist die Performance meist zweitrangig. -Auch bei mobilen Geräten.
Ich selbst bin ja nun hauptsächlich mit 3D-Grafikprogrammierung beschäftigt. Da ist Effizienz ein großes Thema, weil jede unnötige Shader-Anweisung sich doof auf die Framerate auswirken kann. Wenn man objektiv bleiben will, darf man aber nicht davon ausgehen, was man selbst so kennt und tut.
In der Anwendungsentwicklung ist es meist viel wichtiger und kostensparender, einen gut wartbaren Code zu haben, als ein paar Mikrosekunden Rechenzeit einzusparen.
Zitat von Daelach im Beitrag #6
Das ist aber nicht nur bei Mobilgeräten wichtig, sondern durchaus auch bei Servern. Die kosten nämlich Geld, und umso mehr, je fetter man sie wählt. Außerdem kosten sie auch noch Energie im Betrieb, und nicht nur für sich selber, sondern auch noch für die Klimatisierung.
Ist auch sehr speziell.
Zitat von Daelach im Beitrag #6
Effizienter Code muß nicht schlecht lesbar sein. Tatsächlich halte ich sogar das Gegenteil für wahr.
Naja, beim effizienten Code steht die Technik im Vordergrund, bei der Lesbarkeit der Mensch. Wie ich schon schrieb, schlagen rekursive Aufrufe derb auf die Performance, aber man benötigt weniger Code und sie sind für den Menschen leichter nachzuvollziehen. Man sieht es auch schön an den gängigen Sortier-Algorithmen, dass gerade die weniger Performanten, inutuitiver zu erfassen und zu implementieren sind. Das ist auch der einzige Grund, warum sie überhaupt noch verwendet werden.
Zitat von Daelach im Beitrag #6
Wenn ich Code schreibe, meide ich jedwede Ausdrücke, bei denen man nicht auf den ersten Blick sieht, was da gemacht wird. Lieber spalte ich das auf mehrere Zeilen auf, der Compiler wirft am Ende sowieso denselben Code raus und wird durch kryptische Konstrukte allenfalls an seiner eigenen Optimierung gehindert.
Es geht ja auch nicht um "Ausdrücke", sondern - wie ich schon sagte - um die Konzeption der Algorithmen. Mit ihnen steht und fällt die Übersichtlichkeit. Die Code Conventions einzuhalten und möglichst "sprechend" zu programmieren, ist eine Selbstverständlichkeit.
Zitat von Daelach im Beitrag #6
Doch. Was ich schon an C-Code gesehen habe, das geht auf keine Kuhhaut, und 90% davon wäre gar nicht erst passiert, wenn die Leute mit einer brauchbaren Lehrsprache wie Pascal erstmal das klare Denken gelernt hätten. Das ist übrigens so in etwa der Sinn von MISRA - daß man in C auf eine recht pascalhafte Weise programmiert.
Das "klare Denken" lernt man aber nicht durch eine bestimmte Programmiersprache, sondern durch das sprachunabhängige Formulieren von Algorithmen. Die Implementierung ist eigentlich recht banal; der Hinrschmalz steckt in der Planung. Jede Sprache hat doch ihre Besonderheiten auf die man individuell eingehen muss. Wenn ich mit Python oder JavaScript programmiere, gehe ich völlig anders an die Implementierung, als wenn ich mit Java oder C++ arbeite. Aber der abstraktere Part der Entwicklung ändert sich doch nicht. Du schränkst dich nur unnötig ein, wenn du schon beim Algorithmieren in einer bestimmten Sprache denkst und hast so imo eher einen Nachteil, dich auf weitere Programmiersprachen einzulassen.
Zitat von Daelach im Beitrag #6
Weil ich sehe, was dabei rauskommt.
Weißt du was ICH zu sehen meine? Du bist von der "der Weg, den ich gegangen bin, ist eh der Beste"-Fraktion. Kann das sein? ;-)
Zitat von Daelach im Beitrag #6
Wenn man die Dinge nicht mehr von der Pike auf lernen will
Naja, so ganz "von der Pike auf" ist das aber auch nicht. Da muss man natürlich den Weg gegangen sein, den ICH gegangen bin. *zwinker, zwinker*
Also Transistoren zu Flip Flops zusammensetzen, mit denen Logikgatter aufgebaut werden, um daraus arithmetische Operatorschaltungen zu basteln, die man anschließend mit Karnaugh minimiert, bis man irgendwann seinen eigenen Prozessor hat. Hey, wir haben in der theoretischen Informatik sogar gelernt, wie wir eigene Programmiersprachen entwickeln und Compiler bauen. Und was ist denn bitte ein Entwickler, der nie was von Automatentheorie gehört hat? Und du hältst Assembler für die "Pike"?
Ich gestehe mal was: Es ist für die meisten Fälle gar nicht nötig über jeden Scheiß Bescheid zu wissen. Die Systemhierarchie ist so intelligent abstrahiert, dass man sehr wenig über die unteren Ebenen wissen muss, wenn man Anwendungen entwickelt. Klar, grad beim Hacken will man genau diesen hierarchischen Aufbau auch gern mal ausnutzen. Wie tief man da gehen will, muss jeder selbst wissen. Man kann auch sehr viel machen, wenn man nur auf Anwendungsebene verbleibt. Auf gar keinen Fall muss man bei Adam und Eva anfangen und das Rad komplett neu erfinden, nur weil man als Laie in die Programmierung einsteigen will. Wer wirklich den umfassenden Überblick aus allen Perspektiven haben will, der soll Informatik studieren.
Man kann ja auch ganz philosophisch fragen, was eigentlich ursprünglicher ist: Die Hardware oder das abstrakte, algorithmische Denken? Je weiter man die Hierarchie nach oben geht, je abstrakter und geistiger es wird, desto näher ist man beim Menschen. Von dort anzufangen, halte ich eigentlich für ganz naheliegend.
Es geht natürlich Beides, aber welcher Weg der Bessere ist, halte ich schon fast für eine religiöse Frage.
Ich bin da einen Mischmasch gefahren, weil in meiner Kindheit habe ich Basic programmiert, später in der Jugend dann Pascal. An der FH kamen dann 14 weitere Programmiersprachen und die ganze Computertechnik mit hinzu. Ich hätte mit jedem Aspekt beginnen können. Ich glaube nicht, dass man sich gedanklich was verbauen kann, wie einige immer meinen. Komischerweise sind es ja auch immer die Anderen, die sich angeblich was verbaut hätten.
Zitat von Daelach im Beitrag #6
In welchem Studiengang? In Informatik? Ja nun, Informatik ist auch nicht Codierung, sondern hat völlig andere Schwerpunkte. Einen Informatiker würde ich nicht in die Implementierung eines Projektes setzen, dafür ist er normalerweise nicht qualifiziert, sondern den würde ich eher z.B. in der Validierung beschäftigen.
Ein informatiker hat schon über das gesamte Grundstudium auf einem hohen Niveau implementiert, das der Fachinformatiker oder Quereinsteiger nach 10 Jahren Berufserfahrung nicht erreicht. Ich habe zum Beispiel eine komplette 3D-Grafikengine für Browserspiele entwickelt, in nur zwei Monaten und inklusive einer kleinen Flugsimulation. Ich bezweifle, dass das jemand so hinbekommt, der nicht studiert hat, weil da auch einfach der mathematisch-theoretische Background fehlt. Drum sind in der Spielebranche und anderen anspruchsvollen SE-Gebieten auch fast nur Akademiker unterwegs. Es kann aber sein, dass an einer Universität der praktische Anteil arg zu kurz kommt. Das kann ich nicht beurteilen, weil an unserer Fachhochschule haben wir dieses Problem definitiv nicht.
Für triviale Programmieraufgaben ist der Informatiker aber überqualifiziert, das stimmt. Aber grad die Entwicklung sehr komplexer Systeme erfordert eine systematische Planung, für die studierte Informatiker nun mal am besten geeignet sind, denn das haben sie ja gelernt.
zuletzt bearbeitet 29.04.2015 17:43 |
Zitat von S_J im Beitrag #14
Nicht, dass ich sowas irgendwem krummnehmen würde, aber zumindest sollte man nicht erwarten, dass das oder auch der Verweis auf eine Note jemand Anderen dann zum Niederknien bewegt.
Wenn ich Hilfe von jemandem will, dann ist es mir persönlich schon wichtig, dass mein Gegenüber sich mit der Problematik, die mich beschäftigt, auch tiefer befasst hat. Ich finde das ganz pragmatisch. Als Narzisst mache ich natürlich auch kein Geheimnis daraus, wie unfassbar toll ich bin. Ich habe übrigens noch mehr 1en.
Ich wäre aber vorsichtig, in einer kontroversen Diskussion persönliche Leistungen oder "Industrieerfahrung" als Argument dafür zu nehmen, dass ich bezogen auf eine Sachfrage Recht hätte und dem Gesprächspartner eine Gartenzwergperspektive zu unterstellen. Ein argumentum ad hominem ist immer auch eine argumentative Bankrotterklärung.
Stelle ich bei jemandem sowas fest, gehe ich für gewöhnlich auf Abstand, denn ich möchte mich ja inhaltlich verständigen und nicht als Erfüllungsgehilfe für irgendwelche Macken herhalten.
Zitat von S_J im Beitrag #14
aber dass man auf Effizienz verzichten könne, fand ich allgemein gesprochen zumindest seltsam. Wenn es um Geld oder Energie geht, dürfte das so gut wie nirgends so sein.
Aber das ist ja der Punkt! Wartung IST der größte Kostenfaktor bei der Softwareentwicklung:
Man muss halt abwägen, was für den konkreten Fall wichtig ist. Ich habe auch nirgendwo behauptet, dass auf Effizienz nun frei zu scheißen ist. Sie spielt oft nur nicht mehr so die Rolle wie früher, als noch das letzte Byte aus dem RAM gequetscht werden musste als gäbe es sonst kein morgen. Dafür spielt die Wartbarkeit heute eine sehr viel größere Rolle und man kann sich den "Luxus" leisten, die Prioritäten entsprechend zu setzen, wenn es vernünftig ist. Dogmatisch an technischer Effizienz festzuhalten, ist jedenfalls NICHT vernünftig und das lernt man auch so im Studium. Der Trend hin zur objektorientierten Programmierung ist ja genau diesem modernen Ansatz geschuldet. Technisch am effizientesten wäre es wohl, alles direkt in Assembler zu implementieren. Die Entwicklung würde dann aber nicht nur ewig dauern, man könnte auch nichts mehr warten.
Es gibt noch mehr Aspekte, die häufig höher priorisiert werden als die Effizienz, wie Erweiterbarkeit und Plattformunabhängigkeit. So legen Java-Programme eine Performance hin wie der Musikantenstadl, aber sie laufen halt auch fast überall. In der Spiele- und Anwendungsentwicklung werden häufig selbstenwickelte Scriptsprachen eingesetzt, die von einem Interpreter eingelesen werden. Das ist langsam, hat aber den Vorteil, dass die Kopplung verringert wird und schnell Änderungen und Erweiterungen durchgeführt werden können, ohne dass das ganze Projekt neu kompiliert werden muss. Die Vorteile sind so gewaltig, dass man sie schon in den 80ern nicht missen wollte, z. B. bei der Entwicklung der Sierra- und LucasArts-Adventures, obwohl Rechenleistung da auch noch nicht so üppig verteilt war wie heute.
Man sollte immer eine ganzheitliche Sicht auf ein Projekt haben.
zuletzt bearbeitet 01.05.2015 04:06 |
|
|
 Forum Statistiken
|
Besucher
 | Einfach ein eigenes Xobor Forum erstellen |