Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: A case for Delphi



Permlink Replies: 89 - Last Post: Jun 22, 2016 11:19 PM Last Post By: Rudy Velthuis (...
Kim Madsen

Posts: 362
Registered: 12/13/99
A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 1:28 AM
I can say this much... Ive been having the fun of working with Java for
the last several months... Large scale data handling.

What I have (re)discovered (I already knew it from my older Java days),
is that properly coded Delphi simply beats Java server side applications
coded according to all the defacto standards and best practices in 3
categories:

- Memory performance
- Runtime performance
- Ease of testing

Delphi obviously looses out in crossplatform compatiblity compared to Java.

How do I know that?

Because when there were problems with the above with specifically one of
the Java services, I coded a similar one in about 8 hours in Delphi, to
test the claims about "thats how it just is" or "its the customers
network that is at fault".

The Delphi app never used more than 50MB of RAM even though it kept
track of alot of data all the time. The Java app uses up every bit of
RAM allocated to it and then wants more. There are no apparent leaks in
the code, although deep down in some open source library Im sure there
is a leak or some crappy code.

The Delphi app ran 10+ times faster doing the exact same network related
work, and its performance kept stable, while the Java app degraded (most
likely also due to the stupid memory use resulting in paging etc).

Reasons to use Java is:

- There are plenty of developers with Java on their CV. I however think
that the skills of the Java developers are more centered around knowing
open source APIs than knowing how to write nimble, optimized and
readable code.

- Java is very much cross platform. It is, however there are differences
in JVMs in how they react in various scenarios, how they GC etc. But
platforms are not the same. And thus using a Java app on one platform
may work well, while using it on another may work less well if its
written with single code base and no optimization for the target platform.

best regards
Kim/C4D
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 1:52 AM   in response to: Kim Madsen in response to: Kim Madsen
On Tue, 31 May 2016 01:28:43 -0700, Kim Madsen <kbm at components4developers dot com> wrote:

the code, although deep down in some open source library Im sure there
is a leak or some crappy code.

any names of suspected libs?

--
Vladimir Ulchenko aka vavan
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 3:41 AM   in response to: Vladimir Ulchenko in response to: Vladimir Ulchenko
Den 5/31/2016 kl. 10:52 skrev Vladimir Ulchenko:
On Tue, 31 May 2016 01:28:43 -0700, Kim Madsen <kbm at components4developers dot com> wrote:

the code, although deep down in some open source library Im sure there
is a leak or some crappy code.

any names of suspected libs?

Hi,

Yes, but due to the nature of sensitivity I prefer not to mention any :)

best regards
Kim/C4D
Janez Atmapuri ...

Posts: 240
Registered: 2/8/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 2:09 AM   in response to: Kim Madsen in response to: Kim Madsen
Hello Kim,

If you let java free reign, it will gobble up ever single bit of memory. The
so called "recommended" settings are very much excessive. You only need to
pin it down so that the GC is called every few seconds. Of course, if your
app is really heavily allocating memory, then GC will be running all the
time. The trick is to allocate vars on stack and avoid frequent memory
allocations in tight loops.

(Then you actually have to think more about memory than with a non GC
language <g>)

Kind Regards!
Atmapuri
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 3:45 AM   in response to: Janez Atmapuri ... in response to: Janez Atmapuri ...
Hi,

Yup. It will use everything it is assigned, and delay GC for quite a
while until it starts to feel its running out of Java heap.

However it finally does run out of Java heap due to some (at this time)
unidentified allocations or leaks in some (popular) open source libs
thats not easily replacable (thats my current theory).

Thats both a blessing and a course about open source. Its open...
everyone can look and change. But it also means it often becomes brittle
as people only checkin what works for them in their narrow application
testing.

Few open source projects actually gets really stable and well tested
releases, most are just popular and are "tested" at customers site.

best regards
Kim/C4D

Den 5/31/2016 kl. 11:09 skrev Janez Atmapuri Makovsek:
Hello Kim,

If you let java free reign, it will gobble up ever single bit of memory. The
so called "recommended" settings are very much excessive. You only need to
pin it down so that the GC is called every few seconds. Of course, if your
app is really heavily allocating memory, then GC will be running all the
time. The trick is to allocate vars on stack and avoid frequent memory
allocations in tight loops.

(Then you actually have to think more about memory than with a non GC
language <g>)

Kind Regards!
Atmapuri
loki loki

Posts: 787
Registered: 7/1/02
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 4:43 AM   in response to: Kim Madsen in response to: Kim Madsen

- Memory performance
- Runtime performance
- Ease of testing

Delphi obviously looses out in crossplatform compatiblity compared to Java.

