Wenn man etwas wirklich eigenes Programmiert, ohne einfach nur fertige APIs zusammen zu kleben, spricht man auch vom "Hacken".

Ich kann also ohne Drittbibliotheken eine OCR-Software "hacken" ... das bedeutet, ich implementiere sie.

Eine andere Bedeutung von "Hacking" im Zusammenhang mit "Programmieren" ist so viel wie "schnell etwas zusammen pfuschen".

Wenn ich also schnell ein Quick'n'Dirty Addon für Clang zusammen schustere, ohne ordentliche Fehlerbeahndlung, ohne Loggin, ohne Dokumentation, vermutlich auch ohne ordentliches Testing, dann spricht man ebenfalls von "Hacken".

Zu diesen zwei Bedeutungen kommt natürlich noch die herkömmliche Bedeutung, einne Software zu knacken bzw. diese zu cracken oder einen Keygen zu bauen.

Aber im Alltag stolpere ich über den Begriff "Hacking" in der Bedeutung von "Programmieren" eigentlich nur, wenn etwas ohne Abhängigkeiten oder schnell und unordentlich zusammen geschustert wird. Vor allem letzteres trifft hier wohl am ehesten zu! :)

...zur Antwort
Findet ihr auch das zu viel auf Sauberkeit geachtet wird?

Hey,

und zwar mir ist in letzter Zeit aufgefallen das irgendwie alles immer exakter und "Reinlicher" wirken muss um Gemocht zu werden.

Fange ich doch mal mit dem ersten Punkt an.

Im Bauwesen z.B. die Häuser werden immer Würfel förmiger und auch immer symetrischer gestaltet. Warum denn eigentlich, ist das Mode oder ist das wirklich irgendwie so eine Art und weiße alles immer mehr nach Normen zu gestallten ?

Früher hatte man doch auch nicht immer alles in Rei und Glied gebaut, manchmal schon aber das war in meinen Augen eher die Ausnahme. Zudem gab es mehr Vielfalt, Herr Müller baute Häuser Model A und Herr Schneider baute Model Ö z.B.

Wenn mann heute in ein Neubau Gebiet geht sieht man gefühlt überall die Gleiche Grund bau weiße. Ist das so eine Mode Erscheinung oder handelt es sich hier um den immer mehr auftretenden Wunsch sich irgend einer Norm zu unterwerfen ?

Dann der zweite Punkt.

Bei der Erziehung der Kinder wird doch auch immer mehr auf Sauberkeit geachtet, so zum Beispiel wird heute jedes Spielzeug gefühlt 20 mal am Tag desinfiziert, warum?

Oder bestes Beispiel Thematik Sandkasten, ich bin zwar selbst erst 15 aber habe im Sandkasten trotzdem "Kuchen" gebacken und den dann auch gegessen, und für die die es nicht glauben können ja auch in dem Sandkasten wo gerade die Katze rein gekackt hat.

Oder dieses ewige Händewaschen, ich will hiermit nicht sagen das man sich gegen viele Keime (Grippe) teilweise schutzlos aussetzten soll. Aber wird damit nicht ein wenig übertrieben? Manche waschen sich ja schon die Hände wenn sie die Türklinke angefasst haben. Nach dem gang auf den Abort ( Klo ) ist Hände waschen natürlich ein muss ohne wenn und aber, und natürlich auch in medizinschen Einrichtungen ein muss, wie die Normen halt so sind!

Sorry das die Frage doch noch so lang geworden war aber ich musste mich mal wieder richtigst Auskotzen, mich nervt der ganze vor gegaukelte Trott schon mit meinen 15 Jahren schon so, als ob ich 95 wäre und ich zusehen muss wie die nächsten Generationen immer kaputter werden.

Der eigentliche Sinn hinter dieser Frage ist, ordnen wir uns nicht einfach viel zu oft unter und hören zu viel auf andere? Viele Jugendliche in meinem Alter habe ja schon fast keine richtige Persönlichkeit mehr, was ich mehr als bedenklich finde.

Naja ich Verabschiede mich hier mal und danke euch schon mal im Voraus für das durchlesen dieses ewig langen Textes und eventuell auch für Antworten und Meinungen!

Mit freundlichen Grüßen Nico W.

Anhang, Punkt drei und vier Folgen noch!

...zum Beitrag

Dein Verhalten erinnert daran, dass einigen Menschen der Respekt vor radioaktiver Strahlung fehlt, weil sie sie nicht sehen können.

Genauso bei dir und dem Thema "Krankheitserregern".

