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.

>>80
That jerk sounds like a total idiot. Hardware is pretty bug-free precisely because it's so braindead. Software layers above it are buggy precisely because they are necessarily complicated -- to allow programmers to comfortably inhabit those layers.

That idiot appears to honestly believe that he can have both, "dare to imagine a proper computer – one having an instruction set isomorphic to a modern high-level programming language" -- and that that computer would magically come without the same infestation of bugs that any modern compiler has. And of course it's "political forces" that "strangle at birth" people's attempts to deliver that. I wonder if the Jews microwave his own apartment, introducing bugs into his OS (if the poor goy can't even make a stable high-level abstraction in software, I can't imagine what an abomination his hardware would be).

Oops, reposting in the right thread. Sorry for the noise.

They did make processors with hardware support for JVM bytecodes, but no one wanted to use it.

RISC is best ISC.

>>82
>le pedophile sage

>>81
I don't understand you.

Are you saying that if I gave you a computer that ran fast, had hardware GC, had run-time bounds and type checking that you'd say ``No thank you! That is quite superflous, I'll stick with my x86!''?

>>84
I would jack off and cum hard on your shins.

>>84
I don't know about >>81-san, but I would certainly stick to JVM on AMD64, which would run faster and have better GC (this is guaranteed), and still have run-time bounds and type checking.

Focus an mastering algorithms and data structures instead.

Languages are emphasized too much. You should learn the languages most in demand in each popular paradigm (See TIOBE index.)
Once you've touched each paradigm, you can learn other languages in that paradigm easily.

>>86
That's pretty retarded.

>>84
Are you saying that if I gave you a computer that ran fast, had hardware GC, had run-time bounds and type checking that you'd say ``No thank you! That is quite superflous, I'll stick with my x86!''?
I'm saying that you could as well ask me if I'd refuse a blow job from Santa Claus. I mean, I probably wouldn't, but how is that relevant to anything?

>>89
Because the thing about goals and dreams and things like that is precisely that they are not yet achieved.

I think if you want to say ``Well all that would be nice and a pony too, but it's not worth the effort'' that's far more reasonable, but it seemed like you were saying ``Prfft! GC and bounds checking as a hardware service who wants that?''

>>89
ask me if I'd refuse a blow job from Santa Claus. I mean, I probably wouldn't
faggots should be shoot

>>90
You are wishing for the perfection of a defective model. Like a nice syntax for running SQL queries from your view code, it can only help you do things wrong.

>>92
How does GC and bounds checking ``help you do things wrong''

It obviously doesn't, hence the success of platforms such as the CLR or the JVM.

>>92
>le pedophile sage

