@55:00 The funny thing is.... 25-30 years ago (and especially in the good old 8 bit era) in assembly language we generated our "constant parameters" EXACTLY like this . I spot so many relations between the "hot new stuff" and our old "dinosaur techniques", e.g. if you consider how the best (=most efficient) sprite and scrolling routines were written. The "real" runtime code for them was generated right at the beginning of the program (or a new game stage) by generic routines. Processing the gfx data "in advance" to transform it in a way that you got a *highly* optimizied mix of code with inline(!) data for every subroutine - for every specific object, of any given pixel size, color set and so on. This code included all dedicated animation frame data and could handle special cases of positioning atomatically. (...Objects? YES! The result was *big* but specialized code for any required graphics object. For calling such an object you did it just like calling a simple subroutine - but using the cpu registers as "properties" (=parameters) to select the TYPE of behavior that was required at runtime / computed beforehand by some game logic subroutine.)
My father was an technician for the phone company in Australia and we had the red phone at 4:00 in our house. (He got it because it was obsolete and was being thrown away). The hand set was so heavy and uncomfortable to use! A cool gimmick to have but impractical.
I think D is not more popular because of the name... They should rebrand it as D Flame or something. Something catchy, that shows it's fast, and google search actually can return relevant stuff... - And it's also like: rust is slow oxidation. Flame is a much faster oxidation! XD
Михаил Найденов the sad thing is that some companies are still stuck having to write C++ 98/03/11 due to various reasons. C++ 17 at this is really only for hobbyists and maybe a very few new companies.
No coincidence -- some of the same people are involved. D is agile and can have experimental features added or adjustments made, as in his anecdote. The knowledge (winners and losers -- it is just as important to know about pitfalls) is fed to the Committee that chew on it for 3 to 5 years. Case in point: Look for C++ conference presentation called "Static if I had a hammer". What is listed among D's "cons" actually are used to benefit: The lack of formal specification allows and permits rapid hacking on the language. The small but close-knit community _and_ lack of major corporate projects means you don't have to be as paranoid about backwards compatibility.
C++ has not and will not have compile time code generation and proper introspection. What they have added to it, or proposing to add, is nowhere near what D already provided at the time of this talk. Recall that we’re 3 years later and the gap between D and C++ seems to be widening, with D having much more developer friendly features. I’m a novice in D, but it feels more like “nice C” than C++, because C++ is comparatively so arcane. And yet D is a way more expressive language than not only C but also C++, yet feels simple.
@@absurdengineering Have you taken a look at using LLVM for compile time code generation and proper introspection? There are plenty of TH-cam videos about that.
Konstantin Rebrov Oh sure but that’s but a crutch. If you have an entire programming language that just works for what you want to do, then why mess with with amounts to rolling your own? C++ is wonderful for what it is, but it’s absurdly arcane due to the forced full backwards compatibility. There’s a lot of C++ that nobody should be using these days, and the fact we can’t just turn it off and forget about it is troubling. Dragging the almost 30 years of historical baggage along helps nobody. Let it be an optional interop feature that’s not on by default.
@@williamchamberlain2263 Those aren't really relevant, because they are barely a GC. Tracing GCs are not desirable, and contrary to wwwelkam, is not necessary for fast prototyping.
11:30 Quote: *there's no IF during compilation [...] whenever you need an IF, you need to call a different function* He's saying that he wants to be able to use the same keyword *if* in an overloaded sense... In one context, it would be executed during compile-time... in another context, it would be executed at run-time.
He means the fact a separate function might be needed to terminate template instantiation recursion. C++ 17 has this now - constexpr if can be used instead of a function.
Crazy economists - what's wrong with "positive feedback demand"? "Elastic demand implies" that demand levels off as you approach some limit, while some of those examples have unlimited demand.
I'm pretty sure elastic demand actually means that the amount demanded is highly sensitive to the price of the item. Inelastic on the other hand would be something like, idk water, where people demand it pretty constantly even if the price changes
nyrtzi Carrying dependencies means carrying a reference to a module. Moving it from file scope to any other scope changes nothing. The file still transitively depends on that thing you imported 20 turtles down - as long as that thing is used. Unused stuff gets its dependencies discarded, as it should. So build-wise it changes nothing whatsoever, except makes the build lighter since it doesn’t depend on things that you couldn’t make optional before.
Andrei is Brilliant and so is Walter. We want more D!
@55:00 The funny thing is.... 25-30 years ago (and especially in the good old 8 bit era) in assembly language we generated our "constant parameters" EXACTLY like this .
I spot so many relations between the "hot new stuff" and our old "dinosaur techniques", e.g. if you consider how the best (=most efficient) sprite and scrolling routines were written. The "real" runtime code for them was generated right at the beginning of the program (or a new game stage) by generic routines. Processing the gfx data "in advance" to transform it in a way that you got a *highly* optimizied mix of code with inline(!) data for every subroutine - for every specific object, of any given pixel size, color set and so on. This code included all dedicated animation frame data and could handle special cases of positioning atomatically. (...Objects? YES! The result was *big* but specialized code for any required graphics object. For calling such an object you did it just like calling a simple subroutine - but using the cpu registers as "properties" (=parameters) to select the TYPE of behavior that was required at runtime / computed beforehand by some game logic subroutine.)
programming reached the absolute peak with smalltalk. Everything else is toothpaste.
My father was an technician for the phone company in Australia and we had the red phone at 4:00 in our house. (He got it because it was obsolete and was being thrown away).
The hand set was so heavy and uncomfortable to use! A cool gimmick to have but impractical.
so you made code blocks into namespaces
I should have skipped to 0:40
lol iDid ..
They told us it's Universe all the way around! Turns out she wasn't that crazy.
I think D is not more popular because of the name... They should rebrand it as D Flame or something. Something catchy, that shows it's fast, and google search actually can return relevant stuff...
- And it's also like: rust is slow oxidation. Flame is a much faster oxidation! XD
He was right about skipping the first 30 seconds.
great talk.
11:40 interesting how all downsides of C++ are either fixed already or work in progress in fixing.
Михаил Найденов
the sad thing is that some companies are still stuck having to write C++ 98/03/11 due to various reasons. C++ 17 at this is really only for hobbyists and maybe a very few new companies.
No coincidence -- some of the same people are involved. D is agile and can have experimental features added or adjustments made, as in his anecdote. The knowledge (winners and losers -- it is just as important to know about pitfalls) is fed to the Committee that chew on it for 3 to 5 years. Case in point: Look for C++ conference presentation called "Static if I had a hammer".
What is listed among D's "cons" actually are used to benefit: The lack of formal specification allows and permits rapid hacking on the language. The small but close-knit community _and_ lack of major corporate projects means you don't have to be as paranoid about backwards compatibility.
C++ has not and will not have compile time code generation and proper introspection. What they have added to it, or proposing to add, is nowhere near what D already provided at the time of this talk. Recall that we’re 3 years later and the gap between D and C++ seems to be widening, with D having much more developer friendly features. I’m a novice in D, but it feels more like “nice C” than C++, because C++ is comparatively so arcane. And yet D is a way more expressive language than not only C but also C++, yet feels simple.
@@absurdengineering Have you taken a look at using LLVM for compile time code generation and proper introspection? There are plenty of TH-cam videos about that.
Konstantin Rebrov Oh sure but that’s but a crutch. If you have an entire programming language that just works for what you want to do, then why mess with with amounts to rolling your own? C++ is wonderful for what it is, but it’s absurdly arcane due to the forced full backwards compatibility. There’s a lot of C++ that nobody should be using these days, and the fact we can’t just turn it off and forget about it is troubling. Dragging the almost 30 years of historical baggage along helps nobody. Let it be an optional interop feature that’s not on by default.
one likely unsuccessful feature of D IMO: the GC :)
dlang.org/spec/function.html#nogc-functions
GC allows for fast prototyping so its a nice feature.
@@qm3ster : ) don't shared_pointers introduce garbage collection?
@@williamchamberlain2263 Those aren't really relevant, because they are barely a GC. Tracing GCs are not desirable, and contrary to wwwelkam, is not necessary for fast prototyping.
Please provide examples for what a "Recursion/Overloading for if" (actually of if)
would mean in practice.
11:30 Quote: *there's no IF during compilation [...] whenever you need an IF, you need to call a different function*
He's saying that he wants to be able to use the same keyword *if* in an overloaded sense... In one context, it would be executed during compile-time... in another context, it would be executed at run-time.
He means the fact a separate function might be needed to terminate template instantiation recursion. C++ 17 has this now - constexpr if can be used instead of a function.
Brilliant! Did they distribute sleeping-pills to the audience?
3 things in an HOUR
The Jules meme made me laugh.
Crazy economists - what's wrong with "positive feedback demand"? "Elastic demand implies" that demand levels off as you approach some limit, while some of those examples have unlimited demand.
I'm pretty sure elastic demand actually means that the amount demanded is highly sensitive to the price of the item. Inelastic on the other hand would be something like, idk water, where people demand it pretty constantly even if the price changes
@@Swedishnbkongu keying it to price alone assumes that the price is relatively low compared to the consumers' available budget.
Okay, so things carry their dependencies with them. How does things work with build tools aimed at making reproducible builds possible?
nyrtzi Carrying dependencies means carrying a reference to a module. Moving it from file scope to any other scope changes nothing. The file still transitively depends on that thing you imported 20 turtles down - as long as that thing is used. Unused stuff gets its dependencies discarded, as it should. So build-wise it changes nothing whatsoever, except makes the build lighter since it doesn’t depend on things that you couldn’t make optional before.
Googling for functional coding examples was a pointless waste of time. Respect your audience's time more than that.
What a boring talk