4 ms·

The GNU ADA compiler was first released in 1995: https://en.wikipedia.org/wiki/GNAT https://en.wikipedia.org/wiki/GNAT

by shrubble 6mo ago

Narishma 6mo ago
That's a decade too late.
- cmrdporcupine 6mo ago
  Let's just be honest that even if there was a free compiler in 1985 or earlier, there's no way that e.g. someone like Linus Torvalds or an RMS etc would have written various groundbreaking pieces of software on Ada. It was just in an entirely different headspace. I was around then, and culturally there just wasn't this (legitimate) concern with safety in the more "hacker" and Unix community generally. C won headspace at the time precisely because it was minimal and close to the metal while providing the minimum of abstraction people wanted. Which was on the whole fine because the blast radius for mistakes was lower and the machines were simpler.
  - tremon 6mo ago
    > while providing the minimum of abstraction people wanted Yes, I think this is key. I wasn't around in 1985, but on every attempt to write something in Ada I've found myself fighting its standard library more than using it. Ada's stdlib is an intersection of common features found in previous century's operating systems, and anything OS-specific or any developments from the last 30 years seem to be conspicuously absent. That wouldn't be so much of a problem if you could just extend the stdlib with OS-specific features, but Ada's abstractions are closed instead of leaky. I'm sure that this is less of a problem on embedded systems, unikernels or other close-to-hardware software projects where you have more control over the stdlib and runtime; but as much as I like Ada's type system and its tasking model I would never write system applications in Ada because the standard library abstractions just get in the way. To illustrate what I mean, look at the Ada.Interrupts standard library package [0] for interrupt handling, and how it defines an interrupt handler: type Parameterless_Handler is access protected procedure with Nonblocking => False; That's sufficient for hardware interrupts: you have an entry point address, and that's it. But on Linux the same package is used for signal handling, and a parameterless procedure is in no way compatible with the rich siginfo_t struct that the kernel offers. To wit, because the handler is parameterless you need to attach a separate handler to each signal to even know which signal was raised. And to add insult to injury, the gnat runtime always spawns a signal handler thread with an empty sigprocmask before entering the main subprogram so it's not possible to use signalfd to work around this issue either. Ada's stdlib file operations suffer from closed enumerations: the file operations Create and Open take a File_Mode argument, and that argument is defined as [1]: type File_Mode is (In_File, Inout_File, Out_File); -- for Direct_IO type File_Mode is (In_File, Out_File, Append_File); -- for Stream_IO That's it. No provisions for Posix flags like O_CLOEXEC or O_EXCL nor BSD flags like O_EXLOCK, and since enum types are closed in Ada there is no way to add those custom flags either. All modern or OS-specific features like dirfd on Linux or opportunistic locking on Windows are not easily available in Ada because of closed definitions like this. Another example is GNAT.Sockets (not part of Ada stdlib), which defines these address families and socket types in a closed enum: type Family_Type is (Family_Inet, Family_Inet6, Family_Unix, Family_Unspec); type Mode_Type is (Socket_Stream, Socket_Datagram, Socket_Raw); Want to use AF_ALG or AF_KEY for secure cryptographic operations, or perhaps SOCK_SEQPACKET or a SOL_BLUETOOTH socket? Better prepare to write your own Ada sockets library first. [0] https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-C-3-2.html https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-C-... [1] https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-A-7.html https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-A-...
    - OneWingedShark 6mo ago
      To be fair, the file-handling is probably the 'crustiest' part of the standard library. (To use the posix-flags, you use the Form parameter.) The best way to use Ada, IMO, is type-first: you define your problem-space in the type-system, then use that to solve your problem. -- Also, because Ada's foreign-function interface is dead easy, you could use imports to handle things in a manner more amiable to your needs/preferences, it's as simple as: Function Example (X : Interfaces.Unsigned_16) return Boolean with Import, Convention => COBOL, Link_Name => "xmpl16"; You can even put pre-/post-conditions on it.
      - tremon 6mo ago
        Yes, agreed on Ada.Interfaces and the FFI, it's one of the best. The only thing "missing" is auto-import of the definitions in C header files (but there be different dragons). gcc -fdump-ada-specs works fine, but it's effectively a duplication of (non-authoritative) information. That's fine if you're targeting one system, but when targeting multiple systems a single "with Interfaces.C.Syscall_H" quickly becomes a maze of alternative package bodies and accompanying conditional compilation logic. > The best way to use Ada, IMO, is type-first: you define your problem-space in the type-system, then use that to solve your problem I guess that goes to the core of the argument I was trying to make: not that Ada is bad, but that the low-level abstractions in Ada's stdlib are a case of premature optimization. Luckily, I take much less issue with the Numerics and Container parts of the standard library. > To use the posix-flags, you use the Form parameter Do you have any examples/documentation on the use of the Form parameter? According to the RM, it's a String argument so I wouldn't have expected it to support flags. (Also, to correct myself on the signalfd issue: there is GNAT.Signals.Block_Signal to mask signals on the Interrupt_Manager thread)
        OneWingedShark 6mo ago
        Ok, so the Form parameter is implementation defined; this was to allow the implementations the 'wriggle room' to interface with the host-system. For GNAT, these two pieces of documentation are instructive: https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat_rm/the_implementation_of_standard_i_o.html#form-strings https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat... https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gnat_rm/FORM-Strings.html#FORM-Strings https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gnat_rm/FORM-String... (This second one is older documentation, but illustrates how platform-specific Form parameters could be used.) Ada.Text_IO.Create ( File => File, Mode => Ada.Text_IO.Out_File, Name => "test.txt", Form => "shared=no" ); The "maze of alternative package bodies and accompanying conditional compilation logic" is an artifact of C's approach to 'portability' using the preprocessor. Typically, the conditionality should be stable once you abstract it (using the compiler's project-management to select the correct body for a particular configuration) -- As a stupidly trivial example, consider the path separator, for the specification you could have: Package Dependency is Package OS is Function Separator return String; End OS; End Dependency; -- ... Package Dependency is Package body OS is separate; End Dependency; -- Windows separate (Dependency) Package OS is Function Separator return String is ("\"); End OS; -- Classic Mac separate (Dependency) Package OS is Function Separator return String is (":"); End OS; -- VMS separate (Dependency) Package OS is Function Separator return String is ("."); End OS; -- UNIX-like separate (Dependency) Package OS is Function Separator return String is ("/"); End OS; Then in your the rest of your program, you program against the abstraction of DEPENDENCY.OS (and whatever other dependencies you have, likewise), and thus separate out the implementation dependency.

