On Sunday, 14 August 2016 at 18:57:14 UTC, ZombineDev wrote:
> Ok, maybe it's a matter of taste and opinion, but I consider them to be bad design (idea-wise, not implementation-wise) because they're sort of the opposite of DbI and compile-time duck-typing. Maybe they fit nicely in Rust's world but they're definitely something I would want NOT to use. Concepts/traits are useless when you have DbI, because you can implement them in a library if you need dynamic dispatch (e.g. std.range.InputRangeObject, std.experimental.allocator.allocatorObject, std.typecons.wrap, etc.).

Can you demonstrate it through the example you linked to?

And sorry, what's DbI again? :D

On Sunday, 14 August 2016 at 23:50:23 UTC, Enamex wrote:
> On Sunday, 14 August 2016 at 18:57:14 UTC, ZombineDev wrote:
>> Ok, maybe it's a matter of taste and opinion, but I consider them to be bad design (idea-wise, not implementation-wise) because they're sort of the opposite of DbI and compile-time duck-typing. Maybe they fit nicely in Rust's world but they're definitely something I would want NOT to use. Concepts/traits are useless when you have DbI, because you can implement them in a library if you need dynamic dispatch (e.g. std.range.InputRangeObject, std.experimental.allocator.allocatorObject, std.typecons.wrap, etc.).
>
> Can you demonstrate it through the example you linked to?
>
> And sorry, what's DbI again? :D

