speedfixer wrote:marcov, I'm confused.
It happens :-)
speedfixer wrote:I learn a lot from you about languages and programming ... style?? (maybe, technique, attitude, history??)
speedfixer wrote:But you are ALWAYS here selling FPC.
FPC, which is a different thing. I just take FPC as measuring rod.
For two reasons.
- I know FPC best for some strange reason (*)
- (specially in "C" discussions), how many languages/toolchains do you know to compare with, that are at least at some distance of GCC/LLVM and not commercial?
The topics here are FreeBASIC.
You'll see I most engage in general software engineering topics, and general FB course/direction. Comparisons are slightly more on topic in such topics.
Compare and contrast - we learn something. A lot of what you have to say is informative and helps many make better decisions.
But if I do I'm told I'm a FPC fanboy. Critical voices are not appreciated, and whatever sets you apart is exploited to beat you with (well, admittedly except some more senior members like Counting Pine and coderjeff with whom I have had this discussion before).
speedfixer wrote:As gentle as I can say it:
Work to sell FPC over FB, and I think you turn a lot of people off.
We get it: you are an FPC fanboy. But turn down the volume: we don't care.
So - why are you here?
The best way to answer that is explaining why I joined mid-2006. FB was a young compiler with an own independent backend even though it still had a legacy RTS. (The latter still hasn't been fixed, and the former, the independent backend, has taken a backseat). Anyway, it was spunky and vibrant and developed itself quickly.
For me initially it was just a way to relive the decisions I had missed with FPC, having joined AFTER the initial period in 1997, also it was kind of kindred spirits.
All slightly different of course, since the options for FB in 2006-7 were different from FPC in the equivalent period 1993-1995. Back then, a win9x system was future tech, AS didn't have an intel mode, and even DJGPP was cumbersome, requiring high spec machines and having low dos compatibility.
Anyway, while I don't like the C backend option, I'm still curious how this works out in practice, since precious little can be found about the details of such technology, specially on non-*nix. It is always the same basic mantra (blabla, get optimization for free), and never a critical sound/downside.
However I am a bit disappointed in that it seems that FB is nowadays going with the flow more(iow implement what is possible with minimal work) rather than set an own course and do whatever needs tobe done to get there. It was what I was afraid of when the C backend emerged (for proof: search the forum).
The problem is that if you have something big and external in your system, going against it becomes painful.
I don't want you to go away; I don't think anyone wants that.
But stop SPAMMING the virtues of FPC.
That is simple then, keep the discussions then to the point, and don't claim things for FB it can't (yet) deliver, and I don't have to compare it unfavourably to other toolchains. FPC or otherwise. Or simply stop seeing minor criticism as spamming.
If somebody claims C compatibility, I expect to be able to copy and paste C code, or at the very least, to use C headers, not having some superficial syntax similarity, and being able to link to C (which is nigh on universal with programming languages nowadays)
(*) which might have to do something with being a (minor) FPC core member.