Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ada for the C++ and Java Developer [pdf]

learn.adacore.com

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Ada for the C++ and Java Developer [pdf]

#31

Post by okl »

stephen_g wrote: post #30

Wow, reading through some of these examples, it’s pretty clear where VHDL got it’s syntax! I think I do recall some relation between it and Ada, but it’s almost uncannily close. (Looking up now, it was apparently a requirement for it to be based as much as possible on Ada).

VHDL was initially developed by the DoD back in the time when there was a strong push towards unification of programming languages used in government/defense contracts.

Newer VHDL deviates from Ada syntax in some unfortunate ways that can lead to confusion. For example ".all", in Ada is used to "dereference pointers" while in VHDL it is used to import everything from a library.

Also, coming from Ada you eventually realize that many FPGA vendor's tools are non-conforming to the standard in regards to certain features that are seldomly used by hardware designers but are bread and butter for Ada developers. (enum -> int, int -> enum conversions were partly unsupported in the Xilinx toolchains some years ago, not sure if the problem persists.)

Re: Ada for the C++ and Java Developer [pdf]

#32

Post by okl »

EdwardDiego wrote: post #6

If any Ada users are here, I have question on one section: procedure Main is type Distance is new Float; type Area is new Float; D1 : Distance := 2.0; D2 : Distance := 3.0; A : Area; begin D1 := D1 + D2; -- OK D1 := D1 + A; -- NOT OK: incompatible types for "+" operator A := D1 * D2; -- NOT OK: incompatible types for ":=" assignment A := Area (D1 * D2); -- OK end Main; > The predefined Ada rules are not perfect; they…

There's a library for that: http://www.dmitry-kazakov.de/ada/units.htm

Re: Ada for the C++ and Java Developer [pdf]

#33

Post by okl »

gerryeng wrote: post #24

Ada seems like a really good language. Is there any reason why it isn't more popular?

There's a lot of FUD spread online, partly derived from historic facts, partly total bogus. I like how Luke A. Guest (https://github.com/Lucretia) put it:

"You’ve got to love it when people who [know] nothing about Ada like to tell other people, who know nothing about Ada, things about Ada that they probably heard from someone else, who knew nothing about Ada." -- https://users.rust-lang.org/t/if-ada-is-already-very-safe-wh...

That also applies to lots and lots of comments on this site!

(If you read here, hello, Luke :-)

Re: Ada for the C++ and Java Developer [pdf]

#34

Post by okl »

_0w8t wrote: post #8
pjmlp wrote: post #4

Earlier quoted context omitted.

Yes they are bounds checked, at compile time, or runtime if not able to prove them at compile time. Overflow is checked. However both can be disabled via unsafe code pragmas if so desired. As of Ada 2012, the SPARK proof system was integrated into Ada and you can also use DbC as formal proofs. Many of the use cases that in C++ would require new/delete are handled by the compiler itself, thus there is an error if when…

In addition Ada allows dynamically-sized arrays to be allocated on the stack and to be returned from a function. Efficient implement of the latter requires rather non-trivial support on the compiler side and C/C++/Rust have nothing like that. Yet in many cases it allows to eliminate new/delete and simplify code. For example, just consider if C allowed to return a plain C string from a function without any heap alloca…

There a two stacks, the call stack, and a stack for returned values of dynamic size, not very complicated, is it?

Re: Ada for the C++ and Java Developer [pdf]

#35

Post by okl »

foerbert wrote: post #14
MaxBarraclough wrote: post #10

Earlier quoted context omitted.

Although Ada still isn't fully memory safe. Read-before-write causes undefined behaviour, if I recall correctly.

Accesses - pointers - are automatically nulled when declared. So you won't silently screw up who-knows-what with an uninitialized access, though yeah, it's not perfectly safe.

You can also declare access types as "not null" in which case initialization is compulsory.

http://www.ada-auth.org/standards/12rm/html/RM-3-10.html#p13...

Re: Ada for the C++ and Java Developer [pdf]

#36

Post by okl »

MaxBarraclough wrote: post #27
pjmlp wrote: post #22

Earlier quoted context omitted.

You can put a pragma Warning_As_Error (" never assigned "); or the respective compiler switch on GNAT. Other compilers have similar switch. Heck even C and C++ have them, although few make use of them.

Also, I think Ada is fully memory-safe but for initialization. That is to say, the only way in which it's not memory-safe, is regarding uninitialized variables. (That's assuming of course that you don't disable checks.) I'm not sure if it lets you shoot yourself in the foot regarding invalid type conversions, misuse of unions, that kind of thing.

