On Saturday, February 11, 2012 18:01:05 Nick Sabalausky wrote:
> But not all slices are slices of dynamic arrays.

But all slices are still dynamic arrays, even if they refer to a static array. They just have a capacity of 0, so any appending will result in them being reallocated. And slicing static arrays is one of those things that you generally have to be careful about precisely because they aren't managed by the GC and can go out of scope before their slices do.

> Yea, manual memory management is hard and you have to be careful. That's true slices or not.

Yes, but in this case, you're dealing with a language feature which is _designed_ to be managed by the GC. It's not designed for manual memory management at all. It's a completely different situation when you're dealing with user-defined types.

> Arrays knowing their own length *is* a notable improvement over C.

Indeed, but that's pretty much the only improvement that D makes to arrays which is safe to use without a GC without being _very_, _very_ careful.

- Jonathan M Davis

On Sunday, 12 February 2012 at 00:29:35 UTC, Jonathan M Davis wrote:
> On Saturday, February 11, 2012 18:01:05 Nick Sabalausky wrote:
>> But not all slices are slices of dynamic arrays.
>
> But all slices are still dynamic arrays, even if they refer to a static array. They just have a capacity of 0, so any appending will result in them being reallocated. And slicing static arrays is one of those things that you generally have to be careful about precisely because they aren't managed by the GC and can go out of scope before their slices do.
>
>> Yea, manual memory management is hard and you have to be careful. That's
>> true slices or not.
>
> Yes, but in this case, you're dealing with a language feature which is _designed_ to be managed by the GC. It's not designed for manual memory management at all. It's a completely different situation when you're dealing with user-defined types.
>
>> Arrays knowing their own length *is* a notable improvement over C.
>
> Indeed, but that's pretty much the only improvement that D makes to arrays which is safe to use without a GC without being _very_, _very_ careful.
>
> - Jonathan M Davis

Btw, I'm not very fluent in the inner workings of a garbage collector implementation but how does one go about concatenating to an array in a garbage collector as compared to manual memory management? I believe array concatenation can be done in std::vector with the insert() function just fine. Isn't it as simple as determining both array sizes and allocating enough memory for both arrays? I could be oversimplifying things...

On Sunday, February 12, 2012 01:40:50 Zachary Lund wrote:
> Btw, I'm not very fluent in the inner workings of a garbage collector implementation but how does one go about concatenating to an array in a garbage collector as compared to manual memory management? I believe array concatenation can be done in std::vector with the insert() function just fine. Isn't it as simple as determining both array sizes and allocating enough memory for both arrays? I could be oversimplifying things...

Read this:

http://www.dsource.org/projects/dcollections/wiki/ArrayArticle