Well, I guess it would hard for me to convince you if you don't know what Design by Introspection means. Truth be told, when I started learning D I also thought that concepts were the best idea thing ever (I was coming from C++ background, though I didn't have much experience with template metaprogramming), and by extension Rust's traits. It was perhaps after one or two years of using D, reviewing Phobos pull requests and watching Andrei's talk at DConf 2015 that I was finally convinced that concepts / traits are something not worth having.
This is one those things that need time to sink in. Just like understanding that classic OOP is not the solution to all problems and that maybe functional programming is something worth looking into (i.e. it's not some academic nonsense).

On Mon, 15 Aug 2016 06:43:11 +0000, ZombineDev wrote:
> Well, I guess it would hard for me to convince you if you don't know what Design by Introspection means.

Some years ago I was on #d on freenode and someone made a reference to high-order functions. I hadn't encountered the term, so I asked about it. The person answered that if I didn't know what it meant, I must not use high-order functions.

In point of fact I was making moderate use of high-order functions at that time, but I hadn't heard that term for it. There is a difference between knowing how to do a thing and knowing a specific term for that thing.

You still haven't defined the term "design by introspection". Some searching around says it's the pattern of:

template Foo(T) {
  static if (is(typeof(T.bar)) {
    // preferred implementation takes advantage of T.bar
  } else {
    // alternate (also correct) implementation
  }
}

For instance, if T is an allocator and it has a `realloc` method, the preferred implementation, which uses `realloc`, will be chosen. Otherwise, the alternate implementation (which might use a linked list to avoid reallocating) will be chosen.

The term was coined by Andrei, and he's had a couple talks about it, but nothing around here in the past few months.

This pattern is handy for certain types of library code. It's not something that I have much use for.

On Monday, 15 August 2016 at 14:40:14 UTC, Chris Wright wrote:
> You still haven't defined the term "design by introspection". Some searching around says it's the pattern of:
>
> template Foo(T) {
>   static if (is(typeof(T.bar)) {
>     // preferred implementation takes advantage of T.bar
>   } else {
>     // alternate (also correct) implementation
>   }
> }
>
> For instance, if T is an allocator and it has a `realloc` method, the preferred implementation, which uses `realloc`, will be chosen. Otherwise, the alternate implementation (which might use a linked list to avoid reallocating) will be chosen.

There are is a ton of examples in Phobos, especially in std.algorithm or std.range:

https://github.com/dlang/phobos/tree/master/std/algorithm
https://github.com/dlang/phobos/tree/master/std/range

The DTour also has a small Gem about it:

http://tour.dlang.io/tour/en/gems/traits

On Sunday, 14 August 2016 at 18:05:12 UTC, ZombineDev wrote:
> Rust stugg

Exactly what I was after, thanks.

On Saturday, 13 August 2016 at 19:34:42 UTC, Walter Bright wrote:
> It's risky to compare with languages you aren't strongly familiar with. All it takes is one mistake and one audience member who knows more than you about it, and it can seriously derail and damage the entire presentation.
>
> I recommend sticking with describing the unique D features, and let the audience members who know other languages draw their own comparisons.

I do agree with this.

But by the same token, the table highlights what actually are the unique D features. I make a point that the languages themselves are reasonable enough replacements for C++ in many circumstances, but that the things I do with D's compile time functionality aren't easily achievable in those languages.

At this point, the only thing I still haven't found concrete information on is function inspection in Swift and Rust, which should be a mark against the languages if it's not easily Googlable.

On 2016-08-16 08:13, Ethan Watson wrote:

> At this point, the only thing I still haven't found concrete information
> on is function inspection in Swift and Rust, which should be a mark
> against the languages if it's not easily Googlable.

For Objective-C it's possible to use the Objective-C runtime functions to access some of this information. Based on a method you can access the types of the arguments and the return type. Although this data is represented as strings, in a semi mangled format. All this should be accessible in Swift as well but will only (I assume) work for Swift methods that can be called from Objective-C. "Native" Swift methods support other features that are not accessible in Objective-C, like generics.

-- 
/Jacob Carlborg

On Tuesday, 16 August 2016 at 06:36:25 UTC, Jacob Carlborg wrote:
> On 2016-08-16 08:13, Ethan Watson wrote:
>
> For Objective-C it's possible to use the Objective-C runtime functions to access some of this information. Based on a method you can access the types of the arguments and the return type. Although this data is represented as strings, in a semi mangled format. All this should be accessible in Swift as well but will only (I assume) work for Swift methods that can be called from Objective-C. "Native" Swift methods support other features that are not accessible in Objective-C, like generics.

Yeah, this is what I thought was possible with Swift. So thanks for that.

On Monday, 15 August 2016 at 14:40:14 UTC, Chris Wright wrote:
> You still haven't defined the term "design by introspection". Some searching around says it's the pattern of:
>
> template Foo(T) {
>   static if (is(typeof(T.bar)) {
>     // preferred implementation takes advantage of T.bar
>   } else {
>     // alternate (also correct) implementation
>   }
> }
>
> For instance, if T is an allocator and it has a `realloc` method, the preferred implementation, which uses `realloc`, will be chosen. Otherwise, the alternate implementation (which might use a linked list to avoid reallocating) will be chosen.

Strategy pattern at compile time.

On Tuesday, 16 August 2016 at 06:13:18 UTC, Ethan Watson wrote:
>
> [snip]
>
> At this point, the only thing I still haven't found concrete information on is function inspection in Swift and Rust, which should be a mark against the languages if it's not easily Googlable.

From what I could find, definitely no other language from the list than C++ and D provides any sort of compile-time reflection. Between C#, Swift and Rust, C# has the most mature and fully-featured runtime reflection support. Almost every major .NET framework makes heavy use of it. I have even seen it casually used in combination with System.Reflection.Emit [1] for runtime codegen (for efficient DataBinding or FFI to native libraries, when P/Invoke is not enough). Because of the nature of CLR's JIT the difference between CT and RT is quite fuzzy. This even makes for some twisted form of `static if` [2.1] (look for the use of `if (typeof(T) == typeof(Int32))` in the code [2.2]). Though the actual code gen and optimization is treated like an implementation detail - I don't think it is guaranteed in any way.

The only thing that I could find about Rust is that they didn't want to support any reflection beyond `typeid` [3] , because apparently that bloated binaries too much and such cost was too much for every project to pay. `typeid` is used by their `Any` trait [4] which basically is used for dynamic casting. From what I understand, you can't even tell at runtime if an object implements a trait. All you can do is use object.is::<T>() to check if the object is of some concrete type.

Swift developers, on the other hand, explicitly state that they don't want to support any form compile-time metaprogramming: [5]. Ironically they make heavy use of it in their standard-library. However instead of writing the meta code in Swift, they use Python [6] for some weird variant of .NET's T4 preprocessor templates [7]. As for runtime reflection, as Jacob said, you can leverage the Objective-C heritage if your classes derive from `NSObject` [8]. Otherwise, due to the needs of things like XCode's Playground (which btw, is a poor imitation of Bret Victor's ideas [9]), Swift 2 also features some new runtime reflection capabilities [10] [11].

[1]: https://msdn.microsoft.com/en-us/library/system.reflection.emit(v=vs.110).aspx
[2.1]: https://github.com/dotnet/corefx/blob/v1.0.0/src/System.Numerics.Vectors/src/System/Numerics/Vector.tt#L17
[2.2]: https://github.com/dotnet/corefx/blob/v1.0.0/src/System.Numerics.Vectors/src/System/Numerics/Vector.cs#L95
[3]: http://stackoverflow.com/questions/36416773/how-does-rust-implement-reflection
[4]: https://github.com/rust-lang/rust/blob/master/src/libcore/any.rs
[5]: https://github.com/apple/swift/blame/master/docs/Generics.rst#L85
[6]: https://github.com/apple/swift/blob/swift-DEVELOPMENT-SNAPSHOT-2016-08-15-a/stdlib/public/core/FloatingPoint.swift.gyb#L1485
[7]: https://msdn.microsoft.com/en-us/library/bb126445.aspx
[8]: http://stackoverflow.com/a/24072677
[9]: http://worrydream.com/LearnableProgramming/
[10]: https://developer.apple.com/library/tvos/documentation/Swift/Reference/Swift_Mirror_Structure/index.html
[11]: https://appventure.me/2015/10/24/swift-reflection-api-what-you-can-do/