Any decent modern general-purpose languages?

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?

>>39
+1 for properly spelling out the name of Objective-C

- Tremendous Faggot
  163k •31 •320 •628

>>38
Basically you should be able to look at code and know what it does, not poke around with a debugger and static anaylisis to try and find out what the program might do because the code is to unsafe to trust on its own.
Oh lawd the ironing. With native code you can see every single instruction from compiled output, knowing that this copy will not change at all. And you're really delusional. Hardware gets better not to make it easier for weak programmers, but to allow for better software. It's not like everyone is going to buy expensive hardware just so that shitty bloated GCs can run at a maximum. They will buy expensive hardware so that they can run software that delivers in parity with the hardware. For example, I'm not going to buy a new graphics card and use more power just to play a game that has graphics no better than last year. What a fucking waste. Apply the same idea to enterprise servers and we're talking about billions of dollars.

Related: http://www.gotw.ca/publications/concurrency-ddj.htm

>>42
pure disinformation
 As I said, the day when a program loaded in RAM and took over the computer are over, you cant track a program in memory anymore, its all artificial segmented memory hidden from you by the OS and CPU hardware, not to mention most of the program runs in dynamic libraries.

People keep trying to connect garbage collection with slow VM languages like Java and C#, but compiled gc languages are a whole new ballgame.

>>43
but compiled gc languages are a whole new ballgame

I lel'd

http://shootout.alioth.debian.org/u32q/which-programming-languages-are-fastest.php?calc=chart&gcc=on&gpp=on&java=on&go=onj

>>5
x86 is a 1970s instruction set.

Ada. It's great.

>>44
Go is slow as fuck. It has a broken conservative garbage collector. Try a language with a real GC instead of something designed to be retrofitted onto a language with unsafe pointers.
IHBT

Try newLISP. It has pretty much everything you need for general purpose programming. Strings are UTF8, it has pattern matching, pretty battery-included standard library (sockets, regex, etc), trivial c interface and not to mention it has true code = data unlike scheme and cl. The only downside is it's gpl.

Forgot to mention, newLISP also has Cilk baked in

http://factorcode.org/

TI83 BASIC

>>48-49
Oh god no.

>>47
Try a language with a real GC
Like what, you retarded fuck? No example provided, so I assume you mean JAVA.

GC is shit.

>>53
Fuck off and die already you fucking retard.

>>53
Well, Java's GC is pretty robust. But GC is indeed shit.

>>55
Fuck off, retard.

If you havin garbage problems I feel bad for you son, I got 99 problems but a GC ain't one.

>>57
And all the 99 are segmentation faults.

>>1
Archaic cons-based library.
You don't understand Lisp.

Writing complex macros is a PitA due to the unlispy quotation syntaxes.
What the fuck

>>3
I'll look into Lua, thanks.

>>10,26,47
Pig disgusting! Pop infix syntax everywhere — worse than C. Terrible GC. And as I said of Clojure and Erlang, concurrency is not the next big thing, parallelism is.

>>15,50
Interesting. I'll look into Factor.

>>21
JavaScript does have some good parts, like VB6. But overall it's shit.

>>28
Perl has braindamaged syntax, ``There's more than one way to fuck up'' and it's slow.

>>39
What >>40 said.

>>46
Too verbose and antique approach to multiprocessing.

>>48-49
I don't see the point of modifying lambda expressions at run-time. Is that what you call ``true code = data''?

>>59
Archaic cons-based library

You don't understand Lisp
Could you elaborate? I'm fine with the special casing of two-elements records for linked lists but I don't understand why is the user encouraged to use them for things such as association lists elements or trees.

Writing complex macros is a PitA due to the unlispy quotation syntaxes.

What the fuck
I don't know why I wrote that.

I want a language in which you can go as high or as low-level as you like. If you just want to write programs quickly you can use lambdas, dynamic types, etc. but you should also be able to drop down to the level of inline asm for those parts where the compiler isn't good enough. The closest to that at the moment is probably C++.

>>45
And it's withstood the test of time. Besides the classic 8-bits (6502, Z80, 8051, etc.) what other CPU architectures have lasted as long?

