www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++, D: Dinosaurs?

reply "Tony" <tonytech08 gmail.com> writes:
Someone has to ask the obvious question! (The question is in the subject of 
this post).

Tony
Oct 31 2008
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Tony wrote:

 Someone has to ask the obvious question! (The question is in the subject of 
 this post).
 
 Tony 


Well, someone has to give the obvious answer:

42


Andrei
Oct 31 2008
parent Uriel <uriel inbox.ru> writes:
Andrei Alexandrescu Wrote:


 Tony wrote:

 Someone has to ask the obvious question! (The question is in the subject of 
 this post).
 
 Tony 


 
 Well, someone has to give the obvious answer:
 
 42
 
 
 Andrei


Captain Obvious to the rescue!
Oct 31 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Tony" <tonytech08 gmail.com> wrote in message 
news:gegh9e$1q4i$1 digitalmars.com...

 Someone has to ask the obvious question! (The question is in the subject 
 of this post).

 Tony


I've considered C++ a dinosaur for years. For many obvious reasons. But not 
D. I consider D to be the one modern language with the least tendancy 
towards stupid (but popular) design decisions.
Oct 31 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:

 I've considered C++ a dinosaur for years. For many obvious reasons. But not 
 D. I consider D to be the one modern language with the least tendancy 
 towards stupid (but popular) design decisions. 



Yeah, but you guys give me grief for making unpopular decisions <g>.
Oct 31 2008
next sibling parent Mike James <foo bar.com> writes:
Walter Bright Wrote:


 
 Yeah, but you guys give me grief for making unpopular decisions <g>.



"The reasonable man adapts himself to the conditions that surround him... The
unreasonable man adapts surrounding conditions to himself... All progress
depends on the unreasonable man." George Bernard Shaw.


-=mike=-
Nov 01 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote

 Nick Sabalausky wrote:

 I've considered C++ a dinosaur for years. For many obvious reasons. But 
 not D. I consider D to be the one modern language with the least tendancy 
 towards stupid (but popular) design decisions.



 Yeah, but you guys give me grief for making unpopular decisions <g>.


You are reasonable for the most part ;)  You have made a lot of popular 
decisions too.

And some of your unpopular ones are good too.

-Steve
Nov 01 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:

 And some of your unpopular ones are good too.


The decision to move forward with the immutable/const system was 
unpopular, but I am strongly convinced that design will be vindicated.
Nov 01 2008
prev sibling next sibling parent reply Clay Smith <clayasaurus gmail.com> writes:
Tony wrote:

 Someone has to ask the obvious question! (The question is in the subject of 
 this post).
 
 Tony 
 
 


Technically, I'd consider C++ to be undead. Old, ugly, its zombie 
rotting flesh never seems to die. It lives by eating the brains of C 
programmers.

~ Clay
Nov 01 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Clay Smith" <clayasaurus gmail.com> wrote in message 
news:gej5nr$13jd$1 digitalmars.com...

 Tony wrote:

 Someone has to ask the obvious question! (The question is in the subject 
 of this post).

 Tony


 Technically, I'd consider C++ to be undead. Old, ugly, its zombie rotting 
 flesh never seems to die. It lives by eating the brains of C programmers.

 ~ Clay


