Jump to page: 1 24  
Page
Thread overview
Compare boost::hana to D
Apr 19, 2017
Ali Çehreli
Apr 19, 2017
Nicholas Wilson
Apr 19, 2017
Sebastiaan Koppe
Apr 19, 2017
Kagamin
Apr 19, 2017
Nicholas Wilson
Apr 19, 2017
Laeeth Isharc
Apr 19, 2017
Joakim
Apr 19, 2017
Ali Çehreli
Apr 22, 2017
Walter Bright
Apr 19, 2017
Adrian Matoga
Apr 19, 2017
Sebastiaan Koppe
Apr 19, 2017
Adrian Matoga
Apr 19, 2017
David Gileadi
Apr 19, 2017
Adrian Matoga
Apr 19, 2017
Ali Çehreli
Apr 20, 2017
Adrian Matoga
Apr 20, 2017
Mike Parker
Apr 21, 2017
Mike Parker
Apr 21, 2017
Mike Parker
Apr 21, 2017
Adrian Matoga
Apr 22, 2017
Nicholas Wilson
Apr 21, 2017
Joakim
Apr 21, 2017
Adrian Matoga
Apr 19, 2017
Joakim
Apr 21, 2017
Adam D. Ruppe
Apr 21, 2017
Adrian Matoga
Apr 23, 2017
Jesse Phillips
Apr 22, 2017
Johannes Pfau
Apr 22, 2017
Nicholas Wilson
Apr 24, 2017
Adrian Matoga
Apr 20, 2017
Ali Çehreli
April 19, 2017
I'm brushing up on my C++ to prepare for my C++Now 2017 presentation[1]. boost::hana is an impressive library that overlaps with many D features:

  http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html

Have you used boost::hana? What are your thoughts on it?

And please share your ideas for the presentation. There has been threads here about C++ closing the gap. Does D still bring competitive advantage or is it becoming irrelevant? (Obviously, some think its irrelevant already.) I'm trying to collect opinions... :)

Thank you,
Ali

[1] http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html
April 19, 2017
On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote:
> I'm brushing up on my C++ to prepare for my C++Now 2017 presentation[1]. boost::hana is an impressive library that overlaps with many D features:
>
>   http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html
>
> Have you used boost::hana? What are your thoughts on it?
>
> And please share your ideas for the presentation. There has been threads here about C++ closing the gap. Does D still bring competitive advantage or is it becoming irrelevant? (Obviously, some think its irrelevant already.) I'm trying to collect opinions... :)
>
> Thank you,
> Ali
>
> [1] http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html

Even if it offers comparable features I would show the code it takes to do something (probably slightly non-trivial), the error message you get if you do something wrong and the compile time taken, which I suspect D should win significantly in.
April 19, 2017
On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote:
> Have you used boost::hana? What are your thoughts on it?
>
> And please share your ideas for the presentation. There has been threads here about C++ closing the gap. Does D still bring competitive advantage or is it becoming irrelevant? (Obviously, some think its irrelevant already.) I'm trying to collect opinions... :)

Haven't used C++ for a while actually. And seeing it after some time, makes me tremble convulsively.

While hana is indeed an awesome library it adds another set of things to learn, and it just doesn't compare favourably to D where most is buildin and a lot less ugly.
April 19, 2017
On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote:
> I'm brushing up on my C++ to prepare for my C++Now 2017 presentation[1]. boost::hana is an impressive library that overlaps with many D features:
>
>   http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html
>
> Have you used boost::hana? What are your thoughts on it?
>
> And please share your ideas for the presentation. There has been threads here about C++ closing the gap. Does D still bring competitive advantage or is it becoming irrelevant? (Obviously, some think its irrelevant already.) I'm trying to collect opinions... :)
>
> Thank you,
> Ali
>
> [1] http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html

Hi Ali.

Hope you're well.

I think not enough has been written on D's plasticity - Andrei and Walter talk about it in passing a couple of times.  But I have the impression that it's maybe quite important for merits of D's real world commercial value. Compare using refactoring  tools with not really needing them to same extent.

Something related to that.  I can go back and read my D code from early 2014 when I was learning D and it's all perfectly clear to me.  My python code not so much.  And two of the people working with me on D side have no professional experience in finance, but it didn't take long for them to get up to speed on my project which is maybe 120k SLOC plus some wrapping code.  I didn't have time or bandwidth to write comments or tests yet it was quite feasible to understand code without them.

