Der PureBasic Dämon lässt sich nicht austreiben ;)

Hier kann alles mögliche diskutiert werden. Themen zu Purebasic sind hier erwünscht.
Flames und Spam kommen ungefragt in den Mülleimer.
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von TroaX »

Benubi hat geschrieben:Das von Haus? Also ich gebe dir zu 100% Recht, daß das sehr praktisch wäre. Vielleicht kommt ja noch MySQL irgendwann dazu? Wurde das schon auf die Wunschliste gesetzt ? Wenn ich meine Posts so lese, ich habe mir 2-3 mal was gewünscht und es wurde implementiert.

Aber welche "echten" Programmiersprachen können denn das ganze wirklich, ohne ein großes Framework zu sein oder darauf zuzugreifen? Perl oder sowas?
Ist jetzt nicht agressiv gefragt, aber naja... "zu Fuß" sind wir eben... Jeder muß mal zu Fuß gehen, auch der Kaiser.

Ich habe da ein wenig mit IMAP,POP3 und natürlich HTTP in PB gebastellt... fehlt nur etwas mehr Crypto-Support seitens PB und alles könnte man selber machen.... ja!

Übrigens: PUT/DELETE wird das noch oft benutzt oder nur von WebDav ? Gibt's noch WebDav ?
PUT und DELETE sind grundlegende Bestandteile von REST-Services.

