3 ms·

""" The ability to interoperate safely and at a high-level between different languages, from managed C++ to F#, has greatly accelerated development on the Micr

by godDLL 17y ago

""" The ability to interoperate safely and at a high-level between different languages, from managed C++ to F#, has greatly accelerated development on the Microsoft platform. The resulting libraries, like Windows Presentation Foundation, are already a generation ahead of anything available on any other platform. Linux and Mac OS X do not currently have the luxury of a solid foundation like the CLR. Consequently, they are composed entirely from uninteroperable components written in independent languages, from unmanaged custom C++ dialects to Objective C and Python. """ And that's the problem they're trying to solve. Bring some C# Microsoft love to poor dated OS X (and the like). I abstain.

ramchip 17y ago
Making portable applications isn't a solved problem. There's Java. It's decent, especially with Clojure and other JVM languages, but I find the idea of a more powerful language (like OCaml) not without merits. Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization.
- amock 17y ago
  Why do you need HLVM to do this? OCaml already runs on multiple platforms, so all that's needed is some library work. The same is true for Haskell, Standard ML, Lisp, and many other languages. If you want to write languages for multiple platforms HLVM sounds useful. If you want to write portable programs, why not work on improving the libraries available for an existing language?
  - megaman821 17y ago
    I don't think that is the point. I am pretty sure the author was using the CLR as an example. You could write WPF applications using F#, IronPython, or IronRuby because the are all compile CLR code. If the most popular languages on Mac and Linux all compiled down to LLVM they would be a lot more inter-operable like the CLR languages. It would be much easier to leverage the Cocoa framework from Python, Lisp, or Java if all were build on the LLVM (or the HLVM which is built on the LLVM).
    - amock 17y ago
      That makes sense. MacRuby is using the Objective-C runtime as the common denominator but I'd love to see other languages do that same.
- godDLL 17y ago
  You're right, portability of applications is an issue. Though I'd say it's deeper than toolkits, deeper than libraries or frameworks, and deeper than languages. It starts in the interaction model. I like what Apple is doing with this (think iWork on the Mac and iWork on the iPad), and I'd hate to see that go away. You could argue all you want that the Windows 7 desktop is not that different from the MacOS 10.5+ desktop, not that different from the Web interaction model; you'd have your points and I'd have mine. My main one is that if it feels different, then it is (a bit of a duck-typing mindset, understandably). And if it is different, then it requires fundamentally different software application, even if the problem domain you're tackling is the same. Some low-level things might be portable, but many won't be; whatever's closer to hardware (audio, storage, search, video, rasterization) is more likely to be reasonably and defensibly portable. Everything else I want to be specific to the interaction model of a given device, within reason. Objective-C and OCaml are fairly high-level, but that's not what they are going after here; they are going after the likes of WPF and Cocoa and Cocoa Touch, general-purpose high level libraries of code. And that's exactly what I would not want to ever happen. Let's not go there. Because it would be terribly silly.
- cabalamat 17y ago
  > Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization. What in particular about the JVM prevents Clojure from being able to do tail-call optimization? My (admittedly naive) understanding of TCO is that it involves turning tail recusion into a loop, and Java can certainly handle loops OK.
  - WilliamLP 17y ago
    I'm naive too, but apparently there are use cases for TCO for state machines where the tail calls are between various functions, not necessarily in a simple loop.
  - crux_ 17y ago
    > My (admittedly naive) understanding of TCO is that it involves turning tail recursion into a loop This is close, but not the full story. TCO turns tail recursion into a GOTO (well, a goto-with-arguments). In the case of a single function which tail-calls itself, this becomes a loop, but for multiple functions that are mutually recursive, that's not the case. Note that the issues with the lack of TCO boil down to efficiency: there are ways of faking TCO atop a runtime that does not support it (meaning deeply tail-recursive code will run, rather than overflow the stack), but they come at with a runtime cost.

by godDLL 17y ago

ramchip 17y ago

Making portable applications isn't a solved problem. There's Java. It's decent, especially with Clojure and other JVM languages, but I find the idea of a more powerful language (like OCaml) not without merits. Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization.

amock 17y ago
Why do you need HLVM to do this? OCaml already runs on multiple platforms, so all that's needed is some library work. The same is true for Haskell, Standard ML, Lisp, and many other languages. If you want to write languages for multiple platforms HLVM sounds useful. If you want to write portable programs, why not work on improving the libraries available for an existing language?
- megaman821 17y ago
  I don't think that is the point. I am pretty sure the author was using the CLR as an example. You could write WPF applications using F#, IronPython, or IronRuby because the are all compile CLR code. If the most popular languages on Mac and Linux all compiled down to LLVM they would be a lot more inter-operable like the CLR languages. It would be much easier to leverage the Cocoa framework from Python, Lisp, or Java if all were build on the LLVM (or the HLVM which is built on the LLVM).
  - amock 17y ago
    That makes sense. MacRuby is using the Objective-C runtime as the common denominator but I'd love to see other languages do that same.
godDLL 17y ago
You're right, portability of applications is an issue. Though I'd say it's deeper than toolkits, deeper than libraries or frameworks, and deeper than languages. It starts in the interaction model. I like what Apple is doing with this (think iWork on the Mac and iWork on the iPad), and I'd hate to see that go away. You could argue all you want that the Windows 7 desktop is not that different from the MacOS 10.5+ desktop, not that different from the Web interaction model; you'd have your points and I'd have mine. My main one is that if it feels different, then it is (a bit of a duck-typing mindset, understandably). And if it is different, then it requires fundamentally different software application, even if the problem domain you're tackling is the same. Some low-level things might be portable, but many won't be; whatever's closer to hardware (audio, storage, search, video, rasterization) is more likely to be reasonably and defensibly portable. Everything else I want to be specific to the interaction model of a given device, within reason. Objective-C and OCaml are fairly high-level, but that's not what they are going after here; they are going after the likes of WPF and Cocoa and Cocoa Touch, general-purpose high level libraries of code. And that's exactly what I would not want to ever happen. Let's not go there. Because it would be terribly silly.
cabalamat 17y ago
> Clojure has run into a lot of problems due to the JVM, probably the most famous one being the lack of tail call optimization. What in particular about the JVM prevents Clojure from being able to do tail-call optimization? My (admittedly naive) understanding of TCO is that it involves turning tail recusion into a loop, and Java can certainly handle loops OK.
- WilliamLP 17y ago
  I'm naive too, but apparently there are use cases for TCO for state machines where the tail calls are between various functions, not necessarily in a simple loop.
- crux_ 17y ago
  > My (admittedly naive) understanding of TCO is that it involves turning tail recursion into a loop This is close, but not the full story. TCO turns tail recursion into a GOTO (well, a goto-with-arguments). In the case of a single function which tail-calls itself, this becomes a loop, but for multiple functions that are mutually recursive, that's not the case. Note that the issues with the lack of TCO boil down to efficiency: there are ways of faking TCO atop a runtime that does not support it (meaning deeply tail-recursive code will run, rather than overflow the stack), but they come at with a runtime cost.