Why does C++ filter so many people? Every mainstream language builds upon it, yet for some reason people act like it's unintelligible garbage like fucking Lisp
>Every mainstream language builds upon ityea sure...
>>106777727post literally one that doesn't
Too much stuff, arbitrary rules and boilerplate. The worst of all languages in one. I fear those who are proficient in it
>>106777748>other males are more intelligent than mepathetic submissive behavior.
low effort ragebait and e-celeb spamwhy don't jannies clean this up immediately?
>>106777748>I fear those who are proficient in itI accept your submission.
>>106777709>C++>Not C or pure Assembly
>>106777762>>106777777
>>106777709Ultrafuckable in like 4 of those thumbnails
>>106777709The amount of times Youtube shilled that troon to my recommendations is unbearable.
>>106777747C
I WANNA SEE HER P0N0R
>>106778165>troonanon...
>>106777709BUILT FOR SWC
>>106777709Undefined behavior. Radical changes in the standards starting around c++11 and continuing on wards to C++23 this doesn't seem to be changing.Legitimately if you do ansi or iso C++ 89 or C++98 and modern C++23 it is different languages.Sure everything is still supported but the actual techniques and expectations have changed greatly.It is a beast of a language with so many features, gotchas, and points to keep track of any saneproject is basically forced into define a specific subset to use.C++ isn't bad it is just a big knotted ball of yarn.Oh, and lisp isn't unintelligible. it's just influenced by lambda calculus.The biggest problems people tend to have with lisp are it is dynamic, garbage collected, and full of parenthesis.Many also don't like basically having to embed a whole interpreter into any standalone executable.Code as data, list comprehensions, very small core language definition, macros, and being basically the originalrepl language are reasons Lisp is often loved.Though it might be better to say which lisp you're talking about. The original description, clojure, common lisp, scheme?
>>106778842>It is a beast of a language with so many features, gotchas, and points to keep track of any sane>project is basically forced into define a specific subset to use.A single compile-time-only modernization profile that excludes the features that the vaste majority agree should be excluded, with fairly good, ergonomic and visible escape hatches, seems like it could help. Maybe it could exclude gotchas like vector<bool> in a standardized way.
C++ is a dying languageIm sticking with C until I can use Jai
>>106779176Does Carbon count? Its by Google though
Has nice core functionality but has tried to absorb every other paradigm from the fear of being replaced, hence it hangs around forever aggregating a superset of features not really needed for day to day development. Also, the new features can give a false sense of understanding to new devs without them realising they haven't actually worked out how to write software because the actual paradigms of pointer/object-uniqueness/memory management are glossed over in the process. Hence it seems more impenetrable to learn now from scratch than it actually is/was from 30 years ago because newbies don't know where to start.
>>106779298C++ is simply a crutch before a developer has their eureka moment on the path to pursuing C. It blurs the path to try understanding, but sometimes that's a necessary step
>>106779352I used to be optimistic when I first heard of Carbon, but I didn't know anything about it. After reading some of its documentation, I am somewhat pessimistic. The quality of some of their features seemed poor. I fear that they might be grossly underestimating the difficulty and scope of a systems programming language, and I do not know if they have the required expertise in many different fields. That they are trying to make a clone helps, but some of their features are new relative to C++, and at least one of those just looked bad, at least to my eyes.I am not sure they are doing their due diligence, or are being honest with others, and possibly not themselves either.I could be grossly mistaken, however, but it still bothers me.Consider Swift. The main creator of Swift, the same developer that created LLVM as I recall, is by his own description not so much into mathematics. That is perfectly fine, as long as he ensures that he can cover that expertise by others when designing a programming language. However, with Swift, didn't do it, and now, in current Swift, this fails to compile due to (arguably colossal) fuckups in the type inference and type system.https://www.cocoawithlove.com/blog/2016/07/12/type-checker-issues.htmllet a: Double = -(1 + 2) + -(3 + 4) + -(5)https://godbolt.org/z/vqzh9KeaeWill Carbon's developers do similar mistakes? Will their approach lessen the burden, and lessen it sufficiently? Or will compatibility make it harder in some ways? Will they find and bring in the needed experts? Rust's success was in large part due to getting lots of volunteers/tricking people into contributing in all kinds of different ways. Not the only approach, and paid engineers and specialists can make a large difference sometimes, and Google has money. Do they have the needed experts? What experts will their way need?On the JVM and .NET, compatibility is probably way easier, for there is bytecode or intermediate language.
let a: Double = -(1 + 2) + -(3 + 4) + -(5)
>>106779298By the time Jai releases, people won't write code anymore.
