131–140 of 256 posts
Earlier quoted context omitted.
Go isn't immune to the problem either. See the `flag` package, which is something that new users are encouraged to avoid in favor of e.g. https://github.com/jessevdk/go-flags .
I am a Go programmer and I've never seen anyone anywhere encouraging people to use anything over the flag package. How did you get such impression?
Earlier quoted context omitted.
If you can, could you elaborate more on python's stdlib holding it back? I think batteries-included experience is one of the reasons why so many people (including myself) use python. It's also one of the features I sorely miss when using Rust. Luckily, Rust's stdlib is starting to tend towards being more practical with recent additions like system time.
The 'std lib is where libraries go to die' was invented by Python. The libs are shallow, don't break backwards compat and provide a substandard experience. Things that continue to improve provide an out of tree alternative package name. Python codebases that are resilient don't use much of "core", arrow for time, requests for http, simplejson, etc. Using core is an antipattern that will get you stuck on a version of…
In the enterprise space it is quite common that we only get to use what it is in the computer and access to anything else is strictly controlled by IT.
So if it isn't in the standard library or some internal library mirror, we don't get to use it, as simple as that.
Earlier quoted context omitted.
How are type families worse than fundeps? That's a pretty ridiculous assertion; the things you can do with fundeps are strictly fewer than the things you can do with type families. > The principled approach You're dead wrong. The principled approach here is dependent types and full-featured type-level functions. Fundeps are a hack that let you implement a small subset of such functions (while type families gets us a…
> How are type families worse than fundeps? That's a pretty ridiculous assertion; the things you can do with fundeps are strictly fewer than the things you can do with type families. It's not about how much you can do (otherwise, just use a dynamic language, you can do everything, even shoot yourself in the foot!), it's about whether the result makes sense, and how much effort it takes to make sense of it. > You're d…
Hi. As someone that knows type theory and knows homotopy type theory and also knows Haskell well I would pose the following question to you: what purpose on god's green earth would be served by introducing univalence directly to haskell?
(Oh, and furthermore, you realize that fundeps have precisely the same issues in this setting?)
Contrariwise, don't you find it _useful_ that we can have two monoids, say And and Or, which have different `mappend` behaviour?
Now, can you imagine having that feature and _also_ respecting the idea that set-isomorphic things should be indistinguishable? How?
Earlier quoted context omitted.
You don't consider the dynamic, rich document presentation engine that is HTML to be a standard "library"? Seems like it is to me.
HTML doesn't do anything for JS other than provide a way to create visual interfaces. It might be comparable to the role that `tkinter` plays for Python's stdlib, but HTML alone is emphatically not a standard library.
Earlier quoted context omitted.
> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P
You were being down voted, maybe for perceived snark, but I think you raise an interesting point. To me, C did have a standard library: Unix. It's a runtime system too! Due to the nature of the original C bootstrapping process it just happens to be possible to remove this standard library, and Windows was evidence of this. There is another interesting potential counter example: Lua. It's minimalistic standard library…
Fully agree. We just ended up with ANSI C + POSIX, because the standard bodies refused to put everything into the same bag.
In the early days, most C compilers were anyway shipping partial UNIX APIs on top of their K&R and ANSI implementations.
Earlier quoted context omitted.
> otherwise, just use a dynamic language, you can do everything, even shoot yourself in the foot! Type classes allow huge flexibility while maintaining type safety, to a much greater degree than fundeps allow. > it's about whether the result makes sense Which they do. Perhaps you have some examples of when type families confused you or made you perform an error? > Type families as provided in Haskell are incompatible…
> Type classes allow huge flexibility while maintaining type safety, to a much greater degree than fundeps allow. Um, aren't functional dependencies an add-on to multiparameter type classes? I don't see where the opposition is. > Which they do. Perhaps you have some examples of when type families confused you or made you perform an error? I already gave an example above. I defined two type instances that violate the…
You know that's not what parametricity means, right? Like, at all?
Here's a challenge.
`foo :: forall a. a -> a`
Now, by parametricity that should have only one inhabitant (upto iso). Use your claimed break in parametricity from type families and provide me two distinct inhabitants.
I wouldn't recommend following the Haskell approach. It hasn't worked well for us. (I took part in creating the Haskell Platform and the process used to add packages to it. I also used to maintain a few of our core libraries, like our containers packages and networking). Small vs large standard library: A small standard library with most functionality in independent, community-maintained packages has given us API fri…
> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P
C would not have gotten where it is today if it wasn't for the rise of UNIX in the industry, fueled up by free UNIX clones.
Earlier quoted context omitted.
>Um, aren't functional dependencies an add-on to multiparameter type classes? You're right, I meant "type families". > I defined two type instances that violate the principle of not doing evil: We're not doing abstract category theory; we're writing computer programs (well, I am). Have you ever run into a problem with type families in that capacity ? >if two types are isomorphic, applying the same type constructor to…
> We're not doing abstract category theory; we're writing computer programs (well, I am). Have you ever run into a problem with type families in that capacity ? I like being able to reason about my programs. For that to be a smooth process, the language has to be mathematically civilized. > Agreed, but there's a difference between type functions and type constructors. TFs are (a limited form of) type functions. By “t…
You can do this in Haskell with DataKinds (you just pass around a type of the correct kind which contains all the parameters). Admittedly, it is quite clunky at the moment. I did this to pass around CPU configuration objects for hardware synthesis a la Clash, as CPU designs are often parametrized over quite a few Nats.
> parametricity is an abstract uniformity property enjoyed by parametrically polymorphic functions
Whenever one introduces a typeclass constraint to a function, one can only assume that the function exhibits uniform behavior up to the differences introduced by different instances of the typeclass. There is no particular reason to assume that (+) has the same behavior for Int and Word, except insofar as we have some traditional understanding of how addition should work and which laws it should respect. The same is true for type families. It is not a problem that they introduce non-uniform behavior; we can only ask that they respect some specified rules with respect to their argument and result types.
Case-analyzing types in type families is no worse than writing a typeclass instance for a concrete type. Would you say that the fact that "instance Ord Word" and "instance Ord Int" are non-isomorphic is a problem? After all, the types themselves are isomorphic!
Earlier quoted context omitted.
> Empirically, languages that have large standard > libraries (e.g. Java, Python, Go) seem to do better than > their competitors. You seem to be overlooking the ultimate counterexample: C. :P
But C didn't have competitors with large standard libraries, so it didn't suffer as much for it.
For example check Turbo Pascal libraries, including Turbo Vision, already on MS-DOS.
C took off thanks to UNIX's adoption, like JavaScript on browsers nowadays, it became the language to use for anyone working on the enterprise on those new shiny UNIX boxes.
In Europe it was just another systems language to choose from, back when CP/M and other 8 / 16 bit systems were common.
Earlier quoted context omitted.
I think that Go can pull off a good standard library because there's a big corporate sponsor behind it, whereas Ruby may have had difficulty with its standard library for the lack of a sponsor. Standard doesn't mean completely done. Standard should be able to accomodate things like HTTP2, as Go has done, whether that means expanding the API or whatever.
The "big corporate sponsor" argument often comes up when discussing language success. Google doesn't really put more than a few people's time into Go, the rest is open source. Other languages like Python didn't have any real backing until way after success.