111–120 of 204 posts
Earlier quoted context omitted.
QBE[1] seems to be what you're looking for. It "aims to be a pure C embeddable backend that provides 70% of the performance of advanced compilers in 10% of the code". Previous discussion on HN: https://news.ycombinator.com/item?id=11555527 [1]: http://c9x.me/compile/
Neat, I missed this when originally posted. Sadly, it falls apart on the "cross-platform" requirement (does not appear to support Windows).
Earlier quoted context omitted.
I work with .NET, Java and C++ stacks. In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. The biggest issue is of course than one needs to learn how to optimize code, use the right algorithms and data structures in first place.
> In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. If the program runs on the user's machine, I'm pretty certain the users WILL notice the difference, memory wise.
Earlier quoted context omitted.
I agree mostly. Any Java application which does not need GUI other than web is just fine in most use cases.
UIs though... I haven't worked with a single Java based GUI application that did feel smooth, fast and efficient. I wonder why that is.
Earlier quoted context omitted.
Yes I agree with you, I am not trying to say it is impossible to write a C interpreter/compiler in Lisp. Any Turing-complete language can do that. I'm more so interested in the built-in metaprogramming capabilities, and it's evident that reader macros go far in that direction. On a different note, would you say that Lisp's syntax is better because it makes an easy compile target (i.e. it's easier to compile C into Li…
> Lisp's syntax is better because it makes an easy compile target Not quite. Lisp's syntax is (mostly) irrelevant. Lisp's design is better because you don't have to worry about syntax to use Lisp as a compile target. There's a huge conceptual difference between (eval '(some code)) and (using Javascript or Python as an example) eval("Some code") In JS/Python case you are passing a string to EVAL. In the Lisp case you…
Interesting. But I feel like Racket is a better framework for quickly prototyping new languages.
Earlier quoted context omitted.
You cannot. Because Lisp is homoiconic, you don't code in (what I personally believe to be) reasonable syntax, you code in abstract syntax trees. Lisp is so easy to metaprogram because everything is parentheses and the burden is on the user, not the parser, to determine the program's abstract syntactic structure. So, Lisp can only metaprogram its own syntax, you can't introduce a C-like syntax.
> Because Lisp is homoiconic, you don't code in (what I personally believe to be) reasonable syntax, you code in abstract syntax trees. There's no reason a regular macro couldn't implement a basically C-like syntax (though it would have Lisp, not C, tokenization rules, to the extent that those are different) on what is passed as its argument. The actual call to the macro would have typical Lisp syntax, but what the m…
Earlier quoted context omitted.
> Because Lisp is homoiconic, you don't code in (what I personally believe to be) reasonable syntax, you code in abstract syntax trees. There's no reason a regular macro couldn't implement a basically C-like syntax (though it would have Lisp, not C, tokenization rules, to the extent that those are different) on what is passed as its argument. The actual call to the macro would have typical Lisp syntax, but what the m…
Well, for regular macros, only if your C syntax was in a string. Otherwise, lisp would try to tokenize it, and choke. Heck, if your lisp of choice offers an eqivalent of TCL's uplevel, you wouldn't even need a macro, just a function.
Which is why I said normal (rather than reader) macros could do a "basically C-like syntax" but with Lisp tokenization rules.
Earlier quoted context omitted.
I work with .NET, Java and C++ stacks. In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. The biggest issue is of course than one needs to learn how to optimize code, use the right algorithms and data structures in first place.
> In many use cases, C++ might win the benchmark game, but the end user will not notice any difference in human time. If the program runs on the user's machine, I'm pretty certain the users WILL notice the difference, memory wise.
Earlier quoted context omitted.
Do you mean macros? Could you re-implement a language such as C as a macro? And have it be about as fast as GCC? I didn't think they were that sophisticated.
Yes, you could. You'd implement a program to take C code and emit an equivalent Lisp program (i.e., parse C and emit the tree into Lisp), then compile the Lisp program. The annotations and care the parser/semantic analysis code uses will provide the semantics of C. This will, however, not "play" like C without a great deal of work. You will be dragging an entire Lisp VM around and have to shake all of that out to act…
Earlier quoted context omitted.
Android does a bunch of things to keep you off the UI thread(IO throws an exception, handlers, Async Tasks, etc). You still have to GC at some point and when that happens chances are you're going to drop frames. Unless you're very aware of the garbage you're creating you'll take more than ~5ms which is usually enough to push you over 16ms with the other work that goes on during a frame.
Measure Java performance by how Android works is not a good measure. Dalvik is well known on Java world for having a JIT and GC implementations that worse than what most commercial embedded JVM are capable of. Things have improved with ART, but even there there are quite a few performance improvements that Google could eventually do. Soft real time Java GCs for embedded devices are being used in ground station contro…
No they don't. Point me to one windows phone audio app that has low latency audio.