Bei der Erziehung der Kinder wird doch auch immer mehr auf Sauberkeit geachtet, so zum Beispiel wird heute jedes Spielzeug gefühlt 20 mal am Tag desinfiziert, warum?
Oder bestes Beispiel Thematik Sandkasten, ich bin zwar selbst erst 15 aber habe im Sandkasten trotzdem "Kuchen" gebacken und den dann auch gegessen, und für die die es nicht glauben können ja auch in dem Sandkasten wo gerade die Katze rein gekackt hat.
Oder dieses ewige Händewaschen, ich will hiermit nicht sagen das man sich gegen viele Keime (Grippe) teilweise schutzlos aussetzten soll. Aber wird damit nicht ein wenig übertrieben?

Weißt du was Hakenwürmer sind, wie die sich in deinem Darm einnisten, und wie sich deren Anwesenheit bemerkbar macht?

Und wenn dir diverse Hakenwürmer nicht reichen: Google mal nach "Spulwürmern", "Madenwürmern", "Bandwürmern", "Trichinen", "Nematoden", usw. ... aber bitte NICHT nachdem du gerade etwas gegessen hast!

Hinzukommen viele gefährliche Bakterien, darunter auch MRSA-Keime, oder einfach nur Colibakterien, die deine Darmflora chronisch durcheinander bringen, Kokken die Entzündungen auslösen, uvm.

Tipp: Schnapp dir ein gutes Mikroskop deiner Wahl, und untersuche einen Hautabstrich mit Ölimmersion (evtl. unter Anleitung) und dann wiederhole das Ganze nochmal nachdem du dir die Hände gewaschen hast. Und - falls eine fachkundige Person dabei ist - lass dir mal erklären, was Zoonosen sind, und wie man Wurmeier erkennen kann.

Fazit: Dein falsches Empfinden, dass Hygiene übertrieben sei, beruht einzig und allein auf deinem Unwissen über Krankheiten bzw. deren Überträger. Eine Nekrose infolge eines Wurmbefalls z. B. im Dünndarm kann dir den Rest deines Lebens versauen.

Wenn du bisher Folgen von deinem leichtsinnigen Handeln zu spüren bekommen hast, dann sei froh. Du hast Glück gehabt! Aber das wird nicht endlos so weiter gehen, und wenn du weiterhin an verdreckten Dingen rumleckst, bzw. dir diese in den Mund steckst, ist es nur eine Frage der Zeit, bis du dir einen "Mitbewohner" einfängst. :)

Ich wiederhole mich noch einmal: Lass dir unter Anleitung von einem befreundeten Biologen, Arzt, Lehrer, Wasauchimmer erklären, was du so unter dem Mikroskop in einem Abstrich z. B. von einer Türklinke siehst. Macht ruhig mal einen Gram-Test, um ein Gefühl dafür zu bekommen, welche Bakterien potentiell schwierig mit Antibiotika zu bekämpfen sind.

Hab letztens eine Frau in der Bahn gesehen, deren Kind ein Brötchen auf den total verdreckten Boden hat fallen lassen, und sie dieses aufgehoben und dem Kind zum weiteressen in die Hand gedrückt hat. Ihr Kommentar: "Das stärkt das Immunsystem" ... nun, oder es bringt das Kind um. Eins von beiden.

Viele Leute sind leider zu ungebildet, und darüber hinaus noch zu faul, sich mal vernünftig mit dem Thema zu befassen, und sich um ein Mikroskop zu kümmern. Bakterien sieht man zwar erst richtig gut unter Öl, aber es lohnt sich.

Merk dir: Nur weil du etwas nicht siehst, heißt das noch lange nicht, dass es nicht existiert oder harmlos ist!

Und zu den quadratischen Häusern kann ich nur sagen: Die Bauweise von Hundertwasser hat sich vermutlich deshalb nicht durchgesetzt, weil quadratische Formen vermutlich einfach praktischer und pragmatischer sind. Stell mal ein Regal an die Wand in einem runden Zimmer ... es wird sich nie richtig einfügen, es sei denn, du legst richtig viel Geld für eine Spezialanfertigung auf den Tisch. :)

...zur Antwort

Auch wenn ich jetzt auf die Nase bekommen werde, so denke ich, dass Frauen in der Regel schlechter programmieren als Männer.

Begründung: Der Grund dafür liegt darin, dass "Programmieren" eine sehr Zeitintensive Beschäftigung mit der Materie erfordert, um als "professionell" gelten zu können. Die meisten Frauen scheinen aber andere Prioritäten zu haben, als sich am Wochenende stundenlang hin zu setzen, und die neuesten Sprachfeatures bzw. die Standardbibliothek zu studieren, sich durch Manpages und SO nach interessanten Codebeispielen zu wühlen oder ihr Hobbyprojekt bis ins letzte Detail performancetechnisch zu optimieren.

Das ist bei JEDEM Thema / Hobby / Beruf so: Man wird nur besser durch Erfahrung, und die erhält man nun mal mehr, wenn man sich auch nach der Arbeit viele Stunden damit befasst ... und das machen im IT-Bereich eindeutig wesentlich mehr Männer als Frauen.