yes and the introduction of the arc will really not help, you imagine
that emb even planned to make the linux compiler (ie for server
application) under arc :( crazy ...
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 5:22 AM   in response to: loki loki in response to: loki loki
Den 5/31/2016 kl. 13:43 skrev loki loki:

- Memory performance
- Runtime performance
- Ease of testing

Delphi obviously looses out in crossplatform compatiblity compared to Java.

yes and the introduction of the arc will really not help, you imagine
that emb even planned to make the linux compiler (ie for server
application) under arc :( crazy ...

Hi,

I prefer to have the "standard" memory management model as we have on
Win32/Win64 for server side code.
However ARC is way different from Java GC, and imo much more predictable.
It still opens up loads of circular reference issues though, if coders
are not very careful.

best regards
Kim/C4D
loki loki

Posts: 787
Registered: 7/1/02
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 7:28 AM   in response to: Kim Madsen in response to: Kim Madsen

Hi,

I prefer to have the "standard" memory management model as we have on
Win32/Win64 for server side code.
However ARC is way different from Java GC, and imo much more predictable.
It still opens up loads of circular reference issues though, if coders
are not very careful.

best regards
Kim/C4D

ARC it's a nightmare :( and it's slow down all the object because every
access need thread lock for an atomic increase/decrease of the refcount
for single thread i think not really matter but for heavy multi thread :(
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 8:01 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

ARC it's a nightmare :( and it's slow down all the object because every
access need thread lock for an atomic increase/decrease of the refcount
for single thread i think not really matter but for heavy multi thread :(

Now please name me one real-life scenario where speed reduction due to atomic refcounting was an issue. Please remember that refcounting only happens when a reference counted object is copied or goes out of scope, that's all. You can even avoid it most of the time by passing them as "const" parameters to methods. Big deal. I think that in real-world applications the impact is below the noise threshold.

loki loki

Posts: 787
Registered: 7/1/02
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 12:19 PM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
On 5/31/2016 6:01 PM, Arthur Hoornweg wrote:
loki loki wrote:

ARC it's a nightmare :( and it's slow down all the object because every
access need thread lock for an atomic increase/decrease of the refcount
for single thread i think not really matter but for heavy multi thread :(

Now please name me one real-life scenario where speed reduction due to atomic refcounting was an issue. Please remember that refcounting only happens when a reference counted object is copied or goes out of scope, that's all. You can even avoid it most of the time by passing them as "const" parameters to methods. Big deal. I think that in real-world applications the impact is below the noise threshold.


for example string! String types and dynamic arrays just use the same
LOCKed asm instruction everywhere, i.e. for every access which may lead
into a write to the string. the asm LOCK prefix is used to ensure
exclusive access to the memory address. In a multi-core CPU, all cores
just freeze during LOCK execution.

So, if you are writing to a string, there are a few LOCK instructions
being generated by the compiler, every single time. Even if your
computer is a super-duper multi-core machine, it will behave - during
these instructions - if they were a single-core CPU.

and real life scenario? i have this problem in a ISAPI webserver !

but with string, we can use pchar instead, but with ARC object, their is
no alternative :(

and const can not help all the time, just in function parameter ... but
if you manipulating your data via for exemple Tree of object (json, xml,
etc) it's no help

last remark: maybe right now you don't notice the difference but it's
because the FASTMM memory manager it's very bad in
multicore/multithread, try to use instead tbbmalloc and you will see the
difference !
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 7:57 PM   in response to: loki loki in response to: loki loki
last remark: maybe right now you don't notice the difference but it's
because the FASTMM memory manager it's very bad in
multicore/multithread, try to use instead tbbmalloc and you will see the
difference !

Maybe you haven't seen latest FastMM yet. https://plus.google.com/u/0/+PrimožGabrijelčič/posts/3dGCX9pnh6M
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 12:52 PM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre,

| Maybe you haven't seen latest FastMM yet.
| https://plus.google.com/u/0/+PrimožGabrijelčič/posts/3dGCX9pnh6M

I get a "cannot be found" error trying to access that URL. (???)

--

Q -- XanaNews 1.19.1.372 - 2016-06-02 12:51:41
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 2:20 PM   in response to: Quentin Correll in response to: Quentin Correll
Quentin Correll wrote:
Alexandre,

| Maybe you haven't seen latest FastMM yet.
| https://plus.google.com/u/0/+PrimožGabrijelčič/posts/3dGCX9pnh6M

I get a "cannot be found" error trying to access that URL. (???)

--

Q -- XanaNews 1.19.1.372 - 2016-06-02 12:51:41

Hi Q!

I think this is restricted to G+??

Anyway, the latest official Pierre le Riche's repository contains the updated code: https://github.com/pleriche/FastMM4/

More information about the new features can be found here: http://www.thedelphigeek.com/2016/02/finding-memory-allocation-bottlenecks.html

Hope it helps!
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 3, 2016 12:12 PM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre,

Thanks!

| Anyway, the latest official Pierre le Riche's repository contains the
| updated code: https://github.com/pleriche/FastMM4/

I'm currently getting a "GitHub is not responding" error for that link.

I'll try again later.

--

Q -- XanaNews 1.19.1.372 - 2016-06-03 12:08:03

Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 4, 2016 10:50 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre,

| Anyway, the latest official Pierre le Riche's repository contains the
| updated code: https://github.com/pleriche/FastMM4/

| More information about the new features can be found here:
|

http://www.thedelphigeek.com/2016/02/finding-memory-allocation-bottlenecks.html

| Hope it helps!

I tried again this morning. However, I am still getting a "GitHub is
not responding" error trying to use the FastMM4 link. (?)

--

Q -- XanaNews 1.19.1.372 - 2016-06-04 10:47:25
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 5, 2016 1:37 AM   in response to: Quentin Correll in response to: Quentin Correll
I tried yesterday, and just now: no problem to follow the github fastmm4 link...
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 6, 2016 1:37 PM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud,

| I tried yesterday, and just now: no problem to follow the github
| fastmm4 link...

I still have the same problem today.

I don't have time right now to investigate. When I do I'll report
back.

Thanks people for the hand-holding!

--

Q -- XanaNews 1.19.1.372 - 2016-06-06 13:35:15
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 7, 2016 10:40 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
Arnaud,

I messed-with-it for a while again this morning. No joy.

--

Q -- XanaNews 1.19.1.372 - 2016-06-07 10:39:50
Attila Molnár

Posts: 7
Registered: 12/2/09
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 7, 2016 10:41 PM   in response to: Quentin Correll in response to: Quentin Correll
Hi!

Try ScaleMM2. We are using it for 2 year now. It really fast, stable, scales and avoids memory fragmentation well.

https://github.com/andremussche/scalemm


Quentin Correll wrote:
Arnaud,

I messed-with-it for a while again this morning. No joy.

--

Q -- XanaNews 1.19.1.372 - 2016-06-07 10:39:50
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 8, 2016 11:26 AM   in response to: Attila Molnár in response to: Attila Molnár
Attila,

Thanks for that info!

--

Q -- XanaNews 1.19.1.372 - 2016-06-08 11:26:23
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 1:16 AM   in response to: loki loki in response to: loki loki
Hi,

In a multi-core CPU, all cores
just freeze during LOCK execution.

In old multicore i486 days, it was so. Today it isnt so.

"In the days of Intel 486 processors, the lock prefix used to assert a
lock on the bus along with a large hit in performance. Starting with the
Intel Pentium Pro architecture, the bus lock is transformed into a cache
lock. A lock will still be asserted on the bus in the most modern
architectures if the lock resides in uncacheable memory or if the lock
extends beyond a cache line boundary splitting cache lines. Both of
these scenarios are unlikely, so most lock prefixes will be transformed
into a cache lock which is much less expensive."

https://www.quora.com/How-is-the-LOCK-instruction-implemented-in-the-Intel-processors

But for highest performance its obviously still important to avoid lock
contention on the same data. That will effectively reduce performance to
single core.
So if you have a multithreade ISAPI app, dont use the same string as the
outset for all results build for all threads.
Use at least a string per thread, and even better, due to all the
copying of data in strings, use a TStringBuffer per thread.

best regards
Kim/C4D
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 3:31 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

for example string! String types and dynamic arrays just use the same
LOCKed asm instruction everywhere, i.e. for every access which may lead
into a write to the string. the asm LOCK prefix is used to ensure
exclusive access to the memory address. In a multi-core CPU, all cores
just freeze during LOCK execution.

I have never even noticed any overhead through reference counting. The LOCK prefix only ensures that the CPU has exclusive ownership of that particular cache line for the duration of the operation. It's not so that all CPU's grind to a halt. Delphi's memory manager serializes memory allocations to guarantee that the heap (one heap for the whole process) remains consistent.

On average reference counted strings are still much faster than non-managed strings because A:=B doesn't actually copy anything. Compare that with shortstrings or Widestrings. Use tStringbuilder if you want to do a lot of string writing.

last remark: maybe right now you don't notice the difference but it's
because the FASTMM memory manager it's very bad in
multicore/multithread, try to use instead tbbmalloc and you will see the
difference !

Please name a real-world scenario where this bottle neck affects you.

One of my applications (a NT service) currently replicates data from 21 oil wells simultaneously using 520 threads. It uses the Remobjects remoting framework (web services). The resolution of the data is 1 Hz. . It makes extensive use of reference-counted interfaces. The whole thing consumes a smooth 1% CPU load on a dual-cpu virtual machine (vmware esxi 5.5) and I'm perfectly OK with that.
Ronald Klitsche

Posts: 326
Registered: 8/26/01
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 3:43 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Please name a real-world scenario where this bottle neck affects you.

This simple string example didn't scale with the number of Threads:

uses
System.Threading, System.Diagnostics;

procedure TForm3.Button1Click(Sender: TObject);
var
Tasks : array of ITask;
i: Integer;
sw : TStopwatch;
begin
SetLength(Tasks, 4);

sw := TStopwatch.StartNew;
for i := Low(Tasks) to High(Tasks) do
Tasks[i] := TTask.Run(procedure ()
var
x : Integer;
LString : string;
begin
LString := StringOfChar('X', 10000000);
for x := 0 to 1000 do
Delete(LString, x, 1);
end);

TTask.WaitForAll(Tasks, INFINITE);
sw.Stop;

Caption := Format('%d ms', [sw.ElapsedMilliseconds]);
end;
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 1:09 AM   in response to: Ronald Klitsche in response to: Ronald Klitsche
LString := StringOfChar('X', 10000000);
for x := 0 to 1000 do
   Delete(LString, x, 1);

Ronald, let's take a step-by-step look at this.

-Every single "delete" operation in your benchmark moves 20 megabytes (10 million widechars) of data in memory.
-That's certainly not going to fit into any CPU cache line.
-According to Wikipedia, DDR3 Ram does something like 6.4 gigs/sec.
-So one single "delete" will keep the memory channel busy for roughly 3 milliseconds.
-That's 9 million cpu cycles on a fast 3 GHz processor.

I find very little information about the duration of a "lock" prefix. The highest estimate I found on the internet was something like 100 cpu cycles.

Using this value, the overhead due to bus locking/reference counting in your benchmark should be in the order of magnitude of 100/9000000 which is roughly 0.001%. I can only conclude that your example doesn't scale with multi-processing because your bottleneck is the RAM, not the reference counting.

You could double-check this by comparing a move() with your delete().

Regards,
Arthur

<edit> The iterator starting at 0, was that a typo or did you really use zero-based strings?

Edited by: Arthur Hoornweg on Jun 2, 2016 1:17 AM

Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 4:14 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
On Wed, 1 Jun 2016 03:31:21 -0700, Arthur Hoornweg <> wrote:

The resolution of the data is 1 Hz. . It makes extensive use of reference-counted interfaces. The whole thing consumes a smooth 1% CPU load on a dual-cpu virtual machine (vmware esxi 5.5) and I'm perfectly OK with that.

isn't 1 Hz (meaning one sample per second) a typo?

--
Vladimir Ulchenko aka vavan
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 6:23 AM   in response to: Vladimir Ulchenko in response to: Vladimir Ulchenko
Vladimir Ulchenko wrote:

isn't 1 Hz (meaning one sample per second) a typo?

No it isn't, we record up to 200 parameters per oil well at a 10 Hz rate, perform some running min/max/avg calculations on them and store the result in 1 Hz sample interval (yes that's 3600 records per hour). The result is mirrored over the internet, sometimes to multiple destinations. And apart from time-based data, we also mirror depth-based data, reports and messages.

Of course the latency of the internet is unpredictable and sometimes a bit high but that is no problem: this particular synchronization process performs a RPC that returns all records added since the previous query (within reasonable limits). Most of the time the result will consist of one single record, sometimes it will contain two or three. The result is Zlib compressed by the server and larger results benefit from better compression. So we maintain an average data rate of 1 Hz even though we can't guarantee 1 s latency.

Remote procedure calls (such as web services) are typically a query-and-answer scenario. If the internet latency is high there will be a lot of "radio silence" between sending the query and receiving the answer and bandwidth efficiency is low. The easiest way to increase efficiency is by using multiple independent communication threads. We have some 25 of them running per well, each for a different purpose.
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 7:26 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
On Wed, 1 Jun 2016 06:23:43 -0700, Arthur Hoornweg <> wrote:

No it isn't, we record up to 200 parameters per oil well at a 10 Hz rate, perform some running min/max/avg calculations on them and store the result in 1 Hz sample interval (yes that's 3600 records per hour)

thanks for really interesting and detailed explanation but I think that such low rated dataflow is nowhere near high load and contention
level and might well be handled even by older 80386 without stressing it much

--
Vladimir Ulchenko aka vavan
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 11:51 PM   in response to: Vladimir Ulchenko in response to: Vladimir Ulchenko
thanks for really interesting and detailed explanation but I think that such low rated dataflow is nowhere near high load and contention
level and might well be handled even by older 80386 without stressing it much

The contention is at the receiving end where the data of twenty wells are retrieved by over 500 communication threads, but still cpu load rarely exceeds 1% and one doesn't even notice the service is running.
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 3, 2016 1:22 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
On Wed, 1 Jun 2016 23:51:33 -0700, Arthur Hoornweg <> wrote:

The contention is at the receiving end where the data of twenty wells are retrieved by over 500 communication threads, but still cpu load rarely exceeds 1% and one doesn't even notice the service is running.

I guess most of the time those threads just waiting for the data to come from the network therefore don't stress cpu/memory at all

--
Vladimir Ulchenko aka vavan
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 3, 2016 8:38 AM   in response to: Vladimir Ulchenko in response to: Vladimir Ulchenko
Vladimir Ulchenko wrote:

I guess most of the time those threads just waiting for the data to come from the network therefore don't stress cpu/memory at all

Yes that's very likely. But I'm still amazed that Windows has no problem at all running applications with 500+ threads. I had to reduce the default stack size of the program to avoid excessive memory use, though.
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 3, 2016 11:27 PM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
On Fri, 3 Jun 2016 08:38:11 -0700, Arthur Hoornweg <> wrote:

Yes that's very likely. But I'm still amazed that Windows has no problem at all running applications with 500+ threads. I had to reduce the default stack size of the program to avoid excessive memory use, though.

it can handle ten times more without much hassle. but that really depends on available memory amount and stack size

--
Vladimir Ulchenko aka vavan
loki loki

Posts: 787
Registered: 7/1/02
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 1:50 PM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
I have never even noticed any overhead through reference counting. The LOCK prefix only ensures that the CPU has exclusive ownership of that particular cache line for the duration of the operation. It's not so that all CPU's grind to a halt. Delphi's memory manager serializes memory allocations to guarantee that the heap (one heap for the whole process) remains consistent.

me i notice it because on a ISAPI application with i work, most of the
function was without "const". and i can say that after adding the const
everywhere, the speed much more faster !
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 1:12 AM   in response to: loki loki in response to: loki loki
me i notice it because on a ISAPI application with i work, most of the
function was without "const". and i can say that after adding the const
everywhere, the speed much more faster !

I'm pleased to hear that the "const" prefix omits the refcount for strings as well, I only knew it did so for interfaces.

Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 3:04 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur Hoornweg wrote:

me i notice it because on a ISAPI application with i work, most of
the function was without "const". and i can say that after adding
the const everywhere, the speed much more faster !

I'm pleased to hear that the "const" prefix omits the refcount for
strings as well, I only knew it did so for interfaces.


I thought it was well known that it does this for strings. Actually,
("long", i.e. Ansi) strings were the first types to benefit from that,
before interfaces were even part of the language.

That is why you will most of the time see strings being passed as
const, in runtime functions, the VCL or other libraries.

--
Rudy Velthuis http://www.rvelthuis.de

"Life is like a game of cards. The hand that is dealt you
represents determinism; the way you play it is free will."
-- Jawaharlal Nehru
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 3, 2016 8:52 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

I thought it was well known that it does this for strings. Actually,
("long", i.e. Ansi) strings were the first types to benefit from that,
before interfaces were even part of the language.

I tend to pass immutable parameters as const anyway so I just never noticed.

Janez Atmapuri ...

Posts: 240
Registered: 2/8/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 9:40 PM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Hello Arthur,

Intel libraries for example since recently try not to allocate any memory at
all internally. Everything is left to the user to avoid the the bottle neck
for multithreading.

The LOCK instructions is actually a huge problem, if you want to multithread
your algorithm for faster execution, especially if your code works with
strings and the strings are "short".

If you were to put this also on objects, the problem would nearly pin Delphi
to "single core language".

Regards!
Atmapuri
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 1:16 AM   in response to: Janez Atmapuri ... in response to: Janez Atmapuri ...
Janez Atmapuri Makovsek wrote:

The LOCK instructions is actually a huge problem, if you want to multithread
your algorithm for faster execution, especially if your code works with
strings and the strings are "short".

Then use "const" parameters wherever possible to avoid the refcount.

Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 3:01 AM   in response to: Janez Atmapuri ... in response to: Janez Atmapuri ...
Janez Atmapuri Makovsek wrote:

Hello Arthur,

Intel libraries for example since recently try not to allocate any
memory at all internally. Everything is left to the user to avoid the
the bottle neck for multithreading.

The LOCK instructions is actually a huge problem, if you want to
multithread your algorithm for faster execution, especially if your
code works with strings and the strings are "short".

If you were to put this also on objects, the problem would nearly pin
Delphi to "single core language".

Not quite true. The lock only occurs if the refcount changes, i.e. if
an ARC-ed object is assigned or when it leaves scope. It does not
happen on any other access. And on many "newer" processors (Pentium and
newer), the lock does not affect all threads anymore, unless several
threads access the same variable.

--
Rudy Velthuis http://www.rvelthuis.de

"Whatever is begun in anger ends in shame."
-- Benjamin Franklin (1706-1790)
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 3:05 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

Janez Atmapuri Makovsek wrote:

The LOCK instructions is actually a huge problem, if you want to
multithread your algorithm for faster execution, especially if your
code works with strings and the strings are "short".

If you were to put this also on objects, the problem would nearly
pin Delphi to "single core language".

Not quite true. The lock only occurs if the refcount changes, i.e. if
an ARC-ed object is assigned or when it leaves scope. It does not
happen on any other access. And on many "newer" processors (Pentium
and newer), the lock does not affect all threads anymore, unless
several threads access the same variable.

... and, as Arthur already said, it does not happen on const parameters.

--
Rudy Velthuis http://www.rvelthuis.de

"God is a comedian playing to an audience too afraid to laugh."
-- Voltaire (1694-1778)
Janez Atmapuri ...

Posts: 240
Registered: 2/8/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 2, 2016 4:48 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Dear Rudy,

Nevertheless, Intel thought it would be a good idea to introduce:

"
Intel® Transactional Synchronization Extensions New Instructions (Intel®
TSX-NI) are a set of instructions focused on multi-threaded performance
scaling. This technology helps make parallel operations more efficient via
improved control of locks in software.
"

Introducing new instruction last year only to tackle the problem of the
LOCK. Available only on latest Xeons for now.
LOCK is a big thing to think about when writing multithreaded code for the
sake of speeding up computation.

Regards!
Atmapuri

"Rudy Velthuis (TeamB)" wrote in message
news:856484 at forums dot embarcadero dot com...

Rudy Velthuis (TeamB) wrote:

Janez Atmapuri Makovsek wrote:

The LOCK instructions is actually a huge problem, if you want to
multithread your algorithm for faster execution, especially if your
code works with strings and the strings are "short".

If you were to put this also on objects, the problem would nearly
pin Delphi to "single core language".

Not quite true. The lock only occurs if the refcount changes, i.e. if
an ARC-ed object is assigned or when it leaves scope. It does not
happen on any other access. And on many "newer" processors (Pentium
and newer), the lock does not affect all threads anymore, unless
several threads access the same variable.

... and, as Arthur already said, it does not happen on const parameters.

--
Rudy Velthuis http://www.rvelthuis.de

"God is a comedian playing to an audience too afraid to laugh."
-- Voltaire (1694-1778)
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 9:19 AM   in response to: Kim Madsen in response to: Kim Madsen
Kim Madsen wrote:
What I have (re)discovered (I already knew it from my older Java days),
is that properly coded Delphi simply beats Java server side applications
coded according to all the defacto standards and best practices in 3
categories:

- Memory performance
- Runtime performance
- Ease of testing

Remember me with https://robertocschneiders.wordpress.com/2012/11/22/datasnap-analysis-based-on-speed-stability-tests/
The java server was responding well, but was eating a lot of memory!
I guess that a well written Delphi library, like kbmMW (as you for sure have used for your tests) or mORMot (as in this article), may have a very low memory and resource consumption.
The following diagram is self-telling: https://robertocschneiders.files.wordpress.com/2013/01/memory_consumption_nthreads.png

But .Net has a low memory use, also, in this test-case.
This was not a real world server, just an echo server.
So it was mainly using the http.sys web server of WCF, and not stress the .net garbage collector.
Once you add true data marshalling, and involve DB access, the resource use of .net is also increasing, much more than a Delphi server.
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: May 31, 2016 7:36 PM   in response to: Kim Madsen in response to: Kim Madsen
I have been saying this during the last 10 years! A well written Delphi server application is hard to beat in terms of performance.
I've been writing server applications in Delphi for a long long time and our applications kicked some serious Java and C# contenders every single time that performance was really measured and compared.
However, people tend to pick an isolated benchmark (in general a floating point one, where Delphi does not shine) and tell you: "see, Java is faster than Delphi". Pure BS.
IMO, Roberto Schneider's benchmark application didn't help much either (and I see his test results being referenced everywhere...). The comparison was not only unfair but also unrealistic.

Doesn't matter if one solution can handle 1 bazzilion simultaneous connections against another which can handle 1000 thousand connections. If this is the only number that matters, nothing could beat Oracle when comparing raw capability numbers like this. There would be no case for SQL Server or DB2 anywhere, because Oracle can beat them all in such simplistic tests!
What you have to ask yourself is: Can my server handle the number of simultaneous connections that I realistically expect with the given resources (memory/CPU/storage/network/etc)??
If your Indy based server can handle 200 users in a single core server using 1 Gb memory and you expect to have 50 users, you don't need anything else.
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 8:33 AM   in response to: Kim Madsen in response to: Kim Madsen
I'd like to see how GO stacks up because I have a web API that blows
through millions of rows of data and the GO server never goes above
40MB. Garbage collection doesn't have to suck.

It's fast and the deployment is a single exe. No runtime dependency.
Runs on linux, mac, windows and you can even cross compile.

Standard library has everything you need to build any type of server.
Janez Atmapuri ...

Posts: 240
Registered: 2/8/00
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 1, 2016 9:45 PM   in response to: Mike Margerum in response to: Mike Margerum
Hello Mike,

Garbage collection doesn't have to suck.

Agreed. If you write your code so that you don’t trigger repeated memory
allocations, it can have the same performance as software that does not
allocate memory <g> However the amount of effort of fishing this out and
thinking how to design your code is perhaps much more than not using GC.

Kind Regards!
Atmapuri

"Mike Margerum" wrote in message news:856392 at forums dot embarcadero dot com...

I'd like to see how GO stacks up because I have a web API that blows
through millions of rows of data and the GO server never goes above
40MB. Garbage collection doesn't have to suck.

It's fast and the deployment is a single exe. No runtime dependency.
Runs on linux, mac, windows and you can even cross compile.

Standard library has everything you need to build any type of server.

Mike Margerum

Posts: 590
Registered: 12/1/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 3, 2016 6:12 AM   in response to: Janez Atmapuri ... in response to: Janez Atmapuri ...
On 6/2/16 12:45 AM, Janez Atmapuri Makovsek wrote:
Hello Mike,

Garbage collection doesn't have to suck.

Agreed. If you write your code so that you don’t trigger repeated memory
allocations, it can have the same performance as software that does not
allocate memory <g> However the amount of effort of fishing this out and
thinking how to design your code is perhaps much more than not using GC.

Kind Regards!
Atmapuri

I didn't make any memory optimizations or attempt to reuse structures
and my Go server code never goes over 37MB parsing through gigabytes of
log files.

Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 13, 2016 6:06 AM   in response to: Kim Madsen in response to: Kim Madsen
- Memory performance
- Runtime performance

Nobody uses Java for that. Otherwise they will be using C or C++ (which has great cross-platform capabilities as well).

- Ease of testing

Mmmh, many testing techniques you're using in Delphi were born in Java, or appeared earlier in Java than in Delphi. There's always been a larger community of computer scientist and "methodologists" around Java than in Delphi.

Ask yourself why they are using Java, then...

I can tell some reasons:

1) Big enterprise backing (IBM, Oracle, RedHat, etc.) which Delphi utterly lacks. This is one of the biggest drivers.
2) Application servers availability which makes developing and deploying large server applications "easier". With Delphi, you're wholly on your own. Even the Windows service class is outdated. Datasnap is a joke, especially its security. Third party solutions less known, and with smaller companies behind.
3) Large number of third party libraries, tested again by a large number of users. Delphi ecosystem far smaller, sometimes code from a "one man company".
4) Web development support (JSP, etc). Again, Delphi doesn't offer but some "little known" solutions without a strong standard behind.
5) Free IDEs and other tools. Which also run on "free" Linux.
6) Easy deploy on Linux and other *nixes servers (mainframes included). The only server operating system Delphi supports (partially) is Windows. Apple is not interested in servers, and the others are mobile ones. Delphi Linux support is going to be a by-side product of Android, and that doesn't bode well for large server applications.
7) Large number of cheap developers who should be "sandboxed" by the language/VM itself. The large number of critical Java bugs made that not so advantageous...
8) Need to interop with existing Java applications.
9) Large pre-existing investment.
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 13, 2016 6:19 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
- Memory performance
- Runtime performance

Nobody uses Java for that. Otherwise they will be using C or C++ (which has great cross-platform capabilities as well).

Some Java experts do wonders... with a lot of tweaks and tricks... and performance lower than C/C++/Delphi in fact...
See https://www.lmax.com

I agree with those:

1) Big enterprise backing (IBM, Oracle, RedHat, etc.) which Delphi utterly lacks. This is one of the biggest drivers.
3) Large number of third party libraries, tested again by a large number of users. Delphi ecosystem far smaller, sometimes code from a "one man company".
7) Large number of cheap developers who should be "sandboxed" by the language/VM itself. The large number of critical Java bugs made that not so advantageous...
8) Need to interop with existing Java applications.
9) Large pre-existing investment.

About the following:

2) Application servers availability which makes developing and deploying large server applications "easier". With Delphi, you're wholly on your own. Even the Windows service class is outdated. Datasnap is a joke, especially its security. Third party solutions less known, and with smaller companies behind.
4) Web development support (JSP, etc). Again, Delphi doesn't offer but some "little known" solutions without a strong standard behind.
5) Free IDEs and other tools. Which also run on "free" Linux.
6) Easy deploy on Linux and other *nixes servers (mainframes included). The only server operating system Delphi supports (partially) is Windows. Apple is not interested in servers, and the others are mobile ones. Delphi Linux support is going to be a by-side product of Android, and that doesn't bode well for large server applications.

