BlitzMax Opensource! & Free

Übersicht

Sonstiges

Smalltalk

Gehe zu Seite Zurück 1, 2, 3

	Jan_ Ehemaliger Admin	Mo, Okt 05, 2015 9:57 Antworten mit Zitat
@hectic, schön, dass noch jemand meiner Meinung ist. Eine Erweiterung von Blitzmax zu einer Kongurenzfähigen Sprache - sinnfrei Andere Targets- Ja, juhu, weil auf dem PC kein Kind mehr spielen will. Einfachere Strukturen anbieten: Ja, auf jeden Fall. Was haben wir hier Jahre lang gemacht: Types statt arrays gepredigt, doch das war denn Noobs zu schwer. Wer ist die Zielgruppe von Blitz? Das sind die kleinen Männel, die Bruzard gemalt hat:YAN - misst eingepullert. Wie kommen sie an die Sprache heran: Bücher, internet, Handy - hier macht das Target Handy viel sinn. Fasse ich meine Vorstellung zusammen: ein geändertes Blitz3d für Handys, mit einem Buch von René, spielen im Appstore wie Stranded, Blitzpong, Crillon z, Dogfigth, don't get angry, sheepwars, ... Wenn das nicht erreichbar ist, sind alle Anstrengungen umsonst. Scheiß auf OOP.
between angels and insects

Jan_

Ehemaliger Admin

Mo, Okt 05, 2015 9:57
Antworten mit Zitat

@hectic, schön, dass noch jemand meiner Meinung ist.

Eine Erweiterung von Blitzmax zu einer Kongurenzfähigen Sprache - sinnfrei

Andere Targets- Ja, juhu, weil auf dem PC kein Kind mehr spielen will.

Einfachere Strukturen anbieten: Ja, auf jeden Fall.

Was haben wir hier Jahre lang gemacht: Types statt arrays gepredigt, doch das war denn Noobs zu schwer.

Wer ist die Zielgruppe von Blitz?
Das sind die kleinen Männel, die Bruzard gemalt hat:YAN - misst eingepullert.
Wie kommen sie an die Sprache heran: Bücher, internet, Handy - hier macht das Target Handy viel sinn.

Fasse ich meine Vorstellung zusammen:
ein geändertes Blitz3d für Handys, mit einem Buch von René, spielen im Appstore wie Stranded, Blitzpong, Crillon z, Dogfigth, don't get angry, sheepwars, ...

Wenn das nicht erreichbar ist, sind alle Anstrengungen umsonst.

Scheiß auf OOP.

between angels and insects

	DAK	Mo, Okt 05, 2015 16:25 Antworten mit Zitat
Handy-Target wird recht schwer, hauptsächlich deswegen, weil z.B. unter Android die Programmstruktur komplett anders ist als unter Windows. So verlangt Android z.B. Methoden wie onCreate(), onPause(), onResume(), usw., die für Windows nicht nötig sind. Noch dazu ist der Flow der Applikation unter Windows und Android komplett anders. Unter Windows rennt ein Programm von dem Zeitpunkt wo es gestartet wird, bis zu den Zeitpunkt, wo es von sich aus schließt. Ein Klick auf das X rechts oben wird von dem Programm als Input genommen und das Programm muss sich dann selbstständig schließen. Unter Android rennt das Programm bis der User es schließt. Die Datenstruktur um ein Projekt ist unter Android auch recht stark genormt. Ich denke, ein Handy-Target ohne Verkomplizierung für den User wird nicht möglich sein. Deswegen schaut Monkey ja auch so aus wie es ausschaut, um diesen Bedingungen entgegen zu kommen. Ein HTML5-Target sollte einfacher gehen, solange es dabei klar ist, dass nicht alle Features verwendet werden können (beginnend bei z.B. Programm Beenden). Erweiterungen auf hohem Niveau zahlen sich kaum aus. Die Leute, die so hohe Features verwenden (z.B. wirklich tolles Threading) verwenden meistens schon Sprachen, die das können. Zahlt sich denke ich nur aus, wenn die Features schnell implementiert sind. Inkompatible Änderungen sollten echt nicht der Fall sein. Wenn normaler BMax-Code drauf nicht rennt, dann macht man sich die Codebase kaputt. OOP sollte auf keinen Fall rausfliegen, allerdings zahlt sich eine Erweiterung wohl auch kaum aus. Bei LLVM weiß ich nicht, ob sich das wirklich auszahlt. Wer programmiert schon auf Alpha- oder Spark-Rechnern? Die einzigen Targets die irgendwie Sinn machen (neben x86) sind emscripten und ARM. Fragt sich, ob die Performance den Aufwand wert ist. Die wenigsten Anfänger werden an ein echtes Performancelimit stoßen. Goto im Strict Mode sollte es nicht geben, ihmo. Das würde den Sinn vom Strict Mode verunstalten. Eventuell könnte man einen Semistrict Mode oder so machen, der das wieder erlaubt.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mo, Okt 05, 2015 16:25
Antworten mit Zitat

