Any decent modern general-purpose languages?

Assembly: Unportable. No standardised syntax.
Classical Visual Basic: Some good parts. Shit overall.
C: Shitty standard library. Deficient type system. Can't into Unicode. ``Unportable assembly.''
D and C++: Obfuscated boilerplate languages.
Java and C#: Forced OOP.
Common Lisp: Archaic cons-based library. Writing complex macros is a PitA due to the unlispy quotation syntaxes.
Scheme: CL without namespaces.
Clojure and Erlang: Concurrency is unneeded outside of a few very specific applications. Parallelism is where it's at.
OCaml: Great language, only one, deficient, implementation.
Haskell: Academic sex toy.
Forth: Reinventing the wheel over and over.
Ruby: Implicit declarations. Slow as fuck.
Python: Implicit declarations. FioC.
Perl: Brain damage.
PHP: Pretty much shit.
JavaScript: "" == false

It's impossible to list them all but, please, what decent modern general-purpose languages exist?

>>111
Compilers can track the state of numerous registers far more effectively than a human can. They can take a higher level approach to assigning code than a human would reasonably do with a pen.

>>84
Compilers don't do magic. They follow a set of rules like any software to turn common constructs into tighter code.

Depending on the set of optimization algorithms they employ, they can appear to be magical.

But compilers are not aware of the context of the problem you're trying to solve, or the algorithm you're trying to express.

Then you are using the wrong language. You should only express the program as a minimally described idea. The compiler can then find an implementation of the idea that obtains an optimal efficiency on that target architecture and platform.

Suppose you're in a very hot block of code. You find a more clever solution than the ASM output. That's where you use inline assembly.

I'd rather let my genetic peep hole simulated annealing optimizer run on it with test input for two days.

>>>111

TRIPS

Clearly none of you are experienced with Asm, or looked at compiler output (or you have, but can't understand/see a way to do it better, because of the first point). Compilers are a good way to generate code quickly; even at the highest optimisation level none of them can reason about things like register allocation in the same way that a knowledgeable programmer can.

http://en.wikipedia.org/wiki/Register_allocation
http://en.wikipedia.org/wiki/Liveness_analysis
http://en.wikipedia.org/wiki/Category:Data-flow_analysis

People have been saying compilers are better at generating code than programmers, but that's only if you compare to average or below-average Asm programmers.

Use a better compiler.

Go learn Asm and compile any program you want, then look at the Asm output. Find a function and see if you can do it better. Unless you have some ultra-powerful compiler I haven't seen before, chances are you can beat the compiler in size, speed, or both. Perhaps because of the source language semantics the compiler can't do something,

Use a better language. The only defined behavior present should be critical to the correctness of the program.

but YOU (should) know how your program operates and can easily take advantage of things like cross-function register allocation, convenient invariants (you can prove a register will always have e.g. 0, and use it appropriately; the compiler can't), and advanced stack manipulation.

http://en.wikipedia.org/wiki/Interprocedural_optimization

Saying a language is "terribly designed" when it has the capabilities I need (and then some) is simply opinion. And it's not "write a few lines of code required to use the FFI", it's having to do that plus all the other "administrative" cruft surrounding it. In other words the integration is not as seamless as it could be. You said it yourself -- "FFI". Not "embed code directly in the compiler/JIT's output".

This is an implementation issue, not a language issue.

Unless those arguments require extensive computation, chances are that the overhead of preparing to get that done would outweigh the cost of just running them all in 1 thread serially.

This is a decision that can be made by the compiler. Although it would be annoying if in order to take advantage of this optimization, if you had to stuff large expressions to evaluate in parallel inside of function call parameter lists. In the purely functional setting, you can simply define your variables relative to other prior evaluations, and the compiler can create a dynamic evaluator that evaluates expressions as soon as their dependencies are finished, using a number of threads optimal for the target architecture.

Modern processors are now quite good at parallel instruction execution, IIRC these 3 instructions

add b[edx], 5
sub eax, ecx
sub ebx, ecx

are executed in parallel since ~Core 2, with the second two running while the first is waiting on two memory accesses.

cool stuff.