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?

>>12
I was talking about defining a function inside another function and then returning it.
This inner function has access to the scope of the outer function, so you can do something like this:
def a(b):
    def c(d):
        return b + d
    return c

f = a(3)
print f(2) # 5
print f(3) # 6
g = a(6)
print g(2) # 8
print f(2) # still 5
As you can see, the inner function closes over the variables in the outer one, thus ``closure''.

Basically, anything you could do with a lambda, you can also do with a standard function.

>>10
package/import aren't elegant.

easy to FFI with C
What isn't?

Factor.

>>14
Why aren't they elegant? Packages are useful for organization and what would you use instead of import?

Many languages have FFI, I didn't say Go is special. However, there are several languages where that isn't really simple to do. Go isn't among them.

>>1
lol general purpose languages.

java is about as general purpose as it gets, it has the worst of pretty much every paradigm.

(or you could like, pick your language based on your task like everyone else)

>>13
So a closure is a nested function? Does that mean GNU C has closures?

Damn.

Thanks, >>13-san.

>>18
http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

GCC implements taking the address of a nested function using a technique called trampolines. This technique was described in Lexical Closures for C++ (Thomas M. Breuel, USENIX C++ Conference Proceedings, October 17-21, 1988).

yes apparently

>>5
totally agree, C and C++'s day is over as general purpose programming language, they will be relegated to systems/embedded programming which they were meant for. Languages like D, Go and Rust are the future

>>1
fuck you for thinking javascript is shit. you're obviously not worthy of calling yourself a programmer

>>20
D, Go
GC is shit

Rust
not ready yet

1-22
languages
terrible

>>20
Languages like D, Go and Rust are the future
That's funny because they are all terribly useless. Absolutely no one uses them in production, for good reason. Go is a shit language; it's like C mixed with Javascript and Pascal, but crippled. Google doesn't even use it for anything important. The only reason anyone has heard of it is because of cat-v Plan 9 faggots astroturfing on the web. Rust and D are even more obscure and shitty. D is like C++ except for retards. Not to mention that none of these have compilers that produce code as fast as C++ compilers, or even the JVM for that matter.

D is like C++ except for retards

lol'd

have an upboat

>>24
Go is hardly useless. It it enough like C to feel familiar while not bothering to implement features irrelevant to modern programming. That makes it simple to program with (unlike stuf like C++) without any major drawbacks (such as Java's forced OOP or scripting languages' inability to do any lower level stuff, not to mention their egregiously slow speed). Go sources are usually more portable than your standard C or C++ code too.

For example, the lack of pointer arithmetic and manual memory management means that the programmer has a lot less stuff to worry about.

In addition to removing completely unnecessary (and outright dangerous) features, Go is also quite strict. You mustn't have unused variables, code style is enforced, no implicit type casting (including int and int32, despite being the same underneath, being separate and requiring explicit casting), etc. While that may seem to be excessively restrictive to your standard volatile C obfuctor, it inevitably results in a code that is generally cleaner, safer and better.

Garbage collection should be the norm in userland applications anyway, because the tiny amount of speed gained by manual memory management is utterly negligible in all but the most performance-critical code, while it makes segfaults and memory leaks all but gone (yes, >>22, GC is actually useful).

In speed, it's true that Go is somewhat slower than C/C++, but that's only to be expected with GC, type reflection and other features. It still at least matches, if not outright exceeds, the (both programming and execution) speed of most equivalent Java programs.

Google stated that they use Go in several of their internal applications. In addition to that, Go is a good choice for Google App Engine.

Conclusively, Go is a true current-generation programming language that's focused on ease of use and good programs, not on any  irrelevant innovation that's ultimately destructive, since it precludes the good, simple and obvious ways of coding in order for the programmer to make use of the novelties.

>>26
Why is prague such a destination for viral marketers?

Perl. Haters gonna hate.

Truth is, if you have to ask "can i do _ with perl?" Answer is most likely yes.

