Rosetta Code:Village Pump/FBSL Categorization Question
This is a particular discussion thread among many which consider Rosetta Code.
Summary
Why not let FBSL stay alone?
Discussion
Hello community,
I've just noticed some activity going on to group various BASIC dialects into a common BASIC branch in the language tree of certain tasks. It being generally a positive idea which obviously targets better readability and ease of language tree navigation, I wouldn't however consider it reasonable to place such true multi-syntax languages as FBSL, or interoperative languages like Terra, LuaJIT/DynASM and a few others, into any particular side branch of the tree. They are too, well, extraordinary for that, and an unbecoming neighborhood may do such languages a disservice of misleading their potential users. Yup, it is difficult to be different, as Paddy3118 once said. ;)
FBSL is exactly as much "BASIC" as it is "assembly" or "C". Why aren't assemblers grouped in a branch? Why aren't C clones (C, C++, C#) grouped either? Markup languages? Esoteric languages? Then why not let FBSL stay alone in the main trunk? At least for fear lest someone rewrite the FBSL solutions in FBSL's thoroughbred Dynamic C and claim C kindred. :)
Kind regards, --TheWatcher 03:58, 11 November 2013 (UTC)
- ... not to mention the various LISP flavors. -- Gerard Schildberger (talk) 10:29, 11 November 2013 (UTC)
- I don't think there's any problem at all in having FBSL entries in their own right, provided the idiomatic way of achieving the task at question is significantly different in FBSL than other BASIC variants. (Goodness knows, they vary a lot.) The difference could even be down to different typical availability of libraries (though if that's the case, it should be documented with {{libheader}} of course).
- All I'd like to avoid is having the same thing written out multiple times, or entries that just say “see this other entry”. The former is wasteful, and the latter sucks as the users of the other language won't easily see that there's strong syntactic similarities; we can use multiple {{header}} macros in one heading if necessary, and that creates better usability and discoverability. (This is what I was encouraging the Icon/Unicon entries to do; AIUI, they're often the same, but not always.) –Donal Fellows (talk) 08:27, 12 November 2013 (UTC)
- @Donal Fellows
- If I get you correctly, an FBSL entry may only stay alone if it shows anything that other BASIC's can't do? I assume you've already had a quick look here or here. Let me assure you each and every entry may be (re)written in exactly that style without any stand-alone libraries or include files with extra code. Each and every portion of the script down to a separate statement may be written in one of the three constituent languages - BASIC script (extended BASIC), Intel assembly, or ANSI C. Everything is there in one and the same 600KB Fbsl.exe binary. The only general-purpose include file we've found helpful so far is <Windows.inc> which hosts about 7,000 standard Windows #Define macros. This is because around 2,300 Windows API's from system-wide kernel32.dll, user32.dll and gdi32.dll are always available to the FBSL users transparently as if they were just part of the native vocabulary.
- If it boils down to being different in each and every entry just by showing off that unique feature again and again instead of the user or criticist looking it up just once in the Category:FBSL entry, I will re-write all my submissions in that style for FBSL to remain in the language tree trunk once and for all. Regards, --TheWatcher 23:57, 12 November 2013 (UTC)
In the same vein, one of those updates/consolidations managed to delete two program (solution) entries, namely a Batch File and an XPL0 entry.
I made a mention of this in the talk section of the Rosetta Code task (in the same day or next morning that it happened), but so far, those two language entries haven't been repaired or re-instated. To make it worse, I have at this point forgotten which task it was, but it was one of the first attempts at the consolidation/grouping of the BASIC languages. -- Gerard Schildberger (talk) 10:29, 11 November 2013 (UTC)