You could have nice technical solutions, including FPC/Lazarus which supports Linux, and has advanced web/SOA OpenSource libraries, like Brooks or our little mORMot.
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 6:09 AM   in response to: Arnaud Bouchez in response to: Arnaud Bouchez
You could have nice technical solutions, including FPC/Lazarus which supports Linux,

FPC/Lazarus is not Delphi. Actually you have a fragmented scenario, with partial compatibility, little promoted and little known outside a niche of users. Java had far better (and bigger) PR, and that counts. And let's remember Borland jumped on Java early, and for a while JBuilder worked, often at the expenses of Delphi itself. Eventually, it didn't pay out - IBM with Eclipse killed it. Eclipse never became the "the commodity only IDE" everybody was talking about, not even in Java itself, but the damage was done.

and has advanced web/SOA OpenSource libraries, like Brooks or our little mORMot.

I know, and some others know. And technically speaking, they may be very good.

But when you have to compete with WebSphere, Weblogic, JBoss, Tomcat.... it becomes a little more difficult, especially in environments when those tools are already widely deployed and known. Many people will look at the market "leaders" and use them, even when better "technical" solution may be available. It the old saying "nobody was fired for buying IBM" still working. Many just choose the less "risky" solution. It's difficult to change that mindset.

If you add that FPC is a little known open source product, and Delphi changed hands three times in the past years, in some sectors it's not really something you can "sell" easily, despite any technical merits.
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 13, 2016 7:04 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Den 6/13/2016 kl. 15:06 skrev Luigi Sandon:
- Memory performance
- Runtime performance

Nobody uses Java for that. Otherwise they will be using C or C++ (which has great cross-platform capabilities as well).

So applications shouldnt perform?
Weird argument.
The case is that (on the Windows platform), Delphi applications are
easier to write, read, debug and maintain than any of the above, and
they perform almost as well as C/C++ and have a much smaller memory
footprint than Java if you look at apps just a tad more complex than
hello world.

- Ease of testing

Mmmh, many testing techniques you're using in Delphi were born in Java, or appeared earlier in Java than in Delphi. There's always been a larger community of computer scientist and "methodologists" around Java than in Delphi.

Doesnt matter. The fact of life is that you have absolutely no idea
about what is actually running in most Java setups.

The application building and running is getting poluted with hooks, bean
instantiations and property settings in various volatile XML files
(which can be everywhere, including in jar/war files and externally in
the file system, and during distribution via capsule apps, typically
goverend by a mixture of ANT and POM files, which works like automatic
download/update of all prerequieites.... which results in a cascade of
other downloads from any number of repositories, which you may or may
not in reality know is active.

Further the defacto preferred way to do "standard" applications is to
download some blackbox CRM/ERP/whatever app, and "tune" it to your need.
Tuning it, typically includes various levels of embedding/customizing
source code, which in quite a number of cases makes it impossible to
update the original software without great hurdles.

There is a reason for the huge market for consultants for "cheap" open
source products.

Basically imo, architects of Java frameworks has gone out of their ways,
to make alot runtime alterably. Which means that when you load an app or
server, functionality in it, may actually be loaded from serialized
beans in some obscure storage framework, of which there is also no real
standard.... well.. there are 200 standards for that in Java.

The same with everything else in most Java frameworks.. there are no
real standards, but plenty plenty of custom (typically RTTI based) ways
of doing everything.

It makes testing Java apps quite complicated.

The simple unittest stuff is fine fine in Java. Interfaces et all, but
thats not what Im refering to.

Ask yourself why they are using Java, then...

Because companies were tired of being locked into expensive proprietary
mainframe solutions, where IBM etc were doing everything they could to
milk their customers.

That ALONE is the reason for Java's success imo.

The points you mention below, are the self fueling story about why
people should continue to use Java. And I agree that is the reason
people use for using Java (or any other major popular technology).

1) Big enterprise backing (IBM, Oracle, RedHat, etc.) which Delphi utterly lacks. This is one of the biggest drivers.

True... see above... Read about lockin and what the major companies "had
to do" to keep their customers :)

2) Application servers availability which makes developing and deploying large server applications "easier". With Delphi, you're wholly on your own. Even the Windows service class is outdated. Datasnap is a joke, especially its security. Third party solutions less known, and with smaller companies behind.

Good that you are quoting "easier". In fact deploying any reasonably
complex Java enterprise app is not easy. It has however become slightly
easier than it was in the early Websphere/JBoss days and before.

3) Large number of third party libraries, tested again by a large number of users. Delphi ecosystem far smaller, sometimes code from a "one man company".

Lots of thirdparty open source code, of which alot of it has low
quality, or is the result of uncontrolled open source contributions.
That can also be found in the Delphi world, but its one of the potential
dangers of open source. Most open source projects has few maintainers or
everybody is a maintainer. Then there are the fairly few large
"buzzword" projects, which are popular, and where their maintainers
typically are employed by one of the large machine vendors.

4) Web development support (JSP, etc). Again, Delphi doesn't offer but some "little known" solutions without a strong standard behind.

JSP... It is in use by more developers than any Delphi solution sure...
but thats just a numbers thing. It doesnt make it better for all
solutions by that fact.

5) Free IDEs and other tools. Which also run on "free" Linux.

And yet, many choose to replace the free IDE's with paid IntelliJ
licenses, which is fairly cheap actually, but none the less replaces
Eclipse many places.

One of the good things about IntelliJ is the build in support for so
many Java frameworks..... and its also its drawback, because menues in
the user interface simply ends up being cluttered with stuff that you
really dont need or that confuses you if you havnt used that particular
framework before.

6) Easy deploy on Linux and other *nixes servers (mainframes included). The only server operating system Delphi supports (partially) is Windows. Apple is not interested in servers, and the others are mobile ones. Delphi Linux support is going to be a by-side product of Android, and that doesn't bode well for large server applications.

Very weird.... Partially??? It seems to me you are really strongly
skewed in your perception of things.
How do you know anything about a product that is not released yet (the
linux part)? Thats just FUD until the opposite is proven.
In fact it is so far from "the Android side" as it almost can be,
because they focus solely on server side compilation.

Sure... Java is vastly more portable, which I also mentioned as its
strong point, but which also becomes a weak point at times.

7) Large number of cheap developers who should be "sandboxed" by the language/VM itself. The large number of critical Java bugs made that not so advantageous...

And still Java applets were banned in I think all browsers today. Memory
is short ;)
Java has loads of potential issues, specially when accessed via JNI.
To stay with the number game....
Of all the breakins happening around the world, I bet that Delphi server
side applications, counts for a very low number of those. The majority
is Java server side apps, PHP server side apps, .Net server side apps,
Python server side apps, Ruby etc. You get the picture I hope.

The common denominator of those platforms and installations, is that
ensuring a high level of security (even things as avoiding SQL injection
which were a wellknown hack 15 years ago) seemingly is pretty
complicated on all those popular platforms. Otherwise we wouldnt see all
those constant security problems.

Sandboxing works reasonably on mainframes, ensuring one app not directly
affecting another one, but it doesnt work against changing data which
both apps use, via a 3rd media (like a database or nosql storage).

8) Need to interop with existing Java applications.

Yep... Thats a very reasonable reason to use Java.

9) Large pre-existing investment.
Also a reasonable reason to use Java.
Interestingly enough reason 8 and 9 are bashed severely on these
newsgrouns when Delphi shops use those as their "excuse".

best regards
Kim/C4D
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 5:53 AM   in response to: Kim Madsen in response to: Kim Madsen
So applications shouldnt perform?

Applications need to perform withing their performance requirements. Being obsessed with performance alone may lead to the wrong choices. As said, if your application is time critical and needs high performance probably you'll be using C or C++. Sometimes even other specific languages better suited for a given problem. If your requirements include many other aspects, maybe a n ecosystem like Java is the correct solution.

The case is that (on the Windows platform), Delphi applications are
easier to write, read, debug and maintain than any of the above, and

I wouldn't say easier, but at least on par. Although you may find less tools to help you, even if those available are often very good.

they perform almost as well as C/C++ and have a much smaller memory
footprint than Java if you look at apps just a tad more complex than

I often said BorInCodeEmbIdera should have positioned Delphi as an "easier C++", and not as a "VB killer", just to be killed. Just it would have required an investment they didn't want to make, and they aimed for the lowest hanging fruit.

Thus the compiler was often behind C/C++ compilers - up to the point they had to switch to someone else one to cope. They lost all the advantage they had when Borland C++ was highly regarded compared to Microsoft C/C++. Then VC++ became faster, and better optimized.

Doesnt matter. The fact of life is that you have absolutely no idea
about what is actually running in most Java setups.

I don't know where you're working and with whom (and with which skills), thereby....

The application building and running is getting poluted with hooks, bean
[..]
not in reality know is active.

Oh well, I've seen dreadful Delphi applications as well (and in several other languages). That's a design and configuration management issue, not a language one.


Further the defacto preferred way to do "standard" applications is to
download some blackbox CRM/ERP/whatever app, and "tune" it to your need.

True. In Delphi you start from scratch because nothing to start from exists... <G>

Jokes aside, VAR way of doing things is not something new. It happened with COBOL and other mainframes products/languages before, happens in Java, happens in many other technologies that became used in that market segment.

standard.... well.. there are 200 standards for that in Java.

Compared to no standard at all in Delphi because nobody cares :-)

It is true Java ecosystem became large and often fragmented. It's up to the project leaders to ensure an application stays consistent. That's true beyond Java.

real standards, but plenty plenty of custom (typically RTTI based) ways
of doing everything.

Just like much newer Delphi stuff became more and more heavily RTTI based?

It makes testing Java apps quite complicated.

When you have to deal with third party stuff it usually becomes more complex. That's true. But often if you had to build all that infrastructure yourself the project could become unfeasible.

That ALONE is the reason for Java's success imo.

Just IBM was and still is one of the biggest backer of Java. It became the natural evolution path for those applications running on mainframes.

True... see above... Read about lockin and what the major companies "had
to do" to keep their customers :)

The issue is you first buy big systems (i.e. databases, ERP, etc.) from those companies, and then found they are mostly designed to be augmented and customized using Java - at least as the "simplest" solution. Remember for most user what is important is the data and their transformations, not how actually that is done.

Good that you are quoting "easier". In fact deploying any reasonably
complex Java enterprise app is not easy. It has however become slightly
easier than it was in the early Websphere/JBoss days and before.

Exactly. But they offers functionalities that if you had to write from scratch in Delphi would take a very long time, and very skilled people. And where are Delphi commercial counterparts?

Lots of thirdparty open source code, of which alot of it has low
quality, or is the result of uncontrolled open source contributions.

There are also commercial libraries. And on average, most Java open source projects are better maintained then their Delphi counterparts. As you said, some projects are backed by some large vendors and thereby has adequate manpower behind them - just it happens with Linux and Apache.

JSP... It is in use by more developers than any Delphi solution sure...
but thats just a numbers thing. It doesnt make it better for all
solutions by that fact.

It exists and it is a standard, Delphi lacks something like that. And probably doesn't even make sense. Delphi targets should be much more alike C/C++ ones.

And yet, many choose to replace the free IDE's with paid IntelliJ

True, but still free tools enable a large availability of cheap developers. Then, when you found there are better ways, the clever one will invest in a better IDE - as long as it pays its price. The ugly price model Delphi now employs doesn't bring in more developers, I'm afraid.

6) Easy deploy on Linux and other *nixes servers (mainframes included). The only server operating system Delphi supports (partially) is Windows. Apple is not interested in servers, and the others are mobile ones. Delphi Linux support is going to be a by-side product of Android, and that doesn't bode well for large server applications.

Very weird.... Partially??? It seems to me you are really strongly
skewed in your perception of things.

There are a lot of actual Windows server features Delphi doesn't support out of the box. AFAIK, its service implementation is stuck to deprecated NT APIs. Can you easily AD enable a Delphi application? What about MSMQ? Clustering? What about writing an MMC plugin (while Windows moved to .NET ones and PowerShell cmdlets as well).

Sure, you have full access to the Windows API and can code everything yourself... that's why IMHO it's "partial support".

linux part)? Thats just FUD until the opposite is proven.

Let's wait and see.... it looks it it will use the same compiler, which is not a great starting point. Issues has been already discussed elsewhere.

And still Java applets were banned in I think all browsers today. Memory
is short ;)

Just like ActiveX ones - which could also be written in Delphi.

Will you bet your job on Delphi security? BorInCodeEmbIdera shown it doesn't understand security - Datasnap and AppTethering are big ugly examples. Java went under a lot of scrutiny. Delphi never. What may lurk inside?

Java has loads of potential issues, specially when accessed via JNI.

And are you sure Delphi has little, or none?

Of all the breakins happening around the world, I bet that Delphi server
side applications, counts for a very low number of those. The majority
is Java server side apps, PHP server side apps, .Net server side apps,
Python server side apps, Ruby etc. You get the picture I hope.

Because there is a very low number of Delphi server applications, especially internet facing, I believe <G>

I get the picture - the more used ones are also the most attacked one. And some of them were (and are) badly implemented, true. Would you bet Delphi is better? Would you fully trust Indy on an internet facing application, especially one that would be an appealing target for skilled hackers?

ensuring a high level of security (even things as avoiding SQL injection
which were a wellknown hack 15 years ago) seemingly is pretty
complicated on all those popular platforms. Otherwise we wouldnt see all
those constant security problems.

Would we like to test how many Delphi applications are vulnerable to SQL injection? You don't need to be a web application to be vulnerable. How much Delphi code issue SQL statements after concatenating strings blindly, and maybe connecting as a privileged DB user? Are those issues a language issues, or developers issues? Last time I checked JDBC supported parameters and the like...

Yep... Thats a very reasonable reason to use Java.

And because Java is widely used is a self-feeding mechanism, which Delphi utterly lacks. Delphi in the past had the advantage of being able to deliver good Windows desktop applications. Unluckily BorInCodeEmbIdera lost the way an attempted to go several dead ends. Crippling their strongest appeal, and gaining nothing in others. Especially, they failed to understand Windows became more than a single user desktop GUI environment.

And worst of all, Delphi also actively managed to cripple its database access capabilities, which were a "crown jewel" for a while. dbExpress has been a nightmare for years, before being replaced, forcing to look for third party solutions. While Datasnap looks designed by novices without a clue about how to write a sound middleware, especially security-wise. Many developers went away, and many switched to a Java-like language like .NET. Why?

9) Large pre-existing investment.
Also a reasonable reason to use Java.

Sure. Rewriting big systems in another language is rarely an option. Unless you can offer a truly appealing alternative. And in its current state, Delphi unluckily is not.

Interestingly enough reason 8 and 9 are bashed severely on these
newsgrouns when Delphi shops use those as their "excuse".

I'm still partially using Delphi also because of the big investment made in the past. It works in any situation. Just you're going to find much more companies with a big investment in Java than in Delphi.

Edited by: Luigi Sandon on Jun 14, 2016 6:21 AM
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 9:00 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Den 6/14/2016 kl. 15:23 skrev Luigi Sandon:
So applications shouldnt perform?

Applications need to perform withing their performance requirements. Being obsessed with performance alone may lead to the wrong choices. As said, if your application is time critical and needs high performance probably you'll be using C or C++. Sometimes even other specific languages better suited for a given problem. If your requirements include many other aspects, maybe a n ecosystem like Java is the correct solution.

Reality is that most general Java users almost never looks into chooing
a better algorithm, or optimizing code. They have by their schooling
been thaught that its not needed.
Statement 1) "Java takes care of memory management much better than the
developer"
Statement 2) "You have a great JIT'er. The loop will be fast enough."

What they end up in, is often needing to buy vastly stronger hardware to
be able to run the application, compared to what would be needed using
for example Delphi.

And its not really that much of an effort doing that with Delphi,
because at least a pretty good sized part of the 3rdparty vendors, have
pride in their work, and wnat to make it work swiftly, securely and
stabily.