>>28
Can I write uniform-looking and easily-readable code (from the perspective of someone who's not a Perl wizard) that also executes fast enough (Java-tier speed, not Python-tier) with Perl?

>>28
can i write a function that accepts two arrays as arguments?

>>27
It's the same reason why there are trolls and shitposters who disparage others senselessly.

>>28
Can I reify part of the continuation up to a certain prompt contained inside of a continuation mark as a procedure and call it multiple times?

>>13
>Basically, anything you could do with a lambda, you can also do with a standard function.

Except for the fact the closures won't have the same state unless the variables are immutable.

>>33
If you change a variable afterwards, that's your fault.
Don't do it if you don't want that.

>>34
Which defeats the purpose of emulating closures in the first place.

And just for the record, java requires variable to be final when emulating certain types of closures.

Every programming language is crap unless it's Lisp, which is shit.

Programming is a disgusting practice and you should be ashamed.

>>24
That's funny because they are all terribly useless. Absolutely no one uses them in production, for good reason. Go is a shit language; it's like C mixed with Javascript and Pascal, but crippled. Google doesn't even use it for anything important. The only reason anyone has heard of it is because of cat-v Plan 9 faggots astroturfing on the web. Rust and D are even more obscure and shitty. D is like C++ except for retards. Not to mention that none of these have compilers that produce code as fast as C++ compilers, or even the JVM for that matter.

Languages like C and C++ had their day in the 80s when you had to write directly to hardware on singletasking OSless home computers. When you wrote a program back then, the program was the OS, everyone used asm back then. Using an archaic language like C++ now is sheer stupidity. Having to manually manage memory back when you were writing directly to hardware addresses and had full control of the CPU, but that kind of programming is gone with mondern OS's. You can call it astroturfing all you want, but languages like Go, D and Rust are going to take over and eliminate all the stupid time wasting errors that could be eliminated with garbage collection. 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. There are a lot of people who make their living coding C/C++ whos work will be made obsolete by modern compiled languages, languages that should have caught on 15 years ago.

Objective-C.

>>39
a language that has C as a strict subset with unsafe OO bolted on
gtfo

>>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.

>>79
So, it just means they're full of security flaws hidden in C undefined behaviour.

>>71
So you would rather use a terribly designed language than to write a few lines of code required to use the FFI? Seriously?

You shouldn't need inline assembly anywhere except in kernels and some
case of extreme optimizations. Requiring a modern language to support that is outright ludicrous.

By the way, check this:
package main
// #include <stdio.h>
// int f(int a, int b) { return a * b; }
import "C"
func main() {
    C.printf(C.CString("%d\n"), C.f(2, 3))
}
Yes, I just defined and called a C function in inline Go. See that? It's not that hard to use C stuff.
However, I see no reason at all to require my language to support anything more than that. Inline ASM? C as a subset of the language? What purpose would any of that serve in the long run except to complicate my job?

By the way, there's no such thing as asm block in C. What you're referring to is a C extension included in whatever C-based language you're using.

>>82
Weave as a part of scipy and Instant as a part of Fenics are just two Python modules which can do the same thing, they also allow easy access to numpy arrays.

>>72
Compilers don't do magic. They follow a set of rules like any software to turn common constructs into tighter code. But compilers are not aware of the context of the problem you're trying to solve, or the algorithm you're trying to express. Suppose you're in a very hot block of code. You find a more clever solution than the ASM output. That's where you use inline assembly.

>>82
By the way, there's no such thing as asm block in C.
It's not standard, but every C compiler to exist has implemented it.

Try Grovy or Scala or Erlang

>>85
In midly incompatible ways.

>>84
However, it's extremely rare that such an optimization would be worth more than general portability. It certainly shouldn't be a requirement for a general-purpose language (note that ``general'' does not mean ``specific set of hardware''). So, when you REALLY have to use that, you can use whatever convoluted way you can think of, since it's quite unlikely that you'll be doing it regularly.

>>85
And that's exactly what I said. That block isn't a part of the C language, but is a very common compiler extension.

>>71,82
Haha, prawg, open your mouth and take my huge Lisp with inline C. http://lush.sourceforge.net/index.html

Scheme: CL without namespaces.
lol no, Scheme: unbloated CL

Perl6 come to me

>>90
Scheme is the C of Lisp. Undefined as shit.

>>92
Say, what's undefined in Scheme?

>>93
Order of evaluation of arguments, let may evaluate its clauses in any order, and certainly some others.

>>90
More like
Scheme: CL without any standard library

>>1
Erlang: Concurrency is unneeded outside of a few very specific applications. Parallelism is where it's at.

You do realize that Elang can do both, right?
At the same time, too.

>>96
yea but can it do both while it's doing both?

>>97
Just because you're the robot doesn't mean you're the robot.

Did you even read the book?

>>98
No, but I read SICP.

100 GET

>>94
Order of evaluation of arguments, let may evaluate its clauses in any order

I don't know why some people thinks that 'undefined behaviors' are a bad thing. Actually it's good because it force you to think in a correct way

Why would such a minor freckle like this matter? Are you mutating states, /prog/?

>>101
No, it's not.  Everything should be well-defined and nothing left up to the implementation.

>>102
In fact I am mutating states whenever I must, which happens about 1% of the time.  And in that 1% of the time, only 1% of the time does the side-effect escape the function.

>>103
I think that you don't understand why something is undefined behavior

JACKSON 5 + 100 GET

20 TIMES BETTER THAN JACKSON  5 GET

>>103
Everything should be well-defined and nothing left up to the implementation.
No languages have ``nothing left up to the implementation'' unless they are ``defined'' by their implementation. See: Perl.

>>103
I guess you want Java, “run once, write everywhere”.

The best programming language there ever was, or ever will be, is Spectrum BASIC.
Every machine out there should have an interpreter.

>>103
Who made up that rule? If I made a Shitgol and left the entire language as an exercise to the implementations and Shitgol compiler writers and Shitgol users were okay with that then it should be fine. Standard specs only exist to prevent excess incompatible extensions between vendors.

>>104
I do understand, it's because compiler writers want extra room for optimizations.  For instance, a compiler could schedule the evaluation of a procedure's arguments in parallel.

>>106
Most languages aren't Lisp, thus they're crap.  Pointing out that most languages have undefined behaviour means nothing.

>>107,109
I never thought I'd say this, but Java does have something good about it.  I find reproducibility to be fairly important -- if a program is executed on two different implementations, it should have the same result (leaving aside things like reference->integer conversions which aren't even guaranteed to be the same across two runs of the same implementation).  Leaving undefined behaviour in your language is a great way to make your users shoot themselves in the foot.

