All current programming languages

Just .. miss the point, slightly, of what programming *is*.

We could do so much better, I'd like to start a language design group.

Anybody interested? (if so you could post a little bit about what sort of semantics and essence you'd like to work on)

http://dis.4chan.org/read/prog/1217887165

We could do so much better
Not really.  http://mitpress.mit.edu/sicp/full-text/book/book.html

We even tried not too long ago: http://dis.4chan.org/read/prog/1217887165

We could do so much better
HAHAHA.

One word Haskell thread over

Anoniskell

>>5
Did you mean: Perl 6

>>1
One word, Python without statements and with a couple of new functional programming features, keeping its fantastic object model, running on a virtual machine that doesn't have the GIL.

Java

>>8
One word, FORCED INDENTATION OF THE CODE, THREAD OVER

>>8
And not slow as fuck...
also,
>fantastic object model
I prefer CLOS.

>>11
Python is remarkably fast for an interpreted language.

Java is the future.

>>7
Perl6 is going to be awesome

I repeat: Perl6 is going to be awesome

>>1
I'm pretty sure that all significant ``programming paradigms'' have already been invented.

>>16
What about chaos-oriented paradigm? I think it hasn't been invented yet.

>>16
so. fucking. naive.

>>18
YHBT

>>14
Problem is, it's coming right in the year of the Linux desktop, and it's the high-level programming language used in Duke Nukem Forever. Even Python 3000, bytecode compiled Ruby and PHP 6 are coming before it.

>>17
It has. See Sepples.

>>20
We should write a Universal bytecode language. It will be powerful enough to support compilation from any dynamic language, including the algorithmic language Scheme, the slow as fuck language Ruby, and the FIOC. But it will be simple enough to allow efficient implementation directly in hardware. How does that sound.

>>22
you mean like inferno or java bytecode?

>>22
It's called assembly.

>>23
Like Parrot, lol.

>>24
It's called portability.

>>25
The compiler will compile to different assemblers. Distributing binary files sucks ass anyway, and is writing a compiler capable of doing 4 or 5 different architectures really that much harder than witing a bytecode interpreter?

>>26
Cool, I'll be waiting for all your JIT cores to show up in Parrot.

>>26
No, distributing source code that needs to be compiled sucks ass, especially if it has anything to do with the GNU toolchain. It's fugly, messy, and shitty, and it's made of fail, file not found, unresolved external and make: Stop. And 4 or 5 different architectures? If the project is going to have any success, there are like 10 relevant architectures to support.

>Just .. miss the point, slightly, of what programming *is*.

How?

>>26
Compiling to different architectures is easy. But if you want to do anything beyond a shitty console app, things get complicated. The problem is that there are no decent cross-platform libraries for IO, GUIs, networking, etc.

This is a good opportunity for the Anonix community to step in. If we write some libraries to implement the things I mentioned above, compiled to the universal bytecode language UBL, it will be the first step towards replacing the bloat and slowness of Java with clean, simple, Anonix-style code.

Networking?  BSD sockets are already as universal as it gets.  You may need wrappers to support obscure systems, but there's no point changing the interface.

GUI?  GUI toolkits are indeed horrid.  They usually fail because they believe every platform is identical except for the API, and don't recognize that they have to be a platform themselves.  The only feasible approaches to this are 1) SDL-like window manager with fully custom drawing and widget systems on top of OpenGL (plus a capability-based extension system to help integrate with other system services), and 2) semantic descriptions of the UI layout, rendered and operated entirely by a platform module (e.g. HTML).

Of course, compiling to different architectures is not easy, unless your idea of compiling is in line with Java's ("technically it has native instructions in it, but it still runs like crap").

And regarding universal bytecode languages...how many more do we need?  We already have Parrot (though the implementation doesn't really work), LLVM, even .NET.  Why duplicate all that?  Do you have any particular design ideas that could make it better?

Oh, why am I even talking to you.  The Anonix community is a myth anyway.

>>22
portable assembly = linoleum

>>32
portable assembly = x86

>>32
Portable assembly = C

>>33
gb2/DOSbox

Do you have any particular design ideas that could make it better?
``The Anonix community'''s only idea is to eliminate ``bloat'' by writing shitty code.

>>35
Define ``shitty''. And "because I didn't write it" isn't a valid definition, nor is "because it doesn't use ENTERPRISE BEST PRACTICES".

I highly doubt the rest of the Anonix group are going to support bytecode as anything other than compiler IR. It's far too inefficient.

>>28
Yeah, GNU toolchain is bloated shit. Hmm... make maybe make front-ends that compile whatever language to the bytecode mentioned above, then compile again the bytecode to native via machine-dependent back-ends.

>>36
You mean like GCC does?

Wow, trolling with two opposite viewpoints in the same post. That is true ENTERPRISE-GRADE SHIT

>>37
GCC takes both ends and mashes them together into one huge mess.

I just wanted to congratulate everyone ITT by being the part of this EPIC FAILURE