PureBasic 6.00 Alpha 1

Ankündigungen PureBasic oder die Community betreffend.
Benutzeravatar
TroaX
Beiträge: 524
Registriert: 08.03.2013 14:27
Wohnort: ERB

Re: PureBasic 6.00 Alpha 1

Beitrag von TroaX »

@tft:
Die Stärken von PureBasic kann man definitiv nicht mit nur einer Hand abzählen. Aber das fehlende C-Backend ist keine davon, war nie eine davon und wird auch nie eine davon sein. Man könnte es sogar eher als eine der Schwächen bezeichnen. Denn im Gegensatz zu einem guten C-Compiler fehlt es einem Assembler an vielen Optimierungsmöglichkeiten, die bei PureBasic über den PB-Transpiler geregelt werden müssen. Denn das Programmieren mit einem Assembler ist in der Regel viel viel Kleinschrittiger und macht dadurch Optimierungen seitens des Assemblers einfach unfassbar komplex. Bei C hingegen liefern die Compiler schon erheblichste Optimierungen mit, da der zu Grunde liegende Code einfach weniger Kleinschrittig und somit leichter zu optimieren ist.

Als Stärken für PureBasic zähle ich ganz klar:
1. Klare einfache Syntax mit einer optischen strikten Trennung. Zum Beispiel der Unterschied zwischen einer Variable und einer Konstante.Blöcke haben einen beschreibenden Anfang und ein beschreibendes Ende (naja BASIC-Typisch eben) usw.
2. Ein strikter Sprachgebrauch in der Dokumentation und eine klare Benennung von Sprachfeatures. Ein gutes Beispiel dafür sind Keywords. In PureBasic sind Keywords genau das, was Keywords auch sein sollen. Schlüsselwörter, die dem Compiler sagen, wie das Programm zu erzeugen und wie mit Variablen und anderen Konstrukten umzugehen ist. In vielen vielen anderen Sprachen hingegen wird der Begriff Keyword auch für "Build-In Functions" verwendet, die Programmfunktionalität zur Verfügung stellen. Keywords sollten aber keine Programmfunktionalität liefern. Sie sollen nur den Ablauf und die Beziehungen innerhalb des Codes beschreiben. Aber in PureBasic ist alles, was Programmfunktionalität liefert in Bibliotheken und darunter in Prozeduren klar ausgewiesen. Das macht die Arbeit damit sooooo viel leichter.
3. In der Doku werden die Bibliotheken klar nach ihrem Einsatzzweck benannt. Bei der fragmentierten Programmierung, wie das in anderen modernen Umgebungen der Fall ist, gestaltet sich die Suche nach geeigneten Bibliotheken zeitraubend, da diese nur selten nach ihrem Einsatzzweck sauber gelistet sind und sich zudem alles hinter ihren Fancy Namen versteckt. Python sei hier einmal als Beispiel genannt. Man hört davon, das man mit Python das Qt Framework nutzen kann und sucht nach Modulen. Wie zur Hölle soll man bei dem Namen PySide darauf kommen, das sich dahinter die eigentlich beste Qt-Implementierung für Python versteckt? Oder wie soll man eine vernünftige Datenbankbibliothek ohne ORM für z.B. MariaDB/MySQL finden, wenn alle nur von SQLAlchemy reden, welches aber ORM und eine Unterstützung für fast alle DBMS Systeme mitliefert? Bei PureBasic weiß ich, wo ich suchen muss.
4. Die Bibliotheken selbst. Ich finde hätten die Herschafften nicht so viel Zeit mit Spiderbasic verplämpert, hätten wir hier jetzt viel mehr haben können. Aber auch so ist der Bibliotheksumfang schon ganz ordentlich. Bei PureBasic wirken die Bibliotheken auch so, als würden diese klar zur Sprache gehören und verfolgen nach Möglichkeit einen Vergleichbaren Ansatz, wie diese zu nutzen sind. Dieses zusammenschustern aus externen Quellen, die unterschiedliche Güte von Dokumentationen, die teils deutlich abweichenden Nutzungswege machen in anderen Sprachen das Programmieren teils echt zur Folter. In Python oder Node (JS) heißt die Doku Google oder Stackoverflow und viele suchen sich nur noch Snippets raus und passen diese an, um an ihr Ziel zu kommen. Denn es gibt einfach keine wirklich zentrale Anlaufstelle für Wissen und jeder kocht da seine eigene Suppe.

Und es gibt da noch einige mehr Punkte. Aber es wird gerade doch sehr Offtopic.