Handy-Target wird recht schwer, hauptsächlich deswegen, weil z.B. unter Android die Programmstruktur komplett anders ist als unter Windows. So verlangt Android z.B. Methoden wie onCreate(), onPause(), onResume(), usw., die für Windows nicht nötig sind.

Noch dazu ist der Flow der Applikation unter Windows und Android komplett anders. Unter Windows rennt ein Programm von dem Zeitpunkt wo es gestartet wird, bis zu den Zeitpunkt, wo es von sich aus schließt. Ein Klick auf das X rechts oben wird von dem Programm als Input genommen und das Programm muss sich dann selbstständig schließen.

Unter Android rennt das Programm bis der User es schließt.

Die Datenstruktur um ein Projekt ist unter Android auch recht stark genormt.

Ich denke, ein Handy-Target ohne Verkomplizierung für den User wird nicht möglich sein. Deswegen schaut Monkey ja auch so aus wie es ausschaut, um diesen Bedingungen entgegen zu kommen.

Ein HTML5-Target sollte einfacher gehen, solange es dabei klar ist, dass nicht alle Features verwendet werden können (beginnend bei z.B. Programm Beenden).

Erweiterungen auf hohem Niveau zahlen sich kaum aus. Die Leute, die so hohe Features verwenden (z.B. wirklich tolles Threading) verwenden meistens schon Sprachen, die das können. Zahlt sich denke ich nur aus, wenn die Features schnell implementiert sind.

Inkompatible Änderungen sollten echt nicht der Fall sein. Wenn normaler BMax-Code drauf nicht rennt, dann macht man sich die Codebase kaputt. OOP sollte auf keinen Fall rausfliegen, allerdings zahlt sich eine Erweiterung wohl auch kaum aus.

Bei LLVM weiß ich nicht, ob sich das wirklich auszahlt. Wer programmiert schon auf Alpha- oder Spark-Rechnern? Die einzigen Targets die irgendwie Sinn machen (neben x86) sind emscripten und ARM. Fragt sich, ob die Performance den Aufwand wert ist. Die wenigsten Anfänger werden an ein echtes Performancelimit stoßen.

Goto im Strict Mode sollte es nicht geben, ihmo. Das würde den Sinn vom Strict Mode verunstalten. Eventuell könnte man einen Semistrict Mode oder so machen, der das wieder erlaubt.

Gewinner der 6. und der 68. BlitzCodeCompo

	Thunder	Mo, Okt 05, 2015 18:02 Antworten mit Zitat
Jan_ hat Folgendes geschrieben: Andere Targets- Ja, juhu, weil auf dem PC kein Kind mehr spielen will. PC Games sind noch lange nicht tot (auch nicht bei den Jungen). Siehe Steam. DAK hat Folgendes geschrieben: Bei LLVM weiß ich nicht, ob sich das wirklich auszahlt. Wer programmiert schon auf Alpha- oder Spark-Rechnern? Die einzigen Targets die irgendwie Sinn machen (neben x86) sind emscripten und ARM. Fragt sich, ob die Performance den Aufwand wert ist. Die wenigsten Anfänger werden an ein echtes Performancelimit stoßen. Das ist wahr. Du sparst dir halt damit das Modul für x86_64. Also entweder man schreibt noch ein Modul für x86_64, das auch fasm generiert oder eins, das LLVM IR produziert. DAK hat Folgendes geschrieben: Goto im Strict Mode sollte es nicht geben, ihmo. Das würde den Sinn vom Strict Mode verunstalten. Eventuell könnte man einen Semistrict Mode oder so machen, der das wieder erlaubt. Dachte mir schon, dass du das meinst. In meinem Fork passiert es bestimmt. Goto ist ein Teil von Basic. Man muss es ja nicht verwenden. Ich will sowieso Strict und SuperStrict loswerden, da denke ich nicht über einen Semistrictmode nach.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mo, Okt 05, 2015 18:02
Antworten mit Zitat

Jan_ hat Folgendes geschrieben:

Andere Targets- Ja, juhu, weil auf dem PC kein Kind mehr spielen will.

PC Games sind noch lange nicht tot (auch nicht bei den Jungen). Siehe Steam.

DAK hat Folgendes geschrieben:

Bei LLVM weiß ich nicht, ob sich das wirklich auszahlt. Wer programmiert schon auf Alpha- oder Spark-Rechnern? Die einzigen Targets die irgendwie Sinn machen (neben x86) sind emscripten und ARM. Fragt sich, ob die Performance den Aufwand wert ist. Die wenigsten Anfänger werden an ein echtes Performancelimit stoßen.

Das ist wahr. Du sparst dir halt damit das Modul für x86_64. Also entweder man schreibt noch ein Modul für x86_64, das auch fasm generiert oder eins, das LLVM IR produziert.

