[=;139936]
maybe will be able to code even with QBASIC on UE4 
[/]
OMG! That would be sweet.
10 PRINT âUE4 Rocks!â
20 GOTO 10
[=timconwell;139948]
OMG! That would be sweet.
10 PRINT âUE4 Rocks!â
20 GOTO 10
[/]
ManâŚthat means we are oldâŚbut wasnât that?
Begin:
Print âUE4 Rocks!â
Goto Begin
Applesoft BASIC didnât have labels, so GOTO and GOSUB used line numbers. Named labels were really nice. Applesoft BASIC also only allowed two digit variable names, so AA, AB, AC, etc until you ran out.
Haha! Yeah, probably does mean we are old, or past the point of being young at least. Feel like I ought to brush up on my basic now. The pranks we used to play in the computer lab plus teachers who barely knew how this stuff worked. Good times.
[=gmpreussner;136995]
Iâll repeat what I said during the West Coast DevCon: All programming languages suck. They just suck in different ways 
[/]
Yup. Basically this. The interesting thing about programming is that the languages are simply tools to use for a job. I mean you can argue that a steak knife could cut steak better then a butter knife but in the end does it make it easier? Depends on the job (And how much memory you have to work with!) and the tools youâre comfortable with using.
Now having said that⌠I really love pointers, ha.
[=Master Kyp;140998]
Yup. Basically this. The interesting thing about programming is that the languages are simply tools to use for a job. I mean you can argue that a steak knife could cut steak better then a butter knife but in the end does it make it easier? Depends on the job (And how much memory you have to work with!) and the tools youâre comfortable with using.
Now having said that⌠I really love pointers, ha.
[/]
Yes to the above, but having said that, the whole point is which language is better suited for the job not which language sucks more.
It also depends on, what you are planning to prepare for your users. Will it be some âbeefyâ experience or just ordinary, every-day, bread and butter sandwich.
In my opinion (and I believe most of professional AAA developers) C++ is your man.
Gaming industry speaks C++.
[=;139936]
But things already being solved, there script that let you implement any scripting people like, once marketplace will be open for plugins you will maybe will be able to code even with QBASIC on UE4
[/]
And good luck with thatâŚ
âa steak knife could cut steak better then a butter knife but in the end does it make it easier?â
I believe a steak knife does cut up steak easier.
Finally! Something I know something about! Bam! 
Here is an interesting talk about what is horrible in C++, by one of the top leading figure in the C++ world - Scott Meyers :
https://.com/watch?v=48kP_Ssg2eY
Then, this is kind of off-topic here, but some people are going to find this interesting - itâs a take on game-programming from an experienced âAAAâ games developer and game-designer:
https://.com/watch?v=TH9VCN6UkyQ
There is an initiative that is developing for defining a spec for a new programming-language that is âkindaâ domain-specific for games, the same way Go is âkindaâ domain-specific - this is for actual game-engine code, not scripting, so itâs not about UE4 - itâs more about the future of programming in games in general.
He goes over many interesting topics, and touches on Go, D, and Rust, whatâs good about them to take inspiration from and whatâs not.
[=EruArnold;151998]
Then, this is kind of off-topic here, but some people are going to find this interesting - itâs a take on game-programming from an experienced âAAAâ games developer and game-designer:
There is an initiative that is developing for defining a spec for a new programming-language that is âkindaâ domain-specific for games, the same way Go is âkindaâ domain-specific - this is for actual game-engine code, not scripting, so itâs not about UE4 - itâs more about the future of programming in games in general.
He goes over many interesting topics, and touches on Go, D, and Rust, whatâs good about them to take inspiration from and whatâs not.
[/]
1.) Blow is an indie developer, not a AAA developer. Heâs notable for developing Braid.
2.) I watched the talk, I wouldnât call it a developing initiative yet. Itâs a week of thinking of some ways to write a better language, turned into a two hour talk.
That said, thanks for the link, it was a very interesting talk. I agree with most of his frustrations regarding C++, though Iâm not sure heâs put enough thought into his suggestions yet. In fact I think thatâs what the talk was, it was a kind of request for discussion on those ideas. I appreciate how often he tried to make it clear when he pulled things out of thin air.
Favorite part of the talk though, was the part where he mentioned wanting to stay away not only from languages built to support an ideology, but from doing that with this proposed language. Thatâs incredibly important.
The 85% > 100% as a design tenet is a good way to approach this, and he did a good job at not sounding elitist when saying it shouldnât be built explicitly for newbies.
But whether these things just sound good or actually turn into a decent alternative to C++ for games is still way up in the air, and right now itâs closer to just sounding good. Several of those suggestions sound great in theory, but Iâm worried about his throwing around the word âtrivialâ so much in regards to creating a new language. He doesnât speak as though he has experience in language design outside of (2+ decade old) college courses on writing compilers, so if he heads this up I expect some severe growing pains.
It is very easy to come up with âgreat ideasâ for great language. Much harder to actually see it through. Thatâs the first point.
âIn theory practice is simpleâ as somebody once said.
Second point - nobody ever claimed that C++ has no faults. So does C#, Java, python etc⌠All languages suck in some respect as one of the Epicâs guys pointed out. One of most horrible things in C# or Java? Its slowness, lame template system, decompiling is as easy as compiling etc, etc. The point is that all languages have their faults.
Main point is that as the current state of affairs is, C++ is the best and really only vital choice when AAA game programming is concerned. There is simply no way around it.
And I am really tired of hearing guys coming here and claiming that performance doesnât matter - especially when game development is concerned.
It does matter, it always did and it always will.
AAA Gaming industry speaks C++.
There is one languague that solved C++ annoyances. Itâs called D.
How many people are using it ? Oh ⌠How many of you heard about it ?
While designing new language is certainly not very easy, itâs also not terribly complex.
What is really hard:
- Getting people to use it.
- Build tools, to make using language easier.
If you donât have ecosystem around your language or you are not big enough to make that ecosystem happen (like Microsoft did with C#), then itâs just academic or fun activity to make new programming language, that is better.
At this point, I would bet more on native compiled C#, than anything else.
[=;152384]
There is one languague that solved C++ annoyances. Itâs called D.
How many people are using it ? Oh ⌠How many of you heard about it ?
While designing new language is certainly not very easy, itâs also not terribly complex.
What is really hard:
- Getting people to use it.
- Build tools, to make using language easier.
If you donât have ecosystem around your language or you are not big enough to make that ecosystem happen (like Microsoft did with C#), then itâs just academic or fun activity to make new programming language, that is better.
[/]
^^^ Agreed, agreed, agreed.
I think he makes some valid points in his talk - I donât think he is going to write any programming language himself - he even says so - so I wouldnât worry about his ability or background for being able to personally do it.
I think his main goal at this point is just to raise awareness of the possibility of such a project, and of the potential net-gain that can be made if/when such a thing would ever exist.
As for performance, , it is pretty obvious from your reaction that you didnât watch the talk at all.
He aims for such a new language to not only be faster then C++, but possibly even faster then C.
Granted, this is no small aspiration, but I agree with him that it is not impossible.
If you take into consideration the amount of bloat, cruft and general âlegacyâ/âbackward-compatibilityâ-related encumbrances that muti-decades-old languages like C and C++ carry with them, you should be able to build a case for the viability of possibly writing a new spec from scratch that doesât suffer from such evolutionary-baggage, and thus be potentially faster. He doesnât suggest another âmanaged-languageâ (like C# or Java), in fact, he flat-out dismisses the inclusion of any sort of garbage-collector as a ânon-starterâ, which is the main reason he dismisses Go, for exampleâŚ
I liked how he practically dismisses the whole âsmart-pointersâ story of C++11/14 as being âimpracticalâ, due to the cost of heap-allocation(s) and the need to consolidate them for any kind of real-world viability in terms of performance. This falls flat in the face of anyone claiming that C++11 âchanges the gameâ so to speak when it comes to memory-safety. It theory, yes it does. In practice, nopeâŚ
Same goes for standard-library templates for âcontainersâ and âalgorithmsâ - they may be at the point of being âaffordableâ, in terms of âprogrammer-productivityâ (thanks to the addition of âLambdasâ and âautoâ), as well as ârun-time-performanceâ (mainly thanks to r-value references, âMove-Semanticsâ, perfect-forwarding, variadic-templates, etc.) - but all of this is not âfreeâ, and incurres a cost at âcompile-timeâ - which makes them ultimately âun-affordableâ in the grand-scheme⌠(at least for large-projects, due to the accumulative compile-time-cost).
I am not sure this is a solvable-problem in a new language, but letâs think about it:
Letâs say a new language is designed, do the default-behaviors are the ones that are actually being used ~80% of the times in C++ anyways:
- Variables are âimmutableâ (const) by default, and you have to explicitly define them as mutable using a key-word (Rust does this).
- Ownership is âMovedâ by default, and you have to explicitly state you want to âShareâ (Rust does this, sortaâŚ)
- Arguments and assignment-operators are âpass-by-referenceâ by default, and you have to explicitly say you want a âcopyâ in case you do.
- Memory-Allocations of members (for structs/classes) are optimized in the compiler to be done âin-bulkâ by default, as well as guaranteed to be layed-out sequentially (which prevents the whole âmemory-block-memberâ workaround shown in the video, and known very well by game-developers).
- Pointers are unique by default (using a standard-notation, built-in to the language, not a template in a library that needs to be compiledâŚ).
- Shared-pointers have their own notation (say, re-purposing the â&â for this semantics, given No.2 + No.3 makes C++ style references redundant).
- Arrays are implemented built-in as the C++ Vectors are, and not as a compiled-template.
- All other containers as built-ins instead of templates (Maps, List, Queue, Set, etc.).
- Algorithms as built-in-functions instead of templates (Sort, find, etc).
- A decent âModulesâ architecture (no more pre-processor compilation of headers for inclusions/imports)
âŚ
I can go on, but you get the pictureâŚ
There is A LOT of room for improvement from what C++11/14 offers, just by taking a look at patterns that are already being done for decades now, and switching-up the default-behaviors to represent the +80% use-cases, as well as turning templates into built-ins - all of which can dramatically improve code-readability, expressiveness AND performance, memory-efficiency and safety, and all long before one even begins to talk about game-domain-specific optimizationsâŚ
So yeah, would it be difficult? Probably. Yes. Is it impossible? Definitely no. Is there a strong case for it? HELL YEAH!!!
[=EruArnold;152616]
I think he makes some valid points in his talk - I donât think he is going to write any programming language himself - he even says so - so I wouldnât worry about his ability or background for being able to personally do it.
I think his main goal at this point is just to raise awareness of the possibility of such a project, and of the potential net-gain that can be made if/when such a thing would ever exist.
As for performance, , it is pretty obvious from your reaction that you didnât watch the talk at all.
He aims for such a new language to not only be faster then C++, but possibly even faster then C.
Granted, this is no small aspiration, but I agree with him that it is not impossible.
If you take into consideration the amount of bloat, cruft and general âlegacyâ/âbackward-compatibilityâ-related encumbrances that muti-decades-old languages like C and C++ carry with them, you should be able to build a case for the viability of possibly writing a new spec from scratch that doesât suffer from such evolutionary-baggage, and thus be potentially faster. He doesnât suggest another âmanaged-languageâ (like C# or Java), in fact, he flat-out dismisses the inclusion of any sort of garbage-collector as a ânon-starterâ, which is the main reason he dismisses Go, for exampleâŚ
I liked how he practically dismisses the whole âsmart-pointersâ story of C++11/14 as being âimpracticalâ, due to the cost of heap-allocation(s) and the need to consolidate them for any kind of real-world viability in terms of performance. This falls flat in the face of anyone claiming that C++11 âchanges the gameâ so to speak when it comes to memory-safety. It theory, yes it does. In practice, nopeâŚ
Same goes for standard-library templates for âcontainersâ and âalgorithmsâ - they may be at the point of being âaffordableâ, in terms of âprogrammer-productivityâ (thanks to the addition of âLambdasâ and âautoâ), as well as ârun-time-performanceâ (mainly thanks to r-value references, âMove-Semanticsâ, perfect-forwarding, variadic-templates, etc.) - but all of this is not âfreeâ, and incurres a cost at âcompile-timeâ - which makes them ultimately âun-affordableâ in the grand-scheme⌠(at least for large-projects, due to the accumulative compile-time-cost).
I am not sure this is a solvable-problem in a new language, but letâs think about it:
Letâs say a new language is designed, do the default-behaviors are the ones that are actually being used ~80% of the times in C++ anyways:
- Variables are âimmutableâ (const) by default, and you have to explicitly define them as mutable using a key-word (Rust does this).
- Ownership is âMovedâ by default, and you have to explicitly state you want to âShareâ (Rust does this, sortaâŚ)
- Arguments and assignment-operators are âpass-by-referenceâ by default, and you have to explicitly say you want a âcopyâ in case you do.
- Memory-Allocations of members (for structs/classes) are optimized in the compiler to be done âin-bulkâ by default, as well as guaranteed to be layed-out sequentially (which prevents the whole âmemory-block-memberâ workaround shown in the video, and known very well by game-developers).
- Pointers are unique by default (using a standard-notation, built-in to the language, not a template in a library that needs to be compiledâŚ).
- Shared-pointers have their own notation (say, re-purposing the â&â for this semantics, given No.2 + No.3 makes C++ style references redundant).
- Arrays are implemented built-in as the C++ Vectors are, and not as a compiled-template.
- All other containers as built-ins instead of templates (Maps, List, Queue, Set, etc.).
- Algorithms as built-in-functions instead of templates (Sort, find, etc).
âŚ
I can go on, but you get the pictureâŚ
There is A LOT of room for improvement from what C++11/14 offers, just by taking a look at patterns that are already being done for decades now, and switching-up the default-behaviors to represent the +80% use-cases, as well as turning templates into built-ins - all of which can dramatically improve code-readability, expressiveness AND performance, memory-efficiency and safety, and all long before one even begins to talk about game-domain-specific optimizationsâŚ
So yeah, would it be difficult? Probably. Yes. Is it impossible? Definitely no. Is there a strong case for it? HELL YEAH!!!
[/]
This guy will never introduce any new language. He may aim and introducing language that is faster than C++, but all he will end up is just couple of excited talks. Nothing else.
Everybody can come up with great ideas for great language. This is so easy.
Implementing it, making people to use it is a very different story as @inside rightly pointed out.
I hope you not taking this guy seriously.
If Iâm wrong I will admit that I was wrong and get you a beer.
If Iâm right you will admit that, deal?
Lets give him 2-3 years and we see how this project progresses from where it is now, that is, big, âfairylandâ talk, nothing concrete, nothing else.
Of course this is very early, but there seems to be enough of a demand for such a thing, so my bet is that itâs going to get done eventually.
In fact, Rust may end-up being it, as he says - his only 2 reservations regarding it, is itâs memory-safety that feels too constraining (though there exist an escape-rout in the form of âunsafe {âŚ}â blocks), and itâs relative âimmaturityâ, which will be even more of an issue for a completely new language, and should be somewhat resolved in a few months/weeks for Rust when it officially reaches â1.0â - and even much more so in a year or 2 when âServoâ launches (Mozillaâs next-gen browser written in Rust).
Lets wait then.
[=timconwell;139948]
OMG! That would be sweet.
10 PRINT âUE4 Rocks!â
20 GOTO 10
[/]
Thanks for remembering how old I am!
So the flood-gates have finally opened, and cppcon 2014 video-recordings are starting to poor-into âŚ
Happened to stumble upon a particularly relevant talk about C++ for Game-Engine development:
https://.com/watch?v=rX0ItVEVjHc
Turns out, as you can see in the talk, that not only C++ is unfit for scripting, it is even also unfit for game-engines (!)
The speaker was asked specifically what are the benefits of using C++ as the language of choice to implement a game-engine, to which he could not come up with any answer⌠If it was up to him, the entire engine would be written in C99 with some parts in assembly (yes, he actually said that explicitly in a C++ conferenceâŚ).
Bjarnâs short-description for C++ has always been on the line of ââŚaffordable abstractionsâŚâ
Well, turns-out they are not so affordable after-all, and that compile-time is almost as important as runtime.
So, they donât use the STL at all, as well as (almost) never write or use any Templates(!)
Why? Too expensive in compile-time⌠(yes, thatâs what he said)
Think about the magnitude of that statement:
That means no smart-pointers of any kind (yes he said that specifically also), as well as no use of any standard containers or algorithms.
They also never use multiple-inheritance and tend to shy-away from virtual/abstract methods and function/operator-overloading.
Why? Too expensive in runtime-cost (perf. and/or mem.)
They also shy-away from having much members in any given class, as they tend to favor custom-made allocators.
So, where are all these so-called âaffordable abstractionsâ that have consistently been promised as the pinnacle of C++? Turns out there arenât that many leftâŚ
And if this isnât enough, turns-out that most compilers still optimize very poorly (surprised?), especially MSVC (no surprise hereâŚ), and require the code to include lotâs of unnecessary helping-hands to nudge them in the right direction.
In short, the C++ that you tend to find in game-engines code, seems to end-up looking like âC With Classesâ at best, and âPre C99â at worstâŚ
Abstractions? Type-Safety? Modern-Style? Turns one none of these âluxuriesâ are affordable for game-enginesâŚ
The only reason the speaker found to use C++, is âculturalâ, as he notes many timesâŚ
So, seems like even Modern C++ is the âmiddle-manâ that no one likes - it takes too much and returns very little benefitsâŚ
Too slow for game-engines, too unproductive for scripting game-logic.