Python Arghhh!! - Gemecker

lockdoc

lockdoc

Well-Known Member
Warum muessen denn so viele Programme mit Python geschrieben werden!??! Ich find das fuer GUI Anwendungen auesserst schlecht. Irgendwie taugen die Dinger nichts. Wenn sie nicht mehr responden, dann legen sie gleich das ganze System auf Eis und man wartet mal ne Minute bis der Desktop wieder bedienbar ist. Nen C-Programm waer sauber angestuerzt:D
Zudem werden die ganz schnell komplett irresponsive sobald man mal im normalen Arbeitstempo die Applikationen mit Mausklicks zuklackert.

Noch son uebel fuer den Desktop sind grosse Projekte geschrieben in Mono :ugly:
Wie banshee. Voll schade eigentlich. Finde fuer mich, dass dies einer der besten open source media player/music manager ist, aber instabil wie sau. Also er stuerzt nicht ab, sondern ist reagiert einfach irgendwann nicht mehr und das interface ist blank, wenn man es denn ueberhaupt noch in den Vorderrund kriegt

Warum wird sowas nicht mit C oder C++ gebaut????;'(;'(;'(

Ich wuerd ja fuer die GUI python, java, mono und konsorten bei mir komplett verbannen, leider gibts keine Alternativen bis jetzt
 
Ist das Verhalten bei Python gleich ob du TK oder QT nutzt? TK lässt sich nämlich recht gut abschießen, nach meiner Erfahrung.
Bei Java-Oberflächen, sofern kein nativen Elemente(SWT bspw.) drinstecken, ebenso.
 
Also die Probleme bei Python habe ich mit QT :-(
Dann steht erstmal der komplette Desktop still. Die Maus laesst sich aber noch bewegen.
Wenn ich dann wieder eine Reaktion vom Desktop habe und das Programm hackt immer noch (was meisst der Fall ist), dann hilft nur ein "killall -9 python"
 
lockdoc schrieb:
Warum wird sowas nicht mit C oder C++ gebaut????;'(;'(;'(
Zum Vergrößern anklicken....

Weil das Programmieren von Nutzer-Anwendungen in diesen Sprachen einfach nur mal die totale Grütze ist. ;)

Und wenn die Entwickler schon mit Python oder Mono keine stabilen Anwendungen hinbekommen, dann will ich gar nicht erst wissen was die mit C/C++ anstellen... Rate mal wo die ganzen Buffer-Overflows herkommen xD
 
Ja aber das ganze immer weiter zu "verlayern" ist nun auch nicht der Bringer, weil sich dadurch ja auch jede Menge Fehler mit einschleichen auf die man dann die weiteren Layer aufbaut.
 
lockdoc schrieb:
Ja aber das ganze immer weiter zu "verlayern" ist nun auch nicht der Bringer, weil sich dadurch ja auch jede Menge Fehler mit einschleichen auf die man dann die weiteren Layer aufbaut.
Zum Vergrößern anklicken....

Aber wenn du danach gehst, müsste jede Anwendung ihren eigenen Window-Manager mitbringen ;)

C/C++ können im Grunde ja mal effektiv gar nichts. Die haben keinen Speicherschutz (darum gibt's so viele Buffer-Overflow-Lücken) und keinen Garbage-Collector/Speichermanager (führt zu Speicherfragmentierung). Man schlägt sich noch mit solche Low-Level Sachen wie Pointern und Referenzen rum... Das braucht und will man bei einer grafischen Anwendung gar nicht haben.

Systeme wie Python, Java oder Mono bieten hier halt einfach viel mehr für die Entwicklung von Anwendungen. Und wenn jemand damit schlechte Anwendungen baut, dann liegt das sicher nicht am System, sondern am Entwickler. ;)
 
Wenn wir keine Layers und große Performance wollen Assembly schreiben. ;)

Es gibt aber auch Alternativen. Die funktionalen Sprachen (allen voran Haskell), wenn man sich damit anfreunden kann und so etwas, wie Ada oder Go. Letztere ist u.A. von Ken Thompson und Robert Pike entworfen worden und hätte Potential. Ja, ich weiß Google, aber BSD-lizenziert und wohl unabhängig genug.
 
