The idea it's good but hard to make it good. A universal language is hard to optimise for a particular language.
Fusion Programming Language
11–20 of 53 posts
Re: Fusion Programming Language
#12> implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.
It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any language that can work with that (i.e. any language).
Re: Fusion Programming Language
#13Re: Fusion Programming Language
#14Reminds me of https://xkcd.com/927/
Re: Fusion Programming Language
#15I'd love to see a comparison to Haxe. https://haxe.org/ I wonder what performance and generated code size/quality look like.
> I've read about Haxe in 2000s, before I started my work on Fusion. They have different design goals: in Haxe you create whole apps, in Fusion you create components to be used from other languages. Haxe has syntax similar to the (now dead) ActionScript, Fusion is similar to C#. Fusion transpiles to C, D, Swift, TypeScript, OpenCL and Haxe does not.
Re: Fusion Programming Language
#16> implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.
I think the target application is writing the same algorithm in multiple places with a guarantee that the logic will be based on a single source of truth. Not unlike Protocol Buffers work to standardize data layout across platforms. It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any lang…
I don't know if fusion is the solution, but I know C isn't.
Re: Fusion Programming Language
#17Earlier quoted context omitted.
I think the target application is writing the same algorithm in multiple places with a guarantee that the logic will be based on a single source of truth. Not unlike Protocol Buffers work to standardize data layout across platforms. It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any lang…
C code called from other languages has terrible ergonomics. Writing it sucks, debugging it sucks, maintaining it sucks. I don't know if fusion is the solution, but I know C isn't.
Re: Fusion Programming Language
#18I'd love to see a comparison to Haxe. https://haxe.org/ I wonder what performance and generated code size/quality look like.
Re: Fusion Programming Language
#19> implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.
I think the target application is writing the same algorithm in multiple places with a guarantee that the logic will be based on a single source of truth. Not unlike Protocol Buffers work to standardize data layout across platforms. It still feels overcomplicated compared to the standard solution of writing a library in a compiled language you like, exposing a C ABI compatible interface, and hooking it up to any lang…
Re: Fusion Programming Language
#20> implementing reusable components (libraries) for C, C++, C#, D, Java, JavaScript, Python, Swift, TypeScript and OpenCL C, all from single codebase Why is this needed? I can't imagine that. I am sure writing code in fusion will produce C++ and Python code which is suboptimal and doesn't fit well in these languages.