Jump to page: 1 223  
Page
Thread overview
The God Language
Dec 29, 2011
Walter Bright
Dec 29, 2011
Max Samukha
Dec 29, 2011
Walter Bright
Dec 29, 2011
Caligo
Dec 29, 2011
Vladimir Panteleev
Dec 29, 2011
Gour
Dec 29, 2011
Caligo
Dec 29, 2011
maarten van damme
Jan 02, 2012
Nick Sabalausky
Jan 02, 2012
Timon Gehr
Jan 02, 2012
Caligo
Jan 03, 2012
Gour
Jan 03, 2012
Timon Gehr
Jan 03, 2012
Gour
Jan 03, 2012
Nick Sabalausky
Jan 03, 2012
Walter Bright
Jan 03, 2012
Nick Sabalausky
Jan 03, 2012
Walter Bright
Jan 03, 2012
J Arrizza
Jan 03, 2012
maarten van damme
Jan 03, 2012
J Arrizza
Dec 29, 2011
Jacob Carlborg
Dec 29, 2011
Walter Bright
Dec 29, 2011
so
Dec 29, 2011
FeepingCreature
Jan 02, 2012
Simen Kjærås
Dec 29, 2011
Don
Jan 05, 2012
bcs
System programming in D (Was: The God Language)
Dec 29, 2011
Vladimir Panteleev
Dec 29, 2011
so
Dec 29, 2011
Walter Bright
Dec 29, 2011
Kapps
Dec 29, 2011
a
Dec 29, 2011
David Nadlinger
Dec 29, 2011
Paulo Pinto
Dec 29, 2011
a
Dec 29, 2011
Walter Bright
Dec 29, 2011
a
Dec 29, 2011
Walter Bright
Dec 29, 2011
Peter Alexander
Dec 29, 2011
bearophile
Dec 29, 2011
Don
Dec 29, 2011
Vladimir Panteleev
Dec 29, 2011
Don
Dec 29, 2011
Vladimir Panteleev
Dec 29, 2011
so
Dec 29, 2011
bearophile
Dec 29, 2011
Vladimir Panteleev
Dec 29, 2011
Walter Bright
Dec 29, 2011
Walter Bright
Dec 29, 2011
so
Dec 29, 2011
Walter Bright
Dec 29, 2011
Walter Bright
Jan 02, 2012
Nick Sabalausky
Dec 30, 2011
Vladimir Panteleev
Dec 30, 2011
Walter Bright
Dec 30, 2011
Vladimir Panteleev
Dec 30, 2011
Walter Bright
Dec 30, 2011
Peter Alexander
Dec 30, 2011
Vladimir Panteleev
Dec 30, 2011
Vladimir Panteleev
Dec 30, 2011
so
Dec 30, 2011
Walter Bright
Dec 30, 2011
Chad J
Dec 31, 2011
so
Dec 31, 2011
Iain Buclaw
Dec 31, 2011
so
Dec 31, 2011
Iain Buclaw
Dec 31, 2011
so
Dec 31, 2011
Walter Bright
Dec 31, 2011
so
Dec 31, 2011
Walter Bright
Dec 31, 2011
Mike Wey
Dec 31, 2011
Iain Buclaw
Dec 31, 2011
so
Dec 30, 2011
Chad J
Dec 30, 2011
Walter Bright
Dec 30, 2011
Chad J
Dec 30, 2011
Trass3r
Jan 03, 2012
Martin Nowak
Jan 04, 2012
Vladimir Panteleev
Dec 29, 2011
Timon Gehr
Dec 29, 2011
David Nadlinger
Dec 30, 2011
Vladimir Panteleev
Dec 29, 2011
Timon Gehr
Dec 30, 2011
Vladimir Panteleev
Dec 30, 2011
Timon Gehr
Dec 30, 2011
Vladimir Panteleev
Dec 30, 2011
so
Dec 30, 2011
Walter Bright
Dec 30, 2011
Timon Gehr
Dec 30, 2011
Timon Gehr
Dec 30, 2011
Walter Bright
Dec 30, 2011
Timon Gehr
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Walter Bright
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Walter Bright
Dec 31, 2011
Timon Gehr
Dec 31, 2011
Walter Bright
Dec 31, 2011
Walter Bright
Dec 31, 2011
Timon Gehr
Jan 02, 2012
Nick Sabalausky
Jan 02, 2012
Timon Gehr
Jan 03, 2012
Jonathan M Davis
Dec 30, 2011
Timon Gehr
Jan 04, 2012
Manu
Jan 04, 2012
bearophile
Jan 04, 2012
Manu
Jan 05, 2012
bearophile
Jan 05, 2012
Peter Alexander
Jan 05, 2012
Manu
Jan 05, 2012
Timon Gehr
Jan 05, 2012
Manu
Jan 05, 2012
Manu
Jan 05, 2012
Walter Bright
Jan 05, 2012
Sean Kelly
Jan 05, 2012
Peter Alexander
Jan 05, 2012
Manu
Jan 05, 2012
Manu
Jan 05, 2012
Sean Kelly
Jan 05, 2012
Manu
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Sean Kelly
Jan 05, 2012
Manu
Jan 05, 2012
Manu
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Artur Skawina
Jan 05, 2012
Manu
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Sean Kelly
Jan 05, 2012
Walter Bright
Jan 06, 2012
Sean Kelly
Jan 07, 2012
Walter Bright
Jan 05, 2012
Walter Bright
Jan 05, 2012
Manu
Jan 06, 2012
Walter Bright
Jan 06, 2012
Iain Buclaw
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Manu
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Peter Alexander
Jan 05, 2012
bearophile
Jan 05, 2012
Peter Alexander
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Manu
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Walter Bright
Jan 05, 2012
Manu
Jan 05, 2012
Walter Bright
Jan 05, 2012
a
Jan 05, 2012
Manu
Jan 04, 2012
Vladimir Panteleev
Jan 04, 2012
Rainer Schuetze
Jan 09, 2012
Martin Nowak
Jan 09, 2012
Manu
Jan 04, 2012
Manu
Re: System programming in D
Jan 05, 2012
Jerry
Jan 04, 2012
Artur Skawina
Jan 04, 2012
Artur Skawina
Jan 05, 2012
Jacob Carlborg
Jan 05, 2012
Artur Skawina
Jan 05, 2012
Jacob Carlborg
Jan 05, 2012
Vladimir Panteleev
Jan 06, 2012
Jacob Carlborg
Jan 04, 2012
Manu
Jan 04, 2012
Walter Bright
Jan 04, 2012
bearophile
Jan 05, 2012
Walter Bright
Jan 05, 2012
Jacob Carlborg
Jan 04, 2012
Manu
Jan 04, 2012
Timon Gehr
Jan 04, 2012
Manu
Jan 05, 2012
Timon Gehr
Jan 05, 2012
Walter Bright
Method hiding [Was: Re: System programming in D]
Jan 05, 2012
bearophile
Jan 05, 2012
Jesse Phillips
Re: Method hiding
Jan 05, 2012
bearophile
Jan 06, 2012
Jesse Phillips
Jan 06, 2012
bearophile
Jan 05, 2012
Manu
Jan 05, 2012
Walter Bright
Jan 05, 2012
Manu
Jan 06, 2012
Walter Bright
Jan 06, 2012
Manu
Jan 05, 2012
Sean Kelly
Jan 05, 2012
Vladimir Panteleev
Jan 05, 2012
Sean Kelly
Jan 05, 2012
Walter Bright
Jan 05, 2012
Manu
Jan 05, 2012
Walter Bright
Jan 04, 2012
Timon Gehr
Jan 04, 2012
Manu
Jan 05, 2012
Iain Buclaw
Jan 05, 2012
Andrew Wiley
Jan 05, 2012
Artur Skawina
Jan 05, 2012
Artur Skawina
Jan 05, 2012
Manu
Jan 05, 2012
Walter Bright
Jan 05, 2012
Manu
Jan 05, 2012
Walter Bright
Jan 05, 2012
Andrej Mitrovic
Jan 05, 2012
Andrej Mitrovic
Jan 05, 2012
Manu
Jan 05, 2012
Walter Bright
Jan 09, 2012
Iain Buclaw
Jan 09, 2012
Artur Skawina
Jan 09, 2012
Iain Buclaw
Jan 09, 2012
Artur Skawina
Jan 09, 2012
Iain Buclaw
Jan 02, 2012
Jonathan M Davis
Jan 05, 2012
Mattbeui
December 29, 2011
http://pastebin.com/AtuzJqh0
December 29, 2011
On 12/29/2011 11:16 AM, Walter Bright wrote:
> http://pastebin.com/AtuzJqh0