Appending to vectors is very different from appending to dynamic arrays because dynamic arrays do _not_ own their own memory (the GC does) and not only could other slices refer the same memory (in which case, you can't just free that memory when an array gets reallocated due to running out of space to append to), but they could already refer to the memory one past the end of the array, making it so that it can't expand into that memory.

Slices change the entire equation. And the way slices are designed, they require the GC.

- Jonathan M Davis

On 02/11/2012 09:19 AM, Paulo Pinto wrote:
> Am 11.02.2012 18:00, schrieb bcs:
>> On 02/11/2012 12:58 AM, Paulo Pinto wrote:
>>> Specially since systems programming in MacOS X and Windows world is
>>
>> Systems programming in the MacOS X and Windows world isn't real systems
>> programming. The closest you get is kernel and driver work but even
>> there you have most of an OS to work with. I think the kind of systems
>> programming being considered is embedded work and/or things like BIOS
>> work.
>
>
> Systems programming is everything you need to get an OS up and running.
> At least it was so a few decades back when I attended computer science
> and informatics engineering course.
>

OK then there may be some people doing systems programming for MacOS X and Windows, but they all work for Apple and MS.

> Regarding embedded and BIOS work, many systems being used today still
> required a custom C compiler without full ANSI C support, so how would
> such systems support a D- implementation?
>
> --
> Paulo

Am 12.02.2012 03:03, schrieb bcs:
> On 02/11/2012 09:19 AM, Paulo Pinto wrote:
>> Am 11.02.2012 18:00, schrieb bcs:
>>> On 02/11/2012 12:58 AM, Paulo Pinto wrote:
>>>> Specially since systems programming in MacOS X and Windows world is
>>>
>>> Systems programming in the MacOS X and Windows world isn't real systems
>>> programming. The closest you get is kernel and driver work but even
>>> there you have most of an OS to work with. I think the kind of systems
>>> programming being considered is embedded work and/or things like BIOS
>>> work.
>>
>>
>> Systems programming is everything you need to get an OS up and running.
>> At least it was so a few decades back when I attended computer science
>> and informatics engineering course.
>>
>
> OK then there may be some people doing systems programming for MacOS X
> and Windows, but they all work for Apple and MS.

So do you mean everyone doing device driver development are also working
for them?

As well as all the companies writing services/daemons with low level protocols for optimal perfomance?



--
Paulo

Am 11.02.2012 15:46, schrieb Nick Sabalausky:
> "Paulo Pinto"<pjmlp@progtools.org>  wrote in message
> news:jh5aip$1qma$1@digitalmars.com...
>>
>> I don't see the point.
>>
>> C++ was the last systems programming language without GC getting market
>> share. I seriously doubt any new systems programming language without GC
>> will ever suceed.
>>
>
> You're looking at it backwards. The whole point is for places where you
> wouldn't want GC. Those people are currently limited to the rotting,
> antiquated C and...that's about it. Nobody said this "D-" would need to take
> over the world. It can still succeed in a niche, and that niche is the whole
> point here.
>
>> Specially since systems programming in MacOS X and Windows world is
>
> Nobody's talking about Mac and Windows here.
>
>> So sum this up. If you need a languague without GC, C and C++ are quite
>> good,
>
> That's laughable. C and C++ are convoluted anachronistic crap. The only
> reason anyone still uses them is because 99.99% of language designers feel
> the way you do, and as a reasult, C/C++ remain the *only* options for
> certain uses.


The reason being that if you remove the GC, then you end up with some kind of C, C++, Pascal or Ada flavour, because there is only so much you
can do without a GC.

So in the end you just get an already existing language, but with different syntax.

So it is not worth the effort designing such languages.

More to the point, research has proven that system programming languages with GC is possible, they have yet not become mainstream because for a systems programming language to become mainstream it has to be choosen from a major OS company.

One of the things I like in D is that it really feels like Sing#, the C#
Singularity version but open source.

--
Paulo

Am 11.02.2012 16:32, schrieb Daniel Murphy:
> This is actually probably not that difficult to do.
>
> A C backend for dmd would be quite difficult to make - but if you strip out
> most of the complex features that make it to code generation (exceptions,
> garbage collected memory, tls, classes, array ops, threading, floating
> point, typeinfo, destructors, postblits etc) then the actual code generated
> doesn't need to be that complex.

If you remove all of that then how good would D- be in regard with existing languages being used for the same tasks?

For example, MikroEletronica sells C, Basic and Pascal compilers that target everything from a small PIC up to big ARMs.

http://www.mikroe.com/eng/products/view/754/mikropascal-pro-for-arm/

I can also get Ada for embedded systems programming, which was actually
one of Ada's design goals,
http://www.adacore.com/home/products/gnatpro/development_solutions/embedded/?gclid=CJ-7yNeImK4CFUGIDgodXT4CJQ

So what does D- bring to the table, besides fragmenting the community?

--
Paulo

Am 11.02.2012 19:50, schrieb Andrei Alexandrescu:
> On 2/11/12 12:07 PM, H. S. Teoh wrote:
>> On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:
>>> On 2/11/12 8:48 AM, Nick Sabalausky wrote:
>> [...]
>>>> I absolutely agree: We've learned a very hard lession from the
>>>> community-fragmenting failure that was known as SafeD.
>>>
>>> Not sure what you mean there. As far as I can tell SafeD did not fail
>>> and there was no community fragmentation at any point because of it.
>> [...]
>>
>> AFAIK, SafeD is just incompletely implemented, right? But it exists and
>> it will be done one day.
>
> That is correct. A nicer way to put it is @safe needs more work.
>
> Andrei
>

Andrei, what would be needed to improve it? Just submitting patches to
existing open issues or is some kind of redesign also needed?

--
Paulo

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:jh6daf$1vq7$1@digitalmars.com...
> On 2/11/12 12:07 PM, H. S. Teoh wrote:
>> On Sat, Feb 11, 2012 at 11:55:07AM -0600, Andrei Alexandrescu wrote:
>>> On 2/11/12 8:48 AM, Nick Sabalausky wrote:
>> [...]
>>>> I absolutely agree: We've learned a very hard lession from the community-fragmenting failure that was known as SafeD.
>>>
>>> Not sure what you mean there. As far as I can tell SafeD did not fail and there was no community fragmentation at any point because of it.
>> [...]
>>
>> AFAIK, SafeD is just incompletely implemented, right? But it exists and it will be done one day.
>
> That is correct. A nicer way to put it is @safe needs more work.
>
> Andrei
>

I don't know why people keep saying this.  Most of safeD is implemented as of about six months ago.

"Paulo Pinto" <pjmlp@progtools.org> wrote in message news:jh7v08$2chs$1@digitalmars.com...
> If you remove all of that then how good would D- be in regard with existing languages being used for the same tasks?

You still have all of D's compile-time magic, which I miss every time I need to do embedded programming.  You still have the simple syntax improvement. I would love to be able to do away with the preprocessor and stupidly_long_method_names_because_of_no_overloading_or_method_syntax.


> So what does D- bring to the table, besides fragmenting the community?

No need to fork the lanugage - just add a couple of pragmas and a basic C backend.