On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
> On Wednesday, 21 August 2013 at 17:45:29 UTC, Ramon wrote:
>>> Moor's law is kaput, finish, niet, we don't know how to use the extra transistor.
>>
>> Even if that were true, we have gone quite some distance. Not even talking about Sparc T4 or 8-core X86, my smartphone is more powerful than what I had as computer 10 years or so ago.
>>
>
> Just read this this : ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come back informed.
>
>>> A vast amount of software is written in javascript, java, C#, PHP and many "safe" languages, and still are crippled with bugs.
>>
>> Do I get you right considering js, java, C# and PHP being "safe" languages?
>>
>
> They are dramatically superior to C in term of safety.
>

Like Modula-2, Pascal dialects (mainly Turbo/Apple Pascal) and
Ada are, but lost their place in developer's hearts.

Now with D, Rust and even Go we can have another go at making
system programming a better world.

--
Paulo

On 08/21/2013 07:12 PM, Andrei Alexandrescu wrote:
>
> The deduper would be insensitive to alpha renaming, e.g. "int a = 10;"
> and "int b = 10;" would be identical.

This is not alpha renaming, it is just renaming. :o)

Eg. "{int a = 10; foo(a);}" and "{int b = 10; foo(b);}" would be identical.

On 08/21/2013 07:17 PM, deadalnix wrote:
>
> You want no bugs ? Go for Haskell.

If you want no bugs, go for formal correctness proof.

> But you'll get no convenience

Yes you do. A lot.

> or performance.

Let's say "easily predictable performance".

> The good thing if that if it does compile, you are pretty
> sure that it does the right thing.

On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
> As for generics, let me put it this way:
> In Eiffel generics have been an integral part of the language design from the beginning. In D ways and mechanisms are provided to achieve what quite usually is the goal of generics, namely generic algorithms in way, i.e. by having to write code for an algorithm just once. That might seem to be a minor difference, in particular when looking from a "Huh? I can get it done, so what's the fuss all about, eh?" perspective.
> Of course, there the C and successors worlds proponents are right, this incurs a price (which templates do, too ...) and, yes, in the end, somewhere someone or something must sort the types out anyway (because of the way CPUs work).

There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach.

Longer form: http://beza1e1.tuxen.de/articles/generics.html

An interesting twist would be to use type erasure for reference types and instantiation for value types. Another idea could be to use instantiation selectively as an optimization and erasure in general.

> Another example is data types, concretely integers. Ada offers a nice way do precisely nail down precision/storage. If I want to store days_of_month I can have an integer type holding ints between 1 and 31 (which, due to the way they implemented it can be a PITA). Eiffel gives me something quite similar (in a more elegant way) and additionally a "dumb" INTEGER (32 or 64 bit) and than a gazillion subtypes like "INTEGER_16". That's great because in a quick and dirty script a plain integer (max size of CPU) is good enough and keeps life simple. If I need days_of_month I can very easily have that as int type.

In D you can use structs:

  struct days_of_month {
    int day;
    /* fill in operator overloading etc */
  }

On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
> On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
>> As for generics, let me put it this way:
>> In Eiffel generics have been an integral part of the language design from the beginning. In D ways and mechanisms are provided to achieve what quite usually is the goal of generics, namely generic algorithms in way, i.e. by having to write code for an algorithm just once. That might seem to be a minor difference, in particular when looking from a "Huh? I can get it done, so what's the fuss all about, eh?" perspective.
>> Of course, there the C and successors worlds proponents are right, this incurs a price (which templates do, too ...) and, yes, in the end, somewhere someone or something must sort the types out anyway (because of the way CPUs work).
>
> There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach.
>
> Longer form: http://beza1e1.tuxen.de/articles/generics.html
>
> An interesting twist would be to use type erasure for reference types and instantiation for value types. Another idea could be to use instantiation selectively as an optimization and erasure in general.

Which is the way .NET does it.

http://blogs.msdn.com/b/carlos/archive/2009/11/09/net-generics-and-code-bloat-or-its-lack-thereof.aspx


>
>> Another example is data types, concretely integers. Ada offers a nice way do precisely nail down precision/storage. If I want to store days_of_month I can have an integer type holding ints between 1 and 31 (which, due to the way they implemented it can be a PITA). Eiffel gives me something quite similar (in a more elegant way) and additionally a "dumb" INTEGER (32 or 64 bit) and than a gazillion subtypes like "INTEGER_16". That's great because in a quick and dirty script a plain integer (max size of CPU) is good enough and keeps life simple. If I need days_of_month I can very easily have that as int type.
>
> In D you can use structs:
>
>   struct days_of_month {
>     int day;
>     /* fill in operator overloading etc */
>   }

