>Muß man bei KDevelop immer noch C/C++ >verwenden oder kann man auch andere, bessere >Sprachen gebrauchen? Was meinst Du mit besseren Sprachen? Was besseres zum Programmieren als C/C++ kann ich mir schwer vorstellen. Einzige Alternative sehe ich bei Java, wobei mir dort einige Sachen fehlen, die das arbeiten bei C++ angenehmer machen. Oder willst Du den Schritt zurück zu COBOL
Die Idee waere gar nicht so schlecht. So ein Ansatz wie beim EMACS, dass jeder seine Sprachen nutzen kann, waere OK. Bessere Sprachen kann ich mir ehrlich gesagt kaum vorstellen. AUSSER in einigen Randgebieten(?) der Informatik, in denen mit Prolog, Lisp und Scheme gearbeitet wird.
Ich fände es toll, wenn KDevelop neben C und C++ (die ich beide sehr mag) auch Python unterstützen würde, da ich denke daß Python auch für große Projekte gut zu gebrauche ist (auch wenn die Objektorientierung meiner meinung nach nicht so toll ist wie in Java und C++ (vor allem kein "privat"))
Ja, ja, ich hätte mir das "besser" wohl doch verkneifen sollen, aber ich konnte es dann doch nicht unterlassen, schließlich war ich doch auf die Reaktionen gespannt und hatte mir schon gedacht, daß ich damit mehr chlafende "Hunde" wecken würde :-) Gemeint ist damit eigentlich nur andere Sprachen, da ich (womit ich nicht alleine stehe) C für eine ziemlich schlechte Sprache halte. Bitte jetzt keinen Sprachenstreit, denn das bringt doch nichts, denn in vielerlei Hinsicht ist es auch eine Geschmacksfrage. Mich wundert aber doch, wie hartnäckig sich solche alten Sprachen trotz der bekannten Schwächen halten, aber da selbst Basic, Cobol und Fortran noch da sind, warum also nicht auch C? Ich will ja auch niemandem sein C abspenstig machen, aber finde es doch schade, wenn es keine Möglichkeit gibt andere Sprachen, sei es nun Ada, Java, Pascal, Lisp, Fortran, Python usw. zu nutzen. Es gibt hunderte von Sprachen, wieso soll man sich da mit C begnügen? Um es mal sarkastisch zu sagen: wenn ich schon einen besseren Assembler möchte, dann nehme ich doch lieber Forth ;-) Mal ernsthafter: woran liegt es, daß KDevelop nur für C geeignet ist? Liegt es an QT oder KDE oder woran? Kann man es nicht offener halten, sodaß jeder seine bevorzugte Sprache nehmen kann, sei es nun eben C oder Lisp oder Smalltalk?
Von Martin Piskernig am Do, 4. Mai 2000 um 16:48 #
Daß andere Sprachen (noch) nicht unterstützt werden, liegt einfach daran, daß noch niemand einen Python/Java/Perl-Parser für den Classbrowser geschrieben hat und andere notwendige Änderungen vornimmt (Compilereinstellungen...). Es handelt sich also um kein prinzipielles, sondern um ein zeitliches Problem.
Ah, danke, dann besteht doch noch Hoffnung, auch für Leute wie mich, die C nicht mögen. Ganz allgemein finde ich es schon erstaunlich, wieviele gute Programme "ehrenamtlich" entwickelt werden. KDevelop ist schon ein sehr gutes Produkt, genauso wie KDE, Gnome, Gimp und viele, viele mehr. Wenn doch KDE 2 nur schon da wäre
Von Benjamin Klöpfer am Do, 4. Mai 2000 um 19:30 #
Nun, ich finde KDevelop schon sehr gut, auch wenn ich grad erst mit c/c++ angefangen habe. Ich meine, und auch viele andere meinen, das KDevelop mit die beste, wenn nicht sogar die beste Entwiklungsumgebung ist. Dem kann ich mich nur anschliessen. Grossen Lob an das KDevelop-Team. Das es nun einige nicht erwarten können, das KDevelop nun auch noch perl oder java usw kann, versteh ich nicht. Abwarten, immerhin muss das alles programiert werden usw .... Aber auch ihr werdet mit KDevelop auf eure kosten kommen. Irgendwann, aber es wird kommen, hoff ich zumindest. Nun, solange bleibt euch noch vim ...
Als best IDe würde ich K-Develop jetz nicht bezeichen. Unter Linux vielleicht aber es gibt ja auch unter Windows Programmieroberflächen, welche durch die jahrelange Arbeit nun doch schon etwas ausgerfeifter sind. Ich finde man kann ja auch eine Windows IDe zum Programmieren verwenden, aber das bleibt ja schließlich jedem selbst überlassen.
Mit KDEVELOP ist ein erstaunlich guter Visual C++ Clone entstanden. Man kann allerdings nicht erwarten das eine IDE alle nur denkbaren Programmiersprachen und Toolkits unterstützt. Fehlt nur noch der Schrei nach UML und sonstiger CASE Unterstützung Für alle die Professional mit C/C++ Entwickeln und sich ellenlange "Handmade" Makefiles sparen wollen, ist KDEVELOP für Linux sicherlich die erste Wahl. Auf meiner Wunschliste steht eigentlich nur noch ein Inline-Debugger. Das scheint aber wohl mit GDB nicht so einfach möglich zu sein;-(
Von Martin Piskernig am Do, 4. Mai 2000 um 22:36 #
Einen Debugger gibt es in KDevelop schon: kdbg! Voll integriert. Und UML-Unterstützung ist On The Way(tm). Du kannst ja schon mal einen Snapshot von KUML probieren, dieses wird später höchstwahrscheinlich als Plugin in KDevelop integriert und wird dann auch Sourcecode aus den Diagrammen erstellen können.
Ich meinte eigentlich einen Inline-Debugger. Aber danke für die Info über KUML. Was ich auf der Webseite sah, macht einen sehr ordentlichen Eindruck. Scheint etwas an Rationals "Rose" angelehnt zu sein Allerdings ist das ganze wohl noch frühe Beta ( wenn ich mir so die Buglist anschaue ;-(
Genau! Das verstehe ich unter einem "Inline-Debugger". Werteveränderung und Ansicht "on the fly". Allerdings ist das eine nicht allzu einfache Angelegenheit. Man betritt hier einen Weg, der den GDB für KDEVELOP überflüssig machen könnte. ( Mir ist nicht bekannt ob der GDB eine so flexible API besitzt um ihn für Inline-Debugging einzusetzen)
>verwenden oder kann man auch andere, bessere
>Sprachen gebrauchen?
Was meinst Du mit besseren Sprachen? Was besseres zum Programmieren als C/C++ kann ich mir schwer vorstellen. Einzige Alternative sehe ich bei Java, wobei mir dort einige Sachen fehlen, die das arbeiten bei C++ angenehmer machen.
Oder willst Du den Schritt zurück zu COBOL
Bessere Sprachen kann ich mir ehrlich gesagt kaum vorstellen. AUSSER in einigen Randgebieten(?) der Informatik, in denen mit Prolog, Lisp und Scheme gearbeitet wird.
:)
"andere, bessere" Sprachen?
Welche denn?
ach ja ... natürlcih ist KDevelop bisher nur für c/c++
auch für große Projekte gut zu gebrauche ist
(auch wenn die Objektorientierung meiner meinung nach nicht so toll ist wie in Java und C++ (vor allem kein "privat"))
Gemeint ist damit eigentlich nur andere Sprachen, da ich (womit ich nicht alleine stehe) C für eine ziemlich schlechte Sprache halte. Bitte jetzt keinen Sprachenstreit, denn das bringt doch nichts, denn in vielerlei Hinsicht ist es auch eine Geschmacksfrage. Mich wundert aber doch, wie hartnäckig sich solche alten Sprachen trotz der bekannten Schwächen halten, aber da selbst Basic, Cobol und Fortran noch da sind, warum also nicht auch C?
Ich will ja auch niemandem sein C abspenstig machen, aber finde es doch schade, wenn es keine Möglichkeit gibt andere Sprachen, sei es nun Ada, Java, Pascal, Lisp, Fortran, Python usw. zu nutzen. Es gibt hunderte von Sprachen, wieso soll man sich da mit C begnügen? Um es mal sarkastisch zu sagen: wenn ich schon einen besseren Assembler möchte, dann nehme ich doch lieber Forth ;-)
Mal ernsthafter: woran liegt es, daß KDevelop nur für C geeignet ist? Liegt es an QT oder KDE oder woran? Kann man es nicht offener halten, sodaß jeder seine bevorzugte Sprache nehmen kann, sei es nun eben C oder Lisp
oder Smalltalk?
Ganz allgemein finde ich es schon erstaunlich, wieviele gute Programme "ehrenamtlich" entwickelt werden. KDevelop ist schon ein sehr gutes Produkt, genauso wie KDE, Gnome, Gimp und viele, viele mehr.
Wenn doch KDE 2 nur schon da wäre
Aber auch ihr werdet mit KDevelop auf eure kosten kommen. Irgendwann, aber es wird kommen, hoff ich zumindest. Nun, solange bleibt euch noch vim ...
Nun, cu
Benjamin Kl.
Für alle die Professional mit C/C++ Entwickeln und sich ellenlange "Handmade" Makefiles sparen wollen, ist KDEVELOP für Linux sicherlich die erste Wahl.
Auf meiner Wunschliste steht eigentlich nur noch ein Inline-Debugger. Das scheint aber wohl mit GDB nicht so einfach möglich zu sein;-(
Und UML-Unterstützung ist On The Way(tm).
Du kannst ja schon mal einen Snapshot von KUML probieren, dieses wird später höchstwahrscheinlich als Plugin in KDevelop integriert und wird dann auch Sourcecode aus den Diagrammen erstellen können.
Aber danke für die Info über KUML. Was ich auf der Webseite sah, macht einen sehr ordentlichen Eindruck. Scheint etwas an Rationals "Rose" angelehnt zu sein