All the CRM/ERP/etc solutions I have seen in Java is not written with
that mindset. Its features only focus. Stability comes much later. And
performance is a non issue to the developers. Just buy more hardware.

The case is that (on the Windows platform), Delphi applications are
easier to write, read, debug and maintain than any of the above, and

I wouldn't say easier, but at least on par. Although you may find less tools to help you, even if those available are often very good.

Ok.. this is obviously subjective, but my experience (and the experience
I hear from other Delphi developers) is that generally .Net developers
and C/C++ developers are getting surprised about the speed at which a
fairly skilled Delphi developer gets a working prototype done, and the
following speed with which that prototype is matured into a working
stable product.

I know there are lots of skilled developers in the .Net and C/C++
community too, and they are good at what they do, and can be pretty
quick in most of it, but at least in my opinion Delphi contain the best
parts of the two worlds, the RAD prototyping and the underlying
frameworks needed for most situations.

At times you will want to go 3rdparty, but the same is always
happening in Java. You will never NOT go 3rdparty in the Java world.
In fact you are typically using a pretty high number of 3rdparty
libraries and tools at the same time in even the smallest (except Hello
world) Java applications.

The difference may be that those 3rdparty tools typically are open
source, while the majority of good ones for Delphi often are non open
source but imo often more covering. What people tend to forget btw is
that open source does not always mean free. The moment the project is to
be used for commercial use, then some open source vendors actually
charge for that, and some others they will not reply a single reply
except... pay to get our support... and pay much please :).


they perform almost as well as C/C++ and have a much smaller memory
footprint than Java if you look at apps just a tad more complex than

I often said BorInCodeEmbIdera should have positioned Delphi as an "easier C++", and not as a "VB killer", just to be killed. Just it would have required an investment they didn't want to make, and they aimed for the lowest hanging fruit.

I agree to the positioning. But I suppose there were an internal
conflict between the C/C++ fraction and the Delphi fraction.


Thus the compiler was often behind C/C++ compilers - up to the point they had to switch to someone else one to cope. They lost all the advantage they had when Borland C++ was highly regarded compared to Microsoft C/C++. Then VC++ became faster, and better optimized.

Doesnt matter. The fact of life is that you have absolutely no idea
about what is actually running in most Java setups.

I don't know where you're working and with whom (and with which skills), thereby....

Regardless of who I work with and their skills, thats really a fact. The
moment that POM (which I actually kind of like because of its reasonable
simplicity) gets into the game, then stuff are being instantated and
downloaded from many places.
If you then use capsules or other similar packers, they may also auto
download stuff to put into the package.
And the sheer number of 3rdparty packages required, to enable the Jar or
War project to run, makes it challenging to know exactly which versions
of which libraries are used. It can even end up in having the
requirement for multiple versions of a library in the same product,
(specially if you use extend existing CRM/ERP etc. products).

IMO its not simple. Its not nice, and Delphi is much simpler.

That spring and most other such frameworks utilize RTTI to the extreme
with dynamic loading (sometime early, sometime lazy) of this and that
and everything, really doesnt make it easier to know exactly whats being
run at which time.

If you build your Java app from scratch, keeping the number of 3rdparty
frameworks/libraries low, then obviously you have much better track of
things. But thats just not what the majority of Java shops do.

The application building and running is getting poluted with hooks, bean
[..]
not in reality know is active.

Oh well, I've seen dreadful Delphi applications as well (and in several other languages). That's a design and configuration management issue, not a language one.

Agreed. However RTTI based frameworks, which most are in Java, not only
give you the pistol, it also provides all the ammunition you want (and
more too) to shoot yourself in the foot, even completely unknowningly.

Further the defacto preferred way to do "standard" applications is to
download some blackbox CRM/ERP/whatever app, and "tune" it to your need.

True. In Delphi you start from scratch because nothing to start from exists... <G>

And you are able to get a product that actually does exactly what you
need. Not something generic that needs to be recoded for your use, which
often is almost as timeconsuming.

Jokes aside, VAR way of doing things is not something new. It happened with COBOL and other mainframes products/languages before, happens in Java, happens in many other technologies that became used in that market segment.

True. I suppose what I object to, is the copy from everywhere, add some
goo and see if it blends. It typically does with enough force put into
it, but the outcome is often a nasty sticky brown colored mixture with a
bad taste.


standard.... well.. there are 200 standards for that in Java.

Compared to no standard at all in Delphi because nobody cares :-)

So how are 200 standards better than no standard? Actually imo there are
fairly strict standards in Delphi for many things, namely almost all
those that comes with the tool. Most 3rdparty vendors they extend on
those standards (and then there are some, granted, like me, that invents
new standards... :) )

real standards, but plenty plenty of custom (typically RTTI based) ways
of doing everything.

Just like much newer Delphi stuff became more and more heavily RTTI based?

Yes. And it makes sense for some purposes. But IMO not to the extent
that it is being used in Java. In Delphi, I would say that the majority
of applications do not knowingly take advantage of RTTI, while in Java
thats the standard. You cant use a Java framework and not use RTTI in
the extremes. Basically everything is glued together with RTTI.
It is one of several reasons why starting a Java server app can take
quite some time, the other obviously being jitting, poor algorithms for
startup since "it really doesnt matter much if it starts in 2 minutes or
2 seconds in a production environment" attitude, which in many cases is
true, but it is imo an unhealthy rule of engagement being a developer
with pride.

It makes testing Java apps quite complicated.

When you have to deal with third party stuff it usually becomes more complex. That's true. But often if you had to build all that infrastructure yourself the project could become unfeasible.

To some extents I agree. All the 3rdparty code obviously provides
functionality you need. It is however more the norm than not, that "we
bring in yet another library for something" than write it ourselfs, even
for smaller things.

There is often a mix of Google frameworks (Guava, Guice), Spring, Apache
commons, mixture of various logging frameworks, Grails, various XML,
YAML and JSON/BSON frameworks etc. in one big ugly mess within the same
application.

Even making a standard for how configuration is made is impossible in Java.

Java applications are typically using at least 3 different protocols for
configurations, at the same time:

- Java start up parameters
- XML files instantiating beans and setting property values, often
cascadingly refering to other XML files, of which some are out in the
open in the file system and some are "hidden" in embedded Jar files etc.
- property files.

Further often JSON, additional XML files, YAML files etc are also used
by various frameworks for their configuration.

It is honestly a true bloody mess!

JSP... It is in use by more developers than any Delphi solution sure...
but thats just a numbers thing. It doesnt make it better for all
solutions by that fact.

It exists and it is a standard, Delphi lacks something like that. And probably doesn't even make sense. Delphi targets should be much more alike C/C++ ones.

JSP is just one way of doing web sites in Java... one of the more
popular ways, just as ASP and ASP.Net. It was actually made as a
competitor to ASP originally.

Delphi does have built in web page handling, but its not really JSP/ASP
like. That doesnt mean that nothing exists for Delphi. It does, as a
part of Delphi, and may actually be faster to get something done in,
than JSP.

However like with Java, there in Delphi also exists 3rdparty tools.
Actually every month it seems that a new one pops up, so it seems to me
that there is alot of choise, although I personally would also look on
the longevity of their support until now, when choosing... and in fact I
would obviously use my own template based system, built into kbmMW, for
at least a good number of the sites that I would create using Delphi.

And yet, many choose to replace the free IDE's with paid IntelliJ

True, but still free tools enable a large availability of cheap developers. Then, when you found there are better ways, the clever one will invest in a better IDE - as long as it pays its price. The ugly price model Delphi now employs doesn't bring in more developers, I'm afraid.

I agree with you that it would be really nice if Delphi had a free
version that had enough functionality for people and 3rdparty vendors to
actively support it. This would make it more interesting for newcomers,
which might be actual users in the longer run.

But I do recognize that Java has never been a product that was ment to
earn money in itself. It has always been about making consultancy work
around Java solutions and in Suns case, shipping Sun servers, and for
Oracle getting control over the large Java installations, mixing Java
into Oracle without licensing problems and attempting to lock DB users
into the Oracle database.

And that is quite difficult to compete against for a vendor, who's
primary product is selling development tools.

No doubt that its a challenge that makes it difficult to grow quickly.
I suppose one can compare it with TV most places these days, or news...
Originally people paid good money for the channels (some still do), and
the newspapers. Over time free versions came, and people shifted their
attention to those, without realizing that the quality of tv and news
actually degrades at the same time.
The vendor pushing free stuff does need to make a living... either by
commercials or by selling consultancy hours, which strongly skews the
business case and thus also the contents offered.

The users doesnt really realize that, or they "just keep living with it,
because ... what to do?"

And thats exactly also whats going on in the software business. The
outcome is not better quality, nor better solutions, or in the end lower
price. Its going to be the opposite.

There are a lot of actual Windows server features Delphi doesn't support out of the box. AFAIK, its service implementation is stuck to deprecated NT APIs. Can you easily AD enable a Delphi application? What about MSMQ? Clustering? What about writing an MMC plugin (while Windows moved to .NET ones and PowerShell cmdlets as well).

THen you can say that Java supports no platforms either or only
partially. Java do not support any of those things directly either. You
can get 3rdparty libraries that assists you, the same as you can in Delphi.

linux part)? Thats just FUD until the opposite is proven.

Let's wait and see.... it looks it it will use the same compiler, which is not a great starting point. Issues has been already discussed elsewhere.

Thats the debate about reference counted garbage collection. But why is
it that using Java, which imo have an even worse GC strategy, then its
completely fine :)

And still Java applets were banned in I think all browsers today. Memory
is short ;)

Just like ActiveX ones - which could also be written in Delphi.

Sure.. but Delphi were never sold as a sandboxed safety thing. Java was.

Will you bet your job on Delphi security? BorInCodeEmbIdera shown it doesn't understand security - Datasnap and AppTethering are big ugly examples. Java went under a lot of scrutiny. Delphi never. What may lurk inside?

Actually Im much more confident in people not breaking into my servers
(written in Delphi, using my framework) from the internet, than I am
with any other Java (or PHP or Python or Perl or....) application server
out there.

Why? Not because Java is badly coded actually. But because the majority
of developers out there doing Java are using code they have no idea of
if safe or not, and mocking up their business on that.
And in fact many of those making that existing code, really do not focus
on actual security, nor performance either.
Functionality and looking smart is what often counts.

Java has loads of potential issues, specially when accessed via JNI.

And are you sure Delphi has little, or none?

Delphi in itself, does not pretend to be unbreakable! Java is sold as a
safe sandbox, which is vastly different.
I have however exposed Delphi based servers to the internet for more
than 10 years, and have never been bitten by doing so. In that period
every Java, PHP, Perl.... server solution have had more than one breach!
And Im daily seeing hundreds of attacks from scriptkiddies and others.
And they simply do not penetrate.

Im absolutely certain that you can bring a server of mine down, by
overloading it, but Im also fairly confident that you wont be able to
control it to make it do other things than it was designed for.

Of all the breakins happening around the world, I bet that Delphi server
side applications, counts for a very low number of those. The majority
is Java server side apps, PHP server side apps, .Net server side apps,
Python server side apps, Ruby etc. You get the picture I hope.

Because there is a very low number of Delphi server applications, especially internet facing, I believe <G>

Yep.. that was what I kind of hinting at. But percentage wise, then Id
still say that Java servers historically has has a much worse
penetration protection ratio than Delphi servers, that were designed to
face towards the internet.


I get the picture - the more used ones are also the most attacked one. And some of them were (and are) badly implemented, true. Would you bet Delphi is better? Would you fully trust Indy on an internet facing application, especially one that would be an appealing target for skilled hackers?

See above.

Would we like to test how many Delphi applications are vulnerable to SQL injection? You don't need to be a web application to be vulnerable. How much Delphi code issue SQL statements after concatenating strings blindly, and maybe connecting as a privileged DB user? Are those issues a language issues, or developers issues? Last time I checked JDBC supported parameters and the like...

There is a difference between applications and server applications
facing the internet imo. Inhouse applications may not need as high level
of security, because only trusted people are using them and the data may
be available for those trusted people.

Im personally advocating for high level of security also for those apps,
why I have designed kbmMW with that in mind.

However what counts more is where the application faces public access.
And yes, I really believe that in those situations, Delphi fares better.
Again Ive never had a SQL injection issue on any of my servers in 10+
years. Sure... its very possible to make a badly designed web server
with Delphi that would allow for that, but at least for 10 years there
has been a framework that do not fall for that in the Delphi world, when
used according to recommendations.

And worst of all, Delphi also actively managed to cripple its database access capabilities, which were a "crown jewel" for a while. dbExpress has been a nightmare for years, before being replaced, forcing to look for third party solutions. While Datasnap looks designed by novices without a clue about how to write a sound middleware, especially security-wise. Many developers went away, and many switched to a Java-like language like .NET. Why?

During that whole period kbmMW has been available. They could have
switched to using that instead. So why didnt they?

Because it was not the reason for why they switched to Java or .Net.
Marketing and masshysteria and Microsoft/Sun/Oracle/IBM never goes wrong
mantra made them change.

Oh... actually the switch from Delphi to .Net imo has largely been
driven by Sharepoint and the pilfering of Anders H which were a
marketing wise loss for Borland at the time strongly affecting Delphi
imo. Further Delphi never had something like Sharepoint, and if it would
have it, it would have had to be before MS came out with theirs, to have
any impact.

best regards
Kim/C4D
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 12:23 PM   in response to: Kim Madsen in response to: Kim Madsen
Reality is that most general Java users almost never looks into chooing
a better algorithm, or optimizing code. They have by their schooling

Not that Delphi too shines in this regard... remember when FastCode routines had to be brought in to cover the deficiencies of Delphi RTL? Knuth's book are no longer a "mandatory" read <G>. It's not limited to Java.

Statement 1) "Java takes care of memory management much better than the
developer"

Well, they have little choice. Anyway FastMM author knew better than Delphi developers...

Statement 2) "You have a great JIT'er. The loop will be fast enough."

Mmmmh, some developers also think "native code is always faster". But as said, not always speed is everything. Especially when you may need to wait for a long query to complete.

All the CRM/ERP/etc solutions I have seen in Java is not written with
that mindset. Its features only focus. Stability comes much later. And
performance is a non issue to the developers. Just buy more hardware.

That's a different software league, big ugly software on which a lot of money runs - and it is true that a lot of off-shore development doesn't shine...

and C/C++ developers are getting surprised about the speed at which a
fairly skilled Delphi developer gets a working prototype done, and the

Prototype is one thing, testing and maintaining another. Delphi surely is not inferior to Java as a good OO language, and as a RAD tool far superior. It's also very risky if the prototype becomes the final application. IMHO the VCL would have need a good redesign since Delphi 1 times. In the wrong hands, tightly coupling between the UI and the logic is the norm.

At times you will want to go 3rdparty, but the same is always
happening in Java. You will never NOT go 3rdparty in the Java world.

Today is difficult to develop any application without including 3rd party libraries, unless you're a shop large enough to be able to write and maintain your own. There are many different areas that may require specific expertise - i.e. encryption libraries, or network protocols.

source but imo often more covering. What people tend to forget btw is
that open source does not always mean free. The moment the project is to

I won't dive in this argument now - my opinion is to choose the right libraries knowing what you're using and what support you get.

I agree to the positioning. But I suppose there were an internal
conflict between the C/C++ fraction and the Delphi fraction.

IMHO management was too eager to jump into the fashionable market of the moment, believing to reap easy money. They repeated that mistake over and over (Kylix, .NET, Ruby, PHP...). A more careful planned approach would have paid better.

Regardless of who I work with and their skills, thats really a fact. The
[...]
IMO its not simple. Its not nice, and Delphi is much simpler.

I understand your feelings, and believe me, I've seen many projects under Linux using the same approach (even written in C++). Because a lot of stuff is free, people tend to glue together a lot of disparate pieces. Sometime you may not have also any choice because of other software requirements. That depends mostly on how much control you have on the software design and implementation, is only partially related to using Java or Delphi. In Delphi you're usually shielded by those issues because you usually have more control, and there are less (free) pieces to put together.

That spring and most other such frameworks utilize RTTI to the extreme

I know - but it's not different in other languages, it's the design used for such frameworks. Flexible, but at a price.

Agreed. However RTTI based frameworks, which most are in Java, not only

