9 ms·

Amazing, our Oxygene compiler, Delphi and FPC has solved all of these issues ages ago, perhaps it's time to let this article go after all this time. - 2.0 Type

by ckok 8y ago

Amazing, our Oxygene compiler, Delphi and FPC has solved all of these issues ages ago, perhaps it's time to let this article go after all this time. - 2.0 Types and scopes: Apple = type Integer; makes it a distinct type - 2.1 Array size: dynamic arrays - 2.2 Admittedly, not exactly solved, but classes are how we hide variable these days. - 2.3 Oxygene doesn't care about order of things - 2.4: Long solved - 2.5: While allowed; something can be said for using an alias here to make the intent obvious; the in set is also solved in Oxygene since c in ['a'..z'] compiles to c >='a' and c <='z'. - 3: boolean shortcircuitry has long been part of Pascal - 4: With streams apis this is no longer a thing - 5: xor/or has lng been part of the languages, the semicolon issue seems a style issue to me, not a big deal (edit: had to insert enters to make it readable)

jstimpfle 8y ago
I've used Delphi in the last year and, while I hated it overall, there were a few things I liked about it. It's really nice that it compiles so quickly. And it feels very principled, at least the Pascal baseline. The main problem I remember is that you cannot simply use pointer types, or other complex types, as function parameters. You always have to declare a typedef first, such that the type that is used in the function signature is a single word (named reference to the typedef). Working on a compiler myself, I understand from an implementation perspective why Wirth did this, but this is really lazy. From a developer's perspective, to me that's next to unusable. It's really stressful to predeclare pointer types before using them, and using names like TypeP, TypePP and so on is much less readable than simple ^Type, ^^Type, etc. Another thing that's driving me crazy is case insensitivity. I would never willfully choose a language with case insensitive identifiers. It's driving me nuts. > 2.2 Admittedly, not exactly solved, but classes are how we hide variable these days. global initialized variables are really important to me to avoid unnecessary boilerplate and indirection (which is just as painful as not having initialized globals). What I did was initialize them in the initilization section. But it was another major inconvenience.
- kbp 8y ago
  > Another thing that's driving me crazy is case insensitivity. I would never willfully choose a language with case insensitive identifiers. It's driving me nuts. What about it annoys you? Do you often define a lot of variables whose names differ only by case, in languages that let you? Common Lisp normally behaves as though it were case insensitive, and I've never found that to be a pain point.
  - Shivetya 8y ago
    I never understood the falsification with case insensitive languages, to me it was yet another way to trip up a team effort let alone working with many related sources. however my view is jaded by working mostly on minis and our languages were always this way. the focus was on concise naming and logic and to me just adding another method for a typo to nail me does not benefit a language. so can someone tell me the reason why?
  - jstimpfle 8y ago
    In fact I often use the "Thing thing" approach to variable declaration and I think I like it. It's an easy way for me to avoid thinking about taxonomy. But it's not that important. If it wasn't possible I could invent different names. What really irks me is that in case-insensitive languages, codebases naturally start to use all kinds of variations of casing, to refer to the same variable. It really trips me up when reading code. It's also difficult when writing code since I tend to remember variable names in a very visual way. (Same reason why I dislike the case-insensitive Windows filesystems). There simply isn't any good reason not to always use the same case for any variable throughout a project. Beyond that it's also aesthetically not pleasing, from an engineering viewpoint. Case-insensitive comparison is much more complicated than simply comparing strings as arrays of bytes. Historically, I think the reason why case-insensitive languages exist is simply that at the time they were invented (at least in the case of Pascal), many systems couldn't input lowercase characters.
    - clouddrover 8y ago
      > I often use the "Thing thing" approach to variable declaration The Pascal way would be to use the "T" convention for the name of the type. So "thing : TThing".
- clouddrover 8y ago
  > It's really stressful to predeclare pointer types before using them Depending on what you're doing exactly there are things you can do to mitigate that. If you're using records, you can just pass the record by reference instead. If you're using objects then you don't often need separate pointer types to them (the object reference is a pointer itself). If it makes sense for what you're doing you can also use untyped parameters: http://docwiki.embarcadero.com/RADStudio/Rio/en/Parameters_(Delphi) http://docwiki.embarcadero.com/RADStudio/Rio/en/Parameters_(... If you don't need to actually deference the pointers you can use the Pointer type (and if you still need to get at the data in some circumstances you can cast to a typed pointer inside the function): http://docwiki.embarcadero.com/RADStudio/Rio/en/Pointers_and_Pointer_Types_(Delphi) http://docwiki.embarcadero.com/RADStudio/Rio/en/Pointers_and...
  - jstimpfle 8y ago
    Yes I know these workarounds but I don't think they are better than typedefs. Instead I simply want the obvious and readable thing that doesn't try to hide what happens and that doesn't require extra keyboard typing.
    - clouddrover 8y ago
      > I don't think they are better than typedefs Why? Passing a record by reference looks like this: procedure SomeProc(var AMyRec : TMyRecord); Passing an object reference looks like this: procedure SomeProc(const AMyObj : TMyObject); I don't see that these are somehow onerous or hiding anything.
      - jstimpfle 8y ago
        Sure. When used they look like normal variables. And when you set them it looks like setting a local variable. This is hiding that what really happens is it's writing through a pointer. And it's modifying the caller's state. Add to that the unfounded non-orthogonality (like in C++, references are technically the same as pointers, but not syntactically, and not in the type system, leading to combinatorial explosion. And of course the bloated standard library is proof). Furthermore this approach doesn't work for pointers that point to arrays. Again, Delphi has its own zoo of workarounds that OOP enthusiast will think are so much better -- from dynamic arrays (really weird interactions with reallocations combined with "var" modifier or not), to ObjectLists (not typed) to a version of generics (has its own technical problems). But what I want is the simple and obvious thing (pointer parameters without typedefs) and there's no good reason why we shouldn't have it.
- na85 8y ago
  >I would never willfully choose a language with case insensitive identifiers. If you run into name collisions between FooBar and fooBar due to case insensitivity, isn't that indicative of your naming scheme for variables and functions, rather than a fault in the language design?
  - jstimpfle 8y ago
    You mean I shouldn't make both a function FooBar and a variable fooBar? Not the worst rule probably. We shouldn't get to clever with casing. Which is why I use mostly lowercase (to avoid decision paralysis). However, the language problem I see is when I define something as FooBar and reference it as FoOBAr or FOOBAR and that is not a symbol-not-found error.
- ckok 8y ago
  The pointer alias requirement is something we got rid of in our language (oxygene). We even allow defining method pointer types inline, though I wouldn't ever do that myself in a method signature, it's quite useful inside a structure, especially when doing com like or jni interop. Case insensitive, our compiler by default warns about mismatches between definition and use. Initialization is there, what I meant is that we don't have something where you define a static var inside a method body. You can of course make it implementation only or private which can severely limit the scope of what can access it.
  - deleted 8y ago
    [deleted]
Svip 8y ago
> - 2.2 Admittedly, not exactly solved, but classes are how we hide variable these days. You can use a const in a function and wrap it in {$J+} to allow modifying consts. And that's a static variable on that function (or procedure), e.g. {$J+} procedure A; const C: integer = 0; begin Inc(C); Writeln(C); end; {$J-}
zerr 8y ago
I believe even in 80s most of these were fixed in various 3rd party vendor Pascal compilers. Anyway, I've always found your particular products/business interesting. Could you please share some insights? Like who are your userbase (I believe you're in a very niche space, but I might be wrong), how strong are sales going on, etc...
- dwarfland 8y ago
  We don't usually share information about sales, as that is confidential business data, but suffice to say we're pretty happy and are going strong for ~15 years, now. Our users come from all ranges, both in terms of company size (from single-dev shops to big-name Fortune 500s) and target area (mobile, desktop, web, services, enterprise, you name it). Elements is a general purpose programming environment, and I believe there's something to find and like about it for just about every software developer. For example, while we have a strong focus on sharing code across platforms, the product is nit just about that, a lot of developers single-platform devs still love Elements for other reasons, even if they only care about, say, .NET, or only about Cooca. The multi-platform support is just one of a list of many benefits any individual dev might be attracted to (or not care about). —marc
