November 04, 2008
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).
> 
True. And that's why I search opportunity to get around such limitations.

> #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
November 04, 2008
"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 ;)


November 04, 2008
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.
November 04, 2008
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
November 04, 2008
"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!


November 05, 2008
"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


November 05, 2008
"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.


November 06, 2008
"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


November 06, 2008
"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.


November 06, 2008
"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
>
>