Natürlich gibt es auch solche Frauen, aber prozentual mit Sicherheit um Faktoren weniger, als man unter Männern findet. Und außerdem sind die meisten Männer schon nicht allzu tolle Programmierer.

Ich habe das an anderer Stelle hier schon mal geschrieben, dass ich denke, dass mindestens 90% aller Programmierer nicht wirklich professionell sind. Bei Frauen dürfte dieser Anteil nochmal deutlich höher liegen.

Aber da du ja explizit nach "in der Regel" fragst, womit der Durchschnitt gemeint sein dürfte, kann ich ganz klar sagen: Frauen sind im Schnitt schlechter, auch wenn die meisten Männer nicht wirklich gut sind. Aber natürlich gibt es auch richtige Cracks beim weiblichen Geschlecht. Bei einigen ist es ein wahrer Genuss, sich Talks von denen anzuhören, aber wie gesagt, die gibt es viiiieeeel weniger als bei den Männern ... wohlgemerkt in "relativen" Zahlen, aber "absolut" ja sowieso. :)

Nachtrag: Auch bei Hackathons ist es fast immer so, dass Frauen lieber irgendwelche Facebook-APIs mit JS zusammenkleben und in einen Electron-Container packen, als wirklich selbstständig etwas wirklich neues zu entwickeln. Wie gesagt, das ist NICHT immer so, aber es gibt da eine deutliche Tendenz, die bei Frauen und Männern ganz ganz weit auseinander geht.

...zur Antwort

Der Film ist - obwohl er m. M. n. völlig zu unrecht gehypt wird - total unrealistisch und absoluter Blödsinn.

Wie jemand anderes schon geschrieben hat, ist Maschinencode und Assembler nicht das gleiche. Bei Hacking-Wettbewerben nutzt man normalerweise Assembler um Software zu knacken, aaaaaber es gibt auch Kategorien, bei denen man nur einen Hexeditor nutzen darf und weiter rein gar nichts. In so einem Falle muss man Wissen bzgl. Maschinencode haben.

Maschinencode ist aber keine soooo große Sache, wie in dem Film dargestellt. Wer sich mit dem Thema Reversing befasst, und manchmal sog. "Crackmes" zu Übungszwecken knackt, der prägt sich unweigerlich und völlig automatisch eine ganze Latte an Maschinencode-Instruktionen ein, weil die normalerweise bei allen gängigen Disassemblern nehmen dem Klartext stehen.

(Meist hat man auf der linken Seite die Offsets, dann folgt der Maschinencode in Hexform und danach das Disassemblat ... kann man sich aber in nahezu jedem Debugger so konfigurieren, wie man lustig ist, und gerade bei professionellen Werkzeugen gibt es natürlich noch mehr Spalten mit Zusatzinfos.)

Lange Rede, kurzer Sinn: Maschinencode ist die binäre Darstellung, die man nur in einem Hexeditor vernünftig bearbeiten kann, und Assemblercode ist die textuelle Darstellung, für die es normalerweise komfortable grafische Oberflächen gibt.

Zum Rest deiner Fragen:

  1. Es ist der Binärcode gemeint, der i. d. R. in Hexform dargestellt wird, da er anders für Menschen kaum lesbar wäre. (siehe oben)
  2. Die Stichworte lauten "Jumphost" und "Kaskade". Viele Leute nutzen auch den Begriff "Proxy", was zwar auch richtig ist, den Zweck aber nicht so sehr verdeutlicht.
  3. Du kannst im Grunde genommen beliebig viele Betriebssysteme auf deinem Rechner installierten, und dann auch einen "Hexboot" machen, wenn du lustig bist. Allerdings ist es oftmals sinnvoller, auf virtuelle Maschinen oder Emulatoren zu setzen ... je nachdem, um welche Zielplattform es sich handelt.
  4. Um den "Strom zu hacken" genügt im Grunde genommen ein handelsüblicher Laptop und eine Netzwerkbuchse, da Infrastruktur auch in Deutschland (und vielen anderen Ländern) meist völlig ungeschützt über ein Standardprotokoll läuft, welches überhaupt gar kein Sicherheitskonzept vorgesehen hat. Ich will mich hier jetzt aber nicht in die Nesseln setzen, und verweise an dieser Stelle lieber auf entsprechende Vorträge des CCC. Für jemanden, der sich wirklich damit beschäftigt, ist es kein Problem, den Strom an z. B. einem Einkaufzentrum komplett abzuschalten.

Aber egal ... merk dir bitte einfach, dass nur Idioten Schaden anrichten und Dinge zum Nachteil ihrer Mitmenschen tun. Ein wahrer Hacker hat ethische Grenzen, die er nicht überschreiten wird. Als Hacker, sollte man der Gesellschaft helfen und nicht das Gegenteil davon tun.

Und nochmal zum Schluss: WhoAmI ist ein grauenvoller und unrealistischer Film. Jedem Fachmann kommt bei den Dialogen das Mittagessen hoch ... wegen Fremdschämen. :)