Aber Apple hat mit dem M1 nun einmal gezeigt, wie Leistungsfähig und vor allem wie effizient diese ARM-Dinger arbeiten können. Dabei stehen die selbst ja noch am Anfang. Und auch der Raspberry Pi bietet viel Potenzial, Ist aber nun einmal nicht mit PureBasic kompatibel. Die Intel-Macs werden nun einmal jetzt nach und nach verschwinden und wenn PureBasic die Kompatibilität zu Max OSX on ARM nicht herstellen kann, würden sie früher oder später viele Nutzer einbüßen, da sich hier nun einmal auch viele Mac-Entwickler tummeln. Vor allem im englischen Forum. Zudem könnte das C-Backend später helfen, weitere externe Bibliotheken sauber einzubinden. Vielleicht fließen dadurch noch modernere und interessantere Bibliotheken in die Umgebung ein, die sich mit dem Assembler-Backend nur sehr mühselig oder garnicht einbinden ließen.

Und Windows für ARM wird genauso ein Reinfall wie Windows RT. Man versucht zwar, mit Hilfe von Virtualisierung die x86 Anwendungen zum laufen zu bekommen. Doch am Ende wird dies einfach daran scheitern, das für zeitkritische Anwendungen der Performanceverlust einfach nicht umgangen werden kann, die Leute im Zuge dessen darauf verzichten werden und weiterhin die x86 Variante nutzen. Und welcher Entwickler soll sich am Ende darauf einstellen? Da hat Apple eine bessere Position. Denn durch den Wegfall der Intel-Macs, wird es irgendwann keinen Grund geben, die Intel Macs weiterhin zu supporten und die Entwickler werden zwangsweise umsteigen. Das ist der Vorteil an einem geschlossenen Ökosystem, welches eher kleinere Planeten besiedelt, anstatt wie bei Windows ganze Galaxien einnimmt. Microsoft kann Windows x86 nicht einfach wegschmeißen. Die Abhängigkeiten von diesem System sind einfach immens und man würde sich am Ende selbst schlachten.

Aber ob der M1 am Ende auch für die Windows-Welt so gut ist? Adobe weiß, welche Zielgruppe überwiegt und wird dann ggf. rechnen, ob das parallele unterstützen von x86 noch lukrativ ist oder ob es sich für sie nicht doch lohnt, ARM den Vorzug zu geben. Und selbst wenn nicht. Arbeiten sie dann am Ende an beiden Architekturen gleichermaßen oder wird der x86 zur ungeliebten Stiefmutter? Steinberg? Abbleton? Native Instruments? Was werden die alle machen? Denn Windows für ARM muss sich erst einen ordentlichen Marktanteil erarbeiten, damit das Unterstützen der Plattform sich lohnt. Alle wollen die Henne sein. Aber aus welchem Ei soll die Henne schlüpfen?

Und vor allem. Warum drifte ich immer so hart ins Offtopic ab? Ich sollte mich echt mal schämen :lol: :oops:

Am Ende ist das C-Backend logische Konsequenz und auch wichtig, da die Technologien einfach nicht stehen bleiben und auch ein PureBasic zumindest ein wenig in diese Richtung gehen muss. Klar werden auch Browser immer wichtiger. Aber Spiderbasic war und ist da einfach der völlig falsche Ansatz. Die sollen das lieber ruhig sterben lassen und sich voll und ganz auf PureBasic konzentrieren. Dann wird es auch gut. Das andere da war meiner Meinung nach nie gut und wird auch nie gut werden.
PC: AMD Ryzen 9 3950X | 64 GB RAM | RTX 3060 TI | 2,5 TB NVMe SSD | 2 TB SATA SSD | WIN 10 | 3x FHD Display
Mobil: AMD Ryzen 7 4800H | 16 GB RAM | GTX 1650 TI | 1 TB NVMe SSD | Win 10
Server: MSI Cubi N | Pentium Silver N5000 | 8 GB RAM | 1 TB HDD | Debian/Yunohost + Nextcloud
Programmierung: PureBasic | B4J | B4A | PHP | Python
Benutzeravatar
tft
Beiträge: 560
Registriert: 08.09.2004 20:18
Computerausstattung: GTX Titan , i9 9900K , 32 GB Ram , 500 GB SSD , 3 ASUS FullHD Monitore and more
Wohnort: Dachsen
Kontaktdaten:

Re: PureBasic 6.00 Alpha 1

Beitrag von tft »

meine rede ...... danke für dieses umfangreiche statmend.... oder wie das auch immer geschrieben wird.

Gruss TFT
TFT

W10 , i9 9900K ,32 GB Ram , GTX Titan , 3 Monitore FHD
ARDUINO Freak :-)
Benutzeravatar
diceman
Beiträge: 335
Registriert: 06.07.2017 12:24
Kontaktdaten:

Re: PureBasic 6.00 Alpha 1

Beitrag von diceman »

@TroaX:
Danke für diese Zusammenfassung. :allright:
Now these points of data make a beautiful line,
And we're out of Beta, we're releasing on time.
Syr2
Beiträge: 13
Registriert: 11.03.2020 13:39

Re: PureBasic 6.00 Alpha 1

Beitrag von Syr2 »

Also ich bin mit Pb groß geworden und kann keine andere Sprache so gut wie Pb. Dann wird mal leider schnell mal so nach dem Motto "ah, Basic" belächelt.
Für mich wäre es aus dieser Sicht sehr interessant, wenn man in Zukunft PB-Code 1:1 in C-Code konvertieren kann (macht das Backend nicht genau das?), dann wäre man nämlich zu C-Programmierern kompatibel und könnte den ganzen Wiedersprechern an den Kopf werfen, dass das auch nix anderes als C ist.
Vielleicht ist eine Option die den C-Code anzeigt ja sogar implementierbar? Ich wäre sehr interessiert!
Benutzeravatar
Olafmagne
Beiträge: 86
Registriert: 07.12.2017 17:30
Wohnort: Sete/Frankrich

Re: PureBasic 6.00 Alpha 1

Beitrag von Olafmagne »

Syr2 hat geschrieben: 02.06.2021 15:16 ...
Vielleicht ist eine Option die den C-Code anzeigt ja sogar implementierbar? Ich wäre sehr interessiert!
Das ist mit einer Compiler-Option möglich (Konsole) .
Unsinnige Anweisungen von Seiten des Chef's lösen grundsätzlich ein "Syntax Error" bei mir aus
OS=Windows 10:PB=5.31/5.73:PC=LENOVO ideapad 330(AMD A6)
Linux Mint-Cinamon
Benutzeravatar
TroaX
Beiträge: 524
Registriert: 08.03.2013 14:27
Wohnort: ERB

Re: PureBasic 6.00 Alpha 1

Beitrag von TroaX »

@Syr2
Die Belächelung kommt nicht von ungefähr. Basic ist nun mal aus den 60ern und wurde zu einer Zeit erfunden und entwickelt, wo Computer noch sehr rudimentär und einfach gewesen sind. Das Ur-Basic ist heutzutage einfach nutzlos und die Nachfahren sind einfach weder schön noch konsequent. Modernere Abkömmlinge wie Visual Basic hinterließen bei den Entwicklern gemischte Gefühle. Nicht nur wegen dem Preis, sondern das man mit der Anwendung eine Runtime mitliefern musste, die meines Wissens nach nicht einmal direkt mit der Anwendung ausgeliefert werden durfte. Zumindest erinnere ich mich noch daran, das man die VB Runtime immer gesondert laden musste.
Visual Basic wurde beim Wechsel auf das .NET zudem relativ stiefmütterlich behandelt.

Basic hat seinen Ruf weg und den wird es auch nicht mehr los. Da kann weder PureBasic noch B4X oder VB.NET etwas ändern. Die Basic-Coder bleiben weiterhin unter sich. Und da wird auch das Backend nichts ändern. Denn der C-Code ist nur MIttel zum Zweck und wird auch kaum mit einem von Hand geschriebenen C-Code vergleichbar sein.
PC: AMD Ryzen 9 3950X | 64 GB RAM | RTX 3060 TI | 2,5 TB NVMe SSD | 2 TB SATA SSD | WIN 10 | 3x FHD Display
Mobil: AMD Ryzen 7 4800H | 16 GB RAM | GTX 1650 TI | 1 TB NVMe SSD | Win 10
Server: MSI Cubi N | Pentium Silver N5000 | 8 GB RAM | 1 TB HDD | Debian/Yunohost + Nextcloud
Programmierung: PureBasic | B4J | B4A | PHP | Python
Benutzeravatar
juergenkulow
Beiträge: 146
Registriert: 22.12.2016 12:49
Wohnort: :D_üsseldorf-Wersten

Re: PureBasic 6.00 Alpha 1

Beitrag von juergenkulow »

Hallo TroaX,

Code: Alles auswählen

; printf gibt Daten aus der Datasection aus in PB_C. 
EnableExplicit
Define s$
OpenConsole()
Read.s s$ 
While s$<>""
  Define *string=UTF8(s$)
  ! printf(p_string); 
  FreeMemory(*string)
  Read.s s$ 
Wend 
Input()
CloseConsole()
DataSection
  Data.s "Ich freue mich auf Deine bahnbrechenden PB-C Programme."
  Data.s ""
