Too many languages

There are thousands of programming languages.

The purpose of a programming language is to express programs. The
purpose of learning programming languages is to build up a toolbox for
reasoning about and synthesizing programs in any one given language.

There are diminishing returns on learning programming languages, and
time is scarce.

Therefore one must select between programming languages to study.

A good selection of languages has both
+ breadth
  + satisfies a number of real world economic needs.
+ focus
  + exploits similarity between languages and incremental learning.
  + some unifying basis

A good member of a particular selection meets a number of the
following criteria:
+ Satisfies one particular school of thought on programming languages.
+ Significant difference from predecessors
+ Significant influence on successors
+ Economically significant
+ Advanced i.e. no direct, established and proven heir.
+ A good language.
  + Easy to express programs with
  + Easy to read programs expressed with
  + Easy to reason about programms expressed with

No one of these criteria are sufficient or even necessary conditions.

A bad member satisfies the opposite criteria.

>>120
>le pedophile sage

>>120
The idea isn't to have hardware accelerated garbage collection. It's to have hardware garbage collection period. No software would have to implement anything with regards to memory allocation, only the hardware manufacturers.

All programs would be able to allocate memory as they wish knowing that it will be safely deallocated when all hardware type tagged references to that memory disappear.

This also points out that hardware GC has to go hand in hand with hardware type tagging. You can't have one without the other.

Again, the idea isn't optimization. I don't give two shits about optimization (in this context). I care about sitting ontop of sane abstractions and not having every second software vendor reimplementing something that is a basic service to be expected from the hardware or at least the operating system.

>>122`
>22
>dubs
nice :^)

>>122
I care about sitting ontop of sane abstractions and not having every second software vendor reimplementing something that is a basic service to be expected from the hardware or at least the operating system.
Then only use programs written for JVM. Here, I solved your problem.

Or do you perchance believe that if you get a new incompatible hardware platform, suddenly you'd get more programs that JVM features? LOL.

I mean, what you're saying is that you don't want faster GC, you want enforced GC. Well, good luck with that.

>>122
Once you have hardware GC, the next step are hardware continuations and closures! Even C has escape continuations (jmp_buf). You would need some kind of dynamic-wind for exception handling.

>>125
Assembly has continuations!
jmp penis
now, jump on my penis

>>124
He said sane abstractions, not JVM.

>>126
Not a sane abstraction, ya dumb goy.

>>1
Advanced i.e. no direct, established and proven heir.
shove it up your ass, fancy boy.

>>124
You didn't solve shit.

JVM != All software running on my machine.

What do you mean incompatible? You can write a C compiler for any machine and emulate the lack of GC. There are C compilers targetting the JVM, and Common Lisp, and other advanced platforms.

>>122
And how do you think the hardware manufacturers would go about implementing a feature as advanced as garbage collection? They would micro code it, performance would be scarcely better than what pure software and a well thought out ISA could achieve, and you'd be stuck with said mediocre implementation forever.

What you're proposing has been tried before; the result was called the iAPX 432 and it was a miserable failure. Nobody has seriously proposed making hardware do so much work since the 1980s.

>>131
Nobody has seriously proposed making hardware do so much work since the 1980s.
Scratch that; I forgot about Jazelle. ARM also did what you're proposing in the 90s; they also ultimately realized that it was better not to prematurely specialize their hardware.

>>131
The iAPX 432 was designed when anything larger than a 68000 needed multiple chips. With today's technology the whole iAPX 432 takes up less space than the non-cache part of a modern x86 CPU with all its decoder baggage. What are all these transistors being used for? Dynamic translation and out-of-order execution to make an obsolete, hard to decode, inefficient instruction set run fast.

>>133
Nobody holds up x86 as an example but its frontend is still simpler and more conducive to a performing implementation than a 432s'. Most transistor gains of the last 10 years have gone into the caches; just make sure a software GC fits in those and you've got all the hardware support you will need.

>>131
>le pedophile sage

>>132
>le pedophile sage

>>134
>le pedophile sage

>>134
Cudder does.

>>134
Cudder has crazy Intel Stockholm syndrome and is obsessed with code density measurements. x86 is serviceable but pretending the RISC people didn't win a long time ago is silly.

>>136-137
You can't Polish a turd.

>>137
>le pedophile sage

disgusting stinky NIGGERS

>>137                                  `
>tfw
>you will never have Cudder kidnap you,
>tie you up and torture you
>strap on a dildo and fuck your tight little goy ass
>shove her used tampons down your throat while calling you a filthy goy scum

>>141
you seem like a stupid faggot sub goyim that deserves to die

her
what!?

BOYS KIDNAP GIRLS. NOT TRANNIES BOYS!

Just got reminded of the Mills architecture by this:

http://jakob.engbloms.se/archives/2004

Now we can argue the commercial viability of this, and how realistic their claimed performance is, but this is what real architecture research looks like.

Note the focus on providing a small set of useful primitives, and a distinct lack of pothead "what if we, like, made a garbage collector, but in hardware?" bullshit.

They're actually pushing stuff over to software - from what I can tell the "Mill CPU" target is basically a VM, and you do an additional compilation pass over the bytecode to adapt it to your specific hardware.

check 'em dubz