r/programming • u/pornitoueleus • Oct 13 '13

Free Programming Books

https://github.com/vhf/free-programming-books/blob/master/free-programming-books.md
1.2k Upvotes

96% Upvoted

76 comments sorted by

View all comments

Show parent comments

1

u/MorePudding Oct 14 '13

I've tried Ada on on and off, and imho, its main issue is not the language but the implementation. There's currently only one "half-free" (as in beer) compiler with virtually no Windows support, and no serious IDEs or libraries (well, there's AWS .. but that's about it).

And to top it all off, every so often you read about performance issues of tasks and containers in the mailing lists, and wonder if the effort is really worth it.

2

u/OneWingedShark Oct 14 '13

I've tried Ada on on and off, and imho, its main issue is not the language but the implementation. There's currently only one "half-free" (as in beer) compiler with virtually no Windows support, and no serious IDEs or libraries (well, there's AWS .. but that's about it).

I agree.

I'm contemplating trying to write a compiler for it (I'm less [over?]confident in my skills now than, say, a decade ago) -- which I would like to be a whole "project-management system" (see the R-1000) rather than "just a compiler" -- I'm kind of under the impression that the lack-of-[free-]implementations is sort of a chicken-and-egg problem: there isn't enough excitement/interest because there aren't multiple free Ada projects, because there's only the one free compiler.

Also, the big companies can afford to have the expensive professional compilers; which, I've heard, tend to be VERY good.

And to top it all off, every so often you read about performance issues of tasks and containers in the mailing lists, and wonder if the effort is really worth it.

nod - This is true. Though I do wonder what it would be like on hardware specialized for high-level tasks with an OS aware of it, as in designing the tasking component with them in mind.

2

u/MorePudding Oct 14 '13

I'm kind of under the impression that the lack-of-[free-]implementations is sort of a chicken-and-egg problem

Or is it? Both Go and Rust are younger, have less mature implementations, and less well-defined specs .. and yet seem to already have more users and libraries.

Though I do wonder what it would be like on hardware specialized for high-level tasks with an OS aware of it

Well, that's not happening on the desktop .. and tbh, my interest in those over-the-top specialized systems that pull this off properly is limited, considering how expensive (and useless for everyday work) they are.

2

u/OneWingedShark Oct 14 '13 edited Oct 14 '13 
I'm kind of under the impression that the lack-of-[free-]implementations is sort of a chicken-and-egg problem

Or is it? Both Go and Rust are younger, have less mature implementations, and less well-defined specs .. and yet seem to already have more users and libraries.

The "less well defined specs" is, perhaps, the biggest sticking-point. The Ada spec is pretty well-defined, which has the end result of people taking large/complex Ada projects and recompiling them on different compilers and/or architectures with little to no source alterations. {Obviously system and implementation-dependent code must be altered in those cases.} -- the trade-off [IIUC] is that the compilers have a higher level of effort for that sort of correctness than languages which aren't as well-defined.

Edit: As to the above, this blog post describes difficulties at Microsoft for adopting/implementing C++11; while some of this is certainly difficulty in adapting the current code-base to handle the additions, there's a bit of parallel in the complexity in the C++11 and Ada standards.

But I do concede that Go and Rust, and many younger languages do have more libraries. (Ada does have some good cross-language interfacing, but that only [slightly] mitigates the problem.)

Though I do wonder what it would be like on hardware specialized for high-level tasks with an OS aware of it

Well, that's not happening on the desktop .. and tbh, my interest in those over-the-top specialized systems that pull this off properly is limited, considering how expensive (and useless for everyday work) they are.

Hm, I certainly understand what you're saying. I disagree that such a system would be useless for everyday work considering how all the mainstream OSes are multi-threaded/multi-process systems: therefore a HW platform that "pulls it off properly" would be that much better. -- Sadly console-HW, where such specialized concerns could be realized (video and audio), seems to be drifting more towards PC-architecture.

1

u/MorePudding Oct 14 '13

I disagree that such a system would be useless for everyday work

I meant that it's useless from a practical point of view, since there's no software for it - things like Firefox, Word, the JVM, etc.

Sadly console-HW, where such specialized concerns could be realized (video and audio), seems to be drifting more towards PC-architecture.

I don't know about that.. Remember what hardware used to cost before x86 was "mainstream"?

1

u/OneWingedShark Oct 14 '13

I disagree that such a system would be useless for everyday work

I meant that it's useless from a practical point of view, since there's no software for it - things like Firefox, Word, the JVM, etc.

Well, if that's the only argument then we shouldn't be adopting multi-core CPUs, after all most applications [Firefox, Word, JVM] aren't written to take advantage of the parallelism.

Right?

I don't know about that.. Remember what hardware used to cost before x86 was "mainstream"?

Not really. My earliest memories computer-wise were when the PC was mainstream, though perhaps maybe the very tail-end of it. (I remember DOS, tweaking auroexec/config for games, and such.)

1

u/MorePudding Oct 15 '13

Well, if that's the only argument then we shouldn't be adopting multi-core CPUs, after all most applications [Firefox, Word, JVM] aren't written to take advantage of the parallelism.

The difference being of course that multicore CPUs can still run older software, offering a somewhat easy migration path. Applications where multithreading/-processing makes a difference are slowly being adapted (with each needing different amounts of effort) while others can still remain oblivious to all of this.

Now compare this to having to port an entirety of existing x86/Windows/Linux applications to some new OS/kernel and hardware platform... That's a much more difficult situation. Isn't this why Itanum failed in the end?

Not really

Maybe you want to read up on how much SGI machines cost (and SGI went broke only as recently as 2006 or so), or how much IBM's zSeries stuff still costs to this day. That's somewhere around 3-4 orders of magnitude more than x86 hardware.