I'm not a fan of (excessive use of) RTTI, thereby I agree with you. Unluckily there's a "fashion" driving that way, and not only in Java, although it's very visible in it.

And you are able to get a product that actually does exactly what you

Depends on how good the starting point is :-)

True. I suppose what I object to, is the copy from everywhere, add some

Again, something you can do in any language. As said, the availability of a lot free stuff, and lack of proper development skills and project management (and maybe unrealistic planning and funding) may lead to such monsters. In Delphi projects too I had to fight developers trying to sneak in external libraries because of laziness (or worse).

So how are 200 standards better than no standard? Actually imo there are

Sure, you can pick one instead of creating your own <G> Jokes aside, there are a few sounder standards you can use, if you don't let you carried away by the latest and more hyped ones.

Delphi is sometimes too quick to abandon old standards to jump on new ones. For example it abandoned too quickly SOAP to jump on the REST/JSON bandwagon. Of little help when, say, VMWare uses SOAP and Delphi fails to load its WSDL for an old and stupid 64Kb limit...

Even making a standard for how configuration is made is impossible in Java.

That's an issue that spans beyond Java. You're going to see it a lot under Linux.

at least a good number of the sites that I would create using Delphi.

IMHO Delphi is not a good tool for web development, just like C/C++ are not. It's better suited for other tasks.

But I do recognize that Java has never been a product that was ment to
earn money in itself. It has always been about making consultancy work

I agree that Java is partly a "byside" product of other interests. But it got a broad support for a given class of applications, and it's not easy to remove it from there. Tools more widely used then Delphi couldn't.

And that is quite difficult to compete against for a vendor, who's
primary product is selling development tools.

IMHO the real issue with Borland tools it's they never attempted to grow enough and properly to compete in a larger arenas, especially when they were growing rapidly. Sometimes they were blinded by the success in more limited markets (like the Windows desktop applications), and failed to grow further to cope with the new needs arising. Other time lack of focus derailed the products.

Originally people paid good money for the channels (some still do), and

I do pay because free TV here is truly ugly. But I perceive a value. To sell an expensive product, you need to find the right "place", and ensure people perceive a value for what they pay.

THen you can say that Java supports no platforms either or only
partially. Java do not support any of those things directly either. You
can get 3rdparty libraries that assists you, the same as you can in Delphi.

Java offset that for "true" portability. Delphi needs to decide if it is a "native" development tool from which I do expect broad support for the "native" platform, or a cross platform one, but then I expect good support of the platforms most used.

Sure.. but Delphi were never sold as a sandboxed safety thing. Java was.

And Java truly deserves all the flack it took. And still, it wasn't enough to kill it :-(

Actually Im much more confident in people not breaking into my servers
(written in Delphi, using my framework) from the internet, than I am
with any other Java (or PHP or Python or Perl or....) application server
out there.

Most attacks are performed using "kits" that use already known vulns. Only dedicated attacks (usually called "APTs") are perfomed by skilled hackers trying to look for and exploit new and unknown ones. The target usually has to be one "valuable" enough to "pay" for the expenses.

of developers out there doing Java are using code they have no idea of

Believe me, it's not because of Java. It's because of bad developers. It is true some languages broadly used and less "hard" to learn have an higher percentage of bad developers.

Functionality and looking smart is what often counts.

Often, it is what is asked for and what sells, unluckily.

And Im daily seeing hundreds of attacks from scriptkiddies and others.
And they simply do not penetrate.

It's the skilled hacker you have to be afraid of. Attackers looking for the low hanging fruit may be put off by something less used they don't have an exploit ready for.

control it to make it do other things than it was designed for.

Have you ever had a pen test made?

facing the internet imo. Inhouse applications may not need as high level
of security, because only trusted people are using them and the data may
be available for those trusted people.

I'm sorry, but that's old thinking and today dangerously wrong. You can't today believe defending the perimeter is enough. You can't trust insiders (remember Snowden....) and attackers may penetrate inside anyway (using an OS or other applications/libraries vulns) and then look for more vulnerable applications to gather valuable data (which also could be useful for more attacks), to elevate privileges, to hide, and so on.

During that whole period kbmMW has been available. They could have
switched to using that instead. So why didnt they?

Maybe you didn't promote it enough? ;-)

Marketing and masshysteria and Microsoft/Sun/Oracle/IBM never goes wrong
mantra made them change.

You may not like it or not, but that's something you have to face. And you need support from your tool of choice supplier. Unluckily Borland failed miserably, and the situation doesn't help.
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 2:13 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Den 6/14/2016 kl. 21:23 skrev Luigi Sandon:

Well, they have little choice. Anyway FastMM author knew better than Delphi developers...

Its not comparable as you also know. There have been memory managers for
decades. The difference between Java and Delphi is not in allocation of
the memory, but in getting rid of it again.
And THAT difference is pretty massive ;)

Statement 2) "You have a great JIT'er. The loop will be fast enough."

Mmmmh, some developers also think "native code is always faster". But as said, not always speed is everything. Especially when you may need to wait for a long query to complete.

No.. Native code is per definition not necessarely faster. The choice of
algorithm is what makes the largest difference. However even in that
category, I see that most of the ERP/CRM etc solutions really dont care
about it and just use what can be found to have the functionality they
need, completely disregarding memory utilization optimization and
performance ditto.

Prototype is one thing, testing and maintaining another. Delphi surely is not inferior to Java as a good OO language, and as a RAD tool far superior. It's also very risky if the prototype becomes the final application. IMHO the VCL would have need a good redesign since Delphi 1 times. In the wrong hands, tightly coupling between the UI and the logic is the norm.

I agree that a prototype in it self, should not by default be elevated
to a production product, unless you know exactly what you elevate and
why you do so.
However its actually possible to make well coded, well designed
prototypes where parts of functionality is what has been left out.
Those prototypes can be elevated to production product pretty quickly,
when the missing functionality has been added.

Today is difficult to develop any application without including 3rd party libraries, unless you're a shop large enough to be able to write and maintain your own. There are many different areas that may require specific expertise - i.e. encryption libraries, or network protocols.

You can get an awful long way in Delphi without any 3rdparty libraries,
which is actualy sometimes a problem for 3rdparty vendors ;)
But I do agree that there are users that have needs that exceeds whats
in the box, and looks for 3rdparty stuff (fortunately).

Im just saying that in the Java world, you cant make any of the
current applications without including some opensource 3rdparty library.

However I do find that to be less relevant, as long as people are very
aware about what they choose, and why.

I understand your feelings, and believe me, I've seen many projects under Linux using the same approach (even written in C++). Because a lot of stuff is free, people tend to glue together a lot of disparate pieces. Sometime you may not have also any choice because of other software requirements. That depends mostly on how much control you have on the software design and implementation, is only partially related to using Java or Delphi. In Delphi you're usually shielded by those issues because you usually
have more control, and there are less (free) pieces to put together.

Maybe the problem is open source related then :). Actually to some
extent I believe its so. The open source movement was founded as a
protest against the rigid and expensive licensing imposed by many large
vendors (IBM again as one of them).
Protest movements that are religious about things like freedom of
information etc, tend to adhere less to administrative things, and tend
to be more impulsive in their acting.
That mindset most likely is the reason to some of the mess, but
obviously also for the good that has come out of it.

That spring and most other such frameworks utilize RTTI to the extreme

I know - but it's not different in other languages, it's the design used for such frameworks. Flexible, but at a price.

Its a design made IMO to foremostly be flexible in most conceivable
theoretical ways, more than pratical. The worldwide combined time lost
in debugging, understanding, altering while keeping those types of apps
stable, would have been better used in other aspects of programming imo.

I'm not a fan of (excessive use of) RTTI, thereby I agree with you. Unluckily there's a "fashion" driving that way, and not only in Java, although it's very visible in it.

Thats a good word... fashion. That unfortunately drives alot of business
decisions, ending up in lost time, lost money and lost oppertunity....
except for the consultants, who always earns vast amounts of money on
exactly that fashion game.

Delphi is sometimes too quick to abandon old standards to jump on new ones. For example it abandoned too quickly SOAP to jump on the REST/JSON bandwagon. Of little help when, say, VMWare uses SOAP and Delphi fails to load its WSDL for an old and stupid 64Kb limit...

I dont think they are as such actually abandoning SOAP, but it might be
that they have not had compelling reasons to invest money in fixing that
bug. If you want to be considered up to speed in something, you need to
spend your development money on the "new and MUCH improved stuff" that
the marketing gurus of the largest firms has (re)"invented".

Even making a standard for how configuration is made is impossible in Java.

That's an issue that spans beyond Java. You're going to see it a lot under Linux.

Open Source illness ;)

IMHO Delphi is not a good tool for web development, just like C/C++ are not. It's better suited for other tasks.

Why do you believe so?
Delphi can serve web pages with all their gory Javascript libraries and
cascading style sheets etc. just as fast and just as safely as any other
development tool.

JSP is "just" ASP for Java. A many year old impure way to mix HTML,
Javascript and "Java native" code, which even Java architects has been
talking against for years.

You have JSP like functionality in Delphi. You can even choose what
langauge you want to use... Pascal, Basic, Javascript or C (if I
remember correctly). And the script can even be compiled to native code
before execution, or you can choose to run it interpreted.
www.PaxCompiler.com - I seem to remember they had a template parser
which could be used to mix for example HTML and script in the same way
as JSP.
DWS certainly has that capability, and is also pretty fast as far as I
know, and its free as far as I know.

And then you can choose to go in a different direction, where you only
use macros, html templates etc, and do not mix server side scripting
with your HTML code. This is what for example kbmMW includes out of the
box, and it works well.

Writing Web sites is less about whats serving the pages, and more about
the Javascript you put into them to make the appeared response time and
functionality application like.

of developers out there doing Java are using code they have no idea of

Believe me, it's not because of Java. It's because of bad developers. It is true some languages broadly used and less "hard" to learn have an higher percentage of bad developers.

I agree. Java is not to blame. But the unfortunate amount of badly coded
well recognized libraries and applications and their developers are.
Unfortunately that is what the rest of the Java developers ends up
working with.

It's the skilled hacker you have to be afraid of. Attackers looking for the low hanging fruit may be put off by something less used they don't have an exploit ready for.

Sure... but I think its problematic that the easy hacks by the
scriptkiddies tends to penetrate a fairly large amount of sites using
non Delphi development tools, on a regular basis.

I'm sorry, but that's old thinking and today dangerously wrong. You can't today believe defending the perimeter is enough. You can't trust insiders (remember Snowden....) and attackers may penetrate inside anyway (using an OS or other applications/libraries vulns) and then look for more vulnerable applications to gather valuable data (which also could be useful for more attacks), to elevate privileges, to hide, and so on.

I did write that I personally find that any application should be
written in a safe way. However the fact is also that the moment you are
inside the perimeter in most ocmpanies, then you basically have access
to everything, its network, its file shares, its databases, USB ports of
PCs etc.
There may be some attempts to put passwords on some things, but going
all in encrypting all network traffic is fairly rare in non classified
places.

So the moment an attacker is inside, he/she is able to cause havoc most
places, regardless of preventing SQL injection etc. in apps. They just
circumvent.

Maybe you didn't promote it enough? ;-)

That must be it ;)

You may not like it or not, but that's something you have to face. And you need support from your tool of choice supplier. Unluckily Borland failed miserably, and the situation doesn't help.

I dont like it, but I know it is like it is.

best regards
Kim/C4D
jesu ortega

Posts: 68
Registered: 9/28/01
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 2:09 AM   in response to: Kim Madsen in response to: Kim Madsen
I dont think they are as such actually abandoning SOAP, but it might be
that they have not had compelling reasons to invest money in fixing that
bug. If you want to be considered up to speed in something, you need to
spend your development money on the "new and MUCH improved stuff" that
the marketing gurus of the largest firms has (re)"invented".

Unfortunately it seems that government agencies are locked into using Java for everything related to certificates, e-government and secure webservices.

And more unfortunately, Delphi is unable to call those webservices and Embarcadero don't care about it. They don't care even to create a bridge to the .NET implementation so they don't need to implement it themselves. I haven't used CrossTalk, but if something like that was included with Delphi it would allow to do many things that now are simply non-viable.
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 3:33 AM   in response to: Kim Madsen in response to: Kim Madsen
Its not comparable as you also know. There have been memory managers for

Java adopted a given model, and we all know the differences among manual management, ARC and GC. Just, like all GCs are not equal, nor are memory managers. For a long time Delphi came with an outdated memory manager. It was required an independent developer to replace it with a more modern one. Delphi often hides dust under the carpet, and strive for new shining features (often not well implemented), instead of fixing and replacing outdated but basic features.

category, I see that most of the ERP/CRM etc solutions really dont care

True. Partly is because performance is not among their main requirements (while "safety" may be, better slower than risk) , and partly because of cheap developers. Can native code outperform Java? Sure. Just all those companies perceive a far higher risk in using languages like C/C++ (and Delphi, if they still remember about it), and known their developers are more expensive. Nobody will buy the "fastest ERP" because of that. It's not what customers look for, even if later they may find it "a bit slow".

You can get an awful long way in Delphi without any 3rdparty libraries,

Are you sure? Actually, to develop any decent application in Delphi I can barely use the compiler, part the RTL, and the basic VCL classes - almost everything else need to come from 3rd party libraries - the GUI, the database libraries, encryption, networking, charting... without them Delphi offered too little (and often buggy).

Im just saying that in the Java world, you cant make any of the
current applications without including some opensource 3rdparty library.

Depends on what you develop and with what budget. For example you can develop Delphi applications with almost no third party libraries, I really can't.

Maybe the problem is open source related then :). Actually to some

Partly it is. You have "free" stuff that does what you need, you use it instead of developing it yourself, accepting compromises. If you had to "buy", you would choose more wisely and will anyway use less external code. Also commercial developers are usually more "conservative" and adopt more standards. Many FOSS projects may adopt something just because "it's new", and when you code not for money often you do for fun and to learn.

Its a design made IMO to foremostly be flexible in most conceivable
theoretical ways, more than pratical. The worldwide combined time lost

Java likes that approach. Also the push of other (fashionable) languages that put flexibility before speed (and often safety) has been strong.

It is true Delphi is often more practical. Just look at controls events handling :-) Anyway, Spring was ported to Delphi as well, because devs now like and want it.

Thats a good word... fashion. That unfortunately drives alot of business

I know, but if other tools becomes utterly un-fashionable like Delphi became, it's then difficult to "sell" them in business. BorInCodeEmbIdera "marketing" never had a clue about it.

Java despite its shortcoming is sustained by far better marketing. Isn't Embarcadero too using Jira now? Jira is written in Java.... and aren't these newsgroup running on a Java application too? Where are the Delphi competitors?

I dont think they are as such actually abandoning SOAP, but it might be

SOAP support has never been updated since a long time. For "abandoned" I mean "no longer actively maintained and updated", not "removed".

The bug was fixed AFAIK in a recent release, but back then I had to develop our software to drive the VMWare test system in another language.

spend your development money on the "new and MUCH improved stuff" that
the marketing gurus of the largest firms has (re)"invented".

And that's "fashion" again. Delphi is not immune from the "fashion driven development" - just doesn't take any real advantage from it, while others do.

There's a lot of half-implemented stuff in Delphi which has been the "new stuff" for a while just to be quickly abandoned as soon more "new stuff" became fashionable.

Sometimes "chasing the market" is correct, sometimes is not. You need a sound plan on how to evolve, understanding your environment. Jumping like a mad frog to catch any new fly won't help your product sales, and won't help your customers.

Open Source illness ;)

Every team, or even single developer creates software on its own for its needs, and publish it. Without a "centralized" management, is inevitable that X uses XML files, Y uses YAML, Z uses an INI like syntax, while another creates its own standard. For many people "free" is more important than anything else :-)

Why do you believe so?

Because Delphi would be more apt to write a web server then a web application. Not that it can't serve web pages, and surely he can be much faster than PHP or Python, just how web applications are designed, deployed and maintained, other languages are better suited to create them.

I don't believe a single language/tool should be used everywhere and for everything. IMHO there are tools better suited for some tasks, but not for others.

remember correctly). And the script can even be compiled to native code
before execution, or you can choose to run it interpreted.
www.PaxCompiler.com - I seem to remember they had a template parser

