Jump to content

FreeDelphiPascal

Members
  • Content Count

    51
  • Joined

  • Last visited

Posts posted by FreeDelphiPascal


  1. On 4/16/2024 at 10:04 PM, Lars Fosdal said:

    Are there any practical languages that are applicable to writing the same variety of solutions as Delphi, that are actually memory safe?

    A solid question!

    I don't know all the languages out there, but Java and C# (which are more memory safe than Delphi because of their GC), loose quite a bit of speed because they have to spend some time to check the GC and decide what to clean up (release). EVEN if they would spend very little on this task, they have to "stop the world" from time to time. There is no way to use such a language in time-critical systems (I worked on such a system in the past).

     

    Therefore, these safer languages, have to pay a price for their safety. I am curious if there is any language out there that is as fast as Delphi and more memory safe.

     

    From what I heard, Rust is not using a GC, while still being fast and safe. I would like to see some speed comparison between Delphi and Rust. I heard that its speed is only slightly smaller than C++'s speed (and from here we can extrapolate to Delphi's speed). But its compilation time is even higher than C++ compilation time, which compared to Delphi... well... we all know how ridiculous C++ is at this chapter. 🙂

    Also, Rust cannot do GUI natively, like Delphi. So, you cannot even compare Delphi and Rust at this chapter. In Rust, you must opt for GTK, QT (ha ha ha) or do some web-based GUIs - with all their known drawbacks. So, I would say, Rust is more oriented towards "systems" (DB, servers, automations, embedded systems, robots, etc.) not towards desktop apps.

     

    So, as you Lars said, I would like to see a language that is memory safe and executes fast, and compiles fast and comes with 500 visual components out of the box.

     

     

    __________


    Note:

    Note: When I say Delphi is safe, I assume that the programmer played safe and didn't abuse the pointers and didn’t override Delphi’s strong typing system. I worked on a system that look like it was written by a C programmer. Procedures like DoSomething(var P); all over the place, and half of the parameters passed are raw pointers. But as somebody said above, give a bold programmer a safe language, and it would find a way to abuse it. It would take a bit more creativity than in Delphi which puts the pointers (almost directly) on the table, but sure you can screw up in the end.


  2. On 3/17/2022 at 9:05 PM, Anders Melander said:

    Nooooooooo! No. No. No. NO.

     

    1. Change the pixelformat to pf32bit
    2. Desaturate the RGB:

    But aren't you supposed in the end to put the PixelFormat to pf8????

     

    I need the final image as pf8. But if I set its PixelFormat to pf8, some wavy patterns appear in it (like when you convert a high color image to 256 color GIF)
     


  3. 4 minutes ago, Dalija Prasnikar said:

    But again, also it is not technically a bug in LLVM, but merely lack of certain feature, which is not so easy to add at this time.

    Yes. I totally understand and agree with that.

    Because of this, I went in my post above, and I changed the word "error" with "issue", to eliminate any interpretation. I like to be pedantic 🙂


  4. 23 minutes ago, Dalija Prasnikar said:

    It is language related, more precisely compiler related (LLVM backend).

    LLVM is not quite a programming language. So, you are right in a way: you could recover at the hardware level, but LLVM fails to do so. But then, let's not blame Delphi language itself for this.

     

    So, I would correct myself and say that the issue is between the hardware and the language, in the LLVM. Do you agree with this "technicality"? 
    🙂 


  5. On 3/8/2024 at 8:28 AM, David Schwartz said:

    ....

    So I really don't want to hear about all of the exceptions and reasons why it's important to shave 50 ms off of the execution time of some loop you may be working on. The last place I worked printed bills and invoices, stuffed them into envelopes, and sent them out to the US Post Office -- 7 or 8 full 40' semi-trailers EVERY DAY, 7 days a week. They got pissed off if part of a line on an invoice was cut off on a print run of 50,000 invoices; not whether it took an extra 15 minutes to run a given print job, as long as the people who got the materials could read them and they looked "professional".

     

    If customers didn't complain, that meant nothing was wrong. Nobody cared what we programmers might find.

     

    One thing I've found over the past 15 years is that Management is far more scared of allowing programmers to refactor code than just about anything else. Because trying to shave a few seconds of processing time often leads to bugs that did not exist previously. And yes, that's because they don't have comprehensive test suites (which are notoriously hard to write for form-based Delphi apps).

     

     

    Nice post David S!
    I had recently to fix a bug in a program that was sending wrong financial reports to a governmental financial institution (equivalent to RSI in America) for 18 years. After 18 years, somebody observed the problem. It ended up that there was not only one bug, like 15. Nobody ever observed the other 14 instances where data was wrong.

    I was told to shut up and move on. Also, nobody cared that my new program was running 100x faster than the previous one.

     

    I told them that probably there were another 100 bugs in there (pascal-like code, no objects, thousands of warnings and hints - at least, there were no pointers!). They wouldn't let me rewrite the program. They said, it now it works, let it as it is.

     

    So people, don't blame Delphi for not being totally memory-safe. It is mostly the programmer that dictates the safety of a language.
    I guess the programmer that wrote that program in Delphi would be able to sneak in some calamities like this also in a language like Rust.

    __________

     

    Also, many people complained about buffer overflow here. Turn on the damn Range and Overflow checking. It will catch a good bunch of those overflows - unless the devil thought you to use pointers all over the place.

    • Like 2

  6. On 3/7/2024 at 12:39 PM, Kas Ob. said:

    I mentioned or to be exact dreamed about more evolved Pascal enhancement, mentioned it here at once as i recall, but really can't remember any comments or any discussions.

    So will write it here as it is relevant for memory safety.

    My suggestion is to introduce new modifier(s) to managed (and non managed) variables, this include classes/objects, the new main modifier is "Auto", example

    
    procedure Test(aFileName: string);
    var
      SList: TStringList; auto;           // the compiler will ensure calling the default constructor and destructor
    begin
      //SList := TStringList.Create;      //  should stop the compiler with specific Error, you are not allowed to create an auto
      SList.LoadFromFile(aFileName);
      //SList.Free                        //  should stop the compiler with specific Error, you are not allowed to destreuct/free an auto
    end

    ..........

    Too much useless talk about this topic.
    But this guy (Kas Ob) came with real ideas/solutions. Great job Kas!


  7. On 3/1/2024 at 11:31 AM, David Heffernan said:
    
    obj := TObject.Create;
    obj.Free;
    obj.Free;

    Take that, NSA!

    obj := TObject.Create;
    FreeAndNil(obj);
    FreeAndNil(obj);


    ------------------------------

     

    On SO somebody wrote an example like this to prove how unsafe Delphi is:

      s: String;
      i: Integer;
    begin
      s:= 'four';  
      for i:= 1 to 1138 do begin 
        write( s[i] );  // What will it access after i=4?
      end;
    end;

     

    At one point, we should stop talking about how safe the programming language is and start talking about how "unsafe" is the programmer

    🙂

    🙂

    • Like 1
    • Haha 2

  8. On 12/1/2023 at 8:47 PM, Ian Branch said:

    I think I eventually discovered the same thing.  Too long ago now... 😉

    It is odd because background compilation worked until I reinstall Delphi (the same version!)


  9. On 12/1/2023 at 8:47 PM, Ian Branch said:

    I think I eventually discovered the same thing.  Too long ago now... 😉

    But it worked for me since ever, until recently when I installed Delphi fresh.
    Looks like there is some good dose of randomness in that installer 🙂


  10. On 12/7/2023 at 11:43 AM, Stefan Glienke said:

    You do realize that Java and C# are not interpreted like Python, yes?

    I did a test - Julia vs Delphi.
    Julia beats the crap out of Delphi.
    Some code executes 7 times faster!

     

    But on the other hand, it is true: You cannot deliver a Julia monolithic app to a customer - unless that customer installs Julia and some other stuff first.


  11. On 11/27/2023 at 9:07 AM, Dalija Prasnikar said:

    I think it got a bit further... we are somewhere in the Dark Ages...

    You are right, we are going through dark ages (I would also call them sad ages).
    So, when are we all going to sign a petition to Embarcadero and ask for a modern Delphi that does not crash every 10 minutes, it is not stuck in the 2000 and does not have the fart-smell of an 100 grandpa?
    We should all promise that we won't buy next version until they really really fix it.


    And we want a true road map.

    Embarcadero should understand that they don't own Delphi. They cannot do whatever they want and when they want. We are the customers.

     

    They cannot release 12 new tiny features and pretend it worth buying Delphi 12 just for that.
    I mean, come on! I would be ashamed to tell my users that in the next version they will be able to write text on two lines instead of one! This is not something even worth mentioning. Presenting this like a brand new shiny feature means
    "Hi Delphi guys,
    we full around last year, then we were busy to fix some bugs that were not supposed to be there, and improve the C++ which nobody uses anyway, so for you, we didn't have much time left,

    but at least we did this impressive feature that lets you split your string on two lines.

    PS: you have to pay for it.

    PSS: you have to pay also for the bug fixes!".
     

    Have you seen how fast are other languages advancing? Take a look at Julia! High level language BUT in some benchmarks it beats the craps out of grandpa Delphi.
    And its costs... nothing! Slap a nice IDE as VS Code on top of it, and you got a nice environment.

    Updates? Every few weeks.

     

    I am afraid to admit it, but I think I am (we all are) in love with what Delphi was in 95, when it was indeed cutting edge.
    Now we are all a bunch of gray beards and bold heads. No new blood to Delphi.

    I haven't heard of a single new startup company that uses Delphi.

    All the jobs around are offered by companies that started in 90-95 with pascal/delphi. All of them hove now 2 million lines of legacy code and a desperate need of Delphi developers.
    I know a few of them that never-ever take down the Delphi job position because it is never filled. Or if they find a good (and pretty old) programmer every 2-3 it is not enough to replenish the big number of old programmers that now are at the retiring age. For each new programmer they put their hands on, two retires. And as the "new" programmer is close to retiring age also, it only perpetuates the avalanche. Been there, seen that with my own eyes. I was the young one there, even though I am not that young anymore.

    You also see the lack of Delphi programmers when the job is announced as Delphi "slash" C++. They try to lure-in some C++ Builder programmers this way. Trick them into a Delphi position.

     

    I personally try to promote Delphi.
    But all my kids around me (nephews, friend's children, etc) are going with the cool wave. The old PHP is getting to be the new cool kid in the town now. Internet technologies. C#.
    I am not saying they are better. But they are definitively "cool". Embarcadero, with all its old guys there (good guys/programmers but not in touch with the new generation, with the new ways) and with its "get the money first - give the quality later" policy is not "cool". And cool is ******** important, because you don't lure in into the language old die-hard C or ASM gurus, you want to lure in kids.

    My kid is having more fun with Delphi than with Scratch. But I wouldn't put him on a Delphi-career path. Not with Delphi's featured being almost sealed.

     

    Embarcadero! The time to reverse the tide is running out! Delphi opportunity window is almost almost closed!
    I do see some efforts from Embarcadero (some blogs, some barely-voted youtube videos, some shy promotions), and in general Embarcadero is going into the right direction. But too slow. Waaay too slow.
    The biggest positive move was the Community Edition. I would have paid > 1000 euros to buy a license for my kid!
    (I still don't have words to say how dismayed I am that Emba didn't offer a free license until few years ago!!!!!!!!!!!!!!!!!!!!!!!!!!!)

     

    Wellllll.....

    In theory, I should shut up and relax, and fave fun with Delphi until my retiring age comes. I never ever had problems getting income with Delphi.
    But I love Delphi too much. It will be such a shame for Delphi to get retired the same day I retire!

     

    On 11/24/2023 at 10:35 PM, Darian Miller said:

     

    For myself, if I use that new feature it will only be used sparingly because, as usual, new language features break tooling.  Here are a few QP issues added on multi-line strings:

    I do the same! I never use a new released feature in the first 3-4 years.
    I wait for it to get ripe and stable. 🙂Well, some things like "skins" (styles), 64 bit compiler, obviously took more than 3-4 years. FMX, still way to go...
    How many years ago they announced first time that Delphi has support for high DPI?
    Today, I can't still build decent high dpi apps in Delphi.

     

    I personally, won't buy a new license until I get a usable version to worth the price. It simply not fair to pay for bug fixes. My users will laugh at me if I would dare to ask money for a showstopper bug that was not supposed to be there.
    I always said (joking) that if Emba will release one-single-true-stable-version they will get out of business because everybody will buy that version (remember Delphi 7?) and lock into it. Nobody will upgrade to the next version for 8-12 years (unless the next version is as good as the other one). I am kinda doing that with 10.4.

    • Like 4

  12. On 11/11/2023 at 5:49 PM, Stefan Glienke said:

    At least in 13 they would have an excuse for poor quality :classic_tongue:

    Ok. This really made my day! The best replica on the whole forum.
    I should put it in my signature.
    _____

     

    Maybe we should ALL skip buying Delphi 13 if it is still buggy. And the next versions....... Until they finally release something usable.
     

     


  13. On 11/10/2023 at 9:13 AM, Vandrovnik said:

     I welcome multi-line strings.

    Are you kiding me? Pay thousands of $ to get all those tiny featues? Especially that some of them (like multi line strigs or colored lines between begin/end) were already availalbe since 100 years ago via IDE plugins.


  14. On 11/8/2023 at 5:55 PM, David Heffernan said:

    All these marketing people trying to generate buzz around a name. How about fixing the bugs and making the product better? Then you can call it anything you like and it will sell.

    You are right.
    There are 28 years since first Delphi.
    After all this time, should we still hope that we will ever have a stable version? (IDE, RTL, VCL, compiler, even cross-platform stuff and EVEN FMX)
    We keep renewing the licenses in order to get a better/stable version that fixes some specific bugs that hunt us, only to discover that new bugs plague the new version. So, next year we have to upgrade again.

    GREAT MARKETING GIMMICK!

     

     

×