Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Dethroning C++

Name: Anonymous 2015-03-16 12:34

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: Anonymous 2015-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: Anonymous 2015-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: Anonymous 2015-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

Name: Anonymous 2015-03-16 13:40

subtyping is precisely why OOP is fucking shit

Name: Anonymous 2015-03-16 13:47

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: Anonymous 2015-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: Anonymous 2015-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: Anonymous 2015-03-16 17:07

>>9
2.Support for OOP
6.C-like syntax, more clarity than C/C++.

Name: Anonymous 2015-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.

Name: Anonymous 2015-03-16 17:40

OP, just add macros to Ada and you have your language.

Name: Anonymous 2015-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: Anonymous 2015-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)".

Conclusion: OP is a moron.

Name: Anonymous 2015-03-17 17:36

>>14
Unify this
*grabs dick*

Name: Anonymous 2015-03-17 18:08

>>14
These are more or less standard C++14 features(syntax might be less clear than desired).

Name: Anonymous 2015-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).

Name: Anonymous 2015-03-17 18:20

>>14 Throw away your logic and kick reason to the curb!
http://en.wikipedia.org/wiki/C%2B%2B14#New_language_features
http://en.wikipedia.org/wiki/C%2B%2B11#Type_inference
http://en.wikipedia.org/wiki/C%2B%2B11#Alternative_function_syntax
http://www.cprogramming.com/c++11/c++11-auto-decltype-return-value-after-function.html
http://www.cprogramming.com/c++11/c++11-lambda-closures.html
http://www.cprogramming.com/c++11/c++11-nullptr-strongly-typed-enum-class.html
http://www.cprogramming.com/c++11/rvalue-references-and-move-semantics-in-c++11.html

Name: Anonymous 2015-03-17 18:27

>>18
No, sir Wikipedia Knight, "auto" is not nearly enough for a language to have type inference.

Name: Anonymous 2015-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: Anonymous 2015-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.

Name: Anonymous 2015-03-17 18:43

>>20
void foo(SomeClass arg) {
// SepplesTypeInfer(arg) = ???

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: Anonymous 2015-03-17 21:34

prime get

Name: Anonymous 2015-03-18 0:43

>>19
>>21
If Wikipedia's articles are lacking, please edit them.

Name: Alexander Dubček 2015-03-18 0:55

C with Channels is a pleasure to use.

Name: Anonymous 2015-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: Anonymous 2015-03-18 1:40

>>26
Not so. Sometimes you are just reverted by a bot.

Name: Anonymous 2015-03-18 3:17

>>26
As long as the change is made, does it matter who wrote it?

Name: Anonymous 2015-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.

Name: Anonymous 2015-03-18 6:07

>>30
So C++ will never be dethroned. </thread>

Name: Anonymous 2015-03-18 18:20

>>31
It will be dethroned, but by a language that is actually better than it, not by Sepples 2.0.

Name: Anonymous 2015-03-19 4:55

But will it be better than dubs?

Name: Anonymous 2015-03-19 10:56

fibs get

Name: Anonymous 2015-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: Anonymous 2015-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.

Name: Anonymous 2015-03-19 17:42

deepthroating C++

Name: Anonymous 2015-03-20 2:03

>>37
Sounds dangerous.

Name: Anonymous 2015-03-20 8:18

>>36
Homoiconic Back-Tracing Left-Functor Deduction
(very useful in writing Abstract Homoiconic Back-Tracing Left-Functors)

Name: Anonymous 2015-03-20 14:03

>>37
Good way to get std::s. ( ≖‿≖)
Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List
All trademarks and copyrights on this site are owned by their respective parties. All comments and posts are the responsibility of their own posters.
- Tinychan + 2ch Mode + RSS -