4 ms·

Interesting but ultimately useless. I see something like this come around a couple of time per year. Always fades into oblivion within a year or two. The C cod

Interesting but ultimately useless. I see something like this come around a couple of time per year. Always fades into oblivion within a year or two. The C code will not be optimized C (like a seasoned C developer would write). Java is compiled to byte code which is compiled to machine language. This ugly, unoptimized, generated C is compiled into machine language too. The performance (both memory and CPU usage) of the JVM product will be far superior through. Don't think that you will be writing for embedded devices or device drivers with something like this. it will be a mess. Use C for things that should to be done in C. For Desktop apps, Web apps, or services use Closure ETC. I don't like seeing a square peg rammed into a round hole. It does not work well so don't get too exited lisp programmers. This is an interesting hobby - that is about it.

Xcelerate 14y ago
Your post adds nothing of value to the discussion. You say this project will fade into oblivion -- how do you know this? Do you know, or are you familiar with, the developer's work? How do you know that the C code, when passed through an optimizing compiler, will not be able to compete with the JVM? Have you done these tests? The author already mentioned on this page that the goal is to get it working, and then focus on performance. As far as I can tell, he is a "seasoned C developer" and should be able to construct the generated C so that it compiles efficiently. Without more than mere pessimistic speculation, your failure to contribute any sort of primary or objective information does little more than to make you appear curiously angry at a project in which you have no interest or affiliation. EDIT: Just read through your comment history. A lot of your posts are written in this sort of negative tone. Why do you do that? If you would provide some links or alternative viewpoints, substantiated with a paper or even a blog post, that would be a lot more insightful.
- goggles99 14y ago
  Poorly written C code run through an optimizing compiler will only produce slightly better (at best) executing machine code. Why do this? this should compile to native machine language directly if anything. Would you transform it to C first so you could edit the C? Then what if you want to make a big update using the Closure source? it will overwrite your changes. This approach is not practical, perhaps I am failing to understand any logic as to why you would go with this approach. Portability (between processor architectures) is all I can think of but you will never achieve competitive performance if this is the case. Good C coders write their code differently against different processors and platforms because all machines have different capabilities and resources (strength and weaknesses). The whole point these days of writing something in C to achieve the second highest performance (only behind pure assembly language) in both processor gpu/cpu/other co-processors and at the same time using as little memory as possible (both ram and NV storage).
  - Xcelerate 14y ago
    Okay, now we're getting somewhere. I'm still not sure about the assumption you make in the first line (1. that it will be poor quality C code 2. that its compilation will result in inefficient machine code) -- we would actually need to test it out in order to find out whether that is true. Although I can understand your point in the second paragraph. Indeed, C is a language that is nowadays mostly suited for performance-oriented application. The reason the author translates Clojure code into C, and then into machine code is that this is vastly easier than going straight to native code. As you say, there are so many platforms with different sets of instructions that it would be almost pointless to write an optimized compiler directly from Clojure code to all these platforms, particularly since Clojure is still a somewhat obscure language. The value in doing this is that Clojure promotes good programming practices. In turn, this means that someone who has little experience with embedded systems or hand-optimizing assembly can write better performing code in Clojure -> C -> assembly than if they tried to use C without any experience. Sure, it won't be as fast as if they were an experienced assembly guru, but the difference will only be a factor of 1-2 -- the algorithm is much more important than the compilation, and this is where Clojure shines. One other use is when a project is not performance-oriented, but development-oriented. A fast development cycle is in a lot of situations much more important than the speed at which the code runs. As Clojure is currently limited to the JVM (and Javascript maybe??), extending this support to C now extends the domain of Clojure to almost anything.
    - goggles99 14y ago
      Name a place (besides IOS) where this will enable Closure to run that does not already have a JVM? Now tell me if it would be practical to run it there (printer firmware ETC) VS hand coded C. Speaking of IOS - This IS an area where this may be practical, but that is only because of politics (Apple's tyrannical restrictions). But there are already closure compilers for IOS.
      - pjmlp 14y ago
        > printer firmware ETC Ricoh printers have a JVM builtin, http://ricoh-ridp.com/sdkj http://ricoh-ridp.com/sdkj

Xcelerate 14y ago

Your post adds nothing of value to the discussion. You say this project will fade into oblivion -- how do you know this? Do you know, or are you familiar with, the developer's work? How do you know that the C code, when passed through an optimizing compiler, will not be able to compete with the JVM? Have you done these tests? The author already mentioned on this page that the goal is to get it working, and then focus on performance. As far as I can tell, he is a "seasoned C developer" and should be able to construct the generated C so that it compiles efficiently. Without more than mere pessimistic speculation, your failure to contribute any sort of primary or objective information does little more than to make you appear curiously angry at a project in which you have no interest or affiliation. EDIT: Just read through your comment history. A lot of your posts are written in this sort of negative tone. Why do you do that? If you would provide some links or alternative viewpoints, substantiated with a paper or even a blog post, that would be a lot more insightful.

goggles99 14y ago
Poorly written C code run through an optimizing compiler will only produce slightly better (at best) executing machine code. Why do this? this should compile to native machine language directly if anything. Would you transform it to C first so you could edit the C? Then what if you want to make a big update using the Closure source? it will overwrite your changes. This approach is not practical, perhaps I am failing to understand any logic as to why you would go with this approach. Portability (between processor architectures) is all I can think of but you will never achieve competitive performance if this is the case. Good C coders write their code differently against different processors and platforms because all machines have different capabilities and resources (strength and weaknesses). The whole point these days of writing something in C to achieve the second highest performance (only behind pure assembly language) in both processor gpu/cpu/other co-processors and at the same time using as little memory as possible (both ram and NV storage).
- Xcelerate 14y ago
  Okay, now we're getting somewhere. I'm still not sure about the assumption you make in the first line (1. that it will be poor quality C code 2. that its compilation will result in inefficient machine code) -- we would actually need to test it out in order to find out whether that is true. Although I can understand your point in the second paragraph. Indeed, C is a language that is nowadays mostly suited for performance-oriented application. The reason the author translates Clojure code into C, and then into machine code is that this is vastly easier than going straight to native code. As you say, there are so many platforms with different sets of instructions that it would be almost pointless to write an optimized compiler directly from Clojure code to all these platforms, particularly since Clojure is still a somewhat obscure language. The value in doing this is that Clojure promotes good programming practices. In turn, this means that someone who has little experience with embedded systems or hand-optimizing assembly can write better performing code in Clojure -> C -> assembly than if they tried to use C without any experience. Sure, it won't be as fast as if they were an experienced assembly guru, but the difference will only be a factor of 1-2 -- the algorithm is much more important than the compilation, and this is where Clojure shines. One other use is when a project is not performance-oriented, but development-oriented. A fast development cycle is in a lot of situations much more important than the speed at which the code runs. As Clojure is currently limited to the JVM (and Javascript maybe??), extending this support to C now extends the domain of Clojure to almost anything.
  - goggles99 14y ago
    Name a place (besides IOS) where this will enable Closure to run that does not already have a JVM? Now tell me if it would be practical to run it there (printer firmware ETC) VS hand coded C. Speaking of IOS - This IS an area where this may be practical, but that is only because of politics (Apple's tyrannical restrictions). But there are already closure compilers for IOS.
    - pjmlp 14y ago
      > printer firmware ETC Ricoh printers have a JVM builtin, http://ricoh-ridp.com/sdkj http://ricoh-ridp.com/sdkj