Wirkungsgrad von 100 m RG213U...

[Helmut Schellong]

Am 11.10.2023 um 17:56 schrieb Christoph Müller:

Am 11.10.2023 um 11:54 schrieb Helmut Schellong:
Am 11.10.2023 um 08:31 schrieb Christoph Müller:

Tja - hinterher ist man immer schlauer. Leider hilft mir diese
Erkenntnis nicht weiter.

Mittlerweile beherrsche ich etwa 20 Programmiersprachen mehr oder weniger gut.
Auch das Ur-Basic mit den Nummern links und VB.

Dein Problem läßt sich nur lösen, indem ein Translator VB-->C programmiert wird.

Wirklich nur EINE Lösung vorstellbar?

Ich habe Deine Schilderungen hierzu gelesen.
Wenn Du nur die VB-Quellen hast, und sonst gar nichts, fällt mir nur ein Quellen-Übersetzer ein.

C eignet sich besonders gut für solche Aufgaben.
C++ wurde in den ersten Jahren übrigens zu einer C-Quelle übersetzt, die dann einem C-Compiler
übergeben wurde.
Danke für den Tipp. Muss mal etwas in mich gehen.

C ist die feinkörnigste universelle Hochsprache.
Daher bestens geeignet für Solches.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Helmut Schellong schrieb:

Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:
On 9/22/23 10:54 AM, Stefan Ram wrote:

   In Python ist es auch möglich, Teile einer Bibliothek oder
   eines Programms zur Beschleunigung in C zu schreiben,

oder in jeder anderen Hochsprache.

Überwiegend nein, weil keine anderen Sprachen als C und ASM
genügend schnellen Code generieren.

Bei C müsstest du aber wissen, was der Compiler draus macht.
Und bei Numerik wird auf Libraries zurückgegriffen.
Teste mal, ob
x = a^2
etwa 50x langsamer ist als
x = a * a
falls ja, ist dein Compiler doof und/oder unbekannt, was er so treibt.
Es ging Jahre bis Jahrzehnte, bis C so schnell wie Fortran war,
und im Supercomputing wüsste ich jetzt nicht, was da genommen wird.
Fortran war von Anfang an auf Optimierung ausgelegt. Die Überlegung
war ja gerade, dass die Sprache nur Erfolg haben wird, wenn sie
nicht langsamer als Assembler ist.

--
mfg Rolf Bombach

 

[Rolf Bombach]

Christoph Müller schrieb:

Am 11.10.2023 um 11:15 schrieb Hans-Peter Diettrich:
On 10/11/23 8:31 AM, Christoph Müller wrote:
Am 10.10.2023 um 23:48 schrieb Rolf Bombach:

VB6 installiert sich problemarm unter Win10 und Win11,

Vorausgesetzt, die CDs sind noch auffindbar. Ist leider nicht der Fall.

Das ist natürlich schlecht. Sonst hätte eine virtuelle Maschine mit einem passenden Windows gereicht, um VB6 in seiner gewohnten Umgebung weiter benutzen zu können.

Notfalls könnte aus der Maschine, auf der VB6 noch läuft, eine virtuelle Maschine erzeugt werden. Hab\'s allerdings noch nie selbst gemacht...

Hat nicht funktioniert.

Ansonsten könnte VB6 auch noch von VB.NET verdaut werden. Auch noch nie probiert.

Kann man damit auch editieren?

Ich verstehe die Frage nicht. VB6 ist doch eine Entwicklungsumgebung.

--
mfg Rolf Bombach

 

[Helmut Schellong]

Am 11.10.2023 um 23:17 schrieb Rolf Bombach:

Helmut Schellong schrieb:
Am 22.09.2023 um 23:29 schrieb Hans-Peter Diettrich:
On 9/22/23 10:54 AM, Stefan Ram wrote:

   In Python ist es auch möglich, Teile einer Bibliothek oder
   eines Programms zur Beschleunigung in C zu schreiben,

oder in jeder anderen Hochsprache.

Überwiegend nein, weil keine anderen Sprachen als C und ASM
genügend schnellen Code generieren.

