Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2017-07

Food for thought - language string improvement

47 messages · 16 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Graeme Geldenhuys

Ever had a problem like this? You have some SQL, say:

SELECT Customers.CustomerName, Orders.OrderID
FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;

and you want to add that SQL to the SQL property of a end up either having to turn this into a string like this:

'SELECT Customers.CustomerName, Orders.OrderID' +
'FROM Customers' +
'FULL OUTER JOIN Orders' +
'ON Customers.CustomerID = Orders.CustomerID' +
'ORDER BY Customers.CustomerName;'

or manually in each line like this (oh please NEVER do this!):

FDQuery1.SQL.Add('SELECT Customers.CustomerName, Orders.OrderID');
FDQuery1.SQL.Add('FROM Customers');
FDQuery1.SQL.Add('FULL OUTER JOIN Orders');
FDQuery1.SQL.Add('ON Customers.CustomerID = Orders.CustomerID');
FDQuery1.SQL.Add('ORDER BY Customers.CustomerName;');

Now this has normally not been much of a problem for me, because part of tiOPF's support tools, there is a tool name tiSQLEditor that does bi-directional conversions for you - to and from quoted strings for SQL. And even straight from/to the clipboard. This tool has been around for 17+ years. But why must this be a tool problem or a IDE problem? Why can't the Object Pascal language solve this for us!

[the following part quoted from a online discussion by somebody else - I fully agree with his thoughts though]

Imagine if FPC had type inference and multi-line strings, neither very exotic features. The code then becomes:

=========================================
var query := '''SELECT Customers.CustomerName, Orders.OrderID FROM Customers
FULL OUTER JOIN Orders
ON Customers.CustomerID = Orders.CustomerID
ORDER BY Customers.CustomerName;'''

FDQuery1.SQL.Add(query);
=========================================

Easier to read, easier to edit, no need for a IDE wizard or external tools.

Language features like this is what increases productivity. But unfortunately it seems we all rather rely on a specific tool or IDE to improve our productivity - thus also locking us into using those tools only.

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Marcos Douglas B. Santos
to Graeme Geldenhuys
Graeme Geldenhuys wrote 17 lines
Imagine if FPC had type inference and multi-line strings, neither very exotic features. The code then becomes: ========================================= var query := '''SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName;''' FDQuery1.SQL.Add(query); ========================================= Easier to read, easier to edit, no need for a IDE wizard or external tools. Language features like this is what increases productivity. But unfortunately it seems we all rather rely on a specific tool or IDE to improve our productivity - thus also locking us into using those tools only.

That would be very, very nice.
And instead of using [ " ' sql ' " ] would be better to use just [ " sql " ].

Best regards,
Marcos Douglas

Reply by email