...zur Antwort

Threads und Prozesse sind eigentlich das gleiche, allerdings spricht man bei Threads i. d. R. von Prozessen, die eine große Anzahl an Ressourcen mit dem Elternprozess teilen.

Zum Beispiel teilen sich Threads mit dem Elternprozess meistens Speicher oder Dateihandles, usw.

Allerdings ist der Übergang absolut fließend, und wenn man z. B. bei Linux statt fork() den clone() Syscall nutzt, um einen neuen Prozess / Thread zu erzeugen, hat man Kontrolle über zich verschiedene Ressourcentypen, die dabei kopiert, geteilt, zerstört oder anderweitig behandelt werden sollen.

Unter Windows funktioniert das ähnlich, allerdings nutzen Entwickler fast ausschließlich Bibliotheken wie pthreads, welche dir die ganze Arbeit abnehmen, und intern clone() so einsetzen, wie es "meistens" sinnvoll ist.

Fazit: Die Begriffe bedeuten das gleiche, wobei die Tendenz bei "Thread" eher in Richtung "leichtgewichtiger" geht, was bedeutet, dass bei der Erzeugung eine vergleichsweise geringe Teilmenge an Ressourcen neu erzeugt bzw. kopiert wird. Von einem Prozess redet man, wenn fast das ganze Programm Eins zu Eins im Speicher dupliziert wird. (wobei hierbei seit einigen Jahrzehnten das sog. Copy-On-Write zum Einsatz kommt, um den Aufwand zu reduzieren)

Trotz Copy-On-Write schneidet der Umgang mit den benötigten Ressourcen bei Prozessen im Punkto Performance viel tiefer ein, als bei Threads, sodass man bei einfachen Parallelisierungsaufgaben normalerweise nur Threads nutzt, bzw. einen sog. Threadpool für diese Aufgaben vorhält, damit nicht bei jedem Pippifax ein neuer Thread erzeugt werden muss.

Außerdem gibt es noch wesentlich leichtere Arten von (Pseudo-)Parallelisierung, wie die Fibers unter Windows, die Coroutinen in diversen Programmiersprachen, oder entfernt auch solche Dinge wie Generatoren von Python, die sich dafür missbrauchen lassen.

...zur Antwort

Arbeite doch einfach mit mehreren Prozessen, und werte den Rückgabewert des Kindprozesses aus:

#!/bin/sh

foobar() {
	secs=`date -u '+%S'`
	rslt=`expr $secs % 2`

	test $rslt -eq 0 && echo SUCCESS || echo FAILURE

	exit $rslt
}

foobar &
foopid=$!

wait $foopid
if [ $? -eq 0 ]; then
	echo 'Foo'
else
	echo 'Bar'
fi

Anstelle von der Funktion "foobar" kannst du natürlich auch ein externes Skript aufrufen.

Alles in allem holst du dir die Kind-PID über "$!" und dir liefert "wait" das Resultat des Kindprozesses wie üblich in "$?". Der obige Code ist absolut portabel und sollte mit nahezu jeder Bourne-basierten Shell funktionieren. (also bash, zsh, ksh, usw. aber natürlich nicht die csh-Familie!)

...zur Antwort
Unentschlossen, da....

Mal völlig abgesehen vom Geschlecht oder Präfixen wie "Girls-" oder "Boys-", finde ich Praktika oder Schnuppertage für Kinder (eigentlich egal welchen Alters) an sich sehr gut.

Allerdings sollte man den Fokus m. M. n. eher auf bereits erblühte Interessen lenken. Wenn sich ein Kind für Robotik, Genetik oder Philosophie interessiert, sollte man das dann lieber fördern, anstatt Kinder in Themengebiete zu pressen, in denen am Ende höchstens ein verschwindend geringer Bruchteil hängen bleibt ... wenn überhaupt.

Bei mir gab es früher auch so eine Art Girlsday, an dem Mädchen aus vielen Klassen trotz ausdrücklicher Abneigung dem Thema ggü. regelrecht dazu gezwungen wurden, für einen Tag eine Berufsschule für Mechatroniker zu besuchen. Jungs, die davon hörten, und unbedingt mal die Bedienung und Programmierung einer CNC-Fräse erleben wollten wurden abgewiesen.

Dieses Projekt wurde zwei oder drei Jahre durch gezogen und in dieser Zeit hat sich nicht ein EINZIGES Mädchen gefunden, was eine Ausbildung an der besagten Berufsschule anfangen wollte. Von den Jungs, die sich aber durchaus dafür interessiert haben, aber nicht bei den Vorführ-Veranstaltungen bzw. Praktika dabei sein durften, haben nicht wenige ihre Lehre an genau dieser Schule abgeschlossen.

Das war Ende der 90er, noch bevor der Girlsday offiziell eingeführt wurde, und kurz nachdem der damals noch neue Studiengang "Mechatroniker" eingeführt wurde.