Bei C müsstest du aber wissen, was der Compiler draus macht.

Das weiß ich gut bei clang, gcc und embarcadero_clang (Windows).

Zu Nachfolgendem muß ich aber die Deklaration der Variablen kennen.
In C ist x = a^2 beispielsweise unbekannt.
Einen Potenzier-Operator gibt es nicht.

Und bei Numerik wird auf Libraries zurückgegriffen.
Teste mal, ob
x = a^2
etwa 50x langsamer ist als
x = a * a
falls ja, ist dein Compiler doof und/oder unbekannt, was er so treibt.
Es ging Jahre bis Jahrzehnte, bis C so schnell wie Fortran war,
und im Supercomputing wüsste ich jetzt nicht, was da genommen wird.
Fortran war von Anfang an auf Optimierung ausgelegt. Die Überlegung
war ja gerade, dass die Sprache nur Erfolg haben wird, wenn sie
nicht langsamer als Assembler ist.

--
Mit freundlichen Grüßen
Helmut Schellong

 

[Rolf Bombach]

Bernd Laengerich schrieb:

Am 16.09.2023 um 23:40 schrieb Rolf Bombach:

Fortran war halt _der_ Durchbruch, 1957(!).

Da muß ich doch aus von Lutz Donnerhacke zusammengetragenen \"Fachbegriffen der Informatik\" zitieren.:

\"FORTRAN ist älter als jeder Lötkolben, ist klobiger als jede Elektronenröhre und unpraktischer als Würfelzucker in Tuben. Ein streunender Kater, der nach einem nächtlichen Gesangsauftritt mit dem
Inhalt eines Nachttopfs übergossen wurde, ist verglichen mit einem Stück FORTRAN77-Sourcecode eine ausnehmend elegante Erscheinung. Nun, immerhin kann FORTRAN die vier Grundrechenarten. \" (Nico Hoffmann)

Und nun? Hat er sich genügend ausgekotzt? Niemand hat behauptet, dass F77
hübschen Code hat. Aber offenbar ist heute \"Eleganz\" das wichtigste.
Allerdings ist das Beispiel hinreichend dämlich, als würde man anhand
eines Teslas zeigen, wie Rückständig ein Ford T sei.

Die Donnerkacke soll mal zeigen, welche C-Version Anno 1957 da besser war.

C kam ungefähr 33 Programmiersprachen später hinzu, 1972 übrigens.
Die Formeleingabe ist heftig von Algol abgekupfert.
Später alles besser machen ist nicht wirklich eine Kunst.
BTW, wann kam eigentlich Fortran 66-ANSI X3.9-1966 raus?
ANSI-C? 1989.

Heutiges Fortran ist objektorientiert und strukturiert.
Übrigens, Fortran hatte von Anfang an intrinsisch x^y, dort allerdings x**y
geschrieben, eingebaut und bald auch alle trigonometrischen Funktionen.
Und von Anfang an komplexe Zahlen. Und alles ohne include lib irgendwas.
Daher ist F2C auch schwierig.

Der PL-11-Assembler wurde in Fortran geschrieben. Reine Nervensache.

Der Code von heutigem Fortran sieht allerdings fast so aus wie der von C
und ist daher Scheisse. (Ich versuche mich an das Niveau anzupassen.)

--
mfg Rolf Bombach

 

[Hans-Peter Diettrich]

On 10/11/23 8:40 PM, Helmut Schellong wrote:

Am 11.10.2023 um 17:56 schrieb Christoph Müller:
Am 11.10.2023 um 11:54 schrieb Helmut Schellong:

Dein Problem läßt sich nur lösen, indem ein Translator VB-->C
programmiert wird.

Wirklich nur EINE Lösung vorstellbar?

Ich habe Deine Schilderungen hierzu gelesen.
Wenn Du nur die VB-Quellen hast, und sonst gar nichts, fällt mir nur ein
Quellen-Übersetzer ein.

C eignet sich besonders gut für solche Aufgaben.

