[CLOSED] Midnight trolling: Don't take everything serious!

[marcov]

In fairness, I /have/ seen features criticised in the mailing list as "too C-like".

There is in my mind a grey area between "feature" and "new grammar". 

Well said. And not just that the feature might follow a different syntax paradigm requiring the various a+++++b disambiguations and errormessages), but also to really make the same use of it as in the other language is often quite different (e.g. in the case of when features are transplanted from GCed languages)

[MarkMLl]

In fairness, I /have/ seen features criticised in the mailing list as "too C-like".

There is in my mind a grey area between "feature" and "new grammar".  Would the following request fall under new feature or new grammar (or just simply make FPC compile C code):

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

1.   a += foo(++b--);

Some may claim this line of code can replace three lines of Pascal code, saving precious seconds of typing because typical Pascal code would be three lines (OK it can be reduced to two lines, but then it is already a bit obfuscated). But is it Pascal (in my opinion no!), CPascal, PascalC, Pascal++ or plain C?

I agree that's not Pascal and I think it would be a substantial syntax change since it would probably imply that the lexer could no longer treat a leading - as part of a number. I think it's C and I suspect that a lot of people would argue that it's not good C.

MarkMLl

[BrunoK]

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

1.   a += foo(++b--);

Doesn't

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

1. a := a + foo(b + 1);

do the same thing ?

[ccrause]

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

1.   a += foo(++b--);

Doesn't

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

1. a := a + foo(b + 1);

do the same thing ?

Indeed it does.  Lets see where this thread drifts to next.

[guest65109]

Quite frankly I'd agree with most of that. If there's one thing I don't entirely agree with it's your assertion that because Pascal is comparatively verbose it's slow to write: if the sourcecode verbosity contributes usefully to the compiler's detection of errors, or for that matter to the detection of errors during testing, I'd say that it's entirely excusable.

Besides which, C++ and "modern C" attempt to have type checking etc. which is probably stricter than Pascal was originally, and working round that can result in a maze of casts and macros which is difficult to navigate even for those fully versed in C idioms. And setting structures etc. up properly can be pretty damn verbose as well... and by "properly" I mean "sufficient to satisfy all doctrine about how C/C++ can go wrong if not carefully written".

Is my writing good? This is the first time I write that much text in English. I know it's full of grammar errors, sorry everyone for my poor English  Please don't hate me everyone, I only want to write something to entertain everybody here. Finally, good night everyone. Bye 

Since you ask... "This is the first time that I have written this much text in English" would be better, and "grammatical" rather than "grammar". Apart from that you're doing fine :-)

MarkMLl

I miss of C-like languages the ability to declare variable everywhere. Professionals see the idea before they code. Amateur like me try to find the idea when coding. This mean I have no idea how to solve the problem. Just trial and error. People would said: come back and take a course on structure and algorithm. Honestly, I have tried many times but I'm too stupid to understand. I also lack of mathematics background, so I fear anything about Graph. If you ask me to implement a double linked list myself I would rather cry 

Pascal forced me to declare anything at the beginning. Because I have no idea how to solve the problem or how many variables are needed and I have to jump back and forth regularly. If the procedure is long it's very painful. The IDE must be provide some shortcut key for that, but sadly, I don't know 

[MarkMLl]

Pascal forced me to declare anything at the beginning. Because I have no idea how to solve the problem or how many variables are needed and I have to jump back and forth regularly. If the procedure is long it's very painful. The IDE must be provide some shortcut key for that, but sadly, I don't know 

Make the procedures shorter. Or if you can't, then have multiple windows open looking at the same file.

Pascal departed from ALGOL in that it insisted that users define variables in one place, specifically outside the block that define their scope. I'm not convinced that was a good idea, since it precludes defining loop control variables locally.

MarkMLl

[guest65109]

Pascal is a very easy to read language, but very very inefficient to write because it's too wordy.

False.
Modern C++ syntax requires more symbols to be used, compared to Pascal.
Java/C# with the dotted notation, has be need "wordier" than Pascal from the start.

It should be because I'm more familiar with mathematics symbols, I found nothing difficult to parse and understand the syntax of C++/C#/Java. I found it to be more compact and easier to interpret, writing also way faster. I hate Objective C's syntax, though, I don't understand it, it's very difficult to parse for me.

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

1. TMyList = specialize TFPGObjectList<TMyClass>;

You see, I think specialize is a spare keyword. Just like this is enough:

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