DAK hat Folgendes geschrieben:

Goto im Strict Mode sollte es nicht geben, ihmo. Das würde den Sinn vom Strict Mode verunstalten. Eventuell könnte man einen Semistrict Mode oder so machen, der das wieder erlaubt.

Dachte mir schon, dass du das meinst. In meinem Fork passiert es bestimmt.
Goto ist ein Teil von Basic. Man muss es ja nicht verwenden. Ich will sowieso Strict und SuperStrict loswerden, da denke ich nicht über einen Semistrictmode nach.

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	Holzchopf Meisterpacker	Mo, Okt 05, 2015 18:29 Antworten mit Zitat
Ich bin strikt gegen die Einführung von Goto. Und gegen die Abschaffung von Superstrict und Strict. Basic kann meiner Meinung nach Basic bleiben, auch mit Superstrict. Und auch ohne Goto. Ich verwende Goto schon so lange nicht mehr, dass ich nichtmal weiss, ob es noch möglich ist, mit Goto aus einem Scope zu springen und so den GC zu töten. Wenn ja: Dann tu's deinem Fork an, aber lass BlitzMax bitte von Goto verschont
Erledige alles Schritt um Schritt - erledige alles. - Holzchopf CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018) Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

Holzchopf

Meisterpacker

Mo, Okt 05, 2015 18:29
Antworten mit Zitat

Ich bin strikt gegen die Einführung von Goto. Und gegen die Abschaffung von Superstrict und Strict. Basic kann meiner Meinung nach Basic bleiben, auch mit Superstrict. Und auch ohne Goto. Ich verwende Goto schon so lange nicht mehr, dass ich nichtmal weiss, ob es noch möglich ist, mit Goto aus einem Scope zu springen und so den GC zu töten. Wenn ja: Dann tu's deinem Fork an, aber lass BlitzMax bitte von Goto verschont Wink

Erledige alles Schritt um Schritt - erledige alles. - Holzchopf
CC BY ♫ BinaryBorn - Yogurt ♫ (31.10.2018)
Im Kopf da knackt's und knistert's sturm - 's ist kein Gedanke, nur ein Wurm

	DAK	Mo, Okt 05, 2015 19:03 Antworten mit Zitat
Finde ich auch. Man braucht ja Superstrict nicht verwenden. @Holzchopf: Scopespringen geht nicht mit Goto, insofern ist es eh kein Basic-Goto mehr.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mo, Okt 05, 2015 19:03
Antworten mit Zitat

Finde ich auch. Man braucht ja Superstrict nicht verwenden.
@Holzchopf: Scopespringen geht nicht mit Goto, insofern ist es eh kein Basic-Goto mehr.

Gewinner der 6. und der 68. BlitzCodeCompo

	CO2 ehemals "SirMO"	Mo, Okt 05, 2015 22:46 Antworten mit Zitat
Was wollen denn alle mit anderen Targets? Es sollte doch jedem klar sein, dass man diese nicht miteinander vergleichen kann, was deren Leistungsfähigkeit angeht. Möchte man ein Spiel - und ich rede von einem richtigen Spiel - programmieren, ist das Target gleich klar: Rechner. Möchte ich Internetgedöns machen, nehme ich HTML5... Warum sollte es eine Sprache geben, die alle Targets beglücken kann? Das ist dann wieder so eine eierlegende Wollmilchsau! Ich denke, man sollte die bestehenden Konzepte erstmal zuende denken: So ist die OOP aus mehrfacher Sicht "lieblos" umgesetzt: Keine Sichtbarkeiten, etc. Wenn man das hat, kann man über das andere Zeug nachdenken wie verschiedene Targets... PS: Jan_ hat Folgendes geschrieben: Scheiß auf OOP. - Ok, verschiedene Targets müssen her, aber OOP ist vernachlässigbar? Was zur Hölle? [ironie]Scheiß auf Funktionen.[/ironie]
mfG, CO² Sprachen: BlitzMax, C, C++, C#, Java Hardware: Windows 7 Ultimate 64-Bit, AMX FX-6350 (6x3,9 GHz), 32 GB RAM, Nvidia GeForce GTX 750 Ti

CO2

ehemals "SirMO"

Mo, Okt 05, 2015 22:46
Antworten mit Zitat

Was wollen denn alle mit anderen Targets? Es sollte doch jedem klar sein, dass man diese nicht miteinander vergleichen kann, was deren Leistungsfähigkeit angeht. Möchte man ein Spiel - und ich rede von einem richtigen Spiel - programmieren, ist das Target gleich klar: Rechner. Möchte ich Internetgedöns machen, nehme ich HTML5... Warum sollte es eine Sprache geben, die alle Targets beglücken kann? Das ist dann wieder so eine eierlegende Wollmilchsau!
Ich denke, man sollte die bestehenden Konzepte erstmal zuende denken: So ist die OOP aus mehrfacher Sicht "lieblos" umgesetzt: Keine Sichtbarkeiten, etc. Wenn man das hat, kann man über das andere Zeug nachdenken wie verschiedene Targets...

