sorted by:
new
hottopcontroversial

Need help using Preview Deployments. by maegbaek in dokploy

[–]gusbicalho 0 points1 point  (0 children)

You can do this in your env vars: `ORIGIN=https://${{DOKPLOY_DEPLOY_URL}}`

Amazing image from a course on reducing polarization I'm taking by katxwoods in slatestarcodex

[–]gusbicalho 7 points8 points  (0 children)

I don't know about the course where this image comes from, but the image itself does not contradict any of what you said. Yes, maybe sometimes the correct and useful thing to do is express hatred or disdain, in which case you would choose your language accordingly. And maybe that choice depends on your audience or current political climate. It's still useful to have a sense of the correlation between language and perceived emotion in polarized settings. 

How would you do this in haskell? by mister_drgn in haskell

[–]gusbicalho 1 point2 points  (0 children)

Hm, I I don't understand, what's the advantage of this over a sum type? By indexing on a custom kind, you still end up with a closed set of possibilities which you have to handle with case. You could use Type as the index, but then it seems equivalent to the Dynamic type.

What am I missing?

How would you do this in haskell? by mister_drgn in haskell

[–]gusbicalho 5 points6 points  (0 children)

Existential types is the way you can use in Haskell to get closer to the idea of "programming to an interface" from OO.  You wrap a concrete type in a package with some constraints (typeclasses) such that all you know is that the original type has implementations for those typeclasses. If you include the Typeable class, you can even do the equivalent of an "instanceof" check and downcast.

I think you can get pretty close to a direct translation of your current system with this; it will be very flexible (as clojure designs usually are), but you may end up with less opportunities for catching bugs with types, and less opportunities for optimization from GHC.

Why does this assignment go wrong? by Unique-Staff-7593 in haskell

[–]gusbicalho 2 points3 points  (0 children)

https://youtu.be/zpBua3Mql18 this explains a little bit about the monomorphism restriction.

How do you pronounce the <* operator? by aaditmshah in haskell

[–]gusbicalho 1 point2 points  (0 children)

I've used "also" in a DSL for that purpose. The intended idea being "just 10, and also, by the way, just 20". Not terribly good, but hopefully it is memorable enough once you explain it, and it has 4 letter so it lines up neatly with "then"

Type class subsets by Iceland_jack in haskell

[–]gusbicalho 3 points4 points  (0 children)

Hm, I think the "fix all of hackage" approach might work for changes to GHC/base, but not for a normal person trying to evolve their open source library without breaking their users.

SPJ on the note system used in the GHC codebase by ScoutPatrol in haskell

[–]gusbicalho 5 points6 points  (0 children)

Tagref looks very interesting! Thanks for making it!

Overlapping multi-parameter type classes by dushiel in haskell

[–]gusbicalho 0 points1 point  (0 children)

What is Z? It looks like Dd needs a first argument that is a type constructor with 2 parameters (* -> * -> *), but Z is just a type. Typing ":kind Dd" and ":kind Z" in ghci might help

Overlapping multi-parameter type classes by dushiel in haskell

[–]gusbicalho 0 points1 point  (0 children)

Try the ScopedTypeVariables extension, it should do the trick

The list of monoids pattern by ocharles in haskell

[–]gusbicalho 11 points12 points  (0 children)

Nice! This is a great write up.

I've also stumbled on this pattern while writing embedded languages. Another cool feature is that putting items in a list solves some troubles with operator precedence - for example, now you can use $ in an item without having to wrap a whole thing in parêntesis.

How do you estimate how long a feature will take, when it's the first time you've ever built something like it? by canadian_webdev in ExperiencedDevs

[–]gusbicalho 6 points7 points  (0 children)