Naja das mag ja alles sein, aber performance maessig sind beispielsweise mono und java echte Bremser.

Wenn ich jetzt auf meinem System Rhythmbox (was in C geschrieben ist) starte, dann macht es "schwupps" und die Anwendung ist da und laeuft sauber durch.
Starte ich jetzt Banshee (mono), dann laedt hier erstmal der ganze Monokram durch und irgendwann bequemt sich dann auch mal die Anwendung selbst optisch in Erscheinung.

Beim starten von Java Anwendungen geh ich dann gleich mal Kaffee aufsetzen, weil das noch laenger dauert.

So leidet im Prinzip der User durch die Bequemlichkeit des Programmierers, der sich denkt "jaja wir ham ja alle Ramdisks und nen Quadcore, da abstrahieren wir mal was die Layers hergeben". Irgendwann kann man bestimmt seine Programme via drag und drop zusammenstellen... vieleicht baut ja einer nen java framework dafuer

An Rhythmbox sieht man beispielsweise, dass es schnelle saubere Loesungen geben kann (Leider gefaellt mir Banshee bis jetzt noch besser :-( , hoffe aber mal, dass die Rhythmbox entwickler fleissig weiter entwickeln)

Wenn hier immer weiter abstrahiert wird und immer hoehere High-Level Sprachen benutzt werden, dann wird der User automatisch auf laengere Wartezeiten sensibilisiert. Und die jenigen die mehr mit dem PC machen wollen als lustige Kaestchen mit der Maus auf dem Desktop zu ziehen muessen dann auf moderne Hardware upgraden

Wo sind die "John Carmack" Zeiten hin? Er hat wenigstens noch um jedes Bit im Speicher gekaempft und resultierend daraus wa, das sowas wie Quake3 1999 auf ner recht Schwachbruestigen Maschine (64MB RAM und ca. 350Mhz) lief. Ich weiss ja nicht ob das Banshee schaft xD
 
lockdoc schrieb:
Starte ich jetzt Banshee (mono), dann laedt hier erstmal der ganze Monokram durch und irgendwann bequemt sich dann auch mal die Anwendung selbst optisch in Erscheinung.

Beim starten von Java Anwendungen geh ich dann gleich mal Kaffee aufsetzen, weil das noch laenger dauert.
Zum Vergrößern anklicken....

Ja, weil bei dir anscheinend noch keine Mono bzw. Java VM lief. Würde bereits eine laufen, dann gäbe es die Probleme nicht ;-)

Und die Startzeit einer Anwendung.... nunja... wie oft startet man die Anwendung? Ein mal am Tag? Unerheblich...

Dafür kannst du bei einer Mono/Java-Anwendung sicher sein, dass dir eine manipulierte Playlist nicht gleich einen Trojaner unterjubelt. ;-) Such bei Google mal einfach nach "buffer overflow playlist" und guck mal in was die entsprechenden Anwendungen geschrieben sind.
 
Zuletzt bearbeitet:
lockdoc schrieb:
Wenn ich jetzt auf meinem System Rhythmbox (was in C geschrieben ist) starte, dann macht es "schwupps" und die Anwendung ist da und laeuft sauber durch.
Starte ich jetzt Banshee (mono), dann laedt hier erstmal der ganze Monokram durch und irgendwann bequemt sich dann auch mal die Anwendung selbst optisch in Erscheinung.
Zum Vergrößern anklicken....

Wenn es Dir um Resourcen schonendes Musik abspielen geht, dann schau dir doch mal audio/cmus an, läuft im Terminal, ganz ohne Python und Mono.
Irgendwie musste ich beim Mecker über das lahme Banshee automatisch an Ubuntu denken, die haben im letzten Release ja Banshee in Ubuntu als default reingesetzt, das viel mir da auch gleich unangenehm auf, wie lahm das war. Es gibt aber auch cmus Pakete für die Buntus. ;)
 
> sind beispielsweise mono und java echte Bremser.
Das stimmt so nicht. Es hängt massiv von den Fähigkeiten des Entwicklers ab.
Jemand der Java nicht verstanden hat, schreibt ebenso ineffizienten Code wie jemand, der C++ nicht verstanden hat.

