Jetz mach ich das was ich vor fast 20 Jahren auch mal gemacht habe, als ich konträr zur C64 Welt meine ersten BASIC-Programme auf nem SHARP-Rechner schrieb.......... Schneller als C/C++ und 100-500 x kleinerer Code!!!! "Hello World" in einem Grafikfenster kostet 3,5 Kb wärend VisualBasic dafür mit 1,6 Megabyte zuschlägt!!! Es werden kaum fremde DLL's benutzt! Bibliotheken anderer Sprachen können eingebunden werden. Läuft auf: Amiga, Windos (32 Bit) Linux (32 Bit) MacOS-X (32 Bit) Was fehlt ist noch die 64 Bit Variante, doch was bei Siemens-Fujitzu, und dem Max-Plank-Institut, als auch bei einigen Banken und Versicherungen für Furore sorgte, dürfte auch für Euch reichen. Meine negative Meinung über aufgeblasene OOP-Sprachen hat sich hier also in der Realität bestätigt!!!!! Ich hab mir mal ein paar Code-Beispiele angesehen, und sage nur es ist gradezu lächerlich ein Meü zu bauen, man braucht dafür keinen Designer der Unmengen an Code generiert. Und jetzt muss Dimpel-Ing oder Dimpel-Inf nur noch eines machen: Seine mathematischen Kenntnisse als Waffe benutzen, damit könnt ihr die Skriptkiddys zum Teufel jagen, die euch das Brot streitig machen wollen! Vorhang auf für "Back to the Future": http://www.purebasic.de/was.shtml Theo
@Thomas Warum nicht wieder ? Das Teil ist doch ne feine Sache, sieh es dir erstmal genauer an! @Rahul Das ist nur in der freien download Version so. Man kann auch die C bestellen, da ist das Handbuch dann gedruckt dabei. Kostet aber dann 99,- Euro. Jedenfalls ist das ein klasse Ansatz dendie Jungs da hingelegt haben. Theo
> Und ein Tutorial als .exe Datei - was will man mehr...
Hehe, in der Tat.
Was viele nicht wissen ist dass Purebasic in Purebasic programmiert wurde, desswegen ist das so schnell. Und jedesmal wenn man den Purebasic Compiler nochmal mit sich kompiliert wird er noch kleiner UND schneller! WER DAS NICHT GLAUBT SOLL ES DOCH SELBER MAL AUSPROBIEREN! Wenn die exe Datei erstmal klein genug geworden ist, ist der Compiliervorgang nicht mehr zu stoppen! Und wird dadurch immer schneller, jeder kann sich vorstellen welche Mengen an Energie dabei freigesetzt wird. Ein Glück dass der Iran und Nordkorea sich nur mit Atomwaffen beschäftigen, wenn denen Purebasic in die Hände fällt...
> Jetz mach ich das was ich vor fast 20 Jahren auch mal gemacht habe, als > ich konträr zur C64 Welt meine ersten BASIC-Programme auf nem > SHARP-Rechner schrieb.......... Kommt mir bis hier hin noch bekannt vor... > Schneller als C/C++ und 100-500 x kleinerer Code!!!! Kann eigentlich nur Assembler sein... > "Hello World" in einem Grafikfenster kostet 3,5 Kb wärend VisualBasic > dafür mit 1,6 Megabyte zuschlägt!!! Maschiensprache bietet zwar nicht mehr den Faktor ~450, aber immer noch drastisch weniger als VB. > Es werden kaum fremde DLL's benutzt! > Bibliotheken anderer Sprachen können eingebunden werden. Das gilt für so ziemlich alle aktuellen "großen" Sprachen. > Läuft auf: > Amiga, > Windos (32 Bit) > Linux (32 Bit) > MacOS-X (32 Bit) Kein wirklich "Großes" System, kein AIX, z/OS, VMS oder SunOS > Was fehlt ist noch die 64 Bit Variante, doch was bei Siemens-Fujitzu, > und dem Max-Plank-Institut, als auch bei einigen Banken und > Versicherungen für Furore sorgte, dürfte auch für Euch reichen. Wenn's bei Banken laufen soll, warum dann kein halbes OS. In dem Bereich werden entweder ausgereifte Sachen bevorzugt oder es wird die "reine Lehre" angewandt (sei es die von M$)... > Meine negative Meinung über aufgeblasene OOP-Sprachen hat sich hier also > in der Realität bestätigt!!!!! Die "reine Lehre" kennt nur 5 (fünf) reservierte Bezeichner... > Ich hab mir mal ein paar Code-Beispiele angesehen, und sage nur es ist > gradezu lächerlich ein Meü zu bauen, man braucht dafür keinen Designer > der Unmengen an Code generiert. > Und jetzt muss Dimpel-Ing oder Dimpel-Inf nur noch eines machen: > Seine mathematischen Kenntnisse als Waffe benutzen, damit könnt ihr die > Skriptkiddys zum Teufel jagen, die euch das Brot streitig machen wollen! Mathematische Kenntnisse helfen weder bei der Planung, noch bei der Implementierung, schon gar nicht wenn man neue Algorithmen braucht... > Vorhang auf für "Back to the Future": Genau...
>> Und jetzt muss Dimpel-Ing oder Dimpel-Inf nur noch eines machen: >> Seine mathematischen Kenntnisse als Waffe benutzen, damit könnt ihr die >> Skriptkiddys zum Teufel jagen, die euch das Brot streitig machen wollen! >Mathematische Kenntnisse helfen weder bei der Planung, noch bei der >Implementierung, schon gar nicht wenn man neue Algorithmen braucht... ---------------------------------------------------------------------- Spätestens bei einer passenden Problemstellung, denn ich habe nach dem Studium 1996 auch sofort keinen Job bekommen. Um aber in der Zeit an Kohle zu kommen, hab ich mir bei Control-Data nen Lehrgang besorgt, der vom Arbeitsamt finanziert wurde. Einerseits Zeitvertreib andererseits eben ALG-1. (damals ging das noch....seit 2002 nicht mehr) Als dann vorne ein Pauker referierte und Strukturen/Klassen in C/C++ einführen wollte, wählte er ein Beispiel mit komplexen Zahlen, weil er wusste das ich sowie 2 Ingenieure und eine russische Mathematikerin damit wohl keine Probleme hatten. Und genau da ging die Ausrasterei von den restlichen Ex-Zahnklempnern & Co die man auf die schnelle zum "Informatiker" umstylen wollte nämlich los......Chaos pur was ich garnicht verstehen konnte und mich eher amüsierte (Zahlen die nach deren Meinung offensichtlich Komplexe haben...:-) Und genau das war damit gemeint, denn diese reinen Chrashkurs-Herrschaften sind nämlich der Auffassung, das man mal eben ein paar Konstrukte zusammen kleistert und das wars dann. Das ein seriöses Softwareprojekt 60% Planung aus macht keine Spur und wenns dann noch an Trivialitäten wie den Grundrechenarten bei komplexen Zahlen scheitert gute Nacht. Die selbe Tragödie sah ich dann im SQL-Teil des Kurses, so nach dem Motto für sowas gibts ja Query by Example, scheiss-egal ob dabei nen riesiger overhead in der künstlich generierten Abfrage erzeugt wird! Ergo bringt gehobenes mathematisches Denkvermögen mehr als zuerst gedacht, nicht zuletzt weil es ja grade in div. Kreisen als Chic gilt, davon keine Ahnung zu haben.....und die Ex-Zahnklempner eigendlich nur da rein gelotst wurden um sie aus der AL-Statistik raus zu lügen......... Theo
>Mathematische Kenntnisse helfen weder bei der Planung, noch bei der >Implementierung, schon gar nicht wenn man neue Algorithmen braucht... Hätte vllt etwas anders formuliert werden sollen. Gemeint war vielmehr, dass theoretisches Wissen (in Maßen) zwar eine notwendige Grundlage ist, dies aber bei weitem nicht fehlende Kreativität, Erfahrung, Neugier oder auch Offenheit für neue/andersartige Ansätze ausgleicht.
In 3.5kB kann man mit den richtigen Compiler/Linker-Settings in VC++6.0 problemlos ein kleines OpenGl-Fenster aufmachen und sogar was 3D-iges darin animieren.Ein einfaches "Hallo Welt!" (für Win32,wohlgemerkt) ist dann mit etwas über 2kb drin.Und was die Geschwindigkeit angeht,ist pures Assembler wohl nur von hochgezüchteten Compilern zu schlagen,und die gibt es grossteils für C.
>>Mathematische >>Kenntnisse helfen weder bei der Planung, noch bei der >>Implementierung, schon gar nicht wenn man neue Algorithmen braucht... >Hätte vllt etwas anders formuliert werden sollen. >Gemeint war vielmehr, dass theoretisches Wissen (in Maßen) zwar eine >notwendige Grundlage ist, dies aber bei weitem nicht fehlende >Kreativität, Erfahrung, Neugier oder auch Offenheit für >neue/andersartige Ansätze ausgleicht. Sie führen aber zu einem funktionsfähigen Programm. Zumindest wenn mathematisch auch informatisch einbezieht. Über die Schönheit des Programmes läßt sich dann immer noch streiten. Das Einzige was diese Kenntnisse ansatzweise aufwiegen kann, ist jahrelange Erfahrung. Der Rest: >Kreativität,Neugier oder auch Offenheit für neue/andersartige Ansätze ist leider allzuoft die Einstellung "Ich bin schlauer als alle Anderen" Wenn man programmiert hat man gewöhnlich eine Aufgabe. Um diese zu lösen braucht man einen Algorithmus. Warum muss man unbedingt einen neuen erfinden? Für die meisten Probleme gibt es Algorithmen und diese sind sehr gut untersucht bezüglich ihrem Laufzeitverhalten und ihrer Schwachstellen und Eignung zur Lösung von Problemen. Wenn ich keinen Algorithmus finden kann, muss man einen neuen entwerfen. Dazu muss ich mich mit den mathematischen/physikalischen/chemischen etc. Grundlagen des Problems auseinandersetzen. Den Algorithmus muss ich als nächstes untersuchen. Terminiert er? Wie ist sein Laufzeitverhalten? Für Datentypen muss abgeschätzt werden, ob ihre Genauigkeit und Größe ausreicht. u.s.w. Also ich sehe da eine ganze Menge an mathematischen Wissen das erforderlich ist.
@Theo Guter Tip! Ich habe es mir hergeladen und bin gerade dabei, mit Hilfe des Manuals ein kleines Progrämmchen zu erstellen. Es ist erstaunlich, was für kleine "EXEN" das ergibt. Mfg Paul
> Schneller als C/C++ und 100-500 x kleinerer Code!!!!
Und wieder einmal wird die Qualität einer Software allein an
Laufzeitperformance und Programmgröße festgemacht ("Code"-Größe ist es
schliesslich nicht, wovon gesprochen wird). "Nebensächliche" Elemente
wie Wiederverwendbarkeit, Robustheit, Lesbarkeit, Wartbarkeit,
Entwicklungszeit, etc. pp. werden gleich außen vor gelassen.
Und die die Qualitätsbetrachtung anhand des "Hallo-Welt" Beispiels.
Praxisnahe Projekte haben eine Komplexität, die obiges deutlich
übersteigt. Da ist ein "Hallo-Welt"-Vergleich das Papier nicht wert, auf
dem er steht. Birnen und Äpfel lassen sich auch gut vergleich...
Hallo Thomas B. Meiner Meinung nach sind Wiederverwendbarkeit, Robustheit,... mindestens zu 90% von Programmierer abhängig. Ein Compiler hat nunmal die Aufgabe, ein Quellprogramm zu übersetzen, und nicht zu erzeugen.
Natürlich ist bei genannten Punkten auch der Programmierer gefragt, aber auch die Struktur der Sprache trägt dazu bei. Es geht ja auch nicht ausschliesslich um einen bestimmten Compiler, sondern darum, dass "aufgeblasene OOP-Sprachen" namentlich "C/C++" prinzipiell langsamere und größere Programme generieren, als besagtes Wunderbasic. Mein Punkt ist, dass die Bewertung wieder auf zwei Faktoren eingedampft wird. Allerdings ist es im echten Leben so, dass eben nicht die Laufzeitperformance das Seeligmachende ist, gerade Entwicklungszeit ist ein maßgeblicher Faktor und da spielt die Entwicklungsplattform/Sprache eine große Rolle. Pure-ASM bringt bestimmt auch nochmal 1% Gewinn an Laufzeitperformance, sollen deswegen Projekte mit Millionen Zeilen Hochsprachencode in Assembler geschrieben werden?
Ja, aber die "Lines of Code per Function Point"-Analyse besagt auch, dass man mit Smalltalk (15) viel effizienter als mit Java, C++, C#,... (alle über 40) ist. Trotzdem programmiert fast niemand mehr mit Smalltalk. (Wobei ich diese LOCperFP-Analysen auch nicht für die ganze Wahrheit halte). Egal, der Markt entscheidet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.