Thanks for the Eiffel info.

On Wednesday, 21 August 2013 at 17:48:49 UTC, Andrei Alexandrescu wrote:
> No random access. I didn't know about drop-last though - does it work in O(1)?

There is "nth" <http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/nth> but the O(n) cited there is rather disturbing.

> More accurately was the point that Clojure's sequence API is (to the best of my understanding) only dealing with forward access, whereas D distinguishes between one-pass, forward, bidirectional, and random, and designs algorithms around these notions.

I'll check up with my friend on the forward access side.  What certainly seems to be true is that the API doesn't make the useful distinctions/classifications that D does.

On Thursday, 22 August 2013 at 02:06:13 UTC, Tyler Jameson Little wrote:
> - array operations (int[] a; int[]b; auto c = a * b;)
>   - I don't think these are automagically SIMD'd, but there's always hope =D

That isn't allowed. The memory for c must be pre-allocated, and the expression then becomes c[] = a[] * b[];

Is it SIMD'd?

It depends. There is a whole load of hand-written assembler for simple-ish expressions on builtin types, on x86. x86_64 is only supported with 32bit integer types because I haven't finished writing the rest yet...

However, I'm not inclined to do so at the moment as we need a complete overhaul of that system anyway as it's currently a monster*.  It needs to be re-implemented as a template instantiated by the compiler, using core.simd. Unfortunately it's not a priority for anyone right now AFAIK.


*
hand-written asm loops. If fully fleshed out there would be:
  ((aligned + unaligned + legacy mmx) * (x86 + x64) + fallback loop)
  * number of supported expressions * number of different types
of them. Then there's unrolling considerations. See druntime/src/rt/arrayInt.d

On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
> On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
>> As for generics, let me put it this way:
>> In Eiffel generics have been an integral part of the language design from the beginning. In D ways and mechanisms are provided to achieve what quite usually is the goal of generics, namely generic algorithms in way, i.e. by having to write code for an algorithm just once. That might seem to be a minor difference, in particular when looking from a "Huh? I can get it done, so what's the fuss all about, eh?" perspective.
>> Of course, there the C and successors worlds proponents are right, this incurs a price (which templates do, too ...) and, yes, in the end, somewhere someone or something must sort the types out anyway (because of the way CPUs work).
>
> There are basically two ways to implement generics. Type erasure (Java,Haskell) or template instantiation (C++,D). Instantiation provides better performance, but sacrifices error messages (fixable?), binary code size, and compilation modularity (template implementation must be available for instantiation). Type safety is not a problem in either approach.
>
> Longer form: http://beza1e1.tuxen.de/articles/generics.html
>
> An interesting twist would be to use type erasure for reference types and instantiation for value types. Another idea could be to use instantiation selectively as an optimization and erasure in general.
>
>> Another example is data types, concretely integers. Ada offers a nice way do precisely nail down precision/storage. If I want to store days_of_month I can have an integer type holding ints between 1 and 31 (which, due to the way they implemented it can be a PITA). Eiffel gives me something quite similar (in a more elegant way) and additionally a "dumb" INTEGER (32 or 64 bit) and than a gazillion subtypes like "INTEGER_16". That's great because in a quick and dirty script a plain integer (max size of CPU) is good enough and keeps life simple. If I need days_of_month I can very easily have that as int type.
>
> In D you can use structs:
>
>   struct days_of_month {
>     int day;
>     /* fill in operator overloading etc */
>   }


Thank you.

Well in an OO language the actual type(s) is/are known. So real genericity boils done to whether an object has the required functions or not.

D has, obviously piously following the C++ way (which can be a good thing), chosen to go the template way, that is, to handle it compile time. Other languages have chosen to do it runtime which is no worse or better per se but happens to be more consistent with OO.

Some here argued that, well, in the end, say, a simple int and a bank account, need different data types and operations because it matters to CPUs whether it does sth. with a DWORD or a char[]. And, so they argued, therefore you have to pay a runtime penalty for real generics. I don't think so.
Sure, one evidently pays a penalty for OO in general (as opposed to simple scalars). But it's not the genericity that costs.

Last but not least, there simply isn't a either/or issue. Once can perfectly well have both. And no, that doesn't necessarily bring a performance penalty with it.

Another point of view that doesn't match precisely but may help to understand it is this:

True OOP is basically about "It's the *data*!" while systems programming understandably is closer to "it's the *code*!"
Where the former has data "carrying the operations with them" the latter has data as something that is fed in and processed and spit out by the machinery. And it's that what brings up the question "Well, but how would the CPU know what kind of data it's working on? That requires expensive extra steps".

Again, for systems programming that's just fine. But the whole penalty assumption largely stems from looking at true OOP through the C/C++ model.

