NotRustAgain

Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native.

Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...

What an awkward way to say "most libs work on Python 3 now"... Why is that? I suspect it's because saying it clearly doesn't deliver the message you want.

Yes yes, I'll be sure to let you know. In the meantime, I hope you'll keep up the great work maintaining the status quo and contributing to a language which avoids problems that experienced programmers don't really have.

:P

Your second paragraph had a bunch of economic pseudo-theory about what sells... Maybe that explains why we don't have a good general purpose programming language, but it said little about whether there could be one.

This really just seems to me a matter of no one having done it right yet...

Following your example (which I like), I can have both mutable and immutable types in my language. Your point is that the library will favor one or the other, but I think you admit both libraries are possible. Why can't I have twice the library?

Yeah, it might be more work to have a library twice as big, (and again, no one seems to have done it yet) but it's not more work than having two languages with two libraries.

All that to say, you're summarizing what's been done, but you haven't proven that something better couldn't be done.

The problem with using metaphors to make your argument is we generally have to argue about whether the metaphor is even appropriate enough that the conclusions apply to the original topic... It's simpler just to argue the topic.

Within a huge class of problems, I don't need to get a new computer to solve each new thing that comes up. That's a very general tool. Why do I need different programming languages?

> All-in-one compromise solutions only excel [...]

Who asked for a compromise? I could make a short list of all the features I want in a language, and while there isn't one single languages that currently has all those features, I doubt you could make a proof that creating such a language is impossible or would involve some horrible trade off. Your list might be different than mine, but that's not the point.

> Has that been proven and do we have pointers to any peer reviewed papers on that?

I agree with you and can't stand it when people say things like: "All languages have their strengths and weeknesses" or "you just need to choose the right tool for the job".

I can't see any reason a clean and simple language can't have high level constructs when you want them and low level performance when you need it. It's just that no one has done it well enough yet.

My idiot instructor for comparative programming languages set me back years in understanding the cool parts of Lisp. He focused on "List Processing", which seemed pointless to me because lots of languages have lists... (I work with him now, so I'm allowed to call him an idiot)

You seem to think it's about the function calls. Maybe you had a bad instructor too, and he focused on "functional programming", which is all the rage for the last decade. I dunno, maybe you came to that conclusion on your own.

The thing I now think is wonderful about Lisp (Scheme for me), is that you can write your program however you want. If you want to use switch statements, and your language doesn't have one (Python), just make your own:

    (switch foo
        (case bar -> (do whatever you want))
        (case hmm -> (do something else)))

    (backtrack
        (keep trying)
        (different things)
        (until it works))

You're lucky it isn't Fortran and a homegrown (crappy) macro language.... You can't fairly judge Scheme or C from a legacy codebase unless you judge every other language that way too.

    let z = Complex<f64>::new(1.0, 2.0);
    let A = Matrix<f64>::ident(10, 10);
    let B : Matrix<Complex<f64>> = z*A;
    let C : Matrix<Complex<f64>> = 2.0*B;

(yes, I know there are some syntax errors in the type declarations above - It's my opinion Rust got that wrong too...)

Supposedly this kind of thing will eventually be possible with the recent "specialization" changes, but I haven't seen anything that allows operators to work as above...

ps: Last I looked, there was fledgling support for SIMD on the horizon... LLVM supports that, so it could happen.