PS:
Jan_ hat Folgendes geschrieben:

Scheiß auf OOP.

- Ok, verschiedene Targets müssen her, aber OOP ist vernachlässigbar? Was zur Hölle?
[ironie]Scheiß auf Funktionen.[/ironie]

mfG, CO²

Sprachen: BlitzMax, C, C++, C#, Java
Hardware: Windows 7 Ultimate 64-Bit, AMX FX-6350 (6x3,9 GHz), 32 GB RAM, Nvidia GeForce GTX 750 Ti

	Tennisball	Mo, Okt 05, 2015 22:58 Antworten mit Zitat
CO2 hat Folgendes geschrieben: Möchte man ein Spiel - und ich rede von einem richtigen Spiel - programmieren, ist das Target gleich klar: Rechner. Definiere "richtiges Spiel". Tetris ist in meinen Augen ein richtiges Spiel und läuft sauber auf allen erdenklichen Geräten, angefangen beim GameBoy über Tablets bis hin zum Rechner aber eben auch im Browser. Warum ist es so klar, dass das Target für Spiele der PC sein sollte? Und da man sich hier anscheinend sowieso nie einig wird unterlasse ich es mal meinen eigenen Senf auch noch dazu zu geben.

Tennisball

Mo, Okt 05, 2015 22:58
Antworten mit Zitat

CO2 hat Folgendes geschrieben:

Möchte man ein Spiel - und ich rede von einem richtigen Spiel - programmieren, ist das Target gleich klar: Rechner.

Definiere "richtiges Spiel". Tetris ist in meinen Augen ein richtiges Spiel und läuft sauber auf allen erdenklichen Geräten, angefangen beim GameBoy über Tablets bis hin zum Rechner aber eben auch im Browser. Warum ist es so klar, dass das Target für Spiele der PC sein sollte?

Und da man sich hier anscheinend sowieso nie einig wird unterlasse ich es mal meinen eigenen Senf auch noch dazu zu geben.

	Thunder	Mo, Okt 05, 2015 23:04 Antworten mit Zitat
@Tennisball: Ich glaube CO2 wollte (er darf mich gerne korrigieren) darauf hinaus, dass es unrealistisch ist, eine Sprache zu haben, die auf allen Targets ein Spiel erzeugen kann, das in annehmbarer Geschwindigkeit läuft, oder auch, dass die mehreren Targets auf Kosten von Features gehen, die zwar auf dem PC funktionieren würden, aber wegen der anderen Targets nicht benutzt werden. Bin schon der Meinung, dass du in einer ruhigen Minute deinen Senf beisteuern kannst, hier geht es lang nicht mehr darum einig zu werden. Aber vielleicht findet man ja doch Ideen von anderen interessant und kann darüber reden. @Goto: Dass wegen einem kleinen Feature alle eskalieren...
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mo, Okt 05, 2015 23:04
Antworten mit Zitat

@Tennisball: Ich glaube CO2 wollte (er darf mich gerne korrigieren) darauf hinaus, dass es unrealistisch ist, eine Sprache zu haben, die auf allen Targets ein Spiel erzeugen kann, das in annehmbarer Geschwindigkeit läuft, oder auch, dass die mehreren Targets auf Kosten von Features gehen, die zwar auf dem PC funktionieren würden, aber wegen der anderen Targets nicht benutzt werden.

Bin schon der Meinung, dass du in einer ruhigen Minute deinen Senf beisteuern kannst, hier geht es lang nicht mehr darum einig zu werden.
Aber vielleicht findet man ja doch Ideen von anderen interessant und kann darüber reden.

@Goto: Dass wegen einem kleinen Feature alle eskalieren... Rolling Eyes

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	Tennisball	Mo, Okt 05, 2015 23:12 Antworten mit Zitat
Thunder hat Folgendes geschrieben: @Tennisball: Ich glaube CO2 wollte (er darf mich gerne korrigieren) darauf hinaus, dass es unrealistisch ist, eine Sprache zu haben, die auf allen Targets ein Spiel erzeugen kann, das in annehmbarer Geschwindigkeit läuft, oder auch, dass die mehreren Targets auf Kosten von Features gehen, die zwar auf dem PC funktionieren würden, aber wegen der anderen Targets nicht benutzt werden. So gesehen ist das teilweise richtig. Es gibt allerdings auch Dinge die mit einem Smartphone besser funktionieren als mit einem PC. Beispielsweise kann man einen PC-Bildschirm nicht ohne weiteres schnell um 90° drehen. Um dieses "Gefühl" mit einem PC zu rekonstruieren bedürfte es z.B. schon eines Lenkrads, und die breite Masse hat sowas eben nicht. Thunder hat Folgendes geschrieben: [...] hier geht es lang nicht mehr darum einig zu werden. Die Ursprungsidee war ja, BlitzMax weiterzuentwickeln. Dass das aufgrund der Größe des Projekts nicht im Alleingang geht ist ja offensichtlich. Also hab ich das wohl richtig verstanden, dass das Ziel endgültig verworfen wurde. Gruß und schönen Abend noch, Tennisball

