| 1 |
пн, 20 апр. 2020 г. в 17:38, Michael Orlitzky <mjo@g.o>: |
| 2 |
> Diamond dependencies manifest mainly in delayed version |
| 3 |
> bumps, while slyfox does all the work to make sure that the things |
| 4 |
> already in the tree will work with the new version. This requires lots |
| 5 |
> of careful updates to neighboring packages, and unfortunately a lot of |
| 6 |
> cabal file hacking. |
| 7 |
|
| 8 |
This is precisely what I meant by "doesn't scale well". |
| 9 |
|
| 10 |
Wonder if this can be automated. |
| 11 |
|
| 12 |
> > Dunno much about Go and I don't have a single Go package locally to |
| 13 |
> > check. Do they do static or dynamic linking with the deps, for |
| 14 |
> > instance? What's the language model wrt API and linking? |
| 15 |
> |
| 16 |
> FORGET I MENTIONED IT |
| 17 |
|
| 18 |
Lol, happy to! |
| 19 |
|
| 20 |
> >> and C. |
| 21 |
> > |
| 22 |
> > More stable API (and ABI). |
| 23 |
> > |
| 24 |
> |
| 25 |
> Definitely. The "Haskell" language changes entirely every few years. |
| 26 |
|
| 27 |
Some say the same about C++ (and ABI does change even within a standard), so... |
| 28 |
|
| 29 |
> I've learned the hard way that it discourages you from doing all the |
| 30 |
> things that I just said high-quality software should do. |
| 31 |
|
| 32 |
Again, ranging from one-off pseudo-scripts that I had to come back to |
| 33 |
after a couple of years, to quite complicated pieces of software |
| 34 |
running in prod and actually serving customers I had to update up to |
| 35 |
the latest LTS after 3-4 years of inactivity, I tend to disagree. Even |
| 36 |
the latter was a surprisingly smooth process boiling down to about an |
| 37 |
hour or two of very effortless, mechanical and thus boring code |
| 38 |
changes (mostly about Semigroup/Monoid hierarchy, if you wonder). |
| 39 |
|
| 40 |
This is surely offtopic, but I just don't want to silently participate |
| 41 |
in spreading things that aren't objectively true (even if they are |
| 42 |
subjectively true in your/mine/etc experience). |
| 43 |
|
| 44 |
> There's a core of mature Haskell that's pretty easy to develop against. |
| 45 |
> (I think you just have to wait about five years with any project before |
| 46 |
> the authors realize that changing everything every month isn't fun.) Out |
| 47 |
> in the woods you can still get into a lot of trouble though. We now have |
| 48 |
> the mature core stuff in ::gentoo, and the crazies out in the ::haskell |
| 49 |
> overlay. That feels like the right mix. |
| 50 |
|
| 51 |
I've seen transifex-client last-rited the other day and was thinking |
| 52 |
of throwing up something in haskell (plus I have a couple of other |
| 53 |
projects that might be useful). Let's see what it'd take to get that |
| 54 |
into ::gentoo once I'm done. |
| 55 |
|
| 56 |
BTW having things like servant in ::haskell as opposed to ::gentoo is |
| 57 |
like having boost in some C++ overlay as opposed to ::gentoo. |
| 58 |
|
| 59 |
-- |
| 60 |
Georg Rudoy |
Archives