Von daher denke ich, dass es eine enorme Zeit-, Geld- und Ressourcenverschwendung ist, wenn man Kinder für Dinge begeistern will, die sie nicht primär interessieren, und am Ende so extrem wenig von dieser Anstrengung übrig bleibt. Mit dem gleichen Zeit-, Geld- und Ressourcenaufwand könnte man hingegen Interessengebiete, die bisher nur als zartes Pflänzchen oder fixe Idee sprießen, in eine Zukunftsvision umwandeln und den Wunsch für ein Studium oder eine Ausbildung zementieren.

Zu guter letzt: Ein Verwandter von mir ist Kindergärtner, also als Mann. Es war EXTREM schwierig für ihn, einen Job zu finden, obwohl in seiner Wohngegend und -umgebung angeblich überall händeringend nach Erziehern gesucht wurde. Er bekam ganz klipp und klar gesagt, dass es viele Eltern nicht "wünschen", dass ihr Nachwuchs von einem Mann betreut wird.

Ach, und mir fällt gerade noch ein, dass ich als Schüler mal einen Nachmittag in eine Forschungseinrichtung gegangen bin, und dem Pförtner einfach gesagt habe, dass ich mit einem Arachnologen sprechen möchte. Daraufhin habe ich ziemlich lange und ausführlich mit einem Professor am Tisch gesessen, der mir viele Fragen beantwortet und mich danach ins Archiv eingeladen hat, wo ich mir Präparate ansehen konnte, die normalerweise nicht für die Öffentlichkeit bestimmt waren. Mein Hauptinteresse zu diesem Zeitpunkt waren übrigens Mikrocontroller, hatte also überhaupt nichts mit Biologie zu tun!

Deshalb denke ich, dass JEDER (egal welchen Geschlechts) es schaffen sollte, sich für Themen jenseits des Tellerrandes zu begeistern und auch mal in andere Themengebiete hinein zu schnuppern. Niemand muss zu seinem Glück gezwungen werden, egal ob Girls-, Boys- oder Hamster--Day. Allerdings wären mehr Betriebsbesuche (geschlechterübergreifend) sicherlich für alle Kinder wertvoll.

Von mir aus, soll es ruhig weiter Girls- und Boys-Days geben, aaaaaber wenn ein Junge an einer Veranstaltung für Mädchen teilnehmen möchte, sollte er nicht ausgeschlossen werden. Anders herum gilt das gleiche. Eine Veranstaltung zum Zwecke der Inklusion sollte also nicht das Gegenteil bewirken.

...zur Antwort

Wenn ich lokal eine Software untersuche und z. B. AES-Schlüssel extrahieren will, dann kommt man um Assembler kaum drum rum.

Wenn du hingegen eine Datenbank von einem entfernten Server auslesen willst, brauchst du eigentlich nur irgend eine Skriptsprache um deine Queries abzusetzen und die Ergebnisse in Empfang zu nehmen.

Falls du hingegen in einen gut gesicherten Server einbrechen willst, der über aktuelle Updates - und damit über keine bekannten Sicherheitslücken - verfügt, dann musst du dir die Serversoftware lokal bei dir installieren und selbst nach Bugs suchen und ein Exploit dafür bauen. Dafür brauchst du dann wieder Assemblerkenntnisse.

Das, was gemeinhin als Hacking verstanden wird, ist im Grunde nur ständiges Wiedergekäue von althergebrachten Standardtechniken. Assembler würde solche Leute überfordern, weshalb hier eigentlich nur die bekannten Werkzeuge in Kombination mit Skriptsprachen eingesetzt werden. Also vergleichbar mit einem Skriptkiddie, wenn auch deutlich umfangreicher.

Zum Einbetten von Shellcode bzw. bei der Entwicklung desselben, kommen natürlich auch Hochsprachen zum Einsatz.

Trotzdem denke ich, dass die meisten Leute, die sich "Hacker" nennen, selbst überhaupt nicht mit Assembler klar kommen und nutzen werden. Braucht man ja auch nicht, wenn man "nur" eine Datenbank klauen will. :)

...zur Antwort

Warum schlagen denn hier auf einmal binnen weniger Minuten so viele Fragen zu fast dem selben Thema ein? :)

Guck mal, was ich hier jemand anderem geschrieben habe, der sich ein "Social Media" bauen will:

https://www.gutefrage.net/frage/social-media-programmieren#answer-314245946

So ziemlich das gleiche kann man auf deine Frage antworten, auch wenn deine Chat-App wesentlich realistischer ist. Dennoch lerne lieber erst mal "normal" programmieren.

Für Android-Apps wäre Java oder Kotlin empfehlenswert, für iOS hingegen Swift. Sei dir aber im Klaren darüber, dass da noch einige weitere (auch Nicht-Programmier-) Sprachen auf dich drauf zu kommen werden. (SQL, XML, für die Cleintseite HTML, JS, CSS, und noch irgendwas serverseitiges)