On the other hand I was reading some object oriented C++ code of 20k lines split between 200 files.  I just about read C++ so ceteris non paribus.  But the fragmentation and artificial abstraction makes it much harder to see what's going on and it's scarier to change it.  Plus template errors in C++! And that 20k lines is maybe 6k lines in 10 files in D.

I haven't always been super happy about using dub on Windows and like Manu said there is an energy gap introducing Windows colleagues to D.  Bad enough from C++, let alone C#.  However dub isn't worse than cmake - porting some windows C++ code to build on linux.

The keynote by the embedded device guy at last years c++ conf was spot on - if you're arguing you're losing.  Why should I use D? Well probably you shouldn't if you don't want to.  In fact in these cases you definitely shouldn't, whether you want to or not.  However some people find its brought them some benefits and here are some if the commonalities.

Some concrete examples that are true and essentially real might be a nice counterpart to the "quicksort in two lines" language evangelism that Andrei rightly complains about.

Maybe you have some from Weka.  Please ask Atila Neves if some finance examples might be helpful.  (Eg excel-d, which I started and Stefan and Atila finished).

One last thing.  D is a pretty good language for getting stuff done quickly in for a prototype that can be cleaned up quickly. That's a point Andy Smith made, and that Liran made in his talk also.  I am having to deal with that increasingly now.  I would certainly much rather turn a D prototype written by a trader into production than a python one - lets not speak of Matlab! This aspect is mentioned on website but should be hammered home - it's a practical language for getting started stuff done fast  without leaving a mess.




April 19, 2017
On Wednesday, 19 April 2017 at 10:58:06 UTC, Laeeth Isharc wrote:
> One last thing.  D is a pretty good language for getting stuff done quickly in for a prototype that can be cleaned up quickly. That's a point Andy Smith made, and that Liran made in his talk also.  I am having to deal with that increasingly now.  I would certainly much rather turn a D prototype written by a trader into production than a python one - lets not speak of Matlab! This aspect is mentioned on website but should be hammered home - it's a practical language for getting started stuff done fast
>  without leaving a mess.

This is a point that keeps coming up, but it is hard to market without people either trying the language or user testimonials.  Would you be able to write up a blog post about this, perhaps along with your D collaborators to fish out some concrete examples from your collective experience, maybe for the D blog?

We tend to focus more on the technical side for the D blog, would be nice to have a post from this development perspective.
April 19, 2017
On Wednesday, 19 April 2017 at 09:01:25 UTC, Sebastiaan Koppe wrote:
> Haven't used C++ for a while actually. And seeing it after some time, makes me tremble convulsively.

_STD_BEGIN
        // basic_string INSERTERS AND EXTRACTORS
template<class _Elem,
    class _Traits,
    class _Alloc> inline
    basic_istream<_Elem, _Traits>& operator>>(
        basic_istream<_Elem, _Traits>&& _Istr,
        basic_string<_Elem, _Traits, _Alloc>& _Str)
    {	// extract a string
    typedef ctype<_Elem> _Ctype;
    typedef basic_istream<_Elem, _Traits> _Myis;
    typedef basic_string<_Elem, _Traits, _Alloc> _Mystr;
    typedef typename _Mystr::size_type _Mysizt;

    ios_base::iostate _State = ios_base::goodbit;
    bool _Changed = false;
    const typename _Myis::sentry _Ok(_Istr);

    if (_Ok)
        {	// state okay, extract characters
        const _Ctype& _Ctype_fac = _USE(_Istr.getloc(), _Ctype);
        _Str.erase();

        _TRY_IO_BEGIN
        _Mysizt _Size = 0 < _Istr.width()
            && (_Mysizt)_Istr.width() < _Str.max_size()
                ? (_Mysizt)_Istr.width() : _Str.max_size();
        typename _Traits::int_type _Meta = _Istr.rdbuf()->sgetc();

        for (; 0 < _Size; --_Size, _Meta = _Istr.rdbuf()->snextc())
            if(_Traits::eq_int_type(_Traits::eof(), _Meta))
                {	// end of file, quit
                _State |= ios_base::eofbit;
                break;
                }
            else if (_Ctype_fac.is(_Ctype::space,
                _Traits::to_char_type(_Meta)))
                break;	// whitespace, quit
            else
                {	// add character to string
                _Str.append(1, _Traits::to_char_type(_Meta));
                _Changed = true;
                }
        _CATCH_IO_(_Istr)
        }

    _Istr.width(0);
    if (!_Changed)
        _State |= ios_base::failbit;
    _Istr.setstate(_State);
    return (_Istr);
    }