The GNU ADA compiler was first released in 1995: https://en.wikipedia.org/wiki/GNAT https://en.wikipedia.org/wiki/GNAT

Narishma 6mo ago

That's a decade too late.

cmrdporcupine 6mo ago
Let's just be honest that even if there was a free compiler in 1985 or earlier, there's no way that e.g. someone like Linus Torvalds or an RMS etc would have written various groundbreaking pieces of software on Ada. It was just in an entirely different headspace. I was around then, and culturally there just wasn't this (legitimate) concern with safety in the more "hacker" and Unix community generally. C won headspace at the time precisely because it was minimal and close to the metal while providing the minimum of abstraction people wanted. Which was on the whole fine because the blast radius for mistakes was lower and the machines were simpler.
- tremon 6mo ago
  > while providing the minimum of abstraction people wanted Yes, I think this is key. I wasn't around in 1985, but on every attempt to write something in Ada I've found myself fighting its standard library more than using it. Ada's stdlib is an intersection of common features found in previous century's operating systems, and anything OS-specific or any developments from the last 30 years seem to be conspicuously absent. That wouldn't be so much of a problem if you could just extend the stdlib with OS-specific features, but Ada's abstractions are closed instead of leaky. I'm sure that this is less of a problem on embedded systems, unikernels or other close-to-hardware software projects where you have more control over the stdlib and runtime; but as much as I like Ada's type system and its tasking model I would never write system applications in Ada because the standard library abstractions just get in the way. To illustrate what I mean, look at the Ada.Interrupts standard library package [0] for interrupt handling, and how it defines an interrupt handler: type Parameterless_Handler is access protected procedure with Nonblocking => False; That's sufficient for hardware interrupts: you have an entry point address, and that's it. But on Linux the same package is used for signal handling, and a parameterless procedure is in no way compatible with the rich siginfo_t struct that the kernel offers. To wit, because the handler is parameterless you need to attach a separate handler to each signal to even know which signal was raised. And to add insult to injury, the gnat runtime always spawns a signal handler thread with an empty sigprocmask before entering the main subprogram so it's not possible to use signalfd to work around this issue either. Ada's stdlib file operations suffer from closed enumerations: the file operations Create and Open take a File_Mode argument, and that argument is defined as [1]: type File_Mode is (In_File, Inout_File, Out_File); -- for Direct_IO type File_Mode is (In_File, Out_File, Append_File); -- for Stream_IO That's it. No provisions for Posix flags like O_CLOEXEC or O_EXCL nor BSD flags like O_EXLOCK, and since enum types are closed in Ada there is no way to add those custom flags either. All modern or OS-specific features like dirfd on Linux or opportunistic locking on Windows are not easily available in Ada because of closed definitions like this. Another example is GNAT.Sockets (not part of Ada stdlib), which defines these address families and socket types in a closed enum: type Family_Type is (Family_Inet, Family_Inet6, Family_Unix, Family_Unspec); type Mode_Type is (Socket_Stream, Socket_Datagram, Socket_Raw); Want to use AF_ALG or AF_KEY for secure cryptographic operations, or perhaps SOCK_SEQPACKET or a SOL_BLUETOOTH socket? Better prepare to write your own Ada sockets library first. [0] https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-C-3-2.html https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-C-... [1] https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-A-7.html https://docs.adacore.com/live/wave/arm22/html/arm22/arm22-A-...
  - OneWingedShark 6mo ago
    To be fair, the file-handling is probably the 'crustiest' part of the standard library. (To use the posix-flags, you use the Form parameter.) The best way to use Ada, IMO, is type-first: you define your problem-space in the type-system, then use that to solve your problem. -- Also, because Ada's foreign-function interface is dead easy, you could use imports to handle things in a manner more amiable to your needs/preferences, it's as simple as: Function Example (X : Interfaces.Unsigned_16) return Boolean with Import, Convention => COBOL, Link_Name => "xmpl16"; You can even put pre-/post-conditions on it.
    - tremon 6mo ago
      Yes, agreed on Ada.Interfaces and the FFI, it's one of the best. The only thing "missing" is auto-import of the definitions in C header files (but there be different dragons). gcc -fdump-ada-specs works fine, but it's effectively a duplication of (non-authoritative) information. That's fine if you're targeting one system, but when targeting multiple systems a single "with Interfaces.C.Syscall_H" quickly becomes a maze of alternative package bodies and accompanying conditional compilation logic. > The best way to use Ada, IMO, is type-first: you define your problem-space in the type-system, then use that to solve your problem I guess that goes to the core of the argument I was trying to make: not that Ada is bad, but that the low-level abstractions in Ada's stdlib are a case of premature optimization. Luckily, I take much less issue with the Numerics and Container parts of the standard library. > To use the posix-flags, you use the Form parameter Do you have any examples/documentation on the use of the Form parameter? According to the RM, it's a String argument so I wouldn't have expected it to support flags. (Also, to correct myself on the signalfd issue: there is GNAT.Signals.Block_Signal to mask signals on the Interrupt_Manager thread)
      - OneWingedShark 6mo ago
        Ok, so the Form parameter is implementation defined; this was to allow the implementations the 'wriggle room' to interface with the host-system. For GNAT, these two pieces of documentation are instructive: https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat_rm/the_implementation_of_standard_i_o.html#form-strings https://docs.adacore.com/live/wave/gnat_rm/html/gnat_rm/gnat... https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gnat_rm/FORM-Strings.html#FORM-Strings https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gnat_rm/FORM-String... (This second one is older documentation, but illustrates how platform-specific Form parameters could be used.) Ada.Text_IO.Create ( File => File, Mode => Ada.Text_IO.Out_File, Name => "test.txt", Form => "shared=no" ); The "maze of alternative package bodies and accompanying conditional compilation logic" is an artifact of C's approach to 'portability' using the preprocessor. Typically, the conditionality should be stable once you abstract it (using the compiler's project-management to select the correct body for a particular configuration) -- As a stupidly trivial example, consider the path separator, for the specification you could have: Package Dependency is Package OS is Function Separator return String; End OS; End Dependency; -- ... Package Dependency is Package body OS is separate; End Dependency; -- Windows separate (Dependency) Package OS is Function Separator return String is ("\"); End OS; -- Classic Mac separate (Dependency) Package OS is Function Separator return String is (":"); End OS; -- VMS separate (Dependency) Package OS is Function Separator return String is ("."); End OS; -- UNIX-like separate (Dependency) Package OS is Function Separator return String is ("/"); End OS; Then in your the rest of your program, you program against the abstraction of DEPENDENCY.OS (and whatever other dependencies you have, likewise), and thus separate out the implementation dependency.