EndDataSection
CompilerIf Defined(PB_Processor_C,#PB_Constant) And #PB_Compiler_Processor<>6 ; #PB_Processor_C=6 
  CompilerError "Benutze Compiler C-Backend in Compiler-Option"
CompilerElseIf Defined(PB_Compiler_Backend,#PB_Constant) 
  CompilerIf #PB_Compiler_Backend<>#PB_Backend_C
    CompilerError "Benutze C Backend Compiler #PB_Compiler_Home Compilers\pbcompilerc"
  CompilerEndIf
CompilerElseIf #PB_Compiler_Version<600 
  CompilerError "Benutze PureBasic Version >=6.00 Alpha" 
CompilerEndIf   
CompilerIf #PB_Compiler_ExecutableFormat<>#PB_Compiler_Console 
  CompilerError "Exectable-Format muss Console sein in Compiler-Option"
CompilerEndIf 
Edit: CompilerIf Defined(PB_Processor_C,#PB_Constant) ...
Zuletzt geändert von juergenkulow am 20.06.2021 07:10, insgesamt 1-mal geändert.
Bitte stelle Deine Fragen, denn den Erkenntnisapparat einschalten entscheidet über das einzig bekannte Leben im Universum.

Jürgen Kulow Wersten :D_üsseldorf NRW D Europa Erde Sonnensystem Lokale_Flocke Lokale_Blase Orion-Arm
Milchstraße Lokale_Gruppe Virgo-Superhaufen Laniakea Sichtbares_Universum
Benutzeravatar
TheCube
Beiträge: 145
Registriert: 20.07.2010 23:59
Wohnort: NRW

Re: PureBasic 6.00 Alpha 1

Beitrag von TheCube »

Dank der nützlichen CompilerIf's im Beispielcode von juegenkulow habe ich auch endlich den untenstehen Codeschnipsel (frei aus engl. Forum)
zum laufen bekommen. Hatte Exe-Format nicht auf 'Console' geändert. /:->

Code: Alles auswählen

OpenConsole()
!  printf("Hello world!\n");
!  getchar();
end
Für was und inwieweit die direkte C-Code-Einbinderei nützlich sein wird sei dahingestellt. Aber man kann's wenn man will ... :D
---------------
Hat jemand vielleicht einen verlässlichen Codeschnipsel, um die unterschiedlichen Ausführungsgeschwindigkeiten (FASM, C, C optimiert)
mal auf dem eigenen PC vergleichen zu können ? Den Code von "Superquadratics" habe ich weder in PB-Examples noch im Internet gefunden.
Wäre ja schon interessant, allein um die Fortschritte späterer alphas wahrzunehmen.
GPI
Beiträge: 1510
Registriert: 29.08.2004 13:18
Kontaktdaten:

Re: PureBasic 6.00 Alpha 1

Beitrag von GPI »

das hilft tatsächlich extrem. Wenn man include- commandos etc. auch verwenden kann. Das ist noch eine Frage.
Gerade wenn es um sowas geht das komplette Struckturen übergeben wird, also nicht nur Pointer. Das kann Purebasic nicht. Man könnte es mit sowas deutlich einfacher lösen. Es wäre dann auch möglich Bibliotheken zu benutzen, die auf Klassen beruhen. sofern auch c++ - code erlaubt ist.

Ich bin mittlerweile sogar dafür den Assembler-Backend komplett abzuschaffen, die Vorteile (schnellere Programme, leichter portabel auf andere Plattformen) überwiegen. Zudem könnte man aus C sehr einfach weitere Eigenschaften importieren. Wie eben besagte Struckturen Übergabe und Rücknahme.
Wünschenswert wäre bspw. auch ein "EnableExplicitPointer" - das die Pointer-Typen passen müssen.
CodeArchiv Rebirth: Deutsches Forum Github Hilfe ist immer gern gesehen!
Benutzeravatar
jacdelad
Beiträge: 73
Registriert: 03.02.2021 13:39
Computerausstattung: Ryzen 5800X, 108TB Festplatte, 32GB RAM, Radeon 7770OC
Wohnort: Riesa
Kontaktdaten:

Re: PureBasic 6.00 Alpha 1

Beitrag von jacdelad »

@tft: Soweit ich gelesen habe bleibt das ASM-Backend erhalten, jedenfalls vorerst. Auf lange Sicht wird es sicher abgelöst. Was ich jetzt nicht ganz verstehe ist deine Ablehnung. Wo ist das Problem ob nun ASM, C oder Jogurt erstellt wird, solange es funktioniert?
Wenn andere Entwicklungsumgebungen bessere Bedingungen für lau bieten solltest du die nutzen. Bitte verstehe das nicht als böse Kritik, ich würde gern verstehen, warum du diese Meinung vertrittst.
Antworten