1. var MyArr = new ArrayList<String>();

This Java is unfamiliar, isn't it? It's Java 10. Language does improve over time.

They're very wrong. C# in fact is the saving of Delphi heritage. By combining Object Pascal with Java syntax,

False. C# syntax was based on C, rather than Java. So, there's no "Object Pascal" in "Java syntax".

Do you see C# also use upper camel case like Delphi? If it's C it should be underscore case. If it's Java it should be lower camel case. C# also has very similar classes and API.

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

1. Application.Init();
2. Application.Run();
3. Application.Quit();

Does it sound familiar? Of course it is:

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

1. Application.Terminate;

C# really make the very boring and inefficient to write in Delphi language to be something much more easier and comfort to write in.

False.
The biggest difference is that Pascal will likely ask you to release the allocated resource, file C# will do a garbage collection in runtime.
On the other hand, in C# system resources has to be explicitly disposed anyway (while in pascal, the system resource can be released together with the explicit release of the object).

I hate to call the Create constructor directly.

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

1. a := MyClass.Create('Pascal');

Why don't it just be like this:

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

1. a := MyClass('Pascal');

Having to manually Free object is obviously inconvenient, because sometime we forget to Free it and it will leak memory.

[guest65109]

Pascal forced me to declare anything at the beginning. Because I have no idea how to solve the problem or how many variables are needed and I have to jump back and forth regularly. If the procedure is long it's very painful. The IDE must be provide some shortcut key for that, but sadly, I don't know 

Make the procedures shorter. Or if you can't, then have multiple windows open looking at the same file.

Pascal departed from ALGOL in that it insisted that users define variables in one place, specifically outside the block that define their scope. I'm not convinced that was a good idea, since it precludes defining loop control variables locally.

MarkMLl

Yes, I think the same. Having to declare loop variables at the beginning is plain stupid. We ended up with a long ugly declaration like this:

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

1. var
2.   I, J, K, L, MIN, MAX, TMP, SUM: integer; // how these variables have any meanings outside of the loop?

With modern C++ it should be like this:

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

1. for(auto i = 0; i < 10; i++) {}

[guest65109]

If counting the ratio of LOC with the feature it providing Delphi should be the most inefficient language. So many line of code just to archive a simple functionality.

Here is a very "efficient" implementation of a well known problem, all you have to do is, figure out what the problem is. In the meantime, you can enjoy how efficient it is.

Code: C  [Select][+][-]

1. int v,i,j,k,l,s,a[99];main(){for(scanf("%d",&s);*a-s;v=a[j*=v]-a[i],k=i<
2. s,j+=(v=j<s&&(!k&&!!printf(2+"\n\n%c"-(!l<<!j)," #Q"[l^v?(l^j)&1:2])&&++
3. l||a[i]<s&&v&&v-i+j&&v+i-j))&&!(l%=s),v||(i==j?a[i+=k]=0:++a[i])>=s*k&&
4. ++a[--i]);printf("\n\n");}
5.  

This is plain dishonest! This code is taken from an obfuscation contest. You could obfuscate any language, even Pascal.

[guest65109]

You can download both Tomboy and tomboy-ng from github, here is the fact I promised, unzipped, the Tomboy source is 14 Meg, tomboy-ng is 5 Meg.

Davo

Your calculation is wrong. Lazarus is a RAD environment. Many people have done the heavy lifting for you and anything you have to do is just drag and drop and bind everything together using logic. Mono is not a RAD environment. Even though they have the Stetic GUI Designer, you pretty much have to write anything yourself. They have to deal with GTK# directly (which just is an C# OOP wrapper of GTK+), the LCL is much more high level than GTK#. My conclusion is: you can't compare the size of the two projects, as you can't know how much of LCL code your application has used. Anyway, choosing Lazarus for your project is a very wise decision.

[guest65109]

In fairness, I /have/ seen features criticised in the mailing list as "too C-like".

There is in my mind a grey area between "feature" and "new grammar".  Would the following request fall under new feature or new grammar (or just simply make FPC compile C code):

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

1.   a += foo(++b--);

Some may claim this line of code can replace three lines of Pascal code, saving precious seconds of typing because typical Pascal code would be three lines (OK it can be reduced to two lines, but then it is already a bit obfuscated). But is it Pascal (in my opinion no!), CPascal, PascalC, Pascal++ or plain C?

