Ich denke, man kann Delphi und XProfan nur ganz schwer miteinander vergleichen. Delphi spricht eine ganz andere Zielgruppe an und ist keine Einsteigersprache. Wird zwar gerne so verkauft, aber die Lernkurve ist schon steil. Da hat RGH mit XProfan schon eine Sache hingelegt, die wirklich durchdacht ist und Anfängern den Einstieg in die Programmierung ermöglicht, aber auch Fortgeschrittenen genug an die Hand gibt, um gute und komplexe Programme zu entwickeln.
Zukunft XProfan
-
-
- Gerade eben
- Anzeige
Hallo!
Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.
- ✔️ Schnelle Ladezeiten (optimiert für WordPress, WoltLab & Co.)
- ✔️ Deutsche Server & DSGVO-konform
- ✔️ Persönlicher Support (kein 0815-Ticket-System)
-
Da spricht auch viel Firmen-Philosophie mit. Mittlere und größere Firmen, die eine Entwicklungsabteilung haben, werden wohl kaum XProfan verwenden. Da wird schon das genommen, was z.Zt. aktuell und sehr bekannt ist. Vielleicht kleinere Firmen, die was von XProfan-Programmierern angeboten bekamen, nutzen das. Damals, vor ca. 25 - 30 Jahren, sprach man dann auch von 'mittlerer Datentechnik'. Und als dann die ersten SQL-Datenbanken rauskamen, verlor dBase immer mehr an Bedeutung. Zwar reicht dBase für kleine/mittlere Betriebe von der Datenmenge her immer noch aus, ist aber leider nicht netzwerkfähig.
Das Ziel von XProfan ist eher für den 'Hausgebrauch' zu programmieren, bzw. Neueinsteigern mit evtl. gewissen Programmierhintergrund (BASIC) den Einstieg zu erleichtern.
-
Hallo Heinz,
da Du immer wieder (zu Recht) beklagst, dass man in PureBasic keine einfachen Textausgaben mit Print wie in XProfan machen kann, sondern stattdessen das Debug-Fenster braucht, habe ich den simulierten Textmodus von XProfan mal in PureBasic nachgebaut, siehe Dateianhang. Es sind alle wesentlichen Funktionen enthalten, die es auch in XProfan gibt (nur nicht sowas wie Input, Scrn, Font, TMouse).
Einfaches PureBasic-Beispielprogramm:
Ist zwar nur eine Spielerei, aber für uns XProfaner für ganz kleine Tools ja vielleicht doch ein wenig brauchbare Nostalgie.
Gruß, Jens-Arne
-
Nett gemacht. Sieht gut aus.

-
Na gut, InputS() gibt es jetzt auch (und eine Detailverbesserung beim internen Bildschirmmanagement). Es soll ja, wenn es schon keiner braucht, wenigstens gut funktionieren.

-
hab mir die Anleitung durchgelesen, aber nicht probiert, weil kein Windows.
Schöne Alternative zu einer grafischen GUI. Da könnte man sozusagen eine schlanke Konsolenanwendung schreiben.
Hab es bis jetzt tatsächlich noch nicht geschafft, für Linux ein Konsolenprogramm mit PureBasic zu bauen, obwohl es laut Hilfe gehen soll. Im IDE-Modus gehts, aber sobald ich das kompilierte Programm starte, öffnet sich kein Terminal.
Vllt. habe ich aber auch irgendwas falsch verstanden... -
Naja, das imitiert das Aussehen einer Konsolenanwendung (wenn auch standardmäßig schwarz auf weiß und nicht weiß auf schwarz). Mehr aber auch nicht, d.h. man kann z.B. keine Ein- oder Ausgaben umleiten. Allerdings hat XProfan eine der kürzesten "Hello world"-Codes der Welt:
Cls
Print "Hello world"
WaitInputDas geht in PureBasic so nicht, wobei sowas für ganz einfache Ausgaben aber sehr hilfreich ist. Normalerweise muss man immer gleich mindestens ein Gadget (z.B. ein EditorGadget oder ein ListViewGadget für die Ausgabe) erstellen und zumindest einen rudimentären EventLoop schreiben. Deshalb vermissen wir Profaner diese einfache Möglichhkeit der Textausgabe halt in PureBasic (bis jetzt
). -
genau, für einfache Ausgaben bzw. Tastatureingaben ist das schon eine feine Sache. Gibt viele Szenarien, wo diese Art von Ein- & Ausgabe völlig ausreicht, wenns um spezielle Lösungen geht oder auch nur, um mal eben was zu probieren