Genau wie jede andere Hochsprache. Davor müßte man allerdings erst
einmal einen Emulator schreiben, der die VB Semantik in irgend was
anderes übersetzen kann. Und da niemand diese Semantik genau kennt,
scheitert das Unterfangen schon an dieser Stelle.

DoDi

 

[Hans-Peter Diettrich]

On 10/11/23 5:56 PM, Christoph Müller wrote:

Am 11.10.2023 um 11:54 schrieb Helmut Schellong:
Am 11.10.2023 um 08:31 schrieb Christoph Müller:

Tja - hinterher ist man immer schlauer. Leider hilft mir diese
Erkenntnis nicht weiter.

Mittlerweile beherrsche ich etwa 20 Programmiersprachen mehr oder
weniger gut.
Auch das Ur-Basic mit den Nummern links und VB.

Dein Problem läßt sich nur lösen, indem ein Translator VB-->C
programmiert wird.

Wirklich nur EINE Lösung vorstellbar?

Microsoft ist mit seinen Versuchen, VB zu compilieren, fürchterlich auf
die Schnauze geflogen. Ich habe mir den von VB.NET aus VB6 erzeugten
Quelltext angeschaut und war ziemlich enttäuscht, was da hinter den
Kulissen alles emuliert werden muß.

Ich würde mal im Internet nach VB6 CDs suchen, könnte ganz günstig zu
haben sein. Im Prinzip genügen sogar Kopien, wenn nur der Schlüssel noch
bekannt ist.

DoDi

 

[Bernd Laengerich]

Am 12.10.2023 um 01:09 schrieb Hans-Peter Diettrich:

Ich würde mal im Internet nach VB6 CDs suchen, könnte ganz günstig zu haben
sein. Im Prinzip genügen sogar Kopien, wenn nur der Schlüssel noch bekannt ist.

Könnte aber auch ein Schuß in den Ofen sein. Ich habe jahrelang eine ältere
Installation von VB.NET (mit ComponentOne) in einer VM am Leben gehalten
(99,9% im künstlichen Koma) weil man die alte Version gar nicht mehr
installiert bekam (Aktivierungsserver verweigerte dies). Ich hatte keine Lust
den geerbten Schrott nochmal zu portieren (war mal VB6), inzwischen verweigere
ich da Hand anzulegen.

 

[Helmut Schellong]

Am 12.10.2023 um 01:14 schrieb Hans-Peter Diettrich:

On 10/11/23 8:40 PM, Helmut Schellong wrote:
Am 11.10.2023 um 17:56 schrieb Christoph Müller:
Am 11.10.2023 um 11:54 schrieb Helmut Schellong:

Dein Problem läßt sich nur lösen, indem ein Translator VB-->C programmiert wird.

Wirklich nur EINE Lösung vorstellbar?

Ich habe Deine Schilderungen hierzu gelesen.
Wenn Du nur die VB-Quellen hast, und sonst gar nichts, fällt mir nur ein Quellen-Übersetzer ein.

C eignet sich besonders gut für solche Aufgaben.

Genau wie jede andere Hochsprache.

Nein, C ist die feinkörnigste universelle Hochsprache.
Folglich eignet sie sich besonders gut für solche Aufgaben.
(Ich wiederhole das hier.)

> Davor müßte man allerdings erst einmal einen Emulator schreiben,

Nein, man setzt die VB-Quelle in Token um, mit denen man weitermacht.
Es werden alle VB-Token in entsprechende C-Token übersetzt.
Die Anzahlen müssen dabei nicht jeweils 1 sein.
Eine direkte Übersetzung (an Ort und Stelle) ist auch möglich.

der die VB Semantik in irgend was anderes übersetzen kann. Und da niemand diese Semantik genau
kennt, scheitert das Unterfangen schon an dieser Stelle.

Niemand kennt die VB-Semantik genau?
Dann ist das eine teilweise undefinierte Schrott-Sprache.
Ich habe damals damit etwa eine Handvoll Programme programmiert.
Da war die Semantik aber zutreffend beim Ablaufen erkennbar.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Helmut Schellong]