Funny you mention that, the analogies I normally think of for C++ are either 
a 120+ year-old on life support or, as you said, the living dead. It's long 
past it's time, but people just won't let it finally rest (probably because, 
aside from D, there's no modern language that's a suitable replacement for 

replacements. They can handle many of C++'s uses, but not all.)
Nov 02 2008
parent reply "Tony" <tonytech08 gmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gel5tu$1a1v$1 digitalmars.com...

 "Clay Smith" <clayasaurus gmail.com> wrote in message 
 news:gej5nr$13jd$1 digitalmars.com...

 Tony wrote:

 Someone has to ask the obvious question! (The question is in the subject 
 of this post).

 Tony


 Technically, I'd consider C++ to be undead. Old, ugly, its zombie rotting 
 flesh never seems to die. It lives by eating the brains of C programmers.

 ~ Clay


 Funny you mention that, the analogies I normally think of for C++ are 
 either a 120+ year-old on life support or, as you said, the living dead. 
 It's long past it's time, but people just won't let it finally rest 
 (probably because, aside from D, there's no modern language that's a 

 instance, are only partial replacements. They can handle many of C++'s 
 uses, but not all.)


The "in *all* of C++'s use-cases" part is probably the way to create a 
dinosaur (call it E, F or G or whatever). The concept of "general purpose 
language" is getting a bit long-toothed?

Tony
Nov 03 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Tony" <tonytech08 gmail.com> wrote in message 
news:genht8$2fcg$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gel5tu$1a1v$1 digitalmars.com...

 "Clay Smith" <clayasaurus gmail.com> wrote in message 
 news:gej5nr$13jd$1 digitalmars.com...

 Tony wrote:

 Someone has to ask the obvious question! (The question is in the 
 subject of this post).

 Tony


 Technically, I'd consider C++ to be undead. Old, ugly, its zombie 
 rotting flesh never seems to die. It lives by eating the brains of C 
 programmers.

 ~ Clay


 Funny you mention that, the analogies I normally think of for C++ are 
 either a 120+ year-old on life support or, as you said, the living dead. 
 It's long past it's time, but people just won't let it finally rest 
 (probably because, aside from D, there's no modern language that's a 

 for instance, are only partial replacements. They can handle many of 
 C++'s uses, but not all.)


 The "in *all* of C++'s use-cases" part is probably the way to create a 
 dinosaur (call it E, F or G or whatever). The concept of "general purpose 
 language" is getting a bit long-toothed?

 Tony


I strongly disagree. The concept of domain-specific languages is 
ultra-trendy these days (probably promoted by the same knuckleheads that 
hailed things like pure-OO, pure-functional, and Extreme Programming as 
silver bullets). But I consider domain-specific languages to be purely a 
symptom of a strong need for a better general purpose language.

Let's face it: programming needs and uses have expanded so much over the 
last decade or so that C/C++ hasn't really been a "general purpose" language 
for quite some time. These days it's a systems/performance language instead. 
True, all the attempts at retrofitting it with modern-ish features to try to 
keep it general-purpose have turned it into a regular frankenstein's monster 
of a language, but that does nothing to disprove the viability of general 
purpose languages in general. It just demonstrates that C++ needs a reboot 
(hence: D). Heck, D is already far better as a general-purpose language than 
C/C++ (although it's still not quite there yet).

I'd *much* rather use a true general-purpose language (which, again, C++ is 
no longer an example of) than muck around with 500 different languages for 
every stupid little thing.

For example, have you ever tried doing web development? You can't 
realistically do anything nontrivial without tripping over at least handful 
of different, essentially domain-specific, languages: ECMAScript, (T)SQL, 

And that's just the bare minimum for any non-trivial web site. For one 
thing, most of those are great examples of the fact that domain-specific 
languages do nothing to prevent piss-poor language design. But besides that: 
Conceptually, web development is one of the most trivial forms of 
programming out there. But the domain-specific language-soup realities of it 
have turned what should have been trivial into one of the programming 
world's biggest pains-in-the-ass. It's an absolute mess. I'm currently 
writing my first compiler, and I have in the past written homebrew for the 
Atari VCS, and an Asm sound driver for a multiprocessing 
microcontroller/embedded-device that has no sound hardware other than a 
generic DAC capability. All of those have proven to be far less 
pains-in-the-ass than any of my web development work. Considering the 
conceptual simplicity of the web, that's just absolutely pathetic.
Nov 03 2008
next sibling parent reply "Tony" <tonytech08 gmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:genrqm$1h4$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:genht8$2fcg$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gel5tu$1a1v$1 digitalmars.com...

 "Clay Smith" <clayasaurus gmail.com> wrote in message 
 news:gej5nr$13jd$1 digitalmars.com...

 Tony wrote:

 Someone has to ask the obvious question! (The question is in the 
 subject of this post).

 Tony


 Technically, I'd consider C++ to be undead. Old, ugly, its zombie 
 rotting flesh never seems to die. It lives by eating the brains of C 
 programmers.

 ~ Clay


 Funny you mention that, the analogies I normally think of for C++ are 
 either a 120+ year-old on life support or, as you said, the living dead. 
 It's long past it's time, but people just won't let it finally rest 
 (probably because, aside from D, there's no modern language that's a 

 for instance, are only partial replacements. They can handle many of 
 C++'s uses, but not all.)


 The "in *all* of C++'s use-cases" part is probably the way to create a 
 dinosaur (call it E, F or G or whatever). The concept of "general purpose 
 language" is getting a bit long-toothed?

 Tony


 I strongly disagree. The concept of domain-specific languages is 
 ultra-trendy these days (probably promoted by the same knuckleheads that 
 hailed things like pure-OO, pure-functional, and Extreme Programming as 
 silver bullets).



 But I consider domain-specific languages to be purely a symptom of a 
 strong need for a better general purpose language.


Probably. But to further on that, I would say that languages like C++ and D 
ARE the specialized ("domain specific") languages rather then the "general 
purpose" ones. Consider them as "where/when you need high level assembly 
language type of tool". Everyone who invents "the better C++" ends up in the 
same category as that overly complex, for a GP language, language.


 Let's face it: programming needs and uses have expanded so much over the 
 last decade or so that C/C++ hasn't really been a "general purpose" 
 language for quite some time.


"General Purpose Language" may indeed be an oxymoron. (All kinds of jokes 
noting 'GPL', omitted).


 These days it's a systems/performance language instead.


And not a very influential one at that, which really bogs down development.


 True, all the attempts at retrofitting it with modern-ish features to try 
 to keep it general-purpose have turned it into a regular frankenstein's 
 monster of a language, but that does nothing to disprove the viability of 
 general purpose languages in general.


If you define "general purpose" like C++ does, then that's exactly what you 
will get: something trying to be all things to all people, which never works 
well.


 It just demonstrates that C++ needs a reboot (hence: D). Heck, D is 
 already far better as a general-purpose language than C/C++ (although it's 
 still not quite there yet).


Note that I put them in the same grouping, so you know where I stand with D. 
I mean, it's fine for those who like cosmic OO hiearchy in the 
implementation and also like GC (one HAS to use GC with D, right?). I have 
my own memory management architecture so I don't want to be forced to use 
something else.


 I'd *much* rather use a true general-purpose language (which, again, C++ 
 is no longer an example of) than muck around with 500 different languages 
 for every stupid little thing.


Now you're being typically extremist. There is continuum from 1 to 500. 
Obviously then the task becomes deciding where to draw the lines.


 For example, have you ever tried doing web development? You can't 
 realistically do anything nontrivial without tripping over at least 
 handful of different, essentially domain-specific, languages: ECMAScript, 

 Python or Ruby.


I wouldn't do it that way. A lot of the difficulty is trying to get content 
specification and delivery technologies to work like a real program. You 
have specified a bunch of high level tools (not all nor most are languages 
in the sense of C, D etc BTW) and therefore made the development complex 
just by the sheer number of tools and therefore knowledge needed. If you 
think you need all that just because your website hosting provider supports 
those, maybe it's time to self-host and code up what you want with a small 
subset of tools: whatever you want to create the content, an embedded 
database, maybe ISAPI on Windows. Depending on how dynamic (read "program 
like") the website needs to be may cause some headaches because there is no 
good solution for that because the web was not designed to do that.


 And that's just the bare minimum for any non-trivial web site.


Not necessary at all.


 For one thing, most of those are great examples of the fact that 
 domain-specific languages do nothing to prevent piss-poor language design.


I too don't want to use more languages than necessary (read: one). I want 
good libraries with a good "GPL" to handle most things. If you relegate the 
"domain specific" moniker to only such high level and disparate technologies 
that you mentioned, well, those are the things I avoid or want to avoid.


 But besides that: Conceptually, web development is one of the most trivial 
 forms of programming out there. But the domain-specific language-soup 
 realities of it have turned what should have been trivial into one of the 
 programming world's biggest pains-in-the-ass. It's an absolute mess.


It's not that bad unless you are forced to program to your host's interfaces 
that they must maintain to control what one can do on a machine from a 
security point of view. If you are self-hosting, there are no such limits: 
you write the code and trust it to do what you want it to.


 I'm currently writing my first compiler, and I have in the past written 
 homebrew for the Atari VCS, and an Asm sound driver for a multiprocessing 
 microcontroller/embedded-device that has no sound hardware other than a 
 generic DAC capability. All of those have proven to be far less 
 pains-in-the-ass than any of my web development work. Considering the 
 conceptual simplicity of the web, that's just absolutely pathetic.


Trying to make an elephant jump through a hoop is difficult, yes.

Tony
Nov 03 2008
next sibling parent reply Piotrek <starpit tlen.pl> writes:
Tony wrote:


 [...] I would say that languages like C++ and D 
 ARE the specialized ("domain specific") languages rather then the "general 
 purpose" ones. Consider them as "where/when you need high level assembly 
 language type of tool". Everyone who invents "the better C++" ends up in the 
 same category as that overly complex, for a GP language, language.


I also see a GP language strictly connected with processors way of 
"thinking" and operating  with memory but with ability of switching to 
higher level (on demand) to ovoid using tons of primitives. If well 
deigned it can utilize computer to *everything* you need - without 
pain-in-ass.

Or one may say:


 "General Purpose Language" may indeed be an oxymoron. (All kinds of jokes 
 noting 'GPL', omitted).


IMHO D is a better stage of what we can call: general propose language.


 (C++) These days it's a systems/performance language instead.


 
 And not a very influential one at that, which really bogs down development.
 


Until D. Give me example of a language where you can develop 
faster/esier (besides IDE infrastructure).

Cheers
Nov 03 2008
parent reply "Tony" <tonytech08 gmail.com> writes:
"Piotrek" <starpit tlen.pl> wrote in message 
news:geo2vt$s62$1 digitalmars.com...

 Tony wrote:


 [...] I would say that languages like C++ and D ARE the specialized 
 ("domain specific") languages rather then the "general purpose" ones. 
 Consider them as "where/when you need high level assembly language type 
 of tool". Everyone who invents "the better C++" ends up in the same 
 category as that overly complex, for a GP language, language.


 I also see a GP language strictly connected with processors way of 
 "thinking" and operating  with memory but with ability of switching to 
 higher level (on demand) to ovoid using tons of primitives. If well 
 deigned it can utilize computer to *everything* you need - without 
 pain-in-ass.

 Or one may say:


 "General Purpose Language" may indeed be an oxymoron. (All kinds of jokes 
 noting 'GPL', omitted).


 IMHO D is a better stage of what we can call: general propose language.


Maybe. But more probably, "general purpose language" needs to be defined 
directly because it is so subjective in context. (hehe, isn't that a 
criticism of C++: non-contenxt free grammar?).


 (C++) These days it's a systems/performance language instead.


 And not a very influential one at that, which really bogs down 
 development.


 Until D. Give me example of a language where you can develop faster/esier 
 (besides IDE infrastructure).


I envision a language existing "in between" the characteristics of C++ and D 
(kind of). The object models both need work in C++ and D, IMO and if I am 
forced to use GC in D, then it's a no for me because I have my own memory 
management architecture. I can "shoe horn" C++ to behave, at least, with the 
object model and the memory is unconstrained, and I do consider the latter a 
main important feature.

Tony
Nov 03 2008
parent Piotrek <starpit tlen.pl> writes:
Tony wrote:



[...] But more probably, "general purpose language" needs to be defined 
 directly because it is so subjective in context. (hehe, isn't that a 
 criticism of C++: non-contenxt free grammar?).
 


Wikipedia says: "Context-sensitive grammars are more general than 
context-free grammars but still orderly enough to be parsed by a linear 
bounded automaton.". Whether this sentence is true or not, our way of 
thinking is context-sensitive which ironically makes things simpler 
(more info with less steps to carry out).



 I envision a language existing "in between" the characteristics of C++ and D 
 (kind of). The object models both need work in C++ and D, IMO and if I am 
 forced to use GC in D, then it's a no for me because I have my own memory 
 management architecture. I can "shoe horn" C++ to behave, at least, with the 
 object model and the memory is unconstrained, and I do consider the latter a 
 main important feature.


Robert and Nick have explained that. Only I must update my sentence 
where I was speaking about higher level on demand. Actually it's more 
likely  that D gives lower level on demand (and it's more natural IMHO).

Cheers
Nov 04 2008
prev sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Tony wrote:

 (one HAS to use GC with D, right?)


No. Well, the compiler generates calls to allocate & free memory, but 
you can replace those calls with whatever you want. See Tango's 
(druntime's) "stub" GC, which just reroutes compiler-generated calls to 
GC methods to malloc() and free(). You can implement your own "GC" or 
whatever management scheme you want (in fact, if you're writing, say, a 
device driver in D, you would want to use a custom allocator like this 
and not the built-in GC).
Nov 03 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but you 
 can replace those calls with whatever you want. See Tango's (druntime's) 
 "stub" GC, which just reroutes compiler-generated calls to GC methods to 
 malloc() and free(). You can implement your own "GC" or whatever 
 management scheme you want (in fact, if you're writing, say, a device 
 driver in D, you would want to use a custom allocator like this and not 
 the built-in GC).


Plus, D allows classes to have custom allocators and deallocators which can 
help when using either a non-GC approach or mix-and-match.

I would like to see a less hacky way to rip out the GC, but that's a rather 
low priority as current way is still perfectly workable.
Nov 03 2008
prev sibling parent reply "Tony" <tonytech08 gmail.com> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but you 
 can replace those calls with whatever you want. See Tango's (druntime's) 
 "stub" GC, which just reroutes compiler-generated calls to GC methods to 
 malloc() and free(). You can implement your own "GC" or whatever 
 management scheme you want (in fact, if you're writing, say, a device 
 driver in D, you would want to use a custom allocator like this and not 
 the built-in GC).


Please clarify for me the mem mgmt of D: is the garbage collector optional 
or not? Just allowing me to replace "getmorecore()" or something like that 
and then having the collector on top of that is unacceptable to me. I think 
you may be saying that dynamic memory is in every program, which again is 
not acceptable to me.

Really, memory control is a key issue when choosing a language for me 
anyway. I require that level of closeness to the hardware. Anything less is 
too 4GL-like for me.

Tony
Nov 03 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Tony wrote:

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but you 
 can replace those calls with whatever you want. See Tango's (druntime's) 
 "stub" GC, which just reroutes compiler-generated calls to GC methods to 
 malloc() and free(). You can implement your own "GC" or whatever 
 management scheme you want (in fact, if you're writing, say, a device 
 driver in D, you would want to use a custom allocator like this and not 
 the built-in GC).


 
 Please clarify for me the mem mgmt of D: is the garbage collector optional 
 or not? Just allowing me to replace "getmorecore()" or something like that 
 and then having the collector on top of that is unacceptable to me. I think 
 you may be saying that dynamic memory is in every program, which again is 
 not acceptable to me.
 
 Really, memory control is a key issue when choosing a language for me 
 anyway. I require that level of closeness to the hardware. Anything less is 
 too 4GL-like for me.
 
 Tony 


Whenever memory is allocated (i.e. "new", AA use, append to a dynamic 
array), the compiler generates a call to a GC function. You can replace 
this with your own allocator. In other words, YES -- you can remove the 
_entire_ GC and replace it with your own allocation scheme, but you must 
be careful not to use AAs or the ~ (or ~=) operator carelessly, since 
these depend on the allocator. In D2, you need to worry about closures, too.
Nov 04 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Tony" <tonytech08 gmail.com> wrote in message 
news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but you 
 can replace those calls with whatever you want. See Tango's (druntime's) 
 "stub" GC, which just reroutes compiler-generated calls to GC methods to 
 malloc() and free(). You can implement your own "GC" or whatever 
 management scheme you want (in fact, if you're writing, say, a device 
 driver in D, you would want to use a custom allocator like this and not 
 the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector optional 
 or not?


Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but it's 
perfectly doable. I did it a few years ago when I was playing around with 
using GDC with DevKitARM for GBA.

IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" in 
the internal portion of phobos/tango/druntime or wherever it lives now and 
comment-out the calls to "gc_init()" and "gc_term()". You might also need to 
call "gc.disable()" or something (don't really remember). And then if you 
still want to use "new" and/or "delete" with your own memory manager, you 
can use D's class allocator and deallocator feature 
(http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you could 
probably plug those class allocators/deallocators directly into the internal 
object class if you wanted.
Nov 04 2008
next sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" in 
 the internal portion of phobos/tango/druntime or wherever it lives now and 
 comment-out the calls to "gc_init()" and "gc_term()". You might also need to 
 call "gc.disable()" or something (don't really remember). And then if you 
 still want to use "new" and/or "delete" with your own memory manager, you 
 can use D's class allocator and deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you could 
 probably plug those class allocators/deallocators directly into the internal 
 object class if you wanted. 


That would work in all cases and be the only way if using D1+Phobos, but 
for Tango or D2/druntime, the better way would be 
http://www.dsource.org/projects/tango/browser/trunk/lib/gc/stub . The 
way you described would still link in the old GC and possibly generate 
erroneous calls to it.
Nov 04 2008
prev sibling parent reply "Tony" <tonytech08 gmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but 
 you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls to 
 GC methods to malloc() and free(). You can implement your own "GC" or 
 whatever management scheme you want (in fact, if you're writing, say, a 
 device driver in D, you would want to use a custom allocator like this 
 and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but 
 it's perfectly doable. I did it a few years ago when I was playing around 
 with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" in 
 the internal portion of phobos/tango/druntime or wherever it lives now and 
 comment-out the calls to "gc_init()" and "gc_term()". You might also need 
 to call "gc.disable()" or something (don't really remember). And then if 
 you still want to use "new" and/or "delete" with your own memory manager, 
 you can use D's class allocator and deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into the 
 internal object class if you wanted.


It sounds like a lot of work and new stuff to learn about the 
implementation. Let's face it, I'm not going to use D since it doesn't offer 
me anything over C++ that I want. The main thing I may like about D is that 
it makes the effort to make implementation of the language easier, and that, 
I think, is very key. I am here to look for features I would put in a new 
language, though that may be too large of an endeavor for someone my age.

Tony
Nov 04 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Tony" <tonytech08 gmail.com> wrote in message 
news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but 
 you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls to 
 GC methods to malloc() and free(). You can implement your own "GC" or 
 whatever management scheme you want (in fact, if you're writing, say, a 
 device driver in D, you would want to use a custom allocator like this 
 and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but 
 it's perfectly doable. I did it a few years ago when I was playing around 
 with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" in 
 the internal portion of phobos/tango/druntime or wherever it lives now 
 and comment-out the calls to "gc_init()" and "gc_term()". You might also 
 need to call "gc.disable()" or something (don't really remember). And 
 then if you still want to use "new" and/or "delete" with your own memory 
 manager, you can use D's class allocator and deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into the 
 internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the 
 implementation. Let's face it, I'm not going to use D since it doesn't 
 offer me anything over C++ that I want. The main thing I may like about D 
 is that it makes the effort to make implementation of the language easier, 
 and that, I think, is very key. I am here to look for features I would put 
 in a new language, though that may be too large of an endeavor for someone 
 my age.

 Tony


If you've already got your own full-fleged, reliable, memory management 
system, plugging it into D via the methods Robert and I pointed out is 
nothing by comparison.
Nov 04 2008
parent reply "Tony" <tonytech08 gmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but 
 you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls 
 to GC methods to malloc() and free(). You can implement your own "GC" 
 or whatever management scheme you want (in fact, if you're writing, 
 say, a device driver in D, you would want to use a custom allocator 
 like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but 
 it's perfectly doable. I did it a few years ago when I was playing 
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" 
 in the internal portion of phobos/tango/druntime or wherever it lives 
 now and comment-out the calls to "gc_init()" and "gc_term()". You might 
 also need to call "gc.disable()" or something (don't really remember). 
 And then if you still want to use "new" and/or "delete" with your own 
 memory manager, you can use D's class allocator and deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into 
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the 
 implementation. Let's face it, I'm not going to use D since it doesn't 
 offer me anything over C++ that I want. The main thing I may like about D 
 is that it makes the effort to make implementation of the language 
 easier, and that, I think, is very key. I am here to look for features I 
 would put in a new language, though that may be too large of an endeavor 
 for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory management 
 system, plugging it into D via the methods Robert and I pointed out is 
 nothing by comparison.


If I could do something with the object model, and or if the compiler is 
open source, I would maybe look at the implementation as a potential 
starting point or learning tool. Every time I've considered using existing 
code though, I have ended up just starting with a clean slate for a number 
of reasons. For now, I'm going to evolve my framework a bit more and produce 
some programs. I'm keeping away from "advanced features" of existing 
languages as much as possible so as not to be tied to them. So far I've not 
found problem doing that. Error handling is the worst beast that I don't 
have completely slain yet. Generics and mem mgmt I have under control. I 
feel a bit limited by existing languages object models, that's probably the 
key reason why I'd like to invent a new language, be it for my own use or 
for more widespread use. Having full control of a language and it's 
implementation is nothing to sneeze at either, but taking advantage of that 
probably takes quite a bit of labor (more than one developer).

Tony
Nov 06 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Tony" <tonytech08 gmail.com> wrote in message 
news:gevmuc$11hb$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but 
 you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls 
 to GC methods to malloc() and free(). You can implement your own "GC" 
 or whatever management scheme you want (in fact, if you're writing, 
 say, a device driver in D, you would want to use a custom allocator 
 like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but 
 it's perfectly doable. I did it a few years ago when I was playing 
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" 
 in the internal portion of phobos/tango/druntime or wherever it lives 
 now and comment-out the calls to "gc_init()" and "gc_term()". You might 
 also need to call "gc.disable()" or something (don't really remember). 
 And then if you still want to use "new" and/or "delete" with your own 
 memory manager, you can use D's class allocator and deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into 
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the 
 implementation. Let's face it, I'm not going to use D since it doesn't 
 offer me anything over C++ that I want. The main thing I may like about 
 D is that it makes the effort to make implementation of the language 
 easier, and that, I think, is very key. I am here to look for features I 
 would put in a new language, though that may be too large of an endeavor 
 for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory management 
 system, plugging it into D via the methods Robert and I pointed out is 
 nothing by comparison.


 If I could do something with the object model, and or if the compiler is 
 open source, I would maybe look at the implementation as a potential 
 starting point or learning tool. Every time I've considered using existing 
 code though, I have ended up just starting with a clean slate for a number 
 of reasons. For now, I'm going to evolve my framework a bit more and 
 produce some programs. I'm keeping away from "advanced features" of 
 existing languages as much as possible so as not to be tied to them. So 
 far I've not found problem doing that. Error handling is the worst beast 
 that I don't have completely slain yet. Generics and mem mgmt I have under 
 control. I feel a bit limited by existing languages object models, that's 
 probably the key reason why I'd like to invent a new language, be it for 
 my own use or for more widespread use. Having full control of a language 
 and it's implementation is nothing to sneeze at either, but taking 
 advantage of that probably takes quite a bit of labor (more than one 
 developer).

 Tony


Out of curiosity, what benefits are you going for by using your own memory 
management system instead of just a built-in GC? From some of your comments 
in this thread, I'm guessing it has to do with either game development or 
limited-memory/speed embedded devices (or both in the case of handheld or 
retro gaming). I can see how those could provide reasons for a custom memory 
manager.
Nov 06 2008
parent reply "Tony" <tonytech08 gmail.com> writes:
"Nick Sabalausky" <a a.a> wrote in message 
news:gevou0$15j4$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gevmuc$11hb$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, 
 but you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls 
 to GC methods to malloc() and free(). You can implement your own 
 "GC" or whatever management scheme you want (in fact, if you're 
 writing, say, a device driver in D, you would want to use a custom 
 allocator like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, 
 but it's perfectly doable. I did it a few years ago when I was playing 
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" 
 in the internal portion of phobos/tango/druntime or wherever it lives 
 now and comment-out the calls to "gc_init()" and "gc_term()". You 
 might also need to call "gc.disable()" or something (don't really 
 remember). And then if you still want to use "new" and/or "delete" 
 with your own memory manager, you can use D's class allocator and 
 deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into 
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the 
 implementation. Let's face it, I'm not going to use D since it doesn't 
 offer me anything over C++ that I want. The main thing I may like about 
 D is that it makes the effort to make implementation of the language 
 easier, and that, I think, is very key. I am here to look for features 
 I would put in a new language, though that may be too large of an 
 endeavor for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory management 
 system, plugging it into D via the methods Robert and I pointed out is 
 nothing by comparison.


 If I could do something with the object model, and or if the compiler is 
 open source, I would maybe look at the implementation as a potential 
 starting point or learning tool. Every time I've considered using 
 existing code though, I have ended up just starting with a clean slate 
 for a number of reasons. For now, I'm going to evolve my framework a bit 
 more and produce some programs. I'm keeping away from "advanced features" 
 of existing languages as much as possible so as not to be tied to them. 
 So far I've not found problem doing that. Error handling is the worst 
 beast that I don't have completely slain yet. Generics and mem mgmt I 
 have under control. I feel a bit limited by existing languages object 
 models, that's probably the key reason why I'd like to invent a new 
 language, be it for my own use or for more widespread use. Having full 
 control of a language and it's implementation is nothing to sneeze at 
 either, but taking advantage of that probably takes quite a bit of labor 
 (more than one developer).

 Tony


 Out of curiosity, what benefits are you going for by using your own memory 
 management system instead of just a built-in GC?


Avoiding yet another black box for one thing. I can't really disclose here 
other reasons.


From some of your comments in this thread, I'm guessing it has to do with 
either game development or limited-memory/speed embedded devices (or both 
in the case of handheld or retro gaming). I can see how those could provide 
reasons for a custom memory manager.


See, you think in terms of "What reason would there be not to use GC?" 
whereas I think "For what reason would I want to use GC?". Either is OK, 
just personal preference (well in moreso in C++ than in D).

Tony
Nov 06 2008
parent bearophile <bearophileHUGS lycos.com> writes:
Tony:

 Avoiding yet another black box for one thing.


Yes, that's a real problem. In practice to program effectively in D1 you have
to read the source code of the GC (or use lot of documentation about the Phobos
GC, but it's absent still).

Bye,
bearophile
Nov 06 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Tony wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, but 
 you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls 
 to GC methods to malloc() and free(). You can implement your own "GC" 
 or whatever management scheme you want (in fact, if you're writing, 
 say, a device driver in D, you would want to use a custom allocator 
 like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, but 
 it's perfectly doable. I did it a few years ago when I was playing 
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" 
 in the internal portion of phobos/tango/druntime or wherever it lives 
 now and comment-out the calls to "gc_init()" and "gc_term()". You might 
 also need to call "gc.disable()" or something (don't really remember). 
 And then if you still want to use "new" and/or "delete" with your own 
 memory manager, you can use D's class allocator and deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into 
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the 
 implementation. Let's face it, I'm not going to use D since it doesn't 
 offer me anything over C++ that I want. The main thing I may like about D 
 is that it makes the effort to make implementation of the language 
 easier, and that, I think, is very key. I am here to look for features I 
 would put in a new language, though that may be too large of an endeavor 
 for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory management 
 system, plugging it into D via the methods Robert and I pointed out is 
 nothing by comparison.


 
 If I could do something with the object model, and or if the compiler is 
 open source, I would maybe look at the implementation as a potential 
 starting point or learning tool. Every time I've considered using existing 
 code though, I have ended up just starting with a clean slate for a number 
 of reasons. For now, I'm going to evolve my framework a bit more and produce 
 some programs. I'm keeping away from "advanced features" of existing 
 languages as much as possible so as not to be tied to them. So far I've not 
 found problem doing that. Error handling is the worst beast that I don't 
 have completely slain yet. Generics and mem mgmt I have under control. I 
 feel a bit limited by existing languages object models, that's probably the 
 key reason why I'd like to invent a new language, be it for my own use or 
 for more widespread use. Having full control of a language and it's 
 implementation is nothing to sneeze at either, but taking advantage of that 
 probably takes quite a bit of labor (more than one developer).
 
 Tony 
 
 


What exactly is your memory management system? Is it a GC? Is it pooling 
code? Is it a more efficient implementation of free/malloc?


-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Nov 07 2008
parent reply "Tony" <tonytech08 gmail.com> writes:
"Bruno Medeiros" <brunodomedeiros+spam com.gmail> wrote in message 
news:gf2967$opv$1 digitalmars.com...

 Tony wrote:

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, 
 but you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls 
 to GC methods to malloc() and free(). You can implement your own 
 "GC" or whatever management scheme you want (in fact, if you're 
 writing, say, a device driver in D, you would want to use a custom 
 allocator like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, 
 but it's perfectly doable. I did it a few years ago when I was playing 
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" 
 in the internal portion of phobos/tango/druntime or wherever it lives 
 now and comment-out the calls to "gc_init()" and "gc_term()". You 
 might also need to call "gc.disable()" or something (don't really 
 remember). And then if you still want to use "new" and/or "delete" 
 with your own memory manager, you can use D's class allocator and 
 deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into 
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the 
 implementation. Let's face it, I'm not going to use D since it doesn't 
 offer me anything over C++ that I want. The main thing I may like about 
 D is that it makes the effort to make implementation of the language 
 easier, and that, I think, is very key. I am here to look for features 
 I would put in a new language, though that may be too large of an 
 endeavor for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory management 
 system, plugging it into D via the methods Robert and I pointed out is 
 nothing by comparison.


 If I could do something with the object model, and or if the compiler is 
 open source, I would maybe look at the implementation as a potential 
 starting point or learning tool. Every time I've considered using 
 existing code though, I have ended up just starting with a clean slate 
 for a number of reasons. For now, I'm going to evolve my framework a bit 
 more and produce some programs. I'm keeping away from "advanced features" 
 of existing languages as much as possible so as not to be tied to them. 
 So far I've not found problem doing that. Error handling is the worst 
 beast that I don't have completely slain yet. Generics and mem mgmt I 
 have under control. I feel a bit limited by existing languages object 
 models, that's probably the key reason why I'd like to invent a new 
 language, be it for my own use or for more widespread use. Having full 
 control of a language and it's implementation is nothing to sneeze at 
 either, but taking advantage of that probably takes quite a bit of labor 
 (more than one developer).

 Tony


 What exactly is your memory management system? Is it a GC? Is it pooling 
 code? Is it a more efficient implementation of free/malloc?


I can't disclose those details, sorry.

Tony
Nov 07 2008
parent Christopher Wright <dhasenan gmail.com> writes:
Tony wrote:

 I can't disclose those details, sorry.


Either you're working for DoD, or you're trolling. If the entire point 
of your code were memory management, you would have said that, most 
likely, and would have no interest in D, unless you could base its 
garbage collector on your memory management system.

I can't fathom your purpose in posting here. You ask us for what D does 
better than C++ and immediately say that none of it applies to you, and 
imply that it's not worthwhile. D isn't the language for you. You've 
established that. Why are you still here?
Nov 07 2008
prev sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tony wrote:

 Please clarify for me the mem mgmt of D: is the garbage collector optional 
 or not? Just allowing me to replace "getmorecore()" or something like that 
 and then having the collector on top of that is unacceptable to me. I think 
 you may be saying that dynamic memory is in every program, which again is 
 not acceptable to me.


You can pretty much avoid all gc in D by doing your allocations using 
malloc/free and overloading operators new and delete for your classes. 
Some language features rely on gc, like dynamic closures, array 
concatenation, and the built-in associative arrays, but those features 
need not be used.



 Really, memory control is a key issue when choosing a language for me 
 anyway. I require that level of closeness to the hardware. Anything less is 
 too 4GL-like for me.


I understand how you feel. For a very long time, I felt the same way. I 
wanted the control. I thought GC was for below average programmers who 
couldn't handle memory allocation. I worked with a Java implementation 
for a while when Java first came out (building a native Java compiler) 
and came to realize the basis of my beliefs were unfounded.

GC has some compelling advantages:

1. GC programs can be faster

2. GC programs can use less memory

3. GC programs can be guaranteed to be memory safe

4. GC programs are faster to develop and have fewer bugs
Nov 08 2008
next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
Walter Bright wrote:

 I understand how you feel. For a very long time, I felt the same way. I 
 wanted the control. I thought GC was for below average programmers who 
 couldn't handle memory allocation. I worked with a Java implementation 
 for a while when Java first came out (building a native Java compiler) 
 and came to realize the basis of my beliefs were unfounded.


I feel obliged to mention Kris's presentation on garbage collection, 
"Array Slicing Fo' Shizzle" ( 
http://www.authorstream.com/Presentation/george-38229-Kris-Array-Slicing-foShizzle-Background-Java-Enigma-GC-Pressure-slic-Educa
ion-ppt-powerpoint/ 
), mentions some issues with abusing a garbage collector. (Where are the 
videos for that? I thought they were released, but I don't see any links 
in the likely places.)
Nov 09 2008
parent John Reimer <terminal.node gmail.com> writes:
Hello Christopher,


 Walter Bright wrote:
 

 I understand how you feel. For a very long time, I felt the same way.
 I wanted the control. I thought GC was for below average programmers
 who couldn't handle memory allocation. I worked with a Java
 implementation for a while when Java first came out (building a
 native Java compiler) and came to realize the basis of my beliefs
 were unfounded.
 


 I feel obliged to mention Kris's presentation on garbage collection,
 "Array Slicing Fo' Shizzle" (
 http://www.authorstream.com/Presentation/george-38229-Kris-Array-Slici
 ng-foShizzle-Background-Java-Enigma-GC-Pressure-slic-Education-ppt-pow
 erpoint/ ), mentions some issues with abusing a garbage collector.
 (Where are the videos for that? I thought they were released, but I
 don't see any links in the likely places.)
 



http://video.google.com/videoplay?docid=-4010965350602541568&hl=en

The link is provided from this page:

http://d.puremagic.com/conference2007/speakers.html

I haven't actually watched any of these yet since I'm still on dialup. :P 
 But I see that they can be downloaded as a mp4 file, so maybe I'll have 
a go at it.

-JJR
Nov 09 2008
prev sibling parent reply "Tony" <tonytech08 gmail.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:gf5r4l$2kt9$1 digitalmars.com...

 Tony wrote:

 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not? Just allowing me to replace "getmorecore()" or something 
 like that and then having the collector on top of that is unacceptable to 
 me. I think you may be saying that dynamic memory is in every program, 
 which again is not acceptable to me.


 You can pretty much avoid all gc in D by doing your allocations using 
 malloc/free and overloading operators new and delete for your classes. 
 Some language features rely on gc, like dynamic closures, array 
 concatenation, and the built-in associative arrays, but those features 
 need not be used.



 Really, memory control is a key issue when choosing a language for me 
 anyway. I require that level of closeness to the hardware. Anything less 
 is too 4GL-like for me.


 I understand how you feel. For a very long time, I felt the same way. I 
 wanted the control. I thought GC was for below average programmers who 
 couldn't handle memory allocation. I worked with a Java implementation for 
 a while when Java first came out (building a native Java compiler) and 
 came to realize the basis of my beliefs were unfounded.

 GC has some compelling advantages:


To you and a bunch of others it does, you mean. "Compelling", to me, means 
something like "leapfrogs enough other issues or capabilities and/or in a 
nicer way" than what is currently available or what can be created.


 1. GC programs can be faster

 2. GC programs can use less memory

 3. GC programs can be guaranteed to be memory safe

 4. GC programs are faster to develop and have fewer bugs


None of which "sell me" on GC. But please don't "go there"! (I know that "to 
GC or not to GC" is a flamewar topic). Who knows, maybe my own memory 
management architecture (the reworked (new and improved! literally) version 
not yet in production, but soon) will evolve to be the backend to a garbage 
collector. As an independent developer, I have to keep my cards close to my 
chest about some of (one?) the reasons why I thing "my way" is compelling 
(in the true sense of the word). Gar bage collectors have a (some?) 
characteristic(s) that may indeed be deal breakers for some (a lot?) of 
software. That's why I think GC should be an opt-in rather than an opt-out 
choice. That's a key characteristic of C++: opt-in. And I really, really 
like that level of creative freedom. (Of course, in my own language, I'll do 
that even better than C++ does. :) Which is not to say though that I expect 
to replace C++. My language will be "higher level" (whatever that means) 
than C++).

Tony
Nov 14 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Tony" <tonytech08 gmail.com> wrote in message 
news:gflkav$8rc$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gf5r4l$2kt9$1 digitalmars.com...

 1. GC programs can be faster

 2. GC programs can use less memory

 3. GC programs can be guaranteed to be memory safe

 4. GC programs are faster to develop and have fewer bugs


 None of which "sell me" on GC.


Why not? They sound like pretty darn good reasons to me. What are you 
expecting out of a memory manager, the secret of the universe?

If you have reason to disagree that the items on that list are true, then 
ok, I can understand. But if you're saying that those aren't good enough 
reasons, then it sounds like you have unrealistic expectations.


 As an independent developer, I have to keep my cards close to my chest 
 about some of (one?) the reasons why I thing "my way" is compelling (in 
 the true sense of the word).


I'm an independent developer too, but I have to say, this is a clear 
indication that your system isn't nearly as special as you think it is.

There are only three types of people who ever have a non-standard solution 
and think it's actually worth bothering with such secrecy: 1. 
Industry-renowned full-time tech researchers who actually do create good 
stuff (and then make it publicly known by the time their research is done), 
2. Suits and managers, who don't know a damn thing about the technical side 
of anything, including code, and 3. Novices.

I'm not saying this to try to convince you to tell us, or to insult you, but 
as a cautionary tale. You need to take a good hard look at your system, be 
as objective as you can possibly be, and make sure it really is the that 
special. Because anytime you tell yourself "This is so good that nobody else 
has thought of it and it's the ace up my sleeve", that should raise a giant 
red flag in your mind saying that no, in fact, it's extremely doubtful that 
it's anything special at all.
Nov 14 2008
next sibling parent superdan <super dan.org> writes:
Nick Sabalausky Wrote:


 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gflkav$8rc$1 digitalmars.com...

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:gf5r4l$2kt9$1 digitalmars.com...

 1. GC programs can be faster

 2. GC programs can use less memory

 3. GC programs can be guaranteed to be memory safe

 4. GC programs are faster to develop and have fewer bugs


 None of which "sell me" on GC.


 
 Why not? They sound like pretty darn good reasons to me. What are you 
 expecting out of a memory manager, the secret of the universe?
 
 If you have reason to disagree that the items on that list are true, then 
 ok, I can understand. But if you're saying that those aren't good enough 
 reasons, then it sounds like you have unrealistic expectations.
 

 As an independent developer, I have to keep my cards close to my chest 
 about some of (one?) the reasons why I thing "my way" is compelling (in 
 the true sense of the word).


 
 I'm an independent developer too, but I have to say, this is a clear 
 indication that your system isn't nearly as special as you think it is.
 
 There are only three types of people who ever have a non-standard solution 
 and think it's actually worth bothering with such secrecy: 1. 
 Industry-renowned full-time tech researchers who actually do create good 
 stuff (and then make it publicly known by the time their research is done), 
 2. Suits and managers, who don't know a damn thing about the technical side 
 of anything, including code, and 3. Novices.


4. beneficiaries of da sayin' "on the internet nobody knows ur a dog".


 I'm not saying this to try to convince you to tell us, or to insult you, but 
 as a cautionary tale. You need to take a good hard look at your system, be 
 as objective as you can possibly be, and make sure it really is the that 
 special. Because anytime you tell yourself "This is so good that nobody else 
 has thought of it and it's the ace up my sleeve", that should raise a giant 
 red flag in your mind saying that no, in fact, it's extremely doubtful that 
 it's anything special at all.


nice words my friend. but somethin' tells me yer wasting yer breath.
Nov 14 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Nick Sabalausky wrote:

 I'm not saying this to try to convince you to tell us, or to insult you, but 
 as a cautionary tale. You need to take a good hard look at your system, be 
 as objective as you can possibly be, and make sure it really is the that 
 special. Because anytime you tell yourself "This is so good that nobody else 
 has thought of it and it's the ace up my sleeve", that should raise a giant 
 red flag in your mind saying that no, in fact, it's extremely doubtful that 
 it's anything special at all.


If it really is that special, ask yourself: why isn't your whole 
business centered on this one thing?

If your business actually is centered on that, then make sure you have 
good marketing, because just having special code or algorithms won't 
suffice.
Nov 15 2008
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Tony wrote:

 That's why I think GC should be an opt-in rather than an opt-out 
 choice. That's a key characteristic of C++: opt-in. And I really, really 
 like that level of creative freedom.


I've used a GC with C++ (both the Boehm one and one I wrote myself). The 
idea that GC is opt-in in C++ is ok for the user, but not for the 
library writer. The poor library writer, faced with supporting both GC 
and explicit allocation, winds up stuck with the worst of both. The 
problem is when calling new, you cannot tell which you're getting. That 
just throws a monkey wrench into designing portable software, because to 
effectively use GC entails writing code in a different way.
Nov 14 2008
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Tony:

 Walter Bright:

 1. GC programs can be faster
 2. GC programs can use less memory
 3. GC programs can be guaranteed to be memory safe
 4. GC programs are faster to develop and have fewer bugs


 
 None of which "sell me" on GC.


Generally a program that uses GC uses more RAM (2-12 times) than a manually
memory managed one. I have also read various articles that say the same thing. 

They also say that GC-managed programs can be almost as fast as manually
managed ones only of you give them 2-6 the RAM you give un-GC-managed ones.

It can be right only if you count memory leaks too: they make programs that
manage memory manually to use unbound amounts of memory. On the other hand a GC
doesn't prevents you all memory leaks, because you can leave around references,
etc.

So even taking into account that Walter's experience on such topics is far
greater than mine (I've never written a GC for C++, for example), I'd risk say
that in general point 2 is wrong.
Said that, most of the times using a GC is better (especially if you use a
modern GC, like the HotSpot one, etc), and often today RAM isn't a scarce
resource anymore, so I like D to have a built-in GC activated by default, plus
a C heap to manage things manually :-)

Bye,
bearophile
Nov 15 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Tony:

 Walter Bright:

 1. GC programs can be faster 2. GC programs can use less memory 
 3. GC programs can be guaranteed to be memory safe 4. GC programs
 are faster to develop and have fewer bugs




 So even taking into account that Walter's experience on such topics
 is far greater than mine (I've never written a GC for C++, for
 example), I'd risk say that in general point 2 is wrong.


When people do benchmarks comparing the same code in explicit allocation 
and GC, the GC uses more memory. However, and this is a big however, the 
existence of GC means you can structure your algorithm to need far fewer 
allocations. Kris Bell's talk on that at the last D conference was a 
prime example of that.

For example, with GC you can slice an existing string. With manual mm, 
you have to allocate memory and copy it.
Nov 15 2008
prev sibling parent reply Daniel de Kok <daniel nowhere.nospam> writes:
On Fri, 14 Nov 2008 22:48:41 -0600, Tony wrote:

 breakers for some (a lot?) of software. That's why I think GC should be
 an opt-in rather than an opt-out choice. That's a key characteristic of
 C++: opt-in. And I really, really like that level of creative freedom.


That's not necessarily good. There are now multiple commonly-used methods 
for pointing to instances in C++: plain pointers, references, and smart 
pointers, all with different usage and semantics. It's a burden for 
library writers and library users. An opt-in GC only makes the burden 
heavier.

In contrast, most GC-ed languages make life simpler not requiring a 
plethora of alternate management/lifetime schemes.

Take care,
Daniel
Nov 15 2008
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Daniel de Kok (daniel nowhere.nospam)'s article

 On Fri, 14 Nov 2008 22:48:41 -0600, Tony wrote:

 breakers for some (a lot?) of software. That's why I think GC should be
 an opt-in rather than an opt-out choice. That's a key characteristic of
 C++: opt-in. And I really, really like that level of creative freedom.


 That's not necessarily good. There are now multiple commonly-used methods
 for pointing to instances in C++: plain pointers, references, and smart
 pointers, all with different usage and semantics. It's a burden for
 library writers and library users. An opt-in GC only makes the burden
 heavier.
 In contrast, most GC-ed languages make life simpler not requiring a
 plethora of alternate management/lifetime schemes.
 Take care,
 Daniel


Agreed.  Also, whether or not GC is the default in a language deeply affects the
de facto standard way of doing things.  For example, in C++, you don't have nice
slice syntax in STL because STL is designed for use with manual memory
management.
 Also, from what I've seen and heard, you tend to lose a lot of the theoretical
efficiency of manual memory management when you replace it with ref counting
(read:  poor man's GC), or lots of copying to make every object have a clear
owner.  I translated a small but computationally intensive machine learning
program from C++ to D a few months ago, and the D version was drastically faster
because it avoided lots of excess copying.  Granted, the C++ version *could*
have
been more optimized, but in the real world, people don't have forever to
optimize
all this stuff away.

Another interesting thing about D that I don't think people give enough notice
to
is how cleanly you can mix manual and automatic memory management to get the
best
of both.  GC is fast (compared to manual memory management) when you have large
amounts of small objects with non-trivial lifetimes.  It is slow when you have a
few large objects with trivial lifetimes.  The way I usually write my code,
which
is generally number crunching type stuff that can require lots of scratch space,
is to use GC for all the small objects and objects where the lifetime is
non-trivial, and free things like scratch arrays that can be large and are only
used within one function manually.
Nov 15 2008
parent Walter Bright <newshound1 digitalmars.com> writes:
dsimcha wrote:

 Agreed.  Also, whether or not GC is the default in a language deeply affects
the
 de facto standard way of doing things.  For example, in C++, you don't have
nice
 slice syntax in STL because STL is designed for use with manual memory
management.
  Also, from what I've seen and heard, you tend to lose a lot of the theoretical
 efficiency of manual memory management when you replace it with ref counting
 (read:  poor man's GC), or lots of copying to make every object have a clear
 owner.  I translated a small but computationally intensive machine learning
 program from C++ to D a few months ago, and the D version was drastically
faster
 because it avoided lots of excess copying.  Granted, the C++ version *could*
have
 been more optimized, but in the real world, people don't have forever to
optimize
 all this stuff away.


Modern C++ practices (as best as I can tell) make extensive use of 
ref-counting memory management, i.e. shared_ptr<>. This requires TWO 
allocations for each use, not just one. The second allocation is for the 
reference counting management.

Next, every time you copy a pointer (like pass it to a function, return 
it, etc.) you have to increment, then decrement, the reference count. If 
you've got multithreading on, this requires a mutex or the usual memory 
syncing primitives which are 100x slower than regular memory access.

You can escape the inc/dec overhead by converting the shared ptr to a 
regular pointer, but then you lose all the safety guarantees.
Nov 15 2008
prev sibling next sibling parent reply Piotrek <starpit tlen.pl> writes:
Nick Sabalausky wrote:

 [...]The concept of domain-specific languages is 
 ultra-trendy these days (probably promoted by the same knuckleheads that 
 hailed things like pure-OO, pure-functional, and Extreme Programming as 
 silver bullets). But I consider domain-specific languages to be purely a 
 symptom of a strong need for a better general purpose language.
 


Totally agree. At my point of view it looks excacly the same. I started 
with pascal then moved to c/c++ at university but I abandoned it because 
of its ugliness and non intuitive application development. Then I found 
working with PHP/JAVA much easier but I was disappointed by its 
fundamentals (please let me forget about PHP as a programming language). 
And when I was left without any hope I saw a Bright light. :D

For me D takes the best of everything I have seen. Of course it isn't 
perfect but takes the right course and I want to be aboard.


 Let's face it: programming needs and uses have expanded so much over the 
 last decade or so that C/C++ hasn't really been a "general purpose" language 
 for quite some time. These days it's a systems/performance language instead. 
 True, all the attempts at retrofitting it with modern-ish features to try to 
 keep it general-purpose have turned it into a regular frankenstein's monster 
 of a language, but that does nothing to disprove the viability of general 
 purpose languages in general. It just demonstrates that C++ needs a reboot 
 (hence: D). Heck, D is already far better as a general-purpose language than 
 C/C++ (although it's still not quite there yet).


Those words are mine (I wish) ;)


 I'd *much* rather use a true general-purpose language (which, again, C++ is 
 no longer an example of) than muck around with 500 different languages for 
 every stupid little thing.
 
 For example, have you ever tried doing web development? You can't 
 realistically do anything nontrivial without tripping over at least handful 
 of different, essentially domain-specific, languages: ECMAScript, (T)SQL, 

 And that's just the bare minimum for any non-trivial web site. For one 
 thing, most of those are great examples of the fact that domain-specific 
 languages do nothing to prevent piss-poor language design. But besides that: 
 Conceptually, web development is one of the most trivial forms of 
 programming out there. But the domain-specific language-soup realities of it 
 have turned what should have been trivial into one of the programming 
 world's biggest pains-in-the-ass. It's an absolute mess. 


That's why I'm planing to use D + Tango + Mango and blow up everything 
else including existing http servers. (I had also questions in my mind 
why the hell databases relies on SQL so much).

Cheers
Nov 03 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Piotrek" <starpit tlen.pl> wrote in message 
news:geo14c$ol9$1 digitalmars.com...

 Nick Sabalausky wrote:

 [...]The concept of domain-specific languages is ultra-trendy these days 
 (probably promoted by the same knuckleheads that hailed things like 
 pure-OO, pure-functional, and Extreme Programming as silver bullets). But 
 I consider domain-specific languages to be purely a symptom of a strong 
 need for a better general purpose language.


 Totally agree. At my point of view it looks excacly the same. I started 
 with pascal then moved to c/c++ at university but I abandoned it because 
 of its ugliness and non intuitive application development. Then I found 
 working with PHP/JAVA much easier but I was disappointed by its 
 fundamentals (please let me forget about PHP as a programming language). 
 And when I was left without any hope I saw a Bright light. :D

 For me D takes the best of everything I have seen. Of course it isn't 
 perfect but takes the right course and I want to be aboard.


 Let's face it: programming needs and uses have expanded so much over the 
 last decade or so that C/C++ hasn't really been a "general purpose" 
 language for quite some time. These days it's a systems/performance 
 language instead. True, all the attempts at retrofitting it with 
 modern-ish features to try to keep it general-purpose have turned it into 
 a regular frankenstein's monster of a language, but that does nothing to 
 disprove the viability of general purpose languages in general. It just 
 demonstrates that C++ needs a reboot (hence: D). Heck, D is already far 
 better as a general-purpose language than C/C++ (although it's still not 
 quite there yet).


 Those words are mine (I wish) ;)


 I'd *much* rather use a true general-purpose language (which, again, C++ 
 is no longer an example of) than muck around with 500 different languages 
 for every stupid little thing.

 For example, have you ever tried doing web development? You can't 
 realistically do anything nontrivial without tripping over at least 
 handful of different, essentially domain-specific, languages: ECMAScript, 

 Python or Ruby. And that's just the bare minimum for any non-trivial web 
 site. For one thing, most of those are great examples of the fact that 
 domain-specific languages do nothing to prevent piss-poor language 
 design. But besides that: Conceptually, web development is one of the 
 most trivial forms of programming out there. But the domain-specific 
 language-soup realities of it have turned what should have been trivial 
 into one of the programming world's biggest pains-in-the-ass. It's an 
 absolute mess.


 That's why I'm planing to use D + Tango + Mango and blow up everything 
 else including existing http servers.


I've found that, unfortunately, to not be quite enough. Not because of any 
limitations of D/Tango/Mango, but because:


programmer, have little to no say on how the server is set up and what 
languages are available (for instance, I've done plenty of PHP and VBScript, 
but never by choice).


that you're still stuck with de-facto standards like ECMAScript, and a lack 
of the upcoming/proposed improvements to (X)HTML (things I've thought should 
have been in HTML all along...*grumble*).

This is why I've recently been getting interested in high-level language 
translation, and have been playing around with writing such a tool. I'd like 
to be able to write code in a sensible language like D and just translate 
that into whatever horrible scripting language the 
sysadmin/netadmin/browser-vendor decided would be suitable.


 (I had also questions in my mind why the hell databases relies on SQL so 
 much).


I agree. I'd much rather just use a sensible API (DBMS-agnostic of course). 
Pasting together SQL snippets is just plain ugly, and why dynamically 
generate code just for the DBMS to go and parse it? I mean, geez, just cut 
the middleman and pass the request directly. LINQ is better, but I'm still 
not convinced it's the right approach. TSQL stored procedures are something 
I'd rather, well, just write in a more "normal" language.  And then, of 
course, there's the bizarre "insert" vs. "update" syntax inconsistencies and 
general incompatibilities across vendors (ex: insert a row and retreive the 
auto-gen id <- which is really a rather common thing to need to do, 
particularly if you've got any foreign keys in the DB design, which again is 
rather common).

To be fair though, I have to say that without some of the advanced features 

an API for any non-trivial queries could potentially get ugly.
Nov 03 2008
next sibling parent reply "Danny Wilson" <bluezenix gmail.com> writes:
Op Tue, 04 Nov 2008 02:55:41 +0100 schreef Nick Sabalausky <a a.a>:


 This is why I've recently been getting interested in high-level language
 translation, and have been playing around with writing such a tool. I'd  
 like
 to be able to write code in a sensible language like D and just translate
 that into whatever horrible scripting language the
 sysadmin/netadmin/browser-vendor decided would be suitable.



That sensible language already exists! Be sure to check out: haxe.org
Nov 04 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"Danny Wilson" <bluezenix gmail.com> wrote in message 
news:op.uj26ncatbmuhq1 danny-wilsons-ep45-ds4.local...

 Op Tue, 04 Nov 2008 02:55:41 +0100 schreef Nick Sabalausky <a a.a>:


 This is why I've recently been getting interested in high-level language
 translation, and have been playing around with writing such a tool. I'd 
 like
 to be able to write code in a sensible language like D and just translate
 that into whatever horrible scripting language the
 sysadmin/netadmin/browser-vendor decided would be suitable.



 That sensible language already exists! Be sure to check out: haxe.org


That looks pretty good (I've come across it once before), but what I had in 
mind was a little more universal (and perhaps, more experimental or even 
naive ;) ). What I'm planing to experiment with is having a basic 
compiler/translator program which accepts language plugins that describe 
both how to parse the language and how to output it. Then the tool would go 
something like "Input HLL -> Input AST -> Intermediate AST -> Output AST -> 
Output HLL". Toss in a whole bunch of language plugins and, assuming it 
could actually be pulled off, what you'd have is something like HaXe except:

- ASP would be supported (important for me, a lot of clients are MS houses).

- The programmer (or tech lead, if applicable) could chose what they 
consider a sensible language (For instance, HaXe does look pretty good from 
what I've seen, but I prefer C-style variable declarations over HaXe's 
ECMAScript3/4-style declarations (though I could certainly live with them)).

- HLLs and platforms, in general, would be much more divorced than they are 
today. Much less chance of the choice in platform forcing/limiting your hand 
in the choice of language. HaXe just simply gives you one extra choice, and 
even then, only when you're targeting ECMAScript, Flash, PHP or some rare 
system that actually has Neko.

- It would have a name that isn't mixed case and isn't inconsistent between 
spelling and pronunciation ;)
Nov 04 2008
parent reply "Danny Wilson" <bluezenix gmail.com> writes:
Op Tue, 04 Nov 2008 21:36:23 +0100 schreef Nick Sabalausky <a a.a>:


 That looks pretty good (I've come across it once before), but what I had  
 in
 mind was a little more universal (and perhaps, more experimental or even
 naive ;) ). What I'm planing to experiment with is having a basic
 compiler/translator program which accepts language plugins that describe
 both how to parse the language and how to output it. Then the tool would  
 go
 something like "Input HLL -> Input AST -> Intermediate AST -> Output AST  
 ->
 Output HLL". Toss in a whole bunch of language plugins and, assuming it
 could actually be pulled off, what you'd have is something like HaXe  
 except:


Except it isn't a language anymore, but more like a complete compiler  
framework ;-)



 - ASP would be supported (important for me, a lot of clients are MS  
 houses).

 - The programmer (or tech lead, if applicable) could chose what they
 consider a sensible language (For instance, HaXe does look pretty good  
 from
 what I've seen, but I prefer C-style variable declarations over HaXe's
 ECMAScript3/4-style declarations (though I could certainly live with  
 them)).

 - HLLs and platforms, in general, would be much more divorced than they  
 are
 today. Much less chance of the choice in platform forcing/limiting your  
 hand
 in the choice of language. HaXe just simply gives you one extra choice,  
 and
 even then, only when you're targeting ECMAScript, Flash, PHP or some rare
 system that actually has Neko.


Well PHP is a pretty recent addition. Someone has been working on MSIL  
output to target .NET (and thus Silverlight aswell). Someone else has  
announced he's working on C++ output aswell.
The compiler is written in OCaml and very fast. Due to haXe's nature of  
targetting different platforms, it is already setup pretty pluggable.

But yea I'd like some additions to haXe myself, like a stronger template  
system (yay D!) for starters. :-)



 - It would have a name that isn't mixed case and isn't inconsistent  
 between
 spelling and pronunciation ;)


But at least its fairly unique. Unlike some single letter which also  
happens to be the first letter of my name .. hehe.



- Danny Wilson
Nov 04 2008
parent "Nick Sabalausky" <a a.a> writes:
"Danny Wilson" <bluezenix gmail.com> wrote in message 
news:op.uj36sqczbmuhq1 danny-wilsons-ep45-ds4.local...

 Op Tue, 04 Nov 2008 21:36:23 +0100 schreef Nick Sabalausky <a a.a>:


 That looks pretty good (I've come across it once before), but what I had 
 in
 mind was a little more universal (and perhaps, more experimental or even
 naive ;) ). What I'm planing to experiment with is having a basic
 compiler/translator program which accepts language plugins that describe
 both how to parse the language and how to output it. Then the tool would 
 go
 something like "Input HLL -> Input AST -> Intermediate AST -> Output 
 ST  ->
 Output HLL". Toss in a whole bunch of language plugins and, assuming it
 could actually be pulled off, what you'd have is something like HaXe 
 except:


 Except it isn't a language anymore, but more like a complete compiler 
 framework ;-)


Yes, but I consider that a good thing because I view the goals of 
"create/choose a good language" and "allow an alternate language for a 
particular platform" to be separate problems that, ideally, should have 
separate (but compatible) solutions. HaXe mixes the two: it lets you choose 
an alternate language for browser-scripting, Flash, and web 
server-scripting, but only if the language you choose is the one language 
that the HaXe project provides for you.

Granted, I'm not saying HaXe is a bad thing. I'm quite tempted to use it in 
the meantime before my project actually bears any fruit (*if* it ever does), 

ever created for it.


 - ASP would be supported (important for me, a lot of clients are MS 
 houses).

 - The programmer (or tech lead, if applicable) could chose what they
 consider a sensible language (For instance, HaXe does look pretty good 
 from
 what I've seen, but I prefer C-style variable declarations over HaXe's
 ECMAScript3/4-style declarations (though I could certainly live with 
 them)).

 - HLLs and platforms, in general, would be much more divorced than they 
 are
 today. Much less chance of the choice in platform forcing/limiting your 
 hand
 in the choice of language. HaXe just simply gives you one extra choice, 
 and
 even then, only when you're targeting ECMAScript, Flash, PHP or some rare
 system that actually has Neko.


 Well PHP is a pretty recent addition. Someone has been working on MSIL 
 output to target .NET (and thus Silverlight aswell). Someone else has 
 announced he's working on C++ output aswell.
 The compiler is written in OCaml and very fast. Due to haXe's nature of 
 targetting different platforms, it is already setup pretty pluggable.


Good to know :)


 But yea I'd like some additions to haXe myself, like a stronger template 
 system (yay D!) for starters. :-)



 - It would have a name that isn't mixed case and isn't inconsistent 
 between
 spelling and pronunciation ;)


 But at least its fairly unique. Unlike some single letter which also 
 happens to be the first letter of my name .. hehe.


Very true!
Nov 04 2008
prev sibling parent Piotrek <starpit tlen.pl> writes:
Nick Sabalausky wrote:

 I've found that, unfortunately, to not be quite enough. Not because of any 
 limitations of D/Tango/Mango, but because:
 

 programmer, have little to no say on how the server is set up and what 
 languages are available (for instance, I've done plenty of PHP and VBScript, 
 but never by choice).
 


True. And that's why I search opportunity to get around such limitations.



 that you're still stuck with de-facto standards like ECMAScript, and a lack 
 of the upcoming/proposed improvements to (X)HTML (things I've thought should 
 have been in HTML all along...*grumble*).
 


Also true. JavaScript is necessary to make dhtml and ajax and I see no 
way to get rid of it for now (only I can do is use it when truly needed).



 [...] Pasting together SQL snippets is just plain ugly, and why dynamically 
 generate code just for the DBMS to go and parse it? I mean, geez, just cut 
 the middleman and pass the request directly. LINQ is better, but I'm still 
 not convinced it's the right approach. TSQL stored procedures are something 
 I'd rather, well, just write in a more "normal" language.  And then, of 
 course, there's the bizarre "insert" vs. "update" syntax inconsistencies and 
 general incompatibilities across vendors (ex: insert a row and retreive the 
 auto-gen id <- which is really a rather common thing to need to do, 
 particularly if you've got any foreign keys in the DB design, which again is 
 rather common).
 


The LINQ project looks ok. However I don't use the Microsoft software at 
all.


 To be fair though, I have to say that without some of the advanced features 

 an API for any non-trivial queries could potentially get ugly. 



I find non-trivial SQL queries as ugly as hell. I'd rather see it in OO way.

Cheers
Nov 04 2008
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:

 For example, have you ever tried doing web development? You can't 
 realistically do anything nontrivial without tripping over at least handful 
 of different, essentially domain-specific, languages: ECMAScript, (T)SQL, 

 And that's just the bare minimum for any non-trivial web site. For one 
 thing, most of those are great examples of the fact that domain-specific 
 languages do nothing to prevent piss-poor language design. But besides that: 
 Conceptually, web development is one of the most trivial forms of 
 programming out there. But the domain-specific language-soup realities of it 
 have turned what should have been trivial into one of the programming 
 world's biggest pains-in-the-ass. It's an absolute mess. I'm currently 
 writing my first compiler, and I have in the past written homebrew for the 
 Atari VCS, and an Asm sound driver for a multiprocessing 
 microcontroller/embedded-device that has no sound hardware other than a 
 generic DAC capability. All of those have proven to be far less 
 pains-in-the-ass than any of my web development work. Considering the 
 conceptual simplicity of the web, that's just absolutely pathetic. 


Microsoft agrees.

http://www.informationweek.com/news/internet/webdev/showArticle.jhtml?articleID=204701262

Write your web frontend & backend in .NET. Throw in a little LINQ-to-SQL 
  and you don't even need SQL. (The official website ihas been down 
since September... I assume they're productizing it).
Nov 03 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Robert Fraser:

 Write your web frontend & backend in .NET. Throw in a little LINQ-to-SQL 
   and you don't even need SQL. (The official website ihas been down 
 since September... I assume they're productizing it).


Is this relevant?
http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

Bye,
bearophile
Nov 03 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:geo736$15ic$1 digitalmars.com...

 Robert Fraser:

 Write your web frontend & backend in .NET. Throw in a little LINQ-to-SQL
   and you don't even need SQL. (The official website ihas been down
 since September... I assume they're productizing it).


 Is this relevant?
 http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

 Bye,
 bearophile


Funny, the people complaining about LINQ being killed sound exactly like me 
whenever I explain my reluctance to buy a 360 after having MS blatantly 
abandon my XBox 1 (By constrast, Sony still supports their PS2. But I liked 
my XBox 1 better.)
Nov 03 2008
parent Robert Fraser <fraserofthenight gmail.com> writes:
Nick Sabalausky wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:geo736$15ic$1 digitalmars.com...

 Robert Fraser:

 Write your web frontend & backend in .NET. Throw in a little LINQ-to-SQL
   and you don't even need SQL. (The official website ihas been down
 since September... I assume they're productizing it).


 Is this relevant?
 http://ayende.com/Blog/archive/2008/10/31/microsoft-kills-linq-to-sql.aspx

 Bye,
 bearophile


 
 Funny, the people complaining about LINQ being killed sound exactly like me 
 whenever I explain my reluctance to buy a 360 after having MS blatantly 
 abandon my XBox 1 (By constrast, Sony still supports their PS2. But I liked 
 my XBox 1 better.) 


That's all business concerns. More people still have PS2s than PS3s, so 
  it's in Sony's best interest to continue to support the PS2. The same 
is not true of the XBOX.

I didn't know they killed LINQ to SQL, but I guess they didn't kill LINQ 
in general, so they probably have (or are going to have) a new tech to 
replace it. I don't know hoe the Entity Data Model interacts with LINQ, 
but I'd assume that's the "next big thing".
Nov 04 2008
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"Robert Fraser" <fraserofthenight gmail.com> wrote in message 
news:geo6oh$14m3$1 digitalmars.com...

 Nick Sabalausky wrote:

 For example, have you ever tried doing web development? You can't 
 realistically do anything nontrivial without tripping over at least 
 handful of different, essentially domain-specific, languages: ECMAScript, 

 Python or Ruby. And that's just the bare minimum for any non-trivial web 
 site. For one thing, most of those are great examples of the fact that 
 domain-specific languages do nothing to prevent piss-poor language 
 design. But besides that: Conceptually, web development is one of the 
 most trivial forms of programming out there. But the domain-specific 
 language-soup realities of it have turned what should have been trivial 
 into one of the programming world's biggest pains-in-the-ass. It's an 
 absolute mess. I'm currently writing my first compiler, and I have in the 
 past written homebrew for the Atari VCS, and an Asm sound driver for a 
 multiprocessing microcontroller/embedded-device that has no sound 
 hardware other than a generic DAC capability. All of those have proven to 
 be far less pains-in-the-ass than any of my web development work. 
 Considering the conceptual simplicity of the web, that's just absolutely 
 pathetic.


 Microsoft agrees.

 http://www.informationweek.com/news/internet/webdev/showArticle.jhtml?articleID=204701262

 Write your web frontend & backend in .NET. Throw in a little LINQ-to-SQL 
 and you don't even need SQL. (The official website ihas been down since 
 September... I assume they're productizing it).


Microsoft comes up with a lot of great ideas like this, but then they hijack 
any potential for widespread usage by marrying it to other MS-only products 
and technologies. I'm not saying its good or bad business sense for them to 
do this, not saying it's ethical or unethical, but as an outside programmer 
it just doesn't help me much. Which gets frustrating, because I'll know I'm 
looking at a good thing, but just can't justify jumping on board until if 
and when the open-source community builds a compatibility-solution.
Nov 03 2008
prev sibling parent Don <nospam nospam.com> writes:
Nick Sabalausky wrote:

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:genht8$2fcg$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gel5tu$1a1v$1 digitalmars.com...

 "Clay Smith" <clayasaurus gmail.com> wrote in message 
 news:gej5nr$13jd$1 digitalmars.com...

 Tony wrote:

 Someone has to ask the obvious question! (The question is in the 
 subject of this post).

 Tony


 Technically, I'd consider C++ to be undead. Old, ugly, its zombie 
 rotting flesh never seems to die. It lives by eating the brains of C 
 programmers.

 ~ Clay


 Funny you mention that, the analogies I normally think of for C++ are 
 either a 120+ year-old on life support or, as you said, the living dead. 
 It's long past it's time, but people just won't let it finally rest 
 (probably because, aside from D, there's no modern language that's a 

 for instance, are only partial replacements. They can handle many of 
 C++'s uses, but not all.)


 The "in *all* of C++'s use-cases" part is probably the way to create a 
 dinosaur (call it E, F or G or whatever). The concept of "general purpose 
 language" is getting a bit long-toothed?

 Tony


 
 I strongly disagree. The concept of domain-specific languages is 
 ultra-trendy these days (probably promoted by the same knuckleheads that 
 hailed things like pure-OO, pure-functional, and Extreme Programming as 
 silver bullets). But I consider domain-specific languages to be purely a 
 symptom of a strong need for a better general purpose language.


Yeah. Domain-specific languages used to be really popular. I can 
remember when everyone invented their own language for saving 
configuration settings, for example <g>. It's symptomatic of an absence 
of a decent standard.


 I'd *much* rather use a true general-purpose language (which, again, C++ is 
 no longer an example of) than muck around with 500 different languages for 
 every stupid little thing.
 
 For example, have you ever tried doing web development? 
 Considering the
 conceptual simplicity of the web, that's just absolutely pathetic. 


Amen. IMHO, it's one of the great failures of the software industry.
I find it incredible that we've ended up with a situation which is so 
dreadful.
Nov 04 2008
prev sibling parent reply superdan <super dan.org> writes:
Tony Wrote:


 
 "Nick Sabalausky" <a a.a> wrote in message 
 news:gevou0$15j4$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gevmuc$11hb$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message 
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message 
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message 
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory, 
 but you can replace those calls with whatever you want. See Tango's 
 (druntime's) "stub" GC, which just reroutes compiler-generated calls 
 to GC methods to malloc() and free(). You can implement your own 
 "GC" or whatever management scheme you want (in fact, if you're 
 writing, say, a device driver in D, you would want to use a custom 
 allocator like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector 
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky, 
 but it's perfectly doable. I did it a few years ago when I was playing 
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char **argv)" 
 in the internal portion of phobos/tango/druntime or wherever it lives 
 now and comment-out the calls to "gc_init()" and "gc_term()". You 
 might also need to call "gc.disable()" or something (don't really 
 remember). And then if you still want to use "new" and/or "delete" 
 with your own memory manager, you can use D's class allocator and 
 deallocator feature 
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume you 
 could probably plug those class allocators/deallocators directly into 
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the 
 implementation. Let's face it, I'm not going to use D since it doesn't 
 offer me anything over C++ that I want. The main thing I may like about 
 D is that it makes the effort to make implementation of the language 
 easier, and that, I think, is very key. I am here to look for features 
 I would put in a new language, though that may be too large of an 
 endeavor for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory management 
 system, plugging it into D via the methods Robert and I pointed out is 
 nothing by comparison.


 If I could do something with the object model, and or if the compiler is 
 open source, I would maybe look at the implementation as a potential 
 starting point or learning tool. Every time I've considered using 
 existing code though, I have ended up just starting with a clean slate 
 for a number of reasons. For now, I'm going to evolve my framework a bit 
 more and produce some programs. I'm keeping away from "advanced features" 
 of existing languages as much as possible so as not to be tied to them. 
 So far I've not found problem doing that. Error handling is the worst 
 beast that I don't have completely slain yet. Generics and mem mgmt I 
 have under control. I feel a bit limited by existing languages object 
 models, that's probably the key reason why I'd like to invent a new 
 language, be it for my own use or for more widespread use. Having full 
 control of a language and it's implementation is nothing to sneeze at 
 either, but taking advantage of that probably takes quite a bit of labor 
 (more than one developer).

 Tony


 Out of curiosity, what benefits are you going for by using your own memory 
 management system instead of just a built-in GC?


 
 Avoiding yet another black box for one thing. I can't really disclose here 
 other reasons.


translation: "im a 13 yo wannabe cutting my teeth at shit who tries to look
interesting on the net."
Nov 07 2008
parent reply "Nick Sabalausky" <a a.a> writes:
"superdan" <super dan.org> wrote in message 
news:gf1rhi$2ors$1 digitalmars.com...

 Tony Wrote:


 "Nick Sabalausky" <a a.a> wrote in message
 news:gevou0$15j4$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message
 news:gevmuc$11hb$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message
 news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory,
 but you can replace those calls with whatever you want. See 
 Tango's
 (druntime's) "stub" GC, which just reroutes compiler-generated 
 calls
 to GC methods to malloc() and free(). You can implement your own
 "GC" or whatever management scheme you want (in fact, if you're
 writing, say, a device driver in D, you would want to use a 
 custom
 allocator like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky,
 but it's perfectly doable. I did it a few years ago when I was 
 playing
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char 
 **argv)"
 in the internal portion of phobos/tango/druntime or wherever it 
 lives
 now and comment-out the calls to "gc_init()" and "gc_term()". You
 might also need to call "gc.disable()" or something (don't really
 remember). And then if you still want to use "new" and/or "delete"
 with your own memory manager, you can use D's class allocator and
 deallocator feature
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume 
 you
 could probably plug those class allocators/deallocators directly 
 into
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the
 implementation. Let's face it, I'm not going to use D since it 
 doesn't
 offer me anything over C++ that I want. The main thing I may like 
 about
 D is that it makes the effort to make implementation of the language
 easier, and that, I think, is very key. I am here to look for 
 features
 I would put in a new language, though that may be too large of an
 endeavor for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory 
 management
 system, plugging it into D via the methods Robert and I pointed out 
 is
 nothing by comparison.


 If I could do something with the object model, and or if the compiler 
 is
 open source, I would maybe look at the implementation as a potential
 starting point or learning tool. Every time I've considered using
 existing code though, I have ended up just starting with a clean slate
 for a number of reasons. For now, I'm going to evolve my framework a 
 bit
 more and produce some programs. I'm keeping away from "advanced 
 features"
 of existing languages as much as possible so as not to be tied to 
 them.
 So far I've not found problem doing that. Error handling is the worst
 beast that I don't have completely slain yet. Generics and mem mgmt I
 have under control. I feel a bit limited by existing languages object
 models, that's probably the key reason why I'd like to invent a new
 language, be it for my own use or for more widespread use. Having full
 control of a language and it's implementation is nothing to sneeze at
 either, but taking advantage of that probably takes quite a bit of 
 labor
 (more than one developer).

 Tony


 Out of curiosity, what benefits are you going for by using your own 
 memory
 management system instead of just a built-in GC?


 Avoiding yet another black box for one thing. I can't really disclose 
 here
 other reasons.


 translation: "im a 13 yo wannabe cutting my teeth at shit who tries to 
 look interesting on the net."


Or he's under a very strict NDA, or he's researching experimental memory 
management techniques. If you weren't exactly what you're accusing Tony of 
being, you'd have the experience to know that, for bettor or worse, 
ultra-strict NDAs are a common, standard occurance in most of the commercial 
world. I've been under a number of them myself.
Nov 07 2008
parent superdan <super dan.org> writes:
Nick Sabalausky Wrote:


 "superdan" <super dan.org> wrote in message 
 news:gf1rhi$2ors$1 digitalmars.com...

 Tony Wrote:


 "Nick Sabalausky" <a a.a> wrote in message
 news:gevou0$15j4$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message
 news:gevmuc$11hb$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message
 news:gergn9$109b$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message
 news:gerdem$rc4$1 digitalmars.com...

 "Nick Sabalausky" <a a.a> wrote in message
 news:gep0ej$232$1 digitalmars.com...

 "Tony" <tonytech08 gmail.com> wrote in message
 news:geogvj$1p5r$2 digitalmars.com...

 "Robert Fraser" <fraserofthenight gmail.com> wrote in message
 news:geo5p6$12gk$1 digitalmars.com...

 Tony wrote:

 (one HAS to use GC with D, right?)


 No. Well, the compiler generates calls to allocate & free memory,
 but you can replace those calls with whatever you want. See 
 Tango's
 (druntime's) "stub" GC, which just reroutes compiler-generated 
 calls
 to GC methods to malloc() and free(). You can implement your own
 "GC" or whatever management scheme you want (in fact, if you're
 writing, say, a device driver in D, you would want to use a 
 custom
 allocator like this and not the built-in GC).


 Please clarify for me the mem mgmt of D: is the garbage collector
 optional or not?


 Yes, it can be ripped out, replaced, whatever. It's slightly hacky,
 but it's perfectly doable. I did it a few years ago when I was 
 playing
 around with using GDC with DevKitARM for GBA.

 IIRC, you just go into "extern (C) int main(size_t argc, char 
 **argv)"
 in the internal portion of phobos/tango/druntime or wherever it 
 lives
 now and comment-out the calls to "gc_init()" and "gc_term()". You
 might also need to call "gc.disable()" or something (don't really
 remember). And then if you still want to use "new" and/or "delete"
 with your own memory manager, you can use D's class allocator and
 deallocator feature
 (http://www.digitalmars.com/d/1.0/class.html#allocators). I assume 
 you
 could probably plug those class allocators/deallocators directly 
 into
 the internal object class if you wanted.


 It sounds like a lot of work and new stuff to learn about the
 implementation. Let's face it, I'm not going to use D since it 
 doesn't
 offer me anything over C++ that I want. The main thing I may like 
 about
 D is that it makes the effort to make implementation of the language
 easier, and that, I think, is very key. I am here to look for 
 features
 I would put in a new language, though that may be too large of an
 endeavor for someone my age.

 Tony


 If you've already got your own full-fleged, reliable, memory 
 management
 system, plugging it into D via the methods Robert and I pointed out 
 is
 nothing by comparison.


 If I could do something with the object model, and or if the compiler 
 is
 open source, I would maybe look at the implementation as a potential
 starting point or learning tool. Every time I've considered using
 existing code though, I have ended up just starting with a clean slate
 for a number of reasons. For now, I'm going to evolve my framework a 
 bit
 more and produce some programs. I'm keeping away from "advanced 
 features"
 of existing languages as much as possible so as not to be tied to 
 them.











 So far I've not found problem doing that. Error handling is the worst
 beast that I don't have completely slain yet. Generics and mem mgmt I
 have under control. I feel a bit limited by existing languages object
 models, that's probably the key reason why I'd like to invent a new
 language, be it for my own use or for more widespread use. Having full
 control of a language and it's implementation is nothing to sneeze at
 either, but taking advantage of that probably takes quite a bit of 
 labor
 (more than one developer).

 Tony


 Out of curiosity, what benefits are you going for by using your own 
 memory
 management system instead of just a built-in GC?


 Avoiding yet another black box for one thing. I can't really disclose 
 here
 other reasons.


 translation: "im a 13 yo wannabe cutting my teeth at shit who tries to 
 look interesting on the net."


 
 Or he's under a very strict NDA, or he's researching experimental memory 
 management techniques. If you weren't exactly what you're accusing Tony of 
 being, you'd have the experience to know that, for bettor or worse, 
 ultra-strict NDAs are a common, standard occurance in most of the commercial 
 world. I've been under a number of them myself. 


yeah. worked in hw design a long time. there ndas and all legal shit r tougher
n easier to enforce. patent law applies keener to material shit. "accusing" is
a bit much. just inferred an assessment based on ton's many other preposterous
remarks. & his reaction when given attention.

ton may be working on googles next weird project fer all i know. assuming
googles next weird project is a small one dood project given to an
inexperienced youngster who don't compile in months don't know c++ macros suck
don't ever runs into compilation time shit don't know processor speed hit a
wall years ago don't understand dbc don't understand const don't understand
modules don't understand what gc is good at. but has an opinion on all of the
above. i suspect his nda has somethin' 2 do with mum suspending cookie rights.

but hang on. sure there's more fun stuff where that came from. my second fave
after "don't compile in mos" is "i know too much about c++ to move do d and
relearn stuff". this teen looks at spendin' his 401k golfing in peace already.
Nov 07 2008