-
Ich zerbreche mir übrigens die ganze Zeit den Kopf, ob ich Dir diese kleine Freude nicht auch in reinem PureBasic für Linux bescheren könnte. Aber nach reiflichem Nachdenken glaube ich nicht, dass das funktioniert. Ein Hauptziel ist ja, dass wir keinen EventLoop schreiben müssen. Unter Windows kann ich Sachen wie das Bearbeiten von Größenänderungen des Fensters oder das Neuzeichnen desselben, wenn der Anwender es aus dem Desktop herausgeschoben hat oder es von anderen Fenstern verdeckt wurde, durch das Umbiegen der Hauptfensterprozedur (oder noch eleganter durch deren Anzapfen via Subclassing) automatisch erledigen. Mit reinem (portablem) PureBasic sehe ich nicht, wie das gehen könnte. Auch die Abfrage der Tastatur für InputS() ist in reinem PureBasic eine Qual. Daher bleibt das wohl leider eine Windows-Spielerei.
-
ja - einige Sachen sind in PureBasic komplett anders zu handhaben. Da sind wir in einigen Bereichen mit XProfan schon etwas verwöhnt.
Aber Danke für das "Kopf zerbrechen"
Das jetzt für Linux umzusetzen, wäre Wahnsinn - ich seh da auch kaum Möglichkeiten.
Habe in dieser Richtung vor einiger Zeit mit OpenConsole() gespielt und die Beispiele in der Hilfe probiert. Dort ist auch kein EventLoop nötig. Wenn ich das dann direkt aus der IDE starte, funktioniert das auch. Aber sobald ich das Programm als ausführbare Datei starten möchte, ist nix zu sehen.
Möglicherweise liegt das wohl eher an Linux, irgendwas übersehe ich dort.
Werd mal bei Gelegenheit nochmal einen Versuch starten - werd dann berichten...schon witzig, das wir uns in der XProfan-Ecke über PureBasic unterhalten

-
Was auch noch interessant wäre :
wenn RGH beim Delimiter (D) die reg. Ausdrücke als Alternative mit einbeziehen könnte. Ob jetzt nach einem Komma o.ä. gesucht wird oder halt das Ergebnis des reg. Ausdrucks. So hätte man blitzschnell die Ergebnisse in der Listboxliste zum Weiterverarbeiten.
Oder alternativ ein
Wäre viell. schnell als das hier :
Code
Alles anzeigenDeclare String z z = "123 plus 456 plus 789 ergibt 1068" Move("MatchToList", "[0-9]{1,}", z) Print Move("ListToStr", ",") SubProc Move.MatchToList Parameters String match, s Declare Long x x = 1 ClearList Set("RegEx", 1) While Instr(match, s, x) <> 0 AddString(0, $Match) Inc x, %MatchLen + %MatchPos EndWhile Set("RegEx", 0) EndProc waitkeyMir ergeht es halt oft so, daß meine selbgemachten Funktionen mit der Zeit immer in den Tiefen meines Quellcode - oder Include - Ordners verschwinden. Nach dem Motto : Da hab ich mal was gemacht und such..., such . Was Eingebautes und in der Hilfe Erwähntes ist mir da viel lieber, da ich die Hilfe, wie viele andere auch, immer offen und zur Hand habe.
-
Bin gerade mal über den Befehl
gestolpert und habe bei XProfan.net einiges gelesen.
Da der Befehl ja nur im Interpreter geht, ist es ja auch ziemlich sinnfrei.
Früher, zu DOS-Zeiten, gab es mal in Turbo Pascal 4.5
in der IDE einen Menü - Befehl :Zitat
Compile to MemoryDamit konnte man ins Memory compilieren. War interessant, um nicht immer
auf Diskette zu kompileren und auszuführen. Und es war logischerweise auch
viel schneller in der Ausführung.Vielleicht wäre so was auch für XProfan möglich (eine Art Scriptsprache) ?
Der bereich# müßte dann intern auf die richtige Größe gebracht werden
und könnte dann auch mitaufgerufen werden. Oder evtl. auch über eine Systemvariable.
CodeSet("Memory", 1) aktiviert einen bereich#, der von Compile(bef, bereich) genutzt wird. Call &Memory, [P1, P2...PN]Das wäre dann praktisch eine compilierte .prc - Datei im RAM, die dann die
Runtime aufruft. Ein selber compiliertes XProfan- Programm macht ja auch
nichts anderes.Wäre mal wieder so eine Idee von mir.
-
Absolut tolle Vorschläge. Nicht nur sinnvoll, sondern richtig brauchbar. Allerdings besteht wohl wenig bis gar keine Aussicht auf Umsetzung, angesichts der (ausbleibenden) Reaktionen seitens RGH.
Habe in den vergangenen Wochen mal etwas mit PB und Lazarus/FP rumgemacht. Haben aber beide, wie alles Menschengemachte, ihre Vor-/Nachteile und auch Defizite. Defizite vor allem in der Dokumentation und Beschreibung der Optionen/Funktionen. Da gibt es einerseits sporadisch Hinweise auf Parameter und Funktionen, andererseits aber keinerlei Erklärungen oder Dokumentation dazu. Manchmal nicht mal in den Foren. Da bleibt dann nur Trial & Error - suboptimal.
Die Integration einer Datenbank in der L/FP Umgebung löste bei mir tatsächlich mehrmals Kopfschütteln aus. WTF? Dafür gibt es dort ein sehr detailliert ausgeführtes Grid mit dem man schnell mal eine sehr ansprechende funktionale Datentabelle erstellen kann. Die Datenbankintegration bei PB ist deutlich einfacher und vergleichbar mit RGH's XP. Der Umgang mit Arrays ist bei PB leider semioptimal gelöst. Irgendwie wünsche ich mir immer wieder, es gäbe PHP als echte Programmiersprache für alle OS und nicht nur als Server Scriptsprache.
RGH's XP hätte mit Sicherheit auch weiterhin großes Potential, ausgehend vom Gesamtkonzept und der kompetenten Umsetzung (wenn man von der Tilde bei den RegExen absieht LOL). Aber mittlerweile sind Jahre der Stagnation ins Land gegangen. Das macht wenig Hoffnung auf ein Comeback bzw. Update. Was is nu, Roland? Gib mal Laut

