September 30, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | Am 30.09.2013 14:48, schrieb bearophile:
> Paulo Pinto:
>
>> By writing D instead. :)
>
> D helps avoids several C++ traps, but it's far from being not-bug-prone.
>
> Bye,
> bearophile
True, but changing system programming languages takes ages as it depends on the whims of OS vendors.
As such, it seems we can only hope for incremental changes.
--
Paulo
|
October 01, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | I'm waiting for Carmack to adopt D already. Barring some implementation details (GC issues, shared libraries, bla bla) it's pretty much the perfect language for what he wants to do. (Fast and functional in parts.) Plus, if anyone could work around issues or figure out how to do really cool things with D, it would be Carmack. |
October 01, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to w0rp | On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote:
> I'm waiting for Carmack to adopt D already. Barring some implementation details (GC issues, shared libraries, bla bla) it's pretty much the perfect language for what he wants to do. (Fast and functional in parts.) Plus, if anyone could work around issues or figure out how to do really cool things with D, it would be Carmack.
He is familiar with D and has shown appreciation for D `pure` functions in his twitter posts.
|
October 01, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On Tuesday, 1 October 2013 at 12:14:31 UTC, Dicebot wrote:
> On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote:
>> I'm waiting for Carmack to adopt D already. Barring some implementation details (GC issues, shared libraries, bla bla) it's pretty much the perfect language for what he wants to do. (Fast and functional in parts.) Plus, if anyone could work around issues or figure out how to do really cool things with D, it would be Carmack.
>
> He is familiar with D and has shown appreciation for D `pure` functions in his twitter posts.
Link to post? Sorry, but what does 'pure' mean in this content? Does it's mean good or bad?
|
October 01, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to Suliman | On Tuesday, 1 October 2013 at 12:27:56 UTC, Suliman wrote: > On Tuesday, 1 October 2013 at 12:14:31 UTC, Dicebot wrote: >> On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote: >>> I'm waiting for Carmack to adopt D already. Barring some implementation details (GC issues, shared libraries, bla bla) it's pretty much the perfect language for what he wants to do. (Fast and functional in parts.) Plus, if anyone could work around issues or figure out how to do really cool things with D, it would be Carmack. >> >> He is familiar with D and has shown appreciation for D `pure` functions in his twitter posts. > > Link to post? Sorry, but what does 'pure' mean in this content? Does it's mean good or bad? https://twitter.com/ID_AA_Carmack/status/173111220092682240 http://dlang.org/function.html#pure-functions |
October 01, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to w0rp | Am 01.10.2013 14:02, schrieb w0rp:
> I'm waiting for Carmack to adopt D already. Barring some implementation
> details (GC issues, shared libraries, bla bla) it's pretty much the
> perfect language for what he wants to do. (Fast and functional in
> parts.) Plus, if anyone could work around issues or figure out how to do
> really cool things with D, it would be Carmack.
There are a few QuakeCon talks, already mentioned here, where we goes along describing his endeavours with Haskell, OCaml, Lisp and Scheme.
But he also mentions that he has some issues to expose normal game developers to such languages, and is exploring how to bring some of those ideas into their C++ codebase.
Will he ever try D? Who knows.
One thing that I got to learn from the game development culture, is that tooling does not matter the way other software development industries think about it.
What really matters about software stacks, is using the official devkits, and the right tooling that allows to transform an idea into a game that sells.
If the languages, IDE, and so on, are good or bad, it does not matter that much. In comparison to have prototypes running fast enough and achieving publisher deals.
--
Paulo
|
October 04, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Sabalausky | On 27/09/2013 23:10, Nick Sabalausky wrote: > On Fri, 27 Sep 2013 12:35:29 +0100 > Bruno Medeiros <brunodomedeiros+dng@gmail.com> wrote: > >> "Hardware does get faster more rapidly than software gets slower -- >> > > Well, when you're in an industry that's constantly upgrading to the > latest top-of-the-line hardware, perhaps; for everyone else, certainly > not. > New hardware is cheap, for a developer's salary. But even so desktop specs haven't even improved much in the last 3 years or so (apart from GPUs). My desktop is 4 years old and I don't think I would tell a difference in performance if I upgraded it (again, apart from the GPU). -- Bruno Medeiros - Software Engineer |
October 04, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to Bruno Medeiros | On Fri, 04 Oct 2013 16:36:12 +0100 Bruno Medeiros <brunodomedeiros+dng@gmail.com> wrote: > On 27/09/2013 23:10, Nick Sabalausky wrote: > > On Fri, 27 Sep 2013 12:35:29 +0100 > > Bruno Medeiros <brunodomedeiros+dng@gmail.com> wrote: > > > >> "Hardware does get faster more rapidly than software gets slower -- > >> > > > > Well, when you're in an industry that's constantly upgrading to the latest top-of-the-line hardware, perhaps; for everyone else, certainly not. > > > > New hardware is cheap, for a developer's salary. But not always necessary, depending on the exact field and industry. > But even so desktop > specs haven't even improved much in the last 3 years or so (apart > from GPUs). My desktop is 4 years old and I don't think I would tell > a difference in performance if I upgraded it (again, apart from the > GPU). > Yea, exactly. I'm amazed that even "low-end" budget machines are so ridiculously powerful these days. Pretty damn cool. |
October 04, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dicebot | On 01/10/13 14:14, Dicebot wrote:
> On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote:
>> I'm waiting for Carmack to adopt D already. Barring some implementation
>> details (GC issues, shared libraries, bla bla) it's pretty much the perfect
>> language for what he wants to do. (Fast and functional in parts.) Plus, if
>> anyone could work around issues or figure out how to do really cool things
>> with D, it would be Carmack.
>
> He is familiar with D and has shown appreciation for D `pure` functions in his
> twitter posts.
One thing that I noted in his QuakeCon talk was his remarks about multiparadigm languages versus strictly functional languages, and how the former while they seem superior have the problem that, because you _can_ break the paradigm, you _do_.
I rather suspected he might have had D partially in mind with that remark, although he was gracious enough to not single out any languages.
That said, although I don't feel experienced enough in functional programming to comment with any authority, my impression is that D lets you be as strictly functional as you want to be, and has enough to let software architects impose strict purity etc. on a codebase. But it is arguably less nice to have to keep marking "pure const nothrow ..." everywhere, plus const/immutable parameters, compared to something like Haskell where everything is that way by default.
I don't suppose it's possible to do that either by scope or even by module?
module my.module const nothrow pure @safe
or
const nothrow pure @safe
{
// my code here ...
}
|
October 04, 2013 Re: John Carmack on Eclipse performance | ||||
---|---|---|---|---|
| ||||
Posted in reply to Joseph Rushton Wakeling | On Friday, 4 October 2013 at 23:38:17 UTC, Joseph Rushton Wakeling wrote:
> On 01/10/13 14:14, Dicebot wrote:
>> On Tuesday, 1 October 2013 at 12:02:29 UTC, w0rp wrote:
>>> I'm waiting for Carmack to adopt D already. Barring some implementation
>>> details (GC issues, shared libraries, bla bla) it's pretty much the perfect
>>> language for what he wants to do. (Fast and functional in parts.) Plus, if
>>> anyone could work around issues or figure out how to do really cool things
>>> with D, it would be Carmack.
>>
>> He is familiar with D and has shown appreciation for D `pure` functions in his
>> twitter posts.
>
> One thing that I noted in his QuakeCon talk was his remarks about multiparadigm languages versus strictly functional languages, and how the former while they seem superior have the problem that, because you _can_ break the paradigm, you _do_.
>
> I rather suspected he might have had D partially in mind with that remark, although he was gracious enough to not single out any languages.
>
> That said, although I don't feel experienced enough in functional programming to comment with any authority, my impression is that D lets you be as strictly functional as you want to be, and has enough to let software architects impose strict purity etc. on a codebase. But it is arguably less nice to have to keep marking "pure const nothrow ..." everywhere, plus const/immutable parameters, compared to something like Haskell where everything is that way by default.
>
> I don't suppose it's possible to do that either by scope or even by module?
>
> module my.module const nothrow pure @safe
>
> or
>
> const nothrow pure @safe
> {
> // my code here ...
> }
D has some really serious flaw when it come to functionnal style.
- Function aren't first class.
- Delegates break type system.
- Immutable object have identity issue that wouldn't show up in a functional language. It is unsure what the semantic around them is (and if identity must be preserved, then functional style is badly impaired).
- Many qualifier do start to not make any sense when using functions as arguments (inout for instance).
- Expect for type qualifier, it is impossible to express return qualification depending on the input(s qualification (and see point above, that do not work when using first class functions/delegates).
On implementation side, heap allocated values aren't optimized to go on the stack, ever. And the GC is unable to take advantage of immutability. Note that because everything is immutable in functional programming, both are mandatory if you don't want to trash your performances.
|
Copyright © 1999-2021 by the D Language Foundation