Ein Abiturient, der gerade sein Abi gemacht hat, will im Oktober mit dem Studium Wirtschaftsinformatik beginnen. Java kennt er schon aus dem Leistungskurs Informatik. Welche Programmiersprache würdet ihr zum Lernen empfehlen, C# oder Python, um die freie Zeit von heute bis zum Studium zu nutzen?
wer schrieb: > Excel/VBA Noch wichtiger: Outlook, Powerpint und MS-Teams sowie ein gutes Buzzword Lexikon ;-)
Jeder Unternehmen dieser Erde hat Excel installiert, besonders im BWL-Bereich. Von Python kann da gar nicht die Rede sein. Außerdem kann man fast Alles mit VBA schreiben, was mit Python auch ginge.
Rolf R. schrieb: > Welche Programmiersprache würdet ihr zum Lernen empfehlen, C# oder > Python, um die freie Zeit von heute bis zum Studium zu nutzen? C
Nano schrieb: > Rolf R. schrieb: >> Welche Programmiersprache würdet ihr zum Lernen empfehlen, C# oder >> Python, um die freie Zeit von heute bis zum Studium zu nutzen? > > C Und zwar ohne #
Rolf R. schrieb: > Welche Programmiersprache würdet ihr zum Lernen empfehlen, C# oder > Python, um die freie Zeit von heute bis zum Studium zu nutzen? Wenn nur die Wahl zwischen diesen beiden Sprachen in Frage kommt, dann ganz klar: C#.
c-hater schrieb: > Rolf R. schrieb: > >> Welche Programmiersprache würdet ihr zum Lernen empfehlen, C# oder >> Python, um die freie Zeit von heute bis zum Studium zu nutzen? > > Wenn nur die Wahl zwischen diesen beiden Sprachen in Frage kommt, dann > ganz klar: C#. Ich bin auch offen für andere Sprachen. Erst dachte ich, Excel/VBA wäre ein Witz gewesen. Jetzt habe ich mir dazu aber mal ein paar Videos auf youtube angeschaut und gesehen, dass es nicht schaden kann, das zu können als Wirtschaftsinformatiker. Ich denke, es wird darauf hinauslaufen, von diesen 3 die Grundlagen bis Oktober zu lernen: - Python - C# - Excel/VBA Am Ende hat er dann Grundlagenwissen von allen drei und kann dann bei Bedarf später tiefer einsteigen.
:
Bearbeitet durch User
Rolf R. schrieb: > Ich denke, es wird darauf hinauslaufen, von diesen 3 die Grundlagen bis > Oktober zu lernen: > - Python > - C# > - Excel/VBA Das wird eng mit dem Zeitplan. Man kann nicht wirklich hinreichend diese drei Sprachen in diesem Zeitrahmen lernen. Die Sprache ist ja immer nur die halbe Miete (bestenfalls). Die eigentliche Macht ergibt sich immer erst durch die Kenntnis der durch die Sprache erreichbaren Frameworks. Das können nichtmal Leute, die sowieso seit Jahrzehnten mit immer wieder anderen Sprachen behelligt wurden und das deshalb schon ein wenig gewohnt sind (und ggf. auch verwandte Sprachen oder erreichbare Frameworks schon vorher kannten). Zumindest würde es auch für die etwas knapp werden. Für jemanden, der eigentlich keine Ahnung, keine Erfahrung und keine Vorkenntnisse hat: hoffnungslos unrealistisch.
c-hater schrieb: > Für jemanden, der eigentlich keine Ahnung, keine Erfahrung und keine > Vorkenntnisse hat: hoffnungslos unrealistisch. Vorkenntnisse in Java sind ja vorhanden. Und C# z.B. ist relativ leicht zu lernen, wenn man schon Java kann. Es geht ja auch nicht darum, in allen drei perfekt zu sein. Es geht darum, die Grundlagen zu kennen. Mit diesem Grundlagenwissen kann man dann später z.B. besser einschätzen, welche Sprache für welches Problem besser geeignet ist. Tiefer einsteigen kann er dann später immer noch je nach den Anforderungen, die bei einer Werkstudentenstelle gefordert werden.
Rolf R. schrieb: > Vorkenntnisse in Java sind ja vorhanden. Und C# z.B. ist relativ leicht > zu lernen, wenn man schon Java kann. Was nützt C# ohne .net-Framework? Nahezu nix.
Nur, dass es .NET quasi überall gibt. C# ist eine super Applikationssprache, vor allem für GUIs. Und es ist echt fix. Dazu lernst du vor allem modernes OOP. Kann nicht schaden, und wenn es nur dazu ist, zu wissen, dass man es nicht braucht ;) Modernes VBA ist auch erstaunlich leistungsfähig und vielseitig. Aber Microsoft geht IMO in die Richtung einer neuen Skriptsprache, vba ist nicht unterstützt in o365 Web. @op, lern Python. Das kannst du nämlich für alles benutzen, gerade für viel Kleinscheiß. Du lernst eh während des Studiums, welche Sprachen du brauchst. Außerdem geht’s häufig um Konzepte. Viel Spaß
Rolf R. schrieb: > Ich denke, es wird darauf hinauslaufen, von diesen 3 die Grundlagen bis > Oktober zu lernen: > - Python > - C# > - Excel/VBA > > Am Ende hat er dann Grundlagenwissen von allen drei und kann dann bei > Bedarf später tiefer einsteigen. Nur hat er dann keine Ahnung wie unter der Haube verkettete Listen aufgebaut sind. Ebenso wird ihm ein tieferes Verständnis bezüglich Stack und Heap fehlen. Und wenn das Studium beginnt, hat er kaum Zeit, da richtig einzusteigen. Deswegen empfehle ich C.
Rolf R. schrieb: > Vorkenntnisse in Java sind ja vorhanden. Und C# z.B. ist relativ leicht > zu lernen, wenn man schon Java kann. Ich würde sogar sogar sagen, daß es redundant ist. C# ist die Sprache, die man mit Java eigentlich schaffen wollte. OK, abgesehen davon, daß es eine Nischensprache ist. Auch wenn für manche diese Nische die ganze Welt zu sein scheint: Jan schrieb: > Nur, dass es .NET quasi überall gibt Wenn man Windows für "alles man es gibt" hält, dann ja. Aber ich habe schlechte Nachrichten für dich: die Tage von Windows sind gezählt. Das hat inzwischen sogar Microsoft eingesehen. Mein Vorschlag wäre: mal ein radikal anderes Programmiersprachen Konzept auszuprobieren. Also Lisp oder Haskell. Oder - weil es weniger ungewohnt ist - Ruby. Oder wenn man beim althergebrachten bleiben will: eine moderne Interpretation wie z.B. Rust.
Axel S. schrieb: > Jan schrieb: >> Nur, dass es .NET quasi überall gibt > > Wenn man Windows für "alles man es gibt" hält, dann ja. .net gibt es aber längst nicht mehr nur unter Windows. Naja, es heißt anderswo anders (nämlich mono) und stellt nur einen Subset der Features bereit, aber es existiert und funktioniert inzwischen erstaunlich gut. Und auch dieser Feature-Subset wird ständig aufgebohrt (und von der anderen Seite über .net Core geschrumpft). Es ist ganz klar, dass das Ziel ist, am Ende ein vereinheitlichtes systemübergreifendes Framework zu schaffen. Um das NICHT zu erkennen, muß man wohl Axel S. heißen... > Aber ich habe > schlechte Nachrichten für dich: die Tage von Windows sind gezählt. Das > hat inzwischen sogar Microsoft eingesehen. Das bezweifele ich. Ganz ernsthaft. Die diversifizieren nur. Aber so lange sich mit Windows Geld verdienen läßt, werden die das tun. Nur Idioten würden ein OS aufgeben, was auf >>90% der Desktop-Systeme weltweit erfolgreich läuft und auf das unzählige wichtige Industrie-Anwendungen aufsetzen. Und auch wieder: Um das NICHT zu erkennen, muß man wohl Axel S. heißen...
Access mit Macros ist als Datenbanksystem immer noch ungeschlagen und die Nachfrage wird in Zukunft exponentiell steigen!
Nano schrieb: > Rolf R. schrieb: >> Ich denke, es wird darauf hinauslaufen, von diesen 3 die Grundlagen bis >> Oktober zu lernen: >> - Python >> - C# >> - Excel/VBA >> >> Am Ende hat er dann Grundlagenwissen von allen drei und kann dann bei >> Bedarf später tiefer einsteigen. > > Nur hat er dann keine Ahnung wie unter der Haube verkettete Listen > aufgebaut sind. Ebenso wird ihm ein tieferes Verständnis bezüglich Stack > und Heap fehlen. Abgesehen davon das die Liste falsch herum sortiert ist, muss er auch nicht wissen wie eine (doppelt) verkettete Liste, oder sonstwas unter der Haube aussieht, er ist als Wirtschaftsinformatiker in dieser Hinsicht Anwender, kein Entwickler. > Und wenn das Studium beginnt, hat er kaum Zeit, da richtig einzusteigen. > > Deswegen empfehle ich C. Als Entwickler ist C nie verkehrt, aber als Wirtschaftsinformatiker eher unwichtig; dagegen ist Excel/VBA absolut Sinnvoll und auch C# kann für einfache und schnell gebaute GUI-Programme gute Dienste Leisten. C ist halt prozedurale Programmierung und damit für einen Wirtschaftsinformatiker deutlich weniger Wert als irgendwas Objektorientiertes. Ich habe ursprünglich mit Basic, Assembler und C angefangen, später in der Schule kam dann Delphi und im Studium gings wieder zu C und C++. Aufgrund der absolut vermurksten Firmenpolitik von Borland/Embacadero/Inprise habe ich mich dann irgendwann komplett von Delphi abgewandt (was ich immer noch lieber als C++ und QT für GUIs genutzt habe) und kam schließlich zu C# was ich bis heute wenig bereue. Beruflich nutze ich hingegen deutlich öfter Excel als mir lieb ist, einfach weil man da am schnellsten Ergebnisse bekommt. Auf Microcontrollern ASM oder C und die Entsprechenden GUIs auf den Rechnern meist mit C# wenn nicht gerade ein Webinterface als GUI genutzt wird.
:
Bearbeitet durch User
Ich habe zwei Wirtschaftsinformatiker als Vorgesetzte. Beide haben keinen Schimmer von Programmierung. Der ältere von beiden hatte damals wenigstens mal einige Batchscripte erstellt. Damals gab es wohl noch kein VBA. Der jüngere hat mal etwas mit VBA gemacht. Jedoch nie ernsthaft. Von anderen Sprachen haben sie keine Ahnung. Während meines Studiums wurden die Wirtschaftsinformatiker gerne für die SAP-Programmierung verheizt. Keine Ahnung, in was das programmiert ist. Wer als Wirtschaftsinformatiker überhaupt programmieren kann, gehört schon zur Oberschicht.
Informatik ist nicht (allein) die Wissenschaft vom Programmieren. Es gibt folglich Tätigkeiten für Informatiker, die Kenntnis in Programmierung verlangen. Und es gibt viele Tätigkeiten, die das nicht verlangen. Mit oder oder Wirtschaft.
c-hater schrieb: > .net gibt es aber längst nicht mehr nur unter Windows. Naja, es heißt > anderswo anders (nämlich mono) und stellt nur einen Subset der Features > bereit, aber es existiert und funktioniert inzwischen erstaunlich gut. Und wird wo genau eingesetzt? Es ist für einen WI Ing wahrscheinlich völlig wuppe, aber zum ernsthaft programmieren tut man sich professionell nicht mehr eine Sprache an die nur auf einem Betriebssystem läuft. Oder hast du Beispiele wo mono professionell eingesetzt wird? In Zeiten von Cloud Computing, Virtualisierung und Container setzt keiner mehr im professionellen bereich nur auf Windows. Und Oberflächen sind mehr und mehr Web-Oberflächen. Kann man gut finden, muss man nicht aber so sieht die Welt aus. Und wenns Hardwarenah sein soll ist es immer noch C oder C++
Christian H. schrieb: > Wer als Wirtschaftsinformatiker überhaupt programmieren kann, gehört > schon zur Oberschicht. Wenn ein Programmierer aufsteigt, ist er nur noch mit Besprechungen, Konferenzen und Präsentationen beschäftigt, und hat keine Zeit mehr, das Projekt programmtechnisch voran zu bringen. Chefs in einem entsprechenden Umfeld müssen also wissen, wer unter den Programmierer unverzichtbar ist. Und die müssen unten halten, sonst fehlen sie. Wer aber besser koordinieren und labern als programmieren kann, wird da nicht gebraucht, und darf aufsteigen. > Ich habe zwei Wirtschaftsinformatiker als Vorgesetzte. Beide haben > keinen Schimmer von Programmierung. q.e.d. Wer stolz verkündet, dass ein Projekt sich voll auf seine Fähigkeiten als Programmierer stützt, der ist in der Hierarchie wahrscheinlich unten angesiedelt. Soviel zu Oberschicht. ;-)
:
Bearbeitet durch User
Viele verwechseln das Erlernen einer Programmiersprache mit Programmieren lernen. Es ist aber viel wichtiger, die Grundprinzipien des prozeduralen und OOP-Programmierens allgemein zu verstehen. Konzepte, Strukturen, Algorithmen ... und das kommt nur durch langjährige Praxis, egal in welcher Sprache. Viel wichtiger ist der "analytische Blick", um ein Problem zu erfassen. Und das kommt nicht von jetzt auf gleich. Natürlich benötigt man Kenntnisse in einer Programmiersprache, um das Erlernte auszuprobieren, aber ob im konkreten Fall nun die Klammern rund oder eckig sind oder am Ende einer Zeile ein Semikolon stehen muss oder nicht, ist sowas von egal ...
:
Bearbeitet durch User
Rolf R. schrieb: > Ein Abiturient, der gerade sein Abi gemacht hat, will im Oktober mit dem > Studium Wirtschaftsinformatik beginnen. Dass der Abiturient hier nicht selber nachfragt, zeigt, dass er den Wirtschaftsteil seines geplanten Studiengangs gar nicht mehr nötig hat, Denn das A und O eines Wirtschaftlers beherrscht er schon bestens: das Delegieren. Mit dieser Fähigkeit verliert aber auch der Informatikteil an Bedeutung, denn alles, was er dort lernen würde, lässt er zukünftig sowieso andere erledigen. Fazit: Der Abiturient muss nicht studieren, er kann sofort in den Job einsteigen. Damit er aber auch ohne Studium von seinem zukünftigen Vorgesetzten, der ein waschechter BWLer sein wird, als Informatikexperte akzeptiert wird, sollte er sich vorher noch zwei weitere Fähigkeiten (am besten in einem VHS-Kurs) aneignen: - den Vorgesetzten bei seinen Vorträgen beim Weiterblättern der Powerpoint-Präsentation unterstützen (erstellen muss er die Präsentation nicht können, das macht die Sekretärin) - den Windows-Laptop des Vorgesetzten neuinstallieren, nachdem sich darauf so viel Mist aus dem Internet angesammelt hat, dass die Powerpoint-Präsentation nicht mehr ohne peinliche Pop-Ups durchläuft SCNR ;-) Zur eigentlichen Frage: Ich würde die Sprache lernen, die laut Studienplan im Studium verwendet wird. Falls die Frage darauf abzielt, welche Sprache in seinem späteren Berufsleben von Nutzen sein wird: Jede Antwort darauf ist mit sehr hoher Wahrscheinlichkeit falsch.
Yalu X. schrieb: > Ich würde die Sprache lernen, die laut Studienplan im Studium verwendet > wird. Das ist Java. Java hat er aber schon im Informatikleistungskurs gehabt.
Jojo schrieb: > Das lernt er doch im Studium oder nicht? Als Wirtschaftsinformatiker? Das hängt von den Modulen ab. Da er im Wirtschaftsinformatikstudium aber kaum Module hat, die ins Low Level der Informatik absteigen, würde ich es für möglich halten, dass er das kaum lernt. Sicherlich kann das auch vom Prof abhängen. Aber Wirtschaftsinformatik ist halt mehr High Level Sprachen wie C#, Java, JavaScript und jede Menge Webzeugs. Und das Thema Wirtschaft muss auch noch irgendwo untergebracht werden, also fehlt die Zeit für Module die tief in die Materie einsteigen. Und natürlich ist das von Bundesland zu Bundesland unterschiedlich. Aber selbst wenn er jetzt reine Informatik studieren würde, würde ich ihm C empfehlen. Weil auch da fängt man am Anfang meist mit Java an und macht dann ne Weile in den ersten Semestern Java ohne wirklich zu wissen, wie Java unter der Haube arbeitet. Später kommen dann natürlich die anderen Module dazu, wo dann C unabdingbar ist. Aber da ist es dann schon gut, wenn man C schon kann und vorher ist es gut, wenn man C schon kann, weil man dann auch über Java ein besseres Verständnis hat. Letzten Endes macht man mit C nie etwas falsch, wenn man das lernt und kann.
Axel S. schrieb: > Jan schrieb: >> Nur, dass es .NET quasi überall gibt > > Wenn man Windows für "alles man es gibt" hält, dann ja. Aber ich habe > schlechte Nachrichten für dich: die Tage von Windows sind gezählt. Das > hat inzwischen sogar Microsoft eingesehen. Es gibt noch Mono. https://de.wikipedia.org/wiki/Mono_(Software)
Tim T. schrieb: > Nano schrieb: >> Rolf R. schrieb: >>> Ich denke, es wird darauf hinauslaufen, von diesen 3 die Grundlagen bis >>> Oktober zu lernen: >>> - Python >>> - C# >>> - Excel/VBA >>> >>> Am Ende hat er dann Grundlagenwissen von allen drei und kann dann bei >>> Bedarf später tiefer einsteigen. >> >> Nur hat er dann keine Ahnung wie unter der Haube verkettete Listen >> aufgebaut sind. Ebenso wird ihm ein tieferes Verständnis bezüglich Stack >> und Heap fehlen. > > Abgesehen davon das die Liste falsch herum sortiert ist, muss er auch > nicht wissen wie eine (doppelt) verkettete Liste, oder sonstwas unter > der Haube aussieht, er ist als Wirtschaftsinformatiker in dieser > Hinsicht Anwender, kein Entwickler. Ja und dann kommt so ein scheiß unperformanter Code als Ergebnis raus. Gerade weil er nicht weiß, wie das unter der Haube funktioniert. Genau das ist die Folge davon. Wer guten Code schreiben muss, muss wissen, wie es unter der Haube funktioniert. Man sollte sogar die Hardware kennen, damit man nicht auf die Schnappsidee kommt und glaubt, dass das Einfügen eines Wertes in eine verkettete Liste grundsätzlich schneller sei, als in ein nicht all zu großes Array. > C ist halt prozedurale Programmierung und damit für einen > Wirtschaftsinformatiker deutlich weniger Wert als irgendwas > Objektorientiertes. Der Wert erschließt sich dadurch, in dem man weiß, was in einer konkreten Situation vom High Level her performant ist, weil man es vom Low Level her einschätzen kann. Und zu dem Rest deines Beitrags was du alles so nutzt. Schön und gut, aber das trägt nichts zur Thematik bei.
Nano schrieb: > Wer guten Code schreiben muss, muss wissen, wie es unter der Haube > funktioniert. Man sollte sogar die Hardware kennen, damit man nicht auf > die Schnappsidee kommt und glaubt, dass das Einfügen eines Wertes in > eine verkettete Liste grundsätzlich schneller sei, als in ein nicht > all zu großes Array. Oben habe ich mich gerade unglücklich ausgedrückt. Mit Wert meine ich hier ein weiteres Element.
Axel S. schrieb: > die Tage von Windows sind gezählt Verallgemeinert: Die Tage massenhafter, selbständig arbeitender zur Autarkie fähiger Systeme sind gezählt. Das zumindest ist der Trend.
Frank E. schrieb: > Viele verwechseln das Erlernen einer Programmiersprache mit > Programmieren lernen. > > Es ist aber viel wichtiger, die Grundprinzipien des prozeduralen und > OOP-Programmierens allgemein zu verstehen. Konzepte, Strukturen, > Algorithmen ... und das kommt nur durch langjährige Praxis, egal in > welcher Sprache. > > Viel wichtiger ist der "analytische Blick", um ein Problem zu erfassen. > Und das kommt nicht von jetzt auf gleich. > > Natürlich benötigt man Kenntnisse in einer Programmiersprache, um das > Erlernte auszuprobieren, aber ob im konkreten Fall nun die Klammern rund > oder eckig sind oder am Ende einer Zeile ein Semikolon stehen muss oder > nicht, ist sowas von egal ... Richtig, den analytischen Blick kriegst du aber nicht zwingend mit einer Hochsprache, weil du dafür wissen musst, wie das Zeug unter der Haube funktioniert. Und diese Ahnung lernt man eben mit C, während die Hochsprache alles wegabstrahiert und sich dann der Nutzer wundert, warum seine Lösung, ein paar tausend Elemente in Listen einzufügen auf der gegebenen Hardware langsamer geht, als der Programmierguru, der dafür ein Array verwendet.
Nano schrieb: > Axel S. schrieb: >> Jan schrieb: >>> Nur, dass es .NET quasi überall gibt >> >> Wenn man Windows für "alles man es gibt" hält, dann ja. Aber ich habe >> schlechte Nachrichten für dich: die Tage von Windows sind gezählt. Das >> hat inzwischen sogar Microsoft eingesehen. > > Es gibt noch Mono. Ach bitte! Das ein weiteres .net Framework das zu nichts kompatibel ist. Als ich Windows noch angefaßt habe mußte ich alle Nase lang eine neue Version des Frameworks installieren, weil irgendeine verk*ckte Software ein Feature ganz toll fand, das erst in der nächsten Version drin war. Und jetzt verlassen wir das M$ Universum und stellen uns das ganze mit Mono vor ... Nein, das .net Projekt ist tot. Noch töter als Java, nachdem es von Oracle aufgekauft^W ausgeschlachtet wurde. Wenn Microsoft gewollt hätte, dann hätten sie .net ja plattformübergreifend bereitstellen können. Aber sie haben das selbst nach der Übernahme von Xamarin nicht getan. Die wollen anscheinend gar nicht, daß das jemand benutzt.
Nano schrieb: > Tim T. schrieb: >> Abgesehen davon das die Liste falsch herum sortiert ist, muss er auch >> nicht wissen wie eine (doppelt) verkettete Liste, oder sonstwas unter >> der Haube aussieht, er ist als Wirtschaftsinformatiker in dieser >> Hinsicht Anwender, kein Entwickler. > > Ja und dann kommt so ein scheiß unperformanter Code als Ergebnis raus. > Gerade weil er nicht weiß, wie das unter der Haube funktioniert. > Genau das ist die Folge davon. Nö, er wird einfach ein List Objekt benutzen und das wurde bereits von entsprechenden Leuten hinreichend schnell genug implementiert. > Wer guten Code schreiben muss, muss wissen, wie es unter der Haube > funktioniert. Man sollte sogar die Hardware kennen, damit man nicht auf > die Schnappsidee kommt und glaubt, dass das Einfügen eines Wertes in > eine verkettete Liste grundsätzlich schneller sei, als in ein nicht > all zu großes Array. Guter Code bedeutet aber nicht zwangsweise performant. >> C ist halt prozedurale Programmierung und damit für einen >> Wirtschaftsinformatiker deutlich weniger Wert als irgendwas >> Objektorientiertes. > > Der Wert erschließt sich dadurch, in dem man weiß, was in einer > konkreten Situation vom High Level her performant ist, weil man es vom > Low Level her einschätzen kann. Da du bereits den Unterschied zwischen gutem Code und performantem Code nicht verstanden hast, ist die Diskussion darüber nicht wirklich zielführend. Zumal ein Wirtschaftsinformatiker selten hoch performanten Code braucht. > Und zu dem Rest deines Beitrags was du alles so nutzt. > Schön und gut, aber das trägt nichts zur Thematik bei. Stimmt, danke. Es fehlt die Information das ich nach meinem Abschluss in Elektrotechnik mit Schwerpunkt Informationstechnologie(Informatik) selber einen Master als Wirtschaftsingenieur mit dem Schwerpunkt Informationstechnologie(Informatik) gemacht habe, also nicht so weit weg von einem Wirtschaftsinformatiker bin und daher sowohl die Anforderungen als auch das spätere Einsatzfeld ganz gut beurteilen kann.
:
Bearbeitet durch User
Tim T. schrieb: > Nano schrieb: >> Tim T. schrieb: >>> Abgesehen davon das die Liste falsch herum sortiert ist, muss er auch >>> nicht wissen wie eine (doppelt) verkettete Liste, oder sonstwas unter >>> der Haube aussieht, er ist als Wirtschaftsinformatiker in dieser >>> Hinsicht Anwender, kein Entwickler. >> >> Ja und dann kommt so ein scheiß unperformanter Code als Ergebnis raus. >> Gerade weil er nicht weiß, wie das unter der Haube funktioniert. >> Genau das ist die Folge davon. > > Nö, er wird einfach ein List Objekt benutzen und das wurde bereits von > entsprechenden Leuten hinreichend schnell genug implementiert. Na Gratulation, da sieht man eben, dass du keine Ahnung hast und genau so einer bist, der keinen gescheiten, im Kontext der Thematik also im Sinne von performanten Code hinkriegt. Ein List Objekt kann zwar verglichen mit eigenen implementierten verketteten Listen schnell sein, aber damit schlägst du kein Array das in den Cache passt. Denn letzteres wirst du über ein List Objekt nicht kriegen, weil diese entsprechenden Leute dieses List Objekt generisch erstellen müssen, dass sich für alles mögliche als verkettete Liste einsetzen lässt und die nicht im Vorfeld sehen können, wofür du es und auf welcher Hardware du es einsetzen möchtest. Im Prinzip verhält es sich da wie mit der Wahl zwischen einem guten performanten Algorithmus und einem schlechten langsamen Algorithmus. Es spielt nämlich im Mittel keine Rolle, wie gut dein langsamer Algorithmus implementiert wurde, wenn der andere performante Algorithmus im Mittel meist besser ist. Du hast dann schlichtweg den falschen Algorithmus verwendet und diese Dummheit kann dir auch kein guter Compiler und keine Leute abnehmen, die den Compiler bauen. Und so ist es auch mit verketteten Listen vs. Arrays. >> Wer guten Code schreiben muss, muss wissen, wie es unter der Haube >> funktioniert. Man sollte sogar die Hardware kennen, damit man nicht auf >> die Schnappsidee kommt und glaubt, dass das Einfügen eines Wertes in >> eine verkettete Liste grundsätzlich schneller sei, als in ein nicht >> all zu großes Array. > > Guter Code bedeutet aber nicht zwangsweise performant. Der Kontext ist hier performanter Code und in dem Sinne ist das gut auch zu verstehen. > Da du bereits den Unterschied zwischen gutem Code und performantem Code > nicht verstanden hast, Du hast Dünnschiss > Zumal ein Wirtschaftsinformatiker selten hoch performanten > Code braucht. Das hat mit der Sache gar nichts zu tun. Denn die Frage ist ja, ob er es kann, wenn er es braucht. Und du kannst es, wie man oben sieht, nicht. Und der Wirtschaftsinformatiker wahrscheinlich auch nicht, wenn er sich nicht richtig informiert. Und zum Rest. Nochmal, das ist irrelevant.
Nano schrieb: > Na Gratulation, da sieht man eben, dass du keine > Ahnung hast und genau so einer bist, der keinen > gescheiten, im Kontext der Thematik also im Sinne > von performanten Code hinkriegt. Hmm. Du bist der Meinung, es dient Deiner Position in der Diskussion, wenn Du Leute vollpöbelst und persönlich angreifst, die Dir nix getan haben? Ernsthaft? > Ein List Objekt kann zwar verglichen mit eigenen > implementierten verketteten Listen schnell sein, > aber damit schlägst du kein Array das in den Cache > passt. Ahh ja... besonders wohl deshalb, weil das Einfügen und Streichen von Elementen in Arrays so wahnsinnig performant ist... > Denn letzteres wirst du über ein List Objekt nicht > kriegen, weil diese entsprechenden Leute dieses List > Objekt generisch erstellen müssen, dass sich für > alles mögliche als verkettete Liste einsetzen lässt > [...] Da schlagen die Scheuklappen des geborenen C-Fricklers wieder zu. Wer sagt, dass ein Listen-Objekt als verkettete Liste implementiert sein muss? > Im Prinzip verhält es sich da wie mit der Wahl zwischen > einem guten performanten Algorithmus und einem schlechten > langsamen Algorithmus. > Es spielt nämlich im Mittel keine Rolle, wie gut dein > langsamer Algorithmus implementiert wurde, wenn der andere > performante Algorithmus im Mittel meist besser ist. > Du hast dann schlichtweg den falschen Algorithmus verwendet > und diese Dummheit kann dir auch kein guter Compiler und > keine Leute abnehmen, die den Compiler bauen. Korrekt. Deswegen wird es einen Punkt geben, ab dem ein O(n^2)-Algorithmus, der in hochoptimiertem C implementiert ist, von einem O(n*log(n))- Algorithmus, der in lahmem Tcl programmiert wurde, geschlagen wird. Was wolltest Du doch gleich beweisen? >> Guter Code bedeutet aber nicht zwangsweise performant. > > Der Kontext ist hier performanter Code [...] Ahh ja. Und das findest Du genau wo in der ursprünglichen Frage? >> Zumal ein Wirtschaftsinformatiker selten hoch performanten >> Code braucht. > > Das hat mit der Sache gar nichts zu tun. Ahh ja. Die Frage, was ein Wirtschaftsinformatiker typischerweise so braucht, hat nix mit der Frage zu tun, welche Sprache ein angehender Wirtschaftsinformatiker lernen sollte. Klasse. Keine weiteren Fragen.
Egon D. schrieb: > Nano schrieb: > >> Na Gratulation, da sieht man eben, dass du keine >> Ahnung hast und genau so einer bist, der keinen >> gescheiten, im Kontext der Thematik also im Sinne >> von performanten Code hinkriegt. > > Hmm. > > Du bist der Meinung, es dient Deiner Position in der > Diskussion, wenn Du Leute vollpöbelst und persönlich > angreifst, die Dir nix getan haben? Ernsthaft? Doch, hat er. Lies mal richtig, er schrieb; "> Da du bereits den Unterschied zwischen gutem Code und performantem Code > nicht verstanden hast," das ist ne bodenlose Unterstellung und Frecheit. Also kriegt er, was er wahrlich verdient zurück. >> Ein List Objekt kann zwar verglichen mit eigenen >> implementierten verketteten Listen schnell sein, >> aber damit schlägst du kein Array das in den Cache >> passt. > > Ahh ja... besonders wohl deshalb, weil das Einfügen > und Streichen von Elementen in Arrays so wahnsinnig > performant ist... Tja und du bist leider auch so ein Kandidat der es nicht weiß. Oben habe ich es eigentlich schon erwähnt. Stichwort: Cache Eine Moderne CPU, die ein Array im Cache bearbeitet, hat die schneller sortiert, verändert und neue Elemente eingefügt, als das bei einer verketteten Liste der Fall ist. Letzteres läuft nämlich über den langsamen Hauptspeicher. Aber ich sag ja, das sind so Sachen, die man halt nur weiß, wenn man weiß, wie die Dinger unter der Haube funktionieren und wie die Hardware funktioniert. >> Denn letzteres wirst du über ein List Objekt nicht >> kriegen, weil diese entsprechenden Leute dieses List >> Objekt generisch erstellen müssen, dass sich für >> alles mögliche als verkettete Liste einsetzen lässt >> [...] > > Da schlagen die Scheuklappen des geborenen C-Fricklers > wieder zu. > Wer sagt, dass ein Listen-Objekt als verkettete Liste > implementiert sein muss? Von wo soll der C Compilerbauer denn wissen, wie viele Elemente du darin ablegen willst? Natürlich muss er das generisch machen, also nimmt er eine verkettete Liste oder eine Datenform die er im Hauptspeicher ablegen kann. Er wird also nicht das Array nehmen, denn um das nehmen zu können, muss man wissen, wieviel Cache die Hardware hat und wie viele Elemente da überhaupt bearbeitet werden sollen und das weiß nur der Programmierer der den Compiler lediglich nutzen soll. > Deswegen wird es einen Punkt geben, ab dem ein O(n^2)-Algorithmus, > der in hochoptimiertem C implementiert ist, von einem O(n*log(n))- > Algorithmus, der in lahmem Tcl programmiert wurde, geschlagen > wird. > > Was wolltest Du doch gleich beweisen? Dass du es nicht verstanden hast. Was aber natürlich daran liegt, da dir die Bedeutung des Cache und dieses Geheimnis darum im Zusammenhang von z.b. verketteten Listen nicht bekannt ist. Und das liegt eben wieder genau daran, dass du dich nie damit beschäftigt hast, wie das unter der Haube funktioniert und was die HW leisten kann. > >>> Guter Code bedeutet aber nicht zwangsweise performant. >> >> Der Kontext ist hier performanter Code [...] > > Ahh ja. > Und das findest Du genau wo in der ursprünglichen Frage? Siehe oben mein erstes Posting, da habe ich den Rahmen des Kontextes gezogen.
Nano schrieb: >> Du bist der Meinung, es dient Deiner Position in der >> Diskussion, wenn Du Leute vollpöbelst und persönlich >> angreifst, die Dir nix getan haben? Ernsthaft? > > Doch, hat er. Ich verstehe Deinen Standpunkt, bin aber andere Meinung. > Lies mal richtig, er schrieb; > "> Da du bereits den Unterschied zwischen gutem Code > > und performantem Code nicht verstanden hast," > > das ist ne bodenlose Unterstellung und Frecheit. Nö. Das ist m.E. die Wahrheit. Du hast das tatsächlich nicht verstanden. Für Software gibt es DEUTLICH mehr Qualitätskriterien als die reine Laufzeit. Gute Ingenieure wissen das -- Frickler nicht. >>> Ein List Objekt kann zwar verglichen mit eigenen >>> implementierten verketteten Listen schnell sein, >>> aber damit schlägst du kein Array das in den Cache >>> passt. >> >> Ahh ja... besonders wohl deshalb, weil das Einfügen >> und Streichen von Elementen in Arrays so wahnsinnig >> performant ist... > > Tja und du bist leider auch so ein Kandidat der es > nicht weiß. Oben habe ich es eigentlich schon erwähnt. > > Stichwort: Cache Schwachsinn. > Eine Moderne CPU, die ein Array im Cache bearbeitet, Welche moderne CPU bearbeitet ein Array von, sagen wir, 10 Millionen Elementen im Cache? Im First-Level-Cache gar? Richtig: Keine. Wenn an Position 107 drei Byte eingefügt werden müssen, hast Du die Brille auf, denn dann werden die restlichen 9.999xxx Millionen Elemente umgespeichert. > hat die schneller sortiert, verändert und neue Elemente > eingefügt, als das bei einer verketteten Liste der Fall > ist. Letzteres läuft nämlich über den langsamen > Hauptspeicher. Ich wiederhole mich: Schwachsinn. Was schneller ist, hängt von der Relation der Datenmenge zur Zugriffszeit ab. First-Level-Cache ist über zwei Fäuste 50 mal schneller als Hauptspeicher. Wenn die Datenmenge aber nur 0.1% beträgt, gewinnt trotzdem der Hauptspeicher. > Aber ich sag ja, das sind so Sachen, die man halt nur > weiß, wenn man weiß, wie die Dinger unter der Haube > funktionieren und wie die Hardware funktioniert. Hmm. Lass' es mich so sagen: Ich hoffe, Du hast in 20 Jahren den Anstand, Dich nur mit Schamesröte im Gesicht an diese Sprüche zu erinnern, die Du in Deiner Jugend so unbedacht geklopft hast.
Udo S. schrieb: > Und wird wo genau eingesetzt? An vielen Stellen. Nimm' z.B. IRGENDEINE übliche Linux-Distri. Du wirst darin ein Mono-Paket finden. Und viele Pakete, die eben dies als Abhängigkeit haben. Das war jetzt wirklich einfach... > In Zeiten von Cloud Computing, Virtualisierung und Container setzt > keiner mehr im professionellen bereich nur auf Windows. Und Oberflächen > sind mehr und mehr Web-Oberflächen. Das wollen all die Daten-Zuhälter, da geht ihnen einer ab. Aber ich will das nicht und die meisten Anwender wollen das ebenfalls nicht (sofern sie sich überhaupt Gedanken darüber machen, was leider nur bei einer Minderheit der Fall ist). Der eigentliche Witz ist aber: Mono addressiert primär ebenfalls genau diesen Bereich, die Funktionalität für den Desktop ist eher nur ungeliebtes Nebenprodukt...
c-hater schrieb: > Udo S. schrieb: > >> Und wird wo genau eingesetzt? > > An vielen Stellen. Nimm' z.B. IRGENDEINE übliche Linux-Distri. Ich installiere auf meinen Rechnern üblicherweise Arch Linux. > Du wirst darin ein Mono-Paket finden. Tatsächlich, hab's gefunden :) > Und viele Pakete, die eben dies als Abhängigkeit haben. Wenn 13 für dich viele sind, ok. 10 Von den 13 Paketen sind Entwicklungstools und Bibliotheks-Wrapper für Mono/.Net, die niemand bräuchte, wenn es Mono/.Net nicht gäbe. Es verbleiben also gerade einmal 3 (drei!) Anwendungsprogramme für Mono: - Pinta (einfaches Malprogramm), - OpenBVE (Spiel) und - OpenRA (Spiel). > Das war jetzt wirklich einfach... Dto. :) Mono hat das gleiche Problem wie Wine: Programme laufen darauf nur dann halbwegs sauber, wenn sie entweder - sehr primitiv sind (d.h. nur wenige gängige .Net/Windows-Features nutzen) oder - sie bewusst portabel für Mono/Wine entwickelt wurden (wie bspw. LTspice für Wine). Die meisten größeren .Net- und Windows-Native-Programme laufen unter Mono bzw. Wine nicht, und MS wird nachvollziehbarweise auch keinen Finger krumm machen, um an dieser Situation irgendetwas zu ändern.
c-hater schrieb: > Das wollen all die Daten-Zuhälter, da geht ihnen einer ab. Aber ich will > das nicht und die meisten Anwender wollen das ebenfalls nicht Im Business-Umfeld geht der Trend zu Microsoft 365, also Office in der Cloud statt lokal im Unternehmen. Mal sehen, ob oder wer sich damit ein faules DSGVO-Ei ins eigene Nest legt, das Thema ist ja noch offen.
:
Bearbeitet durch User
Axel S. schrieb: > Wenn Microsoft > gewollt hätte, dann hätten sie .net ja plattformübergreifend > bereitstellen können. Du kennst aber dotnet core bzw. standard, oder? https://dotnet.microsoft.com/download
Entschuldigung, falls das jetzt Ironie war...
Egon D. schrieb: >> Lies mal richtig, er schrieb; >> "> Da du bereits den Unterschied zwischen gutem Code >> > und performantem Code nicht verstanden hast," >> >> das ist ne bodenlose Unterstellung und Frecheit. > > Nö. > Das ist m.E. die Wahrheit. Du hast das tatsächlich nicht > verstanden. Nein, er kann nicht von "nicht verstanden" sprechen, wenn das nicht der Kontext war. Also ist es sein Versagen und sein Fehler, Punkt. >>>> Ein List Objekt kann zwar verglichen mit eigenen >>>> implementierten verketteten Listen schnell sein, >>>> aber damit schlägst du kein Array das in den Cache >>>> passt. >>> >>> Ahh ja... besonders wohl deshalb, weil das Einfügen >>> und Streichen von Elementen in Arrays so wahnsinnig >>> performant ist... >> >> Tja und du bist leider auch so ein Kandidat der es >> nicht weiß. Oben habe ich es eigentlich schon erwähnt. >> >> Stichwort: Cache > > Schwachsinn. Ich sag ja, du hast keine Ahnung. Hier, der Beweis, wenn du es mir nicht glaubst: Ja, der Typ lehrt an einer Uni Informatik: https://www.youtube.com/watch?v=DyG9S9nAlUM Wer nicht alles angucken will, ab 21:00 kommt die Auflösung. Also nix Schwachsinn, also frickel woanders mit deinem Unwissen. >> Eine Moderne CPU, die ein Array im Cache bearbeitet, > > Welche moderne CPU bearbeitet ein Array von, sagen wir, > 10 Millionen Elementen im Cache? Im First-Level-Cache > gar? > > Richtig: Keine. Dein Array muss natürlich reinpassen, denn ich sagte oben, kenne die Hartware. Wenn es performant sein soll, musst du die Hardware kennen. Gibt die Hardware das nicht her, dann musst du eben Linked List nehmen und langsame Zugriffe auf den Hauptspeicher in Kauf nehmen, passt es aber, dann ist das Array wegen dem Cache zu bevorzugen und das optimiert dir eben kein generic List Object weg. Und zu den Cache Größen, ein Intel Ice Lake hat 8 MB 3rd Level Cache, mein Skylake hat ebenfalls 8 MB, da passt sehr viel rein. > Wenn an Position 107 drei Byte eingefügt werden müssen, > hast Du die Brille auf, denn dann werden die restlichen > 9.999xxx Millionen Elemente umgespeichert. Bla bla bla, guck das Video an und Staune. > >> hat die schneller sortiert, verändert und neue Elemente >> eingefügt, als das bei einer verketteten Liste der Fall >> ist. Letzteres läuft nämlich über den langsamen >> Hauptspeicher. > > Ich wiederhole mich: Schwachsinn. Tja und das ist mal wieder so ein Punkt, wo es um das Thema Wissen wie es unter der Haube aussieht und Hardware kennen geht. Etwas was du zumindest definitiv nicht beherrschst. Das meiste Zeug, was bei der OOP im Heap landet, landet im Hauptspeicher und der ist eben vielfach langsamer als Cachezugriffe. Aber guck dir das Video an und lass dich blöd dastehen.
Nano schrieb: > Egon D. schrieb: > >> Nö. >> Das ist m.E. die Wahrheit. Du hast das tatsächlich >> nicht verstanden. > > Nein, er kann nicht von "nicht verstanden" sprechen, > wenn das nicht der Kontext war. Doch, das kann er -- denn gerade Dein insistieren, es sei ja um etwas ganz anderes gegangen, beweist, dass Du TATSÄCHLICH nicht verstanden hast, worum es Tim ging. > Also ist es sein Versagen und sein Fehler, Punkt. Das ist kein zielführender Ansatz für eine produktive Diskussion. Du hast nicht die alleinige Definitionshoheit, was zum Thema gehört und was nicht. >>> Tja und du bist leider auch so ein Kandidat der >>> es nicht weiß. Oben habe ich es eigentlich schon >>> erwähnt. >>> >>> Stichwort: Cache >> >> Schwachsinn. > > Ich sag ja, du hast keine Ahnung. Ironischerweise stimmt das sogar: Ich habe keine Ahnung, wie man sich so in das Thema "Cache" verbeissen kann, wenn der Ausgangspunkt die Frage war: "Ist performanter Code identisch mit gutem Code?" Meine persönliche Antwort auf diese Frage ist ganz klar: "Nein!" Und zu dem Urteil komme ich nicht deshalb, weil ich von Assembler keine Ahnung hätte -- sondern im Gegenteil weil ich mit Assembler und Pascal angefangen habe (erst auf Z80, dann auf x86) und inzwischen bei der Scriptsprache Tcl gelandet bin. Die Programme, die ich heute schreibe, laufen zwar langsamer, sind aber um POTENZEN nützlicher als das, was ich vor 20 Jahren so fabriziert habe. > Hier, der Beweis, wenn du es mir nicht glaubst: Ich brauche keinen Beweis , wenn schon keine verständliche Behauptung formuliert wurde -- außer natürlich den verächtlichen Beschimpfungen, ich hätte keine Ahnung. >>> Eine Moderne CPU, die ein Array im Cache bearbeitet, >> >> Welche moderne CPU bearbeitet ein Array von, sagen wir, >> 10 Millionen Elementen im Cache? Im First-Level-Cache >> gar? >> >> Richtig: Keine. > > Dein Array muss natürlich reinpassen, Echt jetzt?! Ganz ehrlich: Kommst Du Dir nicht selbst bescheuert vor mit solchen hirnrissigen Vergleichen? Wenn die Datenstruktur so winzig ist, dass sie komplett in den (First-Level-)Cache passt, dann ist völlig wumpe, ob das eine verkettete Liste oder ein Array ist -- es geht so oder so rasend schnell, eben weil es sich nur um eine winzige Datenmenge handelt. > denn ich sagte oben, kenne die Hartware. Wenn es > performant sein soll, musst du die Hardware kennen. Ist ja auch überhaupt kein Problem, mein Linuxprogramm mundgeklöppelt auf ca. 10 Plattformen und hunderte von Prozessorvarianten zu optimieren. Meine Fresse... > Gibt die Hardware das nicht her, dann musst du eben > Linked List nehmen und langsame Zugriffe auf den > Hauptspeicher in Kauf nehmen, passt es aber, dann ist > das Array wegen dem Cache zu bevorzugen Kompletter Unsinn. 1) Eine "Liste" als Datentyp bzw. Klasse muss keineswegs als klassische "verkettete Liste" implementiert sein. In Tcl sind Listen einfach spezielle Strings. 2) Nicht nur Arrays profitieren vom Cache -- auf Listen trifft das (je nach Zugriffsmuster) genauso zu. 3) Ob ich ein Array oder eine Liste verwende, hängt nicht primär von der Hardware ab, sondern davon, was der Algorithmus braucht. Das kann auch nicht anders sein, denn der Entwickler eines Anwendungsprogrammes weiss selten, auf welcher genauen Hardware das Programm laufen wird. Es ist deswegen ganz ausdrücklich eine BESCHEUERTE Idee, Anwendungsprogramme ohne Not auf eine bestimmte Hardware zu optimieren. Viel zielführender ist es, nach besseren Algorithmen zu suchen, denn davon profitieren in der Regel alle (wenn auch nicht immer in gleichem Maße). 4) Bei -- relativ zum verfügbaren Hauptspeicher -- kleinen Datenmengen ist die Geschwindigkeitsdiskussion sowieso irrelevant. Spannend wird es bei Datenmengen, die um ein Vielfaches größer als der Cache sind. Hier werden dann die Zugriffsmuster und die Lokalität der Zugriffe wichtig, und man kann auch mit scheinbar einfachen Arrays sehr viel Spaß erleben, wie ich jüngst erfahren durfte... Da ich aber davon sowieso "nicht die geringste Ahnung" habe, verschone ich Dich mit weiterem "Unsinn" zu dem Thema... > und das optimiert dir eben kein generic List Object weg. Der für Dich offenbar unbegreifliche Punkt ist: Diese Aussage mag gar nicht falsch sein -- sie ist aber in vielen Fällen absolut IRRELEVANT. Ein langsames, KORREKTES Programm ist in fast allen Fällen deutlich nützlicher als ein pfeilschnelles FALSCHES. Diese simple Tatsache begründet den Erfolg der Scriptsprachen. > Und zu den Cache Größen, ein Intel Ice Lake hat 8 MB 3rd > Level Cache, mein Skylake hat ebenfalls 8 MB, da passt > sehr viel rein. Und? 1) Die Bilddateien, mit denen ich herumhantiere, haben als Rohdaten 40MByte und temporär (bis zu) 640MByte. 2) Zugriff auf First-Level-Cache kostet beim Skylake ca. 5 Takte; Third-Level-Cache kostet ca. 40 Takte; RAM kostet (grob gerundet) 250 Takte. 3) RAM wird nicht byteweise gelesen wird, sondern in ganzen Cachelines. Die 250 Straftakte fallen somit nur EINMAL je 64Byte-Block an. Gemittelt sind das je Byte 4 Takte, also genau soviele, wie ein Zugriff auf den First-Level- Cache kostet... Der Trick ist daher, auch die Daten zu verwenden, die ohnehin schon aus dem RAM gelesen wurden. Da sind wir beim Thema "Zugriffsmuster" bzw. "Lokalität". > Das meiste Zeug, was bei der OOP im Heap landet, landet > im Hauptspeicher und der ist eben vielfach langsamer als > Cachezugriffe. ??? Im Prinzip landet ALLES erstmal im Hauptspeicher. In den Cache kommt es erst, wenn es gebraucht wird. Das trifft aber auf Listen genauso wie auf Arrays zu...
Ich verstehe das absurde Gehate nicht. Bei primär dialog-orientierter Software verbringt das OS auf heutiger Hardware sowieso 99,9% in Warteschleifen oder Null-Events. Wenn es nicht gerade um die Simulation von gigantschen Modellen (Meteorologie?) oder 3D-Rendering von Spielfilmen geht, ist Performance so ziemlich das Letzte, was bei der Auswahl einer ersterlernten Programmiersprache relevant wäre, weil sowieso im Überfluss vorhanden. Für mich ist die Erzeugung plattform-neutraler Anwendungen nach dem Coding und der Verzicht auf die Installation irgendwelcher Laufzeitbibliotheken und -Umgebungen zusätzlich zum "normalen" OS dagegen deutlich wichtiger, weil praxisrelevant. Und da wird es schon wieder relativ "dünn" ...
Hallo Egon D., Egon D. schrieb: > Ironischerweise stimmt das sogar: Ich habe keine > Ahnung, wie man sich so in das Thema "Cache" > verbeissen kann, wenn der Ausgangspunkt die Frage > war: "Ist performanter Code identisch mit gutem > Code?" ich teile Deinen Standpunkt. Ich behaupte: Die Unkenntnis der O()-Notation führt dazu, daß Leute (auch mit diesem Video) in die Irre geführt werden. Wenn da jemand im Internet etwas über Hardware-Tuningtips verbreitet, dann geht es immer nur um einen Faktor c. Diese Art von Beschleunigung liegt aber immer noch in derselben Klasse. Forist "Schlaumeier" hat mal beschrieben, wie toll er mit seinem O(n^2)-Algorithmus sortieren kann. Im gleichen Atemzug musste er aber eingestehen, dass er für größere Probleme eine Datenbank benutzt. Deren Indexierungsroutinen laufen allerdings nicht in O(n^2), sondern in O(n*log(n)). Und gerade deswegen verzichtet der "Schlaumeier" bei großen Problem auf den eigenen, schlechten Code, der in O(n^2) liegt. :) Welchen Aussagehalt hat der Vergleich von Arrays - bei denen man auf ein Element in O(1)* zugreifen - kann mit Listen (ob nun einfach, zweifach oder dreifach verkettet) wo man Kosten von O(n) hat? * vorausgesetzt, dass Array liegt kontinuierlich an einem Stück im Speicher
:
Bearbeitet durch User
Rolf R. schrieb: > Ein Abiturient, der gerade sein Abi gemacht hat, will im Oktober mit dem > Studium Wirtschaftsinformatik beginnen. Wieso erkundigt sich "der Abiturient" nicht bei der in Frage kommenden Universität / FH? Ist er zu unselbständig dazu? Dann wäre ggf. eine Lehre als Fachinformatiker zielführender. Wenn das kein Trolling ist wirst Du eher SAP (ABAP), Salesforce oder Oracle EBS etc. begegnen. Wichtiger sind die Grundlagen des Software Engineering. Vorbereitend würde ich Volkswirtschaftslehre und Finanzmathematik empfehlen - damit wird im Grundstudium "gesiebt".
:
Bearbeitet durch User
Christian H. schrieb: > Wer als Wirtschaftsinformatiker überhaupt programmieren kann, gehört > schon zur Oberschicht. Habe mal ein wenig "zurück gelesen". Du bist der Beste :-)
Beitrag #6709853 wurde von einem Moderator gelöscht.
Egon D. schrieb: > Ironischerweise stimmt das sogar: Ich habe keine > Ahnung, wie man sich so in das Thema "Cache" > verbeissen kann, wenn der Ausgangspunkt die Frage > war: "Ist performanter Code identisch mit gutem > Code?" Das war aber nicht der Ausgangspunkt der Frage, sondern was ist performanter. Arrays oder verlinkte Listen. Da du auch nicht einmal bereit bist, dir das Video anzugucken, werde ich die Diskussion mit dir hier auch beenden. Nützt ja nichts, schließlich trifft das auf Taube Ohren und ich hab besseres zu tun. Ich habe dem TS geholfen in dem ich ihn ihm einen guten Rat gab und mehr hatte ich auch nicht vor. Ich werde daher an dir auch keine Zeit mehr verschwenden, da es so etwas unbelehrbarem wie dir verlorene Zeit ist. EOD
Frank E. schrieb: > Ich verstehe das absurde Gehate nicht. > ... > > Wenn es nicht gerade um die Simulation von gigantschen Modellen > (Meteorologie?) oder 3D-Rendering von Spielfilmen geht, ist Performance > so ziemlich das Letzte, was bei der Auswahl einer ersterlernten > Programmiersprache relevant wäre, weil sowieso im Überfluss vorhanden. Ich hoffe du verwendet keinen Ad- und Javasript Blocker. Deiner Aussage nach ist das ja nicht schlimm, was da Leistung verbrät und die Wirtschaftsinformatiker so fabrizieren, man hat ja genug. So und damit ist eigentlich alles gesagt.
Peter M. schrieb: > Welchen Aussagehalt hat der Vergleich von Arrays - bei denen man auf ein > Element in O(1)* zugreifen - kann mit Listen (ob nun einfach, zweifach > oder dreifach verkettet) wo man Kosten von O(n) hat? Seufz Es geht zwar immer weiter von der Ursprungsfrage weg, aber was solls. Versuche doch einfach mal eine reale Problemstellung zu lösen, kein Luftschoss, sonst endest du irgendwann wie Nano. Zum Einen hast du beim Array das Problem dass du bei einfüge oder entfern Operationen alle weiteren Elemente im Array bewegen musst, bei einer Liste nur ein paar Pointer umbiegen. Zum Anderen willst du gewöhnlich nicht auf das Element mit Index x zugreifen sondern auf ein Element mit einer bestimmten Eigenschaft welches du in beiden Fällen suchen musst und das läuft in der Regel mit O(n).
Nano schrieb: > Das war aber nicht der Ausgangspunkt der Frage, sondern was ist > performanter. Arrays oder verlinkte Listen. Hast Du eine Leseschwäche? Schau Dir mal den Titel des Threads an.
Hallo Tim T.,
> Versuche doch einfach mal eine reale Problemstellung zu lösen, kein
bitte lese einfach noch einmal meinen Beitrag. Ich habe mich lediglich
zu dem Videoinhalt geäußert.
Geh' einfach mal davon aus, dass ich effiziente Datenstrukturen kenne.
Dazu gehören auch die Kosten der Manipulation derselben. :)
:
Bearbeitet durch User
Peter M. schrieb: > Hallo Tim T., > >> Versuche doch einfach mal eine reale Problemstellung zu lösen, kein > > bitte lese einfach noch einmal meinen Beitrag. Ich habe mich lediglich > zu dem Videoinhalt geäußert. > Geh' einfach mal davon aus, dass ich effiziente Datenstrukturen kenne. > Dazu gehören auch die Kosten der Manipulation derselben. :) Ah ok, das Video hatte ich mir erspart und hielt darum deinen Beitrag für einen weiteren Versuch die über alles erhabene Überlegenheit von Arrays zu propagieren. Wobei ich sagen muss das ich ohne den expliziten Hinweis auf das Video auch bei mehrmaligem Lesen zu dieser Fehlinterpretation komme^^
Hallo Tim, Tim T. schrieb: > Ah ok, das Video hatte ich mir erspart und hielt darum deinen Beitrag Das Video hat auch keinen Erkenntniswert. > für einen weiteren Versuch die über alles erhabene Überlegenheit von > Arrays zu propagieren. Wobei ich sagen muss das ich ohne den expliziten > Hinweis auf das Video auch bei mehrmaligem Lesen zu dieser > Fehlinterpretation komme^^ Nein. Wer die O-Notation kennt, lässt die Hardware Hardware sein und kümmert sich um den Algorithmus, weil die Hardwarebeschleunigung immer nur als konstanter Faktor in die Laufzeit eingeht. Hier ist ein schönes Beispiel, wie eine rekursive Auflistung von Ordnerinhalten aufgrund der Verwendung von dynamischen Arrays die Laufzeit auf O(n^2) hochschraubt: http://www.vb-fun.de/cgi-bin/loadframe.pl?ID=vb/tipps/tip0327.shtml
c-hater schrieb: >> In Zeiten von Cloud Computing, Virtualisierung und Container setzt >> keiner mehr im professionellen bereich nur auf Windows. Und Oberflächen >> sind mehr und mehr Web-Oberflächen. > > Das wollen all die Daten-Zuhälter, da geht ihnen einer ab. Aber ich will > das nicht und die meisten Anwender wollen das ebenfalls nicht (sofern > sie sich überhaupt Gedanken darüber machen, was leider nur bei einer > Minderheit der Fall ist). Du sagst es dir ja selbst 90% der Anwender ist das Wuppe. Wenn dann sind es die Firmen, denen es NICHT Wuppe ist, spätestens wenn ihr Namen in den Nachrichten unten der Überschrift Datenleck zu finden ist (Von Fratzenbuch abgesehen, die scheinen ja ordentlich mit Teflonspray getränkt zu sein.) Es geht nicht um Daten-Zuhälter. Im professionellen Umfeld ist der Zugriff von Cloudanbieter auf Daten der Kundenunternehmen ziemlich genau geregelt. Es geht darum Dinge wie Service, Hardware, Sicherheit, Backup, skalierbare Kapazität, usw. auszulagern. Du hast mal wieder nicht gelsen. Ich schrieb "kann man gut finden oder nicht". Das ist nicht was ich jetzt geil finde, das ist was konkret passiert! Zum Thema mono hat Yalu ja schon was geschrieben. ist auch egal, ich habe keine Lust mit einem Fanboy zu streiten. Es gibt auch Leute für die ist MS-Access der Gipfel der Kunst der Speicherung und Verarbeitung von Daten. Jedem das Seine
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.