Jump to content

Joseph MItzen

Members
  • Content Count

    270
  • Joined

  • Last visited

  • Days Won

    7

Posts posted by Joseph MItzen


  1. 1 hour ago, David Heffernan said:

    If I actually disagreed with you, I'd produce a counter example. I don't think I have because I don't think there is one. 

     

    Therefore I can't believe that I disagree. 

    OK, I think I recalled the disagreement somewhat wrong. It was about being able to call a process and get its output back into Delphi. I cited the standard code examples per

     

    https://stackoverflow.com/questions/9119999/getting-output-from-a-shell-dos-app-into-a-delphi-app

     

    and opined that it was rather complicated. You offered another method and argued that it wasn't really very hard at all.


  2. 36 minutes ago, Vandrovnik said:

    But these routines also have to be installed on the machine where Firebird server is running (that is how I understood "run safely inside Firebird engine space"), or am I wrong?

    If I understood the original post, what's being talked about is the ability to write procedural code in other languages directly within SQL statements being sent to the server. PostgreSQL offers this, and SQL Server offers this (for .NET languages). For example, in PostgreSQL if Python is installed on the server and the python language support is enabled in the database:

    jmadden=> CREATE FUNCTION pymax (a integer, b integer)
              RETURNS integer
              AS $$
                 if a > b:
                     return a
                 return b
              $$ LANGUAGE plpythonu;
    CREATE FUNCTION
    
    jmadden=> select pymax(1, 2);
    
     pymax
    -------
       2
    (1 row)
     

    Here a user was able to send a function to the server just like a regular SQL statement and then call it. Such code could be in the middle of a batch of SQL statements. Triggers can be coded in other languages, custom aggregates, etc.

     

    Firebird doesn't offer this level of support for inlining other languages today.


  3. On 11/7/2019 at 1:50 AM, Fr0sT.Brutal said:

    Lazarus has multiplatform TProcess with STDIN/OUT interception, waiting for finish and so on. I wonder if something like that exists for Delphi (this should really be in RTL as it's "routine stuff")

    I know David Heffernan and I have debated this before :classic_biggrin:, but IMHO no, there's nothing like Lazarus' TProcess, Qt's QProcess, or Python's run function in Delphi (David disagrees). I also am puzzled why Delphi has never had a simple way to execute commands and retrieve results.


  4. 5 minutes ago, Vandrovnik said:

    I wrote UDF for Firebird in Delphi in year 2010 and cross compiled it for linux using FreePascal, so writing functions in Delphi already works quite a long time...

    There's a difference between writing code in an external IDE, compiling it, and having a system administrator install it versus simply enabling a user to inline another language along with their SQL code.

     


  5. On 11/5/2019 at 2:33 AM, Jacek Laskowski said:

    Firebird 3 has very interesting possibilities. Among other things:

    •  Eventually, plug-in support for stored procedures, triggers and functions written in Java, C++, ObjectPascal, etc."

     

    I began looking at Firebird in 2005. I was told that support for writing functions in other languages was coming in Firebird 3.0, which was going to be coming shortly. It came 10 years later. 😭 And of course, no support for writing functions in Delphi, etc. yet. One would be much better off choosing PostgreSQL, which is also open source, has a long history of approximately yearly releases, is highly extensible (create your own data types, indexes, etc.), has a large plugin ecosystem, and allows for inlining code in many languages. Of course, there are also many enterprise-grade features such as parallel queries, significant replication support, etc. I'm not aware of FreePascal language support, but that would only be due to lack of interest; the plugin system can certainly support it. I've even seen a plugin for LOLcode. :classic_huh:


  6. On 10/26/2019 at 2:05 PM, aehimself said:

    Seriously though, my company is not paying for (or don't know about) these and it's a bit pricy for a simple person. There are people in my country who earn the price (or a fraction!) of a 1-day ticket per month.

    *spit-take* Wow, you weren't kidding! 1200 Euros for three days? That's more than my desktop computer cost.


  7. 14 hours ago, John Kouraklis said:

    I remember that as well..a bit sad in my view.

     

    So, there is Embarcadero and then there is Delphi's Product Manager. I wonder how this works...

     

    Feels like the product manager is a freelance and outsourced position:classic_unsure:

    I had someone from inside Embarcadero tell me once about the layers of management. When I mentioned this, Marco told me that my understanding of the hierarchy was wrong and proceeded to try to explain it to me. Rather than convincing me that it was simpler, I felt like I needed flowchart paper to follow his explanation. 🙂 From what I recall there was a manager to manage the coders as well as the product manager (which he mentioned entailed a bit of marketing in the job description) and then when AppMethod was cancelled Sara DuPont because a sort of "co-manager", etc. Before Idera at least there were various Vice-Presidents in charge of software, etc. In neither version did I get an idea that there was one clear person in charge of guiding Delphi. Maybe things are different now with Idera and Atanas Popov.


  8. 12 hours ago, Dalija Prasnikar said:

    Release dates are unknown to the public.

    They're unknown internally too. I'll never forget the time Marco scheduled a preview webinar for an upcoming release and Embarcadero went and released it two or three days before the preview was scheduled! Marco joked it was now a "postview webinar", but it struck  me as strange that not even the project manager had any idea when the product would be released.

    • Haha 1
    • Confused 3

  9. On 8/28/2019 at 9:47 AM, Stefan Glienke said:

    Even though I don't see them pop up when browsing the forum itself (kudos to the mods being quick enough or having automated it) I see stuff like this on beginend.net almost every day recently:

     

    image.png.39ac7d550306d22d885717cff566b9ea.png

     

    Hey, you deal with the Delphi IDE long enough, you need a fistful of cheap unmarked pills of dubious provenance to get through the day! :classic_biggrin:

    • Haha 4

  10. On 9/30/2019 at 4:39 AM, Stefan Glienke said:

    Don't tell me - but this the almighty excuse brought up by the decision makers almost every time some issue like this is brought up - "but what about existing code" - like for that dreaded "directly passing result of ctor call to interface parameter issue" - what about existing code? Well existing code is most likely suffering from a defect.

     

    The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!

    You're reminding me of something written by Dennis Ritchie about operator precedence in C. At one point early on they wanted to change it, but Ritchie said "We can't; there's almost a million lines of C code out there!" :classic_biggrin: He wrote that in retrospect they should have made the change. Contrast this with the creator of Python, Guido Van Rossum, when talking about breaking compatibility to change how Unicode strings were handled. I don't have the exact quote, but it went something like  "All the lines of Python ever written pale in comparison to the number of lines of Python yet to be written".

     

    Quote

    The stupidity of the Delphi compiler in almost every aspect and the unwillingness to change anything significant on that is making me furious!

    This gets into the touchy subject of how many people are writing new code in Delphi versus how many are maintaining legacy code. Even with C++Builder they brought the 32bit compiler up to C++17 first, saying you'd be surprised how much 32bit code is being maintained by C++Builder users.


  11. On 9/21/2019 at 3:46 AM, Dany Marmur said:

    @Bill Meyer, the post was talking about "normalising" or rather "putting in place" stuff that should be application-wide. So not standard in that way. Normalise, standardise you own application. The notion is "global" but this post was written from a Delphi standpoint. Ah, i feel words are failing me. Sigh.

    Maybe the word you're looking for is "template"?


  12. On 9/2/2019 at 5:03 AM, RonaldK said:

    I'm not really sure, that Emba is the bigger company? 

    Embarcadero sold to Idera for $600 million. Idera was said to be about the same size as Embarcadero at the time of acquisition, putting the worth of the combined entity at approximately $1.2 billion dollars. For perspective, Embarcadero bought CodeGear for $30 million. As Jolyon Duranko-Smith once observed, if we're extremely generous and assume that the worth of Delphi doubled under its time with Embarcadero, that puts its contribution to the worth of Idera at 5%. It's not a particularly important asset for them.


  13. On 8/31/2019 at 10:19 AM, David Heffernan said:

    Not so much humour as a comment about the arrogance of imagining that the big company can just decide to buy the small company. Perhaps the small company is happy to be independent. 

    There's no "perhaps" about it. On the RemObjects forum a comment came up about perhaps RemObjects would buy Delphi if it was up for sale (this may have been around the time it became clear Idera was going to buy Embarcadero). Marc Hoffman then replied, asking what made the poster think they'd even want it. He went on to say that he wouldn't want anything to do with Embarcadero after his experiences with them. He also revealed that at one point during their discussions someone from Embarcadero said "We own Pascal".


  14. On 8/30/2019 at 10:50 AM, Arnaud Bouchez said:

    Most dev people outside this forum would argue, paraphrasing @Dalija Prasnikar,  that 'Delphi is a relic of another time and another coding practices: for instance, there is no GC !'. 

    Php adepts would argue that writing $this->foo is much cleaner/safer than what Delphi (and other languages) do about properties. 

     

     

    On 8/30/2019 at 11:25 AM, Dalija Prasnikar said:

    We are not discussing other languages here. 'with' is the problem within language itself. 

     

    Hmmm.... maybe you're both right! I think we need to be discussing other languages here because I can't recall a mainstream language with a "with" statement that does what Delphi's does (Python has a "with" keyword but for a different purpose). So perhaps the question should be asked... how do other languages address this problem?

     

    Joe Gregorio of Google once gave a talk in which he stated that design patterns were "language smell". He stated that when the same code is written over and over that's where a feature is needed. He talked about the lack of design patterns in Python and other languages like LISP and then went through how features like first class functions in those languages removed the need for the classic design patterns.

     

    Perhaps Delphi's "with" points to language smell and we can look at what features languages without that smell have that eliminate it.

     

    Why are people using with? To avoid writing code like this:

     

    someBigThing.x := 7;
    
    someBigThing.y := 8;
    
    someBigThing.z := 9;
    

    No one wants to write "someBigThing" over and over. We also see code in Delphi where an object is initialized, then lots of parameters are set one by one (creating a temptation to use "with") and then finally an "execute" method or similar is called. I once dubbed this "the Delphi pattern" and then discovered that it's also a problem/pattern in Java and they have a name for it. Unfortunately, I can't recall it right now. 😞

     

    But how is this dealt with in languages other than Delphi and Java?

     

    It turns out there is a language feature which eliminates this pattern.... named parameters.

     

    The code above can become

     

    Quote

    someBigThing.set(x=7, y=8, z=9);

     

    No ambiguity of the with statement, yet no redundancy of omitting it either!

     

    The "Delphi pattern" for object initialization can disappear too into one line of code.

     

    Quote

    someBigThing := SomeClass.Create(server="server.com", port="8080", asynchronous=True, timeout=60)

     

    If Delphi introduced named arguments the with statement could be eliminated, removing the dangers, while at the same time preserving the benefits and brevity it granted.

    A simple fix that makes everyone happy and incidentally provides one of the modern language features needed to design some beautiful APIs.

     

    The funny thing is that the language actually does have named parameters, but only under very specific circumstances....

     

    https://stackoverflow.com/questions/885942/named-optional-parameters-in-delphi

     

    Trivia note: The above is the only Delphi-related Stack Overflow question without a reply from David Heffernan. :classic_biggrin:

     

    • Like 2

  15. On 8/30/2019 at 10:50 AM, Arnaud Bouchez said:

    Most dev people outside this forum would argue, paraphrasing @Dalija Prasnikar,  that 'Delphi is a relic of another time and another coding practices: for instance, there is no GC !'. 
    Php adepts would argue that writing $this->foo is much cleaner/safer than what Delphi (and other languages) do about properties. 


     

    Well, maybe we should listen to what all those people have to say too. I'm sure there is a lot to learn from many different languages.

    • Like 1
×