dvfjsdhgfv 8y ago
I just thought I'd give your product a try. My hopes are very high, since at $800 I expect something almost on a par with Delphi. CrossBox seems like a neat idea but it would be great to explain upfront that in order to develop for other platforms you actually need to have that machine. It's half-cross-platform, I'd say.
- ckok 8y ago
  We're working on making the osx target be able to compile locally, but it's a slow process. A beta backend can now create osx executables from windows without running osx. There however are a lot of things that are closed tools that are osx only, like Ibtool, codesign etc, a lot of which are required parts of getting a final application. While we're working on getting around those, osx will be required to compile yes. Obviously debugging Will stay dependent on osx. (Also iOS will require osx due to how it's not possible to upload and debug apps from windows at all). That said I agree that should be made more clear.
WalterGR 8y ago
Amazing, our Oxygene compiler, Delphi and FPC has solved all of these issues ages ago... What does that (partial) sentence mean? Your Oxygene compiler (which is called Delphi) as well as “FPC” have both solved all of these issues ages ago? That seems wrong because Delphi is a Pascal descendent. But otherwise I don’t know how to parse that partial sentence. What are Oxygene and FPC?
- ckok 8y ago
  Should have been 'have'. Oxygene, FPC (freepascal) and Delphi are 3 different Pascal compilers which all have solved most/all of these problems.