:)
April 19, 2017
On Wednesday, 19 April 2017 at 11:58:07 UTC, Kagamin wrote:
> On Wednesday, 19 April 2017 at 09:01:25 UTC, Sebastiaan Koppe wrote:
>> Haven't used C++ for a while actually. And seeing it after some time, makes me tremble convulsively.
> // basic_string INSERTERS AND EXTRACTORS
> [...]
> :)

Ah yes C++ standard implementations. It took me a good 30s to find what function was being declared (operator >>). Used to have nightmares of those flying past at high speed  when getting template errors.
April 19, 2017
On 04/19/2017 03:58 AM, Laeeth Isharc wrote:

> Hope you're well.

I'm doing very well. Hoping to see you at DConf. :)

Here's another reminder to all: The registration deadline is this Sunday!

> On the other hand I was reading some object oriented C++ code of 20k
> lines split between 200 files.  I just about read C++ so ceteris non
> paribus.  But the fragmentation and artificial abstraction makes it much
> harder to see what's going on and it's scarier to change it.

That's a good point that comes up regularly. I wonder why C++ code seems to use OOP more than e.g. D does? Is it the reverberation of that old "everything is an object" style? Otherwise, it's quite possible to do compile-time polymorphism in C++ as well.

> However dub isn't worse than cmake

OT: I've used CMake in an unrelated project. I had failed to learn how to write a custom rule in it. It was super easy to make comman targets like an executable or library, but not custom stuff that we had needed. Anyway... There are smarter people who can use it. :)

> Some concrete examples that are true and essentially real might be a
> nice counterpart to the "quicksort in two lines" language evangelism
> that Andrei rightly complains about.

OT: Is there something new in Haskell that makes Sieve of Eratosthenes easier than the following entertaining paper shows?

  https://www.cs.hmc.edu/~oneill/papers/Sieve-JFP.pdf

> Maybe you have some from Weka.

Yes, Weka is a great user of D. They take full advantage of the compile-time features of D for profit. :)

OT: Unfortunately, I'm not with Weka anymore. :/ Now I know that it takes way more focus to work through the 10 hour and the 1 day differences. Their weekends are Friday and Saturday, so by the time I started my Thursday morning, Israel was already off to their weekends.

> D is a pretty good language for getting stuff done quickly in
> for a prototype that can be cleaned up quickly. That's a point
> Andy Smith made, and that Liran made in his talk also.

Joakim is right when saying "it is hard to market without people either trying the language or user testimonials". I'm dealing with the same issue at my current job: Despite my attempts, there may be separate non-D languages for prototyping and actual implementation.

Ali

April 19, 2017
On Wednesday, 19 April 2017 at 08:19:52 UTC, Ali Çehreli wrote:
> I'm brushing up on my C++ to prepare for my C++Now 2017 presentation[1]. boost::hana is an impressive library that overlaps with many D features:
>
>   http://www.boost.org/doc/libs/1_64_0_b2/libs/hana/doc/html/index.html
>
> Have you used boost::hana? What are your thoughts on it?
>
> And please share your ideas for the presentation. There has been threads here about C++ closing the gap. Does D still bring competitive advantage or is it becoming irrelevant? (Obviously, some think its irrelevant already.) I'm trying to collect opinions... :)
>
> Thank you,
> Ali
>
> [1] http://cppnow.org/2017-conference/announcements/2017/04/09/d-keynote.html

I was at C++ Meeting 2016 in Berlin, where Louis Dionne talked about hana in his keynote [1]. I've summarized my feelings in a blog post [2]. In short, you can do the same tricks in D, but frequently there's an idiomatic way to express the same thing just as concisely without them.
And of course, feel free to use any part of my post in your talk. :)

[1] https://www.youtube.com/watch?v=X_p9X5RzBJE
[2] https://epi.github.io/2017/03/18/less_fun.html

April 19, 2017
On Wednesday, 19 April 2017 at 18:02:46 UTC, Adrian Matoga wrote:
> [2] https://epi.github.io/2017/03/18/less_fun.html

Great article!
« First   ‹ Prev
1 2 3 4