David Heffernan

I'm guessing what happened here is that asker put the variable name into a string and imagined it would be interpreted in the context of the variable namespace.

Why not compile the code as is, and link it from your program?

This is not true. You can use an inline variable declaration. https://docwiki.embarcadero.com/RADStudio/en/Inline_Variable_Declaration Please don't tell us we are jerks. That's just offensive and rude.

I had to read this question x times before I understood it

Not with Electron. I'm thinking of programs built with other tools. Or do you claim that programs exist that perform their task efficiently? I don't disagree. I'm talking about the other use cases. Have you seen how much labour Arnaud puts in to writing asm code? Because the Delphi compilers can't do the job. Other tools can do the job though. I don't think that's a fair assessment. The programs you are talking about call into libraries like numpy and scipy and the kernels of these libraries are implemented in Fortran and C. I wish people would stop telling me that performance doesn't matter to me. How do you all know what matters to me?

Let's look at this argument. There also exist many dev tools and programs built with them, that are blazingly fast. By your logic we would conclude that market does care about speed. But now we've got contradictory conclusions using your logic. There must be a flaw somewhere. Is it possible that performance is critical in some cases, but not others? If go right back to the start of this particular thread, my original comment was in response to a claim that code compiled by delphi was fast. I disagreed with that. Seems like you actually agree with me.

Sorry, I don't know what point you are making. Can you elaborate?

Why not? My experience is that the OS is largely unimportant because it's the hardware that matters. Well no, but that's not even remotely what I'm talking about. My competitors aren't coding for 90s Crays. They are coding for today's hardware, as am I. For of all, we haven't been getting annual doubling of performance for quite a while now. But again I'm not competing against last year's computers. The developers writing code that competes against mine are also able to use that same hardware as me. Just because performance isn't important to you doesn't mean that it isn't important to others. Your experience of the world isn't the same as others.

That's nice. But plenty of other people are in the situation which you are lucky enough never to have found yourself in.

If only delphi's poor performance was limited to math

Yeah, but performance isn't important for 98% of Delphi programmers. (am I doing this right?)

This makes absolutely no sense.

That's absolutely fair. But I was responding this this comment. If performance isn't important to you then you can just ignore such discussions. Just as I ignore discussions on things like database programming in Delphi, because I don't don't use Delphi for that.

My business is based around a computationally intensive numerical finite element code. The performance of the code emitted by the compiler is very important. Why do you think otherwise?

I'm happy for you that delphi is fast enough for you. It does produce slow code when compared to other mainstream modern compilers. C++ is a language with many compilers. Some compilers are faster than others. So it doesn't make sense to compare delphi compilers to C++ as a whole. It's certainly the case that the fastest C++ compilers produce code that is much faster than delphi. Especially for maths. In fact for maths code it's astonishing how slow delphi is.

Might be cast to develop, but the code produced by the Delphi compilers is slow

What is the problem for which this is the solution?

1. More complicated. Depends on the type of code and the libraries. 2. Fair. 3. Not sure about that. 4. Definitely not universally true. Perhaps for Windows GUI components, but probably nothing else. 5. Don't agree at all. Don't you see that different tools are better in different settings? Surely everyone understands that.

Click on the word no

Kind of funny that this site returns a page with a link to the emba site which in turn is a 404. Well, actually it's a 503 but whatever. So even if delphi isn't dead, isdelphidead.com is dead. A meta death if you will.

It's broadly accurate I'd say. What you should ask is the reverse, what advantages delphi has compared to python. For what it is worth I use both delphi and python. For some tasks one is better, for some the other is better. And I use a number of other languages too. Use the the tool that matches the job. In fact my product has a python api and can also host embedded python.

@pyscripter do you know if it's reasonable to implement the python mapping protocol on the Delphi side so that from python it looks like a Python mapping?

Consider a large dictionary with, for sake of argument, 1 million items in it. Suppose in Python you wanted to write value = foo[name] Now if foo was actually in your Delphi code, and backed by a Delphi dictionary, do you really want to populate a new Python dict with 1 million items, then perform the lookup in Python, and then throw away that dictionary. Wouldn't it be better to just ask Delphi to perform the lookup. This is what I mean what I talk about the mapping protocol. But it's entirely possible that I have misunderstood what you actually want to do!

Do you want to create a new instance of Python dict every time the property is called? Or aren't you looking to implement the Python mapping protocol so that Python has something that behaves like a dict, but actually just reflects the underlying Delphi object?

What happens to an exception raised in OnCreate? EDIT: I was curious. This is what happens: procedure TCustomForm.DoCreate; begin if Assigned(FOnCreate) then try FOnCreate(Self); except if not HandleCreateException then raise; end; if fsVisible in FFormState then Visible := True; end; function TCustomForm.HandleCreateException: Boolean; begin Application.HandleException(Self); Result := True; end; So exceptions are handled by a top level handler, and then excecution continues. This feels like quite a strange design choice to me. Swallowing exceptions feels odd. You can change this behaviour by overriding the dynamic method HandleCreateException to return False. Like @dummzeuch I never use OnCreate or OnDestroy.