Karoly Balogh (Charlie/SGR
to Graeme Geldenhuys: Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName,…

Hi,

Graeme Geldenhuys wrote 17 lines
Imagine if FPC had type inference and multi-line strings, neither very exotic features. The code then becomes: ========================================= var query := '''SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName;''' FDQuery1.SQL.Add(query); ========================================= Easier to read, easier to edit, no need for a IDE wizard or external tools. Language features like this is what increases productivity.

Stuff like this looks almost as bad to me, as PHP intermixed with HTML and Javascript. But sure, web devs are well known for their productivity... :P

(And I'm quite conservative on such things, so ignore me. :) )

Charlie

Reply by email

Graeme Geldenhuys
to Karoly Balogh (Charlie/SGR
Karoly Balogh wrote
But sure, web devs are well known for their productivity... :P

Just in case you thought I was a web developer - far from it!

Anyway, the idea was just that - an idea (and possibly an improvement) on an age old problem. I have no means or skills to implement something like that in FPC. But I thought it might be worth a discussion. I like to think outside the box every now and again - most of my projects show that.

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Andreas
to Graeme Geldenhuys: Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName,…

Graeme, I am a big fan of your messages. You have many good ideas and I sometimes read a theme that I am not interested in just to see your response.

In this case however I think you are wrong. Pascal has fantastic inherent type and error checking in its structure. It would be wrong to have an editor that can introduce unwanted errors. Just one way that I can see potential problems in you code style is the line end. Not every string is a SQL text which is very flexible in it's interpretation. Other string may want one or more spaces between the last symbol on the top line and the first on the second, today the editor normally strips these spaces away. If they are left in, they are spaces that visually I can not determine just by looking at the code. A mess.

For this reason I would be against this implementation. Maybe taking away the need for the + sign at the end of the line. The strings are concatenated until a semi-colon or other symbol is encountered

Graeme Geldenhuys wrote 63 lines
Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName; and you want to add that SQL to the SQL property of a query at runtime. You end up either having to turn this into a string like this: 'SELECT Customers.CustomerName, Orders.OrderID' + 'FROM Customers' + 'FULL OUTER JOIN Orders' + 'ON Customers.CustomerID = Orders.CustomerID' + 'ORDER BY Customers.CustomerName;' or manually in each line like this (oh please NEVER do this!): FDQuery1.SQL.Add('SELECT Customers.CustomerName, Orders.OrderID'); FDQuery1.SQL.Add('FROM Customers'); FDQuery1.SQL.Add('FULL OUTER JOIN Orders'); FDQuery1.SQL.Add('ON Customers.CustomerID = Orders.CustomerID'); FDQuery1.SQL.Add('ORDER BY Customers.CustomerName;'); Now this has normally not been much of a problem for me, because part of tiOPF's support tools, there is a tool name tiSQLEditor that does bi-directional conversions for you - to and from quoted strings for SQL. And even straight from/to the clipboard. This tool has been around for 17+ years. But why must this be a tool problem or a IDE problem? Why can't the Object Pascal language solve this for us! [the following part quoted from a online discussion by somebody else - I fully agree with his thoughts though] Imagine if FPC had type inference and multi-line strings, neither very exotic features. The code then becomes: ========================================= var query := '''SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName;''' FDQuery1.SQL.Add(query); ========================================= Easier to read, easier to edit, no need for a IDE wizard or external tools. Language features like this is what increases productivity. But unfortunately it seems we all rather rely on a specific tool or IDE to improve our productivity - thus also locking us into using those tools only. Regards, Graeme

Reply by email

Karoly Balogh (Charlie/SGR
to Graeme Geldenhuys: Just in case you thought I was a web developer - far from it! Anyway, the idea was just…

Hi,

Graeme Geldenhuys wrote 10 lines
On 2017-07-06 15:35, Karoly Balogh (Charlie/SGR) wrote: > But sure, web devs are well known for their productivity... :P Just in case you thought I was a web developer - far from it! Anyway, the idea was just that - an idea (and possibly an improvement) on an age old problem. I have no means or skills to implement something like that in FPC. But I thought it might be worth a discussion. I like to think outside the box every now and again - most of my projects show that.

Sure, we should be free to discuss such proposals, nothing wrong with that. I just stated my opinion, but that shouldn't stop discussion in any way. :)

Charlie

Reply by email

Marco van de Voort
to Graeme Geldenhuys: Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName,…

In our previous episode, Graeme Geldenhuys said:

Show quoted text 10 lines
Imagine if FPC had type inference and multi-line strings, neither very exotic features. The code then becomes: ========================================= var query := '''SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName;'''

''' already has meaning, you'll see that

var s : ansistring;
begin
  s:='''text''';
end.

already compiles now.

Reply by email

Bernd Oppolzer
to Andreas: Graeme, I am a big fan of your messages. You have many good ideas and I sometimes read a…
Andreas wrote
For this reason I would be against this implementation. Maybe taking away the need for the + sign at the end of the line. The strings are concatenated until a semi-colon or other symbol is encountered

This is what the (new) Stanford Pascal compiler does:

program TESTLSTR ( OUTPUT ) ;
var ZEILE : array [ 1 .. 200 ] of CHAR ;
     I : INTEGER ;
begin (* HAUPTPROGRAMM *)
   ZEILE := 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
            'bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb'
            'cccccccccccccccccccccccccccccccccccc'
            'dddddddddddddddddddddddddddddddddddd'
            'eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee' ;
   WRITELN ( ZEILE ) ;
   MEMSET ( ADDR ( ZEILE ) , 'b' , 200 ) ;
   WRITELN ( ZEILE ) ;
   for I := 1 to 200 do
     ZEILE [ I ] := '=' ;
   WRITELN ( ZEILE ) ;
end (* HAUPTPROGRAMM *) .

that is: long strings may be concatenated simply by closing the string constant on one line and reopening it on the next line.

http://bernd-oppolzer.de/job9.htm

HTH, kind regards

Bernd

Reply by email

Sven Barth
to Graeme Geldenhuys: Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName,…
Graeme Geldenhuys wrote 15 lines
Imagine if FPC had type inference and multi-line strings, neither very exotic features. The code then becomes: ========================================= var query := '''SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName;''' FDQuery1.SQL.Add(query); ========================================= Easier to read, easier to edit, no need for a IDE wizard or external tools.

Completely ignoring the type inference which I'm definitely not a fan of
- at least not in Pascal: In my opinion it would be better to improve and finalize the $IncludeStringFile patch from issue #25536 ( https://bugs.freepascal.org/view.php?id=25536 ).
It has the advantage that it doesn't change the language and that the include file can be viewed independently with an appropriate syntax highlighter (especially with more complex SQL statements - to stick with your example - that is something that I'd really welcome). Of course it has the disadvantage that one can't easily add variables, but for things like this one can always pass the included string to Format() and friends which in my opinion would be more cleaned up anyway.

Regards,
Sven

Reply by email

Mark Morgan Lloyd
to Sven Barth
Sven Barth wrote
On 06.07.2017 16:13, Graeme Geldenhuys wrote:> Imagine if FPC had type inference and multi-line strings, neither very> exotic features. The code then becomes:> > =========================================> var query := '''SELECT Customers.CustomerName, Orders.OrderID> FROM Customers> FULL OUTER JOIN Orders> ON Customers.CustomerID = Orders.CustomerID> ORDER BY Customers.CustomerName;'''> > FDQuery1.SQL.Add(query);> =========================================> > > Easier to read, easier to edit, no need for a IDE wizard or external tools. Completely ignoring the type inference which I'm definitely not a fan of- at least not in Pascal: In my opinion it would be better to improveand finalize the $IncludeStringFile patch from issue #25536 (https://bugs.freepascal.org/view.php?id=25536 ).It has the advantage that it doesn't change the language and that theinclude file can be viewed independently with an appropriate syntaxhighlighter (especially with more complex SQL statements - to stick withyour example - that is something that I'd really welcome).Of course it has the disadvantage that one can't easily add variables,but for things like this one can always pass the included string toFormat() and friends which in my opinion would be more cleaned up anyway.

Some sort of heredoc approach would seem reasonable and I think it might be worth noting the PostgreSQL way:

$$Dianne's horse$$
$SomeTag$Dianne's horse$SomeTag$

$function$
BEGIN
     RETURN ($1 ~ $q$[\t\r\n\v\\]$q$);
END;
$function$
Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Graeme Geldenhuys
to Dmitry Boyarintsev: On Thu, Jul 6, 2017 at 10:27 AM, Marcos Douglas B. Santos The thread of discussion:…
Dmitry Boyarintsev wrote

Thanks for the link. Seems this topic has already been discussed a year and a bit ago.

Anybody know if there was any movement on the $IncludeString idea?

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Michael Van Canneyt
to Sven Barth: Completely ignoring the type inference which I'm definitely not a fan of - at least not…
Sven Barth wrote 21 lines
On 06.07.2017 16:13, Graeme Geldenhuys wrote: > Imagine if FPC had type inference and multi-line strings, neither very > exotic features. The code then becomes: > > ========================================= > var query := '''SELECT Customers.CustomerName, Orders.OrderID > FROM Customers > FULL OUTER JOIN Orders > ON Customers.CustomerID = Orders.CustomerID > ORDER BY Customers.CustomerName;''' > > FDQuery1.SQL.Add(query); > ========================================= > > > Easier to read, easier to edit, no need for a IDE wizard or external tools. Completely ignoring the type inference which I'm definitely not a fan of - at least not in Pascal: In my opinion it would be better to improve and finalize the $IncludeStringFile patch from issue #25536 ( https://bugs.freepascal.org/view.php?id=25536 ).

Sven,

What stops us from applying the patch ?
It has been in Mantis for ages.

Michael.

Reply by email

Sven Barth
to Graeme Geldenhuys: Thanks for the link. Seems this topic has already been discussed a year and a bit ago.…

Am 06.07.2017 23:34 schrieb "Graeme Geldenhuys" <

Show quoted text 10 lines
: On 2017-07-06 20:07, Dmitry Boyarintsev wrote: > > The thread of discussion: > http://lists.freepascal.org/pipermail/fpc-devel/2016-February/036709.html Thanks for the link. Seems this topic has already been discussed a year

and a bit ago.

Anybody know if there was any movement on the $IncludeString idea?

See my message from yesterday night. :)

Regards,
Sven

Reply by email

Unknown author
to Graeme Geldenhuys: Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName,…
Graeme Geldenhuys wrote 63 lines
Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName; and you want to add that SQL to the SQL property of a query at runtime. You end up either having to turn this into a string like this: 'SELECT Customers.CustomerName, Orders.OrderID' + 'FROM Customers' + 'FULL OUTER JOIN Orders' + 'ON Customers.CustomerID = Orders.CustomerID' + 'ORDER BY Customers.CustomerName;' or manually in each line like this (oh please NEVER do this!): FDQuery1.SQL.Add('SELECT Customers.CustomerName, Orders.OrderID'); FDQuery1.SQL.Add('FROM Customers'); FDQuery1.SQL.Add('FULL OUTER JOIN Orders'); FDQuery1.SQL.Add('ON Customers.CustomerID = Orders.CustomerID'); FDQuery1.SQL.Add('ORDER BY Customers.CustomerName;'); Now this has normally not been much of a problem for me, because part of tiOPF's support tools, there is a tool name tiSQLEditor that does bi-directional conversions for you - to and from quoted strings for SQL. And even straight from/to the clipboard. This tool has been around for 17+ years. But why must this be a tool problem or a IDE problem? Why can't the Object Pascal language solve this for us! [the following part quoted from a online discussion by somebody else - I fully agree with his thoughts though] Imagine if FPC had type inference and multi-line strings, neither very exotic features. The code then becomes: ========================================= var query := '''SELECT Customers.CustomerName, Orders.OrderID FROM Customers FULL OUTER JOIN Orders ON Customers.CustomerID = Orders.CustomerID ORDER BY Customers.CustomerName;''' FDQuery1.SQL.Add(query); ========================================= Easier to read, easier to edit, no need for a IDE wizard or external tools. Language features like this is what increases productivity. But unfortunately it seems we all rather rely on a specific tool or IDE to improve our productivity - thus also locking us into using those tools only. Regards, Graeme

This multiline string issue also helps with HTML:

s := '<html>' +
'<head>' +
'</head>' +
'<body>' +

Instead it should be a multiline string:

s := '''
<html>
<head>
</head>
<body>
'''

There is also the backquote character, as an option.. `some string
on multiple
lines`

GoLang has multiline strings that work pretty good. AFAIR php has them too, especially for html work - but that is likely because PHP is for web programming and needed that feature more than Pascal did, so the strong need caused them to implement it more than other langauges.

Reply by email

Felipe Monteiro de Carvalho
to Graeme Geldenhuys: Ever had a problem like this? You have some SQL, say: SELECT Customers.CustomerName,…
Language features like this is what increases productivity.

Indeed {$INCLUDESTRINGFILE file} looks like a great solution for this.

Since we are talking about language features, after learning Java I think we could use in Pascal:

1> Default methods in interfaces (implementation multiple-inheritance, would be extremely useful in Lazarus)

2> Try with resources like in Java

Felipe Monteiro de Carvalho

Reply by email

Ched
to Unknown author: This multiline string issue also helps with HTML: s := '<html>' + '<head>' + '</head>' +…

Is this acceptable ?

Show quoted text 5 lines
'SELECT Customers.CustomerName, Orders.OrderID' + 'FROM Customers' + 'FULL OUTER JOIN Orders' + 'ON Customers.CustomerID = Orders.CustomerID' + 'ORDER BY Customers.CustomerName;'

I think that one have to insert space at some loactions: 'SELECT Customers.CustomerName, Orders.OrderID' +
' FROM Customers' +
' FULL OUTER JOIN Orders' +
' ON Customers.CustomerID = Orders.CustomerID' +
' ORDER BY Customers.CustomerName;';

Cheers, Ched

Reply by email

Graeme Geldenhuys
to Marco van de Voort: In our previous episode, Graeme Geldenhuys said: ''' already has meaning, you'll see that…
Marco van de Voort wrote
''' already has meaning, you'll see that

The 3 quotes were simply an idea. You correctly identified that it is already used is some special cases, so then simply replace it with some other unique syntax that is not used yet. As Z505 mentioned, even the back-tick symbol should be a good option, and not used by Object Pascal syntax yet. For simpler typing, seeing as not all keyboard layouts seem to have the back-tick readily available, maybe the quote-quote could be used - as far as I know Object Pascal doesn't use that yet. But if I had to choose between the two, I would opt for the back-tick as it is more clearly distinguishable.

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Graeme Geldenhuys
to Felipe Monteiro de Carvalho: Indeed {$INCLUDESTRINGFILE file} looks like a great solution for this. Since we are…
Felipe Monteiro de Carvalho wrote
Since we are talking about language features, after learning Java I think we could use in Pascal:

I must say, after using Java more and more in recent months, it starts to show why so many developers call Delphi/Object Pascal out of date. [I never thought I would ever say that - I have a real soft spot for Object Pascal]

The Java language has some awesome features and much less typing is required - yet not as cryptic as C/C++. The Java IDEs (primarily Eclipse and IntelliJ IDEA) also blow Lazarus and MSEide out of the water - but then they have a ton more resources at their disposal). Either way, those IDEs are a real pleasure to work with, and have so many programmer friendly features.

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 15 lines
On 2017-07-08 07:57, Felipe Monteiro de Carvalho wrote: > Since we are talking about language features, after learning Java I > think we could use in Pascal: I must say, after using Java more and more in recent months, it starts to show why so many developers call Delphi/Object Pascal out of date. [I never thought I would ever say that - I have a real soft spot for Object Pascal] The Java language has some awesome features and much less typing is required - yet not as cryptic as C/C++. The Java IDEs (primarily Eclipse and IntelliJ IDEA) also blow Lazarus and MSEide out of the water - but then they have a ton more resources at their disposal). Either way, those IDEs are a real pleasure to work with, and have so many programmer friendly features.

Would it be possible to give examples ?
Maybe there are things that can be done in Lazarus, and Pascal ?

I'm doing some work in a Java environment myself lately, and I must say I have not noticed anything of these 'language features'. Lots of useful libraries, yes. There I will not argue.

Michael.

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt

Hi,

I've give a short reply here, in case others deem this off-topic. I always seem to end up in hot water about such stuff here. I can send you more details in private if need be.

Michael Van Canneyt wrote
Would it be possible to give examples ? Maybe there are things that can be done in Lazarus, and Pascal ?

Some IDE examples I have already raised in recent weeks in the Lazarus forum. The Java IDE's are *way* more clever about what code you wrote and makes very intelligent suggestions when it discovers errors, or possible improvements (eg: because you are using a newer Java version that might have an improved solution). In Eclipse, Ctrl+1 will list the options, give you a tooltip hint of how the changed code will look (before any changes are made). Make your pick and press enter. Those could be fixing errors, improved language features, pull in missing import lines, implement getters and setters, define missing classes, field variables or local variables etc. The list of what is on offer is massive.

Purely on the language side of things.... I love the fact that there is no *.h or an "interface section" in my code - why must C/C++ and Object Pascal duplicate that information. If I want to see a purely "interface" view of my code, the IDE doesn't that as standard in the unit Outline window.

As I said, just a short list here, but I can list many more if you want
- both IDE features and language features.

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys
Graeme Geldenhuys wrote 8 lines
Hi, Purely on the language side of things.... I love the fact that there is no *.h or an "interface section" in my code - why must C/C++ and Object Pascal duplicate that information. If I want to see a purely "interface" view of my code, the IDE doesn't that as standard in the unit Outline window.

If that is all, on the language side, I am a happy man :)

I think Java is a rather primitive language,
so I had hoped for something massively impressive.

Let me give you a counter example why I think Java plainly sucks.

I get very depressed when I see things like this:

dstream.foreachRDD(new VoidFunction<JavaRDD<String>>() { @Override
public void call(JavaRDD<String> rdd) {
rdd.foreachPartition(new VoidFunction<Iterator<String>>() { @Override
public void call(Iterator<String> partitionOfRecords) {

         Connection connection = ConnectionPool.getConnection();
         while (partitionOfRecords.hasNext()) {
           connection.send(partitionOfRecords.next());
         }
         ConnectionPool.returnConnection(connection);
       }
     });
   }

});

Such code is completely unreadable to me.

Compare this to the same code in Python:

def sendPartition(iter):
connection = ConnectionPool.getConnection()
for record in iter:
connection.send(record)
ConnectionPool.returnConnection(connection)

dstream.foreachRDD(lambda rdd: rdd.foreachPartition(sendPartition))

The very paragon of readability.

Or Scala:

dstream.foreachRDD { rdd =>
rdd.foreachPartition { partitionOfRecords =>
val connection = ConnectionPool.getConnection()
partitionOfRecords.foreach(record => connection.send(record)) ConnectionPool.returnConnection(connection)
}
}

Infinitely more readable than Java in my opinion.
And that is what matters to me.

The Java version with all it's templates is just painful.

(And mainly the reason why I think common use of Generics or templates is just a plain wrong approach, but that is another story)

So in fact your mail is a relief, I thought there would be some killer arguments why Java is better than Object Pascal...

About the IDE: there I cannot argue, there are probably many more things that can be done in Lazarus.

Michael.

Reply by email

Santiago A.
to denisgolovan: Just my 50 cents. Even though I avoid using debugger at all cost, I am willing to donate…
denisgolovan wrote 6 lines
Just my 50 cents. Even though I avoid using debugger at all cost, I am willing to donate some money should someone start a crowd-funding effort to get "modern" debugging support in Lazarus. That would definitely improve Lazarus/FPC public image.

It is not a matter of public image, it's a matter of usability, a "must have", a stopper.

Saludos Santiago A.

Reply by email

Santiago A.
to Graeme Geldenhuys: I've give a short reply here, in case others deem this off-topic. I always seem to end up…
Graeme Geldenhuys wrote 34 lines
Hi, I've give a short reply here, in case others deem this off-topic. I always seem to end up in hot water about such stuff here. I can send you more details in private if need be. On 2017-07-09 22:16, Michael Van Canneyt wrote: > Would it be possible to give examples ? > Maybe there are things that can be done in Lazarus, and Pascal ? Some IDE examples I have already raised in recent weeks in the Lazarus forum. The Java IDE's are *way* more clever about what code you wrote and makes very intelligent suggestions when it discovers errors, or possible improvements (eg: because you are using a newer Java version that might have an improved solution). In Eclipse, Ctrl+1 will list the options, give you a tooltip hint of how the changed code will look (before any changes are made). Make your pick and press enter. Those could be fixing errors, improved language features, pull in missing import lines, implement getters and setters, define missing classes, field variables or local variables etc. The list of what is on offer is massive. Purely on the language side of things.... I love the fact that there is no *.h or an "interface section" in my code - why must C/C++ and Object Pascal duplicate that information. If I want to see a purely "interface" view of my code, the IDE doesn't that as standard in the unit Outline window. As I said, just a short list here, but I can list many more if you want - both IDE features and language features. Regards, Graeme

My main complain to Freepascal is debugger.

Being unable to debug any field of an object is unacceptable in a modern professional environment (hint, properties with getter, let alone with strings). It's ridiculous to use writeln() or creating dummy variables to debug as if I were in 1980. You can add to the IDE as many bells and whistles as you want, but without a serious debugger, no way.

Saludos Santiago A.

Reply by email

denisgolovan
to Santiago A.

Just my 50 cents.

Even though I avoid using debugger at all cost,
I am willing to donate some money should someone start a crowd-funding effort to get "modern" debugging support in Lazarus. That would definitely improve Lazarus/FPC public image.

Regards, Denis Golovan

Reply by email

Michael Van Canneyt
to denisgolovan
denisgolovan wrote
That's exactly what I mean - some (or major) part of public considers it a stopper for some reason :) Sorry for hijacking the thread.

I can add it to the list of sponsored projects on the foundation page.

Michael.

Reply by email

denisgolovan
to Michael Van Canneyt

Please do.

And to that hero who is willing to take the effort - please post a call for donation in a separate thread :)

10.07.2017, 13:06, "Michael Van Canneyt" :

Show quoted text 12 lines
On Mon, 10 Jul 2017, denisgolovan wrote: >  That's exactly what I mean - some (or major) part of public considers it a stopper for some reason :) > >  Sorry for hijacking the thread. I can add it to the list of sponsored projects on the foundation page. Michael. _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Regards, Denis Golovan

Reply by email

Graeme Geldenhuys
to Michael Van Canneyt: If that is all, on the language side, I am a happy man :) I think Java is a rather…
Michael Van Canneyt wrote
If that is all, on the language side, I am a happy man :)

I did mention that it was purposely a small list

Let me give you a counter example why I think Java plainly sucks. I get very depressed when I see things like this:

You do realise that you don't have to write code like that. ;-) It's like me showing you bad examples of Object Pascal code - there are even dedicated websites that does just that. :-) Just because the language allows for such code, doesn't mean you have to write code like that.

Saying that, I personally agree that your code example is hard to read at first, and I simply try avoid writing Java code like that.

Some more examples of why I like Java.

* This language feature I disagreed with for many years, until I recently understood how Java works. Defining local variables when and where you need them in the code. Read up on the scope of variables to understand it fully, but local variables scope is based on code blocks. So if you define a new variable inside { and } - it is only valid inside that block. The IDEs fully support this obviously and wouldn't even suggest such variables (code completion) outside such code blocks.

* Targeting older Java versions, even though you are using a newer version to compile the code.

* String support, and more specifically, Unicode string support is a breeze to understand and use.

* The backwards compatibility, to use 10-15 year old BOM class files without the original source code. They simply just work - as if you just compiled them. On the flip side, both Eclipse and IDEA can decompile class files back to .java files too - and they do an impressive job at that (that's obviously more useful if the original class file code wasn't run through a obfuscater).

* Try/Catch blocks where you can catch multiple exception types - without needing nested code blocks like Object Pascal. You can even add a finally block in there too - again without nested blocks.

* I seem to have grasped Generics in Java much easier than in FPC or Delphi. I don't fully know why that is. Maybe the syntax, more examples etc? Not sure.

This list just scratches the surface obviously. And then, like you mentioned, the absolute massive and very impressive supporting libraries and frameworks.

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Felipe Monteiro de Carvalho
to Graeme Geldenhuys
Graeme Geldenhuys wrote
* I seem to have grasped Generics in Java much easier than in FPC or Delphi. I don't fully know why that is. Maybe the syntax, more examples etc? Not sure.

Well, Java Generics are very limited in comparison with C++ / Object Pascal generics (Java generics accepts only Objects never primitives), so that's make them much simpler to use/understand of course.

Maybe Java is right and that's all we'll ever need and the performance improvement of templates do not justify the added complexity and the difficulty in debugging. But it is a big limitation, so your comparison is not exactly fair here.

If Object Pascal had generics which accept only TObject I'm pretty sure it would be just as easy to use and understand and debug as in Java!

OTOH: The improved exception handling is indeed something we miss, in particular try-with-resources.

Java has a very significant problem in my opinion: At least where I live, Java is never utilized for any interresting projects. Only for JavaEE with Spring+Hibernate and a little for Android (although Android people don't care that much for Java, they want specific knowledge of Android APIs and libraries, and dislike the Java generic APIs). Its even surprising like: wow, such a nice framework and noone ever does anything interresting with it o.O

It looks like that C++ and C# are utilized in much more varied and interresting projects than Java.

Felipe Monteiro de Carvalho

Reply by email

Michael Van Canneyt
to Graeme Geldenhuys: I did mention that it was purposely a small list You do realise that you don't have to…
Graeme Geldenhuys wrote 18 lines
On 2017-07-10 07:30, Michael Van Canneyt wrote: > > If that is all, on the language side, I am a happy man :) I did mention that it was purposely a small list > Let me give you a counter example why I think Java plainly sucks. > > I get very depressed when I see things like this: You do realise that you don't have to write code like that. ;-) It's like me showing you bad examples of Object Pascal code - there are even dedicated websites that does just that. :-) Just because the language allows for such code, doesn't mean you have to write code like that. Saying that, I personally agree that your code example is hard to read at first, and I simply try avoid writing Java code like that.

You can't. The APIs this is used in can only work like this. They require templates, and they have no other way to work.

https://spark.apache.org/docs/latest/streaming-programming-guide.html

Some more examples of why I like Java.

Well, from your list the only thing I can see we could add is the catch block with multiple exception types.

The rest: I still don't see how this makes java "more modern". Scala is more modern, that is for sure. I would not argue there.

But to each his own opinion, obviously.

Michael.

Reply by email

Michael Van Canneyt
to Felipe Monteiro de Carvalho: On Mon, Jul 10, 2017 at 12:14 PM, Graeme Geldenhuys Well, Java Generics are very limited…
Felipe Monteiro de Carvalho wrote 12 lines
On Mon, Jul 10, 2017 at 12:14 PM, Graeme Geldenhuys wrote: > * I seem to have grasped Generics in Java much easier than in FPC or > Delphi. I don't fully know why that is. Maybe the syntax, more examples etc? > Not sure. Well, Java Generics are very limited in comparison with C++ / Object Pascal generics (Java generics accepts only Objects never primitives), so that's make them much simpler to use/understand of course. Maybe Java is right and that's all we'll ever need and the performance improvement of templates

There is no performance improvement, rather the contrary. The generic list works slower than the native list.

Michael.

Reply by email

Felipe Monteiro de Carvalho
to Michael Van Canneyt
Michael Van Canneyt wrote
There is no performance improvement, rather the contrary. The generic list works slower than the native list.

I meant that C++ templates (and maybe Pascal generics which are very similar if I am not wrong) are faster than Java generics. Maybe it has to do with that primitive types in Java cannot be added to generics at all, but need to be wrapped in an object.

I also don't see why a template list would be slower than a fixed-type one. It should be the same. Its just a copy of the same code.

Anyway C++ guys claim that templates are faster than Java generics, I'm just repeating what I heard.

If they aren't faster, then Java has better generics, because they are easier to use and debug.

Felipe Monteiro de Carvalho

Reply by email

Michael Van Canneyt
to Felipe Monteiro de Carvalho
Felipe Monteiro de Carvalho wrote 12 lines
On Mon, Jul 10, 2017 at 12:52 PM, Michael Van Canneyt wrote: > There is no performance improvement, rather the contrary. The generic list > works slower than the native list. I meant that C++ templates (and maybe Pascal generics which are very similar if I am not wrong) are faster than Java generics. Maybe it has to do with that primitive types in Java cannot be added to generics at all, but need to be wrapped in an object. I also don't see why a template list would be slower than a fixed-type one. It should be the same. Its just a copy of the same code.

The code is definitely not the same.
In each case, it was measured. There is a 10% performance loss.

Michael.

Reply by email

Felipe Monteiro de Carvalho
to Michael Van Canneyt
Michael Van Canneyt wrote
The code is definitely not the same. In each case, it was measured. There is a 10% performance loss.

I'd love a source on this one. I guess you mean in Free Pascal? Because I searching the web C++ developers seam all sure that templates are the 7th wonder and so fast.

And in Java I am 110% certain that generics add zero performance penalty. Generics don't even exist in Java after compilation, they don't produce any different code than if you had hard-coded Object. It's just a compile type type-checking. Under the hood there is only 1 code operating on Object instances. It is backwards compatible to pre-generic Java and it can't possibly impact performance.

Felipe Monteiro de Carvalho

Reply by email

Michael Van Canneyt
to Felipe Monteiro de Carvalho
Felipe Monteiro de Carvalho wrote 6 lines
On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt wrote: > The code is definitely not the same. In each case, it was measured. There is > a 10% performance loss. I'd love a source on this one. I guess you mean in Free Pascal?

Obviously.

The classes unit can be recompiled to use the fgl (well, that used to be so) as a basis. When using the resulting list and stringlist, there was a 10% performance loss. The main reason - If I recall correctly - was that the fgl needs to resort to move() operations instead of direct assignments.

Michael.

Reply by email

Dmitry Boyarintsev
to Graeme Geldenhuys: I did mention that it was purposely a small list You do realise that you don't have to…

On Mon, Jul 10, 2017 at 6:14 AM, Graeme Geldenhuys <

Show quoted text 7 lines
wrote: * Try/Catch blocks where you can catch multiple exception types - without needing nested code blocks like Object Pascal. You can even add a finally block in there too - again without nested blocks.

are you referring to "Catching More Than One Type of Exception with One Exception Handler" in
https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html ?

Reply by email

Sven Barth
to Michael Van Canneyt: Obviously. The classes unit can be recompiled to use the fgl (well, that used to be so)…
"Michael Van Canneyt" wrote 9 lines
On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote: > On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt > wrote: >> >> The code is definitely not the same. In each case, it was measured.

There is

Show quoted text 9 lines
>> a 10% performance loss. > > > I'd love a source on this one. I guess you mean in Free Pascal? Obviously. The classes unit can be recompiled to use the fgl (well, that used to be

so)

as a basis. When using the resulting list and stringlist, there was a 10% performance loss. The main reason - If I recall correctly - was that the

fgl needs to resort to move() operations instead of direct assignments.

The fgl classes don't use Move(), but they have a virtual method that does the assignment between the specialized parameters that's inherited from the non-generic parent list type.

You might want to test with the list provided by the rtl-generics package.

Regards,
Sven

Reply by email

Michael Van Canneyt
to Sven Barth
Sven Barth wrote 28 lines
Am 10.07.2017 13:19 schrieb "Michael Van Canneyt" : > > > > On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote: > >> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt >> wrote: >>> >>> The code is definitely not the same. In each case, it was measured. There is >>> a 10% performance loss. >> >> >> I'd love a source on this one. I guess you mean in Free Pascal? > > > Obviously. > > The classes unit can be recompiled to use the fgl (well, that used to be so) > as a basis. When using the resulting list and stringlist, there was a 10% > performance loss. The main reason - If I recall correctly - was that the fgl needs to resort to move() operations instead of direct assignments. The fgl classes don't use Move(), but they have a virtual method that does the assignment between the specialized parameters that's inherited from the non-generic parent list type.

home:~/fpc/rtl/objpas> grep -i move fgl.pp

   System.Move(Src^, Dest^, FItemSize);
   System.Move(InternalItems[Index+1]^, ListItem^, (FCount - Index) * FItemSize);
     System.Move(ListItemPtr^, ResultPtr^, FItemSize);
   System.Move(InternalItems[Index1]^, InternalItems[FCapacity]^, FItemSize);
   System.Move(InternalItems[Index2]^, InternalItems[Index1]^, FItemSize);
   System.Move(InternalItems[FCapacity]^, InternalItems[Index2]^, FItemSize);
     System.Move(Result^, (Result+FItemSize)^, (FCount - Index) * FItemSize);
   System.Move(CurItem^, TmpItem^, FItemSize);
   System.Move(Src^, Dest^, MoveCount * FItemSize);
   System.Move(TmpItem^, NewItem^, FItemSize);
   System.Move(psrc^, pdest^, LItemSize);
   System.Move(Src^, Dest^, FKeySize);
   System.Move(Src^, Dest^, FDataSize);

Reply by email

Graeme Geldenhuys
to Dmitry Boyarintsev: On Mon, Jul 10, 2017 at 6:14 AM, Graeme Geldenhuys < are you referring to "Catching More…
Dmitry Boyarintsev wrote
are you referring to "Catching More Than One Type of Exception with One Exception Handler" in https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html

Yes. You can have multiple catch blocks inside the same try block. You can also have a single catch block with a comma separated list of exception types.

Then lastly, you can even add a finally block in there too (Java calls this try-with-resources).

So putting those together, it looks like this:

https://docs.oracle.com/javase/tutorial/essential/exceptions/putItTogether.html

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Graeme Geldenhuys
to Graeme Geldenhuys
Graeme Geldenhuys wrote
You can also have a single catch block with a comma separated list of exception types.

Oops, typo.... Not a comma separated list, but a list separated by the | (pipe or vertical bar) symbol.

See the last example here:

https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html

Regards,
Graeme

fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp

Reply by email

Felipe Monteiro de Carvalho
to Graeme Geldenhuys: Yes. You can have multiple catch blocks inside the same try block. You can also have a…
Graeme Geldenhuys wrote
Then lastly, you can even add a finally block in there too (Java calls this try-with-resources).

No, that's not what try-with-resources is.

This is try-with-resources:
https://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html

Any object which implements the interface AutoClosable is auto-closed in the try, regardless of an exception happening or not.

Pascal is a little different, since it has destructors, so I guess in Pascal we could auto-free objects in a hypotetical try-with-resources in Pascal. Something like:

try ( stringList := TStringList.Create;
 otherObj := TSomeOtherClass.Create; )
  code here
except
  exception block, optional
end;

And any object in the () section would be auto-freed, auto-checking if it was already created or not.

Felipe Monteiro de Carvalho

Reply by email

Dmitry Boyarintsev
to Graeme Geldenhuys: Yes. You can have multiple catch blocks inside the same try block. You can also have a…

On Mon, Jul 10, 2017 at 9:46 AM, Graeme Geldenhuys <

Show quoted text 10 lines
wrote: On 2017-07-10 13:34, Dmitry Boyarintsev wrote: > are you referring to "Catching More Than One Type of Exception with One > Exception Handler" in > https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html > Yes. You can have multiple catch blocks inside the same try block.

Well, this has been in FPC/Delphi from the start
Ultimately handling multiple exceptions in one catch block is the whole purpose of having exception mechanism in a language.

You can also have a single catch block with a comma separated list of

exception types.

I think it's actually Pipe separated.
And is that true, that the variable specified for catching such exception would default to a common "Exception" class?
Not available in freepascal indeed.

Then lastly, you can even add a finally block in there too

Also not available, but people are asking :

https://bugs.freepascal.org/view.php?id=24216

Reply by email

Sven Barth
to Graeme Geldenhuys: Yes. You can have multiple catch blocks inside the same try block. You can also have a…

Am 10.07.2017 15:46 schrieb "Graeme Geldenhuys" <

Show quoted text 10 lines
: On 2017-07-10 13:34, Dmitry Boyarintsev wrote: > > are you referring to "Catching More Than One Type of Exception with One > Exception Handler" in > https://docs.oracle.com/javase/tutorial/essential/exceptions/catch.html Yes. You can have multiple catch blocks inside the same try block. You

can also have a single catch block with a comma separated list of exception types.

You can catch multiple exception types in Object Pascal as well:

=== code begin ===

try
expect
  on e: EWhatever do ...;
  on e: EFoobar do ...;
  else ...
end;

=== code end ===

Though you can't use the same code block for multiple types.

Regards,
Sven

Reply by email

Dmitry Boyarintsev
to Sven Barth

On Mon, Jul 10, 2017 at 11:19 AM, Sven Barth via fpc-pascal <

wrote: Though you can't use the same code block for multiple types.

Structured development to the rescue :)

===
program project1;
{$mode delphi}
{$RANGECHECKS on}
uses SysUtils;
function HandlingIt(const e: exception): Integer;
begin
  writeln('something bad has happened:');
  writeln(e.message);
  Result:=0;
end;
function Catch(a,b: byte; oper: char): byte;
begin
  try
    if oper = '+' then Result:=a+b
    else if oper = '/' then Result:=a div b;
  except
    on e: EDivByZero do begin
      writeln('division by zero');
      Result:=0;
    end;
    on e: EIntOverflow do Result:=HandlingIt(e);
    on e: ERangeError do Result:=HandlingIt(e);
  end;
end;
begin
  writeln( catch (1,1,'+'));
  writeln( catch (255,255,'+'));
  writeln( catch (1,0,'/'));
end.

Reply by email

Unknown author
to Ched: Is this acceptable ? I think that one have to insert space at some loactions: 'SELECT…
Ched wrote 17 lines
Is this acceptable ? > 'SELECT Customers.CustomerName, Orders.OrderID' + > 'FROM Customers' + > 'FULL OUTER JOIN Orders' + > 'ON Customers.CustomerID = Orders.CustomerID' + > 'ORDER BY Customers.CustomerName;' I think that one have to insert space at some loactions: 'SELECT Customers.CustomerName, Orders.OrderID' + ' FROM Customers' + ' FULL OUTER JOIN Orders' + ' ON Customers.CustomerID = Orders.CustomerID' + ' ORDER BY Customers.CustomerName;'; Cheers, Ched

And if it is a multiline string, the compiler may have to convert carriage return/new line into a space for you, to allow it to take:

FROM Customers
FULL OUTER JOIN Orders

and convert the carriage return after "Customers" into a space for you..

otherwise it will be:

FROM CustomersFULL OUTER JOIN Orders

..concatenated without a space

Something to be concerned about if implementing it.

Reply by email

Florian Klaempfl
to Sven Barth: There is so) fgl needs to resort to move() operations instead of direct assignments. The…
Sven Barth wrote 29 lines
Am 10.07.2017 13:19 schrieb "Michael Van Canneyt" < >: > > > > On Mon, 10 Jul 2017, Felipe Monteiro de Carvalho wrote: > >> On Mon, Jul 10, 2017 at 1:08 PM, Michael Van Canneyt >> < > wrote: >>> >>> The code is definitely not the same. In each case, it was measured. There is >>> a 10% performance loss. >> >> >> I'd love a source on this one. I guess you mean in Free Pascal? > > > Obviously. > > The classes unit can be recompiled to use the fgl (well, that used to be so) > as a basis. When using the resulting list and stringlist, there was a 10% > performance loss. The main reason - If I recall correctly - was that the fgl needs to resort to move() operations instead of direct assignments. The fgl classes don't use Move(), but they have a virtual method that does the assignment between the specialized parameters that's inherited from the non-generic parent list type.

... which is done to avoid bloat. fgl specialized only a wrapper around an internal list. So the slightly slower code in some cases reduced executable size.

Reply by email