Am 11.10.2023 um 23:54 schrieb Rolf Bombach:

Bernd Laengerich schrieb:
Am 16.09.2023 um 23:40 schrieb Rolf Bombach:

Fortran war halt _der_ Durchbruch, 1957(!).

Da muß ich doch aus von Lutz Donnerhacke zusammengetragenen \"Fachbegriffen der Informatik\"
zitieren.:

\"FORTRAN ist älter als jeder Lötkolben, ist klobiger als jede Elektronenröhre und unpraktischer
als Würfelzucker in Tuben. Ein streunender Kater, der nach einem nächtlichen Gesangsauftritt mit
dem Inhalt eines Nachttopfs übergossen wurde, ist verglichen mit einem Stück FORTRAN77-Sourcecode
eine ausnehmend elegante Erscheinung. Nun, immerhin kann FORTRAN die vier Grundrechenarten. \"
(Nico  Hoffmann)

Und nun? Hat er sich genügend ausgekotzt? Niemand hat behauptet, dass F77
hübschen Code hat. Aber offenbar ist heute \"Eleganz\" das wichtigste.
Allerdings ist das Beispiel hinreichend dämlich, als würde man anhand
eines Teslas zeigen, wie Rückständig ein Ford T sei.

Es fing in den 1980ern an, immer mal wieder geile/coole Sprüche in Texte einzuflechten.
Bei /Auto, Motor und Sport/ fiel mir das besonders auf.

Leute, die das souverän konnten, wurden mit einer gewissen Ehrfurcht betrachtet.
Dabei wurden doch nur Behauptungen in /geile/ Formulierungen aufgebauscht/eingekleidet.
Für mich war das schon immer eine Art von Bauernfängerei.

Die Donnerkacke soll mal zeigen, welche C-Version Anno 1957 da besser war.

C kam ungefähr 33 Programmiersprachen später hinzu, 1972 übrigens.
Die Formeleingabe ist heftig von Algol abgekupfert.
Später alles besser machen ist nicht wirklich eine Kunst.
BTW, wann kam eigentlich Fortran 66-ANSI X3.9-1966 raus?
ANSI-C? 1989.

C/C++ ist von seiner Verbreitung her allerdings unschlagbar.
Der Spruch \"An C kommt man nicht vorbei.\" kann jedenfalls nur auf \'C\' zutreffen.

Heutiges Fortran ist objektorientiert und strukturiert.
Übrigens, Fortran hatte von Anfang an intrinsisch x^y, dort allerdings x**y
geschrieben, eingebaut und bald auch alle trigonometrischen Funktionen.
Und von Anfang an komplexe Zahlen. Und alles ohne include lib irgendwas.
Daher ist F2C auch schwierig.

Wie nachfolgend zu sehen ist, habe ich den Operator ** in die bish implementiert.
Die kann die C-Operatoren mit einem Plus (^^ gibt es auch).

PS G:\\> bish -E
1# echo $((2**20))
1048576
2# echo $((2.1**20))
2782184.29446951548
3# echo $((2.0**20))
1048576.0
4# echo $((2.01**20))
1158566.98474415342
5# echo $((2.05**20))
1718213.8724939435
6#

http://www.schellong.de/htm/math87.htm
Ich habe dort 4 × [sin,cos,tan,cot,sec,csc] implementiert.

Der PL-11-Assembler wurde in Fortran geschrieben. Reine Nervensache.

Der Code von heutigem Fortran sieht allerdings fast so aus wie der von C
und ist daher Scheisse. (Ich versuche mich an das Niveau anzupassen.)

Das /Aussehen/ von C hat mich nie interessiert.
Ich wollte relative Kompaktheit und Einrückungen (indent), die den Ablauf kenntlich machen.
Prägnant und schnelle Erkennbarkeit beim Überfliegen.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Hans-Peter Diettrich]

On 10/12/23 11:39 AM, Helmut Schellong wrote:

Am 12.10.2023 um 01:14 schrieb Hans-Peter Diettrich:

