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-09 2:42

>>250
modern x86 can only function by breaking down the complex instructions to a reduced set for the hardware first.
And that happens in the core, where clock speeds can be pushed much higher. Here's an analogy that makes the situation clearer: suppose you can choose two types of slaves (this is 4chan after all), one can do everything really quickly but also only knows really simple commands, and another that isn't that quick but you can tell them to do something in one word what would take a few dozen with the other, and they'll take their time doing it. You can only talk to one slave at a time. Which type will you choose a few dozen of if you're the master and want to get them to do something like build a house?

With the first type, all your time is going to be spent telling them one-by-one what to do in excruciating detail, while all the others are just waiting for their next little command since they finished their last one almost immediately after you told them. Not a good use of resources and overall throughput is going to suck. With the second, you'll spend much less time telling them what to do, and they'll spend much more time actually doing something rather than waiting. You might even have enough time to go spend some time with your friends. You are the memory. The slaves are cores of a multicore processor. Your friends are peripheral devices. The first type is RISC. The second is CISC. Get it now?

I'm not keen on turning this into personal insults but it appears that your definition of "educated" is more akin to "brainwashed with the beliefs of the academics", and it really shows the lack of actual thinking going on in your head when you can't even seem to understand my argument enough to formulate a defense. I hope the analogy helps.

>>252
The accumulator opcodes are designed for use in calculations involving a long chain of accumulated results, which is relatively frequent. Function return values go there too. It's quite clear that a long-lived variable or set of variables should almost always stay in (e)ax. Multiple encodings are always an issue, they're hard to get rid of but relatively speaking x86 has a lot less of them (and empty space) than some other architectures.

No idea what you're getting at about the Osize/Asize prefices, but that's much better than x86-64's replacing an entire row of register increment/decrement instructions with 64-bit-only prefices. One of the most common operations done in loops. I'm almost willing to bet Intel was NOT pleased with AMD doing that.

>>257
It's probably just you. I have the 8008 manual and it's not bad. Maybe you like the octal notation for opcodes.

We're still using x86 because it's what works the best for general purpose CPUs at the moment. The i432 failed to unseat it, Itanium was pretty dismal, ARM and MIPS are filling the low end of the spectrum where die size/transistor count and power consumption matter more than anything else, POWER, SPARC and the "big RISCs" are in the massively parallel TOP500 supercomputers where they belong (and in applications that can actually make use of all those registers, with specialised hardware/software that ensures all the cores don't fight each other for memory), which leaves x86 to fill in the huge general-purpose/value-performance market.

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