| View previous topic :: View next topic |
| Was wäre euch lieber? |
| Konzentration auf C/C++, weniger Abhängigkeiten |
|
66% |
[ 28 ] |
| Höhere Vielfalt an Sprachen, mehr Abhängigkeiten |
|
33% |
[ 14 ] |
|
| Total Votes : 42 |
|
| Author |
Message |
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
 Posted: Wed Sep 28, 2005 6:31 pm Post subject: Programmiersprachen und Abhängigkeiten - C++ Portage |
 |
|
Hallo, ich starte diesen Artikel erstmal mit zwei Links und einer Grundsatzaussage:
New C++ Portage
Programmiersprachen und Abhängigkeiten
Portage selbst verwendet Python (keine der beiden Hochsprachen C oder C++), dies ist einfach historisch bedingt. Unter anderem war Daniel Robbins scheinbar ein verfechter von Python, ich kann dies aber nicht belegen. Es muss aber zunächst folgendes festgehalten werden:
Portage ist so langsam, weil es viele tausend kleine Textdateien beherbergt, und noch kein Metadatadateisystem oder eine kleine Datenbank verwendet, was sich doch hoffentlich bald ändert.
Bis es soweit ist, kann man nur mit Bugfixes arbeiten, d.h. entweder gleich mit MySQL zur Dampfhammermethode greifen (was als Default wohl eindeutig völlig indiskutabel ist), oder man nimmt ReiserFS, welches mit 4kb Dateien mindestens so unschlagbar ist, wie XFS mit Dateien überhalb von 1GB (soll natürlich nicht heißen, das ReiserFS oder XFS nicht sehr schnell wären mit Dateigrößen zwischen 500kb und 10MB).
Zum Thema:
Portage verwendet Python, und zwingt Gentoo damit zur integration von Python ins Base-System. Ich finde das nicht so schön, da Python wohl eher als zusätzlich Progammiersprache(Interpretersprache) anzusehen ist, nicht als "Kleinster Gemeinsamer Nenner". Ich definier diesen mal wie folgt:
- Assembler - fast schon Maschinencode, ein absolutes Basic (nahe an den Lochkarten)
- C und C++ - beides mächtige Hochsprachen, UNIX und GNU/LINUX basieren auf ihnen
- Bash/ZSH - Shells, und Programmiersprachen (ohne sie kann man sich Unixartige Betriebssystem wohl schlecht vorstellen)
Python macht unsere Base-System also ein gutes Stück fetter, und fett ist erstmal nie schön (ich bin auch nur ein Mann *gg*). Ich habe wirklich nichts gegen fette Menschen, wirklich nicht, aber etwas gegen fette Betriebssytem, die werden langsamer, gefährlicher und verbrauchen ungeheure Mengen an Speicherplatz, für Dinge die man grundsätzlich erstmal nicht braucht.
Ich definiere jetzt mal das Gentoo-Linux Basissystem, auß meiner Sicht:
| Quote: |
GNU-LINUX: Multitasking, Multiuser, Netzwerksupport, vor allem aber auch Performance und Skalierbarkeit
GLIBC und weiter grundlegende Librarys, Kernel, Bash, Standard Unix-Programme - und im Fall von Gentoo ganz besonders: der(?) GCC und der Paketmanager
|
Jetzt zurück!
Ich denke, dass Python hier leider ein Stück zu viel ist, und damit auch mehr als den kleinsten gemeinsamen Nenner darstellt, deswegen befürworte ich das "Portage in C++" Project. Portage wird durch die Umsetzung in C++ höchsten marginal schneller, der Knackpunkt ist allein der Wegfall von Python als Abhängigkeit im Base-System. Und ich finde das schön so 
Das "kleinster gemeinsamer Nenner"-Problem gilt natürlich auch für Perl, Ruby, Lisp (oh je, jetzt verteufeln mich sicher alle), und auch Java/ Mono, ganz einfach weil entweder Java oder Mono ein Rad zu viel am Wagen sind, die Stadt ist zu klein für zwei gleiche Brüder 
Gleiche Brüder sind auch die zuerst von mir genannten Interpretersprachen Python, Ruby, Perl und Lisp, sie sind sinnvoll, weil sie für viele Programmier die Lücke zwischen C und Bash schließen, eine kleines Programm lässt sich damit einfach recht schnell und angenehm aus dem Boden stampfen, ich bin selber kein Programmierer, will mich also auch nicht in die Grabenkämpfe zwischen den einzelnen Sprachen vertiefen.
Klar erscheint mir nur eines, diese Sprachen sind nützlich für viele Programmierer, aber gleichbedeutend mit dem Wort: Abhängigkeit
Wenn ich eine Bogen um ein Programm mache, dann wegen diesen Sprachen. So lange ich meine Useflags auf "-python -perl -ruby -java -mono" gesetzt halte, und Programme wie "Banshee" aka. "Sonance" meide, werde ich gar nicht erst mit diesen so gefürchteten Abhängigkeiten zusammen treffen, geschweige denn über ein fettes Gnome lästern. Ein großer Teil der Entwicklungsarbeit an Gnome gilt nämlich, erfreuliche Art und Weise und leider auch, diesen Interpretersprachen.
So wie ich das sehe, sind diese Sprachen alle nicht ganz perfekt, im ständigen Wettkampf zueinander, oder deren Entstehung nur eine Folge der Unzulänglichkeiten der anderen Sprache. Gleichzeitig erzeugen sie Einerseits widerliche und gewaltige Berge von Abhängigkeiten, und geben den einzelnen Programmieren ihre Wunschsprache zur Hand, was leider auch eine Extrawurst für jeden mitbringt, und damit extra Abhängigkeiten - eine Teufelskreis.
Jetzt könnte man hergehen, und diese Sprache einfach Stück für Stück auszulöschen, mit dem Hintergrund dass es für viele Programmierer und ganz besonders die User leicht wird mit Linux umzugehen. Andererseits töten wir damit ein die Brücke zwischen Bash und C, und berauben vielen Programmieren ihrer liebgewonnen Sprache, und schaden damit vielleicht auch Linux.
Was wäre also wenn man, zumindest "Python, Perl, Ruby und Lisp" zusammen fasst, und durch eine gemeinsame Sprache ersetzt, die alle Bedürfnisse deckt, aber nicht zu kompiliziert ist. Der User kann dann, jedenfalls unter Gentoo, durch seine persönliche Vorliebe wählen, ober er nun Programme auf Basis dieser gemeinsame Sprache will, oder ob er es so hält wie im Base-System - Assemler, C/C++ und Bash, mehr nicht.
Ich habe Mono und Java ausgelassen, weil ich das Gefühl habe, dass sich diese Wettkampf schon von selbst entscheiden wird, und beide in einer anderen Liga Spielen als C/C++ oder die Interpretersprachen. Mir wurde auch schon gesagt dass doch Portage so gut sei, dass doch gerne jeder Programmierer die Programmiersprache seiner Wahl nutzen möchte, seih ja egal wie viele Abhängigkeiten man da hätte, stört doch keinen.
Ich sehe das anders, das stört sehr wohl, und eine Extrawurst für jeden ist im Sinne aller einfach nicht drin (nix mit Star-Trek hier, wir sind Vulkanier!)!
| Quote: | | Ich muss da nur an eine Passage in der Bibel denken - ein gewisser Turm |
Ich wäre sehr froh, wenn auch Programmierer die gerade eben genannten Sprachen sehr gerne nützen, ein offenes Ohr schenken.
Ich habe nichts gegen euch, eure Programme, oder eure Programmiersprachen, ich habe was gegen aufgeblähte Betriebssysteme und Abhängigkeiten, die die Welt nicht braucht.
MfG
Hoschi
<fakeedit> In Erwartung einiger Edits und Flamewars ist hier gleich mal ein Platzhalter
<edit> Python ist auch eine Hochsprache (war mir fast klar dass das gleich was kommt)
<edit> Eine gemeinsame Sprache macht natürlich nur dann Sinn, wenn man mehr als zwei der einzelnen Sprachen nützen würde
_________________
Just you and me strogg!
Last edited by hoschi on Wed Sep 28, 2005 8:07 pm; edited 1 time in total |
|
| Back to top |
|
 |