Just, this is not really "Delphi" itself. They are tools supporting a Delphi-like syntax, developed outside Delphi "standardization", by small companies on their own. They can be technically outstanding, but they will be perceived as "risky", with little support and difficult to maintain for lack of developers. Thereby many people will just use Java.

Writing Web sites is less about whats serving the pages, and more about
the Javascript you put into them to make the appeared response time and
functionality application like.

Depends on the application. There are some with complex server-side processing, with modules that can even be built using different technologies. Right now I'm working on an application which uses a relatively simple Python based web frontend and backend (on Linux). The backend interfaces with an external application written in .NET (on Windows), and an analysis engine written in C++ (on Linux) which does the heavy processing. Delphi is still used for the analysis engine management GUI. We could have developed the GUI in Java or .NET also, but I have Delphi developers sitll around, and Developer Express still allows for some nice GUIs :-)

scriptkiddies tends to penetrate a fairly large amount of sites using
non Delphi development tools, on a regular basis.

Many of those sites have unpatched systems with known vulnerabilities. Easy to pierce.

Probably right now sites developed with tools little known and which were never inspected for vulns may look more secure. But are they really? Windows Mobile phones are "more secure" because they aren't a target for malicious apps, being so few. Most attacks are against Android and iOS. What smartphone do you own?

inside the perimeter in most companies, then you basically have access
to everything, its network, its file shares, its databases, USB ports of
PCs etc.

No. In most companies everybody doesn't have access to everything. If it happens, they have a problem, a big problem.

Sure, the insider has a broader access and thereby is more dangerous. He or she may also be the unknown victim of an attacker - a phishing email, a compromised USB stick, an infected laptop... you have to protect the internal network even better than the perimeter, because the attack surface is usually larger :-)

What about disgruntled employees, idiots and stalkers (we investigated one trying to access the emails of a colleague he got a fancy for), people trying to steal information for money or activism.

There may be some attempts to put passwords on some things, but going
all in encrypting all network traffic is fairly rare in non classified
places.

Why not? Don't you use SSL/TLS internally also (or other secure protocols)? Once you're inside you can try to employ different techniques to capture and analyze network traffic, even not directed to the compromised machine. If some password are transmitted in cleartext (HTTP basic authentication is very dangerous, for example) someone can intercept them and see if they are also reused on more secure and valuable systems. There could be sensitive information transmitted, some also protected by the law, which could put you (you meaning the person responsible for the data) in trouble if accessed by unauthorized people.

Only Embarcadero believed that a "subnet" (for the Embarcadero definition of subnet, which is not actually correct) was a security boundary (AppTethering...). Or that traffic sent with a common, static pre-shared key is safe...

So the moment an attacker is inside, he/she is able to cause havoc most
places, regardless of preventing SQL injection etc. in apps. They just
circumvent.

The less the internal network is protected, the easier for an intruder to access valuable data and exfiltrate them. We can do a lot to make that hard, slow and detectable. If we just surrender now because we believe once their in there's nothing to do, we've already lost :-) Each application security - from design to implementation must be as much secure as it can, and it really doesn't matter if it used internally or at the perimeter.

And remember, a clever attacker will look for less protected systems, even if regarded of "little value" to gain valuable intelligence to attack the valuable ones (user names and roles, accounts, password, documents, relationships among users, whatever can help to mount a more sophisticated attack).

It just needs a lazy user reusing passwords across systems, for example. If on the valuable system that user is correctly limited, the damage can be limited also, and easier to spot. If that user, as everybody else, once connected has "god privileges", because coding is easier, and after all, it's just an internal app, good luck....

Let's not blame Java for being insecure, when our code is not. Just the fact we weren't p0wned yet means little.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 5:01 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

It was required an independent developer to replace
it with a more modern one.

Do I sense some kind of NIH syndrome here?

--
Rudy Velthuis http://www.rvelthuis.de

"I find that most men would rather have their bellies opened
for five hundred dollars than have a tooth pulled for five."
-- Martin H. Fischer
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 5:53 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Do I sense some kind of NIH syndrome here?

?

I'm happy Pierre le Riche wrote it and made it available.

I was just writing BorInCodeEmbIdera was too slow to improve and update basic building blocks, in this case one crucial for performing applications. If a single (yet skilled) developer could create a better memory manager (for free), why paid (with our money) Delphi developers couldn't?

It's not good PR when you ask $$$$$ for a tool, and then you have to look for someone else free code to improve it really. Just chasing new lines to embellish the "feature matrix" may not be so smart

It's hard then to complain about the Java or .NET GC, when the makers of Delphi didn't care about their memory manager (and the first implementation of ARC was dreadful as well).
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 16, 2016 12:44 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Do I sense some kind of NIH syndrome here?

?

NIH = Not Invented Here.

http://www.webopedia.com/TERM/N/not_invented_here_syndrome.html

I'm happy Pierre le Riche wrote it and made it available.

I was just writing BorInCodeEmbIdera was too slow to improve and
update basic building blocks

This naming is pretty childish. Just use their real name.

No, they are not. They just don't write everything themselves and
acquire good solutions from others.

--
Rudy Velthuis http://www.rvelthuis.de

"There are two ways of constructing a software design; one way is
to make it so simple that there are obviously no deficiencies,
and the other way is to make it so complicated that there are no
obvious deficiencies. The first method is far more difficult."
-- C. A. R. Hoare
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 16, 2016 6:12 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
NIH = Not Invented Here.

I know what it means the question mark was about why do you believe I have that "syndrome"

This naming is pretty childish. Just use their real name.

I like it, it tells what mess they became, and make people like you upset :-P

No, they are not. They just don't write everything themselves and
acquire good solutions from others.

Well, one thing is acquiring new technologies to expand a product, another is not being able to invest and develop core ones, and being forced to adopt external ones when you're found pants down. I could have understand it if Delphi already had a good MM, but suddenly a new, outstanding one appear. Good, go and get it. Another is when you stubbornly refuse to invest in your own product, and when users start to use somebody else tool, you eventually notice it and adopt it - still FastMM has only basic support in the RTL and the IDE, you need to download yourself it, and tailor the INC files if you want to exploit it fully. Never understood why you can't also configure it from the project options. Too much work?

What would you think if Microsoft adopts the Linux kernel for Windows? Would you trust it as an operating system supplier, if it can't develop a kernel? People still laugh at it because it was forced to lift BSD code to add TCP/IP support to Windows - the message was "we had no clue how to implement networking".

Or if Oracle adopts Postgres engine for its database? But it looks you trust a development tool maker that can write nor a compiler, nor a memory manager. And just becomes a reseller of tools developed elsewhere.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 16, 2016 7:50 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

NIH = Not Invented Here.

I know what it means the question mark was about why do you believe I
have that "syndrome"

Because you keep complaining about their use of not in-house code.

This naming is pretty childish. Just use their real name.

I like it

No doubt. It remains childish, though.

--
Rudy Velthuis http://www.rvelthuis.de

"Those who see and feel beyond illusion have acquired a far
greater gift than could ever be derived from studying scripture
and philosophy books, for these were meant only to guide the
blind."
-- Shawn Mikula
Roberto Icardi

Posts: 4
Registered: 7/7/01
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2016 6:04 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis (TeamB)" ha scritto nel messaggio
news:858047 at forums dot embarcadero dot com...

Luigi Sandon wrote:

NIH = Not Invented Here.

I know what it means the question mark was about why do you believe I
have that "syndrome"

Because you keep complaining about their use of not in-house code.

This naming is pretty childish. Just use their real name.

I like it

No doubt. It remains childish, though.

Matter of taste. Someone might might find childish a strenuous defense of
the Borland/Codegear/Embarcadero/Idera position to death no matter of the
arguments.
--
Rudy Velthuis http://www.rvelthuis.de

"Those who see and feel beyond illusion have acquired a far
greater gift than could ever be derived from studying scripture
and philosophy books, for these were meant only to guide the
blind."
-- Shawn Mikula
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2016 11:19 PM   in response to: Roberto Icardi in response to: Roberto Icardi
Roberto Icardi wrote:

This naming is pretty childish. Just use their real name.

I like it

No doubt. It remains childish, though.

Matter of taste.

No, matter of upbringing.

Oh, and you might want to learn how to quote. Your message looked like
mine.
--
Rudy Velthuis http://www.rvelthuis.de

"You exist only in what you do."
-- Federico Fellini
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 5:57 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Den 6/15/2016 kl. 12:33 skrev Luigi Sandon:
Java adopted a given model, and we all know the differences among manual management, ARC and GC. Just, like all GCs are not equal, nor are memory managers. For a long time Delphi came with an outdated memory manager. It was required an independent developer to replace it with a more modern one. Delphi often hides dust under the carpet, and strive for new shining features (often not well implemented), instead of fixing and replacing outdated but basic features.

Actually so did Java. Java's originally didnt have a performant GC'er,
nor a particular good JIT'er.
However 3rdparty implenentations of Java did introduce those things, and
it eventually moved into the core code. IBM (again ;) was one of the
companies throwing lots of money after improving Java, and their Java
implementation was for several years far ahead of the Sun (or other)
version of it, in terms of GC and Jitting performance.

You can get an awful long way in Delphi without any 3rdparty libraries,

Are you sure? Actually, to develop any decent application in Delphi I can barely use the compiler, part the RTL, and the basic VCL classes - almost everything else need to come from 3rd party libraries - the GUI, the database libraries, encryption, networking, charting... without them Delphi offered too little (and often buggy).

I suppose we may need a definition of 3rdparty here....

- GUI.. There is apt support for GUI development in Delphi and has been
for many years. Its customizable too and always has been. Sure, there
exists thirdparty grids or componentsets that are really good at their
"thing", but its not the same as to say that its not possible to use
what is in the original SKU.

And regardless of peoples constant bashing for Firemonkey, I am actually
quite capable (and has been since even before it was introduced in XE2)
to use it for creating a very responsive application with some eyegloss
and loads of functionality for its segment.
Only now Im moving from XE2 to 10.1 in that application, because my XE2
dont play well (IDE wise) with Win10.

Database libraries: There has for years been pretty decent database
libraries in Delphi. Sure you could go to 3rdparty to get even better or
even more complete support for various (often less used) details in the
specific database, like query cancellation, callbacks etc.
But I dont really see that Delphi has not (since D3) been able to
connect to the most important databases and operate them in a
client/server manner.
The mess I suppose there has been, is that the API has changed 3-4 times
over the years, which ment a partial rewrite of parts of your
application (depending on isolation level of the changed components) if
you wanted to use the latest nad greatest. And the support for older
technology has been included in every release since its inception
lessening the immediate burden of changing code right now.

The Delphi TDataset idea has been mimicked and copied in both .Net and
Java. In .Net with I think fair success, and in Java with imo much less
success.

Encryption: You have a point here. There is not much included in the
SKU, except using WinAPI or resorting to 3rdparty components.

Networking: I dont agree. Actually Delphi have had native socket support
for many years even without Indy. And with Indy (which is a 3rdparty
library, but included in the SKU and thus not needed to be downloaded
from elsewhere), you actually have quite nice support for networking.
People have been busy bashing Indy for years, but in fact its a pretty
stable product with quite alot of functionality and support for many
protocols. Are there better 3rdparty solutions for specific purposes?
Yes, but that doesnt make your argument valid.
Its perfectly possible to write networking applications in Delphi
without installing anything extra not included in the SKU.

Charting: Delphi has for years offeret TeeChart (which is a 3rdparty
component set, but which is included in the SKU and thus do not need
separate downloading and installation). TeeChart is imo comparable with
or better than most charting solutions out there for Java or Javascript,
although specially the Javascript solutions typically focus on eyecandy
and animation alot more than TeeChart.
Are there better 3rdparty solutions than TeeChart out there? For very
specific scenarios or extremely large datasets, yes. But for the
majority of usecases, the buildin TeeChart contains all and more than
most developers need.

Its interesting you dont mention another important thing, needed in a
very large percentage of use cases.... reporting.

Delphi have had support for reporting for many years, again via 3rdparty
solutions bundled with the SKU. Reporting in Delphi is imo out of its
league compared to anything else on any platform.
Most others have had to resolve to CrystalReports or other external
report libraries, or some obscure ones via Javascript and NodeJS.
But there is IMO nothing that comes close to what has been in Delphi, or
what is in Delphi today (FastReport).

You also dont mention windows service development. Java has nothing for
that. You have to use NSSM or some other pretty crappy solution, that
does not really integrate well with your java application, and with
which you risk dataloss on shutdown due to shutdown hooks are not
guaranteed to fire in Java. In Delphi you will always have access to
do something unless your operating system directly signal 9 your
application, which is a very last resort on Windows only to be used for
completely non responsive applications (gone into some deadlock mode
typically).

Im just saying that in the Java world, you cant make any of the
current applications without including some opensource 3rdparty library.

Depends on what you develop and with what budget. For example you can develop Delphi applications with almost no third party libraries, I really can't.

See above. I can guarantee you that I can develop any client/server
application in standard Delphi without any additionally downloaded and
installed 3rdparty libraries. Is it as much fun as when I choose to also
use for example kbmMW? No. But thats a personal preference.

Maybe the problem is open source related then :). Actually to some

Partly it is. You have "free" stuff that does what you need, you use it instead of developing it yourself, accepting compromises. If you had to "buy", you would choose more wisely and will anyway use less external code. Also commercial developers are usually more "conservative" and adopt more standards. Many FOSS projects may adopt something just because "it's new", and when you code not for money often you do for fun and to learn.

Agreed.

Its a design made IMO to foremostly be flexible in most conceivable
theoretical ways, more than pratical. The worldwide combined time lost

Java likes that approach. Also the push of other (fashionable) languages that put flexibility before speed (and often safety) has been strong.

We agree on that :) Which is one of the reasons for the original post I
made. That flexibility is in many situations too costly, but its often
just accepted by Java developers as "thats how things are", perhaps
because they might not know better?

It is true Delphi is often more practical. Just look at controls events handling :-) Anyway, Spring was ported to Delphi as well, because devs now like and want it.

Yes it has. Time will tell if it will play the same role in the Delphi
community as it does in the Java community. I doubt it, of good reasons :)

Thats a good word... fashion. That unfortunately drives alot of business

I know, but if other tools becomes utterly un-fashionable like Delphi became, it's then difficult to "sell" them in business. BorInCodeEmbIdera "marketing" never had a clue about it.

Yes. It is important to keep a product "attractive" on the looks of
it, to keep users coming to it, and yes there have been lots of blunders
on the way in the earlier days. I would however limit the acronym used
for blunders to BorInCode since what has happened since Embarcadero took
over has boosted my confidence in the future of Delphi.

The Inprise days were the "most expensive" days for the Delphi
community, and thats imo where they really dropped their pacifier and
started sucking on their toes.

Java despite its shortcoming is sustained by far better marketing. Isn't Embarcadero too using Jira now? Jira is written in Java.... and aren't these newsgroup running on a Java application too? Where are the Delphi competitors?

Java mental capital is no doubt much larger than Delphis today, and
thats hard to fight. However there were a time where Google were a non
interesting company and companies like Altavista, Lycos, Hotbot and
others were the top of the pop. That changed, and it can change again,
although I do not expect Embarcadero/Idera to make a Google :)

I dont think they are as such actually abandoning SOAP, but it might be

SOAP support has never been updated since a long time. For "abandoned" I mean "no longer actively maintained and updated", not "removed".

QC 130644, 124627, 66864 122209, 114476 and many more fixed bug reports
since 2008 indicates that they actually do maintain SOAP in Delphi.
http://qc.embarcadero.com/wc/qcmain.aspx?da=3007
There is also many open reports, which indicates that they have not gone
all in on focusing primarely on SOAP, but saying that its no longer
actively maintained is imo incorrect.

The bug was fixed AFAIK in a recent release, but back then I had to develop our software to drive the VMWare test system in another language.

So you have seen it fixed yourself, which means that it was maintained,
but unfortunately not fast enough for your development requirements.


spend your development money on the "new and MUCH improved stuff" that
the marketing gurus of the largest firms has (re)"invented".

And that's "fashion" again. Delphi is not immune from the "fashion driven development" - just doesn't take any real advantage from it, while others do.

