Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Any decent modern general-purpose languages?

Name: Anonymous 2012-07-25 10:55

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?

Name: Cudder !MhMRSATORI!fR8duoqGZdD/iE5 2012-08-07 5:14

>>242
No, more like IA32 with a 64-bit extension closer to how x86 was extended to 32 bits. MIPS is optimised for silicon area and not much else. Things like branch delay slots(!) and fixed-width instructions make the ISA very rigid and there isn't a whole lot the software can do. In other words the ISA is so tightly coupled to the original hardware implementation that there is little opportunity for optimisation. In contrast, with x86 where many instructions perform multiple basic operations, parallelism almost suggests itself. All these improvements can happen inside the core and immediately benefit existing applications, without changing anything else. If anyone here remembers the days of Socket 370, that's exactly what happened.

The RISCs that have huge instructions that only do 1 thing will require more memory bandwidth to do superscalar/OOE, because by necessity they will need to fetch instructions faster. A 32-bit wide core-memory bus will either need to be widened to 64-bit or have its speed doubled. Not needed with x86: 32 bits is already enough to hold up to 4 instructions and they just need to change the core itself to execute them in parallel.

>>245
Cutting off half the opcode space to do that is hardly desirable, not to mention 256 registers is still way too much for the majority of use cases.

x86 has several 3-address instructions (some of the multiplies and divides), and they were likely added because an analysis of existing code showed that those specific instructions were much more likely to benefit with them present.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List