Lob für PureBasic ...
Kollegen,
Nicht nur das hier nicht aufhört zu träumen, nein ihr fangt auch noch an polemisch zu werden...
Hier ein paar Gegenantworten:
# Zu 'C':
Ohne C wuerde es kein Windows, kein Unix, kein Linux, kein... aber sicherlich auch kein PureBasic geben.
# Zu VB, VB.NET
Es wird immer Kritiker geben, die gibt es ja auch bei PB.
Entscheidend ist aber das selbst diese in VB oder VB.NET entwickeln (müssen)
# Zu PureBasic
[zitat=the_pahrao]
die vorzüge von PB gegenüber dem "altem" vb sind: keine megabyte-großen runtime dll's, linux/osx unterstützung, VERDAMMT SCHNELL, kleine unabhängige executables.
gleiche eigenschaften: leicht zu erlernen, gut für einsteiger, mit dem richtigem editor für dialoge auch für RAD geeignet, was sehr wichtig ist für z.B. unternehmen. wie schonmal angesprochen, lässt sich ein basic code leichter lesen und verstehen als z.b. ein c++ code.
und das wichtigste: man kommt schnell zu sichtbaren ergebnissen (überzeugt so manchen vorgesetzten).
[/zitat]
- Die wenigsten Applikationen sind nur eine 'Dialog' Applikation.
- Also C++ ist ein Standard, BASIC nicht. Wer also BASIC beherrscht (z.B. BlitzBasic) wird nicht unbedingt PureBasic sofort verstehen!
- Wenn ich PureBasic Neuling bin, brauche ich bestimmt genause lange wie ein VB Neuling um schnell sichtbare Ergebnisse zu erhalten, bin ich Profi, dann denke ich, sind beide ebenso schnell. Vor allen bei VB habe ich wesentlich mehr Gestaltungsmöglichkeiten durch ThirdParty Products (OCX, Controls, usw).
- Sobald Win32 Funktionen in einen PureBasic Proggy benutzt werden, hast Du natürlich auch die Abaengikeiten zu der entsprechenden DLL.
Übrigends wer von den 'VB-Kritikern' hat den schon in VB6.0 oder VB.NET programmiert?
Nicht nur das hier nicht aufhört zu träumen, nein ihr fangt auch noch an polemisch zu werden...
Hier ein paar Gegenantworten:
# Zu 'C':
Ohne C wuerde es kein Windows, kein Unix, kein Linux, kein... aber sicherlich auch kein PureBasic geben.
# Zu VB, VB.NET
Es wird immer Kritiker geben, die gibt es ja auch bei PB.
Entscheidend ist aber das selbst diese in VB oder VB.NET entwickeln (müssen)
# Zu PureBasic
[zitat=the_pahrao]
die vorzüge von PB gegenüber dem "altem" vb sind: keine megabyte-großen runtime dll's, linux/osx unterstützung, VERDAMMT SCHNELL, kleine unabhängige executables.
gleiche eigenschaften: leicht zu erlernen, gut für einsteiger, mit dem richtigem editor für dialoge auch für RAD geeignet, was sehr wichtig ist für z.B. unternehmen. wie schonmal angesprochen, lässt sich ein basic code leichter lesen und verstehen als z.b. ein c++ code.
und das wichtigste: man kommt schnell zu sichtbaren ergebnissen (überzeugt so manchen vorgesetzten).
[/zitat]
- Die wenigsten Applikationen sind nur eine 'Dialog' Applikation.
- Also C++ ist ein Standard, BASIC nicht. Wer also BASIC beherrscht (z.B. BlitzBasic) wird nicht unbedingt PureBasic sofort verstehen!
- Wenn ich PureBasic Neuling bin, brauche ich bestimmt genause lange wie ein VB Neuling um schnell sichtbare Ergebnisse zu erhalten, bin ich Profi, dann denke ich, sind beide ebenso schnell. Vor allen bei VB habe ich wesentlich mehr Gestaltungsmöglichkeiten durch ThirdParty Products (OCX, Controls, usw).
- Sobald Win32 Funktionen in einen PureBasic Proggy benutzt werden, hast Du natürlich auch die Abaengikeiten zu der entsprechenden DLL.
Übrigends wer von den 'VB-Kritikern' hat den schon in VB6.0 oder VB.NET programmiert?
Siehste! Geht doch....?!
PB*, *4PB, PetriDish, Movie2Image, PictureManager, TrainYourBrain, ...
PB*, *4PB, PetriDish, Movie2Image, PictureManager, TrainYourBrain, ...
ich habe unter Kollegen mal einen kleinen Contest veranstaltet. Jederthe_pharao hat geschrieben:die vorzüge von PB gegenüber dem "altem" vb sind:
[...] VERDAMMT SCHNELL [...]
sollte in seiner 'Lieblingssprache' ein kleines Programm erstellen, welches
die Anzahl von Zeilen in einer 36 Megabyte großen Datei zählt. Ich habe
dabei in VB, VB.NET und Purebasic programmiert. Mit
Standard-Purebasic-Befehlen (also ohne die FastFile-Lib von Rings) landete
PB performancetechnisch im unteren Mittelfeld.
Sprich: Bisher habe ich noch kein Schlüsselerlebnis gehabt, das mir
gezeigt hat, dass PureBasic VERDAMMT SCHNELL ist. Vielleicht habe ich
die entsprechenden Befehle im Handbuch auch noch nicht entdeckt.
Wohlgemerkt: ich spreche von den Standard-PB-Befehlen, nicht von ASM
oder irgendeiner LIB-Unterstützung.
das Argument großer Runtimes wird bei VB(.NET) sehr häufig (und meinerthe_pharao hat geschrieben:übrigens braucht man für eine .net-anwendung noch
ein viel größeres runtime dll als für VB. nämlich das > 20mb .net
framework!
Meinung nach zu unrecht) als Nachteil angeführt. Die VB-Runtimes bzw.
das .NET-Framework installiert man EINMALIG. Danach lassen sich alle
Standard-VB(.NET) Programme ausführen.
ByTheWay: Habe ich das gerade richtig gelesen? Die
DirectX-Enuser-Runtime beträgt 36 Megabytes? Wieso beschwert sich denn
hier niemand über die Größe?
Grüße ... Kiffi
P.S.: Testsieger des Contests war übrigens VB.NET.
Kiffi hat geschrieben: ByTheWay: Habe ich das gerade richtig gelesen? Die
DirectX-Enuser-Runtime beträgt 36 Megabytes? Wieso beschwert sich denn
hier niemand über die Größe?
Grüße ... Kiffi
P.S.: Testsieger des Contests war übrigens VB.NET.
weil es sich dabei um die runtimes für game-programmierung handelt. bei richtiger anwendung versetzen sie auch den einsteiger in die lage, attraktive und professionelle games zu schreiben...
die .net scheisse wird aber für JEDE sorte anwendung gebraucht.
und letzlich ist das nichts anderes als ein weiterer geschickter schachzug von microsoft die computerwelt und insbesondere das web fest in den klauen zuhalten. von programmierung im klassischen sinne ist eigentlich gar nicht mehr die rede...
mit .net wird das programmieren trivialisiert und darum wird es wohl LEIDER erfolgreich sein...
ps:wegen der rumtimes habe ich VB immer für ne unelegante sprache gehalten...und genau das war sie auch....
-
- Beiträge: 51
- Registriert: 09.09.2004 14:20
ach nein? du bedienst word also von der kommandozeile aus?- Die wenigsten Applikationen sind nur eine 'Dialog' Applikation.
ich will hier ja nicht mit meinem halbwissen glänzen, aber gibt es in c nicht auch einen ansi und einen ascii standard?- Also C++ ist ein Standard, BASIC nicht. Wer also BASIC beherrscht (z.B. BlitzBasic) wird nicht unbedingt PureBasic sofort verstehen!
ich denke, für einsteiger und umsteiger ist PB leichter zu erlernen (und SCHNELLER) als z.B. c++
ja, das problem ist aber, dass VB ne stange geld kostet und jetzt nur noch mit .net erhältlich ist (probier mal ein original VB 6.0 irgendwoher zu bekommen).- Wenn ich PureBasic Neuling bin, brauche ich bestimmt genause lange wie ein VB Neuling um schnell sichtbare Ergebnisse zu erhalten, bin
da hast du recht, doch diese ocx controls funktionieren auch nur mit windows und nicht unter osx oder linux.ich Profi, dann denke ich, sind beide ebenso schnell. Vor allen bei VB habe ich wesentlich mehr Gestaltungsmöglichkeiten durch ThirdParty Products (OCX, Controls, usw).
ah.. und was war jetzt der vorteil von ocx und thirdparty controls bei vb?- Sobald Win32 Funktionen in einen PureBasic Proggy benutzt werden, hast Du natürlich auch die Abaengikeiten zu der entsprechenden DLL.
wenn ich mit VB in einem contest teilnehme, in dem gewinnt, wer am schnellsten primzahlen gewinnt, wird VB auch kläglich versagen. oder?Kiffi hat geschrieben:ich habe unter Kollegen mal einen kleinen Contest veranstaltet. Jederthe_pharao hat geschrieben:die vorzüge von PB gegenüber dem "altem" vb sind:
[...] VERDAMMT SCHNELL [...]
(...)PB performancetechnisch im unteren Mittelfeld.
mach mit deinen kollegen doch mal einen contest, wer am schnellsten ein programm schreibt, dass die buchhaltung durch einfache und intuitive bedienbarkeit entlastet.
ich gebe zu, dass ich auch den vergleich zu VB gezogen habe (um das ganze mal aufzulösen) und mich wohl mißverständlich ausgedrückt habe. dennoch ist PB schnell und selbst in c++ und assembler kann man spiele schreiben, die selbst auf 3 ghz rechnern noch ruckeln...Sprich: Bisher habe ich noch kein Schlüsselerlebnis gehabt, das mir
gezeigt hat, dass PureBasic VERDAMMT SCHNELL ist. Vielleicht habe ich
die entsprechenden Befehle im Handbuch auch noch nicht entdeckt.
ja. das zählt aber nur, solange du weißt, wo das programm eingesetzt wird. willst du, dass ein größerer kreis von kunden dein programm nutzt, musst du die VB-Runtimes oder das Framework diesen leuten *irgendwie* zugänglich machen. d.h. mit in die setup-routine klatschen -> braucht viel platz, und nicht jeder hat dsl.das Argument großer Runtimes wird bei VB(.NET) sehr häufig (und meiner
Meinung nach zu unrecht) als Nachteil angeführt. Die VB-Runtimes bzw.
das .NET-Framework installiert man EINMALIG. Danach lassen sich alle
Standard-VB(.NET) Programme ausführen.
du, wenn du dir ein spiel gekauft hast und auf deinem rechner installieren willst, auf dem es dummerweise noch kein directx gibt. leider hast du nur ein dummes altes 56k modem. und der typ, der die das spiel verkauft hat, hat die directx-runtimes natürlich nicht auf die cd gepackt, weil die ja eh schon jeder installiert hat.....ByTheWay: Habe ich das gerade richtig gelesen? Die
DirectX-Enuser-Runtime beträgt 36 Megabytes? Wieso beschwert sich denn
hier niemand über die Größe?
P.S.: Testsieger des Contests war übrigens VB.NET.
auch unter linux?
Epic Space Battles: Solar*Conflict - 3D Shoot'em up: UFO Onslaught! 3d
..... Die Diskussion ist in der richtigen Richtung: PB gegen VB !!!!
dazu aus meiner Sicht:
..... VB ist derzeit für uns (noch) nicht zu ersetzen
aber wir verwenden nicht VB.Net
..... Die VB Runtime DLLs sind bei etlichen Kunden ein
Problem, da sie aus Sicherheitsgründen nicht zugelassen
werden, unerwünscht sind etc. Darauf haben wir als
Lieferant keinen Einfluß.
..... Auch muß in der Regel bei Zahlungsverkehrssoftware eine
Zertifizierung erfolgen, bei kleinen Executables kein Problem,
ist eine fette DLL dabei wirds kritisch und das Procedere dauert lange
und kostet (Man muß den Aufwand für die Prüfstellen ja selbst
bezahlen, zumeist wenigstens...)
..... Also wird das in C++ programmiert, das verzögert
andere Projekte, da nicht unbeschränkt C-Programmier-
kapazität zur Verfügung steht (gute C-Programmierer
muß man suchen (ist wieder einfacher geworden) und
auch auf Dauer im Betrieb halten können (das ist wiederum sehr
schwierig....)
Genau deshalb ist der Bedarf nach einer Basic-Programmiersprache
gegeben, die kleine Executables erzeugt, ohne DLLs, gleich
wie sie heißt.
PB wäre eine Möglichkeit, wir werden das testen, nächste
Woche geht das erste Programm beim Kunden in Betrieb.
Die Entwicklungszeit war naturgemäß etwas länger als
beim gewohnten VB, da nicht auf vorhandene
Programmvorlagen etc. zurückgegriffen werden konnte, aber beim
nächsten Projekt (so es kommt) wird auch hier mehr
Erfahrung vorhanden sein. Das kleine Executable ist der
Lohn des Mehraufwandes....
Auch haben wir noch mehrere uralte QB-Applikationen zum
Ablösen (zum Teil aus 1986....), da die QB Executables
auf schnellen Rechnern (> 3 Ghz) und zumindest unter NT4.0
Timing-Probleme bekommen, also demnächst ersetzt werden
müssen. Diese laufen als *.EXE - Verbund (ohne BRUN) und sind
relativ komplex. Eine Neuprogrammierung in C kommt zu teuer,
ein Umschreiben in ein Basic ist günstiger, da viele Berechnungen
enthalten sind.
Auch hier werden wir wahrscheinlich PB den Vorzug geben.
Also: Es gibt durchaus auch Vorteile von PB gegenüber VB, zumindest
in dem kommerziellen Bereich, wo ich tätig bin ........
Ich denke, es würde sich lohnen, PB zu erlernen,
ebenso wie es sich lohnen würde, PB professionell weiterzu-
entwickeln und bekannt zu machen.
Der Bedarf ist da, Mitbewerb hat noch nie geschadet
und auswählen tue ich auch gerne ....
Cu von Team100
dazu aus meiner Sicht:
..... VB ist derzeit für uns (noch) nicht zu ersetzen
aber wir verwenden nicht VB.Net
..... Die VB Runtime DLLs sind bei etlichen Kunden ein
Problem, da sie aus Sicherheitsgründen nicht zugelassen
werden, unerwünscht sind etc. Darauf haben wir als
Lieferant keinen Einfluß.
..... Auch muß in der Regel bei Zahlungsverkehrssoftware eine
Zertifizierung erfolgen, bei kleinen Executables kein Problem,
ist eine fette DLL dabei wirds kritisch und das Procedere dauert lange
und kostet (Man muß den Aufwand für die Prüfstellen ja selbst
bezahlen, zumeist wenigstens...)
..... Also wird das in C++ programmiert, das verzögert
andere Projekte, da nicht unbeschränkt C-Programmier-
kapazität zur Verfügung steht (gute C-Programmierer
muß man suchen (ist wieder einfacher geworden) und
auch auf Dauer im Betrieb halten können (das ist wiederum sehr
schwierig....)
Genau deshalb ist der Bedarf nach einer Basic-Programmiersprache
gegeben, die kleine Executables erzeugt, ohne DLLs, gleich
wie sie heißt.
PB wäre eine Möglichkeit, wir werden das testen, nächste
Woche geht das erste Programm beim Kunden in Betrieb.
Die Entwicklungszeit war naturgemäß etwas länger als
beim gewohnten VB, da nicht auf vorhandene
Programmvorlagen etc. zurückgegriffen werden konnte, aber beim
nächsten Projekt (so es kommt) wird auch hier mehr
Erfahrung vorhanden sein. Das kleine Executable ist der
Lohn des Mehraufwandes....
Auch haben wir noch mehrere uralte QB-Applikationen zum
Ablösen (zum Teil aus 1986....), da die QB Executables
auf schnellen Rechnern (> 3 Ghz) und zumindest unter NT4.0
Timing-Probleme bekommen, also demnächst ersetzt werden
müssen. Diese laufen als *.EXE - Verbund (ohne BRUN) und sind
relativ komplex. Eine Neuprogrammierung in C kommt zu teuer,
ein Umschreiben in ein Basic ist günstiger, da viele Berechnungen
enthalten sind.
Auch hier werden wir wahrscheinlich PB den Vorzug geben.
Also: Es gibt durchaus auch Vorteile von PB gegenüber VB, zumindest
in dem kommerziellen Bereich, wo ich tätig bin ........
Ich denke, es würde sich lohnen, PB zu erlernen,
ebenso wie es sich lohnen würde, PB professionell weiterzu-
entwickeln und bekannt zu machen.
Der Bedarf ist da, Mitbewerb hat noch nie geschadet
und auswählen tue ich auch gerne ....
Cu von Team100
Kompliziert kann es jeder lösen, aber das wirklich Geniale ist einfach.....
DotNet: weil es sich dabei um die runtimes für applikations-programmierungCreature hat geschrieben: [DirectX]: weil es sich dabei um die runtimes für game-programmierung
handelt. bei richtiger anwendung versetzen sie auch den einsteiger in die
lage, attraktive und professionelle games zu schreiben...
handelt. bei richtiger anwendung versetzen sie auch den einsteiger in die
lage, attraktive und professionelle anwendungen zu schreiben...
Du siehst eventuelle Parallelitäten?
falsch! Ich wiederhole: Das DotNet-Framework muss nur EINMAL auf demCreature hat geschrieben:die .net scheisse wird aber für JEDE sorte anwendung
gebraucht.
Zielrechner installiert werden.
Creature hat geschrieben:und letzlich ist das nichts anderes als ein weiterer
geschickter schachzug von microsoft die computerwelt und insbesondere
das web fest in den klauen zuhalten.
@Creature: Das ist reinste Polemik. Von Dir hätte ich eine differenziertereMARTIN hat geschrieben:Genau. Wer was andres denkt ist einfach nur dumm.
Aussage erwartet.
@MARTIN: Kannst Du Deine Aussage auch mit objektiven Argumenten
untermauen?
Grüße ... Kiffi
@Kiffi
Nein kann ich nicht.
Aber was sollte denn Microsoft sonst damit (sprich .NET) bezwecken, außer ihren Monopol zu stärken ?
.NET soll technisch sehr gut sein, ich habe auch nichts gegen .NET an sich einzuwenden.
Ich muss aber dem Creature recht geben, er hat das gut auf den Punkt gebracht - "geschickter schachzug von microsoft" - und zwar verdammt geschickter.
Nein kann ich nicht.
Aber was sollte denn Microsoft sonst damit (sprich .NET) bezwecken, außer ihren Monopol zu stärken ?
.NET soll technisch sehr gut sein, ich habe auch nichts gegen .NET an sich einzuwenden.
Ich muss aber dem Creature recht geben, er hat das gut auf den Punkt gebracht - "geschickter schachzug von microsoft" - und zwar verdammt geschickter.
Amilo 1667|Suse Linux 10.1_64bit/WinXP |PB 4.00/3.94
@kiffi,
zunächst möchte ich meinerseits martin recht geben indem er schreibt, daß aus rein technischer sicht, das framework eine hervorragende leistung ist. und dir will ich gern bestätigen, daß das famework dem programmierer das leben erleichtert...
habe mich vielleicht falsch ausgedrückt.
ich will sagen: wenn das .net-framework sich durchsetzt ( und die aussicht dafür ist gut) dann hat wieder einmal microsoft einen standart gesetzt der nichts anderes mehr zulässt.
borland z.b. produziert mit delphi 8 eine voll entwickelte programmierumgebung die das .net-framework bedient!
und bei licht betrachtet ist das ganze eine weitere tragende säule des M$ monopols...
desweiteren sind direktx und .net auch nur technisch miteinander vergleichbar. direktx ist auf die game programmierung reduziert während .net ( immer vorrausgesetzt es kommt) dann für jede sorte programm benötigt wird. das meinte ich mit "allen programmen"
ps: kennen wir uns von nem anderen board, da du von mir eine etwas differenziertere sichtweise erwartest?
zunächst möchte ich meinerseits martin recht geben indem er schreibt, daß aus rein technischer sicht, das framework eine hervorragende leistung ist. und dir will ich gern bestätigen, daß das famework dem programmierer das leben erleichtert...
habe mich vielleicht falsch ausgedrückt.
ich will sagen: wenn das .net-framework sich durchsetzt ( und die aussicht dafür ist gut) dann hat wieder einmal microsoft einen standart gesetzt der nichts anderes mehr zulässt.
borland z.b. produziert mit delphi 8 eine voll entwickelte programmierumgebung die das .net-framework bedient!
und bei licht betrachtet ist das ganze eine weitere tragende säule des M$ monopols...
desweiteren sind direktx und .net auch nur technisch miteinander vergleichbar. direktx ist auf die game programmierung reduziert während .net ( immer vorrausgesetzt es kommt) dann für jede sorte programm benötigt wird. das meinte ich mit "allen programmen"
ps: kennen wir uns von nem anderen board, da du von mir eine etwas differenziertere sichtweise erwartest?