Re: If not Ada, what else...

["Björn Lundin" <b.f.lundin@gmail.com>]

On 2015-07-29 20:27, Paul Rubin wrote:
> Björn Lundin <b.f.lundin@gmail.com> writes:
>> See Ada.Containers.*
> 
> Will look there, but those kinds of containers are more useful with GC.

I think you are missing the point.
Many things in Ada is done without allocating with 'new'
And things that are, if OO, may inherit from
Ada.Finalized, which gives a call to the objects'
'Finalize' method where deallcation - if necessary - can be done.
So, the user does not fiddle with new/free.



  declare
  package Stuff_Pkg is new Ada.Containers.Doubly_Linked_Lists(Stuff_Type);
  Stuff_data : Stuff_type;
  Stuff_List : Stuff_Pkg.List
  begin
   for i in 1 ..100 loop
     Stuff_list.Append(Stuff_data):
   end loop;

   -- use stuff_list here

  end;

 --no mem leak here
> 
>> How is Haskell doing in Ada territory, like concurrency etc ?
> 
> It's partly on the implementation, but GHC's concurrency is far superior
> to GNAT's in my opinion.  GNAT uses Posix threads while GHC supports
> lightweight threads with parallel garbage collection.  It can handle
> millions of concurrent threads on a large server:
> 
>   http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf
> 
> GHC also supports software transactional memory (STM), that let threads
> composably share mutable data without the traditional hazards of lock
> inversion etc.  Haskell's type system statically verifies that STM
> operations aren't improperly mixed with I/O that could wedge the runtime:
> 
>   http://book.realworldhaskell.org/read/software-transactional-memory.html
> 
> GHC also supports various kinds of deterministic parallelism, like the
> "par" operator that lets you very simply annotate that two operations
> can be done in parallel (on separate cpu cores):
> 
>   https://donsbot.wordpress.com/2007/11/29/use-those-extra-cores-and-beat-c-today-parallel-haskell-redux/
> 
> The cool thing about this is it doesn't affect the datatypes in the
> program, and if you use it improperly, your program might run slower
> instead of faster, but it will still find the right answers.
> 
> There are also data parallelism libraries that will let you spin array
> computations off to SIMD units or GPU's, but Ada probably has similar
> libraries.
> 
> There is an online book about parallel and concurrent programming in
> Haskell (scroll down for the TOC):
> 
>   http://chimera.labs.oreilly.com/books/1230000000929/index.html
> 
> ================
> 
> Where Ada beats Haskell is in deterministic timing and memory footprint.
> SPARK has ways to verify that an Ada function can't possibly throw an
> exception.  That's difficult in Haskell, because programs constantly use
> the memory allocator, and there can also be unpredictable GC pauses at
> any time in the program.  Ada can also compile to small cpu targets
> because of its small or nonexistent runtime system.
> 
> So I'd see the archetypal Ada application as a critical embedded system
> like a jet engine controller, while the archetypal Haskell application
> is something like a compiler or internet server that must not give wrong
> answers, but where a pause in execution (or even an OOM crash followed
> by a failover or workaround) is annoying but not disastrous.
> 

Interesting reading

-- 
--
Björn