by ckok 8y ago

jstimpfle 8y ago

I've used Delphi in the last year and, while I hated it overall, there were a few things I liked about it. It's really nice that it compiles so quickly. And it feels very principled, at least the Pascal baseline. The main problem I remember is that you cannot simply use pointer types, or other complex types, as function parameters. You always have to declare a typedef first, such that the type that is used in the function signature is a single word (named reference to the typedef). Working on a compiler myself, I understand from an implementation perspective why Wirth did this, but this is really lazy. From a developer's perspective, to me that's next to unusable. It's really stressful to predeclare pointer types before using them, and using names like TypeP, TypePP and so on is much less readable than simple ^Type, ^^Type, etc. Another thing that's driving me crazy is case insensitivity. I would never willfully choose a language with case insensitive identifiers. It's driving me nuts. > 2.2 Admittedly, not exactly solved, but classes are how we hide variable these days. global initialized variables are really important to me to avoid unnecessary boilerplate and indirection (which is just as painful as not having initialized globals). What I did was initialize them in the initilization section. But it was another major inconvenience.

kbp 8y ago
> Another thing that's driving me crazy is case insensitivity. I would never willfully choose a language with case insensitive identifiers. It's driving me nuts. What about it annoys you? Do you often define a lot of variables whose names differ only by case, in languages that let you? Common Lisp normally behaves as though it were case insensitive, and I've never found that to be a pain point.
- Shivetya 8y ago
  I never understood the falsification with case insensitive languages, to me it was yet another way to trip up a team effort let alone working with many related sources. however my view is jaded by working mostly on minis and our languages were always this way. the focus was on concise naming and logic and to me just adding another method for a typo to nail me does not benefit a language. so can someone tell me the reason why?
- jstimpfle 8y ago
  In fact I often use the "Thing thing" approach to variable declaration and I think I like it. It's an easy way for me to avoid thinking about taxonomy. But it's not that important. If it wasn't possible I could invent different names. What really irks me is that in case-insensitive languages, codebases naturally start to use all kinds of variations of casing, to refer to the same variable. It really trips me up when reading code. It's also difficult when writing code since I tend to remember variable names in a very visual way. (Same reason why I dislike the case-insensitive Windows filesystems). There simply isn't any good reason not to always use the same case for any variable throughout a project. Beyond that it's also aesthetically not pleasing, from an engineering viewpoint. Case-insensitive comparison is much more complicated than simply comparing strings as arrays of bytes. Historically, I think the reason why case-insensitive languages exist is simply that at the time they were invented (at least in the case of Pascal), many systems couldn't input lowercase characters.
  - clouddrover 8y ago
    > I often use the "Thing thing" approach to variable declaration The Pascal way would be to use the "T" convention for the name of the type. So "thing : TThing".
clouddrover 8y ago
> It's really stressful to predeclare pointer types before using them Depending on what you're doing exactly there are things you can do to mitigate that. If you're using records, you can just pass the record by reference instead. If you're using objects then you don't often need separate pointer types to them (the object reference is a pointer itself). If it makes sense for what you're doing you can also use untyped parameters: http://docwiki.embarcadero.com/RADStudio/Rio/en/Parameters_(Delphi) http://docwiki.embarcadero.com/RADStudio/Rio/en/Parameters_(... If you don't need to actually deference the pointers you can use the Pointer type (and if you still need to get at the data in some circumstances you can cast to a typed pointer inside the function): http://docwiki.embarcadero.com/RADStudio/Rio/en/Pointers_and_Pointer_Types_(Delphi) http://docwiki.embarcadero.com/RADStudio/Rio/en/Pointers_and...
- jstimpfle 8y ago
  Yes I know these workarounds but I don't think they are better than typedefs. Instead I simply want the obvious and readable thing that doesn't try to hide what happens and that doesn't require extra keyboard typing.
  - clouddrover 8y ago
    > I don't think they are better than typedefs Why? Passing a record by reference looks like this: procedure SomeProc(var AMyRec : TMyRecord); Passing an object reference looks like this: procedure SomeProc(const AMyObj : TMyObject); I don't see that these are somehow onerous or hiding anything.
    - jstimpfle 8y ago
      Sure. When used they look like normal variables. And when you set them it looks like setting a local variable. This is hiding that what really happens is it's writing through a pointer. And it's modifying the caller's state. Add to that the unfounded non-orthogonality (like in C++, references are technically the same as pointers, but not syntactically, and not in the type system, leading to combinatorial explosion. And of course the bloated standard library is proof). Furthermore this approach doesn't work for pointers that point to arrays. Again, Delphi has its own zoo of workarounds that OOP enthusiast will think are so much better -- from dynamic arrays (really weird interactions with reallocations combined with "var" modifier or not), to ObjectLists (not typed) to a version of generics (has its own technical problems). But what I want is the simple and obvious thing (pointer parameters without typedefs) and there's no good reason why we shouldn't have it.
