http://literateprogramming.com/
WEB is expressive enough that there is a tool to directly transpile to C for compiling:
Imagine this - if those had not exists, would anyone say Pascal was a good RAD language.
I suppose what I might be missing is why Pascal was chosen as the language for Delphi.
- Java, C, C++, C#, Kotlin, Rust, Swift, Go, TypeScript, JavaScript, ... → they look more or less the same
Compare with these ones that didn't catch on as much as the ones above:
- ML/Haskell, Erlang, Elixir, APL, Common Lisp (and other Lisps), Lua, Pascal, Delphi, BASIC, Visual Basic, VBA, VBScript, SmallTalk,... → each one bringing something refreshingly new to the PL design space
Even D still has a nod to C strings in it, in that string literals like "abc" have a 0 appended to them that is not included in the array length. "abc" can implicitly convert to a char*, which makes it very convenient when calling printf.
"Software Fault Prevention by Language Choice: Why C is Not My Favorite Language"
https://people.eecs.berkeley.edu/~fateman/papers/software.pd...
Lack of external static storage class, the pinnacle of C programming.
Lack of oh so powerful C strings, terminating in zero (hopefully).
"There is no way to override the type mechanism when necessary, nothing analogous to the "cast" mechanism in C."
"begin" and "end" are bulky compared to { and }.
http://lambda-the-ultimate.org/classic/message4322.html#4671
* Components have a support for customizable UI interfaces for setting the property of components called property sheets and these property sheets are applicable on a component level or at the level of individual property fields in the component. These property sheets show up when you are trying configure a component in the design mode within the IDE. We are not talking about simple text entry type of fields - you can actually do very sophisticated property sheets with tabs, multiple forms etc and what not. It is EXTREMELY configurable and also relatively easy to develop.
* Delphi uses a binary "form" file into which each GUI form persists its interface. So everytime you place a component on a form in the GUI IDE or set its properties, the form and its components have a way of persisting their values into this "form" file. The reverse also happens - so when a form is loaded into the IDE or during runtime, the form fields are read off the "form" file by the form and its components. So the actual .pas file where you are adding code for the events etc is not filled up with a lot of UI related property setting code and so the code looks really clean with clear separation of design and code.
* Components can be installed into the IDE during development very easily
When they hit C, they wrote code around fgets that processes the last line twice:
while (!feof(instream)) {
fgets(linebuf, sizeof linebuf, instream);
process_line(linebuf);
}
while (!feof(instream)) {
char ch = getc(instream);
switch (ch) ...
}In my 30-something years of programming (admittedly my first programs were toy-like Pascal pieces of code), I saw only one improvement in this Algol-like style that I considered major: named arguments. Their use improves code readability, at least for me.
The timeline of 70s and 80s also doesn't really seem to fit with what you're saying either. Of the languages you mention either as "more or less the same" or "refreshingly new", the ones from either the 70s or 80s are C, C++, ML, Smalltalk, Pascal, and Smalltalk; all of the other "refreshingly new" ones are from either before or after those years. Common Lisp was from the 80s, but the syntax originated with LISP in the 50s, so if you're going to go with the most common variant, I'd argue you should also remove ML from the list and replace it with OCaml, which is from the 90s.
Even more significantly, it feels like you're comparing apples and oranges with the discussion of syntax at the beginning and then talking about bringing something new to the PL design space after. I'd guess that most people involved in PL design find syntax to be the least interesting aspect of it, and I think it's hard to argue that none of the languages you described as looking similar brought anything new to the PL design space.
>- Java, C, C++, C#, Kotlin, Rust, Swift, Go, TypeScript, JavaScript, ... → they look more or less the same
The upside being that if you come from C or Java you will fill at home with Go.
* As opposed to BEGIN-END in SQL, indenting in Python or weirdness of Cobol in the 90s.
The new battle has begun with three major contenders: C, Golang, and Rust. Which one will be chosen for the future?
1. preprocessor/parser/semantic all at once
2. optimizer (optional)
3. code generator
Later on in the 80s these were merged into one executable.
Another counterexample to consider is Python. It's quite unlike Algol, but that certainly hasn't stopped it from becoming popular.
The thing we are still trying to add back into C, 50 years later.
(You can avoid some of the pain by using a big-endian length, and converting immutable Str64K pointers to Str255 by taking a pointer to the second byte of the length. But that's a terrible hack.)
Yes, most Pascal dialects, namely UCSD Pascal and Object Pascal also got around fixing them, as did ISO Extended Pascal, the follow up revision that was largely ignored, because by then it was all about Object Pascal.
Whereas by the time Turbo Pascal for Windows came to be, that was also sorted out in Object Pascal according to Borland linage.
As evolution to Modula-2, following up on Pascal evolution, Oberon had it sorted out as well in 1990.
When we say "Pascal" today we speak of a much more ergonomic language than the Pascal of 1981.
>Lack of external static storage class, the pinnacle of C programming.
>Lack of oh so powerful C strings, terminating in zero (hopefully).
>"There is no way to override the type mechanism when necessary, nothing analogous to the "cast" mechanism in C."
>"begin" and "end" are bulky compared to { and }.
In my opinion these are some of the less significant arguments. Your post never stated that it contains merely a subset a subset and instead claims to refute or weaken the overall proposal. I agree with the previous poster that this is a form of lying.
For instance, you ignored one of the very first and most significant points, "The size of an array is part of its type" which means that " it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting"
Incidentally, those are examples of quotes i.e. verbatim excerpts from the article.
A similar thing is happening with game engines. If everyone is taught Unreal engine then you don't get in-house engines anymore which requires skill, because it's easier and cheaper to get some replaceable grunt to implement it in Unreal, perhaps with some off-the-shelf assets, which is perceived as "good enough".
It will be interesting to see how AI generation of code changes development tooling and the skills required.
this is a surprising statement --- in tust you need to formalize the flow of mutability, which is a skill requirement.
so why do you think rust for the boss seems cheaper than C?
Why Pascal Is Not My Favorite Programming Language - https://news.ycombinator.com/item?id=37044792 - Aug 2023 (2 comments)
Why Pascal Is Not My Favorite Programming Language (1981) [pdf] - https://news.ycombinator.com/item?id=22222117 - Feb 2020 (62 comments)
Why Pascal Is Not My Favorite Programming Language (1981) - https://news.ycombinator.com/item?id=19221143 - Feb 2019 (55 comments)
Why Pascal Is Not My Favorite Programming Language – Current Status - https://news.ycombinator.com/item?id=8273608 - Sept 2014 (1 comment)
Why Pascal is Not My Favorite Programming Language (1981) - https://news.ycombinator.com/item?id=8260694 - Sept 2014 (64 comments)
Nowadays it's all Javascript and more specifically Typescript in my case.
That PDF would be probably much longer about Javascript but it seems Kernighan is quite okay with that language nowadays https://www.youtube.com/watch?v=AB60_uUetJs
'This is a '' character'
However, an empty string and nil are also the same in Pascal, there is no distinction between an empty string and the absence of a string. This is because in early computing, strings weren’t separate objects that you pointed to (and hence could be a null pointer), but more like (usually fixed-size) arrays allocated as part of a larger contiguous memory structure. The array could be empty (based on some length variable), but it couldn’t not be there as part of the fixed memory layout.
Actually, in certain systems strings couldn’t even be empty, in the sense that there was no stored size in addition to the fixed-length array. Instead you padded the rest of the array with spaces. The CHAR type in SQL (as opposed to VARCHAR) is a remnant of that practice.
Also, the problem with pascal string was the length being limited to 255 characters, which wasn't enough even at the time.
Pascal implementations typically support index and range checking, while Ada provides even more extensive memory and concurrency safety.
Fortunately for C, clang's -fbounds-safety seems to be making progress. It's implemented in Apple's LLVM fork, so this now works on macOS:
clang -Xclang -fbounds-safety program.c
I wonder how the non-programmers succeed to write commas correctly, because those follow the same logic: e.g. "red, green, blue". In author's opinion, I guess it should be "red, green, blue," instead.
In Free Pascal (and Delphi) all classes have a "metaclass" (a class that describes the class) and can be used in conjunction with the RTTI to obtain information about an object at runtime - including its actual class, exposed properties and any optional metadata (like attributes in FP).
This functionality is used by Delphi/Lazarus to serialize and deserialize objects on disk (the form files you mention are such serialized objects but you can serialize other types of objects and in Lazarus -perhaps Delphi too- you can use several file formats) as well as implement the object inspector.
In a way Delphi/Lazarus work kinda like how game engines like Unreal work in that you are working with "live" instances of objects, using generic object inspectors and saving them on disk is done by serializing them (though obviously it is the opposite since Delphi predates most game engines using this approach :-P).
The important aspect with all the above isn't so much the form/component serialization but the language features that make it possible in the first place: metaclasses and RTTI that provides enough information to instantiate and describe objects and classes at runtime.
My own game engine[0] is written in Free Pascal and Lazarus and uses the exact same language features to provide object serialization, property editing and some other stuff (like object diffing that is used for many undo/redo operations). Instead of TComponent/TPersistent (the types Delphi/FCL provide for serialization), it has its own base types that use a more compact file format, optional compressed streams (e.g. for texture data) and external references (for shared assets stored in separate files), but still relies on the same base functionality provided by the language/compiler.
This was an update to the earlier “Software Tools” book, which was written using RATFOR.
If you read the book, it has a very “C in Pascal” coding style, and you can see how uncomfortable it is by doing so.
"People who are still trying to refer to the article are unaware of the capabilities of current Pascal (Delphi/FPC) implementations."
https://wiki.freepascal.org/Why_Pascal_is_Not_My_Favorite_Pr...
What made standard Pascal problematic wrt string handling is that it did not have array NEW nor pointer arithmetic. So if you wanted to heap-allocate ARRAY[1..100] OF CHAR, that was fine; but there was no way to get a pointer to N bytes on the heap where N is determined at runtime; and even if you could do that, somehow, you still wouldn't be able to use that pointer as an array by indexing through it.
Interestingly enough standard Pascal did support allocating variable-length data structures, but only in form of variant records (roughly analogous to discriminated unions in ML or enums in Rust, but with multi-level nesting and the ability to define a common sequence of fields shared by all variants at any level).
One thing that very clearly distinguished (extended dialects of) Pascal from C in the era where the two were competing was that Pascal's units were self-describing. That is, when you compiled a unit, you got a single file with all the metadata for that unit as well as binary object code for linking. Then, when another unit or program did a USES declaration, that would locate the file by name and use the metadata as needed. Conversely, in C you had to deal with header files, and while on the surface it looks kinda sorta like the INTERFACE section of the Pascal unit, it's not quite that because e.g. it needs to #include things it depends on - and that is textual inclusion, not just a metadata reference.
This all meant that working with dynamically loaded type information was much easier in Pascal tooling - it just needed to parse the metadata embedded in the compiled unit files, and each file would only contain metadata for its own types and functions, without contamination from other units that it relies on. This is great for things like code completion and visual UI designers.
"From the point of view of software engineering, the rapid spread of C represented a great leap backward. It revealed that the community at large had hardly grasped the true meaning of the term “high-level language” which became an ill-understood buzzword."
Source: Niklaus Wirth, A Brief History of Software Engineering, 2008 (https://people.inf.ethz.ch/wirth/Miscellaneous/IEEE-Annals.p...)
The way I look at it in terms of cheaper is that you don't need to be as careful, less need to worry about memory leaks which lead to exploits, etc. I.e. you don't have to track every little thing yourself.
Starting to make inroads with larger projects now.. Firefox's audio subsystem is in Rust, while Chromium's is C++ (w/ tools to help detect leaks).
There were free intro libraries (no code), shareware component libraries, and usually a developer version available that came with source code. Plus a culture of open source libraries.
This community was a key strength of Delphi compared to some other choices. I suspect if Borland had really leaned into a combination of open source, plus better support for commercial proprietary solutions, that would have kept the ecosystem alive.
Also of note is that Delphi came with some source code for library components (often useful when understanding usage or debugging or extending).
Here is C.A.R Hoare's on his "The 1980 ACM Turing Award Lecture", guess to what programming language he is indirectly making a point of, regarding 1980 language designers and users have not learned this lesson.
"A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the lower declared bounds of the array. Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980 language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
C0
C1
C2
AS
LD
And an optional AR
I used Pascal a lot for about ten years starting in the late 70's: multiple flavors of UCSD Pascal, consecutive versions of Turbo Pascal, and VAX Pascal, on six distinct hardware platforms. Pascal was readily available for all of them; Modula-2 had no market share at all, so far as I could ever tell.
And market share is the right word: most compilers cost money in those days, sometimes quite a lot of money. Turbo Pascal took off because Borland sold it for $50, as opposed to something like $700 for Microsoft's compilers.
I wrote a letter to Borland International, asking if they were going to release a Turbo Modula-2, and was told yes. I'd have been first in line. It was never released.
So yeah, Modula-2 existed, technically, but it mostly wasn't relevant, at least not for microcomputer programmers.
type
apple = integer;
orange = integer;
Same in Kotlin sadly. The whole point of giving a different names to a type is to make them incompatible.
That's not necessarily binary. I don't recall if perhaps it was in Delphi 1 (the 16-bit version for Windows 3.x and Windows 95), but from Delphi 2 or 3 or so (released around the turn of the century), it could also save form definitions as plain text. oh, and of course since the height of the XML craze (shortly after the turn of the century?), in that format too.
Many, who don't study or know of the history, can get sucked into the rhetoric of C as the "superior language" versus the reality of it being a heavily corporate pushed language. Pascal was in the way, so got hammered by bad press. Same sort of thing happens today, in these weird programming language scuffles. Rust, Zig, Vlang, Dlang, Odin, C3, etc... If a competitor is in the way, strange one-sided and highly critical blogs can materialize.
By 1987, pretty much any of Kernighan's criticisms involving Pascal and derivatives were moot. But he never retracted or modified what he got wrong or had changed. He had many years to do so. That was before the 2nd edition of his book (The C programming language in 1988). And before ANSI C (1989). Turbo Pascal and Object Pascal were out, which both took lessons from Modula-2, and were widely known successes.