Tennisball

Mo, Okt 05, 2015 23:12
Antworten mit Zitat

Thunder hat Folgendes geschrieben:

So gesehen ist das teilweise richtig. Es gibt allerdings auch Dinge die mit einem Smartphone besser funktionieren als mit einem PC. Beispielsweise kann man einen PC-Bildschirm nicht ohne weiteres schnell um 90° drehen. Um dieses "Gefühl" mit einem PC zu rekonstruieren bedürfte es z.B. schon eines Lenkrads, und die breite Masse hat sowas eben nicht.

Thunder hat Folgendes geschrieben:

[...] hier geht es lang nicht mehr darum einig zu werden.

Die Ursprungsidee war ja, BlitzMax weiterzuentwickeln. Dass das aufgrund der Größe des Projekts nicht im Alleingang geht ist ja offensichtlich. Also hab ich das wohl richtig verstanden, dass das Ziel endgültig verworfen wurde.

Gruß und schönen Abend noch,
Tennisball

	DAK	Mi, Okt 07, 2015 10:07 Antworten mit Zitat
Ich hab mich gestern mal etwas intensiver mit dem Code auseinandergesetzt. Ich hab ja schon vieles gesehen, aber! Der Code ist echt grauenhaft. Kommentare sind seltener als Einhörner. Variablen- und Funktionsnamen sind oft abgekürzt und oft wenig aussagekräftig (z.B. wer kann sich unter parsePriExp(), parsePostExp() und parsePreExp() was vorstellen? Kleiner Tipp: parsePostExp() wird vor parsePreExp() aufgerufen). Ich hab ein nettes Kommentar in parser.cpp gefunden, das den Code gut beschreibt: Mark Sibly hat Folgendes geschrieben: //Yuck! This extremely nasty hack allows for 'bracketless' fun invocation by statements... fun steht hier für function. Mark mag das Wort scheinbar nicht, er kürzt es immer so ab Alles in allem: Ich wollte ein kleines Feature (Stacktraces) einbauen, aber der Code macht das echt schwer.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Okt 07, 2015 10:07
Antworten mit Zitat

Ich hab mich gestern mal etwas intensiver mit dem Code auseinandergesetzt. Ich hab ja schon vieles gesehen, aber!

Der Code ist echt grauenhaft. Kommentare sind seltener als Einhörner. Variablen- und Funktionsnamen sind oft abgekürzt und oft wenig aussagekräftig (z.B. wer kann sich unter parsePriExp(), parsePostExp() und parsePreExp() was vorstellen? Kleiner Tipp: parsePostExp() wird vor parsePreExp() aufgerufen).
Ich hab ein nettes Kommentar in parser.cpp gefunden, das den Code gut beschreibt:

Mark Sibly hat Folgendes geschrieben:

//Yuck! This extremely nasty hack allows for 'bracketless' fun invocation by statements...

fun steht hier für function. Mark mag das Wort scheinbar nicht, er kürzt es immer so ab Wink

Alles in allem: Ich wollte ein kleines Feature (Stacktraces) einbauen, aber der Code macht das echt schwer.

Gewinner der 6. und der 68. BlitzCodeCompo

	Thunder	Mi, Okt 07, 2015 12:28 Antworten mit Zitat
Hast du dir den Code von Blitz3D/BlitzPlus Mal angeschaut? (Template-Horror ) Dagegen ist der BMax-Code sehr hübsch. Aber musst du für Stacktraces so tief in den Compiler?
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mi, Okt 07, 2015 12:28
Antworten mit Zitat

Hast du dir den Code von Blitz3D/BlitzPlus Mal angeschaut? (Template-Horror Shocked

)
Dagegen ist der BMax-Code sehr hübsch.

Aber musst du für Stacktraces so tief in den Compiler?

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	DAK	Mi, Okt 07, 2015 15:35 Antworten mit Zitat
Bei B+/B3D, da hab ich mir's nicht angetan. Trotzdem ist BMax nicht gerade schön. Ich hab kein Builtin oder so gefunden, dass das tut, also hab ich mal angefangen, den Compiler durchzulesen. Ich mein, wenn man wollte, dann könnte man das ganz leicht mit einem Precompiler erledigen, aber ich wollte es eigentlich direkt einbauen.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Okt 07, 2015 15:35
Antworten mit Zitat

Bei B+/B3D, da hab ich mir's nicht angetan. Trotzdem ist BMax nicht gerade schön.

Ich hab kein Builtin oder so gefunden, dass das tut, also hab ich mal angefangen, den Compiler durchzulesen. Ich mein, wenn man wollte, dann könnte man das ganz leicht mit einem Precompiler erledigen, aber ich wollte es eigentlich direkt einbauen.