Beste Grüße

Der Indy
 
lockdoc schrieb:
Warum muessen denn so viele Programme mit Python geschrieben werden!??! Ich find das fuer GUI Anwendungen auesserst schlecht. Irgendwie taugen die Dinger nichts. Wenn sie nicht mehr responden, dann legen sie gleich das ganze System auf Eis und man wartet mal ne Minute bis der Desktop wieder bedienbar ist. Nen C-Programm waer sauber angestuerzt:D
Zudem werden die ganz schnell komplett irresponsive sobald man mal im normalen Arbeitstempo die Applikationen mit Mausklicks zuklackert.

Noch son uebel fuer den Desktop sind grosse Projekte geschrieben in Mono :ugly:
Wie banshee. Voll schade eigentlich. Finde fuer mich, dass dies einer der besten open source media player/music manager ist, aber instabil wie sau. Also er stuerzt nicht ab, sondern ist reagiert einfach irgendwann nicht mehr und das interface ist blank, wenn man es denn ueberhaupt noch in den Vorderrund kriegt

Warum wird sowas nicht mit C oder C++ gebaut????;'(;'(;'(

Ich wuerd ja fuer die GUI python, java, mono und konsorten bei mir komplett verbannen, leider gibts keine Alternativen bis jetzt
Zum Vergrößern anklicken....

Servus lockdoc,

tja warum, weil Du ratzfatz in Python was zusammenbauen kannst, aber Vorsicht Dein gestarteter Thread hat Flame Potential....

# http://www.youtube.com/TheCodersChannel#p/c/0D01B2FCF28634FE/0/dx93U10Kkro

Na ja vielleicht wird Deine Laune damit besser

# http://magazin.c-plusplus.de/artikel/(Humor) Die Entstehungsgeschichte von C

CU

Ergänzung

Das mit Mono/C# hat sich vielleicht bald erledigt:

# http://de.wikipedia.org/wiki/Mono-Projekt
# http://www.golem.de/1105/83536.html

mal schauen was da so die Zukunft bringt geht ja eher in Richtung Java Script + Html5 + Css + Assembler ( Jägermonkey ( gjs ) ) laut jüngster Gnome Developer Konferenz und bei Windows 8 brodelt da auch schon Entwicklergemeinde mit ihren C#- NET scheint es auch dem Ende zuzugehen...
Aber das kennen ja Visual Basic Programmierer der ersten und zweiten Generation zur Genüge konnten Ihre Applikationen zu NET migrieren oder fast immer in die Tonne kloppen so gesehen Geschichte wiederholt sich immer und nun ist halt NET dran egal was es kostet !

Wir werden sehen alles Spekulationen

--- Quellen ----

# http://www.linux-community.de/Inter...-die-Skriptsprache-fuer-den-Desktop-einsetzen
# http://www.golem.de/1106/83981.html
# http://www.golem.de/specials/desktop-summit/
 
Zuletzt bearbeitet:
Unter welchem Betriebssystem bzw. GUI kann eine einzelne Applikation die ganze Oberfläche lahmlegen? Verstoßen Single-Core-CPUs auf Desktop-Rechnern nicht inzwischen gegen die Genfer Konventionen? ;)

indy schrieb:
Das stimmt so nicht. Es hängt massiv von den Fähigkeiten des Entwicklers ab.
Zum Vergrößern anklicken....

Indy hat recht, der Entwickler ist hier entscheidend. Wer hier im Forum hat nicht im Laufe seines Lebens mehr als genug lahme C- und C++-Desktopapplikationen kennengelernt?

Unabhängig von der Performance:
Man muss sich der Nachteile einer dynamischen Sprache bewusst sein und diese kompensieren - was der Compiler dort nicht überprüfen kann, muss man durch (um nur ein Beispiel zu nennen) mehr Unit Tests abdecken.
Sofern man dass beherzigt, kommt man aber in vielen (nicht in allen) Fällen mit einer dynamischen Sprache schneller zum Ziel.
Speziell bei einem Media Player ist doch der Performance-kritische Part sowieso in C-Bibliotheken ausgelagert.