Racket

>>60
Could you elaborate? I'm fine with the special casing of two-elements records for linked lists but I don't understand why is the user encouraged to use them for things such as association lists elements or trees.
Association lists are sometimes useful.  A proper Lisp (pun intended) would provide you with a library with at least hash tables and various trees (for speed, really).

2^8 GET

>>61
I, too, want an winged ponycorn that shoots laser beams from its eyes, Cudder.

>>60
concurrency is not the next big thing, parallelism is
Go's purpose is not to be ``the next big thing'', it's to include already existing functionality in a well-designed way. Concurrency is just fine for real world programming.

>>61
That's utterly ridiculous. Why would you rather have a jack-of-all-trades language like the mess that C++ is than learn a few (even two would suffice) languages that would together cover the same field without any one of them being shit because it tries to be everything at once? Wanting something like that from a programming language shows that you don't have a clue what you want.

>>64
That's not 10

>>65
>>66
It's a perfectly reasonable desire. You can master one language and use it as much as possible. The only drawback is that the language becomes more complex like C++, but no one forces you to use all or even half of the features.

>>64
You're a long ways away from 256

>>69
You're an unsigned char ways away from 256

than learn a few (even two would suffice) languages that would together cover the same field
The point here is easy integration. For whatever reason, language designers often think their language exists in a void and no one else should be using anything other than their language. If they think otherwise, then almost always, access to "outsider" languages is "at a distance", via an API. Take Python as an example. I haven't used it, but a quick search reveals things like http://docs.python.org/extending/extending.html that shows you need to go through an elaborate process just to write a few lines in an alternate language.

An exact opposite example would be asm { } blocks in C/C++. If I'm writing C and want to manually optimise some parts, I can put in an asm { ... } right there. Trying to put some C in Python, or even Asm in Python? No easy way. You have to go through the whole process above. It's complex enough to be discouraging for simple cases, reducing the opportunities that programmers have.

I may seem biased towards C/C++, but that's naturally because I'm an experienced long-time user and understand the entire process behind its design. And yet, like >>68 mentions, I have not used all the features of C++ like advanced templating. I've found that those who complain about it don't understand why it's the way it is. Once you understand how C++ maps to C, you might find it quite interesting and enlightening. Again, it allows you to choose the level of abstraction you want. I can use cout if I feel... "classy" and want to use the (IMHO bloated) OOP output, printf if I want to be C-like, and int 128 function 4 if I want to be as thin as possible and hit the kernel directly.

True utility comes from being able to solve the problem in the way you want, not the way the language designer enforces. Also remember that programming languages are tools, and like physical tools, acquire dirt and wear from use. The only perfect, clean tool is one that is never used.

>>71

you're experience has maid you clothes minded. Going to asm for efficiency is something you should leaf to the compiler, as it can be done well by the compiler and by adding your own bits of assembly, you alienate other architectures. And hand coded asm could be sub optimal. You should only use asm to access features that are not otherwise available, like in a wrapper library that configures interrupts or something.

You should only use asm to access features that are not otherwise available

although it would be appropriate to use assembly for routines that can be implemented with special assembly ops that the compiler isn't clever enough to employ. I like to think that a sufficiently clever compiler can exist, but I don't think it can for every language. In particular C. So I actually take most of >>72 back, but only for advanced opcodes that can only be used in special situations, like SMD stuff.

SMDSIMD stuff

>>71
Trying to put some C in Python, or even Asm in Python? No easy way. You have to go through the whole process above.
Do you ever do any actual research into your bullshit claims you fucking retard?

>>71
Once you understand how C++ maps to C, you might find it quite interesting and enlightening.
And cry a little inside because you can't have your precious life back.

This thread is so bad I'm ashamed of myself. And I haven't even made a post in here yet.

C is undefined bullshit.

>>78
Does that mean by extension that every language that's written in C is undefined bullshit as well?

>>79
No matter how much Larry Wall and Guido van Rossum want you to think otherwise, the implementation is, in fact, not the language.
Else, every language is assembly and you have no excuse to write C.