PMedia
Ich für meinen Teil find es beschissen!
Denn eine schnellere Internetverbindung hat zur Folge, dass noch mehr pseudoh4xx0r das Programmieren lernen wollen, ihre Erfolge präsentieren können, die natürlich mit Drag'n'Drop-Entwicklungsmodulen zusammengebaut sind, und als Nonplusultra's ausgewiesen werden.
Dass der megacoole Taschenrechner 2 gig groß is stört dann keinen mehr.
Dass derartige Progs neue Rechner zur Folge haben... och iwo, eh nötig.
*grummel*
Ach ja ich vergaß den 4gig großen Patch, der dafür sorgt, dass die Applikation nich mehr per BlueTooth8000 machen kann was man will...
ich will zurück zur Akustikkopplerära, wo das ganze noch Stil und Sinn hatte. Das ist doch keine Art, wie heutzutage umgesprungen wird. Schon allein wenn ich hör, dass mein Infolehrer die Mehrwertsteuer in eine Variable packt, kräuseln sich meine Nackenhaare im Quadrat. Es wird gnadenlos heutzutage Rechenleistung und Speicher verschenkt für nix und wieder nix.
Dass da noch keiner demonstrieren gegangen ist... alle tun wir für bezahlen, und dann sowas. Gut für Linux zahlen wir nix, is ja auch gut (bzw nicht), aber trotzdem, wir verschenken/verheizen mehr als genug Leistung. *doof-find*
Bei Linux gehts ja noch, aber wenn ich mir dann Progs anguck, die in Interpretersprachen implementiert sind (egal ob Python oder Java)... oder am besten web2.0-Apps... json geht ja noch, aber AJAX und XML sind einfach nur Untaten, die bestraft gehörn.
Lustig ist auch, wie Ihr-Wisst-schon-wer es selbst bei nem XML-Format schafft, dass mans nich öffnen kann :/
Wie Office von ehemals 30mb ('95) auf 2 gig ('07) anwachsen kann, ohne groß an nutzbaren Funktionen dazugewonnen zu haben ist mir auch ein Rätsel... aber egal, MS ist sowieso unfähig.
docloy
Was ist daran schlimm, wenn dein Lehrer die MwSt in eine Variable packt? Bei einer MwSt-Erhöhung (was wegen Finanzkrise vermutlich noch nächstes Jahr nach der Wahl passiert) muss er dann nur die Variable anpassen und nicht überall im Code die MwSt anpassen.
BioHazard
@ PMedia
Das was du beschissen findest, nenne ich Entwicklung. Schau dir die technischen Möglichkeiten eines typischen PCs der 90er an und vergleiche ihn mit einem typischen PC diesen Jahres.
Ein Beispiel: Zu Beginn der DVD-Ära war der typische PC nicht in der Lage, ohne eine spezielle Decoder-Karte den Film akzeptabel darzustellen. Hintergrundprozesse liefen trotzdem mit inakzeptabler Geschwindigkeit. Heute kannst du mit einem PC theoretisch mehrere DVDs gleichzeitig schauen und dennoch Speicher- und / oder Rechenintensive Prozesse laufen lassen. Der Bluray-disc wird es in Zukunft ähnlich ergehen: Heute braucht es einen Dualcore, morgen schaust du mit 16 Kernen 8 gleichzeitig. Und kannst trotzdem nebenbei arbeiten / arbeiten lassen.
Das ist keine negative Entwicklung, sondern hat in der Vergangenheit zur Verbreitung von PCs beigetragen. Wenn kein Bedarf an Rechenleistung, Speicher, Schnittstellen o.Ä. besteht, lohnt es sich auch nicht in diese Richtung zu entwickeln. Stell dir die multimedialen Inhalte vor, die du mit einem Akustikkoppler (max 2400 Baud) übertragen kannst. Selbst der C64 war damit unterfordert. Das reicht nicht für Streaming, Interaktive Webseiten, HTML-Emails, usw.
Das LHC-Computing-Grid (oder so ähnlich) profitiert z.B. (wie viele andere verteilte Rechensysteme) von der steigenden Bandbreite und spart Jahre an Zeit, die bei einer ausschließlichen, zentralen Berechnung per Cluster o.Ä. zusätzlich angefallen wären. In meinen Augen ist das sehr sinnvoll.
PMedia
Das meine ich damit nichtmal, ich meine primär die Anwendungen, die der OttoNormal-Verbraucher nutzt, der hat für DVD's und BD's noch nen eignen Player.
Da ich zudem gezwungen bin, auf älterer Hardware zu arbeiten, merke ich es so richtig schön, was lahmt und was nicht. Jeder schreibt Software einfach drauf los... hauptsache 's funzt (mehr oder weniger und wenn nicht patchen wir's halt).
Was die Mwst betrifft, würde ich ein #define machen, und das Ding einfach unter die GPL stellen... aber das kennen Interpretersprachen ja zum Teil nichtmal (die großen ausgenommen).
Alles was ich will, ist eine (parallele) Schiene für LowEnd-PCs. Und zwar eine nutzbare.
Dillo ist ganz nett zu nutzen, aber kaum kompatibel zu irgendwas, da CSS nicht wirklich unterstützt wird.
nEdit ist toll - solange wie man keine Zwischenablage nutzt.
XFE ist auch toll - solang man keine Mehrfachauswahl nutzt.
Opera geht mir inzw aufn Keks, da ich zB nur auf Lesezeichen klicken brauch und der Browser schmiert ab - ich weiß nicht wieso
FireFox läuft nur mit gescheitem Grafiktreiber "akzeptabel" - und wenn man ne Seite aufruft, dauerts scho mal 2 seks eh der mal wieder reagiert.
Oder hat irgendeiner von euch schon mal mit Typo3 gearbeitet? Sicherlich. Versucht das mal heute auf ner 1 GHz C7-Maschiene aufzusetzen. Spaß macht das nicht. Warum gibts keine gescheiten OpenSource-CGI-CMS-Systeme mehr? Zumindest keine bekannten?
Warum wird man immer wieder diskriminierend belächelt, wenn man *seine* Hardware listet?
DAS ist was mich primär aufregt. Auch wenn ADSL2+ 25.000 hier eine kleine Hilfe bei darstellt *grins*
Aber das ist doch keine Evolution. Das ist eine definitive Rückentwicklung. Wenn ich mir mal vorstell, wie viel man noch in der 100 MHz-Pentium-1-Ära aus dem PC rausholen konnte... *viel* mehr ist das auch bei einer um den faktor 30 größeren Taktfrequenz und mehreren Recheneinheiten nicht geworden. Findet das keiner von euch merkwürdig? Das verwundert mich. Hier und da sind einige Hardware-Entlastungen dazugekommen... MPEG2-Decoder, Shader & CUDA... schön, nützt mir aber nicht wirklich. Mein PC hat mit 1 GHz (relativ) viel Leistung - man kann sie aber nicht nutzen, da sie sinnlos verbraten wird. Es gibt keine LowEnd-Schiene die auch wirklich nutzbar ist. Und das, obwohl der Absatz dieser Maschienen (ich erinner da mal an Atom's, ThinClients, etc) kontinuierlich steigt.
Markt verfehlt...
DerPi
PMedia schrieb
Alles was ich will, ist eine (parallele) Schiene für LowEnd-PCs. Und zwar eine nutzbare.
Dillo ist ganz nett zu nutzen, aber kaum kompatibel zu irgendwas, da CSS nicht wirklich unterstützt wird.
nEdit ist toll - solange wie man keine Zwischenablage nutzt.
XFE ist auch toll - solang man keine Mehrfachauswahl nutzt.
Opera geht mir inzw aufn Keks, da ich zB nur auf Lesezeichen klicken brauch und der Browser schmiert ab - ich weiß nicht wieso
FireFox läuft nur mit gescheitem Grafiktreiber "akzeptabel" - und wenn man ne Seite aufruft, dauerts scho mal 2 seks eh der mal wieder reagiert.
[...]
Warum wird man immer wieder diskriminierend belächelt, wenn man *seine* Hardware listet?
Aus Zeitgründen will ich nicht auf alles eingehen, daher nur soviel: Deine Probleme mit LowEnd-Maschinen kann ich nicht wirklich nachvollziehen. Ich arbeite privat (aus freiem Willen) auch mit langsameren Maschinen. Mein Server wird von 128MB RAM und einem Celeron 733ULV angetrieben und der Rechner, mit dem ich hauptsächlich arbeite lüft mit 1GB RAM und einem Pentium M 1,2 GHz. Das reicht mir völlig aus, um auf der Kiste zu Entwickeln, ein bißchen zu zocken und eben den üblichen Web- und Office-Kram zu erledigen.
Das kommt meiner Meinung nach schon sehr auf die richtige Software-Auswahl an. Das ist dann wohl aber in diesem Thread eher OT.
JoyFM
@DerPi
ich glaube PMedia will eher sagen, dass schlechter Code heute normal ist und die Projekte auf eine nichtmehr wartbare Ebene gewachsen sind.
Aber zum Thema - es gibt auch noch ein paar Leute, die sich für guten Code einsetzen :
http://www.suckless.org
PMedia
JoyFM schrieb
@DerPi
ich glaube PMedia will eher sagen, dass schlechter Code heute normal ist und die Projekte auf eine nichtmehr wartbare Ebene gewachsen sind.
Aber zum Thema - es gibt auch noch ein paar Leute, die sich für guten Code einsetzen :
http://www.suckless.org
Genau das wollt ich sagen :]
Und dass Interpretercode in Anwendungen nix zu suchen hat :]
Danke für die Kurzzusammenfassung, hab ich nich hinbekommen ^^
BioHazard
Dann habe ich dich wohl falsch verstanden, habe aus deinem Post eine generelle Abneigung gegenüber steigender Leistung gelesen. Ob "schlechter" Code normal ist oder nicht, kann ich nicht bewerten, dafür habe ich einfach noch nicht genug Souce-Code von "gängiger" Software (meist closed-source) gesehen.
Ich möchte allerdings noch einen Aspekt einwerfen: "Guter" Code (ich setze das mal mit Performanz bzw. Speichereffizienz gleich, darauf hast du dich ja bezogen) kann quasi unwartbar sein.
Der Linux-Kernel ist ein gutes Beispiel. C-Code ist im Vergleich zu anderen (meist objektorientierten Sprachen) relativ unübersichtlich. Im Linux-Kernel wird pseudo-objektorientiert in C programmiert. Das ist ein erheblicher Aufwand und der Code ist nicht jedem verständlich. Zudem sind komplizierte und schnelle Algorithmen, Datenstrukturen, Spezial- und Ausnahmebehandlungen zwar in mindestens einem Kriterium "gut" aber eben in der Wartbarkeit nicht.
Die Performanz des Linux-Kernels schwankt in Folge von Umstrukturierungen zugunsten der Wartbarkeit dann auch in relevantem Ausmaß. In den letzten Versionen (bis 2.6.26 / 2.6.27) sank dann auch die Performanz in einigen Workloads. Allerdings konnte der Code in manchen Teilen stark vereinfacht werden, was die künftige Entwicklungsarbeit erleichtert. Dazu gibt es einige Artikel im Netz und Beiträge auf der Kernel-Mailing List.
Worauf ich hinaus will: "Guter" Code kann sich durch eine Vielzahl von Kriterien auszeichnen. Manche davon schließen sich gegenseitig aus. Interpretersprachen haben hier gewisse Vorteile, die sie eben auszeichnen (Plattformunabhängigkeit und (auch manchmal sogar eben deshalb) Wartbarkeit).
Deinen Unmut kann ich durchaus nachvollziehen, allerdings wird es für dich keinen anderen Ausweg geben, als die Leistungsdaten deiner Maschine nach oben zu korrigieren. Jedenfalls nicht, solange sich hübsche, große und leistungshungrige Software am Markt durchsetzt 😉
PMedia
Falsch, meine Maschienen bleiben wie sie sind. Wär ja schlimm wenn ich mir von unfähigen Programmieren nen neuen PC aufschwatzen lassen tu.
Und was den "unwartbaren" Code betrifft, so ist auch dies relativ. Ihn nicht zu verstehen ist für mich kein Argument, in einer langsameren Sprache zu programmieren, im Gegenteil, es wäre mir sogar ein Ansporn ihn verstehen zu wollen. Zumal es die allgemeine Bildung in diesem Sektor stark nach oben korrigiert.
Und grade hier im ArchLinux-Forum dachte ich, diesbezüglich Gleichgesinnte zu finden. Richtet sich doch Arch durch den bewussten Verzicht auf (grafische) Konfigurationsutils auf den informierten Anwender aus. Auch wenn es extras wie optionale grafische Packet Manager gibt - um PacMan zB kommt man nicht herum. Es soll nicht "einfach" sein, es soll bestmöglich funktionieren. So wie der Grundgedanke bei den UNIX und GNU/Linux-Programmen war - sie können nur eine Sache, aber diese so gut wie möglich. So gut wie möglich heißt im Idealfall auch so schnell wie möglich. Und dann darf man sich diese Abgeneigtheit von C ganz schnell wieder abgewöhnen.
BioHazard
PMedia schrieb
Und was den "unwartbaren" Code betrifft, so ist auch dies relativ. Ihn nicht zu verstehen ist für mich kein Argument, in einer langsameren Sprache zu programmieren, im Gegenteil, es wäre mir sogar ein Ansporn ihn verstehen zu wollen. Zumal es die allgemeine Bildung in diesem Sektor stark nach oben korrigiert.
Welche Sprache ist langsam, welche Sprache ist schnell ? Ist C schneller als C++ ? Ist D noch schneller ? Die Effizienz von Software hängt zuallererst von der Effizienz des Compilers ab. Aus dieser Erkenntnis ist mal die RISC-Architektur entstanden. Solltest du etwas von x86-Assembler verstehen, schau doch mal in die Ausgabe des gcc hinein. Sieht für dich gut aus? Für mich auch. Ist aber für echte Könner ein Graus. Es dauert aber 10mal solange ein effizientes Assembler-Programm zu schreiben. Hinzu kommt die Menge an Erfahrung die man braucht. Wenn du etwas entwickelst, was auch auf dem Mac deines Bekannten und dem Solaris in der Firma laufen soll, nimmst du bestimmt ein Werkzeug, welches dir genau das ermöglicht. Du möchtest sicher keinen Mac kaufen, um deine Software dafür anzupassen. Eine Interpreter-Sprache ist doch hier genau das Richtige, oder nicht? Zumal es mit Java ja auch einen guten (und weit verbreiteten) Kompromiss gibt.
PMedia schrieb
Und grade hier im ArchLinux-Forum dachte ich, diesbezüglich Gleichgesinnte zu finden.
Das klingt ein bisschen so, als ob du dich angegriffen fühlen würdest. Das war aber nicht meine Absicht. Ich halte das für einen interessanten Meinungsaustausch. Ich bin aber nur eine einzelne Person, keine ganze Community 😉 Ich spreche nur für mich und kann deine Haltung darüber hinaus wie ich bereits gesagt habe gut nachvollziehen. Ich bin nur anderer Meinung, was nicht heißt, dass diese das Non-Plus-Ultra wäre.
PMedia
Iwo, von dir fühl ich mich nicht angegriffen.
Definitv ineffizente Sprachen sind derzeit zB fast sämtliche Interpretersprachen, Java sowieso.
Am effizientesten empfinde ich C (wenns Portabel sein sollte) und Assembler, und ja ich verstehe ein wenig von Assembler, sollte man wenn man vorhat irgendwann mal ein Hobby-OS zu schreiben, und das bisschen das ich weiß is sogar x86-Assembler :lol:
C ist nach wie vor die beste Wahl wenns um irgendwas geht. Und wer jetzt kommt von wegen Anfällig für Buffer-Overflows, so entgegne ich: der Fehler liegt nicht an der Sprache, der Fehler liegt beim Programmierer. Denn wenn man Assembler kennt, weiß man in etwa wie die Assembler-Equivalente der Char-Arrays aufgebaut sind, und vermeidet so etwas fast instinktiv.
Und wieso sollte ich, wenn ich für den Mac code, eine Interpretersprache verwenden? GCC gibts inzw von Haus aus seit MacOS X, und mir fällt als Einzelne Privatperson sicher nix bei ab, mein Prog unter die GPL zu stellen, und Plattformübergreifende Bibliotheken bzw Plattformübergreifende APIs zu nutzen. FMOD und OpenGL gehen hier mit gutem Beispiel vorran, finde ich. Gimp Toolkit ist so lala, QT sowieso, naja... aber is ja auch egal. C ist nach wie vor nonplusultra und darf nicht verdrängt werden, schon allein aus nostalgischen Gründen :lol: Dass keiner mehr in Assembler programmieren will, ist klar, da will ich auch keine großen Programme mit schreiben.
Aber solange sie klein und fein sind, und in C funktionieren, so steht einem Inline-Assembler-Einsatz nichts mehr im Weg. Ausser vielleicht die dusselige GAS-Syntax die ich noch nicht ganz durchschaut hab.... Inline-Assembly war in FreeBasic halt doch einfacher mit NASM-Syntax :/
Und ja, mit FreeBasic gehört auch ein Basic in die Riege der effizienten Sprachen (Wenn man von der RTLib absieht, die is Kraut und Rüben), FreeBasic's Compiler erzeugt zT "schnelleren" Objektcode als GCC, und es wurden sogar schon Kernel in FB geschrieben. Den Geschwindigkeitsunterschied zwischen FBC und GCC merkt man nur in wenigen Fällen. Allerdings taugt FreeBasic nur für Prototypen, das endgültige Programm finde ich, sollte dennoch in C implementiert werden. Warum? RTlib von FB ist 1. doof, und 2. gibts FreeBasic nur für FreeDOS, Windows und Linux, nicht jedoch zB MacOS. Deshalb: C! :lol:
Zumal ich die Syntax von C schick finde.
Aber naja, das is halt nur meine bescheidene Meinung, ich will jetzt niemanden dazu zwingen, in C zu programmieren. Ich möcht nur zum umdenken anregen. Dass es niemanden reizt, die letzten Reserven aus seinen PC herauszuholen verwundert mich.
Was mich nicht verwundert, ist dass Interpretersprachen auf heutigen PCs schon so schnell laufen wie native Programme vor 5 Jahren. Ist ja toll - nur 5 Jahre hinken wir hinterher... *kopf-schüttel*
Aber as said, auch ich will niemanden damit angreifen.
Lasst uns mal langsam zum Thema wieder zurückkommen.