Multilingual DDoc
I'm novice in D documentation system. I haven't done any comments in DDoc style but want to. My problem is that I want to share my library with community but in the same time I need to make it understandable for programmers in my team who speak Russian but not so good in English. For now I don't want to create documentation and then translate it because as I think it will take a lot of time. But writing doc comments in 2 languages would be a good idea for now. So my question is how it's about multilingual comments in DDoc? What I want is to be able to manage what language to use in doc generation (may be by compiler switch) or put secondary language under spoiler when rendering HTML format docs. Also what is about integration with translation services like Google Translate? Also I would be glad to get some info for getting started with DDoc.
Re: Multilingual DDoc
On Tuesday, 4 March 2014 at 08:21:27 UTC, Uranuz wrote: I'm novice in D documentation system. I haven't done any comments in DDoc style but want to. My problem is that I want to share my library with community but in the same time I need to make it understandable for programmers in my team who speak Russian but not so good in English. For now I don't want to create documentation and then translate it because as I think it will take a lot of time. But writing doc comments in 2 languages would be a good idea for now. So my question is how it's about multilingual comments in DDoc? What I want is to be able to manage what language to use in doc generation (may be by compiler switch) or put secondary language under spoiler when rendering HTML format docs. Also what is about integration with translation services like Google Translate? Also I would be glad to get some info for getting started with DDoc. You can accomplish something similar to this by using DDoc's existing macro system. /** * Some documentation in one language * $(TRANSLATION Some documentation in another language) * Macros: * TRANSLATION=span class=translation$0/span */
Re: adding static return?
On Monday, 3 March 2014 at 23:27:42 UTC, Xavier Bigand wrote: I thought it could be nice to have a static return. My Idea is to remove unnecessary bracket encapsulation made with some static if statements. It will works like this : module xxx.opengl; import buildSettings; // contains some global constants static if (renderMode == directX) return; ... So there will no more need to scope the module code and indent it. Is it a good idea? This is just to avoid brackets and the compulsion of indenting inside them, isn't it? ;-) Version blocks can be used with colons (see http://forum.dlang.org/thread/lep2p3$2765$1...@digitalmars.com for a caveat). May be this syntax could be extended to module-level static ifs. D would look more and more like Python...
Re: Issus with DMD 2.065
On Tuesday, 4 March 2014 at 00:41:09 UTC, Hertz wrote: Ever since I installed the latest DMD 2.065 I cant seem to compile and run .d files anymore. I'm installing dmd using the .deb file on Ubuntu. When it is installed and I try to compile a .d file the console gives me this. cannot find source code for runtime library file 'object.d' dmd might not be correctly installed. Any suggestions? Chances are dmd can't find a dmd.conf, or is reading the wrong one. See http://dlang.org/dmd-linux.html#dmd_conf
Re: Nobody understands templates?
On Monday, 3 March 2014 at 22:50:18 UTC, Frustrated wrote:
On Monday, 3 March 2014 at 18:46:24 UTC, Chris wrote:
I think the problem is not that people don't understand
templates in the sense that they are abstractions. The
question is whether there are loads and loads of use cases for
them.
It is irrelevant if there are loads and loads of use cases for
them. Just because people don't use something doesn't mean it
is useless.
Nobody ever said this.
to have to create a function every
This is a typical use case and always mentioned in tutorials.
The question is how many of these typical cases one
encounters while writing software.
Look at the STL library if you do't believe templates are
useful...
I think another problem with templates is that it is not
always clear what is abstracted. The type or the logic? Both?
In the above example the logic remains the same and is
reproduced by the compiler for each type. Sometimes the logic
can be abstracted for which type independence is important.
But I'm not sure if that can be called a template in the
purest sense. E.g. an algorithm that finds the first instance
of something might be different for each type (string, char,
int) and the abstract implementation has to differentiate
internally (if string else if int else if ...). But this
is no longer a template, or is it?
Both logic and types are abtracted. Even though the template
might use the same operator, the compiler must determine which
concrete operator to use.
The addition between the two abstract objects also requires an
abstract operator.
The great thing is, because the abstract logic is
identical(adding two things) makes the template actually
useful. If it wasn't we would have to specialize the template
for all the different possible binary combinations and then it
would defeat the simplification that abstract is suppose to
offer.
Purely philosophical remark: You're talking about the level of
how the compiler implements it. The logic (a+b) is not abstracted
but the same in every case. How the compiler has to deal with it
in every case is irrelevant for the concept of templates, because
it's the same as writing:
int add(int a, int b) { return a+b;}
int add(double a, double b) { return a+b;}
etc.
The the logical process is used when one looks at procedural
code and realizes that one can simplify it by using oop.
Templates give you the same power over oop that oop gives over
non-oop. But just because templates[oop] are available doesn't
mean you have to use it or it is always the best solution.
I use templates all the time. I create them to simplify some
task then put them in a library. For me, templates allow me to
streamline things that I couldn't otherwise do. Any time I feel
like something is being repeated a lot I automatically think
that a templates will help. I hate copying and pasting and so
I tend to use templates a lot.
I'm starting to do the same thing. But my experience (so far) has
been that abstraction goes only so far and a template only
covers, say, 2 cases instead of 4 and I have to write 2 separate
templates. Granted, in the old days, I would have written a class
that handles all four cases, so it saves me some coding. But in
may applications, templates are not really necessary. If you
write a program that deals with strings, most functions will take
a string as an input and return a string (or an array of strings)
as an output. This is at least my experience. If code is repeated
all over again, you put it into a separate
function/method/class/struct anyway. I find myself using ranges
quite a lot.
One of the main uses of templates is compile time type safety.
This is necessary with oop because oop allows one to create
types at compile time. Hence, the need to be able to make your
oop safe is a natural step and templates help you accomplish
that.
e.g., Array's of objects vs Array's of a Type. One is much
safer, informs the about what your intentions are so it can
make better informed decisions.
e.g., Array!Type allows the Array to determine if the Type
supports certain things at **compile time**. Array!Object can't
do this at compile time.
Yes, we have useful template constraints (isInputRange etc).
If you can't see the benefit of Array!Type vs Array!Object then
you are beyond help. (this is not to say Array!Object is always
useless, but it is the most generic you can get and the
compiler can do little to help the situation)
I'll give you a simple example: One could create an Array type
that allows one to traverse the array in a multitude of ways.
Suppose the objects stored by the arrays are arrays themselves.
If the Array is templated it could easily figure this out and
create an iterator that iterates over the sub-array(calling its
iterator).
This way one could easily display a flat list of the array [of
arrays [of arrays ...]]. Because the Array type could figure
out all this
Re: Nobody understands templates?
On Tue, Mar 04, 2014 at 10:32:52AM +, Chris wrote: [...] Maybe that's why it is so hard to see the benefits of templates, because many cases (of abstraction) are already covered by OOP. I like templates, but I'm not sure if they are as useful as D's ranges. Ranges and component programming handle the ubiquitous inputfilteroutput paradigm present in every program and help to break down the program's logic into digestible chunks, a logic you cannot just copy and paste (but you can reuse the chunks). In cases where you use templates, you can also get away with copy and paste and replace int with double. [...] Ranges in D will be nowhere as convenient as they are today without templates. When you write your own components, you basically have to use templates in order to not incur unacceptable overhead (or impose arbitrary limitations on usage -- such as requiring something to be derived from some chosen base class). T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte
Re: getTid wrapper
On Tuesday, 4 March 2014 at 15:52:37 UTC, Timothee Cour wrote:
quoting from there:
The type of thisTid is Tid, but its value has no significance
for the
program. Further, both threads report it to be surprisingly at
the same
address:
Owner : Tid(std.concurrency.MessageBox), address: 809C360
Worker: Tid(std.concurrency.MessageBox), address: 809C360
That part talks about thisTid, not Thread.getThis. Perhaps that
book section is indeed not clear enough. thisTid actually gets
an address of 'thisTid', which is (at least in current
implementation) a function.
Likewise with writeln(Thread.getThis);
Same as above. So you're printing function pointers, which are of
course the same for every thread.
How would I print a number/string that uniquely identifies a
thread?
Tid is an opaque type, writeln(thisTid) isn't of any use.
If you want to print it, you can do so like this:
writefln(%s, cast(void*)Thread.getThis);
That is, you cast a reference returned by Thread.getThis() to a
void* (a reference is a glorified pointer, after all). If you
want to print something more meaningful, you can utilize the
'name' property of Thread.
For simple identification purposes (i.e. when you want to check
if the calling thread is the one you need), both thisTid and
Thread.getThis can be used:
if (thisTid == expectedTid) { ... }
if (Thread.getThis is expectedThread) { ... }
If you don't feel like printing addresses or using name(), you
can even build your own id system, i.e. like this:
--8--
module threadid;
import core.atomic;
private shared uint lastID; // shared
private uint thisID;// TLS
static this() { thisID = atomicOp!+=(lastID, 1); }
@property uint threadID() { return thisID; }
--8--
...or something to that extent. Now every thread that you ever
create will get an ID number (from 0 to uint.max, be careful
though if your app creates more than uint.max threads :o) ),
which can be queried at any time:
import threadid;
//...
writeln(threadID);
Re: getTid wrapper
On 03/04/2014 08:27 AM, Stanislav Blinov wrote: Perhaps that book section is indeed not clear enough. thisTid actually gets an address of 'thisTid', which is (at least in current implementation) a function. Makes sense. I remember thisTid being a module-level variable at the time I wrote that section. Taking note of one more thing to change... :) Ali
Re: Nobody understands templates?
On Tuesday, 4 March 2014 at 15:52:37 UTC, H. S. Teoh wrote: On Tue, Mar 04, 2014 at 10:32:52AM +, Chris wrote: [...] Maybe that's why it is so hard to see the benefits of templates, because many cases (of abstraction) are already covered by OOP. I like templates, but I'm not sure if they are as useful as D's ranges. Ranges and component programming handle the ubiquitous inputfilteroutput paradigm present in every program and help to break down the program's logic into digestible chunks, a logic you cannot just copy and paste (but you can reuse the chunks). In cases where you use templates, you can also get away with copy and paste and replace int with double. [...] Ranges in D will be nowhere as convenient as they are today without templates. When you write your own components, you basically have to use templates in order to not incur unacceptable overhead (or impose arbitrary limitations on usage -- such as requiring something to be derived from some chosen base class). T True, true. The fact that the compiler can check for the right types is great. Btw, the quote you have in this post: Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-)
Re: getTid wrapper
On Tue, Mar 4, 2014 at 10:09 AM, Timothee Cour thelastmamm...@gmail.comwrote: Thanks, that works does it make sense to add a function to do that? as it stands there are 2 separate ways, cast(void*)Thread.getThis and cast(void*)getTid, so having a function would make it the preferred way. sorry that should be: cast(void*)Thread.getThis (works) thisTid doesn't seem useful for purpose of writing a unique identifier (and can't be cast to void*). So the question is whether we want a wrapper for cast(void*)Thread.getThis.
Re: Nobody understands templates?
On Tue, Mar 04, 2014 at 06:19:38PM +, Chris wrote: On Tuesday, 4 March 2014 at 15:52:37 UTC, H. S. Teoh wrote: On Tue, Mar 04, 2014 at 10:32:52AM +, Chris wrote: [...] Maybe that's why it is so hard to see the benefits of templates, because many cases (of abstraction) are already covered by OOP. I like templates, but I'm not sure if they are as useful as D's ranges. Ranges and component programming handle the ubiquitous inputfilteroutput paradigm present in every program and help to break down the program's logic into digestible chunks, a logic you cannot just copy and paste (but you can reuse the chunks). In cases where you use templates, you can also get away with copy and paste and replace int with double. [...] Ranges in D will be nowhere as convenient as they are today without templates. When you write your own components, you basically have to use templates in order to not incur unacceptable overhead (or impose arbitrary limitations on usage -- such as requiring something to be derived from some chosen base class). T True, true. The fact that the compiler can check for the right types is great. Btw, the quote you have in this post: Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-) I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything). T -- I am not young enough to know everything. -- Oscar Wilde
Re: Nobody understands templates?
On Tue, 2014-03-04 at 10:27 -0800, H. S. Teoh wrote: On Tue, Mar 04, 2014 at 06:19:38PM +, Chris wrote: […] True, true. The fact that the compiler can check for the right types is great. Btw, the quote you have in this post: Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-) I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything). I present you the following, which between then give a good account of the whole situation. Sort of. Possibly. http://en.wikipedia.org/wiki/Hanlon's_razor https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Hanlon_s_razor.html http://blog.writch.com/2009/04/hanlons-razor-which-i-knew-as-heinleins-razor.html -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Nobody understands templates?
On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote: I just discovered by trial and error that I could use 'mixin' in Templates (as opposed to Template Mixins), and when you know that it seems likely that you can accomplish lots of stuff you couldn't before. This was asked about recently. mixin template ... This is the correct way to declare a template to use in mixins, several of us are surprised that you can still mixin a template which wasn't declared in this manner. I've created a bug so an official statement can be made on it: https://d.puremagic.com/issues/show_bug.cgi?id=12298
Re: Nobody understands templates?
On Tue, Mar 04, 2014 at 07:23:49PM +, Jesse Phillips wrote: On Sunday, 2 March 2014 at 11:47:39 UTC, Steve Teale wrote: I just discovered by trial and error that I could use 'mixin' in Templates (as opposed to Template Mixins), and when you know that it seems likely that you can accomplish lots of stuff you couldn't before. This was asked about recently. mixin template ... This is the correct way to declare a template to use in mixins, several of us are surprised that you can still mixin a template which wasn't declared in this manner. I've created a bug so an official statement can be made on it: https://d.puremagic.com/issues/show_bug.cgi?id=12298 I'm pretty sure that's a bug, since TDPL clearly distinguishes between templates and mixin templates. But if this bug leads to interesting use case, maybe it's a case of an unintentional feature? :-P T -- Knowledge is that area of ignorance that we arrange and classify. -- Ambrose Bierce
Re: Nobody understands templates?
On Tuesday, 4 March 2014 at 19:18:28 UTC, Russel Winder wrote: On Tue, 2014-03-04 at 10:27 -0800, H. S. Teoh wrote: On Tue, Mar 04, 2014 at 06:19:38PM +, Chris wrote: […] True, true. The fact that the compiler can check for the right types is great. Btw, the quote you have in this post: Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-) I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything). I present you the following, which between then give a good account of the whole situation. Sort of. Possibly. http://en.wikipedia.org/wiki/Hanlon's_razor https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Hanlon_s_razor.html http://blog.writch.com/2009/04/hanlons-razor-which-i-knew-as-heinleins-razor.html This reminds me of Cipolla's laws of human stupidity. Put this into your search engine: Basic Laws of Human Stupidity, Carlo M. Cipolla Also: https://en.wikipedia.org/wiki/Carlo_M._Cipolla Enjoy!
Re: Nobody understands templates?
On Tue, Mar 04, 2014 at 07:18:17PM +, Russel Winder wrote: On Tue, 2014-03-04 at 10:27 -0800, H. S. Teoh wrote: On Tue, Mar 04, 2014 at 06:19:38PM +, Chris wrote: [...] Btw, the quote you have in this post: Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-) I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything). I present you the following, which between then give a good account of the whole situation. Sort of. Possibly. http://en.wikipedia.org/wiki/Hanlon's_razor https://www.princeton.edu/~achaney/tmve/wiki100k/docs/Hanlon_s_razor.html http://blog.writch.com/2009/04/hanlons-razor-which-i-knew-as-heinleins-razor.html [...] Whoa. So this is one of those things that nobody knows for sure where it came from? :) My new favorite version of it is (allegedly) Elbert Hubbard's: Genius may have its limitations, but stupidity is not thus handicapped. That's going into my quotes file... :) T -- People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG
Re: Mutexes and locking
For what it's worth, you can also do:
auto m = new Mutex;
sycnchronized (m) {
// do stuff
}
The synchronized block will call lock on enter and unlock on
exit, even as a result of a throw.
Re: Nobody understands templates?
On Friday, 28 February 2014 at 18:42:57 UTC, Steve Teale wrote: All the D aficionados seem to wet their pants over meta-programming, but I struggle to find a place to use it. IIRC, I used it in a couple of places when I was trying to write library stuff for MySQL, but in my current project, I use it only once. That's when I want to stuff something onto my undo stack. For that I have two template functions - push(T)(MybaseClass* p, T t, int ID), and pushC, which is just the same except that it checks the top of the stack to see if the ID there is the same as what it is wanting to push. This has served me very reliably, but I struggle to find other places in the whole application where I would benefit from templates. Is this typical - libraries use templates, applications don't, or am I just being unimaginative? This is certainly my experience with C++ and is why I wrote the chapter on templates in the Tango with D book. Personally though, I use templates constantly. For functions, the most common case is to eliminate code duplication where I might normally overload for different parameter types.
ctor for shared and immutable structs
why this code get errors?
[code]
/* 1 */struct PData
/* 2 */{
/* 3 */immutable(ubyte)[] data; // ???
/* 4 */pure this(T)( in T val ) { }
/* 5 */}
/* 6 */
/* 7 */unittest
/* 8 */{
/* 9 */immutable(ubyte)[] data_a = [1,2,3];
/* 10 */ubyte[] data_b = [1,2,3];
/* 11 */auto a = PData( data_a );
/* 12 */auto ca = const PData( data_a );
/* 13 */auto ia = immutable PData( data_a );
/* 14 */auto sa = shared PData( data_a );
/* 15 */auto sca = shared const PData( data_a );
/* 16 */
/* 17 */auto b = PData( data_b.idup );
/* 18 */auto cb = const PData( data_b.idup );
/* 19 */auto ib = immutable PData( data_b );
/* 20 */auto sb = shared PData( data_b );
/* 21 */auto scb = shared const PData( data_b );
/* 22 */}
[/code]
$ dmd -unittest -main -run purector.d
purector.d(13): Error: template purector.PData.__ctor cannot
deduce function from argument types !()(immutable(ubyte)[])
immutable, candidates are:
purector.d(4):purector.PData.__ctor(T)(in T val)
purector.d(14): Error: template purector.PData.__ctor cannot
deduce function from argument types !()(immutable(ubyte)[])
shared, candidates are:
purector.d(4):purector.PData.__ctor(T)(in T val)
purector.d(15): Error: template purector.PData.__ctor cannot
deduce function from argument types !()(immutable(ubyte)[])
shared const, candidates are:
purector.d(4):purector.PData.__ctor(T)(in T val)
why cannot deduce pure ctor?
if i change line 3
/* 3 */immutable(ubyte)[] data; // ???
to
/* 3 */ubyte[] data; // ???
all works
why i can't use immutable data in this case?
Re: Nobody understands templates?
On 3/1/2014 1:00 PM, Steve Teale wrote: I have already dealt with the yada-yada cases by old-fashioned OOP. As I see it, a big part of the benefit of templates is that they can help you avoid a lot of the downsides of OOP: - OO Boilerplate. - Multiple dispatch is ridiculously messy, having to resort to contortions like the visitor pattern. - Upcasting looses compile-time type info. - Decreased opportunity for compiler optimizations, because a single function handles multiple data types at runtime. So the optimizer can't generate optimal code for all the data types used. - Extra indirections at runtime. - Downcasting has a runtime cost. - Poor cache behavior. - Tendency for increased heap activity, which is not cheap at all. - Lumping all data/functionality for a single object instance into the same physical chunk of memory causes problems for parallelization. And that's increasingly problematic on modern processors which work best when operating as streaming-data processors. (See Entity/Component Systems[1] - There are good reasons videogame development has mostly switched from OOP to entity/component systems.) Basically, while OOP certainly has benefits, it also has notable flaws that inherently slow down both the programmer and the computer. JVM goes to an enormous amount of trouble to mitigate that natural tendency, but it still has limits. And most languages (like D) can't expect to approach JVM's work on de-slow-ifying OO. The runtime performance issues of OO aren't *always* a problem, but they can easily kill inner-loop/performance-sensitive sections of code. So with OO, you have to give up the generic/polymorphic benefits for any critical sections. Metaprogramming lets you still be generic even in the critical sections. This is demonstrated in sections #1-4 of an article I wrote a little while back[2]. It's a very contrived example, but even I was still surprised just *how* badly the OO version performed. There's also this template primer[3] which might help, but I'm guessing it may be below your ability level. [1] Entity/Component Systems: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ [2] http://www.semitwist.com/articles/EfficientAndFlexible/MultiplePages/Page1/ [3] https://semitwist.com/articles/article/view/template-primer-in-d
Re: Nobody understands templates?
Nick Sabalausky: - Lumping all data/functionality for a single object instance into the same physical chunk of memory causes problems for parallelization. And that's increasingly problematic on modern processors which work best when operating as streaming-data processors. (See Entity/Component Systems[1] - There are good reasons videogame development has mostly switched from OOP to entity/component systems.) Sometimes OOP is handy, for GUIs and other situations, but if today a more horizontal placement of fields is more efficient when high performance is needed, then perhaps a creative programmer has to find the courage to step out of his/her/hir language constraints to invent a better language. Is it possible to invent a language more fit for this different kind of data layout? Bye, bearophile
Re: Nobody understands templates?
On 3/4/2014 7:42 PM, bearophile wrote: Nick Sabalausky: - Lumping all data/functionality for a single object instance into the same physical chunk of memory causes problems for parallelization. And that's increasingly problematic on modern processors which work best when operating as streaming-data processors. (See Entity/Component Systems[1] - There are good reasons videogame development has mostly switched from OOP to entity/component systems.) Sometimes OOP is handy, for GUIs and other situations, but if today a more horizontal placement of fields is more efficient when high performance is needed, then perhaps a creative programmer has to find the courage to step out of his/her/hir language constraints to invent a better language. Is it possible to invent a language more fit for this different kind of data layout? I don't think it's necessary to go as far as creating a new language. An entity-system in a low-level-capable language gives you enough power to control layouts however appropriate, and using them is pretty easy. It seems intimidating at first, but it's really just like a relational DB: You have a unique ident for each object (ie, what an OO system would call an instantiated object, but in this case called an entity). And then all the data associated with the object/entity is stored in various tables/structs/whatever (in this case, called components) with the entity's unique identifier being the primary key for each table/component. Functionality operates on a particular table/component, or a set of specific tables/components, either on a row-at-a-time basis or as the whole table as an aggregate. Note that this imposes very little, if any, requirements on in-memory layouts, so things can be laid out however desired - possibly even with per-platform topologies thanks to the magic of metaprogramming. In any case, metaprogramming can help abstract away many of the internal memory-layout details. Playing around with the Unity3D editor, and it's tutorial videos, can help grok the usage and modeling power of entities (like any good modern game engine, it uses an entity-based design). Although, FWIW, I'm not convinced Unity3D's design is able to *fully* take advantage of all the potential performance benefits of an entity system (mostly because of its CLR-based scripting and black-box closed-source engine). But, I admit, I have wondered if a language could aid the creation/usage of entity systems with some special language features.
Re: Nobody understands templates?
Nick Sabalausky: But, I admit, I have wondered if a language could aid the creation/usage of entity systems with some special language features. I have seen that a good way to learn lazyness and purity is to try to write some Haskell code. Then you can use the same ideas in other languages, like D. Similarly I've studied regular expressions in dynamic languages, and now I am able to use them in Java, C#, D, etc. So I've seen that it's good to learn a feature/style in a language that uses it a lot, or even in a language designed around such feature. Because languages shape your mind, and specialized languages train your mind to use few specific features. Later in real-world situations often you can't use such specialized/esoteric/rare language, and you have to use a common language as Java. And sometimes if people use a feature a lot in other languages, eventually it gets ported even to the common languages (like lambdas in Java). So even if you can't or you don't want to use a new language to use entity systems, training your mind a bit thinking in a new language designed for it could help use it in a common language, or could even suggest you few features to add to a more general purpose language as D. Wouter van Oortmerssen shows very well that designing many small specialized languages helps you sharpen your mind and later you apply those ideas to more general situations: http://strlen.com/language-design-overview Bye, bearophile
Re: Nobody understands templates?
On 3/3/2014 5:35 PM, Chris wrote:
Maybe I'm a bit too philosophical about this. But consider the following
(made up) case:
struct MyTemp(T) {
// ...
T add(T a, T b) {
if (a is string b is string) {
return a~b; // or return a~+~b; or whatever
} else if (a is integer a is integer) {
return a+b;
}
}
}
I don't know if this can be considered a pure template. It is a
template of sorts, but the type specialization in the function add makes
it a watered-down template,
Any useful template function already works that way. The mere + operator
is *not* one single operation, but a whole category of opcodes which are
chosen based on the operand's type. Thus, + can be thought of as a
built-in template that [roughly] does this:
T opPlus(T a, T b) {
if (T is integer) {
[asm opcode for 32-bit addition] a, b
} else if (T is ubyte) {
[asm opcode for 8-bit addition] a, b
} else if (T is float) {
[asm opcode for floating point addition] a, b
}
}
Specialization is what makes function templates useful. Some of the
specialization is explicit (static if) and some is implicit (+
operator). But without specialization (explicit or implicit), all
instantiations would be identical. If all instantiations are identical,
why even have a template in the first place?
Re: Nobody understands templates?
On 3/4/2014 1:27 PM, H. S. Teoh wrote: On Tue, Mar 04, 2014 at 06:19:38PM +, Chris wrote: Btw, the quote you have in this post: Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte I'm surprised that Napoleon would say something like this. Malice is often a characteristic of the incompetent. The only way to get the better of their betters. :-) I'm not sure if that attribution is accurate. Nick has pointed out to me that he knows the same quote attributed to someone else, so this may be a case of internet misattribution (I picked up that quote from somewhere online, way back when -- no idea if the source was reliable, y'know, being the internet and everything). Hanlon's Razor, a tongue-in-cheek corollary (of sorts) to Occam's Razor. I'm a huge believer in Hanlon's Razor, BTW, as well as Occam's Razor which I see as an axiom (for a loose definition of axiom) that's fundamental in making all of science actually work and separating science from folklore. For all I know, Napoleon may have uttered Hanlon's Razor at some point. I'm sure he's said a lot of things :) If so, he may have been the first.
Re: Nobody understands templates?
On 3/4/2014 9:00 PM, bearophile wrote: Nick Sabalausky: But, I admit, I have wondered if a language could aid the creation/usage of entity systems with some special language features. I have seen that a good way to learn lazyness and purity is to try to write some Haskell code. Then you can use the same ideas in other languages, like D. Similarly I've studied regular expressions in dynamic languages, and now I am able to use them in Java, C#, D, etc. So I've seen that it's good to learn a feature/style in a language that uses it a lot, or even in a language designed around such feature. Because languages shape your mind, and specialized languages train your mind to use few specific features. Later in real-world situations often you can't use such specialized/esoteric/rare language, and you have to use a common language as Java. And sometimes if people use a feature a lot in other languages, eventually it gets ported even to the common languages (like lambdas in Java). So even if you can't or you don't want to use a new language to use entity systems, training your mind a bit thinking in a new language designed for it could help use it in a common language, or could even suggest you few features to add to a more general purpose language as D. Wouter van Oortmerssen shows very well that designing many small specialized languages helps you sharpen your mind and later you apply those ideas to more general situations: http://strlen.com/language-design-overview Yea, all good points. I'm reminded of one of my favorite quotes from Joel Spolsky: I have never met anyone who can do Scheme, Haskell, and C pointers who can't pick up Java in two days, and create better Java code than people with five years of experience in Java, but try explaining that to the average HR drone. - http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