>>93
Notice how there exist both CLR and JVM, each having underwent a number of revisions, with CLR getting user-defined value types and reified generics, while JVM got a JIT compiler iterated through several versions of GC (not to mention third party stuff like Azul's C4). Also, other virtual machines, people don't make them because they have nothing better to do, you know, but because they have ideas how to improve them.

How do you think things would look like with a hardware GC?

>>93
Notice how there exist both CLR and JVM, each having underwent a number of revisions, with CLR getting user-defined value types and reified generics, while JVM got a JIT compiler iterated through several versions of GC (not to mention third party stuff like Azul's C4). Also, other virtual machines, people don't make them because they have nothing better to do, you know, but because they have ideas how to improve them.

How do you think things would look like with a hardware GC?

>>95
I think things would look great.

If you're trying to say the costs of experimenting with software are lower than the costs of experimenting with hardware, then I agree with you.

Again, my point is, Economics aside, Hardware with GC, bounds checking and type checking, which dollar for dollar ran programs as fast as hardware today, would be superior to that hardware.

The next best thing of course would be a sane operating system. Shame the momentum of UNIX and VMS killed all the Smalltak, Lisp, Prolog, Oberon and even Java OSes.

I hope Microsoft makes that CLR OS.

>>96
Have you heard of project Oberon? It was pretty cool.

Here's a recent talk about it:
http://www.multimedia.ethz.ch/conferences/2014/wirth
(The last video)

I think, judging by your attitude, you'd find project Oberon much more inspiring than pushing the facilities it provides to hardware (which you understandably think is not worth the effort).

You can download and play around with Bluebottle (a currently worked on successor) today. Aside from being technically quite cool, one neat thing about it is that it's default GUI is a ZUI.

>>98
Here's a recent talk about it:
Is there a written version? Don't want to waste time on a video.

>>99
http://www.inf.ethz.ch/personal/wirth/ProjectOberon/index.html

Enjoy :)

>>100
Thanks.

>>97
Hardware with GC, bounds checking and type checking, which dollar for dollar ran programs as fast as hardware today, would be superior to that hardware.

It would not, because five minutes after it was designed, and six months before it shipped, someone would improve the software, and everyone would just keep using that instead. It is not just that it is hard and expensive to make. It would be a thing lesser than the sum of it parts. Namely, the parts would include a GC that no one asked for or cared to use.

I assume you have never written a compiler, a garbage collector, nor a CPU.

>>102
Virtual memory mapping is ``free'' in modern CPUs but imagine what it would be like if the OS had to swap out to disk all memory used by the old process and swap in all memory used by the new process on every task switch. Old OSes had things called "overlays" and "time sharing" that did just that.
Suppose this new CPU makes GC as fast as stack allocation and bounds checking as fast as virtual memory protection checking. You know how you get an exception when you access a null pointer? Hardware could just as easily be able to check whenever you access outside an array. The programmer doesn't need any extra code and not even a virus or low-level code would be able to break this protection, just like you can't write to kernel memory. That's the difference between doing it in software and doing it in hardware.

>>95-96
Notice how there exist both x86 and AMD64, each having underwent a number of revisions, with x86 getting floating-point units and SIMD, while AMD64 got a virtual machine assist and several versions of cryptographic accelerators (not to mention third party stuff like VIA's PadLock). Also, other CPUs, people don't make them because they have nothing better to do, you know, but because they have ideas how to improve them.

How do you think things would look like with a hardware GC?

>>103
Suppose this new CPU makes GC as fast as stack allocation
Lol. Do you have any idea how GCs work? How different GCs work? Parallel, refcounting, generational, incremental?

Hardware could just as easily be able to check whenever you access outside an array.
Ok, yeah, you can do that part.

not even a virus or low-level code would be able to break this protection
Lol. Don't confuse bounds checking with memory protection. The first is strictly hardening against buggy code.

bestest programing languege is html!! but its hard 2 leern

>>106
Just use M$ Word! It generates html websites for you!

>>107
M$
Are you an Arch^tm user?

>>108
I'm going to abuse your anus.

>>105
Do you have any idea how GCs work? How different GCs work?
GCs have a root of reachable objects and follow pointers, saving only what's reachable. A hardware GC collection could happen on a cache miss or page miss.
Parallel, refcounting, generational, incremental?
Parallel (one per core), generational (related to cache hierarchy and swap system), and incremental (works while you do other stuff).
Today's GCs don't get along with swapping or the cache hierarchy. Software GCs actually swap garbage out to disk but with hardware GC, some garbage may never leave L1 cache. It never even has to be written to RAM. Usually, not even stack allocation has that guarantee. That's the kind of speed-up hardware GC can give you.
The first is strictly hardening against buggy code.
Both are strictly hardening against buggy code, but the truth is code is buggy. MS-DOS and "real mode" Windows 1.x-3.x didn't have any protection or paging at all.

>>103
Virtual memory mapping is ``free'' in modern CPUs
Ahh, you're comparing apples with oranges. Having a CPU support for certain stuff required for making a GC is awesome, and the best part is that we have increasing amounts of it! Modern CPUs can mark pages as "dirty" on writes so that a partial GC knows which pages in the older generation it has to examine, this is already used in .NET, for example.

Trying to embed an entire GC into firmware on the other hand is both idiotic and pointless.

>>110
You're so clueless I don't even know where to start. Go read some papers about the way actual world-class garbage collectors work, not the Wikipedia's bird's eye overview. You underestimate the amount of effort required to make a modern GC so hard it's not even funny. That's besides being plain old ignorant, "incremental (works while you do other stuff)", "Software GCs actually swap garbage out to disk", lol.

>>109
HAX MY ANUS

>>111
Modern GCs know nothing about cache or swap and this is a hardware problem. They can make assumptions about cache size, but they can't tell the cache "this is garbage, don't write it to RAM" and immediately reuse that part of the cache for new data. They can allocate and deallocate virtual memory, but they can't tell the swapper "this page is garbage, don't swap it to disk" and immediately free the page.

WAT KINDA RETOID R U?

A good selection of languages has both
+ breadth
+ satisfies a number of real world economic needs.

PROGRAMMING LANGUAGES DONT DO DAT SHIT, PERIOD. PROGRAMS SATISFY A NUMBER OF REAL WORLD ECONOMIC NEEDS, NOT PROGRAMMING LANGUAGES.

+ focus
+ exploits similarity between languages and incremental learning.
+ some unifying basis

MORE BULLSHIT. WHAT UNIFYING BASIS DO U SEE IN C AND BASH? NONE? AND YET DER'S FUCK-LOADS OF SYSTEMS DAT COMBINE C AND BASH.

AND WAT DA FUCK DOES INCREMENTAL LEARNING HAVE TO DO WITH A PROGRAMMING LANGUAGE? SEEMS TO ME DAT IT HAS EVERYTHING TO DO WITH DA FUCKING TEXT/COURSE UR FOLLOWING.

AND UNIFYING BASIS? C AND BASH HAVE AS MUCH IN COMMON AS SCHEME AND BASH, YA FUCKIN RETOID.

A good member of a particular selection meets a number of the
following criteria:
+ Satisfies one particular school of thought on programming languages.

NOW DIS I AGREE WITH. LOOK AT HOW SHITTY C++ IS. U DONT KNOW WHETHER UR WRITING FUNCTIONAL CODE, PROCEDURAL CODE, OR 'OBJECT ORIENTED' CODE. ITS A FUCKING MESS. WITH SMALLER LANGUAGES DAT STRICTLY ADHERE TO ONE PARADIGM, IT'S FUCKIN OBVIOUS.

+ Significant difference from predecessors
+ Significant influence on successors

LITTLE TO SAY IN REGARD TO DIS, BUT I CONSIDER IT INSIGNIFICANT.

+ Economically significant

SEE MY FIRST POINT YA FUCKIN RETOID. UR LIVING IN A DREAM LAND. PROGRAMS ARE ECONOMICALLY SIGNIFICANT. HOUSES ARE ECONOMICALLY SIGNIFICANT. DA CHOICE OF PROGRAMMING LANGUAGE U USE ISN'T, SO LONG AS U CAN WRITE PROGRAMS WITH IT. DA CHOICE OF SAW DAT U USE ISN'T, SO LONG AS U CAN CUT WOOD WITH IT. ARE U A PROGRAMMER OR ARE U JUST A SISSY WHO WORRIES MORE ABOUT DA COLOUR OF HER DRESS, RATHER THAN MORE IMPORTANT SHIT LIKE GETTING A COCK SHOVED IN2 HER?

+ Advanced i.e. no direct, established and proven heir.

IS IT UR GOAL TO BE VAGUE?

+ A good language.
+ Easy to express programs with
+ Easy to read programs expressed with
+ Easy to reason about programms expressed with

NOW DESE ARE SOME GOOD FUCKING POINTS. I THOUGHT DA WHOLE POST WAS SHIT AT FIRST, BUT MIRACULOUSLY U'VE COME TO THE THINGS DAT ACTUALLY MATTER IN A PROGRAMMING LANGUAGE.

STILL, TAKE UR CHOICE OF PROGRAMMING LANGUAGE AS A GRAIN OF SALT. SO LONG AS U CAN WRITE PROGRAMS AND MAINTAIN 'EM, IT DOES DA FUCKING JOB.

OH, N IN ADDITION TO UR LAST (GOOD) POINTS, IT SHUD BE NOTED DAT DA PROGRAMMING LANGUAGE ONLY CONTRIBUTES LITTLE TO DIS. WHAT'S MORE IMPORTANT IS HOW DA PROGRAMMING WRITES CODE USING DA LANGUAGE. SURE, DA LANGUAGE HELPS A BIT, BUT GET ONE OF DESE FUCKING STACK BOYS TO WRITE A REASONABLY SIZED PROGRAM, IN A PROGRAMMING LANGUAGE DAT U CONSIDER "EASY TO EXPRESS PROGRAMS WITH", DEN COME BACK N TELL ME DAT EXPRESSIVENESS IS MOSTLY IN THE PROGRAMMING LANGUAGE, N NOT MOSTLY IN DA PROGRAMMER.

UR PRETTY MUCH JUST SPEWING SHIT ABOUT A TOPIC DAT DON'T NEED TO HAVE SHIT SPEWED ABOUT IT. ONCE U ACCEPT DAT DA WORLD'S IMPERFECT AND FULL OF SHIT, U MIGHT REALISE WHY PEOPLE OPT FOR SHIT IN ORDER TO MAINTAIN COMPATIBILITY WITH OTHER SHIT. IF U REALLY WANT TO CHANGE DA WURLD N PUSH GOOD DESIGN CHOICES, START OFF SMALL BY GETTING JAVA, A LANGUAGE U ACTUALLY ENCOURAGE THE USE OF, TO SUPPORT UTF-8 NATIVELY AND DROP ITS STUPID UTF-16 BULLSHIT.

>>113
I think we can add swapping to the list of things computers do that you don't know how works.

>>115
All my points were good. Read everything again and consider it as a whole.

>>116
All my points were good. Read everything again and consider it as a whole.

>>116
You have a USB drive and you pull it out and swap it for another one. Don't even have to restart.

>>113
Except that isn't true. A user space garbage collector can use system calls like mincore to check whether an operation is going to cause a page fault or not. I'm not aware of any well known GCs that actually do this, though - changing page mappings is itself a potentially expensive operation so it may be better to avoid such tricks. The same goes double for cache line management - you'd really need to benchmark heavily to tell whether there is a benefit to doing what you suggest. There are well known cases where trying to second guess the CPU's cache management actually hurts performance.

To argue from ignorance a bit - if added hardware support were really so useful, you would see the implementers of popular language VMs like Hotspot, CLR, or V8 recommending new intrinsics for the CPU designers. The market for hardware that runs these VMs is certainly large enough for folks like Intel to consider it worthwhile to add such things.

The last time I checked this was not happening - the language implementers seem to spend a lot more of their time talking to the kernel people to improve code paths that their VMs exercise heavily. Unless you take the position that the language folks are ignorant of what hardware can do for them I'd judge that hardware support isn't the panacea you say it is.