Delphi has been more resistant to fashion things, which has both been
good and bad. I like the langauge to be stable in such sense that you
can continue to use older code without having to spend time in rewriting
things, just to match with a new version of the compiler.
It has unfortunately also meant that some syntactical sugar which is
realy not as such needed, but which would be nice to have, has often
come later to Delphi than other major programming languages.

Id like to see Embarcadero be slightly more aggressive in making useful
syntactical sugar (coming with something truely useful before similar is
put into Java or C#), however only if it can happen without sacreficing
backwards compatibility.

There's a lot of half-implemented stuff in Delphi which has been the "new stuff" for a while just to be quickly abandoned as soon more "new stuff" became fashionable.

I only slightly agree. What I agree on, is the changing database
components, where large improvements typically has come in the form of a
completely new component set. I dare to say that is ending now with
FireDAC, because its really not a bad library, and its actively being
worked on and extended.

About Midas/Datasnap and what it has been called during the years, then
I would agree that there exists much better general solutions (mine for
example ;) ), but it would still be wrong to say they have abandoned it.
They continue to invest in it and add new features. They have a long way
imo to get to the stage where kbmMW is at though....But I may be biased
in that opinion ;)

Sometimes "chasing the market" is correct, sometimes is not. You need a sound plan on how to evolve, understanding your environment. Jumping like a mad frog to catch any new fly won't help your product sales, and won't help your customers.

I agree that the investments in other platforms like PHP, Ruby etc. in
hindsight was not good ideas. The investment in a a C# IDE may also not
have been a good idea. Those money would have been better spend on their
core business (C++ and Delphi).
It it however much easier to see the right choises to be made... after
the fact.

Open Source illness ;)

Every team, or even single developer creates software on its own for its needs, and publish it. Without a "centralized" management, is inevitable that X uses XML files, Y uses YAML, Z uses an INI like syntax, while another creates its own standard. For many people "free" is more important than anything else :-)

But its messy to be forced to have to deal with all those configurations
in one application. I dont see many Delphi applications suffering from
that sickness.

Why do you believe so?

Because Delphi would be more apt to write a web server then a web application. Not that it can't serve web pages, and surely he can be much faster than PHP or Python, just how web applications are designed, deployed and maintained, other languages are better suited to create them.

I don't believe a single language/tool should be used everywhere and for everything. IMHO there are tools better suited for some tasks, but not for others.

Yes.. .why imo web site templates should be made with a designer tool,
like Wysiwyg Web Builder or Dreamweaver or something even more cool.
Then it really doesnt matter what is serving the template. Delphi can do
that just as well as anything else.

remember correctly). And the script can even be compiled to native code
before execution, or you can choose to run it interpreted.
www.PaxCompiler.com - I seem to remember they had a template parser

Just, this is not really "Delphi" itself. They are tools supporting a Delphi-like syntax, developed outside Delphi "standardization", by small companies on their own. They can be technically outstanding, but they will be perceived as "risky", with little support and difficult to maintain for lack of developers. Thereby many people will just use Java.

I agree on the perception of things. That directs plenty (often in the
wrong direction).
Just remember at one time JSP was nose wrinkled at also, because one had
Java Servlets. Today its the defacto standard in Java for writing web sites.

Writing Web sites is less about whats serving the pages, and more about
the Javascript you put into them to make the appeared response time and
functionality application like.

Depends on the application. There are some with complex server-side processing, with modules that can even be built using different technologies. Right now I'm working on an application which uses a relatively simple Python based web frontend and backend (on Linux). The backend interfaces with an external application written in .NET (on Windows), and an analysis engine written in C++ (on Linux) which does the heavy processing. Delphi is still used for the analysis engine management GUI. We could have deve
loped the GUI in Java or .NET also, but I have Delphi developers sitll around, and Developer Express still allows for some nice GUIs :-)

Cool. Since a requirement was that it should run on Linux, then it
obviously makes sense not to use Delphi for other parts. And there may
be some C++ libraries used for analytics, that does not exist in Delphi
either, so there it makes sense to use another tool for the job.

My original post was however about something that could be done faster,
better, more efficient etc. using Delphi than using defacto standards
with Java.

There one could argue that Delphi could be made the right tool for
the job, specially when Linux support comes and specially if it targets
most interesting Linux platforms at some point.


scriptkiddies tends to penetrate a fairly large amount of sites using
non Delphi development tools, on a regular basis.

Many of those sites have unpatched systems with known vulnerabilities. Easy to pierce.

Yes, because they were originally designed with vulnerabilities due to
crappy coders and the mentality of which these coders work on such
projects. Many of the products need not have tnose vulnerabilities from
start because they have been known for years before.

Probably right now sites developed with tools little known and which were never inspected for vulns may look more secure. But are they really? Windows Mobile phones are "more secure" because they aren't a target for malicious apps, being so few. Most attacks are against Android and iOS. What smartphone do you own?

Ive got both IOS and Android around here, and I agree, both are from a
security standpoint horrible. Not necessarely because of intrusions from
3rdparty, but because of their datasharing policies with Apple/Google.

inside the perimeter in most companies, then you basically have access
to everything, its network, its file shares, its databases, USB ports of
PCs etc.

No. In most companies everybody doesn't have access to everything. If it happens, they have a problem, a big problem.

Check your network. Is it encrypted? Check your USB ports... are they
accessible? Do you use Wifi for your communication (plenty of companies
do)? Is your PC's bolted to the floor in a cage which means the PC cant
be opened nor stolen? Do they use mobile devices, tablets, phones etc.
to forexample read their email, login to corporate sites, vpn solutions
etc?

Behind the perimeter (or when somethign from behind the perimeter is
moved outside the perimeter... like mobile devices), everything is
possible unless you go to extremes to protect your site. The majority of
companies really do not do that. They focus on their core product, and
to develop it, they require knowledge sharing, and to do knowledge
sharing they need to spread information on multiple computers (at least
temporarily).

They may have firewalls, even introspecting ones installed. But do they
actually have at least 1 person 100% assigned to only looking at
connection logs and data inspection to see if there is a potential
breach from inside out from a keylogger or something?

Most dont.

Heck read this fresh post:

http://incolumitas.com/2016/06/08/typosquatting-package-managers/

See the organizations affected by this experiment. Both mil and gov ones
(who are supposed to "be experts" in security, are affected by it.

What about disgruntled employees, idiots and stalkers (we investigated one trying to access the emails of a colleague he got a fancy for), people trying to steal information for money or activism.

The disguntled employees are the most dangerous of all. They count for
the absolute majority of all data losses and security breaches.

There may be some attempts to put passwords on some things, but going
all in encrypting all network traffic is fairly rare in non classified
places.

Why not? Don't you use SSL/TLS internally also (or other secure protocols)? Once you're inside you can try to employ different techniques to capture and analyze network traffic, even not directed to the compromised machine. If some password are transmitted in cleartext (HTTP basic authentication is very dangerous, for example) someone can intercept them and see if they are also reused on more secure and valuable systems. There could be sensitive information transmitted, some also protected by the law, whi
ch could put you (you meaning the person responsible for the data) in trouble if accessed by unauthorized people.

Thats simply not the norm in most places. They install the equipment,
pull the cables etc. But they dont configure the equipment with
certficates and encryption unless they are made aware about that is
important. And even then, should they spend time, energy and money on
the product they plan to make money off or are making money from, or on
something that really doesnt pay their bills on the short term.

Thats a simple calculation many companies make, and the result is that
internal security comes later... when we have time.

Only Embarcadero believed that a "subnet" (for the Embarcadero definition of subnet, which is not actually correct) was a security boundary (AppTethering...). Or that traffic sent with a common, static pre-shared key is safe...

No.... not only Embarcadero has done so... Thats actually the norm..
unfortunately.

http://www.infoworld.com/article/3009667/security/millions-of-embedded-devices-use-the-same-hard-coded-ssh-and-tls-private-keys.html

http://www.theregister.co.uk/2015/11/26/lazy_iot_skeleton_keys/

http://www.theregister.co.uk/2015/11/27/nine_percent_of_encrypted_traffic_open_to_hijack_from_shared_keys/

https://www.schneier.com/blog/archives/2016/04/blackberrys_glo.htmhttp://www.theregister.co.uk/2016/02/11/building_automation_systems_so_bad_ibm_hacked_one_for_free/

https://www.wired.com/2015/12/juniper-networks-hidden-backdoors-show-the-risk-of-government-backdoors/

https://www.reddit.com/r/privacy/comments/3yinij/entire_us_voter_registration_record_leaks_191/

http://arstechnica.com/tech-policy/2015/04/meet-the-e-voting-machine-so-easy-to-hack-it-will-take-your-breath-away/

I could go on.... I wont ;)

Let's not blame Java for being insecure, when our code is not. Just the fact we weren't p0wned yet means little.

Sure... I didnt blame Java for being insecure. I blamed loads of open
source code, used by so many users around the world, written in Java to
be insecure.

best regards
Kim/C4D
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 7:26 AM   in response to: Kim Madsen in response to: Kim Madsen
- GUI.. There is apt support for GUI development in Delphi and has been

IMHO Delphi lacks many controls to deliver truly modern and appealing applications. I'm OK with that - deliver the basic one, let 3rd party add the rest. Just, properly support at least the basic OS widget set decently...

And regardless of peoples constant bashing for Firemonkey, I am actually

I will avoid to talk about FM....

Database libraries: There has for years been pretty decent database
libraries in Delphi. Sure you could go to 3rdparty to get even better or

Yes. The BDE and its SQL Links. dbExpress was a pain that ended only when dbExpress was replaced. It is full of bugs and missing functionalities. It was a true shame it could be part of a so expensive product.

even more complete support for various (often less used) details in the
specific database, like query cancellation, callbacks etc.

dbExpress in XE2 can't call a MySQL stored procedure with parameters... while SQL Links for Oracle 8 did support a lot of then advanced features (i.e. nested tables).

In Java at least you get JDBC drivers from the vendor, which usually support a lot of the target database.

you wanted to use the latest nad greatest. And the support for older
technology has been included in every release since its inception

No, SQL Links were removed.

Networking: I dont agree. Actually Delphi have had native socket support

Deprecated. And just plain, outdated sockets.

for many years even without Indy. And with Indy (which is a 3rdparty

Indy is a 3rd party library still alive for the great work of Labeau. Bundling 3rd party apps doesn't make them "native" ones. And usually you need to download and install an updated one.

Charting: Delphi has for years offeret TeeChart (which is a 3rdparty

Again, a bundled 3rd party. You need anyway to buy the full library if your charting needs goes beyond the basic one included.

or better than most charting solutions out there for Java or Javascript,

AFAIK TeeChart is also available for Java... while if you look for a graph generator you'll find a lot of libraries for Java and nothing for Delphi.

Its interesting you dont mention another important thing, needed in a
very large percentage of use cases.... reporting.

True. Something I've not been using for years. Bundled solutions changed a lot, and if you depended on what was bundled, you had to update them often...

You also dont mention windows service development. Java has nothing for

I mentioned it before. Java is cross-platform. And usually you don't write a Java server application from scratch. You'll use an application server to host your code.

Delphi Windows service support is outdated, doesn't support Vista+ features, barely adequate, and uses some objectionable techniques (i.e. the message pump used to communicate from the service handler function).

See above. I can guarantee you that I can develop any client/server

Probably. How much appealing it is is another question :-)

just accepted by Java developers as "thats how things are", perhaps
because they might not know better?

If everybody does that, most designers and developers will just "follow the stream". Look at how many Java-ism and .NET-ism you find in Delphi libraries today. There was some comments on a Cantù post on how attributes syntax was lifted from .NET with no attempt to fit it into a true Pascal syntax. Think about the discussion regarding strings encodings support, and immutabililty.

for blunders to BorInCode since what has happened since Embarcadero took
over has boosted my confidence in the future of Delphi.

IMHO much of what I wrote before happened exactly when Delphi went to Embarcadero. Developers leaving (now again), offshoring... Idera is a DB tools company and didn't want to put its name on Delphi. Hope it has great plans anyway. But the true issues - the wrong people - are still there.

actively maintained is imo incorrect.

Many WS* standards are not supported.

So you have seen it fixed yourself, which means that it was maintained,
but unfortunately not fast enough for your development requirements.

Years later is not fast enough. Yes.

Delphi has been more resistant to fashion things, which has both been

No, actually it wasn't enough. Look at all the .NET story. Or Kylix. Will xplat and mobile pay? It looks it doesn't much. The license changes, the price model changes, all hints at a product that struggle to sell. So people go Java instead :-(

Id like to see Embarcadero be slightly more aggressive in making useful
syntactical sugar (coming with something truely useful before similar is
put into Java or C#), however only if it can happen without sacreficing
backwards compatibility.

I'm more afraid of that. Beware of Java-ism and .NET-ism in Delphi. They could be very, very dangerous. Delphi has to evolve, not to copy, and especially not to ape. The language changes must be planned inside a well thought evolution of the language itself inside its characteristics, not because language X has that and Y too. Who is in charge of the language today? Java language specifications have a formal process, which may be slow, but at least is a process. It's discussed, and you know what will happen.

It it however much easier to see the right choises to be made... after
the fact.

Read my posts of the time... ;-) It wasn't difficult to see.

in one application. I dont see many Delphi applications suffering from
that sickness.

Wait for a Linux compiler... <G> On Windows, there is less variance. But I've found applications using a mix of XML, INI and registry settings.

Just remember at one time JSP was nose wrinkled at also, because one had
Java Servlets. Today its the defacto standard in Java for writing web sites.

Yes, but you still have an "official" standard supported across different vendors. Or you are Microsoft and can force asp.net, or you have an hard time to force another technology. You have to find a broad support like PHP or Python did, but it's difficult with a closed source - and expensive - tool.

Cool. Since a requirement was that it should run on Linux, then it

Linux is often a requirement server side. Borland made the wrong move with Kylix. It was blinded by desktop apps for Linux, when Linux grew mostly as a server-side OS. Java too attempted to target the desktop, but soon found its place on the server side - and a lot of required support was added.

My original post was however about something that could be done faster,
better, more efficient etc. using Delphi than using defacto standards
with Java.

See we use no Java? :-D It was proposed but then refused, mostly because uselessly complex for the part which was developed in Python. In other situations, for example if Oracle has been involved, I could have made a different choice.

But we couldn't use Delphi either but for a small part, and only because it was OK to run the management client on Windows machines only (nor macOS was an option).

most interesting Linux platforms at some point.

It has to compete with GCC and the large number of C/C++ libraries available under Linux. And cope with the distro nuisances. It is true that it's down mostly to redhat/debian compatible ones today. But there could be still differences (i.e. Debian with its very conservative approach, and Ubuntu) to handle.

Java is partially shielded, but not so much. That's why also you may have to download a lot of custom dependencies to make something run...

Yes, because they were originally designed with vulnerabilities due to

Don't bet too much on Delphi in this regard. A lot of older code was designed without much security in mind.

Check your network. Is it encrypted?

Yes,

Check your USB ports... are they accessible?

On my machine, yes, because I'm authorized. On others they are locked down.

Do you use Wifi for your communication (plenty of companies

No. WiFi is forbidden here.

Is your PC's bolted to the floor in a cage which means the PC cant

No, but access is restricted here.

Do they use mobile devices, tablets, phones etc.

Only authorized company phones can access email. I have a VPN with two factor auth using an RSA device.

companies really do not do that.

That's why you see big leaks or even worse (i.e. Sony...) in the news... they should do it really, today.

No.... not only Embarcadero has done so... Thats actually the norm..
unfortunately.

No, among the professional development tools industry it is more an exception than the norm. It didn't take the effort to fill the papers for encryption export, and just deliver a known weak encryption algorithm (the short key RSA one), and an utterly unknown one (PC1). It's putting customers at risk, if they are not aware of that. It would be better to deliver nothing, and tell customers were to find the correct ones (or wrap the OS ones, so you don't export nothing).

I could go on.... I wont ;)

Those are applications, not dev tools. I expect far more quality from a dev tool, especially when it costs thousand of dollars.

The issue is when the dev tool itself - which should be coded by more skilled developers - has basic design flaws. Then if you leave most developer implement their own security, they will almost always make very dangerous mistakes too. Especially when they need to code for a $29.99 router, maybe.

Security if one of those areas where there are very few ways (if not only one) to do something right, and many, many ones to do something wrong. You have to rely on sound tools made by competent developers.- plus awareness and training for yours.

Sure... I didnt blame Java for being insecure. I blamed loads of open

No, Java has been (and may still be) insecure itself. It takes little to make a mistake which can be exploited to attack a system. Some C/C++ compilers for example have switches to perform some checks i.e. on stack "corruption". AFAIK, Delphi has none. In VC++, Microsoft is replacing a lot of functions with safer ones. Delphi sometimes is shielded by its own specific architecture from some issues, but I never saw an effort to assess and fix the attack surface.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 9:24 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 15.06.2016 um 12:33 schrieb Luigi Sandon:

You can get an awful long way in Delphi without any 3rdparty libraries,

Are you sure? Actually, to develop any decent application in Delphi I can
barely use the compiler, part the RTL, and the basic VCL classes -
almost everything else need to come from 3rd party libraries - the GUI,
the database libraries, encryption, networking, charting... without them
Delphi offered too little (and often buggy).

Database libraries? Have you looked at FireDAC?
Looks good enough for me. Supports most databases and often enough more
than just SQL access, e.g. backup and restore as well.

Greetings

Markus
Luigi Sandon

Posts: 353
Registered: 10/15/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 1:54 PM   in response to: Markus Humm in response to: Markus Humm
Database libraries? Have you looked at FireDAC?

FireDAC is a fairly recent acquisition. For years we've been left with dbExpress. Thus you learnt to not trust Delphi, and use something you can trust over time. But I hope FireDAC stays and delivers.

But JDBC drivers usually come from the database vendors directly, with FireDAC you have to hope support is added by Embarcadero itself. Which has strange ideas about database support unless you pay a lot ;-)
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: A case for Delphi [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 16, 2016 9:06 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 15.06.2016 um 22:57 schrieb Luigi Sandon:
Database libraries? Have you looked at FireDAC?

FireDAC is a fairly recent acquisition. For years we've been left with dbExpress. Thus you learnt to not trust Delphi, and use something you can trust over time. But I hope FireDAC stays and delivers.

But JDBC drivers usually come from the database vendors directly, with FireDAC you have to hope support is added by Embarcadero itself. Which has strange ideas about database support unless you pay a lot ;-)

Hello,

when I was still studying I did something in Java using a JDBC driver
which came along with Java itsself. It was for MS Access. in the middle
of the project I found out that there was some documentation stating
that this driver was for demo purposes only and not for production code!
Yuck!

It immediatelly started to randomly fail on computers running Windows
2000. Luckily the university was still on NT4 where the application
worked flawless. On W2000 it sometimes simply threw the DB cursor away
and next line in the log was a complaint about not having a DB cursor... ;-)

Greetings

Markus
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 11:34 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Reality is that most general Java users almost never looks into
chooing a better algorithm, or optimizing code. They have by their
schooling

Not that Delphi too shines in this regard... remember when FastCode
routines had to be brought in to cover the deficiencies of Delphi
RTL? Knuth's book are no longer a "mandatory" read <G>.

The FastCode tricks go well beyond Knuth's algorithms. I don't know if
you ever read their source code, but they use every trick that exists,
like jumps into the middle of loops, bit fiddling, etc.
--
Rudy Velthuis http://www.rvelthuis.de

"I criticize by creation - not by finding fault."
-- Cicero (106-43 B.C.)
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 1:15 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
The FastCode tricks go well beyond Knuth's algorithms. I don't know if
you ever read their source code, but they use every trick that exists,
like jumps into the middle of loops, bit fiddling, etc.

I know. But the rule is 1) Use the correct and fastest algorithms you can use 2) Then optimize the code for the underlying architecture (if the compiler can't). Knut is all about the algorithms, he doesn't treat platform-specific and architecture-specific optimizations. Of course optimizing naive algorithms in assembly is of little use.

While 1) is quitestable in time, unless new faster algorithms are developed, not so common today 2) may change as new architectures are introduced.