Deever
Veteran
Joined: 06 Jul 2002
Posts: 1354
Location: Zürich / Switzerland
|
| Posted: Wed Sep 28, 2005 7:30 pm Post subject: |
|
|
Also als erstes möchte ich hier Python schon verteidigen. Es ist ein Juwel von einer Programmiersprache, die von der Mächtigkeit her stark in Richtung C++ geht (als Skriptsprache!), ohne deren Komplexität zu übernehmen, und sie in bestimmter Hinsicht sogar weit hinter sich bringt (wie implementiert man Klassen, die z.B.nur noch Single Inheritance erlauben, oder ein eigenes 'import'-Statement, ohne den Compiler / die VM zu verändern?), bezüglich der Einfachheit aber IMHO gleichzeitig sogar die Krücke Java schlägt? 
Für die Implementierung einer derart grundsätzlichen Systemkomponente wie Portage würde ich aber dennoch C/C++ vorziehen.
Gruß,
/dev |
|
| Back to top |
|
|
golloza
Guru
Joined: 14 Mar 2004
Posts: 427
|
| Posted: Wed Sep 28, 2005 7:38 pm Post subject: |
|
|
- C ist ne Hochsprache und Python nicht oder wie?
- Von aufblähen kann bei Python eigtl. keine Rede sein, mit so ziemlich allen USE-Flags (allein +doc macht 15MB aus) ist dev-lang/python bei mir gerade mal 30MB groß, mir doch grad egal.
- Die ganze Toolchain die man für C braucht, ist wesentlich größer als der Python-Interpreter. Ok, C ist Standard, Python aber mittlerweile auch.
Ich bin absolut gegen eine Neuimplementierung von Portage in C(++), das erhöht nur den Wartungsaufwand, große Performancesprünge bringt allein der Wechsel der Sprache nicht.
Gut fände ich aber, nicht mehr alle zigtausend Ebuild auf Verdacht zu speichern, sondern eine Datenbank (BDB, Sqlite oder sowas in der Richtung) lokal zu haben, in der alle Paketversionen, Keywords und Abhängigkeiten aufgelistet sind und die entsprechenden Ebuilds dann erst bei Bedarf zu besorgen. HOMEPAGE und DESCRIPTION haben in jedem einzelnen Ebuild eigentlich auch nichts zu suchen.
Soweit ich weiss, ist das ja auch schon teilweise angedacht. |
|
| Back to top |
|
|
Deever
Veteran
Joined: 06 Jul 2002
Posts: 1354
Location: Zürich / Switzerland
|
| Posted: Wed Sep 28, 2005 7:51 pm Post subject: |
|
|
Schön wäre, wenn nicht mehr der gleiche Text in tausendfacher (!) Ausführung zusätzlich multipliziert mit jeder verschiedenen Version eines Packages (!!) auf der Platte liegen müßte! Eine völlig sinnfreie Resourcenverschwendung, meiner Meinung nach...
Gruß,
/dev |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Wed Sep 28, 2005 7:58 pm Post subject: |
|
|
Wie gesagt, mir geht es nicht darum einer dieser Interpretersprachen in irgend eine Form schlecht zu reden, sie sind gut auf ihrem Gebiet,
aber eben nicht die Ausgangsbasis, wie es eben C/C++ ist. Ich muss mich aber schon fast selber Loben in dem Punkt auf Portage selbst nebenbei eingegangen zu sein, so haben schon mal alle einen gemeinsamen Nenner (jaja, diese Nenner-Geschichte ist so ein Ding von mir) - und alle reden am Thema vorbei
| Quote: | | Die ganze Toolchain die man für C braucht, ist wesentlich größer als der Python-Interpreter. Ok, C ist Standard, Python aber mittlerweile auch. |
Stellt sich die Frage für was Python Standard ist, sicherlich für einige Programmieraufgaben, aber nur für Portage im Base-System*.
Versteh mich nicht falsch, ich will sozusagen wenn dann eine neues vereinigtes Python, ohne dass es mir aufgezwungen wird.
*Oder gibts da sonst noch was großes?
_________________
Just you and me strogg! |
|
| Back to top |
|
|
Sas
Veteran
Joined: 05 Jul 2003
Posts: 1229
Location: Germany
|
| Posted: Wed Sep 28, 2005 8:17 pm Post subject: |
|
|
Oha, ein Blinder schreibt über die Farbe.
Also zunächst mal finde ich es übel, funktionale (LISP), imperative/prozedurale und objektorientierte Programmiersprachen (na gut, die beiden lasse ich noch durchgehen) in einen Topf zu werfen. Abgesehen davon, dass es z.B. für LISP auch Compiler gibt und dass Python-Programme genau wie Java oder .NET (Mono) in einen Byte-Code übersetzt werden, der dann interpretiert wird.
Der gespürte Geschwindigkeitsgewinn von Portage auf MySQL-Basis gegenüber der 'normalen' Version ist trotz XFS auf meinem Rechner nicht vorhanden. Aber ich gebe zu, dass ich nicht nachgemessen habe.
Eine Re-Implementierung in C (oder CPP - ja was denn jetzt? Und wenn C, wie dann? Python ist OO, C nicht.) würde da auch nichts Wesentliches bringen, aber das sagst du ja selbst. Sinnvoller wäre hier die Funktionsweise und Architektur von Portage zu überdenken, Ansätze dazu wurden ja bereits genannt.
Ein konkretes Urteil darüber möchte ich mir jetzt gar nicht erlauben, da ich mit der Umsetzung von Portage nicht vertraut bin - wohl aber mit Softwaredesign und -entwicklung im Allgemeinen. Daher kann ich durchaus beurteilen, dass es hier sinnvollere Betätigungsfelder gäbe, als das vorhandene Portage in einer anderen Sprache neu zu schreiben.
Edit: Anmerken möchte ich noch, dass ich eine große Programmvielfalt - nicht nur bei Programmiersprachen - generell befürworte. Das sichert Auswahl, Wettbewerb und die Möglichkeit die Alternative mit den für den konkreiten Anwendungsfall größten Vorteilen zu nutzen. Dass man auf Portage unter Gentoo nicht verzichten kann, leuchtet ein. Aber grundsätzlich gilt: Wenn man sich mit irgendeiner wirklich benötigten Abhängigkeit absolut nicht anfreunden kann, wird man wohl auf die entsprechende Software verzichten müssen.
_________________
42 |
|
| Back to top |
|
|
Freiburg
Guru
Joined: 19 Jun 2004
Posts: 504
Location: Freiburg
|
| Posted: Wed Sep 28, 2005 10:01 pm Post subject: |
|
|
| Von mir aus kann alles in den Portage solange es nicht in c# geschrieben ist, da stellts einem die Fußnägel auf... |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Wed Sep 28, 2005 10:34 pm Post subject: |
|
|
@Sas: Wenn du dem ersten Link gefolgt wärst, hättest du gesehen dass der Kerl Portage in C++ (OO) neu schreibt
Die nähere Funktionsweise von Portage an sich ist allerdings hier auch nicht interessant.
| Quote: | | Wenn man sich mit irgendeiner wirklich benötigten Abhängigkeit absolut nicht anfreunden kann, wird man wohl auf die entsprechende Software verzichten müssen. |
Bis jetzt kann ich gut damit leben, in Zukunft muss ich es "vielleicht" gar nicht mehr, oder doch. Kommt noch auf.
Mich würde allerdings brennend interessieren, was Freiburg uns mitteilen wollte, will er Mono nicht im Portage-Tree,
oder kein Portage auf Basis von Mono 
Dann wäre Banshee für Freiburg interessant, da sollen noch einige Leichen zwischen dem Gnome-Projekt und Novell im Keller liegen,
gerade was Abhängigkeiten angeht (wobei ich das immer noch für einen verdammt schlechten Scherz halte).
Andererseits wäre es auch mal erheiterend zu erfahren, wie manch Schönling meint, dass gewisse Programmiersprachen die Festplattenperformance
steigern soll
_________________
Just you and me strogg!
Last edited by hoschi on Wed Sep 28, 2005 10:37 pm; edited 1 time in total |
|
| Back to top |
|
|
Freiburg
Guru
Joined: 19 Jun 2004
Posts: 504
Location: Freiburg
|
| Posted: Wed Sep 28, 2005 10:36 pm Post subject: |
|
|
| Kein C# im Portage, keine Programme die darauf basieren und schon garkein Portage in C# programmiert |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Wed Sep 28, 2005 10:53 pm Post subject: |
|
|
| Freiburg wrote: | | Kein C# im Portage, keine Programme die darauf basieren und schon garkein Portage in C# programmiert |
Hat das verschiedene Gründe (Abhängigkeiten die damit neu eingeführt werden), oder weil das noch ein paar gefährliche Patente bei
MS im Keller liegen könnten?
_________________
Just you and me strogg! |
|
| Back to top |
|
|
Freiburg
Guru
Joined: 19 Jun 2004
Posts: 504
Location: Freiburg
|
| Posted: Wed Sep 28, 2005 11:01 pm Post subject: |
|
|
| Ich mag die Programmiersprache nicht, das ist finde ich ein ganz ekelhafter Mix aus C++, Visual Basic und Java... |
|
| Back to top |
|
|
Mr. Anderson
l33t
Joined: 22 Apr 2004
Posts: 762
|
| Posted: Wed Sep 28, 2005 11:03 pm Post subject: |
|
|
Der m. E. gravierende Nachteil von C++ besteht darin, dass es nicht plattformunabhängig ist, und da Gentoo nun mal sehr viele Plattformen unterstützt, könnte das wirklich hässlich werden.
Sicher ist es reizvoll im Basissystem möglichst wenig Pakete zu haben, aber das Risiko ist m. E. zu groß. Besser wäre es den Interpreter zu optimieren. (Python optimieren oder z. B. zu Java wechseln) Aber auf Dauer würde das wohl nicht reichen, und der Aufwand ist relativ groß.
Was genau ist eigentlich dieses Rumgerattere "updating portage cache". Was dauert da solange? |
|
| Back to top |
|
|
platinumviper
l33t
Joined: 12 Feb 2004
Posts: 658
Location: Munich, Germany
|
| Posted: Wed Sep 28, 2005 11:17 pm Post subject: Re: Programmiersprachen und Abhängigkeiten - C++ Portage |
|
|
Diese Diskussion ist ziemlich sinnlos, die allermeisten Programme werden nicht explizit für Gentoo (oder andere Sourcecode-basierte Distributionen) geschrieben. Wenn ein Programmierer ein Projekt startet, wird er die Programmiersprache auswählen, die dafür am Besten geeignet ist, bei einer KI-Anwendung also z.B. LISP oder Prolog, aber nicht Perl oder C. Wenn Du das Programm benutzen willst, musst Du entweder die Binärversion (falls es einen Compiler gibt) oder die Sourcen und den Compiler/Interpreter installieren. Das Dir seine Wahl nicht gefällt, wird den Programmierer bestenfalls ein ganz klein wenig traurig machen
Es gibt übrigens zwei Arten von Abhängigkeiten in ebuilds, DEPEND und RDEPEND, was in DEPEND aufgeführt wird, wird zum Compilieren benötigt, wenn es in RDEPEND nicht wieder auftaucht kannst Du es anschliessend wieder deinstallieren.
platinumviper
_________________
No money back garantee. In case of problems, don't call us, we call you. |
|
| Back to top |
|
|
xces
Guru
Joined: 11 Oct 2002
Posts: 515
|
| Posted: Thu Sep 29, 2005 12:00 pm Post subject: |
|
|
| golloza wrote: | | - Von aufblähen kann bei Python eigtl. keine Rede sein, mit so ziemlich allen USE-Flags (allein +doc macht 15MB aus) ist dev-lang/python bei mir gerade mal 30MB groß, mir doch grad egal. |
30 MB weniger im Basissystem ist doch eine Überlegung wert, gerade für Embedded Systeme.
| golloza wrote: | | - Die ganze Toolchain die man für C braucht, ist wesentlich größer als der Python-Interpreter. |
Stimmt, aber diese Toolchain (GCC, make, autotools) brauchst du sowieso zum Erstellen des Systems (z. B. Kernel und praktisch das gesamte Basissystem).
| golloza wrote: | | Ich bin absolut gegen eine Neuimplementierung von Portage in C(++), das erhöht nur den Wartungsaufwand, große Performancesprünge bringt allein der Wechsel der Sprache nicht. |
Nein, Performazsprünge sind auf Grund einer einfachen Reimplementierung bei Portage nicht möglich, aber es würde die Abhängigkeiten beim Erstellen des Basissystems verringern.
| Mr. Anderson wrote: | | Der m. E. gravierende Nachteil von C++ besteht darin, dass es nicht plattformunabhängig ist, und da Gentoo nun mal sehr viele Plattformen unterstützt, könnte das wirklich hässlich werden. |
Wenn man sich an gewisse Konventionen (z. B. POSIX) hält, ist C++ durchaus sehr portabel und könnte fast als plattformunabhängig bezeichnet werden. Andererseits ist C++ eine Programmiersprache und auf die ist das Attribut "plattformunabhängig" sicherlich nicht anwendbar. Du meinst eher den G++, den C++ Compiler der GCC.
| Mr. Anderson wrote: | | Sicher ist es reizvoll im Basissystem möglichst wenig Pakete zu haben, aber das Risiko ist m. E. zu groß. Besser wäre es den Interpreter zu optimieren. (Python optimieren oder z. B. zu Java wechseln) Aber auf Dauer würde das wohl nicht reichen, und der Aufwand ist relativ groß. |
Dir sagt die "Java-Falle" etwas? Dann bleiben wir lieber bei Python. Das ist wenigstens frei.
| Freiburg wrote: | | Ich mag die Programmiersprache nicht, das ist finde ich ein ganz ekelhafter Mix aus C++, Visual Basic und Java... |
Deine Meinung. Wenn du .NET/C#/Mono nicht magst, kannst du die entsprechenden Kategorien und Ebuilds gerne von deinem Portage-Tree ausnehmen. Dann wird bei dir auch keine Bandbreite für diese Ebuilds verschwendet... |
|
| Back to top |
|
|
Freiburg
Guru
Joined: 19 Jun 2004
Posts: 504
Location: Freiburg
|
| Posted: Thu Sep 29, 2005 12:57 pm Post subject: |
|
|
| @xces eben das ist ja finde ich das schöne am Portage: was man nicht will braucht man auch nicht zu haben, jeder kann sich sein System also so bauen wie er will und alle sind glücklich... |
|
| Back to top |
|
|
Mr. Anderson
l33t
Joined: 22 Apr 2004
Posts: 762
|
| Posted: Thu Sep 29, 2005 1:38 pm Post subject: |
|
|
| Quote: | | Wenn man sich an gewisse Konventionen (z. B. POSIX) hält, ist C++ durchaus sehr portabel und könnte fast als plattformunabhängig bezeichnet werden. Andererseits ist C++ eine Programmiersprache und auf die ist das Attribut "plattformunabhängig" sicherlich nicht anwendbar. Du meinst eher den G++, den C++ Compiler der GCC. |
Es ist doch wohl klar, was ich meine. Java ist vom Konzept eine Sprache, deren ausführbare Programmdateien nicht an eine bestimmte Architektur oder ein bestimmtes Betriebssystem gebunden sind. Und die GCC ist genausowenig plattformunabhängig wie jedes C-Programm. Es ist leicht zu portieren, ja, aber ganz sicher nicht plattformunabhängig. Das Minimum besteht darin, es neu zu kompilieren. Sicher, bei Gentoo kein Beinbruch, aber es entstehen neue, unnötige Fehlerquellen schon in der Boot-CD. Wenn man überall denselben Byte-Code verwendet - und er funktioniert dann auf einem System - dann kann man ziemlich sicher davon ausgehen, dass er auch auf den anderen funktioniert und scheidet als Fehlerquelle aus.
| Quote: | | Dir sagt die "Java-Falle" etwas? Dann bleiben wir lieber bei Python. Das ist wenigstens frei. |
Was ist mit GCJ, Jikes, Kaffe, Japhar, vielleicht auch JC usw.? |
|
| Back to top |
|
|
xces
Guru
Joined: 11 Oct 2002
Posts: 515
|
| Posted: Thu Sep 29, 2005 3:14 pm Post subject: |
|
|
| Mr. Anderson wrote: | | Und die GCC ist genausowenig plattformunabhängig wie jedes C-Programm. Es ist leicht zu portieren, ja, aber ganz sicher nicht plattformunabhängig. |
Wenn du Portage in Java implementieren willst, ist das Resultat mit Sicherheit auch nicht mehr plattformunabhängig.
| Mr. Anderson wrote: | | Das Minimum besteht darin, es neu zu kompilieren. Sicher, bei Gentoo kein Beinbruch, aber es entstehen neue, unnötige Fehlerquellen schon in der Boot-CD. |
Und bei Java müsste die JVM gebaut/installiert werden. Wie im Moment Python. Das nimmt sich also nicht viel.
| Mr. Anderson wrote: | | Was ist mit GCJ, Jikes, Kaffe, Japhar, vielleicht auch JC usw.? |
GCJ und Jikes sind nur Compiler, Kaffe hat keine vollständige VM, Japhar ist noch lange nicht vollständig und JC kenne ich nicht.
Du hast übrigens noch GNU Classpath vergessen, eine freie Klassenbibliothek, welche ebenfalls noch nicht vollständig ist. Im Moment bleibst du also bei Suns Java stecken, wenn du das vollständige Featureset und vor allem Plattformunabhängigkeit willst. |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Thu Sep 29, 2005 3:17 pm Post subject: |
|
|
| Mr. Anderson wrote: | Der m. E. gravierende Nachteil von C++ besteht darin, dass es nicht plattformunabhängig ist, und da Gentoo nun mal sehr viele Plattformen unterstützt, könnte das wirklich hässlich werden.
Sicher ist es reizvoll im Basissystem möglichst wenig Pakete zu haben, aber das Risiko ist m. E. zu groß. Besser wäre es den Interpreter zu optimieren. (Python optimieren oder z. B. zu Java wechseln) Aber auf Dauer würde das wohl nicht reichen, und der Aufwand ist relativ groß.
Was genau ist eigentlich dieses Rumgerattere "updating portage cache". Was dauert da solange? |
Ich glaube Plattformunabhängig ist in Bezug auf C/C++ wohl eher als relativ zu betrachten, sobald der Compiler läuft und die Deps erfühlt sind gibts es wohl kaum noch großen Ärger, zwischen WIN und Unix ist das natürlich was anders (und da ist Java einfach ein Segen).
_________________
Just you and me strogg! |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Thu Sep 29, 2005 3:23 pm Post subject: |
|
|
| xces wrote: | | golloza wrote: | | - Von aufblähen kann bei Python eigtl. keine Rede sein, mit so ziemlich allen USE-Flags (allein +doc macht 15MB aus) ist dev-lang/python bei mir gerade mal 30MB groß, mir doch grad egal. |
30 MB weniger im Basissystem ist doch eine Überlegung wert, gerade für Embedded Systeme.
| golloza wrote: | | - Die ganze Toolchain die man für C braucht, ist wesentlich größer als der Python-Interpreter. |
Stimmt, aber diese Toolchain (GCC, make, autotools) brauchst du sowieso zum Erstellen des Systems (z. B. Kernel und praktisch das gesamte Basissystem).
| golloza wrote: | | Ich bin absolut gegen eine Neuimplementierung von Portage in C(++), das erhöht nur den Wartungsaufwand, große Performancesprünge bringt allein der Wechsel der Sprache nicht. |
Nein, Performazsprünge sind auf Grund einer einfachen Reimplementierung bei Portage nicht möglich, aber es würde die Abhängigkeiten beim Erstellen des Basissystems verringern.
| Mr. Anderson wrote: | | Der m. E. gravierende Nachteil von C++ besteht darin, dass es nicht plattformunabhängig ist, und da Gentoo nun mal sehr viele Plattformen unterstützt, könnte das wirklich hässlich werden. |
Wenn man sich an gewisse Konventionen (z. B. POSIX) hält, ist C++ durchaus sehr portabel und könnte fast als plattformunabhängig bezeichnet werden. Andererseits ist C++ eine Programmiersprache und auf die ist das Attribut "plattformunabhängig" sicherlich nicht anwendbar. Du meinst eher den G++, den C++ Compiler der GCC.
| Mr. Anderson wrote: | | Sicher ist es reizvoll im Basissystem möglichst wenig Pakete zu haben, aber das Risiko ist m. E. zu groß. Besser wäre es den Interpreter zu optimieren. (Python optimieren oder z. B. zu Java wechseln) Aber auf Dauer würde das wohl nicht reichen, und der Aufwand ist relativ groß. |
Dir sagt die "Java-Falle" etwas? Dann bleiben wir lieber bei Python. Das ist wenigstens frei.
| Freiburg wrote: | | Ich mag die Programmiersprache nicht, das ist finde ich ein ganz ekelhafter Mix aus C++, Visual Basic und Java... |
Deine Meinung. Wenn du .NET/C#/Mono nicht magst, kannst du die entsprechenden Kategorien und Ebuilds gerne von deinem Portage-Tree ausnehmen. Dann wird bei dir auch keine Bandbreite für diese Ebuilds verschwendet... |
Sprichst mir aus der Seele, soll heißen du verstehst was ich meine und denke.
Zu Mono und Java sage ich aber nichts, ich halte mich da lieber raus - ich kann da ein paar schöne Punkte finden, aber auch nerviges und Gefahren
_________________
Just you and me strogg! |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Thu Sep 29, 2005 3:33 pm Post subject: |
|
|
| Mr. Anderson wrote: | | Quote: | | Wenn man sich an gewisse Konventionen (z. B. POSIX) hält, ist C++ durchaus sehr portabel und könnte fast als plattformunabhängig bezeichnet werden. Andererseits ist C++ eine Programmiersprache und auf die ist das Attribut "plattformunabhängig" sicherlich nicht anwendbar. Du meinst eher den G++, den C++ Compiler der GCC. |
Es ist doch wohl klar, was ich meine. Java ist vom Konzept eine Sprache, deren ausführbare Programmdateien nicht an eine bestimmte Architektur oder ein bestimmtes Betriebssystem gebunden sind. Und die GCC ist genausowenig plattformunabhängig wie jedes C-Programm. Es ist leicht zu portieren, ja, aber ganz sicher nicht plattformunabhängig. Das Minimum besteht darin, es neu zu kompilieren. Sicher, bei Gentoo kein Beinbruch, aber es entstehen neue, unnötige Fehlerquellen schon in der Boot-CD. Wenn man überall denselben Byte-Code verwendet - und er funktioniert dann auf einem System - dann kann man ziemlich sicher davon ausgehen, dass er auch auf den anderen funktioniert und scheidet als Fehlerquelle aus.
| Quote: | | Dir sagt die "Java-Falle" etwas? Dann bleiben wir lieber bei Python. Das ist wenigstens frei. |
Was ist mit GCJ, Jikes, Kaffe, Japhar, vielleicht auch JC usw.? |
Ich weiß dass das gemein ist, entschuldige:
Java hat eindeutig andere Felder, auf dennen es seine Stärken auch ausspielt.
Aber die Behauptung eine C-Applikation wäre nicht portierbar ist einfach nicht klug, sondern falsch, C ist portabel, es ist nur eine Frage des Betriebssystems. GNU/LINUX (Gentoo) hat damit logischer weise überhaupt keine Probleme, ebensowenig alles Unix basierten Systeme (Solaris, BSD, MacOS). Ohne Toolchain hättest du gar keine Linux mehr, dass wäre keine Abhängigkeite von einem C++ Portage, sondern die Abhängigkeite des Betriebssystems in sich. In dem Moment als der GCC, und damit der C-Compiler, erfolgreich unter Linux gestartet wurde, kamm Linux auf die Welt, damit waren nahezu alle Unix-Programme einsetzbar.
Du kannst in Java auch keine Betriebssystem schreiben, Solaris ist dafür kaum ein Beweis, aber in Indiz.
Schade ist nur dass kaum jemand von Javas Portabilität profitieren kann, wenn MS Sun nicht aufs Kreuz gelegt hätte, gäbe es heute vielleicht einige schöne webbasierte Anwendungen mehr. Im Browser klicken, und schon starte das Programm - kommt leider noch selten vor.
Portabel ist ein relativer Begriff.
Hier mal was von einem anderen Forum:
| Quote: | Zitat von Schalentier
Naja, zu Hoschis Theorien sage ich jetzt mal nichts. Der sieht echt Geister.
Aber zu dem Zusammenfassen: Schonmal von Parrot gehört? Die entwickeln seit drei Jahren eine VM komplett mit Intermediate Language und JIT-Compiler, aber eine speziell für Skriptsprache. Parrot geht auf einen Aprilscherz zurück, als sie angekündigt haben, Perl und Python zusammenzuführen, zu einer Sprache. Das wird zwar nicht passieren, aber sie sollen in den nächsten Major-Versionen eine gemeinsame VM bekommen. Wie's aussieht, kommen andere Skriptsprachen dann noch hinterher. Natürlich braucht jede Sprache noch ein paar eigene Bibliotheken und Compiler-Frontend, aber in Theorie sollte eine gemeinsame VM mit gemeinsamen Core-Features (String-Handling, Betriebssystem-Glue-Code, Threading, ...) auch den Bloat reduzieren. Von dem Geschwindigkeitsgewinn mal ganz abgesehen. |
_________________
Just you and me strogg! |
|
| Back to top |
|
|
Mr. Anderson
l33t
Joined: 22 Apr 2004
Posts: 762
|
| Posted: Thu Sep 29, 2005 4:01 pm Post subject: |
|
|
| xces wrote: | | Wenn du Portage in Java implementieren willst, ist das Resultat mit Sicherheit auch nicht mehr plattformunabhängig. |
Ist es dann kein Byte-Code mehr?
| xces wrote: | GCJ und Jikes sind nur Compiler, Kaffe hat keine vollständige VM, Japhar ist noch lange nicht vollständig und JC kenne ich nicht.
Du hast übrigens noch GNU Classpath vergessen, eine freie Klassenbibliothek, welche ebenfalls noch nicht vollständig ist. Im Moment bleibst du also bei Suns Java stecken, wenn du das vollständige Featureset und vor allem Plattformunabhängigkeit willst. |
Also für Portage braucht man nun wirklich kein vollständiges Featureset. Und Kaffe hat Ports für nahezu jedes denkbare System.
| Quote: | Ich weiß dass das gemein ist, entschuldige:
Solaris 10 und sein Desktop sind nicht in Java geschrieben, obwohl Java von SUN selbst kommt.
Es taugt dafür nicht und daran wird sich kaum etwas ändern. |
Hat das was mit Portage zu tun?
| Quote: | Java hat eindeutig andere Felder, auf dennen es seine Stärken auch ausspielt.
Die Behauptung eine C-Applikation wäre nicht portierbar ist einfach nicht klug, C ist portabel,
es ist nur eine Frage des Betriebssystems, ob es mitspielt. |
Ja, das wäre in der Tat nicht klug. Hab ich aber auch nicht gemacht.
Ich sage ja nicht, dass es unbedingt Java sein muss, sondern ich hab davon geschrieben den Interpreter zu optimieren. Dass auch Java Schwächen hat, weiß ich selbst. Ich verstehe aber auch nicht, warum es unbedingt C/C++ sein muss. Ganz gleich in welcher Sprache man es umsetzt - solange sich nicht am Grundgerüst was ändert, werden die gleiche Probleme in einem Jahr wieder auftauchen. |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Thu Sep 29, 2005 4:29 pm Post subject: |
|
|
Die Sache mit dem Grundgerüst von Portage ist hier auch nicht der Kern, ich wollte es nur einmal klar aufzeigen, damit man die C++ - Version losgelöst von den anderen Portage-Problemen sieht. C/C++ liegt deswegen nahe, da es "keine Abhängigkeiten" mit sich bringt und nur ein ohnehin vorhandenes Grundsystem verlangt, dass C/C++ wesentlich weiter verbreitet ist unter Programmierer und sich noch mehr Leute damit befassen werte ich dagegen jetzt nicht mal, die meisten können sowieso mehrere Sprachen.
| Quote: |
"Das Minimum besteht darin, es neu zu kompilieren. Sicher, bei Gentoo kein Beinbruch, aber es entstehen neue, unnötige Fehlerquellen schon in der Boot-CD. Wenn man überall denselben Byte-Code verwendet - und er funktioniert dann auf einem System - dann kann man ziemlich sicher davon ausgehen, dass er auch auf den anderen funktioniert und scheidet als Fehlerquelle aus. " |
Deswegen die Anmerkung mit Solaris, Java ist als Code für ein OS einfach unrealistisch, außer ich habe dich damit falsch verstanden.
Außerdem scheinst du dabei die Wechselwirkungen beim Einsatz verschiedener VMs zu vergessen.
_________________
Just you and me strogg! |
|
| Back to top |
|
|
Mr. Anderson
l33t
Joined: 22 Apr 2004
Posts: 762
|
| Posted: Fri Sep 30, 2005 4:25 pm Post subject: |
|
|
| hoschi wrote: | | Die Sache mit dem Grundgerüst von Portage ist hier auch nicht der Kern, ich wollte es nur einmal klar aufzeigen, damit man die C++ - Version losgelöst von den anderen Portage-Problemen sieht. C/C++ liegt deswegen nahe, da es "keine Abhängigkeiten" mit sich bringt und nur ein ohnehin vorhandenes Grundsystem verlangt, dass C/C++ wesentlich weiter verbreitet ist unter Programmierer und sich noch mehr Leute damit befassen werte ich dagegen jetzt nicht mal, die meisten können sowieso mehrere Sprachen. |
Ok, dann betrachte bitte meine Aussagen zu den strukturellen Problemen als gegenstandslos
| hoschi wrote: | | Deswegen die Anmerkung mit Solaris, Java ist als Code für ein OS einfach unrealistisch, außer ich habe dich damit falsch verstanden. |
Naja, wir reden ja nur von Portage, nicht vom ganzen System. Der Kernel, die Shell und all die grundlegenden Tools sind immer noch in C oder C++ geschrieben.
| hoschi wrote: | | Außerdem scheinst du dabei die Wechselwirkungen beim Einsatz verschiedener VMs zu vergessen. |
Woran denkst Du dabei?
Einen anderen Aspekt möchte ich noch aufgreifen: C/C++ sind vielfältige, mächtige Sprachen. Allerdings gibt es dadurch auch große Unterschiede im Programmierstil. Größer als bei Python oder Java. Einfach deshalb weil man sehr viel mehr Möglichkeiten hat. Nun wird an Portage nicht nur eine Person schreiben, sondern es ist nicht absehbar, ob nicht recht viele Personen dran basteln werden. Das kostet Zeit und gibt Quellen für Fehler. |
|
| Back to top |
|
|
hoschi
Advocate
Joined: 19 Jul 2003
Posts: 2517
Location: Ulm, Germany, Europe
|
| Posted: Fri Sep 30, 2005 6:54 pm Post subject: |
|
|
Ja das stimmt, die steigende Möglichkeit von Fehler mit dem Einsatz von "mächtigerer" Sprachen wird oft diskutiert, aber dieses Risiko entsteht eben durch die größere "Macht" selbst. Ein Werkzeug muss man immer wie ein Schwert betrachten, die eine Klinge zeigt nach Vorn, die andere leider nach Hinten.
Wobei wir uns sicher beide Wünschen, dass wir einen "Schwertführer" haben, der mit der Waffe richtig umgehen kann.
Mächtig ist relativ.
Unter Java gibts es verschiedene VMs:
Welche nützen, warum, welche Vorteile, Nachteile, was geht nicht, welche Fehler auf welchen Plattformen.
Gleichheit und Verschiedenheit sind Dinge die am besten in guter Balance bleiben.
_________________
Just you and me strogg! |
|
| Back to top |
|
|
xces
Guru
Joined: 11 Oct 2002
Posts: 515
|
| Posted: Fri Sep 30, 2005 8:29 pm Post subject: |
|
|
| Mr. Anderson wrote: | | Allerdings gibt es dadurch auch große Unterschiede im Programmierstil. Größer als bei Python oder Java. |
Das glaube ich so nicht. Bei Java gibt es durchaus verschiedene Programmierstil. Die Meisten kann man auf Grund der Ähnlichkeiten in der Syntax von Java und C/C++ direkt von C/C++ nach Java übernehmen.
Bei Python sieht die Sache anders aus, aber auch nur weil z. B. die Einrückungen durch die Syntax von Python bedingt werden. Ob das sinnvoll und/oder schön ist, gehört aber in eine andere Diskussion.
Am Linux-Kernel arbeiten auch sehr viele Leute. Sicherlich n mal soviele, wie an Portage. Dennoch kann man sich offensichtlich auf einen gemeinsamen Stil einigen. Nicht umsonst gibt es bei jedem größeren (oder auch kleineren) Projekt Coding Guidelines. Die sind nicht zum Spass da. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Deutsches Forum (German) 
