Useful Oxygene Features for FPC?

[Shpend]

Hello guys,

this time I really wanted to you to introduce some language-features of the latest RemObjects Oxygene Version.

I worked quite a lot since a couple of months with oxygene and I noticed some stuff which was really good but the rest cant stand with FPC so I switched back to my favor language 

Here are some stuff, which is IMHO, really useful and needed:
https://www.elementscompiler.com/elements/oxygene/language.aspx 
(all Topics listed below you can find on this specific page)

OOP-MODEL:
  1) Class Contracts:
  2) Sequences and Queries
  3) Tuples + their behaviour more important
  4) Duck Typing + Soft Interfaces
  5) Cirrus/Aspect oriented Programming
  6) Nullable Types + the ":" operator

MULTITHREADING
  1) Lock
  2) Parallelism
  3) future types
  4) await + async
 
IMHO when FPC could adapt these models in form of own Keywords, this language would gain more popularity.

Would love to hear from you :=)

Shpend

[lucamar]

IMHO when FPC could adapt these models in form of own Keywords, this language would gain more popularity.

Or one could just directly start programming in Python or whichever else they picked their "features" from

[440bx]

IMHO when FPC could adapt these models in form of own Keywords, this language would gain more popularity.

I think you're right.  Oxygene does have a number of very nice features that help create better, cleaner, more robust code.

Having those features in a compiler instead of an interpreter that, in addition to being an interpreter, depends on a large library (dot net) would be a definite plus.

There are other languages, some very old ones, that have some very nice features that help create simpler, better, more robust and easier to understand code.  They don't seem to get much attention.

Computer languages seem to be like fashion, driven more by fads than logic. 

[marcov]

Here we go again, sigh.

[440bx]

Here we go again, sigh.

Is there something wrong about acknowledging that there are nice features in other languages that would be nice to have in FPC provided they could be implemented in a Pascal-ish way ?

FPC has "imported" a number of features from C, which I think is a good thing.

[michaelthuma]

There is nothing wrong with acknowledging that nice features do exist. I personally fairly make use of them.

Wondering what makes spreading a language beyond those who decided to use it freely beneficial. Of course a macro assembler like C or C++ used in a little more sophisticated C-style is attractive, no doubt about that.

//referring to the original post in the thread
Growth is a phenomenon that just happens on 'things' that work unattended, pretty similar to nature.

Most of the OO frameworks are designed with find the one place in the hierarchy (the guilty one) which is nothing but a requirement from the procedural world. So far almost none has taken the opportunity to get rid of such a design. What people play today is still the old game of trying to put something top-down orchestrated on something that works unattended an hope it will stay pretty much the same. It will grow 

Say it. You want to hand over your legacy code to someone else one day. That' what you all want  one day. Rest assured, that won't work.

When I watched a video from Google I/O, I think, Kotlin and co-routines were presented. Well. Take a ride with the time machine, go back to the mid 90s to university of Linz and ask for Oberon combined with co-routines (Operating systems II (second course))

Oxygene combines more than just a few language features. The 'real' change in the area of programming languages happend with Ruby and Python. Not talking about Rails or such things. If you want Spark use Ada/Spark. Look at Ada. The more features built into a language the less flexible it becomes, since there is a strong tendency to present one way to solve/address an issue (kinda silver bullet). Ada was very very restrictive and to a certain degree still today.

Apart from the race for the 'best' language that started after the software conference in Berchtesgaden (late 60s) a language users was strongly tied to one certain paradigm or technology and the first class representative in the news. I do have the impression that spreading the technology is the agenda.

Here we go again, sigh.

Is there something wrong about acknowledging that there are nice features in other languages that would be nice to have in FPC provided they could be implemented in a Pascal-ish way ?

FPC has "imported" a number of features from C, which I think is a good thing.

[marcov]

Here we go again, sigh.

Is there something wrong about acknowledging that there are nice features in other languages that would be nice to have in FPC provided they could be implemented in a Pascal-ish way ?

Yes. It rarely needs to something useful. It is just parroting other languages bulletlists based on short examples with only a terribly generic "will make language more popular" as so called advantage, without any feel of what is needed or what it is good for, and without investigating any actual needs. Borrowing from GCed languages is especially pointless.

And, more importantly, a project like FPC or lazarus is about so much more than language features. New language features is a tiny corner of the development effort.

FPC has "imported" a number of features from C, which I think is a good thing.

Not so much, most came via Kylix. And even the ones that were local had a specific purpose, and were not implemented as a result of a post like this.

Oxygene is a cobbled together amalgam of features styled to like fashionable. If it were so great, you would be on the Oxygene site using it, not here.

[Rusik]

IMHO when FPC could adapt these models in form of own Keywords, this language would gain more popularity.

MULTITHREADING
      ......
  4) await + async