On Thursday, 22 August 2013 at 12:37:50 UTC, Ramon wrote:
> Well in an OO language the actual type(s) is/are known. So real genericity boils done to whether an object has the required functions or not.
>

Polymorphism say no, you don't know the actual type, and this is the whole point of OOP : being able to interact with object of various type as long as they provide the needed interface to interact with.

> D has, obviously piously following the C++ way (which can be a good thing), chosen to go the template way, that is, to handle it compile time. Other languages have chosen to do it runtime which is no worse or better per se but happens to be more consistent with OO.
>

D recognize that OO isn't the only paradigm on earth. And generic won't work with non OO code.

> Some here argued that, well, in the end, say, a simple int and a bank account, need different data types and operations because it matters to CPUs whether it does sth. with a DWORD or a char[]. And, so they argued, therefore you have to pay a runtime penalty for real generics. I don't think so.
> Sure, one evidently pays a penalty for OO in general (as opposed to simple scalars). But it's not the genericity that costs.
>

Indirections, opaque calls, and heap allocation are probably the 3 first performance killers on modern architecture. OO embrace the 3 of them.

> True OOP is basically about "It's the *data*!" while systems programming understandably is closer to "it's the *code*!"
> Where the former has data "carrying the operations with them" the latter has data as something that is fed in and processed and spit out by the machinery. And it's that what brings up the question "Well, but how would the CPU know what kind of data it's working on? That requires expensive extra steps".
>

No true OOP is about behavioral abstraction. See Liskov's substitution principle. Data is merely a tool and OOP promote its encapsulation. In other term, data is an implementation detail in OOP.

> Again, for systems programming that's just fine. But the whole penalty assumption largely stems from looking at true OOP through the C/C++ model.

The whole penalty assumptions come from how actual compilers and CPU works. If you have new idea to revolution both and change the deal, great, but I highly doubt so.

On Thursday, 22 August 2013 at 05:22:17 UTC, deadalnix wrote:
> Just read this this : ftp://ftp.cs.utexas.edu/pub/dburger/papers/ISCA11.pdf and come back informed.

Well, I can give you a link to some paper that says that the world will break down and stop next tuesday. Interested?

>>> A vast amount of software is written in javascript, java, C#, PHP and many "safe" languages, and still are crippled with bugs.
>>
>> Do I get you right considering js, java, C# and PHP being "safe" languages?
>>
>
> They are dramatically superior to C in term of safety.

I know "bridges" in Siberia that are vastly superior to bridges in the Andes. Frankly, I'd prefer to use a european bridge.
And one *can* be in the C/C++ family and have a vastly safer system. Look at D.

>>> Some codebase are trully scary. Look at gdb's source code or gtk's.
>>
>> Written in C/C++ ...
>>
>
> Well look at phpBB's source code then. Horrible codebase isn't language specific.

So? Is this a "who knows most programs with lousy coding?" contest?

All I see there is that programmers, in particular hobby hackers will spot - and use - any chance to wildly shoot around unless they are mildly (or less mildly) guided by a sound and safe system.

And I see (and confess for myself) that even seasoned programmers can very much profit from a system that makes it easier to do the right thing and harder to do the wrong thing.

>>> You want no bugs ? Go for Haskell. But you'll get no convenience or performance. The good thing if that if it does compile, you are pretty sure that it does the right thing.
>>
>> Why should I? Isn't that what D promises, too (and probably is right)?
>>
>
> D promise a pragmatic balance between safety, performance, ease of use, productivity, etc . . .

Well, being a systems programming language D is condemned to keep quite some doors open. It seems (as far as I can that now) however to have done an excellent job in terms of safety (give or take some minor sins like '=' as assignment).

One might put Java against D. But frankly, I do not consider Javas approach "Subdue them with pervert bureaucracy, hehe" approach as acceptable (and it creates a whole set of problems, too).

Frankly, if I had to work on a highly safety critical and reliable project (say in the medical area) I would have a hard time to spot just 5 languages that I would consider. Ada comes to mind (but I don't like it) and Eiffel, which is great but that great pragmatically. I'm afraid I'd end up where I ended up in the first place: Eiffel vs. D.

I'm probably not counted as a happy D protagonist around here but I'd happily state that D is way ahead of 99% of the known languages. And that expressly includes safety.

>> On another perspective: Consider this question "Would you be willing to have all your software (incl. OS) running 10% or even 20% slower but without bugs, leaks, (unintended) backdoors and the like?"
>>
>> My guess: Upwards of 80% would happily chime "YES!".
>
> Would you accept it if it means a 3x slowdown and no real time capabilities (no video games for instance) ?

I refuse to answer that because it's way out of reality.