> I hated building UIs with Swing/AWT, many of which are still in use today and are gradually being replaced by lovely JavaFX.
Dude JFX yielded what was called RIAs to JavaScript like almost 15 years ago. Of the three major GUI toolkits Swing, JavaFX, and SWT it was Swing that gained HighDPI support first (10 years ago), and continues to be the base for kick-as IntelliJ IDEA and other Jetbrains IDEs.
Swing was simpler in some ways than JavaFX. I still remember JavaFX treeview taking 3 Generics and I was unable to figure out what one of them is for from the docs. Had to go on Stackoverflow, where someone said it basically didn't matter. But JavaFX looked great at the time.
> The main property of SGML-derived languages is that they make "list" a first class object, and nesting second class (by requiring "end" tags) ...
I think you're missing the forrest for the trees ;)
The major point of SGML in this context is that elements have content models defined by regular expressions, just like any other grammar productions eg. BNF.
SGML has at least SP/OpenSP, sgmljs, and nsgml as full-featured, stand-alone parsers. There are also parsers integrated into older versions of products such as MarkLogic, ArborText, and other pre-XML authoring suites, renderers, and CMSs. Then there are language runtime libs such as SWI Prolog's with a fairly complete basic SGML parser.
ISO 8879 (SGML) doesn't define an API or a set of required language features; it just describes SGML from an authoring perspective and leaves the rest to an application linked to a parser. It even uses that term for the original form of stylesheets ("link types", reusing other SGML concepts such as attributes to define rendering properties).
SGML doesn't even require a parser implementation to be able to parse an SGML declaration which is a complex formal document describing features, character sets, etc. used by an SGML document, the idea being that the declaration could be read by a human operator to check and arrange for integration into a foreign document pipeline. Even SCRIPT/VS (part of IBM's DCF and the origin of GML) could thus technically be considered SGML.
There are also a number of historical/academic parsers, and SGML-based HTML parsers used in old web browsers.
Is that the whole story? Why isn't reddit overrun by bots then (or are they?), and why wouldn't basic proof-of-work techniques fence against bots? Since they started out just in January, isn't it plausible to assume they didn't meet their target user figures and investors jumped ship?
Surely that's what happen. They probably couldn't compete with reddit at this point and bots were a secondary issue. Hoping that the interest will develop on its own, partially by the brand knowledge among older users wasn't enough.
It's been over a decade now and reddit despite of own exodus that happen recently still remains the default social link aggregator, and a global multi-forum. Not mention that younger generations prefer different kind of platforms and this largely-text based site might be not attractive to them at all
> XML is fundamentally incompatible with commonly used programming data structures, namely lists/arrays and structs/maps.
Another way to say this is XML is a grammar formalism that deals purely with serialisation rather than higher-level structures that might be serialised such as co-inductive data structures.
> While HTML technically is not XML, it's very close to it and XHTML still is a thing.
XML and HTML-as-serialisation-format are both subsets of SGML.
> The Extensible Markup Language (XML) is a subset of SGML that is completely described in this document. Its goal is to enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML.
Where "generic SGML" refers to markup beyond the basic HTML vocabulary hardcoded into browsers, such as SVG and MathML. XML was specifically designed such that mere parsing doesn't require element-specific rules such as SGML-derived HTML tag omission/inference, empty elements, and attribute shortforms, by excluding these features from the XML subset of SGML. Original SGML always required a DTD schema to inform the parser about these things that HTML has to this day, and not just for legacy reasons either ie. new elements and attributes making use of these features are introduced all the time (cf. [1]).
Now XML Schema (W3C's XML schema language, and by far the most used one) isn't very beautiful, but is carefully crafted to be upwards compatible with DTDs in that it uses the same notion of automaton construction to decide admissability of content models (XSD's Unique Particle Attribution rule), rooted in SGML's zero lookahead design rationale that is also required for tag inference. Relax NG does away with this constraint, allowing a larger class of markup content models but only working with fully tagged XML markup.
XML became very popular for a while and, like JSON afterwards, was misused for all kind of things: service payloads in machine-to-machine communication, configuration files, etc., but these non-use cases shouldn't be held against its design. As a markup language, while XML makes a reasonable delivery or archival language, it's a failure as an authoring language due to its rigidity/redundancy and verbosity, as is evident by the massive use of markdown and other HTML short syntaxes supported by SGML but not XML.
I get what Nick is trying to do (allow F/OSS to continue receiving security fixes while requiring commercial users to pay), even forwarded his call for help or other support last year. I'm not sure though relicensing MIT code under AGPL is legally sound if your additions are just bug fixes.
> I'm not sure though relicensing MIT code under AGPL is legally sound if your additions are just bug fixes.
It is: the original unmodified code is still MIT, but the bits you wrote and thus you hold the copyright for are AGPL. The combination of your bits + old bits is AGPL; some judge may argue your derived work isn't derived enough if you just change a few characters though. Still, I may argue that fixing a bug, no matter how trivial, requires you to perform a creative task, which almost definitely is by itself to be considered enough to go above the threshold required by a derived work.
It really doesn't matter until one tries to enforce an AGPL provision. If you do, that's where as you say will be arguments whether one added something substantial enough; basically the AGPL terms can really only be enforced on those additions.
[1] describes the initial elements of HTML. Almost all were derived from an inofficial SGML folklore tagset with the notable exception of <a> and http URIs.
The term "AI" has changed in recent years but if you mean classic game logic such as complex rules and combinatorial opponents then there's plenty of Prolog game code on github eg. for Poker and other card or board games. Prolog is also as natural a choice for adventure puzzles as it gets with repository items and complicated conditions to advance the game. In fact, Amzi! Prolog uses adventure game coding as a topic for its classic (1980s) introductory Prolog learning book Adventure in Prolog ([1]). Based on a cursory look, most code in that book should run just fine on a modern ISO Prolog engine ([2]) in your browser.
Dude JFX yielded what was called RIAs to JavaScript like almost 15 years ago. Of the three major GUI toolkits Swing, JavaFX, and SWT it was Swing that gained HighDPI support first (10 years ago), and continues to be the base for kick-as IntelliJ IDEA and other Jetbrains IDEs.
reply