Archiv verlassen und diese Seite im Standarddesign anzeigen : Programmiersprache wanted
Svenne
2003-04-26, 09:49:51
Hallo,
ich habe mich einige Zeit mit C++ beschäftigt, aber bis ich da bin wo ich hin will, dauert es mir zu lange.
Irgendwie habe ich das Gefühl ich habe gar nicht sooo große Anforderungen an eine PS, das ich mich mit C++ abquälen muss.
Kann mir jemand einen Tip geben?
Hier der Steckbrief:
Grafik unter Windows (Fenster, später bischen mehr 2D Draws)
Leichte Verknüpfung von Tabellen, Listen, Textdateien... Datenbanktauglich etc.
Gute leicht verständliche Literatur (vor allem deutsch)
Gute Erweiterbarkeit des Quellcodes.
Günstige Entwicklungsumgebung. $$$
Ich habe mal (vor etlichen Jahren) Basic virtuos beherrscht. Das es heute nicht mehr so einfach sein kann, ist mit klar, aber es muss doch was zwischen Basic und C++ geben, oder?
bye
Svenne
TheGamer
2003-04-26, 09:59:47
Hey,
nimm doch Visual Basic
CU
Exxtreme
2003-04-26, 10:46:05
Hmmm, welche C++-Entwicklungsumgebung haste denn genutzt? Da gibt es nämlich auch mächtige Unterschiede, die grösser sein können als zwischen den Sprachen selbst.
Svenne
2003-04-26, 10:51:39
Originally posted by Exxtreme
Hmmm, welche C++-Entwicklungsumgebung haste denn genutzt? Da gibt es nämlich auch mächtige Unterschiede, die grösser sein können als zwischen den Sprachen selbst.
Borlands freien C++ compiler BCC55.
Und Ansi C++ geht mir zu sehr an dem vorbei, was ich machen möchte.
c'u
Svenne
Exxtreme
2003-04-26, 11:02:02
Originally posted by Svenne
Borlands freien C++ compiler BCC55.
Und Ansi C++ geht mir zu sehr an dem vorbei, was ich machen möchte.
c'u
Svenne
Hehe, das was du brauchst ist eine gute Entwicklungsumgebung. Da ist auch C++ nicht mehr so Low-Level. Aber vielleicht ist Visual Basic doch dann das bessere Tool... oder doch Delphi?
Hier mal ein Paar Versionen:
C++-Builder-Trial (http://www.borland.de/products/downloads/download_cbuilder.html)
Delphi-Trial (http://www.borland.de/products/downloads/download_delphi.html)
Delphi Personal-Edition (ftp://ftpd.borland.com/download/delphi/personal/BorlandDelphiPersonalEdition.exe)
Svenne
2003-04-26, 11:21:53
Originally posted by Exxtreme
Hehe, das was du brauchst ist eine gute Entwicklungsumgebung. Da ist auch C++ nicht mehr so Low-Level. Aber vielleicht ist Visual Basic doch dann das bessere Tool... oder doch Delphi?
Hier mal ein Paar Versionen:
C++-Builder-Trial (http://www.borland.de/products/downloads/download_cbuilder.html)
Delphi-Trial (http://www.borland.de/products/downloads/download_delphi.html)
Delphi Personal-Edition (ftp://ftpd.borland.com/download/delphi/personal/BorlandDelphiPersonalEdition.exe)
Ich hatte schon mal den Tip mich an Delphi zu halten bekommen, kannst du mir dazu was sagen? Was hat Delphi, was hat VB?
Danke für die urls
c'u
Svenne
Exxtreme
2003-04-26, 11:28:05
Die Frage ist schwierig zu beantworten. :)
VB ist objektorientiertes Basic während Delphi objektorientiertes Pascal ist... mehr oder weniger.
Ich kenne VB nicht deswegen kann ich leider nicht sagen ob's was taugt. Delphi taugt auf jeden Fall etwas... IMHO.
TheGamer
2003-04-26, 11:43:21
VB taugt mit Sicherheit auch was.
Zum Thema VB und die langsame Geschwindigkeit:
Mittlerweile ist VB sehr schnell geworden und kann ohne Problem mit C++ mithalten.
Darkstar
2003-04-26, 13:54:36
Originally posted by Svenne
Grafik unter Windows (Fenster, später bischen mehr 2D Draws)
Leichte Verknüpfung von Tabellen, Listen, Textdateien... Datenbanktauglich etc.
Gute leicht verständliche Literatur (vor allem deutsch)
Gute Erweiterbarkeit des Quellcodes.
Günstige Entwicklungsumgebung. $$$
Tja, mit dem letzten Punkt fällt Delphi wohl flach. Ich würde Dir Java (http://java.sun.com/) empfehlen (Syntax ist an C++ angelehnt). Legst Du großen Wert auf (2D-)Geschwindigkeit, dann wäre Eclipse (http://www.eclipse.org/) eine passende Entwicklungsumgebung, ansonsten ist NetBeans (http://www.netbeans.org/) sehr empfehlenswert.
Demirug
2003-04-26, 14:02:33
Für Leute die nur Windowsprogramme schreiben wollen und kein Geld haben empfehle ich gerne SharpDevelop http://www.icsharpcode.net/OpenSource/SD/Default.aspx als IDE.
Die Compiler (C# und VB.Net) dazu gibt es kostenlos von Microsoft.
Nasenbaer
2003-04-26, 17:11:36
Gerade für Einsteiger ist Delphi sehr gut geeignet. Erst recht, wenn man Datanbanken nutzen will. Der Quellcode ist zudem sehr ans Englische angelehnt und weniger kryptisch als in C/C++.
Als Buch könnte ich da "Jetzt lerne ich Delphi" vom Markt&Technik Verlag (http://www.mut.de) empfehlen. Das Buch ist wirklich gut und leicht verständlich geschrieben.
In der Personal Edition kostet Delphi7 um die 140€.
Mfg Nasenbaer
Exxtreme
2003-04-26, 19:35:58
Originally posted by Nasenbaer
In der Personal Edition kostet Delphi7 um die 140€.
Mfg Nasenbaer
Das Teil kann man sich auch kostenlos und legal ziehen. Einfach meinen Links folgen. :)
zeckensack
2003-04-26, 19:46:08
Auf die Gefahr hin, mich unbeliebt zu machen, aber VB kann man wohl für ernsthafte Programmierung vergessen.
Dieses dreiste Urteil ist umso dreister, weil ich selbst noch nie VB benutzt habe. Das leite ich ich einzig und allein aus Forenbeiträgen von VB-Nutzern ab, weil dort teilweise haarsträubende Probleme dieser Sprache zu erkennen waren.
Demirug
2003-04-26, 19:48:56
Originally posted by zeckensack
Auf die Gefahr hin, mich unbeliebt zu machen, aber VB kann man wohl für ernsthafte Programmierung vergessen.
Dieses dreiste Urteil ist umso dreister, weil ich selbst noch nie VB benutzt habe. Das leite ich ich einzig und allein aus Forenbeiträgen von VB-Nutzern ab, weil dort teilweise haarsträubende Probleme dieser Sprache zu erkennen waren.
VB.Net ist um einiges besser geworden als der Vorgänger. Ernsthaft benutzen würde ich es aber auch nicht. Das hängt aber eher damit zusammen das ich mit Basic auf dem VC20 und C64/128 programmiert habe und deswegen davon kurriert bin.
TheGamer
2003-04-26, 20:04:06
Ich würde ja auch nie mehr VB coden, habs ihm aber vorgeschlagen da er ja was einfaches wollte.
Exxtreme
2003-04-26, 20:14:51
Originally posted by zeckensack
Das leite ich ich einzig und allein aus Forenbeiträgen von VB-Nutzern ab, weil dort teilweise haarsträubende Probleme dieser Sprache zu erkennen waren.
HAste mal einige URLs?
stabilo_boss13
2003-04-26, 20:25:47
Originally posted by zeckensack
Auf die Gefahr hin, mich unbeliebt zu machen, aber VB kann man wohl für ernsthafte Programmierung vergessen.Naja, man kann schon richtige Programme schreiben.
Hier mal auf die Schnelle ein paar Beispiele:
http://www.technologismiki.com/hackman/
http://www.zada.com.au/worldclock.htm
http://w1.737.telia.com/~u73702956/download.htm
http://www.mbsn.com/mbsn/mp3page.html
http://www.geocities.com/edgemeal_software/
http://www.grafxfreeware.homestead.com/karensfontexplorer.html
Im Normalfall ist es aber einer Software nicht anzusehen, dass sie mit Visual Basic geschrieben ist. Wenn man aber auf http://www.planetsourcecode.com/ vorbeischaut und die lines-Zahlen vergleicht, müsste eigentlich die Hälfte aller Programme auf der Welt in VB geschrieben sein.
Das leite ich ich einzig und allein aus Forenbeiträgen von VB-Nutzern ab, weil dort teilweise haarsträubende Probleme dieser Sprache zu erkennen waren.Liegt vielleicht daran, dass viele Anfänger diese Sprache benutzen und von Softwareentwicklung eigentlich keine Ahnung haben.
Ich selbst schreibe häufig Messsysteme. Die Echtzeit abhängigen Routinen schreibe ich in C. Aber alles an Masken, Datenbankanbindung, Drucken usw. wird rapid mit VB developt.
zeckensack
2003-04-26, 20:32:41
Originally posted by Exxtreme
HAste mal einige URLs?
Keine echten Zeigertypen (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/000935.html)
Keine Callbacks ohne Wadenkrampf (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/001158.html) (wie auch, ohne echte Zeigertypen)
Bekloppte Deklarationssyntax (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007152.html) (da sagt jemand, er hat zwei Tage gebraucht, um eine simple Call by Value-Funktion benutzen zu können)
Bekloppte Schleifensyntax (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=60995)
Nur um mal ein paar Sachen zu nehmen :D
stabilo_boss13
2003-04-26, 20:47:18
Originally posted by zeckensack
Keine echten Zeigertypen (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/000935.html)
Keine Callbacks ohne Wadenkrampf (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/001158.html) (wie auch, ohne echte Zeigertypen)
Bekloppte Deklarationssyntax (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/007152.html) (da sagt jemand, er hat zwei Tage gebraucht, um eine simple Call by Value-Funktion benutzen zu können)
Bekloppte Schleifensyntax (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=60995)
Nur um mal ein paar Sachen zu nehmen :D Also das mit der Schleifensyntax verstehe ich nicht. Ist doch nur Syntax. Reine Lernsache. Imo bei jeder Sprache irgendwie bekloppt.
Bei den anderen Sachen hast du natürlich völlig recht. Aber ich glaube, dafür ist VB auch gar nicht gedacht. Und warum sollte sich jemand, der sich mit Callbacks und Zeigertypen auskennt, VB benutzen?
Die Sprache wurde doch extra dafür geschaffen, sich nicht mit so was auseinander setzen zu müssen.
Und wer OpenGL oder DirectX benutzen will, sollte die Finger von VB lassen. Aber es gibt halt immer wieder Leute die glauben, dass sie mit VB-Schulkenntnissen so eben mal schnell Unreal 3 auf die Beine stellen könnten.
Das oben Gesagte gilt übrigens für Delphi genauso.
Richtige Entwickler programmieren sowieso ganz anders:
copy con unreal3.exe :D
zeckensack
2003-04-26, 21:20:43
Originally posted by stabilo_boss13
Also das mit der Schleifensyntax verstehe ich nicht. Ist doch nur Syntax. Reine Lernsache. Imo bei jeder Sprache irgendwie bekloppt.Ich lobe mir in C/C++, daß jedes Statement durch einen {}-Block ersetzt werden kann.
Ich kann mit // aus jeder beliebigen Schleife einen 'one shot' machen, das gleiche kann ich mit ifs und elses, und mehrfach verschachtelten if/elses. Schau mal hier:
// if (cpu.got_3dnow()) memcpy(VCs,AMD_VCs,19*sizeof(vertex_converter_fp));
// else
/* if (cpu.got_SSE()) memcpy(VCs,SSE_VCs,19*sizeof(vertex_converter_fp));
else */ memcpy(VCs,x86_VCs,19*sizeof(vertex_converter_fp));
Wenn der Code erstmal 'fertig' ist, dann macht's wohl keinen Unterschied, man kann aber viel schneller den Code entwickeln und testen, wenn nicht für jeden Fliegenschiß (sorry) Extra-Konstrukte gebraucht werden ("Exit Do", "End If", "End Sub", etc, ist in C alles "}", bei einzelnen Statements garnichts).
Bei den anderen Sachen hast du natürlich völlig recht. Aber ich glaube, dafür ist VB auch gar nicht gedacht. Und warum sollte sich jemand, der sich mit Callbacks und Zeigertypen auskennt, VB benutzen?
Die Sprache wurde doch extra dafür geschaffen, sich nicht mit so was auseinander setzen zu müssen.
Und wer OpenGL oder DirectX benutzen will, sollte die Finger von VB lassen. Aber es gibt halt immer wieder Leute die glauben, dass sie mit VB-Schulkenntnissen so eben mal schnell Unreal 3 auf die Beine stellen könnten.
Um es mal mit maximaler Härte zu sagen:
Dann ist das Lernen dieser Sprache Zeitverschwendung.
Wenn eine Programmiersprache mehr Hindernisse aufstellt als sie beseitigt, dann brauche ich früher oder später eine andere, freiere. Dann ist der gesamte Einarbeitungsaufwand für die Katz, diese Zeit hätte ich bereits investieren können, um meine Fähigkeiten in der 'besseren' Sprache voranzutreiben.
Wer Programme 'zusammenklicken' will, der wird auch auf anderen Fronten bereits bestens bedient, MSVC, Borland C Builder (und auch Delphi und Dev Pascal) kommen mit mächtigen GUI-Editoren und erzeugen fast fertigen Code mit ein paar Mausklicks.
Das oben Gesagte gilt übrigens für Delphi genauso.Mit Delphi hatte ich kaum Kontakt, deswegen bin ich geneigt dir zu glauben ;)
Richtige Entwickler programmieren sowieso ganz anders:
copy con unreal3.exe :D Jaaaaa =)
Ich denke Programmierer sollten Kontroll-Freaks sein (die meisten die ich kenne sind es auch). Von diesem Gesichtspunkt aus ist der Vorschlag natürlich optimal :-)
Nasenbaer
2003-04-26, 22:21:44
Originally posted by stabilo_boss13
Das oben Gesagte gilt übrigens für Delphi genauso.
Ganz so extrem würde ich es mit Delphi nicht sehen.
Es gibt sogar ein größeres komerzielles Spiel, dass mit Delphi entwickelt wurde aber leider hab ich den Namen vergessen. War auch 2D.
Man sollte zwar keine 3D-Spiele damit proggen aber für Officeanwendungen etc. ist Delphi sehr gut.
Das gute an dieser Sprache ist, dass einem durch einfachen Syntax der Einstieg in die Thematik erleichtert wird. C++ ist für Anfänger sicher viel zu kryptisch.
Wenn man dann doch mehr will könnte man ja Borland C Builder nehmen.
Mfg Nasenbaer
Darkstar
2003-04-26, 23:30:28
Originally posted by Nasenbaer
In der Personal Edition kostet Delphi7 um die 140€.
Wie ich schon oben geschrieben habe: Der Preis ist das K.O.-Kriterium für Delphi.
Exxtreme
Das Teil kann man sich auch kostenlos und legal ziehen. Einfach meinen Links folgen.
Das scheint zumindest sinnvoller, als sich die aktuelle Version zu kaufen, da der Funktionsumfang in etwa gleich geblieben sein dürfte (Delphi6PE (http://www.borland.com/delphi/pdf/del6_feamatrix.pdf) – Delphi7PE (http://www.borland.com/delphi/pdf/del7_feamatrix.pdf)). Dabei sollte man aber berücksichtigen, daß die Lizenz der Personal Edition den Vertrieb von selbst erstellten Programmen nicht erlaubt. Außerdem fehlen der Personal Edition eine ganze Reihe sinnvoller Komponenten, was den Einsatzzweck nur auf das reine Kennenlernen und Ausprobieren beschränkt.
Mit Ausnahme dieser Einschränkungen ist Delphi aber eine sehr zu empfehlende Entwicklungsumgebung für Programmier-Anfänger. Perspektivisch gesehen, halte ich Java trotzdem für die bessere Wahl.
P. S.: Und 3D geht mit Delphi inzwischen auch recht ordentlich: http://www.delphi3d.net/
Exxtreme
2003-04-26, 23:43:45
Originally posted by Darkstar
Dabei sollte man aber berücksichtigen, daß die Lizenz der Personal Edition den Vertrieb von selbst erstellten Programmen nicht erlaubt. Außerdem fehlen der Personal Edition eine ganze Reihe sinnvoller Komponenten, was den Einsatzzweck nur auf das reine Kennenlernen und Ausprobieren beschränkt.
Man darf die Programme schon vertreiben, man darf sie aber nicht kommerziell vertreiben. :)
Also Freeware-Proggies sind erlaubt.
Und der Funktionsumfang der Personal-Edition ist für Anfänger vollkommen ausreichend. :)
Das rTool ist mit der Personal Edition des C++-Builders erstellt worden. :)
Svenne
2003-04-27, 07:14:21
Na ja,
ich werde mich mal näher mit Delphi befassen. Das Markt&Technik Buch schaue ich mir mal an.
thx
Svenne
Tom Servo
2003-04-27, 08:30:58
Originally posted by zeckensack
Wenn der Code erstmal 'fertig' ist, dann macht's wohl keinen Unterschied, man kann aber viel schneller den Code entwickeln und testen, wenn nicht für jeden Fliegenschiß (sorry) Extra-Konstrukte gebraucht werden ("Exit Do", "End If", "End Sub", etc, ist in C alles "}", bei einzelnen Statements garnichts).
Also if ... fi und case ... esac kenne ich auch von sh.
Ein Vorteil davon ist, dass der Parser verständliche Fehlermeldungen erzeugen kann. In C folgt dem "if" eben ein ganz normaler {}-Block, der genauso für Schleifen und Funktionen benutzt wird. Ein Fehlendes '}' wird vom Compiler zwar erkannt, aber die Fehlermeldung ist für Anfänger unverständlich.
int g(void);
int f()
{
if (1) {
g();
}
int g()
{
}
gcc test5.c
test5.c: In function `f':
test5.c:16: parse error at end of input
micki
2003-04-27, 12:29:32
http://www.profan.de/
die sprache trift auf deine anforderungen
"
Grafik unter Windows (Fenster, später bischen mehr 2D Draws)
Leichte Verknüpfung von Tabellen, Listen, Textdateien... Datenbanktauglich etc.
Gute leicht verständliche Literatur (vor allem deutsch)
Gute Erweiterbarkeit des Quellcodes.
Günstige Entwicklungsumgebung.
"
zu, und ich hab damit des öfteren schnell mal eben prototypen von programmen gecodet, superschnell ist die sprache nicht, aber für deine anforderungen sollte es reichen.
MfG
micki
Auf Smalltalk passen auch alle deine Forderungen. Smalltalk hat dazu noch den Vorteil, dass du anhand dieser Sprache sehr gut objektorientiertes Programmieren lernst. Fast alle Konzepte der meisten oo-PS kommen von Smalltalk und nähern sich diesem immer mehr an. (VM, Klasse object, Metaprogrammierung, GC, vollständig reflektiv, Container)
Es gäbe hier soviel über das Thema zu sagen, z.B. dass ein typisches Programm (10000 Zeilen C++-Code) mit ca. 3000 Zeilen Smalltalk zu bewältigen ist. Oder dass die Ausführungsgeschwindigkeit von Smalltalk Java in den Schatten stellt, einfach deswegen, weil die Sprache an sich unkompliziert ist und mit nur wenigen Konstrukten auskommt. (Außerdem hatte der Garbage-Collector fast 30 Jahre Zeit zu reifen)
Die Sprache an sich hat man in ein paar Stunden komplett verstanden, die vollständige Referenz passt auf eine A4-Seite. Die wirkliche Mächtigkeit der Sprache kommt durch ihre Klassenbibliothek, welche in Größe und Benutzbarkeit wohl eine Art Referenz für andere Sprachen darstellt. Ob Windowsprogrammierung oder Web-Services etc, für nahezu alles gibt es Klassen. (auch sind C- und COM-Schnittstellen keine Seltenheit, sodas alter Code wiederverwendet werden kann und sogar OpenGL und DirectX sind möglich)
Sicherlich hat die Sprache auch Nachteile:
- es gibt keinen neueren Sprach-Standard, so dass es viele verschiedene Implementierungen gibt, die leicht anders aufgebaut sind und für die Portierungen des Codes (auf einen anderen ST-Slang und nicht auf eine andere Plattform) Anpassungen verlangen
- nicht so schnell wie C++ wegen VM und GC (aber immer schneller als Java oder C#) - die große Stärke von ST ist der virtuelle Methodenaufruf (das sogar schneller als C++), wenn man also Polymorphie sehr oft anwendet, kann man diesen Nachteil wieder etwas ausbügeln
- Smalltalk ist "anders", in jeder Beziehung. Heute und schon vor 30 Jahren seiner Zeit voraus (wie gesagt, andere Sprachen nähern sich ST immer mehr an, imo dauert es noch ein paar Jährchen, ehe sich ST oder eine ähnliche Sprache richtig durchsetzen kann - und wird), wobei sich ST heute schon in sicherheitskritischen Bereichen bereits durchsetzt (Banken- und Versicherungssektor)
- für jedes Problem gibt es ein Werkzeug (passende Sprache), ST ist wie jede andere Sprache auch nur ein Werkzeug eines guten Programmierers, der weiß, wann er welches einsetzen sollte
Fazit: Lerne so viele Sprachen wie möglich; und lerne Smalltalk! ;) allzu viel Zeit kostet das nicht (ungefähr 637x weniger als das Lernen von C++)
über Smalltalk: (Tutorials, Referenzen, Environments, ...)
www.goodstart.com
www.whysmalltalk.com
beliebte (und kostenlose) entwicklungsumgebungen:
www.cincom.com/smalltalk (VisualWorks - alles was das Herz begehrt, wenn auch etwas mehr Einarbeitungszeit in die Umgebung nötig - plattformunabhängig)
www.object-arts.com (Dolphin Smalltalk - speziell für Windowsprogramme mit sehr schönem View-Konzept)
http://squeak.org/ (Squeak - von einem Smalltalk-Erfinder entwickelt - speziell für Multimedia-Programme)
Demirug
2003-04-27, 16:26:42
KiBa, Smalltalk ist ganz nett aber bei bestimmten Sätzen gehen bei mir immer die Warnlampen an.
"nicht so schnell wie C++ wegen VM und GC (aber immer schneller als Java oder C#)"
eine gewagte Aussage bei der vielzahl von Smalltalkumgebungen. Oder auf was bezog sich das "Schneller"
-die große Stärke von ST ist der virtuelle Methodenaufruf (das sogar schneller als C++), wenn man also Polymorphie sehr oft anwendet, kann man diesen Nachteil wieder etwas ausbügeln
Das will ich sehen. ;) Das Verfahren das die meisten C++ Compiler für virtuelle Methodeaufrufe benutzen ist eigentlich nicht zu überbieten. Aber ich lasse mich gerne überzeugen das es noch einen schnelleren Weg gibt.
Svenne
2003-04-27, 17:18:06
Originally posted by micki
http://www.profan.de/
die sprache trift auf deine anforderungen
...
zu, und ich hab damit des öfteren schnell mal eben prototypen von programmen gecodet, superschnell ist die sprache nicht, aber für deine anforderungen sollte es reichen.
MfG
micki
Danke habe ich mir angesehen und runtergeladen werde ich mir demnächst mal in Ruhe ansehen.
C'Ya
Svenne
Originally posted by Demirug
KiBa, Smalltalk ist ganz nett aber bei bestimmten Sätzen gehen bei mir immer die Warnlampen an.
"nicht so schnell wie C++ wegen VM und GC (aber immer schneller als Java oder C#)"
eine gewagte Aussage bei der vielzahl von Smalltalkumgebungen. Oder auf was bezog sich das "Schneller"
Ok, ich formulier das mal anders: die _meisten_ Implementierungen der _meisten_ Problemlösungen mit Hilfe der _meisten_ Smalltalkumgebungen sind _meistens_ schneller als ihr Java- oder C#-Gegenstück... ;)
Dass es vielleicht akademische beispiele gibt, wo nun gerade Java schneller ist, kann ja gut sein... und die Geforce4 ist auch 7x schneller als die Geforce3... ich hoffe du verstehst was ich meine.
-die große Stärke von ST ist der virtuelle Methodenaufruf (das sogar schneller als C++), wenn man also Polymorphie sehr oft anwendet, kann man diesen Nachteil wieder etwas ausbügeln
Das will ich sehen. ;) Das Verfahren das die meisten C++ Compiler für virtuelle Methodeaufrufe benutzen ist eigentlich nicht zu überbieten. Aber ich lasse mich gerne überzeugen das es noch einen schnelleren Weg gibt.
Da hab ich mich wohl (wieder) etwas unglücklich ausgedrückt, da man die virtuellen Methodenaufrufe von C++ garnicht richtig mit Smalltalk vergleichen kann. in C++ wird bei einfacher Vererbung meist folgendes bei einem virtuellen Methodenaufruf gemacht:
- Zugriff auf Funktionstabelle
- Indexzugriff auf die Methode
- Methodenansprung
zusätzlich kommt noch ein Runtime-Overhead für die Objektgenerierung und -Initialisierung mit dem Funktionstabellenverweis hinzu.
Smalltalk hat virtuelle Methodenaufrufe genau genommen garnicht. Es wird keine Vtable angelegt oder sowas, keine Dereferenzierung etc vorgenommen beim Aufruf. die Methode wird direkt durch einen Indexzugriff angesprungen, einzig allein der Name der Methode ist entscheidend. (das Vererbungsprinzip unterscheidet sich hier sehr von C++)
Originally posted by Svenne
Kann mir jemand einen Tip geben?
Hier der Steckbrief:
Grafik unter Windows (Fenster, später bischen mehr 2D Draws)
Leichte Verknüpfung von Tabellen, Listen, Textdateien... Datenbanktauglich etc.
Gute leicht verständliche Literatur (vor allem deutsch)
Gute Erweiterbarkeit des Quellcodes.
Günstige Entwicklungsumgebung. $$$
Aus meiner eigenen Erfahrung kann ich 4 Sprachen nennen, die hier passen könnten: C#, Java, Delphi und VB.net
Sie alle haben eine umfangreiche Klassenbibliothek, wobei C# und VB.net auf dem .NET Framework basieren und deswegen auch gut miteinander harmonieren. Deswegen braucht man aber auch die .NET Runtime. Delphi braucht kein Runtime Environment, bei Java besteht zumindest die Möglichkeit darauf zu verzichten. Ansonsten ist auf vielen Rechnern aber schon eine Java VM installiert (Dank Microsofts Verzicht auf Java ist diese Tendenz aber abnehmend)
Welche Klassenbibliothek die bessere ist mag ich so jetzt nicht bewerten, weil ich die von Java (noch) kaum kenne.
C# und Java sind syntaktisch an C++ angelehnt, die IMO beste Variante. Wobei ich C# ein bisschen besser finde. Delphi ist Object Pascal, VB.net ein stark erweitertes BASIC. Beides finde ich umständlich. Möglicherweise besser für Einsteiger geeignet, aber da du ja schon ein bisschen mit C++ umgehen kannst, solltest du eher bei dieser Syntax bleiben.
Für alle vier gibt es kostenlose (und gute) Entwicklungsumgebungen, bei Delphi eben eingeschränkt durch die PE-Lizenz. Ich arbeite aber trotzdem am liebsten mit VS.net ;)
C# ist noch jung, deswegen gibt es da wohl etwas weniger Literatur. Ansonsten würde ich von den vieren allerdings C# empfehlen, das IMO "bessere Java".
Aber Smalltalk werde ich mir auch mal anschauen ;)
Demirug
2003-04-28, 18:28:00
Nachdem wir hier ja jetzt bei smalltalk gelandet sind habe ich meine alten Sachen dazu mal wieder rausgeholt. Und dann war mir auch relative schnell wieder klar warum ich die Sache damals ganz schnell wieder weg gelegt habe.
Das Prinzip des dynamischen Bindens war noch nie mein Fall. Da ist mir die Gefahr von unendeckten Fehlern einfach zu hoch.
Originally posted by Demirug
Nachdem wir hier ja jetzt bei smalltalk gelandet sind habe ich meine alten Sachen dazu mal wieder rausgeholt. Und dann war mir auch relative schnell wieder klar warum ich die Sache damals ganz schnell wieder weg gelegt habe.
Das Prinzip des dynamischen Bindens war noch nie mein Fall. Da ist mir die Gefahr von unendeckten Fehlern einfach zu hoch.
genau das ist aber die große stärke der sprache, auch wenn das für einen c++-gewöhnten programmierer unglaubhaft wirkt.
wie hat die ct letztens geschrieben: "der smalltalk programmierer arbeitet immer am offenen herzen" - das kommt der schnelligkeit zugute, mit der man programme entwickeln kann und ist perfekt für methoden wie extreme programming. mit den ausgereiften refactoring-tools und dem komplett dynamischen programmieren (sogar während des debuggens) macht diesen "nachteil" zu einem riesen vorteil.
edit: außerdem schätze ich imo die gefahr bei statischen (zur compile-zeit typgeprüften) sprachen wie c++, ein "unschönes" und kompliziertes design anwenden zu müssen, größer ein, als das dynamische binden bei st. solche designfehler machen sich später viel mehr bemerkbar und kosten meist richtig geld... bestes beispiel in st: es ist überhaupt kein problem, objekte beliebigen typs in einen container zu stecken. in c++ müssen alle objekte eine basisklasse haben, was den codeumfang dazu explodieren lässt und absolut schwer zu verstehen und zu warten ist...
Demirug
2003-04-28, 19:35:09
Originally posted by KiBa
genau das ist aber die große stärke der sprache, auch wenn das für einen c++-gewöhnten programmierer unglaubhaft wirkt.
wie hat die ct letztens geschrieben: "der smalltalk programmierer arbeitet immer am offenen herzen" - das kommt der schnelligkeit zugute, mit der man programme entwickeln kann und ist perfekt für methoden wie extreme programming. mit den ausgereiften refactoring-tools und dem komplett dynamischen programmieren (sogar während des debuggens) macht diesen "nachteil" zu einem riesen vorteil.
und wenn der Arzt bei einer OP am offenen Herzen mist baut heist es Patient tot. Da hat die ct wohl einen schlechten vergleich gewählt.
Wie gesagt ich bevorzuge Systeme die schon vor der Laufzeit so viele Fehlerquellen wie möglich ausschliessen. Es gibt nicht ärgerliches als wenn ein Codepfad der nur in Ausnahmesituationen durchlaufen wird wegen einem einfachen Tipfehler (falscher name) nach hunterten von Stunden laufzeit einen Walkback produziert.
edit: außerdem schätze ich imo die gefahr bei statischen (zur compile-zeit typgeprüften) sprachen wie c++, ein "unschönes" und kompliziertes design anwenden zu müssen, größer ein, als das dynamische binden bei st. solche designfehler machen sich später viel mehr bemerkbar und kosten meist richtig geld...
Designfehler kann man in jeder sprache produzieren. Vorallem da OOA und OOD eigentlich unabhängig von der programmiersprache gemacht werden sollte
bestes beispiel in st: es ist überhaupt kein problem, objekte beliebigen typs in einen container zu stecken. in c++ müssen alle objekte eine basisklasse haben, was den codeumfang dazu explodieren lässt und absolut schwer zu verstehen und zu warten ist...
wieso??? das geht doch ganz einfach.
1. Interfaceklasse mit den benötigen Funktionen
2. Die container speichern die objekte über die Interfaceklasse.
3. Jedes Klasse die in dieser Collection gespeichert werden soll implemtiert das interface
Der zusätzliche Code besteht im wesentlichen nur aus der definition der Interfaceklasse.
oder man nimmt gleich "everything really everything is an object" C#
Originally posted by Demirug
und wenn der Arzt bei einer OP am offenen Herzen mist baut heist es Patient tot. Da hat die ct wohl einen schlechten vergleich gewählt.
der vergleich stimmt haargenau, den ohne den brustkorb zu öffnen kann der arzt nicht richtig operieren und der patient müsste weiter mit seinem herzfehler leben... ;)
außerdem kann man im falle eines fehlers sehr gut eine reanimation vornehmen, ohne der in c++ typischen - fehler finden - fehler beseitigen - neukompilieren - stelle testen - odysee...
Wie gesagt ich bevorzuge Systeme die schon vor der Laufzeit so viele Fehlerquellen wie möglich ausschliessen. Es gibt nicht ärgerliches als wenn ein Codepfad der nur in Ausnahmesituationen durchlaufen wird wegen einem einfachen Tipfehler (falscher name) nach hunterten von Stunden laufzeit einen Walkback produziert.
du hast dich noch nicht ausreichend mit st beschäftigt! gerade solche fehler kommen in st-code (nachweislich) kaum vor, da der code vom umfang erheblich geringer ist und die entwickler quasi im debugger entwickeln. parallel dazu werden test-cases geschrieben, welche die richtigkeit des codes viel besser überprüfen können, als jemals ein compiler mit typüberprüfung könnte. die vorgehensweise beim programmieren unterscheidet sich dabei deutlich von c++.
es sollte dir auch zu denken geben, dass gerade in sicherheitskritischen anwendungen (überwachungs-, bank- und versicherungssysteme) smalltalk sich schon lange durchgesetzt hat.
in st macht man die meisten fehler, wie sie in c++-projekten gleicher art vorkommen, einfach kaum, teilweise weil solche fehler garnicht möglich sind.
Designfehler kann man in jeder sprache produzieren. Vorallem da OOA und OOD eigentlich unabhängig von der programmiersprache gemacht werden sollte
das ist jetzt aber blödsinn. die wahl der sprache hat einen sehr großen einfluß darauf, und es sollte auch nicht anders sein. (manche sprachen bieten z.b. metaprogrammierung, einige andere mehrfachvererbung, etc, was sich zwar nicht so stark im OOA, dafür aber im OOD bemerkbar macht)
Dies ist auch ein grund, warum man st eine "reine" oo-sprache nennt, ein klassendesign unterscheidet sich oft von einem für c++-entworfenem, und die modellierung kann viel besser die realität und das gewollte wiederspiegeln. deshalb ist ein design für st meist viel einfacher, ergo mit weniger fehlern verbunden. und ein design später zu ändern ist das a und o in solchen sprachen wie smalltalk, das ist nicht nur gewünscht, sondern gewollt. (stichwort refactoring - xp) in c++ reißt man sich dabei öfters ein bein aus... ;)
wieso??? das geht doch ganz einfach.
1. Interfaceklasse mit den benötigen Funktionen
2. Die container speichern die objekte über die Interfaceklasse.
3. Jedes Klasse die in dieser Collection gespeichert werden soll implemtiert das interface
Der zusätzliche Code besteht im wesentlichen nur aus der definition der Interfaceklasse.
das schafft eine statische abhängigkeit zur interface-klasse, sowas sollte man aber möglichst verhindern, und dafür objektkomposition einsetzen. (siehe design patterns) es mag je einfach sein, so etwas wie oben beschrieben in der ersten designphase zu machen, in der zweiten oder n-ten hat man dann aber das problem, dass man an x stellen im code anpassen muss, was natürlich wieder fehler heraufbeschwört.
ich verlang ja nicht, dass jetzt die ganze welt snalltalk einsetzen soll (ich selbst programmiere hauptsächlich in c++), aber man kann sich mal mit den prinzipien von anderen sprachen beschäftigen. dann fällt einem einiges leichter, auch wenn man sich entscheidet, die alten methoden weiter anzuwenden.
der thread-starter suchte übrigens ne einfache sprache zum einstieg, und da ist imo st perfekt. man kann sich ganz auf die konzepte der oo-programmierung konzentrieren. (so ähnlich wie bei pascal für die prozedurale programmierung, das wird heute noch gelehrt, obwohl es praktisch kaum genutzt wird)
Demirug
2003-04-28, 23:59:42
KiBa, ja meine Erfahrungen bezüglich st sind eher theoretischer natur mit minimalen codeeinsatz.
Das Entwicklungsverfahren das du beschreibst erinnert mich stark an XP. I will dir jetzt mal glauben das die von mir gefürchteten Typefehler in der Praxsis nicht auftreten. Gerade das mit den Testcases hat bei uns aber total versagt. Aber wir haben auch mit einer etwas ausgewöhlichen Problemstellung zu kämpfen.
wobei eine Frage hätte ich da durchaus noch. Wie realisiert man mit st eigentliche Plug-In Technik? Ich habe mir das ehrlich gesagt noch nicht selber angeschaut aber möglicherweise hats du ja schon mal sowas gemacht.
Originally posted by Demirug
Das Entwicklungsverfahren das du beschreibst erinnert mich stark an XP.
ist es auch, xp wurde mit smalltalk entwickelt...
I will dir jetzt mal glauben das die von mir gefürchteten Typefehler in der Praxsis nicht auftreten. Gerade das mit den Testcases hat bei uns aber total versagt. Aber wir haben auch mit einer etwas ausgewöhlichen Problemstellung zu kämpfen.
in c++ benutze ich auch kaum testfälle, weils einfach zu umständlich und langwierig mit dem compilieren ist. (und der code für die tests ist meist auch ziemlich groß und häßlich)
mit st geht sowas schon viel einfacher, erfordert sicher aber auch etwas übung, wie das programmieren an sich.
wobei eine Frage hätte ich da durchaus noch. Wie realisiert man mit st eigentliche Plug-In Technik? Ich habe mir das ehrlich gesagt noch nicht selber angeschaut aber möglicherweise hats du ja schon mal sowas gemacht.
plugin-technicken hab ich noch nicht benutzt. ich kann mir aber denken, dass es in smalltalk ne menge ansätze dazu gibt. das einfachste wären textfiles mit quellcode, die beim laden compiliert werden (compiler ist in st wie alles andere auch ein objekt, mit dem man arbeiten kann). in visual works kann man auch sogenannte parcels laden (ähnlich wie dlls), dass sind files mit vorkompiliertem "bytecode", welche man mit einem vw-objekt dem image hinzufügen kann. das ganze ist dann natürlich plattformunabhängig und funktioniert ohne einschränkungen. (vererbung etc)
dann gibt es da noch packages, welche das projekt besser strukturieren, ka wie genau...
edit:
da die meisten st-environments unter windows c- und com-schnittstellen verwenden können, wäre das sicher auch noch ne möglichkeit. (und ist nicht an smalltalk gebunden)
x-dragon
2003-04-29, 14:09:56
Originally posted by Nasenbaer Ganz so extrem würde ich es mit Delphi nicht sehen.
Es gibt sogar ein größeres komerzielles Spiel, dass mit Delphi entwickelt wurde aber leider hab ich den Namen vergessen. War auch 2D.
... Die bekanntesten die mir einfallen sind z.B. Age of Wonders 1 & 2 und Siege Of Avalon.
Quake 1 und 2 wurde unteranderem mit Delphi nachprogrammiert, gibts auch als Open-Source, falls jemand interesse hat:
http://sourceforge.net/projects/quake2delphi/
vBulletin®, Copyright ©2000-2025, Jelsoft Enterprises Ltd.