Talk:Anagrams: Difference between revisions

Line 33:

What do others think? --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 07:07, 6 May 2013 (UTC)

==FBSL calling C: Is it useful?==

⚫

You may call me "others" but in fact I'm taking the liberty of talking on behalf of the FBSL Dev Team.

⚫

:You may call me "others" but in fact I'm taking the liberty of talking on behalf of the FBSL Dev Team.

⚫

FIRST, FBSL is not "calling C" and is not "embedding the source" for other languages in itself here in the interactive way as e.g. Lua clones do. Of course it can do it as well in its DLL hypostasis but this is not what you're seeing here or in the Ackermann challenge and will be seeing in many more solutions to come.

⚫

:FIRST, FBSL is not "calling C" and is not "embedding the source" for other languages in itself here in the interactive way as e.g. Lua clones do. Of course it can do it as well in its DLL hypostasis but this is not what you're seeing here or in the Ackermann challenge and will be seeing in many more solutions to come.

⚫

SECOND, Dynamic Assembler and Dynamic C JIT compilers are indispensable features of FBSL alongside its interpretative environment. They do not require any add-ons, add-ins, plug-ins, DLLs, archives etc. etc. etc. They are already there and they interact with their interpretative parent and they exchange data with one another and they are environmental extensions of one another. They are not seen from outside and their code is not accessible for anyone but FBSL itself. The DynAsm and DynC code::blocks are FBSL's subs and functions exactly like its own interpreted subs and functions. You cannot separate them in a very much the same way as you wouldn't be able to separate the Siamese twins or they'll die.

⚫

:SECOND, Dynamic Assembler and Dynamic C JIT compilers are indispensable features of FBSL alongside its interpretative environment. They do not require any add-ons, add-ins, plug-ins, DLLs, archives etc. etc. etc. They are already there and they interact with their interpretative parent and they exchange data with one another and they are environmental extensions of one another. They are not seen from outside and their code is not accessible for anyone but FBSL itself. The DynAsm and DynC code::blocks are FBSL's subs and functions exactly like its own interpreted subs and functions. You cannot separate them in a very much the same way as you wouldn't be able to separate the Siamese twins or they'll die.

⚫

THIRD, the decision of what intrinsic feature of a language to select for a particular task is undoubtedly the programmer's prerogative as long as the task is resolved within the context of its rules. RosettaCode is not the place to generate proprietary/patented/closed-source solutions and more than half of its code base here are ports from one another's code. My solution ''does not'' claim originality. On the contrary, it clearly states it's a verbatim copy totally in accordance with the GNU spirit of this place. But it is unique in that no other language whatsoever can boast such a solution. Who else can claim 100% compatibility with another, but any other language present at RosettaCode?

⚫

:THIRD, the decision of what intrinsic feature of a language to select for a particular task is undoubtedly the programmer's prerogative as long as the task is resolved within the context of its rules. :RosettaCode is not the place to generate proprietary/patented/closed-source solutions and more than half of its code base here are ports from one another's code. My solution ''does not'' claim originality. On the contrary, it clearly states it's a verbatim copy totally in accordance with the GNU spirit of this place. But it is unique in that no other language whatsoever can boast such a solution. Who else can claim 100% compatibility with another, but any other language present at RosettaCode?

⚫

FOURTH, the unavailability of such a section as you suggest may be a clear indication that there are no other languages that are capable of doing the same. You may try to introduce one but I'm afraid, FBSL will be the only participant in there for a very very long time to come.

⚫

:FOURTH, the unavailability of such a section as you suggest may be a clear indication that there are no other languages that are capable of doing the same. You may try to introduce one but I'm afraid, FBSL will be the only participant in there for a very very long time to come.

⚫

LAST, but not the least. We at FBSL cannot be held responsible for other devs not having time or insentive enough to accomplish what we have accomplished in FBSL. We are not saying others are worse. What we are saying is we are different and more versatile than many. Despite our remaining basically BASIC.

⚫

:LAST, but not the least. We at FBSL cannot be held responsible for other devs not having time or insentive enough to accomplish what we have accomplished in FBSL. We are not saying others are worse. What we are saying is we are different and more versatile than many. Despite our remaining basically BASIC.

⚫

Yes, my Anagrams decision was a show-off and a challenge for "others" who can't claim compatible functionality. But it was clearly stated as such. This is not the first time in our 12-year old history that "others" do not like us for what we can do while they can't. But calling us an ugly duckling and trying to impose restrictions not applicable to other contestants would be totally unfair and contrary to the spirit of this place.

⚫

:Yes, my Anagrams decision was a show-off and a challenge for "others" who can't claim compatible functionality. But it was clearly stated as such. This is not the first time in our 12-year old history that "others" do not like us for what we can do while they can't. But calling us an ugly duckling and trying to impose restrictions not applicable to other contestants would be totally unfair and contrary to the spirit of this place.

Kind regards,

:Kind regards,

TheWatcher

:TheWatcher

::<br>Woa. Hold your horses their TheWatcher! So are you saying that FBSL contains both a dynamic assembler and a dynamic C JIT (is that a compiler or interpreter) as subsets of the language? That was not made clear in [[FBSL|the language category page]], or in the introduction on the FBSL home page.

_________________________________________________________________________

::This is supposed to be a site for comparing language features. You should not be surprised if someone sees one languages entry copied and used for another language and questions it.

"Я старый солдат, мадам, и не знаю слов любви."

::Since FBSL has this capability it might be best to show it by showing the FBSL specific framework necessary and then only any differences to the C entry with the rest ellided so that language comparers can concentrate on how FBSL can use stock C - as well as maybe a second answer written in mainly that subset of features FBSL that are not shared with the C JIT. Actually what I have written may be wrong as I do not know how well integrated C is with FBSL. At the moment, the FBSL entry looks like a wrapper for a C compiler/interpreter/JIT. You could use the site to show why it is more than that with careful explanation and use of unique or near-unique features.

::Yep its tough when you're different - just ask the [[J|J language]] guys. But this site gets better by encouraging more language entries and surely if you are different, then you should be able to show the benefits. Those J people have several times explained in depth how their unique solutions work and we could see how their language helps them to think in ways that can generate elegant solutions.

"I am an old soldier, ma'am, and I don't know the words of love."

::If you are that different then you may have to meet your audience half way. --[[User:Paddy3118|Paddy3118]] ([[User talk:Paddy3118|talk]]) 11:23, 6 May 2013 (UTC)

"Je suis un vieux soldat, madame, et je ne connais pas les mots d'amour."