Gewinner der 6. und der 68. BlitzCodeCompo

	Tritium	So, Nov 01, 2015 15:03 Antworten mit Zitat
Hallo zusammen, ich bin nur noch selten hier unterwegs, hab die Diskussion aber mit großem Interesse gelesen. Mir ist dabei folgender Gedanke gekommen: Wie wäre es denn, wenn man sich nicht darüber unterhält, auf wie vielen Plattformen BMax funktionieren soll oder wie die Syntax erweitert werden könnte, sondern wenn man sich als erstes Ziel setzt, den bestehenden Code so zu überarbeiten, dass er lesbar und dokumentiert ist? Also dass man, statt sich um neue Features zu kümmern, erstmal versucht das bestehende zu überarbeiten und wart-/lesbar zu machen und dann im zweiten Schritt die halbherzig implementierten Features (Sichtbarkeit, OOP, etc.) fertigstellt? Ich weiß, ist immer Definitionssache was "fertiggestellt" bedeutet, hier gabs aber schonmal einen Thread, was sich die Nutzer hier im Forum von BMax 2.0 wünschen würden. Für mich waren BlitzBasic (mit Rene Meyers Buch ) und BlitzMax immer auf die Hobby-Entwickler ausgerichtet, die (damals noch mit DirectX7) kleine bis mittelgroße 2D- und 3D-Spieleprojekte für sich und einen tendenziell eher kleinen Kreis von Leuten entwickelt haben, um damit gemeinsam Spaß auf LAN-Partys zu haben und die Freude am Gamedesign/-programmierung zu teilen. Einige haben es dann sogar geschafft, die Spiele einem größeren Kreis bekannt zu machen und evtl. auch Geld damit zu verdienen. An BlitzMax gefiel mir insb. der modulare Ansatz, sodass man mit einem sehr grundlegenden Befehlssatz anfängt und den dann durch Module auf die Sachen erweitert, die man fürs eigene Projekt braucht. Ich kann mir deshalb als langfristige Ziele besonders folgende Punkte vorstellen: - Zielgruppe beibehalten und nicht zwanghaft neue Leute anlocken. Spieleprogrammierung ist einfach ein anderes Hobby geworden als noch vor zehn Jahren und die Sprachen-Konkurrenz wird immer größer, da bleibt es nicht aus, dass die Community schrumpft. Viele hier sind auch nichtmehr in der Schule, sondern studieren oder stecken in den ersten Jobs, da bleibt einfach weniger Zeit für Hobbys - Zielplattform Windows, evtl. auch Mac und Linux. Keinesfalls mobil, Web, embedded oder was auch immer - IDE überarbeiten: Simpel bleiben (keinsfalls eclipse oder so), aber gezielt um Features erweitern (u.a. z.B. für kollaboratives Arbeiten oder Versionsverwaltung) - Genaue Regeln für neue Module festlegen und darauf aufbauend, zusätzlich zu Showcase und den Worklogs, eine Art "Modul-Datenbank" einrichten, um das Finden und die Wartung von Modulen zu vereinfachen

Tritium

So, Nov 01, 2015 15:03
Antworten mit Zitat

Hallo zusammen, ich bin nur noch selten hier unterwegs, hab die Diskussion aber mit großem Interesse gelesen. Mir ist dabei folgender Gedanke gekommen: Wie wäre es denn, wenn man sich nicht darüber unterhält, auf wie vielen Plattformen BMax funktionieren soll oder wie die Syntax erweitert werden könnte, sondern wenn man sich als erstes Ziel setzt, den bestehenden Code so zu überarbeiten, dass er lesbar und dokumentiert ist? Also dass man, statt sich um neue Features zu kümmern, erstmal versucht das bestehende zu überarbeiten und wart-/lesbar zu machen und dann im zweiten Schritt die halbherzig implementierten Features (Sichtbarkeit, OOP, etc.) fertigstellt? Ich weiß, ist immer Definitionssache was "fertiggestellt" bedeutet, hier gabs aber schonmal einen Thread, was sich die Nutzer hier im Forum von BMax 2.0 wünschen würden.

Für mich waren BlitzBasic (mit Rene Meyers Buch Smile

) und BlitzMax immer auf die Hobby-Entwickler ausgerichtet, die (damals noch mit DirectX7) kleine bis mittelgroße 2D- und 3D-Spieleprojekte für sich und einen tendenziell eher kleinen Kreis von Leuten entwickelt haben, um damit gemeinsam Spaß auf LAN-Partys zu haben und die Freude am Gamedesign/-programmierung zu teilen. Einige haben es dann sogar geschafft, die Spiele einem größeren Kreis bekannt zu machen und evtl. auch Geld damit zu verdienen. An BlitzMax gefiel mir insb. der modulare Ansatz, sodass man mit einem sehr grundlegenden Befehlssatz anfängt und den dann durch Module auf die Sachen erweitert, die man fürs eigene Projekt braucht. Ich kann mir deshalb als langfristige Ziele besonders folgende Punkte vorstellen:

