Lazarus
Miscellaneous => Other => Topic started by: 440bx on June 28, 2019, 11:48:13 pm
-
I was reading about the FPC foundation in another thread and, reading about it gave me the following idea:
What if an individual or group of individuals (FPC/Pascal programmers) were to offer to pay the developers, not a foundation but those who are actually actively developing the compiler, for the implementation of a particular feature ?
Of course, something like that would require a method in place to make it work but, it seems doable.
This might attract additional compiler writers to participate in the development of FPC.
What do you think ?
-
There is the wiki page (https://wiki.freepascal.org/Bounties) where you can offer money for implementing a feature you need.
-
I don't think this would help very much, unfortunately. It's become clear to me while observing the bugtracker recently that even if someone can actually implement a new working feature by themselves, if the "core" developers decide that they don't like it for whatever reason, it will just sit there in limbo forever without being merged.
You'd have to have some kind of fork that had more active interest in merging new functionality for this to be a useful concept, I think.
That said, paying for specific bugs to be fixed might have some benefit in the "main" FPC trunk.
-
There is the wiki page (https://wiki.freepascal.org/Bounties) where you can offer money for implementing a feature you need.
Thank you for pointing that out.
I had compiler features in mind, where not just one person would offer a "reward" for its implementation but, anyone who is interested in seeing the feature implemented, could add their name to list along with the additional amount they are willing to add to the "pot".
The reward a group of people can offer for a particular feature will usually be greater than what one individual can offer.
That's the part I have not seen, a way for a group of people to pool their "reward" for a particular feature they desire.
ETA:
It's become clear to me while observing the bugtracker recently that even if someone can actually implement a new working feature by themselves, if the "core" developers decide that they don't like it for whatever reason, it will just sit there in limbo forever without being merged.
I have observed that too.
You'd have to have some kind of fork that had more active interest in merging new functionality for this to be a useful concept, I think.
I agree.
That said, paying for specific bugs to be fixed might have some benefit in the "main" FPC trunk.
I am not fond of that idea. I believe it is a matter of personal pride for a programmer to fix bugs in his software. I am not comfortable with the idea of offering a reward for just fixing bugs. That's just my personal feeling about it, I certainly wouldn't be against the practice if other people wanted to have it.
-
I had compiler features in mind, where not just one person would offer a "reward" for its implementation but, anyone who is interested in seeing the feature implemented, could add their name to list along with the additional amount they are willing to add to the "pot".
I don't see what stops you from adding a bounty for a specific compiler feature, and then asking everyone interested to add to the bounty. Payoff condition would be that feature ends up in official freepascal, so interested implementor would have to make an effort of investigating what would be needed for that to happen.
-
Well, first of all you could check yourself if the desired feature would ever stand a chance.
You can go through past discussions of the forum, to see if your feature was previously mentioned, and why it did not happen.
Some feature are simply deemed "will not ever be accepted". (i.e., if you want them, start a fork).
E.g. it is rather unlikely that the compiler gets a c++ directive (like the asm block), and starts accepting native c code). It is after all Pascal and not C.
Some say the decision process what is allowed is too obscured. Personally I have seen it done more or less the same with many other open source projects: Some group (small or large), with its members defined/selected by some (arbitrary) criteria, must in the end make the decision.
Once a feature is deemed "potentially ok", you can go starting a bounty process (through what ever means)
-
There already have been instances where members of the core team have been payed even very significant amounts of money to implement a feature, replacing a significant part or all of their usual income.
But as Martin wrote and I concur: do not start implementing a feature *before* you researched the likelihood it will be included, usually on fpc-devel.
Aside: any such payments are not public nor published where individual are involved.
Unless they decide to do so themselves.
-
Beautiful idea, but if that is going to work?
I can suggest another approach (by creating an additional value):
1. Find successful commercial project who switched to FPC and present it as success story in figures i.e. with narrative: "we saved XX much by switching from AA to FPC".
2. Find 3-5 similar project that thinking to switch and make contract - we support/help them switch and save them YY amount of money, they donate fraction of saved amount to FPC foundation.
3. Profit. Everyone is happy.
Personally I've never understood any additional value in that the project is open source or that is free. That's is big misunderstanding that get that for free and be happy - like a trees in the wood. To get something out of the trees you need to cut them, process them and only then sell it - there is a gap between goods ant final value (in price) and that gap is usually price (what removes any benefits of being free and being open - you need to spent good amount of resource to benefit from that). If there is a way to bridge the gap, there will be a way to attract more successful commercial projects into FPC.
-
As I wrote, there have been precedents. If you are a good observer you also know which features have been sponsored 8-)
As long as it does not affect the license I do not see a need to publish that. That's up to the contractor and contractee(s).
I am talking about full-time or near full-time occupation, so this can be substantial and therefor private.
-
I don't see what stops you from adding a bounty for a specific compiler feature, and then asking everyone interested to add to the bounty.
You're right, there is nothing stopping me from doing that. What I seem to have missed (if it exists) is a very obvious/visible list of features people have offered a bounty for, thus enabling other people to add themselves and their bounty offer to a particular feature.
What @Zoran pointed to is a list but, IMO, it is not exactly very "visible" nor does it invite others to "opt-in" (or even make that easy/obvious)
Well, first of all you could check yourself if the desired feature would ever stand a chance.
Absolutely!. That's why I mentioned removing limitations on "variants" in a forum thread. I did see a very modest amount of interest from other forum members but, the subject didn't even get a comment from any of the developers. Personally, not only I think it would be very nice, I find it surprising that it has not been implemented yet but, interest seem to be lukewarm at best which, in turn, doesn't do much for my desire to offer a bounty to see it implemented.
Once a feature is deemed "potentially ok", you can go starting a bounty process (through what ever means)
I couldn't agree anymore with that. Again, referring to the "variant" thread, it was essentially ignored by the developers which led me to forget that idea.
... been payed [edit: paid] even ...
your English is good, that's just my 4 keystrokes (excluding punctuation and keyword) to help make it better.
But as Martin wrote and I concur: do not start implementing a feature *before* you researched the likelihood it will be included, usually on fpc-devel.
... and I concur too.
It seems to me that, even though there is somewhat of a mechanism in place, it really isn't very visible nor is it inviting for others to add themselves to those interested in a particular feature.
Basically, I think it would be nice, not to mention potentially much more effective and rewarding for the developers, to have something that is very visible (like the bugtracker for instance) where those interested can add themselves and their bounty in support of a particular feature.
-
IMHO the recent problems with rejections is because aspiring developers try to do too much to soon, without getting a feel for the project.
Start small. Ask questions a lot. Learn proper procedures. And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Many delays come due to unclean patches.
-
... been payed [edit: paid] even ...
your English is good, that's just my 4 keystrokes (excluding punctuation and keyword) to help make it better.
It is quite sufficient since it is correct to write payed in the context of pay. Paid is related to shopping or settling a bill. Payed is remuneration for work or services rendered. So ...? ;D ;D ;D ;D Be careful what you wish for....< >:D >:D > Your "correction" is actually a mistake.
To put this into context: the amount you are being payed to perform a task is usually paid in periodical settlements. Examine any of the good English dictionaries and you will see the error of your ways .. O:-) O:-)
-
It is quite sufficient since it is correct to write payed in the context of pay. Paid is related to shopping or settling a bill. Payed is remuneration for work or services rendered. So ...? ;D ;D ;D ;D Be careful what you wish for....< >:D >:D > Your "correction" is actually a mistake.
Now you're being funny. Unless, you somehow saw the subject as being nautical, your usage of the word "payed" is incorrect.
Since my intention was genuinely to help, I figured I'd keep helping... here is what the word "payed" is for:
pay
/pā/
verb
Nautical
past tense: payed; past participle: payed
seal (the deck or hull seams of a wooden ship) with pitch or tar to prevent leakage.
"an open groove between the planks had to be payed by running in hot pitch from a special ladle"
Unless FPC has planks that need to be sealed, it is quite unlikely that your usage of the word "payed" was correct. Feel free to disagree, I'm sure you will but, don't get grumpy, it's not good for you.
-
Just examine one of the good English dictionaries. Any of them...
-
Just examine one of the good English dictionaries. Any of them...
By that definition Merriam-Webster is not a good dictionary. Here is what they say about "payed"
pay
verb (2)
payed also paid; paying
Definition of pay (Entry 4 of 4)
transitive verb
: to coat with a waterproof composition
-
English is, in the main, an "usage based" tongue (witness the debacle of "virtually" now meaning also "literally; in the real world" ;)) but just for fun:
- Payed or Paid: What’s the Correct Spelling? (https://www.grammarly.com/blog/paid-payed/)
- Payed or Paid: What’s the Difference? (https://writingexplained.org/payed-or-paid-difference)
-
witness the debacle of "virtually" now meaning also "literally; in the real world" ;)
Yeah, but a new word for the original "literally" was needed, since "literally" nowadays is often/sometimes used to mean "figurative" ;)
-
Yeah, English is (or rather English-speakers are) funny like that :D
-
referring to the "variant" thread, it was essentially ignored by the developers which led me to forget that idea.
People have an expectation that FPC core developers follow much of this forum. That is mostly not the case. If you want their attention you should better join fpc-devel mail list:
https://freepascal.org/maillist.html
-
People have an expectation that FPC core developers follow much of this forum. That is mostly not the case. If you want their attention you should better join fpc-devel mail list:
https://freepascal.org/maillist.html
I admit to have a mild level of expectation for the FPC developers to, at least occasionally, check out what's happening here in the forums.
I concur that for an extensive discussion of implementing a new feature in the compiler, the mailing list is probably a better avenue than the forums but, to get an initial "feel" of whether or not a particular feature would be considered, the forums seem to be a reasonable avenue. Plus, it gives other forum members the opportunity to express their opinions too (which can be, both, a pro and a con.)
-
The forum is (by many of the team members) seen as a place for User-to-User discussions.
Some team members are regulars on the forum, others will only attend if they are notified via the mailing lists.
Also I guess, in the specific case of a "what about this feature", there are 2 kind of discussions to be had:
1) What do users want. Kind of get an idea what people want out of that feature.
2) Can the feature be accepted. Or to which extend can it be accepted.
The 2nd kind of discussion, can generate very huge discussions (even if the developers would totally welcome it, other users may bring in arguments why it should be limited).
So it is well possible, that people hold back, in order to avoid starting the 2nd kind of discussion prematurely. (But I do not know if that is/was the case (here, or for any other such topic))
-
I think it is always correct to respond to misunderstandings. That may look off-topic but often is not.
Precise wording is important.
-
I don't think this would help very much, unfortunately. It's become clear to me while observing the bugtracker recently that even if someone can actually implement a new working feature by themselves, if the "core" developers decide that they don't like it for whatever reason, it will just sit there in limbo forever without being merged.
Absolutely right and that's very sad!
Sometime even nobody of the team responded to a patch which easily leads to the impression that help is not wanted. :-\
Would also help to have a list with rejected features/patches and a reason WHY it was rejected.
IMHO the recent problems with rejections is because aspiring developers try to do too much to soon, without getting a feel for the project.
Start small. Ask questions a lot. Learn proper procedures. And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Having some kind of rejected patches/features would help new people to get a better feeling about FPC. Might also reduce duplicate question for feature X...
And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Many delays come due to unclean patches.
Unclean patches could be cleaned by devs if the feature is working, takes less time than asking to submit a new patch which might not fit your rules also...as there are no contribution rules, or?
-
Just one example is
I don't think this would help very much, unfortunately. It's become clear to me while observing the bugtracker recently that even if someone can actually implement a new working feature by themselves, if the "core" developers decide that they don't like it for whatever reason, it will just sit there in limbo forever without being merged.
Absolutely right and that's very sad!
Sometime even nobody of the team responded to a patch which easily leads to the impression that help is not wanted. :-\
One example for this:
Attributes support (https://bugs.freepascal.org/view.php?id=33384)
-
The imagnation that one can force the implementation of non-pascalish features into FPC just with money is really frightening me.
Imho, the compiler is already mature, new features should be considered very restrictively.
On the other hand, addressing new targets (both FPC and Lazarus), making components etc. don't threaten Freepascal, so I would support that.
FPC compiler featured should be spared out and that should be stated very clearly.
-
Would also help to have a list with rejected features/patches and a reason WHY it was rejected.
That should be part of the current process. It would provide a much better idea to FPC users what direction the compiler is going.
-
Note: speaking more for FPC than for lazarus.
Absolutely right and that's very sad!
Sometime even nobody of the team responded to a patch which easily leads to the impression that help is not wanted. :-\
That's the problem with language design. It is quite a minefield. But a lot of it is self-inflicted. They have been warned. Nevertheless, when it happens it is a tragedy. For both sides.
Would also help to have a list with rejected features/patches and a reason WHY it was rejected.
If people wade in to disputed areas (usually: copying syntax from other languages or totally ad-hoc syntax enhancements) after being warned, I don't really think that some list somewhere in the wiki will detract them.
Quite often it is not rejected per se, but the amount of work is simply to daunting for a committer. Specially if he can't do it during normal hours, but really has to set aside holidays to review something that is big or with big consequences.
IMHO the recent problems with rejections is because aspiring developers try to do too much to soon, without getting a feel for the project.
Start small. Ask questions a lot. Learn proper procedures. And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Having some kind of rejected patches/features would help new people to get a better feeling about FPC. Might also reduce duplicate question for feature X...
If you feel that way, start a wiki page.
But I think it is more a sign of the times. For some reason all new contributors want to play with expanding language, the bigger the better. 10 years ago, new contributors were more about new targets, and often were already deeper into that field than core contributors.
That had several important consequences
1) what they didn't, mostly affected the new target, not everything, and the consequences for support etc would be
2) they usually knew what they were doing (wrt that target) better than core anyway.
3) they usually had already quite a string of patches and rearrangements, often for related targets.
It is much easier to let such contributor get commit bits than the current batch that seems to be overly focussed on language (with the dialect backwards compatibility as a Sword of Damocles haging over it).
Just look what happened to similar contributions a few years ago. Where are the case <string> of committers?
And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Many delays come due to unclean patches.
Unclean patches could be cleaned by devs if the feature is working, takes less time than asking to submit a new patch which might not fit your rules also...as there are no contribution rules, or?
Most of these people have submitted more trivial stuff before, so they now about cleanliness rules.
Keeping changesets minimal as possible is a fairly universal rules in open source (or even: multi person projects).
Anyway, while I don't think a rejected patch list will do much good, I do think that the current policy of officially welcoming any patches is bankrupt. It worked in the past when the new developers either had or acquired the same mindset as the old bunch in time, but it doesn't seem to work like that any more.
-
The imagnation that one can force the implementation of non-pascalish features into FPC just with money is really frightening me.
You seem to have a vivid imagination. I haven't seen anyone in this thread suggest the addition of "non-pascalish" features to the compiler, for money or otherwise.
Imho, the compiler is already mature, new features should be considered very restrictively.
Mature doesn't imply it has all the features that would make programming cleaner and easier. It doesn't.
On the other hand, addressing new targets (both FPC and Lazarus), making components etc.
"jack of all trades, master of none."...
... don't threaten Freepascal, ...
I don't see how removing the current limitation on variants being last in a record definition would "threaten Freepascal".
-
And, most importantly, don't reformat code unnecessarily, keep patches to the point and as small as possible. It doesn't matter if it is in a git branch or a submitted patch.
Many delays come due to unclean patches.
Unclean patches could be cleaned by devs if the feature is working, takes less time than asking to submit a new patch which might not fit your rules also...as there are no contribution rules, or?
And then they present an unclean patch for the next issue again. And again. And again. No. If they want to contribute they need to learn how to make it easier for us as well. After all we developers need to look at the bug reports from other users as well. We're willing to point out what they did wrong, but if they're not willing to learn why should I waste my time with them?
Note: I'm not talking about small patches with just a handful of lines; there it is indeed not worth the effort to request a cleaned up patch. Big feature patches... Oh boy. If they include hundreds of unrelated changes, because the IDE decided to be too clever (yes, that happens with FPC's code in Lazarus fairly often) that makes the real changes hard to spot.
But I think it is more a sign of the times. For some reason all new contributors want to play with expanding language, the bigger the better. 10 years ago, new contributors were more about new targets, and often were already deeper into that field than core contributors.
That had several important consequences
1) what they didn't, mostly affected the new target, not everything, and the consequences for support etc would be
2) they usually knew what they were doing (wrt that target) better than core anyway.
3) they usually had already quite a string of patches and rearrangements, often for related targets.
It is much easier to let such contributor get commit bits than the current batch that seems to be overly focussed on language (with the dialect backwards compatibility as a Sword of Damocles haging over it).
That's how I had started as well. With a new target. :)
-
And more importantly, for sizeable patches created over a larger time it is painful to do it afterwards. The whole point is to encourage the policy in the work, not just afterwards.
-
The imagnation that one can force the implementation of non-pascalish features into FPC just with money is really frightening me.
You seem to have a vivid imagination. I haven't seen anyone in this thread suggest the addition of "non-pascalish" features to the compiler, for money or otherwise.
Perhaps not in this thread, but they are there. Inline type declaration, untyped variables...
The title "Features for money", in a way could be understood as "Syntax for money". You still think this would be a good idea?
"jack of all trades, master of none."...
In my narrow view angle, Freepascal is of really high quality and there is much more potential for improvements in Lazarus, especially for the mobile targets. For Freepascal I see in the embedded targets a good chance for growth. People are really looking for alternatives of C.
Didn't you ask before in the Forum for a change of the in/out/var naming? I would (mentally) support such cleanups, but I don't think its a good idea to push them with money.
-
Perhaps not in this thread, but they are there. Inline type declaration, untyped variables...
There will always be "questionable" ideas/requests but, even if they offer money to have them implemented, their chances won't be very good.
The title "Features for money", in a way could be understood as "Syntax for money". You still think this would be a good idea?
I'm not sure what "syntax for money" really means but, while I do appreciate good syntax, good/nice syntax that does not implement something genuinely useful is of little interest (at least to me) and, very unlikely something I would financially support.
In my narrow view angle, Freepascal is of really high quality and there is much more potential for improvements in Lazarus, especially for the mobile targets. For Freepascal I see in the embedded targets a good chance for growth. People are really looking for alternatives of C.
There is plenty of room to improve Freepascal. There are still fairly basic features missing, among them, the ability of having multiple variants in a record definition. The absence of that feature makes porting C code to FPC more work than it should be.
I do agree there is room for improvement in Lazarus. So far, I am under the impression the Lazarus developers are much more open to listen and consider suggestions than FPC's.
Didn't you ask before in the Forum for a change of the in/out/var naming? I would (mentally) support such cleanups, but I don't think its a good idea to push them with money.
No. I didn't ask for a change in the in/out/var naming. What I asked for is the implementation of "in" and "inout" and remove the erroneous assumption FPC is currently making that a "var" should be initialized (chicks for free and useless compiler messages for nothing!.)
The purpose of "in", "out", "inout" is to enable the compiler to do more checking on behalf of the programmer to catch errors at compile time instead of runtime. That is part of the soul of Pascal and one of the most significant advantages it has over other languages such as C (C++ has exceeded Pascal in that area but, in the syntax area, it's just a deformed C atrocity, radioactivity is really bad... even for computer languages.)
Implementing reliable mechanisms a programmer can use to enable the compiler to flag variable usage errors is worth money. (lots of C programmers at one time bought "lint" specifically for that purpose.)
-
I sincerely doubt that there is anyone at all claiming features such as generics or inline variables are "confusing" who is under the age of 45, also.
I do feel like the general tone of your comment is perhaps a bit... aggressive, however: as an "older" developer myself, I am indeed annoyed when people around my age complain about stuff like this.
I certainly would not hire anyone who thought inline variables made Pascal "hard", as that just comes off like a sign of general incompetence to me.
-
Classic Pascal is like the ancient Greek language - beautiful and precise. But modern people speak other languages.
-
The imagnation that one can force the implementation of non-pascalish features into FPC just with money is really frightening me.
You seem to have a vivid imagination. I haven't seen anyone in this thread suggest the addition of "non-pascalish" features to the compiler, for money or otherwise.
Perhaps not in this thread, but they are there. Inline type declaration, untyped variables...
The title "Features for money", in a way could be understood as "Syntax for money". You still think this would be a good idea?
The core developers would always have the final say anyway. That's why marcov said that such ideas should first be discussed on the forum or better on fpc-devel, because if it turns out that the core devs would say no anyway, then why waste money?
People are really looking for alternatives of C.
Yes, they absolutely are.
But they're also looking for languages that support extremely basic things like inline variable declarations, which all of the aging FPC die-hards like to pretend are the devil despite the fact that literally every language uses them and it is not a problem at all, because why the hell would it be.
The crybaby FUD "oh my god, Delphi is ruining Pascal because it introduced inline variable!" bullshit is unbelievably annoying. No, Delphi added a feature that should have been added long ago. Anyone who thinks that inline variables complicate anything is literally an idiot, who cannot possibly be anything resembling a professional programmer in 2019.
Those languages were designed around the ideas of inline variables. The idea of Pascal was an easy to read, declare first language. Inline variables are anything but. And "every other language out there has it" is not a valid reason to include something in a language.
Nobody cares that your language / compiler can make cool Android apps via Lazarus, if they are also aware that it has core developers who actually believe utterly moronic things like "generics are slower than using untyped pointers for everything" or whatever.
Well, it is a fact that a variant of TStringList based on generics was slower than the non-generic one. And especially if managed types (strings for example) are involved untyped pointers are indeed faster, but I personally favor the increased type safety I get with generics.
-
I think a bounty for features is a good approach.
I also would not think of a problem if there was a good unofficial FPC branch with more experimental and bleeding edge features, as long as it's synced to main fpc branch regularly.
The features needed the most are usually already presented in delphi, and can be simply handled as feature request bounties, if financial reward would help them get thru.
I would however also recomment a bounty for more up to date bindings for popular libraries, jedi was a good approach.. a long time ago, but lately, there's not much projects working on delphi interoperatibility bindings.
-
Well, you forget that the standard distribution of FreePascal and Lazarus already contain *way* more features and bindings than Delphi ever had to this day.
And Jedi is too Windows centric to be a serious proposal. I would ask the Delphi community to get up to scratch with what FreePascal offers...... :D :D :D
-
There is plenty of room to improve Freepascal. There are still fairly basic features missing, among them, the ability of having multiple variants in a record definition. The absence of that feature makes porting C code to FPC more work than it should be.
(This is not true. There is a mechanical way to transform those, and if it happens enough you could write software for it or improve header converters:
type
tsomeunion = record
case boolean of
false : ( x : Integer);
true : ( y : word;
case boolean of
true : (z:word);
false: (a:integer);
);
end;
begin
end.
See http://rvelthuis.de/articles/articles-convert.html
Which brings me back to the point, people that don't know what there is, shouldn't be designing language. That only leads to more syntax, and often duplicate just because some other language does it in a different way (and every newbie comes up with it each time again, queue inline variables)
Most new syntax is micro. Optimizations for very local problems, even the old guideline "must make things possible not otherwise" is regularly trampled.
-
So, the bottom line is, it is quite simply impossible to increase the popularity of FPC while simultaneously clinging to these woefully outdated and often wrong opinions on things.
Which is absolutely nonsense. People don't chose languages because of micro syntax, but because what they can do with it.
We heard this tired old line for every language change since 1997, and other than delphi compatibility features, I still have to see the first user coming because of such changes.
-
(This is not true. There is a mechanical way to transform those, and if it happens enough you could write software for it or improve header converters:
really !?... if it is as simple as you are so conveniently pretending it is, I can't help but wonder why you haven't done it. After all, I am under the impression that you are one of the main API header maintainers for FPC.
type
tsomeunion = record
case boolean of
false : ( x : Integer);
true : ( y : word;
case boolean of
true : (z:word);
false: (a:integer);
);
end;
begin
end.
yes, most programmers know how to write a "hello world" program and translate a trivial union.
See http://rvelthuis.de/articles/articles-convert.html
It seems to me that you should have read the article a bit more carefully. One of the things required to apply the multiple "union collapsing" is determining the largest union in the group, something which in many cases is far from trivial since the type definition being used are very likely to be in other .h files and not in the .h file the program is processing.
Which brings me back to the point, people that don't know what there is, shouldn't be designing language.
I completely agree with that. One thing I've noticed is that people who actually know how to design a programming language don't leave much, if any, "undefined territory" in it.
That only leads to more syntax,
The point you are very conveniently missing is, even using the techniques Rudy shows in his article is less than desirable and the reason is obvious: when you look at the documented structure in MSDN it will no longer look like the translated structure. Parallelism went out the window and, if there is a mistake somewhere, due to alignment or wrong size, it will be difficult to find.
Those are the things a well designed language avoids. It doesn't create situations which demand a significant amount of attention from the programmer to solve them.
It's not about syntax, it's about code and definitions that are clear, succinct, accurate and easily understood. Yes, syntax most definitely has an influence in those areas.
It's no wonder Pascal has lost so much ground and isn't going anywhere. Even trivial things that should have been implemented long ago, meet resistance supported by rather deficient reasoning. Good thing the auto industry doesn't share your methods, we'd still be driving Model Ts which you could get any color you wanted as long as it was black.
-
(This is not true. There is a mechanical way to transform those, and if it happens enough you could write software for it or improve header converters:
really !?... if it is as simple as you are so conveniently pretending it is, I can't help but wonder why you haven't done it. After all, I am under the impression that you are one of the main API header maintainers for FPC.
Because the problem is not big enough? The one or two that occasionally happen in a header are easier fixed by hand?
(Automated conversion is overrated in practice anyway, and that is mainly because of preprocessor/conditional code, and the fact that macros are substitution based, so you can't see the intention from the use only)
It seems to me that you should have read the article a bit more carefully. One of the things required to apply the multiple "union collapsing" is determining the largest union in the group, something which in many cases is far from trivial since the type definition being used are very likely to be in other .h files and not in the .h file the program is processing.
Trying to find the next best remote detail to justify a solution to what is a non-problem?
The point you are very conveniently missing is, even using the techniques Rudy shows in his article is less than desirable and the reason is obvious: when you look at the documented structure in MSDN it will no longer look like the translated structure.
Neither does any header. The 1:1 relation simply doesn't exist. For one thing, declarations are sorted.
Parallelism went out the window and, if there is a mistake somewhere, due to alignment or wrong size, it will be difficult to find.
Not really. If you want to check that you need unittests rather than source inspection anyway. See e.g. Wine.
Those are the things a well designed language avoids. It doesn't create situations which demand a significant amount of attention from the programmer to solve them.
....For the duration of translating one union out of a mega headerset.
As said, syntax microoptimization for a non-problem. More syntax is worse than the problem it solves.
It's no wonder Pascal has lost so much ground and isn't going anywhere. Even trivial things that should have been implemented long ago, meet resistance supported by rather deficient reasoning. Good thing the auto industry doesn't share your methods, we'd still be driving Model Ts which you could get any color you wanted as long as it was black.
Your reasoning is that people would select a model T over a new car simply because it had a shade of colour that is not available for the new car. Totally disregard for proportion.
Actually, strike that. Color is an important feature. Make it some detail somewhere in the engine's suspension, and then you get the point.
And of course the elephant in the room is that users select languages more for framework than language details to begin with.
"What can I achieve in a short time with it?" is the central user tenet, and that is governed MORE by libraries than by language details. Which is why the "change this language feature and more users will come" argument is fundamentally flawed.
Micro language optimization only matters for language discussions in forums.
-
"What can I achieve in a short time with it?" is the central user tenet, and that is governed MORE by libraries than by language details. Which is why the "change this language feature and more users will come" argument is fundamentally flawed.
+1
a good example here in brazil is the acbr project.
-
Because the problem is not big enough? The one or two that occasionally happen in a header are easier fixed by hand?
That's an interesting comment. If the problem is so small and trivial then how come FPC is missing so many APIs and structure definitions ? ...
You don't solve "small" problems ?
(Automated conversion is overrated in practice anyway,
Of course, a programmer's dream come true is to translate thousands of APIs and data structure definitions by hand. It is very kind of you not to want to deprive programmers of such pleasures.
Trying to find the next best remote detail to justify a solution to what is a non-problem?
It's a non-problem for people who don't program. There is no doubt in my mind that API function and data structure definitions are likely a non-problem to the average shoe salesman but, for most programmers, they tend to make themselves needed.
Seen from that viewpoint, you're right, it really is a non-problem for a significant percentage of the population.
The 1:1 relation simply doesn't exist. For one thing, declarations are sorted.
There is a 1:1 relation in the translation of API headers. There is _no good_ reason why there isn't a 1:1 relation when translating data structures.
Not really. If you want to check that you need unittests rather than source inspection anyway. See e.g. Wine.
Yes, really. Parallelism does go out the window when there isn't a 1:1 between the original and the translation. Wine is neither here nor there in the subject.
....For the duration of translating one union out of a mega headerset.
one union ?... are you inspecting a bacon-cheeseburger API ? ... because Windows certainly has quite a few more data structure definitions that include a union and even multiple of them in the struct definition and, many of them are tedious to translate "manually" because Pascal is somewhat lacking in that area.
As said, syntax microoptimization for a non-problem.
This has nothing to do with "microoptimization" but... if I have to see how it has something to do with it, do feel free to enlighten me (I suspect you will anyway... though I refer to it as enlightenment because of my generous nature)
More syntax is worse than the problem it solves.
Nice technique. You declare something and, because you did, it must be true. Move over Bertrand Russell.
Your reasoning is that people would select a model T over a new car simply because it had a shade of colour that is not available for the new car. Totally disregard for proportion.
Nice try. My "reasoning" is that if you were in charge of car designs, we'd all be driving Model Ts with triangular wheels (microoptimizing the wheels making them round would not solve any problem since the car can move with the wheels it has)
And of course the elephant in the room is that users select languages more for framework than language details to begin with.
Users hopefully (but not always, unfortunately) select the tool that makes the task easiest to accomplish correctly. For some users, myself among them, it's rather "convenient" to have a complete set of API function and structure definitions (one of the very few things I miss about C/C++). Having to deal with an incomplete set of APIs and, an often enough, not straightforward conversion of data structures, takes some shine away from the tool.
"What can I achieve in a short time with it?" is the central user tenet, and that is governed MORE by libraries than by language details.
If all a programmer cares is how long it takes to achieve something with the language, they can spend their day writing "hello world" programs. Even a beginning programmer should be able to write a few of them every day.
You should give some thought that some programmers use a programming language for what they can accomplish with it and, if the language doesn't have the necessary capabilities to implement the target task then the time spent with that tool will be _zero_.
Which is why the "change this language feature and more users will come" argument is fundamentally flawed.
Did anyone say something to the contrary ?... I must have missed it.
Micro language optimization only matters for language discussions in forums.
You're rather fond of that meaningless term "micro language optimization". You get to pepper your deficient arguments with it to make them sound impressive. Good stuff but, I have seen that syntax before.
Marco,
I got to give you credit for being very consistent. Any discussion of anything that could potentially help FPC go forward is "micro optimization" you don't want to have anything to do with. That syntax horse is so dead by now... what a beating it got... poor thing.
-
Because the problem is not big enough? The one or two that occasionally happen in a header are easier fixed by hand?
That's an interesting comment. If the problem is so small and trivial then how come FPC is missing so many APIs and structure definitions ? ...
Maybe because unions are not the main problem?
You don't solve "small" problems ?
Depends. If the solution is adding to the language, you are making something big out of something small, due to the fact that needs to be supported ad infinitum, including all kinds of cross-talk.
(Automated conversion is overrated in practice anyway,
Of course, a programmer's dream come true is to translate thousands of APIs and data structure definitions by hand. It is very kind of you not to want to deprive programmers of such pleasures.
I'm still waiting for your maintainable auto-translation. While I'm sceptic, I'm still hoping you convince me otherwise.
Trying to find the next best remote detail to justify a solution to what is a non-problem?
It's a non-problem for people who don't program. There is no doubt in my mind that API function and data structure definitions are likely a non-problem to the average shoe salesman but, for most programmers, they tend to make themselves needed.
Sure. But mostly on an exist or not level, not these kinds of details. The user just sees that his .xxxx fieldreference works, no matter if it is a pascal nested union or a c nested union.
one union ?... are you inspecting a bacon-cheeseburger API ? ... because Windows certainly has quite a few more data structure definitions that include a union and even multiple of them in the struct definition and, many of them
are tedious to translate "manually" because Pascal is somewhat lacking in that area.
I'm talking about those non trivial unions that might be hard to automatically map to current support (and then still: in theory)
As said, syntax microoptimization for a non-problem.
This has nothing to do with "microoptimization" but... if I have to see how it has something to do with it, do feel free to enlighten me (I suspect you will anyway... though I refer to it as enlightenment because of my generous nature)
Since you asked: microoptimization on language level. Not necessarily code generator.
More syntax is worse than the problem it solves.
Nice technique. You declare something and, because you did, it must be true. Move over Bertrand Russell.
Who? I'm not that deep into Anglo-Saxon authors. Which period is he from? Elizabethan? Victorian?
Users hopefully (but not always, unfortunately) select the tool that makes the task easiest to accomplish correctly.
True. But usually they avoid knowing all the details, and its the details we are discussing.
For some users, myself among them, it's rather "convenient" to have a complete set of API function and structure definitions (one of the very few things I miss about C/C++). Having to deal with an incomplete set of APIs and, an often enough, not straightforward conversion of data structures, takes some shine away from the tool.
Ah, that explains why you make the whole world revolve around your issue.
Anyway, enough sophism, while fun, I get tired of it quickly, so let's just cut to the chase:
- I don't want big upsets to the current headers because they are hand maintained.
- But I don't rule out anything if you come up with an automated tool to translate headers in sufficient quality. I'm probably even game if anything you show has potential, even if it is not a drop in solution yet. I'm well aware of the current approach problems, just don't have the time to start the alternative from scratch
The current sets are not set in stone, and while I refrain from doing mass-restructures in them, I'm not above throwing them away for something better, and for all, consistent.
For that, I suggest you make a header conversion system that can take meta data instructions on how to translate. (e.g. lists of functions to also translate as var etc). So never edit the result, always edit the process (the converter) if a change needs to be made. Similarly the metadata can disambiguate most macros into decent structures.
I tried building something like that in 2003-2005 while translating commctrl, but alas, I already turned thirty, and my limitless free time periods were over.
In short it is a combination of "Le roi is mort, vive le roi!" and "be careful what you wish for". Show enough prowess with windows headers, and I'll gladly surrender the throne to you. You'll be FreePascal's Windows header king!.
I got into this because in the 2000-2005 frame I did some new stuff with windows api, and the old 1998 headers were deficient and unmaintained. Many others also worked on it, but went out of steam long term, leaving me the defacto "king", though I never aspired to it.
So, show me your metal, and there is a good chance you'll be king of the headers.
-
Maybe because unions are not the main problem?
I see.. only the main problem deserves attention... the other problems don't. I have to say, that's an economical way of paring the number of problems down.
Depends. If the solution is adding to the language, you are making something big out of something small, due to the fact that needs to be supported ad infinitum, including all kinds of cross-talk.
I simply mentioned that removing the limitation on variants forced to be unique and last would make translating headers easier. That is part of the solution but, it isn't only for C headers, it would also make some Pascal only record definitions simpler and easier. No doubt, that's a terrible thing.
I'm still waiting for your maintainable auto-translation. While I'm sceptic, I'm still hoping you convince me otherwise.
I suggest you don't wait for that. I never offered such a thing. In this case, your self-grown skepticism is justified. I have no intention of convincing you otherwise.
I'm talking about those non trivial unions that might be hard to automatically map to current support (and then still: in theory)
and what I'm talking about is enhancing the language to make the process simpler no matter how many nested unions and structs there are. It's not about one particular case.
Since you asked: microoptimization on language level. Not necessarily code generator.
is that statement supposed to answer a question ?... just a reminder, what is it you are so fond of calling "micro optimization" ?
Who? I'm not that deep into Anglo-Saxon authors. Which period is he from? Elizabethan? Victorian?
Don't worry about it. There are some thing you shouldn't concern yourself with. It's another one of those "non problems".
True. But usually they avoid knowing all the details, and its the details we are discussing.
Someone has to take care of the details for others to enjoy the luxury of ignoring them.
Ah, that explains why you make the whole world revolve around your issue.
No. It only explains why I used it as an example. It's a good thing the world doesn't revolve around any of my issues, it would wreak havoc with seasons.
Anyway, enough sophism, while fun, I get tired of it quickly, so let's just cut to the chase:
That sounds like good news. Hopefully, it means you're done typing words like "micro optimization" and "syntax <something" (I don't remember and don't really care to refresh my memory.)
- I don't want big upsets to the current headers because they are hand maintained.
I doubt anyone is interested in big upsets to the current headers. I'm guessing but, I doubt I'm the only one who would welcome any improvements that makes them easier and more straightforward to translate.
- But I don't rule out anything if you come up with an automated tool to translate headers in sufficient quality. I'm probably even game if anything you show has potential, even if it is not a drop in solution yet. I'm well aware of the current approach problems, just don't have the time to start the alternative from scratch
Sounds like you've been smoking some good stuff. I hate to pop your high but, I never offered to create or improve an automated header translation tool.
The current sets are not set in stone, and while I refrain from doing mass-restructures in them, I'm not above throwing them away for something better, and for all, consistent.
I'm quoting that "just in case" someone offers better and you attempt to drown them in "micro optimizations" and "syntax whatever".
For that, I suggest you make a header conversion system that can take meta data instructions on how to translate. (e.g. lists of functions to also translate as var etc). So never edit the result, always edit the process (the converter) if a change needs to be made. Similarly the metadata can disambiguate most macros into decent structures.
Very nice suggestion. If someday I consider creating a header conversion program, I'll keep it in mind.
I tried building something like that in 2003-2005 while translating commctrl, but alas, I already turned thirty, and my limitless free time periods were over.
You couldn't solve that "non problem" before turning thirty ?... I think I'm disappointed now.
In short it is a combination of "Le roi is mort, vive le roi!" and "be careful what you wish for".
Good thing that's not a structure definition... it's "Le Roi est mort, vive le Roi!"... there is one field that got messed up in the translation.
Show enough prowess with windows headers, and I'll gladly surrender the throne to you. You'll be FreePascal's Windows header king!.
I'm terrible at converting headers (everything I know about converting headers I just learned from the link you provided.) In your case it's "Le Roi est vivant, vive le Roi!"... that reminds me, there are a couple of missing header definitions I submitted several months ago that the king has not processed yet.
So, show me your metal, and there is a good chance you'll be king of the headers.
I've just realized I'm a plastic (recyclable, of course) kind of guy. No metal here (who wants rust anyway?)
Thank you for the warm welcome you gave to the idea that is the subject of this thread.
-
@440bx:
Why are you getting that off-topic in "your own" thread?
The discussion about a single specific feature (in a way that it is not just used as an example) gives me the impression, that my scepticism was right and your reguest for "features for money" actually has the aim to push something through, that otherwise would be rejected.
-
@440bx:
Why are you getting that off-topic in "your own" thread?
There is Marco to thank for that.
The discussion about a single specific feature (in a way that it is not just used as an example) gives me the impression, that my scepticism was right and your reguest for "features for money" actually has the aim to push something through, that otherwise would be rejected.
I used that feature as an example. Yes, it is one that I am interested in. Anyone is more than welcome to provide their own example of features they would be willing to support, since I don't know what those are, I can't use them as examples.
If telling yourself you were "right" makes you feel good, by all means, be my guest.
-
I've posted about it before, but this library / program: https://github.com/neslib/Chet (https://github.com/neslib/Chet)
gives pretty much 100% correct translations of basically any header you throw at it (for which it has its use of libClang to thank, specifically).
The only caveats are that it's designed specifically for Delphi, and also that it does tend to leave in a number of "unrelated" definitions for things (which you'll of course generally want to remove from the "final version" of a given translation.)
I'm currently working on a proper FPC port of it though, as even as-is it's way, way, way better than H2Pas. (No offense meant by that, but really, I don't think anyone has ever claimed H2Pas was "good". It relies on a (port) of a (really outdated) version of, uh, Yacc after all...)
Well, it is a fact that a variant of TStringList based on generics was slower than the non-generic one. And especially if managed types (strings for example) are involved untyped pointers are indeed faster, but I personally favor the increased type safety I get with generics.
Again, I'm not a fan of the general tone of the post you were responding to there, but the "generic TStringList was slower because of generics" thing is absurd.
It was slower almost entirely because the specific implementation of maps in FGL (one of which the generic TStringList used internally) is awful. (I.E. they are in no way, whatsoever, actual hashmaps, amongst various other flaws.)
Were it based around stuff from the current revision of Generics.Collections, it would almost certainly be quite a bit faster.
In general: FPC monomorphizes generics in all cases, thus, they cannot be slower, because they are literally the same thing as a directly equivalent non-generic implementation.
-
I'm currently working on a proper FPC port of it though,
I'm really looking forward to your port of it.
Do you have some rough idea as to when you might be done with it ?
-
Do you have some rough idea as to when you might be done with it ?
Soonish. Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.
I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.
-
Soonish.
Very nice!.
Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.
There is always something... <chuckle>
I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.
Nice.
Thank you for the update on your progress.
-
Well, it is a fact that a variant of TStringList based on generics was slower than the non-generic one. And especially if managed types (strings for example) are involved untyped pointers are indeed faster, but I personally favor the increased type safety I get with generics.
Again, I'm not a fan of the general tone of the post you were responding to there, but the "generic TStringList was slower because of generics" thing is absurd.
It was slower almost entirely because the specific implementation of maps in FGL (one of which the generic TStringList used internally) is awful. (I.E. they are in no way, whatsoever, actual hashmaps, amongst various other flaws.)
To be fair: I have never looked at the generic TStringList, thus I hadn't present that it's based on TFPGMap<>. The time when that was implemented and tested was before my time and I was only presented with the results when I asked about the generic TStringList, namely that it's slower than the non-generic one. I had enough items on my ToDo list (and still do), so I simply turned my attention to another points. *shrugs*
In general: FPC monomorphizes generics in all cases, thus, they cannot be slower, because they are literally the same thing as a directly equivalent non-generic implementation.
Now it's you who's generalizing. As always it depends on the implementation. Take a look at TFPGList<>: It's implemented as a descendant of TFPSList and the generic's type handling is done through virtual functions. Compare that to a generic list that implements all in a single class (even if both simply use a dynamic array as implementation). Here the TFPGList<> is slower than this hypothetical generic list due to the virtual call (it might be only a small difference in performance, but it will be there).
But the performance discussion aside, I also stated that I use generics simply due to the type safety they provide. That is IMHO the main reason to use them. I know that there are core developers that don't like generics, but I'm definitely not one of them (after all I developed much of the new functionality since 2.6.4 :-[ ).
-
Do you have some rough idea as to when you might be done with it ?
Soonish. Currently the blocker is just that the GUI "frontend" app for it went ahead and used Delphi 10's "TCardPanel", which Lazarus does not implement, making the app rather annoying to translate without destroying the LFM file.
I've gotten a skeleton of it going with the "TDI" Lazarus package, and am currently just carefully trying to make sure I don't break any of the original UI behavior.
Did you running windows headers through it? Can it handle calling convention macros?