Obwohl ich ein Freund statischer typisierter Programmiersprachen bin, muss ich sagen:
Während der C++-Entwickler noch seine Metatemplates bastelt, ist der Python-Programmierer schon fertig. ;)

indy schrieb:
Jemand der Java nicht verstanden hat, schreibt ebenso ineffizienten Code wie jemand, der C++ nicht verstanden hat.
Zum Vergrößern anklicken....

Es ist meiner Meinung nach noch viel schlimmer. Der Aufwand, um C++ ein akzeptables Verständnis der Programmiersprache zu erreichen, ist um Größenordnungen größer als bei Python oder Java.

Nuke hat weiter oben im Thread auch schon einiges angeführt; selbst die fragwürdigsten Konstrukte in Python (Flamewars über significant whitespace bitte in einen eigenen Thread auslagern) oder Java (z.B. Generics) sind Kinderkram gegen die Fallstricke von C++, die an jeder Ecke lauern.

C ist zwar teilweise einfacher, aber auch weniger mächtig als die anderen drei Programmiersprachen (nur weil Programmiersprachen Turing-vollständig sind, sind sie nicht gleichwertig). Es hat seine eigenen Probleme, die bei Desktop-Anwendungen voll zum Tragen kommen (keine Objektorientierung, die allseits beliebten Pointer, etc.).
 
Zuletzt bearbeitet:
Azazyel schrieb:
Unter welchem Betriebssystem bzw. GUI kann eine einzelne Applikation die ganze Oberfläche lahmlegen? Verstoßen Single-Core-CPUs auf Desktop-Rechnern nicht inzwischen gegen die Genfer Konventionen? ;)
Zum Vergrößern anklicken....

OS: FreeBSD
GUI: Gnome
Applikation: games/anki (Flashkartenprogramm)
CPU: Core Duo

Mehr als merkwuerdig...
 
Moin,

lockdoc schrieb:
OS: FreeBSD
GUI: Gnome
Applikation: games/anki (Flashkartenprogramm)
CPU: Core Duo

Mehr als merkwuerdig...
Zum Vergrößern anklicken....

das hat nix mit der Zahl der CPUs/Kerne zu tun. Das liegt an X(Org|Free86|11), weil es nur eine einzige Message-Queue zur Abarbeitung aller Events (Maus, Tastatur, Window, ...) hat. Da kann es dann halt passieren, dass ein rechenintensives oder schlampig designtes oder hängendes Programm die GUI blockieren kann. Zumindest unter Windows NT 4.0 gab es für jede GUI-Applikation eine Message-Queue, was eine Blockade der GUI weitestgehend verhindert hat.
Es gibt Möglichkeiten, eine Blockade durch geschicktes Multithreading und Verwendung von Semaphoren zu weitestgehend zu verhindern, was bei einer systemweiten Message-Queue allerdings sehr schwierig ist.

JueDan
 
@Juedan:
Vielen Dank fuer die Hilfreiche Erklaerung - Jetzt haben wir ja den Schuldigen gefunden. Ich hab mich schon immer gefragt, warum das bei BSD/Linux manchmal vorkommt, dass sogar die Maus stehen bleibt und bei Windows halt nicht.

Nun ist in meinen Augen dann ja die Vorgehensweise von Windows deutlich besser!!!!!!
Plant X(Org|Free86|11) da mal dran zu schrauben um wenigstens Maus/Tastatur eine eigene Message Queue zu spendieren?
Jemand ne Ahnung?
 
Da sie es nicht mal schaffen eine globale Zwischenablage zu machen, wird das wohl nix ;)

X11 gehört einfach in die Tonne...
 
Ich warte schon auf die seitenlangen Heulthreads, dass das Ding unter BSD wieder gar nicht geht und alles Murks ist.
 
Solange der ganze Kram den Wayland braucht nicht im Kernel ist, wird's wohl auch nicht funktionieren ;)

Und solange die Software und Toolkits nicht angepasst werden bringt's auch nix, da dann alles über einen separat laufenden X-Server läuft.
 
Ist es ja nicht... ;) Außer man nutzt die von Python bereitgestellte Oberfläche... die ist in der Tat "etwas" lahm :D
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben