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. Even C#'s creators are talking about adopting its features <g>.
Nov 01 2008
prev 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
next sibling 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 C++ in *all* of C++'s use-cases. C# and Java, for instance, are only partial 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 suitable replacement for C++ in *all* of C++'s use-cases. C# and Java, 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
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 suitable replacement for C++ in *all* of C++'s use-cases. C# and Java, 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, (X)HTML, XML, CSS, and either PHP, ASP/VBScript, ASP.NET/C#, 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.
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 suitable replacement for C++ in *all* of C++'s use-cases. C# and Java, 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, 
 (T)SQL, (X)HTML, XML, CSS, and either PHP, ASP/VBScript, ASP.NET/C#, 
 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?)

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.

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?)

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).

optional or not?

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.

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

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?)

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).

optional or not?

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.

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

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.
 

"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


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 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.

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, 
 (X)HTML, XML, CSS, and either PHP, ASP/VBScript, ASP.NET/C#, 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 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, 
 (T)SQL, (X)HTML, XML, CSS, and either PHP, ASP/VBScript, ASP.NET/C#, 
 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: #1: In the commercial world there are a lot of times when you, as the 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). #2: You have basically no control over the client-side environment, so for 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 we've been starting to see in languages like D, C#, Python and Ruby, using an API for any non-trivial queries could potentially get ugly.
Nov 03 2008
next 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:
 
 #1: In the commercial world there are a lot of times when you, as the 
 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).
 

 #2: You have basically no control over the client-side environment, so for 
 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 
 we've been starting to see in languages like D, C#, Python and Ruby, using 
 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 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 "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), particularly if ASP/VBScript, ASP.NET/VB.NET, and ASP.NET/C# backends are 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 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, 
 (X)HTML, XML, CSS, and either PHP, ASP/VBScript, ASP.NET/C#, 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).
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).

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, 
 (T)SQL, (X)HTML, XML, CSS, and either PHP, ASP/VBScript, ASP.NET/C#, 
 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

rotting flesh never seems to die. It lives by eating the brains of C programmers. ~ Clay

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 C++ in *all* of C++'s use-cases. C# and Java, for instance, are only partial replacements. They can handle many of C++'s uses, but not all.)

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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling parent 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