>>72,73,82
Clearly none of you are experienced with Asm, or looked at compiler output (or you have, but can't understand/see a way to do it better, because of the first point). Compilers are a good way to generate code quickly; even at the highest optimisation level none of them can reason about things like register allocation in the same way that a knowledgeable programmer can. People have been saying compilers are better at generating code than programmers, but that's only if you compare to average or below-average Asm programmers.

Go learn Asm and compile any program you want, then look at the Asm output. Find a function and see if you can do it better. Unless you have some ultra-powerful compiler I haven't seen before, chances are you can beat the compiler in size, speed, or both. Perhaps because of the source language semantics the compiler can't do something, but YOU (should) know how your program operates and can easily take advantage of things like cross-function register allocation, convenient invariants (you can prove a register will always have e.g. 0, and use it appropriately; the compiler can't), and advanced stack manipulation.

>>82
Saying a language is "terribly designed" when it has the capabilities I need (and then some) is simply opinion. And it's not "write a few lines of code required to use the FFI", it's having to do that plus all the other "administrative" cruft surrounding it. In other words the integration is not as seamless as it could be. You said it yourself -- "FFI". Not "embed code directly in the compiler/JIT's output".

>>83
This is interesting, but note that it's not a core language feature. Someone clearly had the need to do that.

>>88
True portability is a myth. You can never get that in a compiled language, no matter how hard the standards bodies try. The closest thing to it is Java, and everyone should be familiar with its characteristics. If portability is ALL I care about for an application, then that's what I'd choose. My definition of "general purpose language" is one that allows the programmer to use whatever level of abstraction he/she finds appropriate, and switch between them effortlessly. How many architectures out there, in active use, have 37-bit integers, 11-bit bytes, or other oddities that the portability advocates keep using as examples? If you were working on such an uncommon system, portability is going to be the least of your worries. Right now, if you're targeting regular desktops, there's basically two ISAs and two OSs: x86-32/x86-64, Windows/*nix.

>>89
This is the sort of stuff I was talking about.

For instance, a compiler could schedule the evaluation of a procedure's arguments in parallel.
Unless those arguments require extensive computation, chances are that the overhead of preparing to get that done would outweigh the cost of just running them all in 1 thread serially. Modern processors are now quite good at parallel instruction execution, IIRC these 3 instructions

add b[edx], 5
sub eax, ecx
sub ebx, ecx

are executed in parallel since ~Core 2, with the second two running while the first is waiting on two memory accesses.

>>111
While you could hyper-optimize that code, do you really need that? Just when was the last time you really needed something like that instead of the code that would work at least on x86 and ARM?