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.

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_(...

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...

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.

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.

There is no ambiguity and nothing is hidden. Both examples are passing a reference to the procedure and all Pascal programmers will know what it means.

I think your argument boils down to a lack of experience with Pascal (which is fine). But these things you think are problems simply aren't.

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.

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.

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.

There's no reason that types and variables need to live in the same namespace. The language can know what it's expecting at a certain point. Putting them in different namespaces, like Lisp does, lets you re-use the same name for types and variables even with matching case, and is more waterproof with regards to clashes than a case convention.

> There simply isn't any good reason not to always use the same case for any variable throughout a project.

I agree, but I also feel that there isn't any good reason to have multiple distinct objects in the same namespace whose names differ only by case. It just seems like a recipe for confusion.

When I'm quickly iterating on something, it's nice being able to be lazy and inconsistent with capitalisation. Standardising that in a codebase is important, but it's more of a job for a linter, I think.

And as soon as we go to more dynamic languages, where types can also be variables, it all breaks down.

The Pascal way would be to use the "T" convention for the name of the type. So "thing : TThing".

Maybe people who somehow don't differentiate between 'T' and 't', and are not visually remembering persons, don't have this problem. But for me, and for computers, they are different characters.

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?

You should almost never use it in programming, unless you mean it. I've never written Common Lisp code in upper case, other than copying and pasting from REPL output.

Allowing upper case to simply denote lower case any time you want basically PANDERS TO THE MORONS WHO SHOUT LIKE THIS in internet forums.

Supporting case insensitivity in a modern setting requires carrying a large table of Unicode data about all of the world's scripts that exhibit case.

Which scripts exhibit case is controversial. Are Japanese hiragana and katakana in a case relationship? Should れつ (retsu) and レツ (RETSU, sort of) be the same symbol or not?

Programmers used to case distinctions see FOO, Foo and foo as completely different; there is no issue there. Literate non-programmers should also see them as different. "Pat" is a name, "pat" is a verb.

Mathematics uses case distinction. If you're writing a summation notation with Σ, you can't just switch to σ. You can't switch 3 + 4i to 3 + 4I just because you feel like it.

Basically, case insensitivity is for illiterate morons with no background in mathematics.

Why it appears in classical programming languages is because 1950's and 1960's hardware didn't support large enough character sets to have both upper and lower case. Even some consumer grade microcomputers in the late 1970's and early 1980's lacked lower case, like Apple II's.

The Unix TTY system still supports folding to upper case!

Try this at your Linux bash prompt:

   $ stty olcuc  # output: lower case to upper case

Thus, old programming languages were written in upper case, but with increasing support for lower case in character sets and hardware, programmers wanted to use those same languages in lower case. A pragmatic solution was to support it both ways: allow lower case for new programs, but also upper case for backward compatibility with existing code.

So it wasn't illiteracy; there was a technical reason. The technical reason doesn't exist any more, and so repeating this in new designs is just illiteracy. If you're making a new language today, you have no existing code in upper case that has to work.

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?

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.

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?

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...

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

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-}