NotRustAgain

10 anni fadiscuss

https://benchmarksgame.alioth.debian.org/u64q/java.html

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

NotRustAgain

10 anni fadiscuss

> Almost no libs aren't avail on 3 now.

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.

NotRustAgain

10 anni fadiscuss

> :P However, I welcome you to prove me wrong by creating the language to end all others.

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

NotRustAgain

10 anni fadiscuss

> Then ignore the metaphor and focus on the longer paragraph that succeeds it. :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.

NotRustAgain

10 anni fadiscuss

> but the library it ships with is going to privilege one over the other

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.

NotRustAgain

10 anni fadiscuss

> a passenger vehicle, dump truck, submarine, and airplane

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.

NotRustAgain

10 anni fadiscuss

>> A single language needed to solve all problems is a fallacy.

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

NotRustAgain

10 anni fadiscuss

There are several things you could take away from Lisp. I don't think you caught the good parts yet though.

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

Some languages have backtracking:

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

You just can't add those kinds of features to most languages because most languages are not programmable...

NotRustAgain

10 anni fadiscuss

Fast compile times are cool, but I've never heard anyone say they liked programming in a language that Wirth created. The possible exception is Delphi as a Pascal derivative, but that has very little to do with wanting to program in Pascal.

NotRustAgain

10 anni fadiscuss

Pretty much every 20 year old codebase is a mix of terrible stuff. The exceptions are rare and usually involve a strong handed dictator who is willing to make cleanups from time to time.

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.

NotRustAgain

10 anni fadiscuss

I really wanted to use Rust for numerical/scientific computing tasks, but it's kind of miserable for it. I didn't get hung up on the ownership things that all of the Rust zealots talk about (although I think explicit lifetimes are needlessly complicated). I got hung up trying to implement simple things like complex numbers and matrices in a way that was generic and usable. I'm sure some Rust fanboy will argue that Rust has operator overloading through traits, so I'll challenge anyone to make a workable implementation such that zA and 2.0B works in the following generics:

    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;

If Rust can't do scalar multiplication or real to complex conversions, it's really not usable for what Eigen or Numpy can do. Try defining the Mul trait generically for those multiplication operators, and you'll see what I mean.

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

comments