HLC

Posted by Admin on 06-Jan-2013 03:12

Just  checked the docs and it does look like this is still available...  although nothing changed there lately, wonder why this can't be extended  a bit to allow development of modules/additions that can be easily  integrated and used if we can get something like CPAN for Perl modules,  might as well be an 'app store' for i**Whatever fans

Now,  shared buffers and variables are not that commonly used nowadays...  would be great if we can just pass buffer handles back-forth HLC to  start with.

Yeah,  I do know most peoples won't be happy to get hands dirty and write  low-level C but still there might be some that will do it and guess that  will really make the environment more easily extendible...

All Replies

Posted by Admin on 06-Jan-2013 04:04

> Now,  shared buffers and variables are not that commonly used nowadays...  would be great if we can just pass buffer handles back-forth HLC to  start with. 

More precisely I'd say that shared buffers aren't supported anymore in the recommended way of programming in the 21st century (OO).

> Yeah,  I do know most peoples won't be happy to get hands dirty and write  low-level C but still there might be some that will do it and guess that  will really make the environment more easily extendible...

You're right. But the question is what are the use cases? On the GUI client (and .NET AppServers), writing custom .NET Assemblies seems a much better alternative.

Posted by Admin on 06-Jan-2013 04:45

mikefe wrote:

> Now,  shared buffers and variables are not that commonly used nowadays...  would be great if we can just pass buffer handles back-forth HLC to  start with. 

More precisely I'd say that shared buffers aren't supported anymore in the recommended way of programming in the 21st century (OO).

right, but I didn't meant to hurt anyone's feelings

> Yeah,  I do know most peoples won't be happy to get hands dirty and write  low-level C but still there might be some that will do it and guess that  will really make the environment more easily extendible...

You're right. But the question is what are the use cases? On the GUI client (and .NET AppServers), writing custom .NET Assemblies seems a much better alternative.

some use cases are already there in the doc... access multimedia and special devices, data sources (files, databases).

as for .net I know it might be hard to believe but there are life out of  the ms$ ecosystem, using shared/dynamic-link libraries can be used but  HLC could be more easily employed for portable code if there would be a  module management solution in place... in any case being able to pass  buffers/temp-table handles around does make a lot of difference in  performance for cases when 'result sets' need to be transferred (yeah,  some form of serialization or custom structures as memory pointers does  work but it's a waste of time if one can directly put/get that data in/from a  'buffer' structure).

This thread is closed