He will soon realize that he wants an earthborn language rather than the one of God :)
December 29, 2011
On 12/29/2011 1:32 AM, Max Samukha wrote:
> On 12/29/2011 11:16 AM, Walter Bright wrote:
>> http://pastebin.com/AtuzJqh0
>
> He will soon realize that he wants an earthborn language rather than the one of
> God :)

Watch out, or you may attract a thunderbolt!!
December 29, 2011
On Thu, Dec 29, 2011 at 3:16 AM, Walter Bright <newshound2@digitalmars.com>wrote:

> http://pastebin.com/AtuzJqh0
>

This is somewhat of a serious question:  If there is a God (I'm not saying there isn't, and I'm not saying there is), what language would he choose to create the universe?  It would be hard for us mortals to imagine, but would it resemble a functional programming language more or something else?  And what type of hardware would the code run on?  I mean, there are computations happening all around us, e.g., when an apple falls or planets circle the sun, etc, so what's performing all the computation?


December 29, 2011
On Thursday, 29 December 2011 at 10:16:03 UTC, Caligo wrote:
> On Thu, Dec 29, 2011 at 3:16 AM, Walter Bright
> <newshound2@digitalmars.com>wrote:
>
>> http://pastebin.com/AtuzJqh0
>>
>
> This is somewhat of a serious question:  If there is a God (I'm not saying there isn't, and I'm not saying there is), what language would he choose to create the universe?  It would be hard for us mortals to imagine, but would it resemble a functional programming language more or something else?  And what type of hardware would the code run on?  I mean, there are
> computations happening all around us, e.g., when an apple falls or planets circle the sun, etc, so what's performing all the computation?

Obligatory XKCD: http://xkcd.com/224/
December 29, 2011
On Thu, 29 Dec 2011 04:15:27 -0600
Caligo <iteronvexor@gmail.com> wrote:

> This is somewhat of a serious question:  If there is a God (I'm not saying there isn't, and I'm not saying there is),

There is. ;)

> It would be hard for us mortals to imagine, but would it resemble a functional programming language more or something else?

Just answer the following question: Are we mortals the result of pure function or just side-effect?


Sincerely,
Gour

-- 
There are principles to regulate attachment and aversion pertaining to the senses and their objects. One should not come under the control of such attachment and aversion, because they are stumbling blocks on the path of self-realization.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810


December 29, 2011
On Thu, Dec 29, 2011 at 4:40 AM, Gour <gour@atmarama.net> wrote:

>
>
> Just answer the following question: Are we mortals the result of pure function or just side-effect?
>
>
>
You are asking about creationism and evolution, aren't you?  I have to say that I don't know.

Always trust the one who is looking for the truth, not the one who has found it. :-)


December 29, 2011
On Thursday, 29 December 2011 at 09:16:23 UTC, Walter Bright wrote:
> Are you a ridiculous hacker? Inline x86 assembly that the compiler actually understands in 32 AND 64 bit code, hex string literals like x"DE ADB EEF" where spacing doesn't matter, the ability to set data alignment cross-platform with type.alignof = 16, load your shellcode verbatim into a string like so: auto str = import("shellcode.txt");

I would like to talk about this for a bit. Personally, I think D's system programming abilities are only half-way there. Note that I am not talking about use cases in high-level application code, but rather low-level, widely-used framework code, where every bit of performance matters (for example: memory copy routines, string builders, garbage collectors).

In-line assembler as part of the language is certainly neat, and in fact coming from Delphi to C++ I was surprised to learn that C++ implementations adopted different syntax for asm blocks. However, compared to some C++ compilers, it has severe limitations and is D's only trick in this alley.

For one thing, there is no way to force the compiler to inline a function (like __forceinline / __attribute((always_inline)) ). This is fine for high-level code (where users are best left with PGO and "the compiler knows best"), but sucks if you need a guarantee that the function must be inlined. The guarantee isn't just about inlining heuristics, but also implementation capabilities. For example, some implementations might not be able to inline functions that use certain language features, and your code's performance could demand that such a short function must be inlined. One example of this is inlining functions containing asm blocks - IIRC DMD does not support this. The compiler should fail the build if it can't inline a function tagged with @forceinline, instead of shrugging it off and failing silently, forcing users to check the disassembly every time.

You may have noticed that GCC has some ridiculously complicated assembler facilities. However, they also open the way to the possibilities of writing optimal code - for example, creating custom calling conventions, or inlining assembler functions without restricting the caller's register allocation with a predetermined calling convention. In contrast, DMD is very conservative when it comes to mixing D and assembler. One time I found that putting an asm block in a function turned what were single instructions into blocks of 6 instructions each.

D's lacking in this area makes it impossible to create language features that are on the level of D's compiler built-ins. For example, I have tested three memcpy implementations recently, but none of them could beat DMD's standard array slice copy (despite that in release mode it compiles to a simple memcpy call). Why? Because the overhead of using a custom memcpy routine negated its performance gains.

This might have been alleviated with the presence of sane macros, but no such luck. String mixins are not the answer: trying to translate macro-heavy C code to D using string mixins is string escape hell, and we're back to the level of shell scripts.

We've discussed this topic on IRC recently. From what I understood, Andrei thinks improvements in this area are not "impactful" enough, which I find worrisome.

Personally, I don't think D qualifies as a true "system programming language" in light of the above. It's more of a compiled language with pointers and assembler. Before you disagree with any of the above, first (for starters) I'd like to invite you to translate Daniel Vik's C memcpy implementation to D: http://www.danielvik.com/2010/02/fast-memcpy-in-c.html . It doesn't even use inline assembler or compiler intrinsics.
December 29, 2011
I think it would be an object oriented language, I'm a believer in the
string theory :)
I have actually thought of the whole universe as one big simulation, would
really explain how light waves without medium (like a math function).

