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
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.