C eignet sich besonders gut für solche Aufgaben.

Genau wie jede andere Hochsprache.

Nein, C ist die feinkörnigste universelle Hochsprache.
Folglich eignet sie sich besonders gut für solche Aufgaben.
(Ich wiederhole das hier.)

Beweis durch Wiederholung? Hat noch nie funktioniert :-(

Davor müßte man allerdings erst einmal einen Emulator schreiben,

Nein, man setzt die VB-Quelle in Token um, mit denen man weitermacht.
Es werden alle VB-Token in entsprechende C-Token übersetzt.

Und woher weiß man, wie genau diese VB-Tokens zu implementieren sind?
Ich erinnere nur an den Umfang eines C Standards, der Umfang eines VB
Standards dürfte in ähnlicher Größenordnung liegen.

der die VB Semantik in irgend was anderes übersetzen kann. Und da
niemand diese Semantik genau kennt, scheitert das Unterfangen schon an
dieser Stelle.

Niemand kennt die VB-Semantik genau?

Du etwa?

Wie möchtest Du denn ein Token in C übersetzen, das mit
unterschiedlichen Datentypen umgehen können muß?

Ein großer Teil des Arbeitsaufwands eines VB Tokens steckt in der
Ermittlung und Angleichung des Typs seiner Argumente zur Laufzeit, bevor
irgendeine Operation/Aktion ausgeführt werden kann. Dieser Teil ist
bereits im Interpreter optimiert und kann durch den Einsatz einer
\"feinkörnigeren\" Programmiersprache in keinster Weise beschleunigt werden.

> Dann ist das eine teilweise undefinierte Schrott-Sprache.

Nicht un*definiert* sondern nur un*dokumentiert* und beliebig *erweiterbar*.

Ein Teil der undokumentierten Semantik steckt in den Controls, die nicht
notwendig in VB geschrieben sind. Diese müssen daher as Black-Box in
genau dem Zustand eines Programms aufgerufen werden, in dem sie auch im
VB Interpreter aufgerufen würden.

Ich habe damals damit etwa eine Handvoll Programme programmiert.
Da war die Semantik aber zutreffend beim Ablaufen erkennbar.

Das Verfahren soll aber für alle Programme und Programmierstile gelten,
nicht nur für Deine.

Der MS-Hype um compilierte VB Programme, die angeblich 7 mal schneller
laufen sollen als die interpretierten, wurde stückweise der Realität
angepaßt, daß eine Beschleunigung um bis zu 70 Prozent (10:3) überhaupt
und nur in manchen Fällen erreichbar war.

Ich hatte schon beim Schreiben meines VB3 Discompilers festgestellt, daß
sich VB Code durch Compilierung nicht wesentlich beschleunigen läßt.
Microsoft hat das mit seinen nachfolgenden Versionen eindrucksvoll
bestätigt.

DoDi

 

[Christoph Müller]

Am 11.10.2023 um 23:26 schrieb Rolf Bombach:

Christoph Müller schrieb:
Am 11.10.2023 um 11:15 schrieb Hans-Peter Diettrich:
On 10/11/23 8:31 AM, Christoph Müller wrote:
Am 10.10.2023 um 23:48 schrieb Rolf Bombach:

VB6 installiert sich problemarm unter Win10 und Win11,

Vorausgesetzt, die CDs sind noch auffindbar. Ist leider nicht der Fall.

Das ist natürlich schlecht. Sonst hätte eine virtuelle Maschine mit
einem passenden Windows gereicht, um VB6 in seiner gewohnten Umgebung
weiter benutzen zu können.

Notfalls könnte aus der Maschine, auf der VB6 noch läuft, eine
virtuelle Maschine erzeugt werden. Hab\'s allerdings noch nie selbst
gemacht...

Hat nicht funktioniert.

Ansonsten könnte VB6 auch noch von VB.NET verdaut werden. Auch noch
nie probiert.

Kann man damit auch editieren?

Ich verstehe die Frage nicht. VB6 ist doch eine Entwicklungsumgebung.

Na ja - Werbefuzzies drücken sich oft etwas missverständlich aus, um das
Beworbene möglichst als Lösung für alle Lebenslagen anzubieten. Deshalb
meine Nachfrage. Wenn du VB6 als Entwicklungsumgebung bezeichnest, ist
die Sache allerdings klar. Was VB.NET allerdings ist, weiß ich damit
noch nicht. Ist das auch eine Entwicklungsumgebung? Wofür steht das
\".NET\"? Ist damit mit \"VB\" ebenfalls \"Visual Basic\" gemeint?

--
Servus
Christoph Müller
www.astrail.de

 

[Hans-Peter Diettrich]

On 10/13/23 9:00 AM, Christoph Müller wrote:

Was VB.NET allerdings ist, weiß ich damit
noch nicht. Ist das auch eine Entwicklungsumgebung? Wofür steht das
\".NET\"? Ist damit mit \"VB\" ebenfalls \"Visual Basic\" gemeint?

Alle .NET Sprachen können über Visual Studio genutzt werden, da gehört
natürlich auch ein Editor dazu.

Da Basic (und VBA) nicht so richtig in die .NET Sprachfamilie paßt, ist
VB.NET ein Emulator für VB Programme. Wie weit VB.NET mit VB6 kompatibel
ist, entzieht sich meiner Kenntnis. Immerhin kam dazwischen noch VB7 vor.

DoDi

 

[Helmut Schellong]

Am 13.10.2023 um 02:07 schrieb Hans-Peter Diettrich:

On 10/12/23 11:39 AM, Helmut Schellong wrote:
Am 12.10.2023 um 01:14 schrieb Hans-Peter Diettrich:

C eignet sich besonders gut für solche Aufgaben.

Genau wie jede andere Hochsprache.

Nein, C ist die feinkörnigste universelle Hochsprache.
Folglich eignet sie sich besonders gut für solche Aufgaben.
(Ich wiederhole das hier.)

Beweis durch Wiederholung? Hat noch nie funktioniert :-(

Das ist eine seltsame Argumentation, wenn jemand explizit darauf hinweist,
daß er das Geschriebene bereits zuvor geschrieben hat.

\"C ist die feinkörnigste universelle Hochsprache.\"
Stammt nicht von mir, sondern ich habe das der Programmier-Szene entnommen, in
der ich mich seit etwa 1980 befinde.

Davor müßte man allerdings erst einmal einen Emulator schreiben,

Nein, man setzt die VB-Quelle in Token um, mit denen man weitermacht.
Es werden alle VB-Token in entsprechende C-Token übersetzt.

Und woher weiß man, wie genau diese VB-Tokens zu implementieren sind?

Man muß VB sehr gut beherrschen, viel Erfahrung damit haben, auch analytische
Erfahrung mit dem Assembler, der durch einen VB-Compiler erzeugt wird.
Schrifttum zu Basic ist vonnöten.
Ich habe ein Basic-Buch, und bei Microsoft wird man viel dazu finden.
Ich habe ein wenig in Ur-Basic und QuickBasic vor langer Zeit programmiert.

Es kann sein, daß man von Basic eine Zwischensprache erzeugen muß.

Generell wird z.B. eine Schleife in Basic erkennbar und in C übersetzbar sein.
Die Semantik von VB wird nur selten überraschend sein.

Ich erinnere nur an den Umfang eines C Standards, der Umfang eines VB Standards dürfte in ähnlicher
Größenordnung liegen.

Das kommt darauf an.
Die Libraries nehmen in C einen immens großen Raum ein.
Inwieweit die C-Libraries bei einer Quellcode-Übersetzung VB-->C benötigt werden, ist nicht klar.

der die VB Semantik in irgend was anderes übersetzen kann. Und da niemand diese Semantik genau
kennt, scheitert das Unterfangen schon an dieser Stelle.

Niemand kennt die VB-Semantik genau?

Du etwa?

Nein, in VB habe ich noch nie gearbeitet, nur in Basic, QBasic oder QuickBasic.
Aber diejenigen, die schon viel in VB programmiert haben, sollten deren Semantik kennen.

Die Semantik von C ist spätestens seit 1978 erschöpfend definiert.
Der Standard 1989 hat diese Semantik dann festgeklopft, in Verbindung mit kleinen Änderungen.

Wie möchtest Du denn ein Token in C übersetzen, das mit unterschiedlichen Datentypen umgehen können
muß?

Ich kenne VB nicht.

Ein großer Teil des Arbeitsaufwands eines VB Tokens steckt in der Ermittlung und Angleichung des
Typs seiner Argumente zur Laufzeit, bevor irgendeine Operation/Aktion ausgeführt werden kann.
Dieser Teil ist bereits im Interpreter optimiert und kann durch den Einsatz einer \"feinkörnigeren\"
Programmiersprache in keinster Weise beschleunigt werden.

Das ist irrelevant; C hat mit Interpretieren nichts zu tun.
Ein VB-Token macht etwas Bestimmtes.
Das zugehörige C-Token muß entsprechend ausgestaltet werden.
Beispielsweise fügt man einen switch hinzu...

Dann ist das eine teilweise undefinierte Schrott-Sprache.

Nicht un*definiert* sondern nur un*dokumentiert* und beliebig *erweiterbar*.

Genau so schlimm.
Schlimm, schlimmer, am schlimmsten.
Ich will mit Basic und allem danach nichts zu tun haben.
Das ist seit sehr langer Zeit einfach ein schrecklich ungeeigneter Kram.

Ein Teil der undokumentierten Semantik steckt in den Controls, die nicht notwendig in VB
geschrieben sind. Diese müssen daher as Black-Box in genau dem Zustand eines Programms aufgerufen
werden, in dem sie auch im VB Interpreter aufgerufen würden.

Schon wieder \'Interpreter\'!
Das ist irrelevant; C hat mit Interpretieren nichts zu tun.

Ich habe damals damit etwa eine Handvoll Programme programmiert.
Da war die Semantik aber zutreffend beim Ablaufen erkennbar.

Das Verfahren soll aber für alle Programme und Programmierstile gelten, nicht nur für Deine.

Schon wieder eine komische Argumentation.
Bisher hat niemand auch nur ansatzweise undokumentierte VB-Details benannt und erklärt.

Ein solcher Quellen-Übersetzer muß nicht 100% können.
Bei VB geht das ja auch gar nicht, weil Teile undokumentiert sind.

Das ist auch ein Grund, warum ich mich nach Kennenlernen nicht weiter mit Basic befaßt habe.
Ich hatte schon damals das richtige Bauchgefühl.
Einzig Ada finde ich durchgehend interessant.

Der MS-Hype um compilierte VB Programme, die angeblich 7 mal schneller laufen sollen als die
interpretierten, wurde stückweise der Realität angepaßt, daß eine Beschleunigung um bis zu 70
Prozent (10:3) überhaupt und nur in manchen Fällen erreichbar war.

Ich hatte schon beim Schreiben meines VB3 Discompilers festgestellt, daß sich VB Code durch
Compilierung nicht wesentlich beschleunigen läßt. Microsoft hat das mit seinen nachfolgenden
Versionen eindrucksvoll bestätigt.

Der Interpreter war dann sehr gut.
Gewöhnlich sollte eine binäre Exe mindestens 20-fach schneller sein.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Christoph Müller]

Am 13.10.2023 um 15:30 schrieb Hans-Peter Diettrich:

On 10/13/23 9:00 AM, Christoph Müller wrote:

Was VB.NET allerdings ist, weiß ich damit noch nicht. Ist das auch
eine Entwicklungsumgebung? Wofür steht das \".NET\"? Ist damit mit \"VB\"
ebenfalls \"Visual Basic\" gemeint?

Alle .NET Sprachen können über Visual Studio genutzt werden, da gehört
natürlich auch ein Editor dazu.

Besten dank!

Da Basic (und VBA) nicht so richtig in die .NET Sprachfamilie paßt, ist
VB.NET ein Emulator für VB Programme.

Das scheint dann doch brauchbar zu sein. Wahnsinns Rechenleistung
brauche ich für meine antiken Programme nicht.

Wie weit VB.NET mit VB6 kompatibel
ist, entzieht sich meiner Kenntnis. Immerhin kam dazwischen noch VB7 vor.

Was ist VB.NET für ein Ding? Ist das Bestandteil von Windows oder muss
man das kaufen? Wenn ja, für welches Geld?

--
Servus
Christoph Müller
www.astrail.de

 

[Hans-Peter Diettrich]

On 10/13/23 8:51 PM, Christoph Müller wrote:

Was ist VB.NET für ein Ding? Ist das Bestandteil von Windows oder muss
man das kaufen? Wenn ja, für welches Geld?

Frag nicht mich, frag Microsoft.

DoDi

 

[Hans-Peter Diettrich]

On 10/13/23 7:39 PM, Helmut Schellong wrote:

[blabla]

> Gewöhnlich sollte eine binäre Exe mindestens 20-fach schneller sein.

Da Du offensichtlich keinerlei Ahnung von VB hast, erübrigt sich jede
weitere Diskussion.

DoDi

 

[Helmut Schellong]

Am 14.10.2023 um 12:47 schrieb Hans-Peter Diettrich:

On 10/13/23 7:39 PM, Helmut Schellong wrote:

[blabla]

Gewöhnlich sollte eine binäre Exe mindestens 20-fach schneller sein.

Da Du offensichtlich keinerlei Ahnung von VB hast, erübrigt sich jede weitere Diskussion.

Ah ja, Du ziehst Dich zurück.

Ich schrieb ja auch vor einigen Postings, daß ich mit Basic, QBasic, QuickBasic, VB, etc.
nichts zu tun haben will, wobei dieser sehr richtige Entschluß bei mir etwa 1983 fiel.
Das ist eine frühzeitig unnütze Linie innerhalb der Linien der Programmiersprachen.


--
Mit freundlichen Grüßen
Helmut Schellong

 

[Leo Baumann]

Am 14.10.2023 um 16:52 schrieb Helmut Schellong:

Ich schrieb ja auch vor einigen Postings, daß ich mit Basic, QBasic,
QuickBasic, VB, etc.
nichts zu tun haben will, wobei dieser sehr richtige Entschluß bei mir
etwa 1983 fiel.
Das ist eine frühzeitig unnütze Linie innerhalb der Linien der
Programmiersprachen.

QBasic war bis zu dem Zeitpunkt an dem ich das 1. CAM-Programm bekommen
habe eine Möglichkeit schnell kleinere Berechnungen aus der E-Technik zu
machen und Graphen zu plotten.

Zur Zeit habe ich MuPAD-CAM und Mathematica dafür.

QBasic war glaube ich nie dafür konzipiert Anwenderprogramme zu
programmieren.

 

[Helmut Wabnig]

On Sat, 14 Oct 2023 17:00:06 +0200, Leo Baumann <ib@leobaumann.de>
wrote:

Am 14.10.2023 um 16:52 schrieb Helmut Schellong:
Ich schrieb ja auch vor einigen Postings, daß ich mit Basic, QBasic,
QuickBasic, VB, etc.
nichts zu tun haben will, wobei dieser sehr richtige Entschluß bei mir
etwa 1983 fiel.
Das ist eine frühzeitig unnütze Linie innerhalb der Linien der
Programmiersprachen.

QBasic war bis zu dem Zeitpunkt an dem ich das 1. CAM-Programm bekommen
habe eine Möglichkeit schnell kleinere Berechnungen aus der E-Technik zu
machen und Graphen zu plotten.

Zur Zeit habe ich MuPAD-CAM und Mathematica dafür.

QBasic war glaube ich nie dafür konzipiert Anwenderprogramme zu
programmieren.

ELIZA lief drauf, die allererste KI.

(Und auch auf anderen BASICs).

Die Leute standen in Trauben vor der Konsole.
Glaubt heut keiner, aber ich habs gesehen.
Icke war der Tech.

w.