If I were god I would def use object oriented because it makes for easy describing of different particles and strings. and I'm pretty sure there is no garbage collector included in gods language :p


December 29, 2011
On 29-12-2011 12:19, Vladimir Panteleev wrote:
> On Thursday, 29 December 2011 at 09:16:23 UTC, Walter Bright wrote:
>> Are you a ridiculous hacker? Inline x86 assembly that the compiler
>> actually understands in 32 AND 64 bit code, hex string literals like
>> x"DE ADB EEF" where spacing doesn't matter, the ability to set data
>> alignment cross-platform with type.alignof = 16, load your shellcode
>> verbatim into a string like so: auto str = import("shellcode.txt");
>
> I would like to talk about this for a bit. Personally, I think D's
> system programming abilities are only half-way there. Note that I am not
> talking about use cases in high-level application code, but rather
> low-level, widely-used framework code, where every bit of performance
> matters (for example: memory copy routines, string builders, garbage
> collectors).
>
> In-line assembler as part of the language is certainly neat, and in fact
> coming from Delphi to C++ I was surprised to learn that C++
> implementations adopted different syntax for asm blocks. However,
> compared to some C++ compilers, it has severe limitations and is D's
> only trick in this alley.
>
> For one thing, there is no way to force the compiler to inline a
> function (like __forceinline / __attribute((always_inline)) ). This is
> fine for high-level code (where users are best left with PGO and "the
> compiler knows best"), but sucks if you need a guarantee that the
> function must be inlined. The guarantee isn't just about inlining
> heuristics, but also implementation capabilities. For example, some
> implementations might not be able to inline functions that use certain
> language features, and your code's performance could demand that such a
> short function must be inlined. One example of this is inlining
> functions containing asm blocks - IIRC DMD does not support this. The
> compiler should fail the build if it can't inline a function tagged with
> @forceinline, instead of shrugging it off and failing silently, forcing
> users to check the disassembly every time.
>
> You may have noticed that GCC has some ridiculously complicated
> assembler facilities. However, they also open the way to the
> possibilities of writing optimal code - for example, creating custom
> calling conventions, or inlining assembler functions without restricting
> the caller's register allocation with a predetermined calling
> convention. In contrast, DMD is very conservative when it comes to
> mixing D and assembler. One time I found that putting an asm block in a
> function turned what were single instructions into blocks of 6
> instructions each.
>
> D's lacking in this area makes it impossible to create language features
> that are on the level of D's compiler built-ins. For example, I have
> tested three memcpy implementations recently, but none of them could
> beat DMD's standard array slice copy (despite that in release mode it
> compiles to a simple memcpy call). Why? Because the overhead of using a
> custom memcpy routine negated its performance gains.
>
> This might have been alleviated with the presence of sane macros, but no
> such luck. String mixins are not the answer: trying to translate
> macro-heavy C code to D using string mixins is string escape hell, and
> we're back to the level of shell scripts.
>
> We've discussed this topic on IRC recently. From what I understood,
> Andrei thinks improvements in this area are not "impactful" enough,
> which I find worrisome.
>
> Personally, I don't think D qualifies as a true "system programming
> language" in light of the above. It's more of a compiled language with
> pointers and assembler. Before you disagree with any of the above, first
> (for starters) I'd like to invite you to translate Daniel Vik's C memcpy
> implementation to D:
> http://www.danielvik.com/2010/02/fast-memcpy-in-c.html . It doesn't even
> use inline assembler or compiler intrinsics.

+1. D needs a way to force inlining. The compiler can, at best, do heuristics. If D wants to cater to systems programmers -- that is, programmers who *know their shit* -- it needs advanced features like this. Same reason we have __gshared, for example.

- Alex
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11