Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
but no seriously, titties and small waists and nice legs, that is the dream man. OH AND people learning how to write proper C and C++ code thus not making dudes try to write new languages like Nim (which I like), Oding(which I like), Zig (which I also like) and V( let us get back to this sometime later shall we?)
Bit chichis and good languages go hand in hand (see what I did there?) and should be the main focus of this discussion.
and yes, I am still writing a VBScript implementation of a new modern VBScript alternative for old fuckers like me that liked writing classic ASP using VBScript for the web and would like more PHP-like features for the language. -
I don't use debuggers (or only like once per year at most) and IDEs either. Debuggers in particular are only useful if you need to figure out what your code is even doing. That ought to be an exceptionally rare situation, or else something is very wrong to begin with.
Also, typical memory errors will not show up in a debugger unless you feed the program with data or conditions that will make it crash. That in turn requires that you come up with such data and conditions.
But if you can do that, why not just taking that smart pill already when coding and making the program robust from the get-go?
That's what I do. Given the exponential curve of bugfix cost vs. project phase, one hour invested into robust coding spares ten hours of debugging. I code slowly and review my shit several times because I'm too lazy for debugging, and I'm also finished faster that way. -
We've been trying to make programmers write better code for 70 years now. It doesn't work. Humans aren't perfect.
Sure there are some rockstars that can come close to perfect, but there are far too few of them to rely upon.
Esteban Kuber, one of the people working on the Rust compiler says this:
"There are no bad programmers, only insufficiently advanced compilers"
https://twitter.com/ekuber/status/...
I subscribe to this wholeheartedly. The better the compiler, the more any developer can accomplish. -
@ostream I never made mention of it, but since for whatever reason you decided to focus on that out of everything else I wrote I will go ahead and address the notion: If you work on a project larger than what the base generation of the project structure is, then useful features like proper intellisense, package manager support, environment support, debugging etc make a lot of sense.
People talk about memory hungry systems and bloat, then go on and install a trillion plugins on VS code or modify the heck of their emacs/vim environments. -
@Geoxion This as a whole proves my point even more really. I am blaming people here, not languages.
But then, I will disagree with what Esteban Kuber wrote, years in the field seeing the worst Delphi, PHP, JS, Java, C#, VB(6, NET and Script) among a plethora of others has proven to me that people will be bad programmers, regardless of how much a compiler or interpreter error will attempt to assist them. -
@Fast-Nop Multiple times have I told people, in particular when I was mentoring students or training people to stop messing up with a standard text editor if they can't spot their mistake and open it up in an IDE, one time I saw an inexperienced developer continuously forcing a Cpp program in notepad out of all text editors to compile using the command line.
Opened it up in VS, woooo lo and behold lil homie was trying to access a member of a pointer to a struct using . rather than ->, now, If I try and do this on any modern C++ compiler, an easy to read error message. So that is not too much of an issue, an IDE (heck even a Text editor like VS Code would point it out) would point it out as well.
all of this reinforces on my idea that it is more of a reflection of people being stupid rather than language fault.
Also, I did not say that the debugger allows you to debug memory issues, but i believe it does let you see where things are and understand foreign codebases -
@AleCx04 well, but if the problem is people, then what's the solution?
Since the dawn of programming we've relied on people not making mistakes. But no matter how good they are, everybody makes a mistake eventually.
So we've tried simply making fewer mistakes and so far that hasn't worked.
Now what Rust does is minimize the area where mistakes can be made. If you assume that a person makes a % amount of mistakes per loc, then when only 10% of lines even allow for mistakes, you'd expect only 10% of mistakes left in the code.
It can't prevent you from having bad or changing requirements though. -
@Geoxion homie I get you, but I don't think you get me. I am not chastising rust or saying that it is a bad language, I praised it multiple times in my post.
My point is, that if the language was made to prevent people from doing stupid shit it does not mean that the other language is bad, again, reiterating the end of my post, I state that articles calling it the death of c++ because we know have rust should be taking a look at the language through a different point of view not "I can't do stupid here! this better!" -
@AleCx04 Well, plain Notepad wouldn't be my thing because I rely on coloured syntax highlighting for visual navigation, but Notepad++ already offers that.
Using a debugger for figuring out a foreign codebase is at best a temporary crutch that one should leave behind as fast as possible. If the root cause it total spaghetti, leave the codebase, the job, or the company behind.
One big thing that a debugger fails at is non-reproducible bugs. That's why "read the source, Luke" is an important skill. No debugger or IDE can replace that. -
@Fast-Nop agreed 100%, but take into consideration that you and I are not juniors to the field. We do have different concentration areas, but we know how to figure these things out.
-
@AleCx04 Ok, then maybe I can explain why someone might argue that a language can better than another even when they're functionally the same.
Lang A and B are almost equal, even syntactically.
A let's the user do whatever.
B makes sure the user makes fewer mistakes through compile checks.
Now, both A and B have a library ecosystem that equally smart people worked on.
Which ecosystem will be buggier?
It's A of course.
So, because the average code quality of B will be higher, people will argue that B is a better language. -
the gentleman raises an interest topic indeed! Very well very well let us look into this.
In terms of these two languages, consider that most talks, documentation, books etc do not necessarily talk about code quality, but safety. the main selling point of R is safety, I will give the gentleman that safety is around the area of quality.
The gentleman needs now to consider this, Python is safe, can one not write shitty code in Python? What about Java, C# or Go? or PHP? these languages are safe.
Rust removed unsafety, amazingly well so, it did not, however, took away the power that people have of writing bad code.
The gentleman has the floor.
I propose that the study of Rust and therefore the application of said programming language and all of the technology that compromises it should be made because the language is actually really fucking good. Reading and studying how it manages to manipulate and otherwise use memory without a garbage collector is something to be admired, illuminating in its own accord.
BUT going for it because it is a "beTter C++" should not constitute a basis for it's study.
Let me expand through anecdotal evidence, which is really not to be taken seriously, but at the same time what I am using for my reasoning behind this, please feel free to correct me if I am wrong, for I am a software engineer yes, I do have academic training through a B.S in Computer Science yes, BUT my professional life has been solely dedicated to web development, which admittedly I do not go on about technical details of it with you all because: I am not allowed to(1) and (2)it is better for me to bitch and shit over other petty development related details.
Anecdotal and otherwise non statistically supported evidence: I have seen many motherfuckers doing shit in both C and C++ that ADMIT not covering their mistakes through the use of a debugger. Mostly because (A) using a debugger and proper IDE is for pendejos and debugging is for putos GDB is too hard and the VS IDE is waaaaaa "I onlLy NeeD Vim" and (B) "If an error would have registered then it would not have compiled no?", thus giving me the idea that the most common occurrences of issues through the use of the C father/son languages come from user error, non formal training in the language and a nice cusp of "fuck it it runs" while leaving all sorts of issues that come from manipulating the realm of the Gods "memory".
EVERY manual, book, coming all the way back to the K&C book talks about memory and the way in which developers of these 2 languages are able to manipulate and work on it. EVERY new standard of the ISO implementation of these languages deals, through community effort or standard documentation about the new items excised through features concerning MODERN (meaning, no, the shit you learned 20 years ago won't fucking cut it) will not cut it.
THUS if your ass is not constantly checking what the scalpel of electrical/circuitry/computational representation of algorithms CONDONES in what you are doing then YOU are the fucking problem.
Rust is thus no different from the original ideas of the developers behind Go when stating that their developers are not efficient enough to deal with X language, Rust protects you, because it knows that you are a fucking moron, so the compiler, advanced, and well made as it is, will give you warnings of your own idiotic tendencies, which would not have been required have you not been.....well....a fucking idiot.
Rust is a good language, but I feel one that came out from the necessity of people writing system level software as a bunch of fucking morons.
This speaks a lot more of our academic endeavors and current documentation than anything else. But to me DEALING with the idea of adapting Rust as a better C++ should come from a different point of view.
Do I agree with Linus's point of view of C++? fuck no, I do not, he is a kernel engineer, a damn good one at that regardless of what Dr. Tanenbaum believes(ed) but not everyone writes kernels, and sometimes that everyone requires OOP and additions to the language that they use. Else I would be a fucking moron for dabbling in the dictionary of languages that I use professionally.
BUT in terms of C++ being unsafe and unsecured and a horrible alternative to Rust I personaly do not believe so. I see it as a powerful white canvas, in which you are able to paint software to the best of your ability WHICH then requires thorough scrutiny from the entire team. NOT a quick replacement for something that protects your from your own stupidity BY impending the use of what are otherwise unknown "safe" features.
To be clear: I am not diminishing Rust as the powerhouse of a language that it is, myself I am quite invested in the language. But instead do not feel the reason/need before articles claiming it as the C++ killer.
I am currently heavily invested in C++ since I am trying a lot of different things for a lot of projects, and have been able to discern multiple pain points and unsafe features. Mainly the reason for this is documentation (your mother knows C++) and tooling, ide support, debugging operations, plethora of resources come from it and I have been able to push out to my secret project a lot of good dealings. WHICH I will eventually replicate with Rust to see the main differences.
Online articles stating that one will delimit or otherwise kill the other is well....wrong to me. And not the proper approach.
Anyways, I like big tits and small waists.
random
dissertation concerning rust and c++