This is just bad C code. Why the Pascal devs ever want to import such thing like this?

[winni]

This is just bad C code.

That is a tautology.

[ccrause]

In fairness, I /have/ seen features criticised in the mailing list as "too C-like".

There is in my mind a grey area between "feature" and "new grammar".  Would the following request fall under new feature or new grammar (or just simply make FPC compile C code):

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

1.   a += foo(++b--);

Some may claim this line of code can replace three lines of Pascal code, saving precious seconds of typing because typical Pascal code would be three lines (OK it can be reduced to two lines, but then it is already a bit obfuscated). But is it Pascal (in my opinion no!), CPascal, PascalC, Pascal++ or plain C?

This is just bad C code. Why the Pascal devs ever want to import such thing like this?

It is perfectly legal C code. The point I tried to make is not everyone's idea of an "improvement" is universally accepted as such. Again, just because language Z has feature Y (even if it is useful and intuitive to use in language Z) does not mean it will make Pascal more Pascal-like (now what does THAT mean )

[MarkMLl]

This is just bad C code. Why the Pascal devs ever want to import such thing like this?

Now I'm afraid that that /is/ bad English on your part: needs a verb. If you'd said

"Why did the Pascal devs ever want to import such thing like this?"

the answer would be "they didn't" since you'd implied it was something they'd done. But if you'd said

"Why would the Pascal devs ever want to import such thing like this?"

the answer would be "they don't" since you'd asked whether they were contemplating the possibility.

Or if you'd said "why should" it implies that somebody was attempting to coerce them, and so on.

However, I don't think I recall anybody seriously suggesting that Object Pascal should support ++ and -- . More to the point is that I've seen += etc. criticised as too C-like, and I think that it's that criticism that keeps them as optional features which have to be enabled by the -Sc command-line option. Same applies to the inline conditional implemented by ALGOL and C but not by Pascal, which /would/ be useful.

MarkMLl

[skalogryz]

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

1. TMyList = specialize TFPGObjectList<TMyClass>;

You see, I think specialize is a spare keyword. Just like this is enough:

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

1. var MyArr = new ArrayList<String>();

Pascal rule - declare first, then use. So at least you have to have

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

1. type
2.   TMyList = TFPGObjectList<TMyClass>;
3. var
4.   MyArr : TMyList;

"specialize" can be omitted in Delphi syntax mode.
That really reminds me of 1979's article of "Why pascal is not my favorite language".
One of the reasons - you've to declare a type, prior to passing as a function/pascal argument.

Ok. In Pascal one has to introduce exactly 1 type declaration.
But in C one might want to retype the type declaration every time they pass it as an argument?!
This is how C-like languages code becomes more "wordier" than Pascal.

Historical note: in original C there was no custom type definition. So it was a language requirement to type out the whole declaration again.

Do you see C# also use upper camel case like Delphi? If it's C it should be underscore case. If it's Java it should be lower camel case. C# also has very similar classes and API.

1) Library structure has nothing to do with a language.
Check out this Swift/Objective-C class NSApplicaiton.
You see methods there: Init(), run(), stop(), terminate().
What conclusion can we make out of that?

Object Pascal invented in 1980s was designed after Swift language invented in 2014!
Why?! methods are named similar!

2) CamelCase or lowercase or UPPERCASE, Pascal doesn't really care. It's case insensitive.
You might want to inspect some FCL packages. LOTS of them are pure lowercase...

I hate to call the Create constructor directly.

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

1. a := MyClass.Create('Pascal');

Why don't it just be like this:

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

1. a := MyClass('Pascal');

you forgot the new, keyword  in front of MyClass to be C compatible.
I'd hate to explain the difference between C++ and Pascal constructors, because I hate to go deeper, stating that C++ classes can reside on stack, while Pascal are heap only... and then virtual methods and virtual constructors...

Instead, I can suggest you to supply an allocation function for each of the class you want to use.

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

1. function MyClass(const p: string): TMyClass;
2. begin
3.   Result:=TMyClass.Create(p);
4. end;

That's it. With that function you can create classes in the manner you like.

Having to manually Free object is obviously inconvenient, because sometime we forget to Free it and it will leak memory.

That's why the Garbage Collection got so popular idea among PM.
Protect a project from a poor engineer. Poor Engineer = cheaper development.

As a matter of fact, RTL provides a sort of a mechanism for automatic release of hierarchical objects.
But all of them should be TComponent descendant