Why don't you boys join forces to replace C++ with something better?

Why don't you boys join forces to replace C++ with something better?

Bump

Ok, i will make the logo

Is this a Rust thread?

We need to name the new better, non-bloated programming language as G++

That's the old picture desu.

And I like C++, I use it to make >games with SDL. Pretty much the only significant (at least in terms of scale) programming projects I take on.

Roll

Every single one of these "challenges" are trivial, why not try to make something new and exciting instead of things that already exist?

Trivial for who? I'm a programming newb and these are helpful.

I don't know how to make a programming language. I have an idea for what I'd prefer C++ to look like though.

this desu
let's write a rust interpreter in haskell

Rollin

roll

I already upgraded to C# over a year ago. I haven't enjoyed programming this much in decades.

I think rust is better enough

Has anyone ever seriously looked at this image and gone "I'll do 58 or 99" and been successful?

Are you a Windows or Linux user? Do you use an IDE or code editor?

Visual studio

Windows. Visual Studio.

Roll

99 is much easier than you think. 58 too, provided you use a library for sound synthesis.

What other languages you know?

C++, Java, Javascript, Lua, Python, PHP

CS degree or employment via self taught?

Self taught.

roll

how do you feel about java compared to c#?

rolling

C++ is an awesome language. No reason to Bash on it. Unless you C a sharper language. Or R you just not swift enough to program without it being too much of a brainfuck?

There's no need. C++ can be used in a way that's perfectly functional, readable, and easy to write. The problem is that it's vast and has too much cruft, so what is needed is a guide to use it in optimal manner.

Nice. Thats what Im trying to do

Rust

rerolling for more interesting project

tf is tornado text

rust is a c replacement. Let me know when rust++ is out.

It replaces C++ too desu user

It's... okay. There's a lot of recursion to everything. A recursion trend that is taught to everyone simply because everyone is doing it. A recursion that is encouraged by having built in libraries that utilizes recursion. There's just... a lot of recursion all over the place.

This is generally unpleasant when you code because instead of having a library method that takes an int, you instead have a library method that takes an object, which needs to be gotten by calling new on another object, which requires an object in the constructor. So then you have to call a new on that other object, which in turn requires another object which can only be gotten by creating another object and then calling a method of that object. Sometimes it gets even crazier than that. And mind you this is not a third party library, or something written by Rajeet The Pajeet, it's something officially included and maintained by Oracle.

This also creates a whole other side of the same issue, namely finding resources. Since this kind of "tradition" is taught in school, you have a lot of new programmers joining the market following the trend taught by them (and never corrected), so a lot of the time you find yourself sitting down with a task, pondering on how to do it, and you think to yourself "Lets google the problem and see if I can find any ideas or inspiration" (translation: find some code to copypaste so you can spend 5 minutes tweaking rather than 5 hours writing). And you find a thread on stackoverflow that's precisely what you're looking for, with one or several answers. And the answer is... 2 entire pages worth of Java spaghetti code that utilizes recursion upon recursion wrapped inside of recursion so deeply just the first few lines makes you want to take a smoke break when you don't even smoke.

Cont >

Another thing I also took issue with is the weird design decisions that seems to have been put in there by some grumpy person in 1995, and then left in there solely because that grumpy person is now a grumpy old man hiding somewhere in Oracle's basement waving his cane and threatening to kill himself if they so much as suggest the possibility of changing that weird design decision he put in place in 1995.

One thing that comes to mind is the whole issue with unsigned variables, and something I've struggled with on multiple occasions.
It might not seem like much of an issue, because why not just use a bigger variable? The answer is; You should, and you have to. And in the end it doesn't matter that much because 4 bits are just 4 bits, even millions of them are just a few megabytes.
But it actually does become a problem when you deal with networking. Specifically networking where either the server or client is written in something other than Java. The programmers of that application isn't going to arbitrarily limit themselves to sending just signed data over the net. Oh no they're going to be sending you bits and bytes, signs and unsigns and sometimes even pigtails. And then you sit there having to either cram the unsigned short into a signed short and try to figure out the data that way, or you have to shove it into an actual signed int, at which point you have to add a lot of extra code just to make sure it never goes negative otherwise you'll end up dealing with garbage data which at worst might actually crash the application on the other end.

It's such a pointless issue that they could have fixed years ago, but haven't. Instead they've danced around the issue and introduced classes and objects to sort of deal with the problem, but those classes and objects doesn't overload very well and is about 5 billion times slower than using an actual unsigned primitive, so in the end you just shake your head and go back to your bitshifting hackjob praying that the ticket system doesn't explode one day because a stray bit got stuck somewhere and crashed something and you're suddenly looking at a million-dollar-an-hour downtime.

Cont >

And finally the JVM. More specifically the JVM arguments. They're... terrigood. Is that a word? They're horrible and awful, yet amazing and productive. They give you a lot of control, but also too much control.
You can sit hours, sometimes even days tweaking miniscule settings in the JVM. You can set up loggers and tracers and god knows what else which is a godsend when you're trying to performance test an application.

I've always joked that the JVM is the cunt of the programming world. Not the way you're thinking, but literally, the Vagina of the programming world.
Basically you write a piece of software, and you run it in the JVM. It runs okay, but you figure, yeah I can tweak the JVM and make it run better. So you rub the J-Vagina-M a bit, and the code runs 18% better. Great. So you rub it some more, and suddenly the code runs 286% slower. So you rub it again, no change. You poke and fiddle some more and even though it should logically be faster, it's now 301% slower. So you rewrite the code, with a few changes that was suggested here and there, and you toss it to the JVM. Based on information from official post by Oracle themselves, it should be faster. It's not, it's about twice as slow. So you try the changes that made it run 18% faster before, it's now even slower. So you try the code that made the first application slower, it's now twice as fast as the first application with the 18% boost. You change newgen from 3095 to 3096 and it's even faster, then you change it to 3097 and it tanks down to 800% slower.

It's just very... very finnicky and touchy-feely. Which is great, but also terrible.
I've known people who made an entire life off this. Doing nothing from the time they get into office, to the time they leave, but sit in front of a server, looking at logs, looking at graphs and try and determine where the G-spot of this weeks revision of the application is.

(Sorry for the blogpost)

I too dislike the idea of 'reinventing the wheel' but for a noob like myself each challenge is a learning opportunity.

roll