Delphi RTL often failed in both - it used (and still uses) naive algorithms, and lacked optimizations. We've seen it in the IDE too, where Hausladen has been able to greatly improve performance patching it with better code.

Also, because FastCode routines were written for 32 bit CPUs, AFAIK they are no longer used in 64 bit libraries.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 4:41 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

The FastCode tricks go well beyond Knuth's algorithms. I don't know
if you ever read their source code, but they use every trick that
exists, like jumps into the middle of loops, bit fiddling, etc.

I know. But the rule is 1) Use the correct and fastest algorithms you
can use 2) Then optimize the code for the underlying architecture (if
the compiler can't). Knut is all about the algorithms

But not such hackish tricky algorithmas as FastCode uses. This is
something not so many people can actually achieve. I don't expect a
compiler runtime developer to take lots of time to think up these
tricks. Such code grows, and in this case, they used already existing
highly optimized code from a third party, that's all.

--
Rudy Velthuis http://www.rvelthuis.de

Goebel's Second Law Of Useless Difficulty: The fastest way to get
something done is to determine that it isn't worth doing.
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 6:01 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
compiler runtime developer to take lots of time to think up these
tricks. Such code grows, and in this case, they used already existing
highly optimized code from a third party, that's all.

While a human can probably still optimize some code better than a compiler, you do expect (high-end) compilers being able to perform many optimizations for the target CPU(s). Good compilers developers actually spend a lot of time to optimize their code generators. Mean ones hope users won't notice and accept less optimized ones.

While hand-optimized code is static, if the optimizations are performed by the compiler, when a compiler is updated to exploit newer CPUs, recompiled code may take advantage of new optimizations (and avoid issues that could appear).

FastCode developers made an excellent work back then, but AFAIK that code is not maintained nor upgraded.
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 6:08 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Hi,

But the norm of today is to be able to write a line of code, and run it
immediately, which is why PHP, Perl, Ruby, Javascript are so successful.
A really good optimizing compiler still takes quite a number of CPU
cycles to compile anything... one reason (not the only) for the
slowliness of CLANG/LLVM and even slower other C/C++ compilers.

Delphi is in the middle, with a lean towards being almost instant to
compile, when you wnat to try out your latest change of line.

This is a tradeoff. I suppose it would be very nice to have a "final
production" compiler which could spend a very long time over the
compilation to get the most efficient code out of it, but it all costs
money to implement.

FastMM has been upgraded several times, and I think it came from the
FastCode project originally too.

best regards
Kim/C4D

Den 6/15/2016 kl. 15:01 skrev Luigi Sandon:
compiler runtime developer to take lots of time to think up these
tricks. Such code grows, and in this case, they used already existing
highly optimized code from a third party, that's all.

While a human can probably still optimize some code better than a compiler, you do expect (high-end) compilers being able to perform many optimizations for the target CPU(s). Good compilers developers actually spend a lot of time to optimize their code generators. Mean ones hope users won't notice and accept less optimized ones.

While hand-optimized code is static, if the optimizations are performed by the compiler, when a compiler is updated to exploit newer CPUs, recompiled code may take advantage of new optimizations (and avoid issues that could appear).

FastCode developers made an excellent work back then, but AFAIK that code is not maintained nor upgraded.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 16, 2016 12:40 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

compiler runtime developer to take lots of time to think up these
tricks. Such code grows, and in this case, they used already
existing highly optimized code from a third party, that's all.

While a human can probably still optimize some code better than a
compiler, you do expect (high-end) compilers being able to perform
many optimizations for the target CPU(s).

Yeah, like the Intel compiler. Fact is that runtime library
optimizations like FastCode are not nearly the same as normal runtime
design.

--
Rudy Velthuis http://www.rvelthuis.de

"The only one listening to both sides of an argument
is the neighbor in the next apartment" -- unknown
Vladimir Ulchenko

Posts: 248
Registered: 1/12/00
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 1:40 AM   in response to: Luigi Sandon in response to: Luigi Sandon
On Tue, 14 Jun 2016 12:23:09 -0700, Luigi Sandon <> wrote:

Not that Delphi too shines in this regard... remember when FastCode routines had to be brought in to cover the deficiencies of Delphi RTL? Knuth's book are no longer a "mandatory" read <G>. It's not limited to Java.

even Knuth's books are not recipe for success

let me quote Henrique Bucher:

"The main takeaway is that it is essential for very large applications to adopt data structures that maximize performance of memory cache
and it is very important to write and test every possible alternative to understand this behavior as the impact of cache often flies in view
of the traditional academic Big-O studies.

Writing high performance algorithms is nowadays not much of a task of knowing data structures from a textbook. It is instead more of a task
of laboriously generating every possible implementation and testing each and every one of them ad nauseam.

The results very often surprise the most seasoned of the technologists"

--
Vladimir Ulchenko aka vavan
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 3:51 AM   in response to: Vladimir Ulchenko in response to: Vladimir Ulchenko
Vladimir Ulchenko wrote:

"The main takeaway is that it is essential for very large applications to adopt data structures that maximize performance of memory cache

Which is part 2) above, and depends often of what control you have on the deployed application. If I'm working on a dedicated HFT system I can surely optimize it down to the specific CPUs and memory architecture used (i.e. NUMA) - I'm sure nothing else will interfere, I can spec the hw as needed, and I can extensively test all the implementations.

If I just sell an application for which I can't control much how and where it gets deployed, and how much "competition" there will be for the host system resources, very specific optimizations may not work as intended.

Anyway today the art of computer programming reference is Stackoverflow... people just copy the accepted or more voted solution, even when it's clearly wrong <G>
Arnaud Bouchez

Posts: 137
Registered: 8/2/15
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 15, 2016 3:56 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:
Anyway today the art of computer programming reference is Stackoverflow... people just copy the accepted or more voted solution, even when it's clearly wrong <G>

Yes, I hate this "paste and pray" programming style, you can easily recognize in production code sometimes...
Mike Margerum

Posts: 590
Registered: 12/1/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 18, 2016 6:47 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Excellent post!
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 20, 2016 6:55 AM   in response to: Mike Margerum in response to: Mike Margerum
Mike Margerum wrote:

Excellent post!

A short quote would have made it much easier to see to which post you
are replying. Now I have to follow the (large) message tree to find out.

--
Rudy Velthuis http://www.rvelthuis.de

"Theory is when you know something, but it doesn't work. Practice
is when something works, but you don't know why. Programmers combine
theory and practice: Nothing works and they don't know why."
Adem Meda

Posts: 495
Registered: 12/28/98
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 20, 2016 9:34 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

A short quote would have made it much easier to see to which post you
are replying. Now I have to follow the (large) message tree to find out.

XanaNews needs a button for 'Find Parent Post'.
John Treder

Posts: 349
Registered: 8/2/02
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 20, 2016 10:33 AM   in response to: Adem Meda in response to: Adem Meda
Adem Meda wrote:

Rudy Velthuis (TeamB) wrote:

A short quote would have made it much easier to see to which post you
are replying. Now I have to follow the (large) message tree to find out.

XanaNews needs a button for 'Find Parent Post'.

Are you ready to taje it on, Adem? :)

--
John
Adem Meda

Posts: 495
Registered: 12/28/98
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2016 12:22 PM   in response to: John Treder in response to: John Treder
John Treder wrote:

Adem Meda wrote:

Rudy Velthuis (TeamB) wrote:

A short quote would have made it much easier to see to which post you
are replying. Now I have to follow the (large) message tree to find out.

XanaNews needs a button for 'Find Parent Post'.

Are you ready to taje it on, Adem? :)

John,

Unfortunately, my work on XN was interrupted by real life. But, when/if I get
back to it, I definitely will add it.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 21, 2016 2:39 AM   in response to: Adem Meda in response to: Adem Meda
Adem Meda wrote:

Rudy Velthuis (TeamB) wrote:

A short quote would have made it much easier to see to which post
you are replying. Now I have to follow the (large) message tree to
find out.

XanaNews needs a button for 'Find Parent Post'.

Yes, I fully agree. Perhaps Graeme has an idea?

--
Rudy Velthuis http://www.rvelthuis.de

Ryan's Law: Make three correct guesses consecutively and you will
establish yourself as an expert.
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 21, 2016 12:54 PM   in response to: Adem Meda in response to: Adem Meda
Adem,

| XanaNews needs a button for 'Find Parent Post'.

Great idea!

--

Q -- XanaNews 1.19.1.372 - 2016-06-21 12:54:11
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2016 9:04 AM   in response to: Quentin Correll in response to: Quentin Correll
Am 21.06.2016 um 21:54 schrieb Quentin Correll:
Adem,

| XanaNews needs a button for 'Find Parent Post'.

Great idea!

Hm? Does XanaNews lack the threaded view Thunderbird has?
Because that makes it easy to find the parent. Select the child and
press cursor left to go to the parent.

Greetings

Markus
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2016 11:19 AM   in response to: Markus Humm in response to: Markus Humm
Markus,

| Hm? Does XanaNews lack the threaded view Thunderbird has?
| Because that makes it easy to find the parent. Select the child and
| press cursor left to go to the parent.

Wow!

It also worked in my XN! I've used XN for years and never knew of that
functionality!

Thanks!!!

--

Q -- XanaNews 1.19.1.372 - 2016-06-22 11:18:04
Adem Meda

Posts: 495
Registered: 12/28/98
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2016 12:22 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Hm? Does XanaNews lack the threaded view Thunderbird has?
Because that makes it easy to find the parent. Select the child and
press cursor left to go to the parent.

That works too.

But, it closes the child-threads first and then, when you press left cursor
again, it goes to the parent.

Trouble with that is this: since XN does not have any breadcrumb functionalty
(browsing history), that I know of, you will have to hunt down from that parent
(to the node you went to it) manually. For long threads, this can be a chore.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: A case for Delphi [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 22, 2016 12:28 PM   in response to: Adem Meda in response to: Adem Meda
Am 22.06.2016 um 21:22 schrieb Adem Meda:
Markus Humm wrote:

Hm? Does XanaNews lack the threaded view Thunderbird has?
Because that makes it easy to find the parent. Select the child and
press cursor left to go to the parent.

That works too.

But, it closes the child-threads first and then, when you press left cursor
again, it goes to the parent.

Trouble with that is this: since XN does not have any breadcrumb functionalty
(browsing history), that I know of, you will have to hunt down from that parent
(to the node you went to it) manually. For long threads, this can be a chore.

Ah, TB doesn't collapse the subthread.

Greetings

Markus
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 13, 2016 7:26 AM   in response to: Luigi Sandon in response to: Luigi Sandon
Luigi Sandon wrote:

Ask yourself why they are using Java, then...

Probably out of convenience and laziness (everyone uses it, so why
don't we?) or massive plugging. And it is free (as in "free beer"), and
quite easy to use with, say, free NetBeans, which is great for students.
--
Rudy Velthuis http://www.rvelthuis.de

"The cry has been that when war is declared, all opposition
should be hushed. A sentiment more unworthy of a free country
could hardly be propagated." -- William Ellery Channing
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 13, 2016 12:41 PM   in response to: Luigi Sandon in response to: Luigi Sandon
Am 13.06.2016 um 15:06 schrieb Luigi Sandon:
- Memory performance
- Runtime performance

Nobody uses Java for that. Otherwise they will be using C or C++ (which has great cross-platform capabilities as well).

- Ease of testing

Mmmh, many testing techniques you're using in Delphi were born in Java, or appeared earlier in Java than in Delphi. There's always been a larger community of computer scientist and "methodologists" around Java than in Delphi.

Ask yourself why they are using Java, then...

I sometimes really do. A mostly general purpose language with lack of
unsinged integer types (ok, in Java 8 [in reallity it's Java 1.8] they
finally provide them now)? FOr me that's a joke. Yes you can work aound
that buit it's cumbersome and not something we should have had to do in
year 2000.

Greetings

Markus
Luigi Sandon

Posts: 74
Registered: 2/22/08
Re: A case for Delphi
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 6:20 AM   in response to: Markus Humm in response to: Markus Humm
I sometimes really do. A mostly general purpose language with lack of
unsinged integer types (ok, in Java 8 [in reallity it's Java 1.8] they

Given how many developers I've seen mixing signed and unsigned integers without thinking probably was deemed another "security feature" of Java <G>.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02