I've designed a checklist that would instantly decide if language will be a C++ successor or not. Every line is requirement for a "language that will dethrone C++", 9/10 wouldn't cut it. 1.No dependencies on GC/refcounting. 2.Object abstraction system(as powerful as in C++). 3.Same or better execution speed(compared to similar C++ code). 4.Type-inference,type-inferred lambda expression. 5.Strict type system with escapes(fast casts, conversion). 6.Clear and terse imperative syntax. 7.Large standard library with functional/OOP/procedural programming support. Must include threading and graphics. 8.Support for low-level code(such as inline assembler and OS/hardware interfaces). 9.Text-generator(aka #define a(b)) and code-generator(template/mixin/lispmacro) macros. 10.Operator/function overloading without restrictions.
Name:
Anonymous2015-03-16 12:42
Sepples' main territory doesn't need any graphics because it isn't games. If it's optional, you are just going Java, complete with implementations that are either hopelessly incomplete or abstract over fucktons of OS functionality just to be considered compliant.
Text generators are useless in the face of code-generators, especially of the Lisp kind.
Your Bento box includes everything for the sake of including everything and shits on usability, so I guess it can dethrone Sepples just fine. Good job.
Name:
Anonymous2015-03-16 13:03
>>2 The "multi-paradigm way, there many ways to do it" always wins over pure dogmatic "one way - my way" systems. The list is actually the minimum of features the C++-dethroning language must have to have a chance to win the hearts of developers. They must see advantages vs C++: simpler and faster code. better syntax. Larger standard library. better architecture, object systems. better error checking, compiler support. If critical feature X is working better in C++ than in "new language" they wouldn't consider switching since switching cost is not justified. Switching cost is always high and needs to be counterbalanced with advantages of switching.
Name:
Anonymous2015-03-16 13:26
>>4 Having text macros and Lisp macros at the same time isn't multi-paradigm, it's retarded. Having OOP (thus subtyping) and type inference at the same time sounds nice, but is almost impossible to do reliably.
``like the good parts of all languages but without the bad parts'' isn't language design, it's wishful thinking, an illness that is way too common in Sepples fetishists. The worst part is that IMNHBT
language that will dethrone C++ will be C++2060 By that time it would include extensive parts of Lisp, JavaScript, Haskell and pieces of whatever hip new languages appear.
Name:
Anonymous2015-03-16 13:59
>>5 Unsafe, dirty text juggling macros that require no AST manipulation will be always a feature of C++. They're fast(to lex/parse) and easy to write. If there is X feature with N compilation overhead and Y feature with M>N compilation overhead, the X feature will remain. (incoming lisp weenie drivel about lisp macros being the end-all one-way to-write-everything in next posts follows)
Name:
Anonymous2015-03-16 16:49
Those are all idiot non-requirements.
2.Object abstraction system
What the fuck is that? You're talking out of your ass, smartass.
6.Clear and terse imperative syntax.
Haha nice oxymoron joke, faggot.
Name:
Anonymous2015-03-16 17:07
>>9 2.Support for OOP 6.C-like syntax, more clarity than C/C++.
Name:
Anonymous2015-03-16 17:38
>>10 But C++ does not have support for OOP, only for COP.
What you've tried to describe is C++ itself which means that the entire purpose of your thread is nihil. If Sepples is ever going to be overthrown, it will be by a different language. Replacing Sepples with Sepples* is too moronic even for Sepple-fags.
OP, just add macros to Ada and you have your language.
Name:
Anonymous2015-03-17 6:08
>>12 Has to be 10/10 only 6/10 [x]1.No dependencies on GC/refcounting. [x]2.Object abstraction system(as powerful as in C++). [x]3.Same or better execution speed(compared to similar C++ code). [ ]4.Type-inference,type-inferred lambda expression. [x]5.Strict type system with escapes(fast casts, conversion). [clear, not terse as C]6.Clear and terse imperative syntax. [x]7.Large standard library with functional/OOP/procedural programming support. Must include threading and graphics. [x]8.Support for low-level code(such as inline assembler and OS/hardware interfaces). [ ]9.Text-generator(aka #define a(b)) and code-generator(template/mixin/lispmacro) macros. [restricted to standard operators, as in C++]10.Operator/function overloading without restrictions.
Name:
Anonymous2015-03-17 17:27
The "OOP/COP" and "imperative" constraints are not unifiable with "Type-inference,type-inferred lambda expression".
"Clear and terse" is not unifiable with "imperative syntax".
"Operator/function overloading without restrictions" is not unifiable with "Type-inference,type-inferred lambda expression"
"Strict type system" is not unifiable with "with escapes(fast casts, conversion)".
>>14 These are more or less standard C++14 features(syntax might be less clear than desired).
Name:
Anonymous2015-03-17 18:16
>>16 In your dream Equestria world - perhaps. But not here on this mortal soil, where C++ does not have type inference, where its syntax is neither clear nor terse, where it doesn't have type inference (but I repeat myself) and where C++ doesn't have anything resembling a strict type system (it's breakable in a thousand unsafe ways even without static_cast).
>>18 No, sir Wikipedia Knight, "auto" is not nearly enough for a language to have type inference.
Name:
Anonymous2015-03-17 18:36
>>19 decltype(haskell weenie) http://en.wikipedia.org/wiki/Type_inference Some languages that include type inference are ML, OCaml, F#, Haskell, Scala, D, Clean, Opa, Rust, Swift, Visual Basic (starting with version 9.0), C# (starting with version 3.0) and C++11.
Name:
Anonymous2015-03-17 18:40
>>20 Wikipedia is not even Expert Bro-apper level, obviously. It amuses me how much trust you put in it.
The joy of auto The joy of decltype
Seppletards are like a sect based around sticking thorny and sharp dildoes up ass and then trying to convince oneself that it is pleasant. Hare Krishna.
The thing is, arg can be of type SomeClass or of any of its subtypes, and no inference algorithm can infer its type. So no, I'm sorry, but no type inference for Sepples. Ever.
Name:
Anonymous2015-03-17 21:34
prime get
Name:
Anonymous2015-03-18 0:43
>>19 >>21 If Wikipedia's articles are lacking, please edit them.
Name:
Alexander Dubček2015-03-18 0:55
C with Channels is a pleasure to use.
Name:
Anonymous2015-03-18 0:57
>>24 If you edit an article on Wikipedia some asshole who is the self proclaimed owner of the article will revert your changes then make the same change but rewritten by them. Wikipedians are cancer.
Name:
Anonymous2015-03-18 1:40
>>26 Not so. Sometimes you are just reverted by a bot.
>>26 As long as the change is made, does it matter who wrote it?
Name:
Anonymous2015-03-18 6:04
>>1 Static unchecked typecasts and token level macros will never be seen again because they are fucking horrible language destroying ideas. Modern C++ is practically defined by efforts to make the language act as if they had never existed.
>>31 It will be dethroned, but by a language that is actually better than it, not by Sepples 2.0.
Name:
Anonymous2015-03-19 4:55
But will it be better than dubs?
Name:
Anonymous2015-03-19 10:56
fibs get
Name:
Anonymous2015-03-19 13:27
>>30 You have to have unchecked typecasts if you wanna interface with hardware (being able to treat a number as an address to bytes and integers of various sizes), and it's required for certain bit hacks and things like fast int<->float conversions/rounding/rng.
Name:
Anonymous2015-03-19 16:11
Seeples will not be dethroned by a good feature set. It can absorb any features into itself, selling as both touting new features, as well as working with legacy codebases. The only thing that will dethrone C++, is some killer feature that is completely orthogonal to it's existing features.
>>35 Integer conversions most certainly can be checked, and this checking can be performed statically with zero runtime overhead in many cases. It is only necessary to provide escape mechanisms for raw word / bit level access in a very few cases, even in high performance or embedded code.
That C or C++ aren't required to do so by default is a weakness of those particular languages. Any C or C++ codebase of sufficient size is forced to implement its own abstractions for common integer conversion operations precisely because it is so easy to get them wrong.
auto provides only compile-time type inference, since the C/C++ type system only exists at compile time. The only type system available at runtime is that of machine code, which doesn't even have a notion of data type, as all machine code data is just strings of bits. Functions and instructions are typed insofar as different bit manipulations are needed to perform equivalent operations on different data types. This is the opposite of how C operators work: the '+' operator for example can mean either integer addition or floating point addition, depending on the types of the operands. In machine code on the other hand, integer addition and floating point addition are two different instructions, and the operands are interpreted differently depending on which instruction is used. Runtime type inference would require adding overhead to every variable to store its type, and checking types before every operation. That certainly could be done, but C focuses on eliminating any and all unnecessary overhead in order to provide maximum performance.
Runtime type inference would require adding overhead to every variable to store its type, and checking types before every operation
Wrong
Name:
Anonymous2016-11-11 17:46
>>51 If the type can change(fully dynamic) the system must store the type. Valid dynamic variable in js vat x=1.0 x="String" x=[1,["What","is","this","i'm","not","good", "with", "computers"]]
Name:
Anonymous2016-11-11 17:55
Rust: [x]1.No dependencies on GC/refcounting. [traits]2.Object abstraction system(as powerful as in C++). [almost]3.Same or better execution speed(compared to similar C++ code). [x]4.Type-inference,type-inferred lambda expression. [unsafe]5.Strict type system with escapes(fast casts, conversion). [x]6.Clear and terse imperative syntax. [almost]7.Large standard library with functional/OOP/procedural programming support. Must include threading and graphics. [x]8.Support for low-level code(such as inline assembler and OS/hardware interfaces). [macro_rules]9.Text-generator(aka #define a(b)) and code-generator(template/mixin/lispmacro) macros. [traits]10.Operator/function overloading without restrictions.