Und zur Frage welche Programmiersprache: Genau wie Purebasic gibt es genug weitere Programmierprachen, die ein Framework mitliefern und/oder gut gefüllte Paketmanager haben. Um nur einmal ein paar zu nennen: .NET Framework (C#, Visual Basic, J#, F#), Python (samt Paketmanager), Java, Qt Framework für C++, PHP, Node (Javascript).
Und alle genannten können entweder das, was ich brauche von Haus aus oder es gibt Pakete, die ich über einen Einzeiler einbinden kann. Genau dafür sind Frameworks und Paketmanager da. Und genau daran muss sich auch Purebasic messen. Ob es die Entweickler wollen oder nicht. Aber warum beharre ich auf Purebasic darauf? Aus ganz einfachen Gründen. Die Sprache ist für ein BASIC-Dialekt extrem elegant. Es zwingt mich nicht zu OOP. Es erzeugt native Anwendungen und ist somit sehr schnell und das Framework-Konzept zusammen mit dem Handbuch suchen meiner Meinung nach seines gleichen.

Warum verbreiten sich die RasPI-Alternativen nicht? Weil die Software und Treiberunterstützung mies ist. Und warum schreibt die Community keine? Weil es eine Alternative gibt, die funktioniert! Den RasPI selbst. Diese Parallelen lassen sich an unzähligen weiteren Beispielen verdeutlichen. Das gleiche zeigt sich auch bei dem leidigen Thema Windows gegen Linux. Ein ewiger Krieg zwischen geschlossener, aber funktionaler und etablierter Software gegen offener, aber dafür oftmals eingeschränker Software. Ein Libre- oder Openoffice kann auch bis heute mein MS Office nicht ersetzen. Audio-DAW's unter Linux? Keine ist auch nur ansatzweise gut genug.
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benubi
Beiträge: 186
Registriert: 22.10.2004 17:51
Wohnort: Berlin, Wedding

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von Benubi »

GPI: Aber PB will auch Einsteiger-Freundlich sein, und diese #Datei Konstanten sind ja alter Standart à la Datei-Kanal. Nicht mehr zeitgemäß, vielleicht, aber dafür Rückwärtskompatibel von der Syntax. Mit dem Aufpassen auf Konstanten, nun ja das ist alles Programmier-Stil; der Vorteil an dem PB-Objekt-Managment ist IMMER NOCH, daß es "Kugelsicher" sein will. Also Du kannst die Objekte auf Gültigkeit mit den PB-internen Funktionen checken wie z.B. IsImage(1) oder IsImage(myImg)... das trägt zur Robustheit bei, behält den klassischen Basic-Schreibstil bei, und mit #PB_Any haben wir auch noch das dynamische Etwas dazu. Also da ist alles dabei was man braucht, egal wie man es angeht. Es ist nur ein Parameter zu viel für dich; aber ich glaube der erste Parameter wird eh bei PB "verschluckt" weil er ins EAX geschrieben wird ? naja ich weiss auch nicht bin kein Assemblero ^^ Ich denke das ist immer noch eine geniale Lösung, auch wenn vielleicht nicht mehr ganz "zeitgemäß"...


TroaX: das sind Sachen an die ich auch schon mal gedacht habe. Es ist ein hin und her, so ist das mit der Reflektion. Flexion, Reflexion... ein hin und her.
Von den "echten" Programmiersprachen, die Du genannt hast, ist nur C/C++ wirklich Plattform- und Framework- unabhängig.

Frameworks etc. pp. benötigen hunderte Megabytes an extra Bibliotheken und Runtime-Zeugs meistens und verbrauchen zusätzlich RAM, sind anfällig für externe Probleme... Das ist die DLL-eritis Krankheit, schon wieder. Es sei denn, man macht das nativ, aber das bedeutet i.d.R. MS Produkte kaufen oder Ähnliches... und dann muß man trotzdem schlau sein, wegen DLLs und Frameworks etc. und man verliert die Platformunabhägingkeit.

Nur c/c++ hat alles bzw. die benötigte Reichweite in OS und User/Proger; Java hat noch mehr Proger, kann man so glaube ich mit Tools schnell zu c++ konvertieren bzw. andersrum - aber Java ist eine Interpreter-Sprache (es gibt aber auch Java-Versteher-Chips etc.).

Die populärste "Sprache" soll ja PHP sein. Ich bin aber "konservativ". Bei mir war ein MegaByte immer ein MegaByte; kein MibiByte oder GenderByte... das habe ich mir so eingeprägt. Und PHP ist eine Skript-Sprache. Mit fettem Framework, Online-Interpreter etc. Das kann man alles mit ein paar Routinen in PB implementieren. Ich habe bei meinem PB-Server Experiment auch ein PHPBB Forum eingerichtet... was solls.

Im Prinzip läuft es darauf hinaus, daß die Community etwas beiträgt also offenlegt. Das ist bei den anderen Sprachen auch so, oder bei der Entwicklung von Linux oder sowas. Ich denke wenn sich Leute in der PB-Community zusammenfinden und einige Module/Libraries zusammen coden würden - auf verschiedenen Platformen - dann könnte man das hier als Vorschlag posten für PB. So viel ich weiss gibt es in PB libraries, die mit PB geschrieben wurden und nicht in C/Assembler. Auch die IDE ist in PB geschrieben. Außerdem, wie gesagt : Verbesserungsvorschläge werden tatsächlich umgesetzt und/oder akzeptiert. "Mir" und ein paar anderen PB'lern ist es zu verdanken, daß die GetCurrentDirectory() und SetCurrentDirectory() Befehle implementiert wurden - einfach weil ich ein wenig danach gefragt habe. Es ist aber natürlich ein einfacher Vorschlag gewesen und leicht umsetzbar; ich habe gefragt und die Community hat für mehrere Platformen die Lösung geliefert - dann wurde es in PB implementiert.


Das einzige was fehlt ist die Koordination und die Zielsetzung für einige Module/Libraries. Dann könnte man auch jammern, daß wir für die Entwickler die Arbeit machen :lol: Aber vielleicht gibts auch eine Danksagung, Implementation und ein paar Goodies als Dankeschön, sollte man etwas von der Community her anbieten.

Wenn man sich die UserLibs ansieht, so gibt es sehr viel Gutes und Funktionierendes - nur ist es zu oft closed source und daher bestehen diese Libs nicht über die Zeit, wenn sich PB intern ändert. Es gibt jetzt z.B. von Haus aus eine Zip-Library oder FTP, CGI etc. in PureBasic, und das waren auch alles anstöße aus der Community die als Userlibs bei der PB-Area zum Download verfügbar waren/sind.
GPI
Beiträge: 1511
Registriert: 29.08.2004 13:18
Kontaktdaten:

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von GPI »

Benubi hat geschrieben:GPI: Aber PB will auch Einsteiger-Freundlich sein, und diese #Datei Konstanten sind ja alter Standart à la Datei-Kanal. Nicht mehr zeitgemäß, vielleicht, aber dafür Rückwärtskompatibel von der Syntax.
Es ist so viel in PureBasic nicht Standard, von daher seh ich das nicht als argument. Es stammt aus einer Zeit, als Basic-Programme noch Zeilennummern hatten, If-Statements auf eine Zeile beschränkt waren, FOR-NEXT die einzige Schleife waren und man Unterprogramme mit Gosub aufgerufen hat.

#PB_Any ist eingentlich die einzige Alternative, wenn du bspw. mit Modulen Arbeiten willst.

Code: Alles auswählen

a=CreateImage(1,10,10)
Debug a
DeclareModule test
EndDeclareModule
Module Test
  Debug "inmodule"
  Debug IsImage(1)
EndModule
Hier konflikte zu vermeiden wird extrem aufwendig. Eigentlich nur über ein Common-Module.
Wenn du Module schreiben willst, die für eine vielzahl von Projekten genutzt werden sollen, ist #pb_any schlicht Pflicht.

Edit: Userlibs wären dann das nächste Thema. Blöderweise gibt es keine Möglichkeit in Purebasic selbst eine zu schreiben. Das schränkt gewaltig ein. Ja ich weis, es gibt da Bestrebungen, von denen halte ich wenig. Besonders von der aktuellen, wo man einfach von Hinten bis Vorne sehr schnell kapiert, das der Autor wenig Ahnung hat, was der da macht.
CodeArchiv Rebirth: Deutsches Forum Github Hilfe ist immer gern gesehen!
Benubi
Beiträge: 186
Registriert: 22.10.2004 17:51
Wohnort: Berlin, Wedding

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von Benubi »

GPI: Eigentlich hast Du recht. Ich mußte darüber kurz meditieren und an meine eigenen "Arbeiten" denken.

Einerseits: dafür ist doch das #PB_Any da. Warum sollte es anders sein? Man kann auch sicherlich darauf verzichten und solche Parameter beim Erstellen der Objekte weglassen.
Man muss dennoch "Handles" in den Objekt-Zugriffsfunktionen benutzen.
Andererseits: Man kann das Objekt-Management auch ohne "konstante" Objekte "kugelsicher" machen; das wäre vermutlich noch effizienter und sicherer ohne die "Konstanten".

Ich denke es wird verschwinden wie UseFile(1) und UseImage(2), eines Tages ... in PB6, oder vielleicht früher. Oder vielleicht ........ NIE !
/:->
Benutzeravatar
Josh
Beiträge: 1028
Registriert: 04.08.2009 17:24

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von Josh »

GPI hat geschrieben:In ursprünglichen Basic-Konzept vergab man die Handles selbst
also z.b. ReadFile(1,"Hallo.txt")
das hat natürlich massive Nachteile. Man muss drauf achten, das man nicht versehentlich die gleiche Handle-Nummer mehrmals benutzt. Gerade bei Proceduren, die die Datei nicht gleich schließen, weil man noch was eintragen will, gibt es Probleme.
Deshalb gibt es ja die #pb_any - konstante
ReadFile(#pb_any,"Hallo.txt")
damit vergibt das System ein Handle und gibt ihn zurück. Das ist zu 100% sicher. Und dieses Verhalten sollte standard sein. Den ersten Parameter sollte man schlicht komplett abschaffen.
ReadFile("Hallo.txt")
alternativ könnte man den ersten Parameter auch optional machen
Readfile(,"Hallo.txt")
Das #pb_any stört mich mittlerweile nur noch.
Das #Pb_Any wegzulassen würde bedeuten, dass die direkte Verwendung von praktisch jedem alten Code nicht mehr möglich wäre. Eine Möglichkeit dass Pb sich mal richtig von Altlasten befreien kann, könnte nach meiner Meinung so aussehen:
  • Jede erste Codezeile im Mainfile muss in Zukunft eine bestimmte Kopfzeile sein, die Informationen zum zu verwendeten Compiler enthält. Dies wäre dann z.B. ab Pb 6.00 erforderlich.
  • Wenn Pb diese Kopfzeile nicht findet, wird automatisch die älteste Compilerversion (z.B. 5.70) verwendet, die die großen Änderungen noch nicht enthält. Dieser ältere Compilerversion wird automatisch mit allen zukünftigen Pb-Versionen mitgeliefert.
P.S.: Das von dir verwendete, komplett idiotische 'Readfile', würde dann hoffentlich auch auf den Haufen der Altlasten landen :D
Benutzeravatar
TroaX
Beiträge: 659
Registriert: 08.03.2013 14:27
Computerausstattung: PC: Ryzen 9 3950X, 96 GB RAM, RX6800XT, 2.5 TB SSD, 21:9 Display, Pop_OS! | Lappi: Ryzen 7 5800H, 16 GB RAM, 1 TB SSD, Pop_OS!
Wohnort: NRW
Kontaktdaten:

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von TroaX »

Frameworks etc. pp. benötigen hunderte Megabytes an extra Bibliotheken und Runtime-Zeugs meistens und verbrauchen zusätzlich RAM, sind anfällig für externe Probleme... Das ist die DLL-eritis Krankheit, schon wieder. Es sei denn, man macht das nativ, aber das bedeutet i.d.R. MS Produkte kaufen oder Ähnliches... und dann muß man trotzdem schlau sein, wegen DLLs und Frameworks etc. und man verliert die Platformunabhägingkeit.
Das ist so nicht richtig. Purebasic arbeitet auch nicht anders. Unter Windows zum Beispiel liefert man die Bibliotheken als DLL's nicht mit. Sie werden beim kompilieren in die ausführbare Datei statisch einbegettet (unterschied von statischen und dynamischen Bibliotheken). Unter Linux greift es auf die Bibliotheken der Distribution zu. Wenn man unter Linux Software ausliefern will, muss man die Abhängigkeiten mit angeben, damit die Distri die Bibliotheken aus dem Repo laden kann usw. Unter Windows findest du alle statischen Bibliotheken unter %PureBasic%\PureLibraries. Da sind im Grunde die DLL's (nur eben als statische Bibliotheken als .lib).

Man kann auch den C/C++-Tools anweisen, statische Bibliotheken in die executable einbetten.

Frameworks müssen nicht unendlich groß sein. PHP ist ja ein sehr gutes Beispiel. Entweder man nutzt solch Monster wie Symphony oder CakePHP. Oder man nutzt so eines, wie FatFree Framework (welches ich bevorzuge). Das hat entpackt keine 600 KB. Das .NET Framework ist fester Bestandteil von Windows und muss nicht mit ausgeliefert werden. Unter Linux und Mac gibt es das Mono Framework, welches eine große Schnittmenge des .NET abbildet. Auch dies benötigt man nur einmal pro System. Das gleiche gilt für Java. Bei der fertigen Software muss nur das ausgeliefert werden, was außer der Reihe per Paketmanager nachgereicht wurde. Das sind vielleicht 1-5 Bibliotheken.

Und auch Qt ist nicht wirklich groß, auch wenn dessen Umfang etwas anderes andeutet. :wink:

EDIT
Und zum Thema im Forum anmerken/Nachfragen:
http://www.purebasic.fr/english/viewtop ... =3&t=67868
http://www.purebasic.fr/english/viewtop ... =3&t=65248
http://www.purebasic.fr/english/viewtop ... =3&t=64857
http://www.purebasic.fr/english/viewtop ... =3&t=56123
Das waren mal auf die schnelle 4 Themen aus dem englischen Featurerequest-Forum zur HTTP-Funktionalität. Interesant ist auch der zweite Beitrag aus dem letzten Link. Solche Anfragen zum Thema HTTP kommen alle 2 Wochen. Umgesetzt wurde es bis heute nicht. :lol:
PC: Ryzen 9 3950X | 96 GB RAM | RX6800XT | 2,5 TB NVMe | Pop_OS!
Notebook: 16" 3:2 | Ryzen 7 5800H | 16 GB RAM | Radeon Vega | 1TB NVMe | Pop_OS!
NAS: Fritz.Box :lol:
Coding: Purebasic 6.04 | PHP | HTML | CSS | Javascript
Benutzeravatar
X0r
Beiträge: 2770
Registriert: 15.03.2007 21:47
Kontaktdaten:

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von X0r »

Abgesehen von der 3D Engine hat PB alles richtig gemacht.
Wobei man hier noch erwähnen muss, dass OGRE eine reine Rendering Engine ist. OGRE selbst hat nicht mal den Anspruch, als Game-Engine zu fungieren. Deshalb finde ich die Integration in PureBasic sinnfrei, zumal sie ja auch kaum jemand verwendet.

Mir persönlich fehlen derzeit noch viele Sprach-Features. Mit den Modulen ist Fred einen Schritt in die richtige Richtung gegangen, aber die Implementierung ist...grenzwertig. Ich frage mich beispielsweise immer noch, weshalb keine verschachtelten Module möglich sind. Begrenzte Kompetenz?
Benutzeravatar
NicTheQuick
Ein Admin
Beiträge: 8675
Registriert: 29.08.2004 20:20
Computerausstattung: Ryzen 7 5800X, 32 GB DDR4-3200
Ubuntu 22.04.3 LTS
GeForce RTX 3080 Ti
Wohnort: Saarbrücken
Kontaktdaten:

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von NicTheQuick »

Ich finde es auch schade, wenn ich als Administrator vom deutschen Forum Fred eine private Nachricht im englischen Forum schreibe und er schon seit Wochen nicht darauf reagiert. Irgendwie peinlich. Dann gibt es noch ein paar andere Kleinigkeiten, die ich als Bugs gesendet habe. Und darauf gibt es schon ewig keine Antwort.
Ansonsten gebe ich euch mit allen Punkten Recht.

Purebasic ist praktisch um schnell was kleines zu testen, aber ernsthaft kann ich das heute nicht mehr verwenden. Und das Problem liegt viel am fehlenden OOP und SSL.
Bild
CodeBurg
Beiträge: 101
Registriert: 06.06.2011 22:53

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von CodeBurg »

NicTheQuick hat geschrieben:Purebasic ist praktisch um schnell was kleines zu testen, aber ernsthaft kann ich das heute nicht mehr verwenden. Und das Problem liegt viel am fehlenden OOP und SSL.
So sehr ich dir bezüglich SSL/TLS zustimmen kann, so sehr muss ich dir im Bezug auf OOP wiedersprechen. Es braucht kein OOP, auch nicht für große Projekte. Frag mal Mr. Torvalds, was er denn so von OOP und C++ hält ;) Und das gilt ja nicht nur für den Linux-Kernel, er setzt ja praktisch alle seine Projekte wie z. B. auch GIT mit C und nicht mit C++ um.

Ein weiteres Indiz dafür, dass man auch heute noch immer ohne OOP sehr gut arbeiten kann ist die C im Tiobe-Index. Man kann jetzt von diesem Index halten, was man will (ein schönes Beispiel dafür: https://www.heise.de/developer/artikel/ ... 93137.html), aber egalwie genau er erstellt wird, näherungsweise dürften die Zahlen stimmen. Und hier ist es eben schon auffällig, dass sich C seit Jahren sehr gut in dem Wulst an OOP-Sprachen halten kann. Nicht umsonst wurde sie ja auch erst kürzlich zur Sprache des Jahres 2017 gekürt. Wer unbedingt OOP betreiben möchte, hat ja zum Glück mehr als genügens Auswahl auf dem Markt der Programmiersprachen.

Aber ungeachtet der Tatsache, dass ich PB so sehr mag, gerade weil es eine prozedurale Sprache ist, würde auch ich PB nicht große Projekte einsetzen. Dies hat diverse Gründe und definitiv nichts mit OOP zu tun.
Benutzeravatar
NicTheQuick
Ein Admin
Beiträge: 8675
Registriert: 29.08.2004 20:20
Computerausstattung: Ryzen 7 5800X, 32 GB DDR4-3200
Ubuntu 22.04.3 LTS
GeForce RTX 3080 Ti
Wohnort: Saarbrücken
Kontaktdaten:

Re: Der PureBasic Dämon lässt sich nicht austreiben ;)

Beitrag von NicTheQuick »

Ja, mit C kann man wunderbar programmieren, dennoch fehlen mir hier auch schon einige Dinge wie Templates, Referenzen (&) und Namespaces. Für Treiber und Mikrocontroller kann man OOP sowieso meist vergessen. Trotzdem finde ich OOP schöner und zu schreiben. Das ist dann eben meine Meinung. Was Torvalds da sagt, ist mir dabei herzlich egal. ;-) Nichts für Ungut. Die Möglichkeit für OOP sollte aber wenigstens bestehen. Es muss ja niemand verwenden.
Bild
Antworten