Do not do this!  There is no need to turn Pascal into JavaScript!
Spaghetti-code satiated with callback functions is the bad, ba-a-ad way!  In the web this can be found justification but not for the desktop app development.

[Blaazen]

I also prefer language with smaller amount of constructions and decent, rather slow and conservative evolution. FPC suits me.
When we talk about new features, there's opened feature request "case record of" on the bugtracker: https://bugs.freepascal.org/view.php?id=34091
I wonder if it is necessary and I'm curious if it will be accepted. I have no strong opinion on it, my vote would be rather - no.

[Shpend]

Here we go again, sigh.

Is there something wrong about acknowledging that there are nice features in other languages that would be nice to have in FPC provided they could be implemented in a Pascal-ish way ?

Yes. It rarely needs to something useful. It is just parroting other languages bulletlists based on short examples with only a terribly generic "will make language more popular" as so called advantage, without any feel of what is needed or what it is good for, and without investigating any actual needs. Borrowing from GCed languages is especially pointless.

And, more importantly, a project like FPC or lazarus is about so much more than language features. New language features is a tiny corner of the development effort.

FPC has "imported" a number of features from C, which I think is a good thing.

Not so much, most came via Kylix. And even the ones that were local had a specific purpose, and were not implemented as a result of a post like this.

Oxygene is a cobbled together amalgam of features styled to like fashionable. If it were so great, you would be on the Oxygene site using it, not here.

First of all, developer should let their Ego aside for a moment and look rationally on it.


As I said in my post, I did go back to FPC+Lazarus because FPC+Lazarus has:

 1) Mostly stable compiler
 2) Large library
 3) Trillions of plattforms with relative low amount of work to adabt code for the plattforms
 4) Stable and actualyl pretty good Debugger as I learned
 5) A stable sytanx
those are all points which led me back to it, so this is not a hate against FPC, its just taking things others did to evolve.
 Kind of what our mother nature does constantly.


and those points which were taken, were taken because me and other user of Oxygene saw the same so far and of course my own code experience showed me that those features lead to more robust, clean and semantic code and not as you said, that I just say for fun that its better for FPC without any experiencing those.


Butt here some small stuff I dont like of FPC syntax currently with the reason of course.

1) Generics: why introduce a "generic/specialize" keyword, its actually unneseccarry to introduce because what we see as generic is the syntax: "TType<T>" and what we see as specialize is the syntax: "var field: TType<String>"
 
2) why the need of doing: "procedure ASMCODE; assembler" asm {asm code here..} end;
//why the extra assembler need? the "asm" should be sufficient here, shouldnt it?

3)why even the need of: procedure/function instead like method(or if u dont wanna have this OOP implication, because method is more used for OOP description) then use for instance: "routine Dowork;" or "routine getStuff: TStuff";

4) why doing this for extensions: "TExtension = Type helper for record(TRecord)" instead of: "TExtension = extension of(TMyRecord)" would actually do the same because the extensiontype is based on the type it extens obviously


This is IMO not soooo cleanly designed as I think.

[ASBzone]

3)why even the need of: procedure/function instead like method(or if u dont wanna have this OOP implication, because method is more used for OOP description) then use for instance: "routine Dowork;" or "routine getStuff: TStuff";

4) why doing this for extensions: "TExtension = Type helper for record(TRecord)" instead of: "TExtension = extension of(TMyRecord)" would actually do the same because the extensiontype is based on the type it extens obviously


This is IMO not soooo cleanly designed as I think.

Surely, you realize that when making changes to an established computer language, the entire issue of backwards compatibility needs to be taken into account?

The suggestions you offer might be comparatively cleaner to write, but as for the goal of increased popularity that you implied earlier, how do you suppose developers would react if they had to change their existing code bases to deal with this?

Also, did you give any consideration to the fact that the pros you mentioned for FPC are in part available because time hasn't been spent on some of the other items that you like elsewhere?

This is not to imply that all talk of improvement or potential new features is bad.  It is more to highlight the fact that when there is not unlimited (or even "significant") budget and time for a project, attention in one area comes at the expense of attention in other areas.    Some of the items in your current FPC "pro" list might be adversely impacted by trying to implement some of these other wishlist items...

It's not an automatic win to add them...

[440bx]

2) why the need of doing: "procedure ASMCODE; assembler" asm {asm code here..} end;
//why the extra assembler need? the "asm" should be sufficient here, shouldnt it?

3)why even the need of: procedure/function instead like method(or if u dont wanna have this OOP implication, because method is more used for OOP description) then use for instance: "routine Dowork;" or "routine getStuff: TStuff";

This is IMO not soooo cleanly designed as I think.

The "simplifications" you mention would lead to a number of ambiguities that would prevent the compiler from working properly. 

Why the "extra" assembler needed ? ... simple, because it tells the compiler that the function/procedure is entirely written in assembler.  This changes the syntax expected by the compiler.  Not only that, it also changes the set of possible attributes of that function/procedure and the compiler needs to know that to do its job properly (which is the reason it requires a different syntax.)