- Zielgruppe beibehalten und nicht zwanghaft neue Leute anlocken. Spieleprogrammierung ist einfach ein anderes Hobby geworden als noch vor zehn Jahren und die Sprachen-Konkurrenz wird immer größer, da bleibt es nicht aus, dass die Community schrumpft. Viele hier sind auch nichtmehr in der Schule, sondern studieren oder stecken in den ersten Jobs, da bleibt einfach weniger Zeit für Hobbys
- Zielplattform Windows, evtl. auch Mac und Linux. Keinesfalls mobil, Web, embedded oder was auch immer
- IDE überarbeiten: Simpel bleiben (keinsfalls eclipse oder so), aber gezielt um Features erweitern (u.a. z.B. für kollaboratives Arbeiten oder Versionsverwaltung)
- Genaue Regeln für neue Module festlegen und darauf aufbauend, zusätzlich zu Showcase und den Worklogs, eine Art "Modul-Datenbank" einrichten, um das Finden und die Wartung von Modulen zu vereinfachen

	Thunder	Mo, Nov 02, 2015 0:53 Antworten mit Zitat
Tritium hat Folgendes geschrieben: Wie wäre es denn, wenn man sich nicht darüber unterhält, auf wie vielen Plattformen BMax funktionieren soll oder wie die Syntax erweitert werden könnte, sondern wenn man sich als erstes Ziel setzt, den bestehenden Code so zu überarbeiten, dass er lesbar und dokumentiert ist? Also dass man, statt sich um neue Features zu kümmern, erstmal versucht das bestehende zu überarbeiten und wart-/lesbar zu machen und dann im zweiten Schritt die halbherzig implementierten Features (Sichtbarkeit, OOP, etc.) fertigstellt? Naja... um ehrlich zu sein, hab ich keine Lust Code zu kommentieren, der nicht von mir ist, und den ich unter Umständen nicht verstehen muss. Ich hab Mal angefangen bmk neu zu schreiben (leider momentan keine Zeit), aber ich denke das ist ein wichtiger Schritt in Richtung Wartbarkeit, denn bmk ist in BlitzMax geschrieben, aber man braucht bmk, um BlitzMax zu kompilieren (weswegen Mark im Git repo binaries von bmk hat). Wenn man die Targetsprache wirklich auf LLVM IR ändern könnte, wäre das auch nicht nur ein Feature. Du würdest damit die zusätzlichen Plattformen und 64 bit gratis bekommen, ohne signifikant mehr Code. Zitat: - Zielplattform Windows, evtl. auch Mac und Linux. Keinesfalls mobil, Web, embedded oder was auch immer Denke genau so. Es gibt eh Monkey X, das schon versucht diese Niesche zu nutzen. Ich finde, dass man den Code so schreiben und die Libraries so wählen sollte, dass das Programm von Haus aus (ohne weiteres zutun) plattformunabhängig ist. C++ und andere kompilierte Sprachen haben ja den Ruf, nicht plattformunabhängig zu sein, was einfach nicht wahr ist. Zitat: - IDE überarbeiten: Simpel bleiben (keinsfalls eclipse oder so), aber gezielt um Features erweitern (u.a. z.B. für kollaboratives Arbeiten oder Versionsverwaltung) - Genaue Regeln für neue Module festlegen und darauf aufbauend, zusätzlich zu Showcase und den Worklogs, eine Art "Modul-Datenbank" einrichten, um das Finden und die Wartung von Modulen zu vereinfachen Beides sehr gute Vorschläge
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mo, Nov 02, 2015 0:53
Antworten mit Zitat

Tritium hat Folgendes geschrieben:

Wie wäre es denn, wenn man sich nicht darüber unterhält, auf wie vielen Plattformen BMax funktionieren soll oder wie die Syntax erweitert werden könnte, sondern wenn man sich als erstes Ziel setzt, den bestehenden Code so zu überarbeiten, dass er lesbar und dokumentiert ist? Also dass man, statt sich um neue Features zu kümmern, erstmal versucht das bestehende zu überarbeiten und wart-/lesbar zu machen und dann im zweiten Schritt die halbherzig implementierten Features (Sichtbarkeit, OOP, etc.) fertigstellt?

Naja... um ehrlich zu sein, hab ich keine Lust Code zu kommentieren, der nicht von mir ist, und den ich unter Umständen nicht verstehen muss. Ich hab Mal angefangen bmk neu zu schreiben (leider momentan keine Zeit), aber ich denke das ist ein wichtiger Schritt in Richtung Wartbarkeit, denn bmk ist in BlitzMax geschrieben, aber man braucht bmk, um BlitzMax zu kompilieren (weswegen Mark im Git repo binaries von bmk hat).