Fang ganz normal an zu programmieren, und stürze dich nicht gleich auf so ein Großprojekt! :)

PS: Auch WENN du es als Anfänger schaffen solltest, trifft ebenfalls alles aus meiner oben verlinkten Antwort zu: Dein System wird unsicher sein, und mit hoher Wahrscheinlichkeit werden Hacker die Daten deiner User mopsen! Außerdem wird deine App bzw. das Backend nicht gut - wenn überhaupt - skalieren, falls du wider Erwarten einen Ansturm erleben solltest. Hinzu kommt noch das Thema DSGVO it allem, was dazu gehört, wie den TOMs usw. ... also allein mit dem rechtlichen Aspekt wirst du MONATE beschäftigt sein!

Unterschätz das nicht! :)

...zur Antwort

Vergiss das lieber ganz schnell wieder. :)

Man merkt, dass du keinerlei Vorstellung davon hast, was auf dich zukommen wird.

Du bekommst das sicherlich auch als Anfänger eher schlecht als recht binnen weniger Monate zusammen geschustert, aber das ist dann unsicher, nicht skalierbar, hat garantiert eine grauenvolle Codebasis und wird nicht erweiterbar sein. Du wirst vermutlich vom Spaghetti-Code bis hin zu Blob-Klassen alle Antipatterns mitnehmen, die es gibt, und binnen kurzer Zeit enttäuscht aufgeben müssen.

Aber wie gesagt, du hast keine Ahnung, wovon du da eigentlich redest. :)

Lern lieber erst mal "programmieren", so wie alle anderen auch, und in ca. 15 Jahren kannst du dann über deine Frage hier schmunzeln, sofern es GF dann noch geben wird. :)

...zur Antwort

Wenn du wirklich gut sein willst, und Wert auf gute Codequalität legst, dann wird die Umstellung von C# auf C++ sehr "krass" werden.

Da aber die meisten Programmierer ihre aktuelle Hauptsprache meist nur oberflächlich beherrschen, wirst du vermutlich klar kommen, wenn du nur oberflächlich rumfrickelst.

Das hängt also sehr stark von deinem Arbeitgeber ab, insbesondere welchen Wert er auf guten Code legt.

Es ist sehr oft der Fall, dass auch fähige Entwickler leider dazu gezwungen sind, ihren Code "idioten-verständlich" zu schreiben, sodass ihn jeder Azubi beim Überfliegen sofort lesen kann. Dass man damit sämtliche höheren Sprachfeatures und enormes Optimierungspotential ohne Not aus der Hand gibt, ist natürlich sofort klar, aber oft werden Software-Entwickler eben nicht als "Fachleute", sondern als "Ungelernte" angesehen. Und auf diesem Niveau bleiben dann auch die meisten Code-Basen stehen.

Ich muss als C++ler ganz klar sagen, dass mein eigener Code im Schnitt sehr sauber und effizient ist, sich an gängige Konventionen hält, immer bei den striktesten Compilereinstellungen ohne Warnungen kompiliert, maximal portabel ist, gängige Sanitizer / Linter / Checker / Fuzzer keinerlei Bugs oder gar Speicherlecks finden, aaaaaaaber ein Einsteiger wird meinen Code leider nicht lesen und verstehen können.

Beachte bitte den Punkt hinter dem "aaaaaaaber", denn merkwürdiger Weise sind in den meisten Firmen nicht die Punkte davor wichtig, sondern es wird viel zu viel Wert auf die "Lesbarkeit für Unerfahrene" gelegt, was meiner Meinung nach ein riesen großer Fehler ist, und dazu führt, dass so ziemlich alle großen Software Projekte mit der Zeit zu einem riesen Haufen Müll mutieren.

Stell dir mal vor, Fachleute irgendeiner anderen Disziplin würden so arbeiten! Also wenn z. B. ein Physiker auf Tensoren verzichten würde, weil die ja für "Einsteiger zu kompliziert" sind, und sich stattdessen künstlich auf die Grundrechenarten beschränken würden.

Und gerade bei C++ ist es leider der Fall, dass die meisten Entwickler so dermaßen faul sind, sich weiter zu bilden, dass sie sich, theoretisch als Physiker, sogar vor Pippifax wie komplexen Zahlen fürchten und diese meiden.

Ein Beispiel aus der Praxis! Ausnahmen in C++ fängt man so, und zwar NUR so (Disclaimer: Es sei denn, man weiß GENAU was man tut und will eine gefangene Ausnahme speziell behandeln, was aber in 99,999% nicht zutreffen wird):

try {
  // wirf eine FooException
} catch (const FooException & ex) {
  // mach was mit "ex"
}

