Why Type Systems Matter • Hacker News Board

Re: Why Type Systems Matter

#101

Post by gumby » Sat, Aug 19, 2017, 3:40 PM UTC

shakna wrote: post #94

gumby wrote: post #87

Earlier quoted context omitted.

> Most of the time I'd recommend the new type-safe union std::variant Neither g++ 7 nor Clang/LLVM 4.0.1 support std::variant yet :-(. We started a new (blank buffer) codebase earlier this year and decided to use C++17 as the implementation language, which has exposed us to the gaps...which are surprisingly few! But sadly this is one of them.

> Neither g++ 7 Eh? I've been using it a hell of a lot! std::variant is listed on GCC 7's page [0], and I know that is there in at least 7.1 I don't use clang much, but they list it as supported [1], and I believe the patch [2] landed in 5.0 [0] https://gcc.gnu.org/gcc-7/changes.html [1] https://libcxx.llvm.org/cxx1z_status.html [2] https://reviews.llvm.org/rL288547

Hmm, have to check include paths again!

Re: Why Type Systems Matter

#102

Post by shakna » Sun, Aug 20, 2017, 7:53 PM UTC

gumby wrote: post #101

shakna wrote: post #94

Earlier quoted context omitted.

> Neither g++ 7 Eh? I've been using it a hell of a lot! std::variant is listed on GCC 7's page [0], and I know that is there in at least 7.1 I don't use clang much, but they list it as supported [1], and I believe the patch [2] landed in 5.0 [0] https://gcc.gnu.org/gcc-7/changes.html [1] https://libcxx.llvm.org/cxx1z_status.html [2] https://reviews.llvm.org/rL288547

Hmm, have to check include paths again!

So I glanced over this, and found that std::variant is in libc++, as you would expect, but in some cases, when you get a nice modern compiler, you might not end up with it linked to a nice modern stdlib.

So maybe some sort of mis-match got in your way.

Anyways, here's hoping you get to use C++17 in its full glory!

Re: Why Type Systems Matter

#103

Post by naasking » Wed, Aug 23, 2017, 12:21 PM UTC

Veedrac wrote: post #86

naasking wrote: post #47

Earlier quoted context omitted.

Absolutely. It's little different than asking whether you can solve a problem once you have the appropriate data structure. Solving the problem when the right data structure is available becomes almost trivial -- most of the difficult of programming is recognizing what data structures are needed. Very few of the problems we encounter in every day programming don't fall when the right data structure is available.

It's not the same at all; data structures frequently actually are half the problem, though that's not to say that insight buys you anything. Let's say I want to stream logging data at a massive rate (~peak core-core bandwidth) to another core and perform complex queries and visualisations on it in sub-frame times. If I have the data structure for that, the rest is bookwork. If I have the type... what have I gained? L…

> Let's say I want to stream logging data at a massive rate (~peak core-core bandwidth) to another core and perform complex queries and visualisations on it in sub-frame times. If I have the data structure for that, the rest is bookwork. If I have the type... what have I gained?

It depends on how you're using "type" vs how I'm using it.

If you mean the "publicly visible type", ie. the left hand side of "newtype Foo a = ...", my claim is weaker. Even so, the public interface for your type specifies the operations and implies their approximate time and space complexity (1), which points rather suggestively at the types of internal data structures that will be needed to satisfy these properties (2), which as you've said, is at least half the problem.

If by "type", the actual data type definitions needed to satisfy this interface, ie. the right hand side of "newtype Foo a = ...", which is what I originally meant, then you're already at (2) above, from which the conclusion follows almost trivially.

Hopefully that clarifies your follow up points.