https://www.adacore.com/uploads/techPapers/rtchecks.pdf

Re: Ada for the C++ and Java Developer [pdf]

#37

Post by tragomaskhalos »

gerryeng wrote: post #24

Ada seems like a really good language. Is there any reason why it isn't more popular?

Ada was standard in aerospace and defence projects in the UK when I started in s/w back in the 80's, although personally never worked in those areas. It may be that its perceived lack of popularity is tied to its association with those rather more secretive lines of work, although that doesn't in and of itself explain why it didn't become more broadly used - other commenters have mentioned cost, and that consideration was enough to kill another technically excellent language (Smalltalk).

My gut perception of Ada is unfortunately mediated through the murky lens of its bastard offspring PL/SQL, which is by a good distance the least favourite of any language I have ever used, although I'd be willing to entertain the argument that this is in large part due to all the ugly and ill-considered bits nailed onto it by Larry's mob rather than inherent defects in the parent language itself.

Re: Ada for the C++ and Java Developer [pdf]

#38

Post by thesuperbigfrog »

One of my favorite features of Ada 2012 are the design-by-contract checks taken from Eiffel[0]:

Preconditions: "a condition or predicate that must always be true just prior to the execution of some section of code or before an operation"[1]. It is up to the caller (client) to set up the preconditions and ensure that they are true before calling the code in question. If any preconditions are not met, it is the fault of the caller (client).

Postconditions: "a condition or predicate that must always be true just after the execution of some section of code or after an operation"[2]. The code in question guarantees that the postconditions will be true after the code is executed. If any postconditions are not met, it is the fault of the callee (supplier).

Invariants: conditions or predicates that "can be relied upon to be true during the execution of a program, or during some portion of it"[3]. Both parties must ensure the invariants hold.

These features make it very easy to determine where a bug is in the code and make it very explicit what is expected of the caller (client) and callee (supplier).

They act as run-time sanity checks and push Ada / SPARK code in the direction of Haskell function signatures and types. With proper preconditions, postconditions, and invariants in place I think it should be possible to implement a QuickCheck-style[4] testing system to provide some empirical checks if SPARK proof checking is not used.

I would love to see these design-by-contact features added to Rust, C++, and even C.

[0] https://www.eiffel.com/values/design-by-contract/introductio...

[1] https://en.wikipedia.org/wiki/Precondition

[2] https://en.wikipedia.org/wiki/Postcondition

[3] https://en.wikipedia.org/wiki/Invariant_(mathematics)#Invari...

[4] https://en.wikipedia.org/wiki/QuickCheck

Re: Ada for the C++ and Java Developer [pdf]

#39

Post by bXVsbGVy »

okl wrote: post #31
stephen_g wrote: post #30

Wow, reading through some of these examples, it’s pretty clear where VHDL got it’s syntax! I think I do recall some relation between it and Ada, but it’s almost uncannily close. (Looking up now, it was apparently a requirement for it to be based as much as possible on Ada).

VHDL was initially developed by the DoD back in the time when there was a strong push towards unification of programming languages used in government/defense contracts. Newer VHDL deviates from Ada syntax in some unfortunate ways that can lead to confusion. For example ".all", in Ada is used to "dereference pointers" while in VHDL it is used to import everything from a library. Also, coming from Ada you eventually re…

> For example ".all", in Ada is used to "dereference pointers" while in VHDL it is used to import everything from a library.

In VHDL, the meaning of the suffix all depends on kind of the prefix. When the prefix is an object of access type, it behaves similarly to Ada.

Re: Ada for the C++ and Java Developer [pdf]

#40

Post by 13415 »

gerryeng wrote: post #24

Ada seems like a really good language. Is there any reason why it isn't more popular?

My personal reasons as someone who has learned the language quite intensively but ultimately decided not to use it: (i) Vendor lock-in and too much future dependence on Adacore (other commercial Ada compilers do not count as alternatives to me because they are super-expensive), (ii) I can't always use the MGPL and would prefer MIT licenses of important Ada packages, (iii) the user community is split in a weird way between very professional aerospace and high integrity systems engineers and fairly dilettante hobbyists, but not many users in the space in-between those extremes, and (iv) not enough libraries for mundane tasks/operating system integration/GUIs.

I'm currently using Go. Although I would prefer Ada as a language, (iv) is in the end decisive for my tasks. If I used Ada I'd spend half of my time reinventing the wheel or interfacing with C libraries. I'm hoping to find a use for it in the future, though.

Post reply on HN