Ich schätze, dass MINDESTENS 30% bis 40% der C++ler das falsch machen, und man leider zu oft Dinge wie das hier ...

} catch (const FooException ex) {

... oder noch schlimmer das hier ...

} catch (FooException ex) {

... sieht. Den meisten ist überhaupt nicht klar, was ein "Exception-Stack" ist, warum es den gibt und was daran so besonders ist, dass man eben NUR Referenzen und keine kopierten Objekte fängt.

Deshalb muss ich den Satz ...

Ist doch wurscht, kennste eine, kennste alle.

... aus der anderen Antwort leider als gefährlichen Schwachsinn abtun. Diese Art von Aussagen hört man leider viel zu oft von Entwicklern, die sich bei WEITEM selbst total überschätzen und mit ihren paar Jahren auf dem Gebiet denken, sie hätten so etwas wie Erfahrung. Dem ist nicht so! Nicht mal annähernd. (Nebenbei bemerkt hört man solche Aussagen vermehrt auch von Studenten oder Schülern .. je jünger, desto öfter.)

Allein bei der Addition zweier Integer gibt es bei C++ mehr zu beachten als bei C#, und zwar so viel, dass in der einschlägigen Fachliterator ganze Kapitel dazu gefüllt sind.

Im Grunde kann man sagen, dass "kennste Eine, kennste Alle" genau das Gegenteil von dem ist, was eigentlich Realität ist. Du wirst kaum eine Aufgabenstellung finden, und sei sie auf den ersten Blick NOCH so trivial, die ein Profi in C++ so lösen wird, wie in C#.

Ich weiß, das würden so nicht alle Entwickler unterschreiben, aber seien wir mal ehrlich: Wer das anders sieht, ist vermutlich selbst leider eher Mittelmaß und verfügt nicht über den Horizont, das ganze Thema zu überblicken. (Das ist jetzt harsch ausgedrückt, trifft den Nagel aber auf den Kopf. Sorry!)

Fazit: Wenn du "Glück" hast, und an eine Pfuscherbude gerätst (was auf die meisten Firmen zutrifft), dann wird der Umstieg nicht sehr schwer für dich werden, einfach weil es niemanden im ganzen Betrieb gibt, der einschätzen könnte, was guter Code ist. :)

Wenn du "Pech" hast, kommst du in ein Unternehmen, wo du von den alten Hasen lernen kannst, was vermutlich hart werden wird, und du die erste Zeit nach Feierabend massiv büffeln musst, um dich in C++ einzufuchsen. Von solchen Firmen gibt es aber - leider - nicht viele.

Dir und deiner zukünftigen Karriere zuliebe solltest du aber darauf hoffen "Pech" zu haben, denn nur DAS wird dich langfristig weiter bringen, wenn du nicht zum Code-Monkey verkommen willst.

C++ ist sehr komplex und hat sehr viele Paradigmen und Konzepte, die es in anderen Sprachen so nicht gibt (C# übrigens auch, aber weniger als C++). Das alles zu überblicken und zu verstehen braucht Zeit ist am Ende aber das vermutlich mächtigste Werkzeug, was du so finden kannst.

C++ wurde nie für Einsteiger entwickelt, sondern für Profis, welche die Sprache und ihre Möglichkeiten gut kennen, anwenden können und zu schätzen wissen. Wer meint, dass C++ Code nur gut ist, wenn er von jedem Einsteiger sofort gelesen und verstanden werden kann, ist auf dem Holzweg.

Man erwartet von der 3D-Suite Blender auch nicht, dass sich darin sofort jeder zurecht findet, der mal in Paint rumgeklickt hat.

Also wenn du es gut machen willst, dann wird der Umstieg auf C++ von C# her nicht soooo leicht, wie du vielleicht denkst. Wenn dir while, switch und class aber grob reichen und du dich leicht mit Pfusch zufrieden geben kannst, dann solltest du keinerlei Probleme haben. :)

Trotzdem viel Erfolg! ;)
...zur Antwort
Der Umgang mit dem "Gender-Thema" finde ich zuviel.

Ginge es Gender-Befürwortern um Gleichberechtigung in der Sprache, dann würden sie im Schnitt jedem achten weiblichen Substantiv konsequent einen männlichen Artikel voranstellen, weil es ca. 25% mehr weibliche als männliche Substantive gibt.

Und wenn "der Mann" die deutsche Sprache tatsächlich zur Unterdrückung der Frauen geformt hätte, warum ist die höflichste Form dann ausgerechnet weiblich?

Ist mir aber alles ehrlich gesagt völlig Wurst. Soll jeder machen wie er lustig ist. Wenn die Texte am Ende dann aber für Dritte schwerer verständlich sind oder zu Missverständnissen führen, darf sich der Verfasser auch nicht darüber beschweren. Als Leser kann man solche Texte ja einfach beiseite legen. :)

...zur Antwort
Ich nutze tar