na85 8y ago
>I would never willfully choose a language with case insensitive identifiers. If you run into name collisions between FooBar and fooBar due to case insensitivity, isn't that indicative of your naming scheme for variables and functions, rather than a fault in the language design?
- jstimpfle 8y ago
  You mean I shouldn't make both a function FooBar and a variable fooBar? Not the worst rule probably. We shouldn't get to clever with casing. Which is why I use mostly lowercase (to avoid decision paralysis). However, the language problem I see is when I define something as FooBar and reference it as FoOBAr or FOOBAR and that is not a symbol-not-found error.
ckok 8y ago
The pointer alias requirement is something we got rid of in our language (oxygene). We even allow defining method pointer types inline, though I wouldn't ever do that myself in a method signature, it's quite useful inside a structure, especially when doing com like or jni interop. Case insensitive, our compiler by default warns about mismatches between definition and use. Initialization is there, what I meant is that we don't have something where you define a static var inside a method body. You can of course make it implementation only or private which can severely limit the scope of what can access it.
- deleted 8y ago
  [deleted]

Svip 8y ago

> - 2.2 Admittedly, not exactly solved, but classes are how we hide variable these days. You can use a const in a function and wrap it in {$J+} to allow modifying consts. And that's a static variable on that function (or procedure), e.g. {$J+} procedure A; const C: integer = 0; begin Inc(C); Writeln(C); end; {$J-}

zerr 8y ago

I believe even in 80s most of these were fixed in various 3rd party vendor Pascal compilers. Anyway, I've always found your particular products/business interesting. Could you please share some insights? Like who are your userbase (I believe you're in a very niche space, but I might be wrong), how strong are sales going on, etc...

dwarfland 8y ago
We don't usually share information about sales, as that is confidential business data, but suffice to say we're pretty happy and are going strong for ~15 years, now. Our users come from all ranges, both in terms of company size (from single-dev shops to big-name Fortune 500s) and target area (mobile, desktop, web, services, enterprise, you name it). Elements is a general purpose programming environment, and I believe there's something to find and like about it for just about every software developer. For example, while we have a strong focus on sharing code across platforms, the product is nit just about that, a lot of developers single-platform devs still love Elements for other reasons, even if they only care about, say, .NET, or only about Cooca. The multi-platform support is just one of a list of many benefits any individual dev might be attracted to (or not care about). —marc

dvfjsdhgfv 8y ago

I just thought I'd give your product a try. My hopes are very high, since at $800 I expect something almost on a par with Delphi. CrossBox seems like a neat idea but it would be great to explain upfront that in order to develop for other platforms you actually need to have that machine. It's half-cross-platform, I'd say.

ckok 8y ago
We're working on making the osx target be able to compile locally, but it's a slow process. A beta backend can now create osx executables from windows without running osx. There however are a lot of things that are closed tools that are osx only, like Ibtool, codesign etc, a lot of which are required parts of getting a final application. While we're working on getting around those, osx will be required to compile yes. Obviously debugging Will stay dependent on osx. (Also iOS will require osx due to how it's not possible to upload and debug apps from windows at all). That said I agree that should be made more clear.

WalterGR 8y ago

Amazing, our Oxygene compiler, Delphi and FPC has solved all of these issues ages ago... What does that (partial) sentence mean? Your Oxygene compiler (which is called Delphi) as well as “FPC” have both solved all of these issues ages ago? That seems wrong because Delphi is a Pascal descendent. But otherwise I don’t know how to parse that partial sentence. What are Oxygene and FPC?

ckok 8y ago
Should have been 'have'. Oxygene, FPC (freepascal) and Delphi are 3 different Pascal compilers which all have solved most/all of these problems.