Entwicklungsgeschwindigkeit mit verschiedenen Sprachen
-
@Scheppertreiber: Verwendest du nen Debugger?
-
Ein kleines Tool das das makefile erstellt, was denn sonst *smiley*
vi ist nun wirklich fast so schlimm wie edlin. Ich habe den e2 ...
Auch etwas betagt aber ideal. Vielleicht alles nicht der hype aber funktional.
Und das zählt.Gute Nacht, Italschen ist weiter ...
-
ganz armselige Diskussion hier
-
@Shade Of Mine
Hast du dir das Video von .filmor angeguckt? (http://video.google.de/videoplay?docid=6297126166376226181) das demonstriert imo ziemlich gut das Dinge wie IDE und Debugger nicht entscheidend sind. Wichtig ist die passendste Sprache mit dem passendstem framework für das Problem zu finden (und das ist imho in den allerseltensten fällen java).Das mit den Tools trifft schon eher auf low-level embedded Programmierung zu. Da kann ein openocd fähiger jtag oder ein Oskar schonmal nen paar Stunden rumprobieren sparen. Dort hat man allerdings auch oft keine Wahl was Programmiersprachen/Frameworks angeht.
-
borg schrieb:
@Shade Of Mine
Hast du dir das Video von .filmor angeguckt? (http://video.google.de/videoplay?docid=6297126166376226181) das demonstriert imo ziemlich gut das Dinge wie IDE und Debugger nicht entscheidend sind. Wichtig ist die passendste Sprache mit dem passendstem framework für das Problem zu finden (und das ist imho in den allerseltensten fällen java).Das mit den Tools trifft schon eher auf low-level embedded Programmierung zu. Da kann ein openocd fähiger jtag oder ein Oskar schonmal nen paar Stunden rumprobieren sparen. Dort hat man allerdings auch oft keine Wahl was Programmiersprachen/Frameworks angeht.
Shade Of Mine schrieb:
@.filmor:
libraries gehoeren zum toolset dazu.Das Problem ist halt, dass kein Mensch weiß was ein toolset genau sein soll und deshalb kann Shade alles reinpacken und kann sagen, das gehört auch dazu und darum ist man damit schneller. Und der Vergleich Assembler vs. Java/C++/Basic ist doch quatsch, weil man bei größeren Projekten natürlich mit einer Hochsprache immer schneller ist als mit Assembler. Das ist kein Sprachenvergleich sondern ein Sprachtypenvergleich.
Die Frage ist doch eher: Könnte man mit C++ ein Programm genauso schnell schreiben wie mit Visual Basic, wenn beide Sprachen genau die gleichen Libraries und Tools hätten?
-
Scheppertreiber schrieb:
Den ganzen anderen Firlefanz a la IDE etc -> Tonne.
ROFL
-
byto schrieb:
Scheppertreiber schrieb:
Den ganzen anderen Firlefanz a la IDE etc -> Tonne.
ROFL
Was erwartest du? Der Mann ist von Beruf "Programmierhippie". Mit LSD brauchst du keine IDE mehr
-
ich wuerd sagen es kommt sehr darauf an was gemacht werden soll und welche moeglichkeiten man bekommt
zbAufgabe:
Entwickel eine oberflaeche welche die elemente rechts ausrichtet und ein paar elemente beim resizen verschiebt und andere teile skaliert- in MFC oder WinApi zb muss man beim WM_SIZE jedes element anfassen und entsprechend verschieben bzw skalieren
- in .NET mit CLI oder C# kann ich das mit einen klick einstellen und fertig ist
da stellt sich noch die frage bezuelich des flackerns welches dann bei der MFC und WinApi methode einstellt - da muss man dann auch noch bei gehenden performance unterschied kenn ich fuer diesen fall nicht - es geht ja hier gerade um die entwicklungsgeschwindigkeit - und da gewinnt man immer wenn eine IDE und/oder ein framework einen arbeit abnimmt und automatishc erledigt
wenn jemand 10finter tippt - ist er schon schnell - keine frage,
nur wenn die IDE varaiblen und methoden automatisch vorschlaegt und mit Enter einsetzt - ist dieser noch schneller als wenn er alles per hand eintippt - zudem sind tippfehler dann ausgeschlossen (zb gross-klein schreibung)noch ein kleines beispiel
per hand eingeben:
SortedList<DateTime, string> _bla = new SortedList<DateTime, string>();bei VS wird wenn man new schreibt das "SortedList<DateTime, string>" automatisch vorgeschlagen - man kann es mit enter direkt uebernehmen ohne ein wort tippen zu muessen
eine richtige entwicklungsumgebung beschleunigt schon das entwerfen erheblich
muss nur noch entsprechend genutzt werden- dann ist der flaschenhals nur noch die kompetenz des entwicklers
-
Es ging darum, wie man am schnellsten ein Programm fertigbekommt.
Wenn Du's nur mit einer IDE hinbringst dann nimm die halt.Ich mache das nicht.
-
Scheppertreiber schrieb:
Es ging darum, wie man am schnellsten ein Programm fertigbekommt.
wer sagt das ?
Thread schrieb:
Entwicklungsgeschwindigkeit mit verschiedenen Sprachen
entwicklungsgeschwindigkeit ist nicht die dauer eines projektes {o;
-
mama goose schrieb:
Die Frage ist doch eher: Könnte man mit C++ ein Programm genauso schnell schreiben wie mit Visual Basic, wenn beide Sprachen genau die gleichen Libraries und Tools hätten?
könnte man, allerdings braucht der c++ coder ca. 10jahre mehr erfahrung als der vb-coder.
-
Das Wichtige ist die Kombination. Der Programmierer muss seine Tools kennen. Man kann nicht sagen Tool (Programmiersprache) A ist besser/schneller als B.
Da kann jemand ein komplexes Problem mit Assembler + Notepad vielleicht besser lösen, als jemand der Tools benutzt die er nicht oder kaum kennt.
Ein Tool kann auch nur so gut sein wie derjenige der es benutzt.Shade Of Mine schrieb:
das ist das selbe wie wenn man mit einem staubsauger einen ballsaal sauber macht und der andere kommt mit einer zahnbuerste daher. natuerlich ist der staubsauger viel produktiver. er ist nicht unbedingt genauer und vielleicht auch nicht energiesparender aber er ist _schneller_.
Er ist vielleicht schneller "durch". Fertig ist er aber, wenn er keine Ahnung hat, nicht. Ein Beispiel von mir: mit vollem Müllbeutel saugen. Da ists nachher dreckiger als vorher
Der Typ mit der Zahnbürste wäre schneller gewesen.
-
aber wenn der typ schlau ist - checkt er vorher den beutel und startet dann den autopilot des saugers #gg
-
Hi,
die Größe und Anzahl der vorhandenen Libraries dürfte bei den heutigen Rechnergeschwindigkeiten keinen Einfluß mehr habe, daß ziehen die einfach so mit durch.
Die Möglichkeiten die die einzelnen Bibliotheken bieten haben aber schon Einfluß auf die Entwicklungsgeschwindigkeit, genau wie die verwendete Sprache.
Da ich seit langem blos noch mit Borland - heute CodeGear arbeite vergleiche ich mal Delphi (Object-Pascal) mit dem C++Builder. Bei kleineren und kleinsten Sachen bist Du mit Delphi vermutlich lange fertig, bevor Du in C++ zu Potte kommst. Die Sprache ist einfacher mit weniger Schreibaufwand. Durch die geringeren Möglichkeiten mußt Du viel weniger beachten. Andererseits gibts irgendwo eine Größe, wo Du vermutlich mit C++ wesentlich schneller bist. Die Möglichkeiten der stl, die insgesamt weiter gehenden Möglichkeiten der Sprache...
Sehr wesentlich ist aber vor allem welche Version man benutzt. Da liegen zwischen Delphi 1 und RAD 2007 ungeahnte Welten. Heute besteht doch Programmieren in einer modernen Entwicklungsumgebung im wesentlichen aus Wünsche andeuten und bestätigen wie schon Mr Evil schrieb. Wenn man eine alte Version hat, muß man noch alles mit der Hand tippen, und da wird aus jedem Tippfehler ein Fehler, vor allem in Sprachen wie C++ wo zwischen Groß- und Kleinschreibung unterschieden wird.
Beim Programmieren selbst haben eigene Tools heute nicht mehr die Bedeutung wie früher, die angebotenen Pakete sind da doch schon recht weit ausgereizt. Aber selbstgeschriebene bzw. selbst weiterentwickelte oder angepasste Komponenten haben in den CodeGear-Entwicklungsumgebungen immer noch ihre Daseinsberechtigung. Nicht umsonst ist das der wesentliche Unterschied zwischen der kostenlosen Turbo-Explorer-Variante und den Bezahlversionen.
Früher, als einen noch ein nackter Quelltexteditor und ein DOS vom Bildschirm her angeschaut haben war das noch anders. Damals hab ich mir, nach dem Vorbild eines Bekannten einen eigenen Maskengenerator programmiert, mit dem ich die vielen Masken für meine erste Abschlußarbeit au ca 20-30 auswählbaren eigenen Elementen im Dialog am Bildschirm zusammenschieben konnte. Da kam dann anschließend ein fast fertiger C-Quelltext raus, in den ich dann nur noch die entsprechenden Variablen eintragen musste. Gegenüber alles von Hand mit nacktem C zu programmieren war das schon eine Riesenhilfe. Aber heute ist das ja sogar bei kostenlosen Entwicklungsumgebungen mit dabei. Dafür sind heute die eigentlichen Aufgaben und Probleme die mit dem Computer gelöst werden wesentlich umfangreicher als damals.Gruß Mümmel
-
borg schrieb:
Wichtig ist die passendste Sprache mit dem passendstem framework für das Problem zu finden (und das ist imho in den allerseltensten fällen java).
und genau das ist eben ein teil der tools. eine sprache, eine lib, eine ide, ein compiler, eine paradigma, ein planungstool, etc - das sind alles die tools, die werkzeuge die man als programmierer hat.
und hört bitte auf mit vergleichen wo jemand zu dumm zum atmen ist. weil wenn jemand einfach ein kompletter total ausfall ist, dann ist eh alles egal dann muss man den nur schnell zur konkurrenz schicken alles andere ist nicht tragbar.
-
Ist die Programmiersprache dann nicht besser für die Aufgabe, wenn man mit weniger Tools die gleiche Geschwindigkeit erreicht?
In deinem Beispiel dürfte ein Python, Ruby, Scheme, Lisp, Perl, APL etc. Programmierer mit einem einfachen Texteditor schneller sein, als jemand mit einer wer weiß wie großen IDE, Refactoringtools, Sourcecodeverwaltung, UML-Planungstool, J2EE-Libraries und pipapo.
-
Shade Of Mine schrieb:
und hört bitte auf mit vergleichen wo jemand zu dumm zum atmen ist. weil wenn jemand einfach ein kompletter total ausfall ist, dann ist eh alles egal dann muss man den nur schnell zur konkurrenz schicken alles andere ist nicht tragbar.
Ich vermute mal, zumindest zum Teil, war es auch auf meinen Post bezogen.
Das Beispiel sollte lediglich aussagen nicht alles ist so einfach wie es scheint. Und mit "zu dumm" hat das wenig zu tun.
Ich denke jeder hatte schon mal beim Programmieren oder im Alltag ein Erlebnis, bei dem er sich hinterher gefragt hat, warum man da überhaupt etwas auf diese Art gemacht hat; später ist einem dann klar es war total dumm.Und mit Sicherheit wird es Situationen bzw. Leute geben die mit Assembler schneller, effektiver arbeiten als mit einer Hochsprache.
Es kommt drauf an *wer* *was* macht.
Vielleicht sagen wir beide das gleiche. Ich hatte nur in deinen Posts rausgelesen, dass ein bestimmtes Tool generell schlecht sei. Und das es im großen und ganzen fast nur auf die Tools ankommt.
Es gibt Leute die Programmieren schon seit Jahrzehnten prozedual. Die tun sich, nicht alle, aber viele, schwer mit der "Objekt-Welt". Nicht nur mit einer Programmiersprache, sondern auch mit entsprechenden neuen Tools.
-
rüdiger schrieb:
Ist die Programmiersprache dann nicht besser für die Aufgabe, wenn man mit weniger Tools die gleiche Geschwindigkeit erreicht?
eine sprache ist nur ein tool von vielen. die komplette tool kette muss passen.
c++ ist für eine server anwendung sicher erstmal gut geeignet, aber wenn mir auf der plattform zB ein debugger fehlt, dann ist man uU mit einer sprache die schlechter geeignet ist besser bedient, wenn diese eben zB gute debugger anbietet.
deshalb: eine sprache ist nur ein tool von vielen.
objective-c ist zB eine super idee wenn man eine anwendung unter mac os x entwickeln will - gutes cocoa bindung, viele resouren. wenn ich die anwendung aber unter windows entwickeln will ist .net uU besser geeignet. wobei .net vielleicht bei cross plattform systemen (mit mono) vermutlich wieder schlechter abschneidet.
deshalb: die sprache ist nicht alles. c# ist super unter windows, für linux anwendungen aber nicht unbedingt geeignet. das alleine zeigt schon, dass sprachen nicht das non plus ultra entscheidungskriterium ist - man muss alle verfügbaren tools bedenken.
die filemaker script sprache ist zB furchtbar. aber dennoch ist filemaker für viele situationen einfach die richtige wahl - eben weil die toolchain einen bestimmten bereich super abdeckt.
deshalb nochmal:
eine sprache ist ein tool.und es kommt auf die tools an wenn man annimmt dass die programmierer etwa gleichwertig sind.
oder mal ehrlich:
wird irgendjemand auf die idee kommen eine csv datei in eine sql datenbank per assembler und notepad zu integrieren oder werden wir lieber 5 zeilen ruby/python/php/... schreiben?
-
rüdiger schrieb:
In deinem Beispiel dürfte ein Python, Ruby, Scheme, Lisp, Perl, APL etc. Programmierer mit einem einfachen Texteditor schneller sein, als [...].
Dennoch wäre dein erstes Team produktiver würden Sie statt komplett nur mit z.B. nano oder Vergleichbarem doch vielleicht mit einem geeigneterem Editor, einem Versionskontrollsystem etc. arbeiten. Falls ich das Richtig gelesen habe hat Shade nur gesagt, das alle Tools sinnvoll gewählt werden sollten, nicht nur eines der verwendeten (die Sprache).
-
ihoernchen schrieb:
Das Wichtige ist die Kombination. Der Programmierer muss seine Tools kennen. Man kann nicht sagen Tool (Programmiersprache) A ist besser/schneller als B.
Da kann jemand ein komplexes Problem mit Assembler + Notepad vielleicht besser lösen, als jemand der Tools benutzt die er nicht oder kaum kennt.
Ein Tool kann auch nur so gut sein wie derjenige der es benutzt.Erinnert mich an VI, bei dem man erst 5 min das Handbuch durchlesen muss, nur um VI beenden zu koennen.
Aber hier ist wirlich eine eigenartige Diskussion. Wenn ich ein Bild aufhaengen will, dann nehme ich einen Hammer und einen Nagel. Wenn es eine Betonwand ist, ist der Hammer und Nagel aber sinnlos, hier sind Bohrer, Duebel und Schraube gefragt.
Wieso also die Diskussion ob man mit passenden Werkzeugen eine Aufgabe schneller erledigen kann als ohne?
Klar kann man in Assebler alles Programmieren was eine moderne Sprache wie C++, Java, Python, Ruby, etc. ausmacht. Aber in der Zeit in der du in Assebler Verberung, Polymorphie, usw. hinschreibst, habe ich inzwischen das Projekt abgeschlossen. Und wieso sollten diese 08/15 Dinge nicht vom Computer selbst uebernommen werden?
Deswegen haben wir doch Computer erfunden, sie sollen uns 08/15 Dinge abnehmen, damit wir an den richtigen Problemen arbeiten koennen. Somit abstrahieren wir immer weiter, bis die Informationsdichte in einer Codezeile maximal ist. Mit einer Maximierung der Informationsdichte pro Codezeile erreichen wir nunmal schnellere Entwicklungszeit und weniger Fehler.
Dabei unterstuetzt uns eine IDE noch weiter als die Sprache. Die IDE automatisiert das erstellen der Codezeile, warnt vor Fehlern, macht den Code noch mehr leserlich und ueberprueft den Code.
Mit einer IDE minimierst du den Aufwand eine Codezeile hinzuschreiben und du minimierst weiter die Fehleranfaelligkeit. Dies fuehrt zu einer weiteren Reduzierung der Entwicklungszeit und der Fehler im Projekt.