Als ich mich ernsthaft mit dem Thema beschäftigt habe, war pax noch nicht standardisiert, und kam nicht mit Dateien von mehreren GB klar. Inzwischen sieht das anders aus, aber tar ist eben weiter verbreitet.

Darüber hinaus füge ich zusätzliche Redundanz mit Parchhiven hinzu, weil es in der Vergangenheit schon oft passiert ist, dass Backups aufgrund von kaputten Sektoren oder Bitflips nicht mehr bzw. nur noch mit Mühe lesbar waren.

Da du dich momentan mit dem Thema befasst, lege ich dir mal folgenden Link ans Herz:

https://de.wikipedia.org/wiki/PAR2

Ohne entspr. Redundanz ist die beste Backupstrategie für den Eimer, ganz egal ob pax, tar, oder wie sie alle heißen. :)

Und natürlich sollten Backups auch verschlüsselt sein. Und zwar so, dass sie auch in 50 Jahren noch entschlüsselbar sind, sprich: standardisiertes Containerformat, wohl definierter Algorithmus, Toolunabhängiges entschlüsseln möglich (egal ob z. B. openssl oder gpg), usw.

Damit kannst du dir schön voll automatisiert wirklich portable Backup-Skripte bauen, die garantiert auch noch in zich Jahren zuverlässig arbeiten werden, anders als die meisten kommerziellen Lösungen also. :)

...zur Antwort

Selbst an einem sehr kleinen Betriebssystem, mit rudimentärer grafischer Oberfläche, sitzt man als Einzelperson viele Jahre.

Um mehrere relativ große Teams wirst du nicht drum rum kommen. :)

Bei MS arbeiten derzeit zehntausende Leute an Windows, was allerdings nicht nur Programmierer sind, sondern auch sehr viele Tester usw. :)

...zur Antwort
sh

Ich schreibe meine Skripte immer so, dass sie kompatibel zu allen großen Shells der letzten 20 Jahre sind.

Dass heißt, statt Bash-typisch eine Funktion so zu deklarieren ...

function foobar {
  echo foo bar
}

... mache ich es so ...

foobar() {
  echo foo bar
}

... oder Zählvariablen werden nicht so ...

let i++

... sondern so inkrementiert ...

i=`expr $i + 1`

Das mag auf den ersten Blick komplizierter wirken, aber langfristig laufen meine Skripte auf allen *ix-Systemen der letzten 20 Jahre problemlos und ohne Anpassungen.

Ich habe mir für diesen Fall extra ein Hilfsskript gebaut, welches diverste Ausdrücke und Sprachkonstrukte hinter einander in diversen Shells prüft und habe damit zich Inkompatibilitäten gefunden, die es zu vermeiden gilt.

Besonders zsh und ksh haben hierbei einige Fallstricke.

Um deine Frage zu beantworten habe ich "sh" als kleinsten gemeinsamen Nenner gewählt, aber wie gesagt, meine Skripte laufen grundsätzlich auf allen namhaften Shells mit mindestens 20 Jahren Abwärtskompatibilität. :)

...zur Antwort
So etwas wie "Talent" gibt es nicht, zumindest nich mal annähernd in dem Maße, von dem immer ausgegangen wird.

Wichtiger als "Talent" ist einfach nur Fleiß und Durchhaltevermögen.

Egal ob Sprachen, Programmieren oder Mathe: Wenn du genügend Zeit investierst und dich mit dem Thema intensiv befasst, wirst du irgendwann die Früchte ernten können. Punkt.

"Talent" hat damit nur so marginal etwas zu tun, dass dessen Auswirkungen bei den meisten Leuten gegen Null tendieren dürften.

Meistens wird der Begriff "Talent" im Hinblick auf Dritte nur als Ausrede benutzt, um die eigene Faulheit zu kaschieren. Wer wirkliches Interesse hat und auch wirklich arbeitet, der braucht kein Talent. :)

Also wenn du Programmieren lernen willst, dann fang verdammt nochmal damit an. Und zwar sofort. Und hör auf das Wort "Talent" zu missbrauchen. :)

...zur Antwort

Entgegen der anderen Antworten muss ich sagen, dass man "Assemblersprache" eigentlich nur von Außenstehenden hört.

Normalerweise sagt man einfach nur "Assembler" und meint damit entweder die Sprache oder die Übersetzungssoftware an sich.

"Assemblersprache" ist viel zu lang und aufgeblasen, und würde spätestens beim dritten mal durch ein kurzes "Assembler" ersetzt werden, wenn man damit arbeitet. Die einzige Ausnahme wäre, wenn du bewusst den Unterschied zwischen Sprache und Software hervor heben willst, was aber in 99% sowieso vom Kontext her klar sein sollte. :)

Deshalb haben auch alle Bücher zu dem Thema "Assembler" oder "Assemblerprogrammierung" im Titel. Mit "Assemblersprache" habe ich hingegen noch nie eins gesehen.

...zur Antwort