-
Genau das mag ich ja an XProfan, was auch die Dokumentation anbetrifft. Wo es notwendig ist, läßt RGH ja auch manchmal unter die Haube (von XProfan aber auch Windows) blicken, wenn es dem Verständnis zugute kommen soll.
Was den aktuellen Entwicklungsstand von XProfan angeht, da hast du wohl Recht. Da hätte besonders in den vergangenen Monaten mehr von RGH kommen müssen, wie etwa : "Gute Idee", "Kann ich umsetzen", "so ist der momentane Stand", usw. oder auch, wenn etwas nicht umsetzbar ist.
So tappen wir da leider im Dunkeln und sind andererseits voller Hoffnung.
-
Was die anderen Dinge betrifft sammele ich erst mal und werde Anfang nächsten Jahre eine abschließende Version herausbringen.
Was nun den Fortschritt von XProfan betrifft, bin ich dennoch, trotz fehlender Kommunikation, etwas zuversichtlich. Wir kennen RGH ja schon lange genug und ich denke daß er da sein Versprechen doch noch einhalten wird. Mein Vorschlag, den Interpreter zum Probieren freizugeben, kann er ja auch anders sehen. Wenn ich mir so die Python-Gemeinde ansehe, gibt es doch haufenweise Anwender, die ihr Python-Script per Python-Interpreter ausführen und auf eine ausführbare .exe gar nicht angewiesen sind. Gleiches könnte man ja auch mit dem Profan-Interpreter, der ja auch kommandozeilenorientiert arbeitet, machen. Wenn es nicht gerade auf Millisekunden ankommt, spürt man ja kaum oder garnicht den Geschwindigkeitsunterschied. Das würde ja wiederum den einen oder anderen vom Kauf einer Vollversion bzw. Updates abhalten.
Vielleicht gibt RGH erst das Gesamtpaket zum Kauf bzw. Update frei, wenn alles abgearbeitet ist. Mit eingeschlossen könnte ja auch die Anhebung der 64Bit Version sein. Und sowas dauert halt schon eine ganze Weile. Ist halt ein Einmann-Projekt. Das Interesse von RGH scheint ja da zu sein. Nicht umsonst ist er ja fast täglich öfters lesend hier im Forum zugegen. Das wäre bei einem Desinteresse ja nicht der Fall.
-
Heute nur ein kurzer Hinweis:
Ich werde demnächst meine Mail-Adresse ...@t-online.de löschen, da diese nur noch Probleme bereitet. (Es ist halte eine kostenlose Mail-Adresse, wo man wenige Möglichkeiten hat.)
Bitte nutzt künftig: rgh-soft(at)rgh-soft.de
Die Domain gehört mir.
Einen schönen Vatertag!
Gruß
Roland
-
Hallo,
ich hätte da noch eine Idee, falls Roland ja doch noch eine neue Endversion 5 plant. Ud zwar könnte er doch wieder mal eine SubScription starten. Aber diesmal eine kostenlose für alle. Viele Augen sehen ja auch mehr und etwaige Fehlerbereinigungen, Zusatzwünsche usw. könnten so noch einfließen. Das finde ich besser, als wenn (wie in der Vergangenheit) irgendwelche Patches nach der Fertigstellung von RGH nachgereicht werden. Die vergißt man auch schnell mal, wenn z.B. eine Neuinstallation ansteht, sei es ein neur PC oder HDD oder was auch immer.
Mir schwebt da vor, NUR den Interpreter hier im Forum anzubieten. Den könnte RGH doch auch mit einem z. b. Splash-Screen ("Demo, Nur für Testzwecke") versehen. Halt so, daß der Interpreter für den dauerhaften Gebrauch uninteressant ist und auch nervt. Oder er baut sonst noch eine Schikane ein. Sowas wurde ja früher auch gerne gemacht und ist auch heute noch bei vielen Spielen oder sonstiger Software der Fall.
Damit hätte er dann auch mehr Tester. Wer dann Interesse hat, kauft dann eine neue Vollversion oder Update.
-
Moin!
Jetzt wäre es einmal schön gewesen, hätte RGH einen Satz zur Zukunft von XProfan fallen lassen. Aber gut!Ich will mich gar nicht mehr zur Zukunft von XProfan äußern. Ich ziehe meinen Hut vor RGH, denn eine solche Sprache zu entwickeln und über Jahre zu erweitern, einen Platz zu erobern, das ist schon eine großartige Leistung.
Aber tut er sich wirklich einen Gefallen damit, wenn er eine X5-Version entwickelt? Mal ehrlich: Wie groß ist denn das Marktpotenzial dieser Sprache in der heutigen Zeit? Liegt doch bei Null. Selbst wenn er X4 komplett als Freeware freigeben würde, interessierte sich kaum noch jemand dafür, weil die Zeit und die Anforderungen an Programmiersprachen extrem vorangeschritten sind und XProfan sie nicht erfüllen kann.
-
Naja, zum Erlernen von Variablen, Arrays usw. und Kontrollstrukturen kann ich es immer wieder nur empfeheln. Und das ist bei jeder Sprache gleich, mal abgesehen von minimalen Syntax-Unterschieden. Nirgendwo wird der Einstieg so leicht gemacht, wo man blitzschnell zu Ergebnissen kommt. Wenn ich mal PureBasic mit seinem Debug-Zeugs sehe : oh Gott.
Marktpotential gibt es bei Nischensprachen nicht mehr so oft. Das hat Roland ja bereits erkannt. Sieht man ja auch an PureBasic. Dort gibt es auch kaum Neuzugänge trotz internationalem Auftreten. Es geht viel mehr darum, daß RGH XProfan noch eine Weile am Leben erhält.Eine Sprache, die über Jahrzenhnte gediegen ist, sollte man nicht so einfach wegwerfen. Da steckt ja ein gutes Stück Lebenszeit von RGH drin.
Was eine evtl Version X5 bzw. Update angeht, gebe ich dir Recht. Er antwortet mir sogar nicht per E-Mail, wenn ich ihm Vorschläge per (Verbesserungen bzw. neue Funktionalität) schicke. Auf eine Antwort, wie "Gute Idee", "kann ich machen", "geht nicht so einfach" o. ä. warte ich vergebens.
-
Vielleicht noch ein Wort an Roland, falls er dennoch eine versprochene Endversion (Version 5) in Vorbereitung hat, aber noch nicht ganz fertig ist.
Wie wäre es denn mit einer weiteren kostenpflichtigen (wie gehabt etwa 25 €) Subscription ? Der Interpreter würde ja auch zum Testen reichen. Dann könnten wir noch eventuelle Fehler melden oder auch Erweiterungen bzw. Wünsche könnten noch vor Abschluß mit einfließen. Wir User sehen ja manchmal noch Fehler bzw. Ungereimtheiten, die Roland entgangen sind. War ja in der Vergangenheit schon öfter so. Keiner ist halt unfehlbar und mehrere Augenpaare sehen halt mehr als eines. Damit könnten ja dann auch unnötige spätere Patches vermieden werden. Roland könnte ja den Teilnehmern eine Nummer zuweisen, die dann beim Kauf eines Updates oder Vollversion berücksichtigt wird und den Kaufpreis halt um den Subscriptionsbetrag verringert. Mir wäre es lieb, wenn ich dann da eine CD-Vollversionerwerben könnte, die ohne Patches auskommt und auch komplett ist. Eine angehobene 64-Bit Version auf Version 5 (mit Lazarus erstellt) sollte natürlich auch dabei sein.
PS:
Vielleicht wäre hier im Forum auch eine Liste hilfreich, in die sich Interessierte für ein Update oder Vollversion eintragen könnten, um überhaupt mal zu sehen, wie groß das Interesse ist und sich eine letzte Weiterentwicklung lohnt. Wenn ich hier im Forum irgendeinen Code für XProfan einstelle, habe ich nach einem oder ein paar Tagen mehr als Hundert Zugriffe darauf. Die Zahl muß man zwar auch noch etwas revidieren, da manche ja auch zwei- oder dreimal darauf zugreifen. Aber immerhin bleiben da ja noch einige Interessierte übrig.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!