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?

>>71

you're experience has maid you clothes minded. Going to asm for efficiency is something you should leaf to the compiler, as it can be done well by the compiler and by adding your own bits of assembly, you alienate other architectures. And hand coded asm could be sub optimal. You should only use asm to access features that are not otherwise available, like in a wrapper library that configures interrupts or something.

You should only use asm to access features that are not otherwise available

although it would be appropriate to use assembly for routines that can be implemented with special assembly ops that the compiler isn't clever enough to employ. I like to think that a sufficiently clever compiler can exist, but I don't think it can for every language. In particular C. So I actually take most of >>72 back, but only for advanced opcodes that can only be used in special situations, like SMD stuff.

>>71
So you would rather use a terribly designed language than to write a few lines of code required to use the FFI? Seriously?

You shouldn't need inline assembly anywhere except in kernels and some
case of extreme optimizations. Requiring a modern language to support that is outright ludicrous.

By the way, check this:
package main
// #include <stdio.h>
// int f(int a, int b) { return a * b; }
import "C"
func main() {
    C.printf(C.CString("%d\n"), C.f(2, 3))
}
Yes, I just defined and called a C function in inline Go. See that? It's not that hard to use C stuff.
However, I see no reason at all to require my language to support anything more than that. Inline ASM? C as a subset of the language? What purpose would any of that serve in the long run except to complicate my job?

By the way, there's no such thing as asm block in C. What you're referring to is a C extension included in whatever C-based language you're using.