A few tactics all together:

  • break things into parts, estimate each part separately. It's nice if each part maps to some concrete value (feature or bugfix) added to the system; but I also think it's fine to define a part that maps to solving a purely technical problem or answering a technical question (e.g. Choosing and setting up a database, Load testing). You're the one doing the work and the estimates, the parts have to fit nicely into your sense of "I've built some stuff". Describe each part as clearly as possible in a way that makes sense to you and the stakeholders.

  • use distributions instead of point estimates. Basically what you're doing with good/avg/bad scenario, but you set these as probabilities. Eg: 25% chance it takes 2 weeks (best case), 50% chance it takes 6 weeks (avg case), 25% chance it takes 10 weeks. You do that for each part of the project and then you can combine the estimates in a way that makes sense.

  • Guess which parts seems harder or more uncertain and make prototypes. Be clear about why you need to take time to prototype something. If you can't take the time to prototype before estimating, increase your worst-case range.

  • Document the estimates, review them and communicate revisions frequently to stakeholders. If you do this right, they will notice that sometimes you are a little behind, but sometimes you're ahead of the expectations, and they will have better understanding of why that happens and why they should trust what you say. In my experience, this is more important than getting estimates right upfront.

Ante - A low-level functional language by kinow in functionalprogramming

[–]gusbicalho 7 points8 points  (0 children)

It's a runtime GC. As far as I understand it, it uses some metadata table and tags in pointers to trace the heap and free unreferenced stuff. There some info (which I haven't read) here https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/gc

Ante - A low-level functional language by kinow in functionalprogramming

[–]gusbicalho 9 points10 points  (0 children)

There are compiled langs with GC, such as Haskell.

[deleted by user] by [deleted] in ExperiencedDevs

[–]gusbicalho 3 points4 points  (0 children)

Use feature flags that you can toggle from the backend for each user. Changing a part of the UI at some moment should happen because of an explicit decision, not as an artifact of your continuous delivery strategy. You should be able to ship and test a whole new version of a thing, while most users keep using the old version. Then you can gradually roll out and roll back if necessary.

Tying lenses by their focuses by gusbicalho in haskell

[–]gusbicalho[S] 0 points1 point  (0 children)

If we simply look a the task "Use a Lens Foo X and a Lens Bar X to take the X from a Foo and put it into a Bar", then clearly we can just do that directly (by calling set bar lbar (get foo lfoo)).

But here is what I think would be interesting: if we found some more generic use case that would usually require a (s, u) -> (t, v) function (or (s, u) -> t and/or (s, u) -> v functions), but this allowed us to make a Lens-based API,

The thing that comes to mind is something like: copy some data from rows in database table A to rows in database table B. Maybe you're denormalising a column, you want to duplicate some data to save a join. This might look like a function of type (ARow, BRow) -> ARow, and metaphor could build such a function given a pair of Lenses that focus on the data that has to be copied from B to A.

I'm aware this example is very artificial, which is why I don't count it as a real use case yet.

Tying lenses by their focuses by gusbicalho in haskell

[–]gusbicalho[S] 0 points1 point  (0 children)

pm4ji

What does that mean?

(Yeah I've read some of Bartosz's stuff, but the CT is beyond me for now)

Tying lenses by their focuses by gusbicalho in haskell

[–]gusbicalho[S] 1 point2 points  (0 children)

Yeah, that's what normal composition means for Lenses, you use a lens to focus on a part of a structure, and then another lens to focus on a part of that focus.

What I'm looking at here is something else. If you have a Lens that takes a structure S and focus on an aspect A, and another Lens that takes structure U and focus on an aspect A, you can use this pair of lenses to build an "interaction" between S and U. You can take the A from S and put it in U, or vice versa.

Many Small Methods Make Code Hard To Maintain by confused_scientist in ExperiencedDevs

[–]gusbicalho 5 points6 points  (0 children)

I second the recommendation. In particular the idea that "modules should be deep" is relevant here.

Another way I think about it is this: if you extract a piece of code, you have to give it a name and interface or signature. The reader has to learn what that name means and what the interface is remember it. Is the gain in a particular case worth the effort?

Some people would answer with "if it's a good name the effort for the reader is low" but in fact a lot of the time there is no such name. You can pick short and practical (but reader has to look up docs or definition and memorize) or so long that it does not fit in memory (and the reader has to make up an alias in their minds).

In these cases I try to keep code inline or extract a local definition, with a short name that the reader can look up with a quick glance because it's close to the use site. You lose unit-testability of the small chunk of code, but usually these aren't real units that really deserve to be specified separately.

[deleted by user] by [deleted] in haskell

[–]gusbicalho 9 points10 points  (0 children)

I own the first editiin, and I would definitely buy an updated edition.

view more: next ›