Wenn man die Targetsprache wirklich auf LLVM IR ändern könnte, wäre das auch nicht nur ein Feature. Du würdest damit die zusätzlichen Plattformen und 64 bit gratis bekommen, ohne signifikant mehr Code.

Zitat:

- Zielplattform Windows, evtl. auch Mac und Linux. Keinesfalls mobil, Web, embedded oder was auch immer

Denke genau so. Es gibt eh Monkey X, das schon versucht diese Niesche zu nutzen.
Ich finde, dass man den Code so schreiben und die Libraries so wählen sollte, dass das Programm von Haus aus (ohne weiteres zutun) plattformunabhängig ist. C++ und andere kompilierte Sprachen haben ja den Ruf, nicht plattformunabhängig zu sein, was einfach nicht wahr ist.

Zitat:

- IDE überarbeiten: Simpel bleiben (keinsfalls eclipse oder so), aber gezielt um Features erweitern (u.a. z.B. für kollaboratives Arbeiten oder Versionsverwaltung)
- Genaue Regeln für neue Module festlegen und darauf aufbauend, zusätzlich zu Showcase und den Worklogs, eine Art "Modul-Datenbank" einrichten, um das Finden und die Wartung von Modulen zu vereinfachen

Beides sehr gute Vorschläge Smile

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

	DAK	Mo, Nov 02, 2015 18:37 Antworten mit Zitat
Doch einige gute Vorschläge dabei, nur denke ich, dass das hier wohl der Knackpunkt ist, warum das hier wohl nicht wirklich was werden wird: Zitat: - Zielgruppe beibehalten und nicht zwanghaft neue Leute anlocken. Spieleprogrammierung ist einfach ein anderes Hobby geworden als noch vor zehn Jahren und die Sprachen-Konkurrenz wird immer größer, da bleibt es nicht aus, dass die Community schrumpft. Viele hier sind auch nichtmehr in der Schule, sondern studieren oder stecken in den ersten Jobs, da bleibt einfach weniger Zeit für Hobbys Es verwenden hier nicht mehr so viele BMax wirklich selbst. Entweder macht man inzwischen in anderen Sprachen (siehe Studieren und Jobs) oder hat sonst keine Zeit mehr für Programmieren allgemein. Und wenn's im Endeffekt eh quasi keiner mehr verwendet, dann ist das dafür doch ziemlich viel Aufwand.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mo, Nov 02, 2015 18:37
Antworten mit Zitat

Doch einige gute Vorschläge dabei, nur denke ich, dass das hier wohl der Knackpunkt ist, warum das hier wohl nicht wirklich was werden wird:

Zitat:

- Zielgruppe beibehalten und nicht zwanghaft neue Leute anlocken. Spieleprogrammierung ist einfach ein anderes Hobby geworden als noch vor zehn Jahren und die Sprachen-Konkurrenz wird immer größer, da bleibt es nicht aus, dass die Community schrumpft. Viele hier sind auch nichtmehr in der Schule, sondern studieren oder stecken in den ersten Jobs, da bleibt einfach weniger Zeit für Hobbys

Es verwenden hier nicht mehr so viele BMax wirklich selbst. Entweder macht man inzwischen in anderen Sprachen (siehe Studieren und Jobs) oder hat sonst keine Zeit mehr für Programmieren allgemein. Und wenn's im Endeffekt eh quasi keiner mehr verwendet, dann ist das dafür doch ziemlich viel Aufwand.

Gewinner der 6. und der 68. BlitzCodeCompo

	Thunder	Mo, Nov 02, 2015 23:40 Antworten mit Zitat
DAK hat Folgendes geschrieben: Und wenn's im Endeffekt eh quasi keiner mehr verwendet, dann ist das dafür doch ziemlich viel Aufwand. Jemand der was an BlitzMax verändern will, wird das für sich selber machen und nicht (primär) für andere. So einen selbstlosen Menschen möchte ich noch kennenlernen Ich würde BlitzMax gern öfter verwenden als ich es momentan tue, aber ich bin meistens auf Debian 64 bit und BlitzMax auf 64 bit Linux ist untragbar.
Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Thunder

Mo, Nov 02, 2015 23:40
Antworten mit Zitat

DAK hat Folgendes geschrieben:

Und wenn's im Endeffekt eh quasi keiner mehr verwendet, dann ist das dafür doch ziemlich viel Aufwand.

Jemand der was an BlitzMax verändern will, wird das für sich selber machen und nicht (primär) für andere.
So einen selbstlosen Menschen möchte ich noch kennenlernen Razz

Ich würde BlitzMax gern öfter verwenden als ich es momentan tue, aber ich bin meistens auf Debian 64 bit und BlitzMax auf 64 bit Linux ist untragbar.

Meine Sachen: https://bitbucket.org/chtisgit https://github.com/chtisgit

Gehe zu Seite Zurück 1, 2, 3

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

BlitzMax Opensource! & Free