In the example you mentioned about "routine getstuff:tstuff".  One of the problems with such a construction is that the compiler would have to scan 3 tokens past "routine" to figure out that it's dealing with a function declaration and not a procedure.  That makes the compiler's job harder and its code more complicated. 

The "keyword" "routine" doesn't give the compiler much (if any) information it can use.  This is the kind of problem that the original version of Fortran was famous for.  The compiler had to do some semantic analysis during the lexical analysis to figure out how to tokenize the input.  The resulting code was a mess. 

It's much too easy to introduce syntactic and semantic ambiguities in a language. 

Features that allow a programmer to write cleaner, simpler, more expressive code are always welcome (and oxygene has a few of them) but, their syntactic and semantic implementation must be carefully thought out or, they may end up causing more problems than they solve.

Additionally, as ASBzone mentioned, any additions or changes have to fit nicely in the current compiler framework otherwise they could end up breaking a lot of properly working existing code.  That is not what is usually considered an "improvement".

You're right that useful features in other languages should be considered and included if they are useful and it is possible to include them (some features are "very nice" but, if they get used every 2 million lines of code, they are too seldom useful to justify their inclusion in a language.), as long as, they don't introduce semantic ambiguities.

Also, the popularity of a language isn't determined by its features, robustness or its ability to express algorithms clearly and cleanly as a currently very popular language clearly shows.

[Blaazen]

My note to tuples: IMO they can be done simplier. In Oxygen:

Code: Pascal  [Select][+][-]

1. var t: tuple of (String, Int32, Boolean);

it is kind a duplicate of record.

I would do:

Code: Pascal  [Select][+][-]

1. function MyFunc(): Integer, string;
2. ...
3. var i: Integer;
4.      s: string;
5. begin
6.   i, s := MyFunc();
7.  

without need of a new reserved word "tuple".

[marcov]

Butt here some small stuff I dont like of FPC syntax currently with the reason of course.

1) Generics: why introduce a "generic/specialize" keyword, its actually unneseccarry to introduce because what we see as generic is the syntax: "TType<T>" and what we see as specialize is the syntax: "var field: TType<String>"

(note that I was against it), but it was at the time (2005 or so) considered more in sync with the Pascal parsing model. Less ambiguities.  I don't know the exact cited corner cases anymore though.

 

2) why the need of doing: "procedure ASMCODE; assembler" asm {asm code here..} end;
//why the extra assembler need? the "asm" should be sufficient here, shouldnt it?

This predates Free Pascal (TP already had it). I don't know exactly. Probably it was considered important to the parsing model to have procedure "end" match to something.

Anyway, compatibility.

3)why even the need of: procedure/function instead like method(or if u dont wanna have this OOP implication, because method is more used for OOP description) then use for instance: "routine Dowork;" or "routine getStuff: TStuff";

This was already noted by Niklaus Wirth, PASCAL's developer in the late seventies. Which is why back then the successor language to Pascal he created, Modula-2 used procedure for both cases. 

But changing something fundamental like that makes it a different language (and IMHO, therefore Oxygene is a different language).

4) why doing this for extensions: "TExtension = Type helper for record(TRecord)" instead of: "TExtension = extension of(TMyRecord)" would actually do the same because the extensiontype is based on the type it extens obviously

Well, "extension" has no defined meaning in Pascal, so this seems totally arbitrary and taste. Moreover a helper is not based on the type, like deriving a class. It is a different beast, and "helper" signals that best.

You can have multiple helpers for a type, but only one at the time active, and you need to make sure that helper is in the scope.

This is IMO not soooo cleanly designed as I think.

Clean design is not the ultimate objective.  Compatibility is. Freepascal is not a language experiment, but a production level open source compiler with a large set of libraries and a long compatibility trackrecord.  Something you acknowledge in the "Reasons why I came back to FPC+Lazarus".

If you look at the forum, and see the  constant bickering over compatibility issues you might don't believe it, but those are relatively in the fringes. Actually the high level of compatibility makes people obsess about the details.

[Thaddy]

 

4) why doing this for extensions: "TExtension = Type helper for record(TRecord)" instead of: "TExtension = extension of(TMyRecord)" would actually do the same because the extensiontype is based on the type it extens obviously

Code: Pascal  [Select][+][-]

1. {$mode objfpc}{$modeswitch typehelpers}{$macro on}{$define extension := Type helper for}
2. type
3.   TMyExtension = Extension integer
4.     function returntype:TTypekind;
5.   end;
6.  
7.   function TMyExtension.returntype:TTypekind;
8.   begin
9.     Result := GetTypeKind(integer);
10.   end;
11.  
12.  
13.  begin
14.    writeln(1000000.returntype);
15.  end.

There you go...