3 ms·

Cannot speak for Ada. Only looked through a few tutorials once or twice and did not pursue further, I think mainly because I did not like the verbosity. > Obje

Cannot speak for Ada. Only looked through a few tutorials once or twice and did not pursue further, I think mainly because I did not like the verbosity. > Object Pascal FWIW I've worked for 6 months with a large Delphi code base (which is Object Pascal right?) and I really wanted to like it (and I did like quite a few aspects to it). Note that I was employed to improve performance, and I was competent enough about performance to have achieved speedups of 100x to 1000x for the parts I was working on. So, I'm not saying you can't write performant code in Delphi. But here are a few annoyances I can remember: - Need to typedef Type of Pointer-To-Type for anything before using it in function arguments: type Foo = record .. end; type PFoo = ^Foo; type PPFoo = ^^Foo. This is not only annoying. It's also extremely hard to read function signatures like function Foo(a: PFoo; b: PPBar) compared to function Foo(A: ^Foo; b: ^^Bar) IMHO. - Pointer types not really type-checked. Why? It would be so easy to do. - No macros, which are incredibly important (need experience to use them well? Yes, but still). - Object oriented culture pervasively used in libraries (for example, deep deep inheritance trees), leading to bad maintainability and bad performance. Tons of badly thought out features, weird syntactic tricks. Reminds of C++. Pretty sure there were more. As I said there are good things in it that are not in C, like better compilation performance and some parts to the syntax. But especially the first three are show stoppers for me. (The OO culture is painful as well, but you don't need to buy into it if you can do without the libraries). Of course, the Delphi code I wrote is just as unsafe as if it was in C.

pjmlp 8y ago
> Delphi code base (which is Object Pascal right?) Object Pascal was created by Apple with feedback from Niklaus Wirth for Lisa and Mac OS implementation. Other Pascal vendors eventually copied the extensions, most notably Borland. When they released Delphi, they kept calling it Object Pascal, although most of what was in Apple's MPW and Turbo Pascal variants is mostly legacy. As for the rest I will have to agree to disagree. - I love that I already had those OOP features and modules in 1992 vs bare bones C; - I consider proper TDD (Type Driven Programming) a good practice; - pointers are type checked, not sure what you mean here - No macros is plus, the large majority at ISO C++ is creating safer alternatives for each use case - OOP is quite useful in many use cases. I loved Turbo Vision and OWL. > Of course, the Delphi code I wrote is just as unsafe as if it was in C. Naturally one can disable all safety buttons and go full speed, but here lies the beauty of Algol linage of languages. Type safe by default and if one really requires that extra mile, then escape hatches are in place. Thing is, for 99% of most applications that is largely unnecessary.
- jstimpfle 8y ago
  > - pointers are type checked, not sure what you mean here They weren't here with Borland. Maybe it was one of the many optional compiler switches, so I'll take that back. > No macros is plus, the large majority at ISO C++ is creating safer alternatives for each use case That's just wrong. Learn how to use the tool and use it when it makes sense. There are a LOT of situations where the easiest for maintainability by far is to abstract at the syntactic level. The Rust guys acknowledge this as well. Even the Haskell compiler (GHC) has a C-style preprocessor built-in. For example, I use macros for data definitions, to create identifiers, to create strings from identifiers, to automatically insert additional function call arguments like size information or source code location... > that extra mile You mean 100x - 1000x in speed? > Thing is, for 99% of most applications that is largely unnecessary. Your initial comment was explicitly about performance. And I disagree that 99% of applications should accept a 100x - 1000x decrease in speed (and harder maintenance by far, if you ask me!) (corollary: less purity and joy in programming, by far), or even a 10x for that matter, just to get some more safety. I mean, safety is nice and all, but it's not all the reasons why I'm doing this. YMMV. EDIT: I now understand that you mean "99% of most applications", while I read it "99% of (or most) applications". I disagree with the implicit statement that you should write 99% in a "safe" language and the rest in a systems language. It is well known that you can never easily know where the bottleneck is or where the next will be. And it is well known that it is very laborious to accomodate multiple languages, or incompatible code styles, in a single project. (I've also heard some negative stories about integrated scripting languages, for example from the games industry, but I don't work there...) And in the end, speed is actually not the primary reason why I prefer C...
  - pjmlp 8y ago
    Macros can be easily replaced by other means, that is what Java and .NET do via annotations and compiler plugins. Rust macros are tree based and integrated into the compiler, not a text substitution tool running before the compiler, which cannot reason about what is happening. I don't get where that 100x - 1000x factor comes from, most compiled languages aren't that slower than C, specially if you restrict to ISO C. If C extensions are allowed in the benchmarks game, then those other languages also have a few tricks up their sleeves. For example, I can disable all checks in Ada via Unchecked_Unsafe pragmas and in the end there will hardly any difference to generated C code. The big difference is that I am only doing that in that function or package that is required to run like a 1500cc motorbike at full throttle to win the benchmark game, while everything else in the code is happy to run under allowed speed limits.

pjmlp 8y ago

> Delphi code base (which is Object Pascal right?) Object Pascal was created by Apple with feedback from Niklaus Wirth for Lisa and Mac OS implementation. Other Pascal vendors eventually copied the extensions, most notably Borland. When they released Delphi, they kept calling it Object Pascal, although most of what was in Apple's MPW and Turbo Pascal variants is mostly legacy. As for the rest I will have to agree to disagree. - I love that I already had those OOP features and modules in 1992 vs bare bones C; - I consider proper TDD (Type Driven Programming) a good practice; - pointers are type checked, not sure what you mean here - No macros is plus, the large majority at ISO C++ is creating safer alternatives for each use case - OOP is quite useful in many use cases. I loved Turbo Vision and OWL. > Of course, the Delphi code I wrote is just as unsafe as if it was in C. Naturally one can disable all safety buttons and go full speed, but here lies the beauty of Algol linage of languages. Type safe by default and if one really requires that extra mile, then escape hatches are in place. Thing is, for 99% of most applications that is largely unnecessary.

jstimpfle 8y ago
> - pointers are type checked, not sure what you mean here They weren't here with Borland. Maybe it was one of the many optional compiler switches, so I'll take that back. > No macros is plus, the large majority at ISO C++ is creating safer alternatives for each use case That's just wrong. Learn how to use the tool and use it when it makes sense. There are a LOT of situations where the easiest for maintainability by far is to abstract at the syntactic level. The Rust guys acknowledge this as well. Even the Haskell compiler (GHC) has a C-style preprocessor built-in. For example, I use macros for data definitions, to create identifiers, to create strings from identifiers, to automatically insert additional function call arguments like size information or source code location... > that extra mile You mean 100x - 1000x in speed? > Thing is, for 99% of most applications that is largely unnecessary. Your initial comment was explicitly about performance. And I disagree that 99% of applications should accept a 100x - 1000x decrease in speed (and harder maintenance by far, if you ask me!) (corollary: less purity and joy in programming, by far), or even a 10x for that matter, just to get some more safety. I mean, safety is nice and all, but it's not all the reasons why I'm doing this. YMMV. EDIT: I now understand that you mean "99% of most applications", while I read it "99% of (or most) applications". I disagree with the implicit statement that you should write 99% in a "safe" language and the rest in a systems language. It is well known that you can never easily know where the bottleneck is or where the next will be. And it is well known that it is very laborious to accomodate multiple languages, or incompatible code styles, in a single project. (I've also heard some negative stories about integrated scripting languages, for example from the games industry, but I don't work there...) And in the end, speed is actually not the primary reason why I prefer C...
- pjmlp 8y ago
  Macros can be easily replaced by other means, that is what Java and .NET do via annotations and compiler plugins. Rust macros are tree based and integrated into the compiler, not a text substitution tool running before the compiler, which cannot reason about what is happening. I don't get where that 100x - 1000x factor comes from, most compiled languages aren't that slower than C, specially if you restrict to ISO C. If C extensions are allowed in the benchmarks game, then those other languages also have a few tricks up their sleeves. For example, I can disable all checks in Ada via Unchecked_Unsafe pragmas and in the end there will hardly any difference to generated C code. The big difference is that I am only doing that in that function or package that is required to run like a 1500cc motorbike at full throttle to win the benchmark game, while everything else in the code is happy to run under allowed speed limits.