Logs: freenode/#haskell
| 2020-11-03 09:52:56 | <c_wraith> | and there are things no one would ever call simple (like Data.Generics.Labels from generic-lens) that are worth far more than they cost |
| 2020-11-03 09:53:28 | <kuribas> | c_wraith: yeah. Isn't that because most of the complexity is in the library implementation though? |
| 2020-11-03 09:53:39 | <kuribas> | generic-lens doesn't seem so hard to use |
| 2020-11-03 09:53:40 | <maerwald> | kuribas: servant is for cases where you want to autogenerate clients (or consume the haskell types directly). Most cases of servant I've seen in production do neither. That falls under the "unnecessary complexity" category |
| 2020-11-03 09:54:15 | <kuribas> | maerwald: indeed. If you make a non-REST web-app, I would say servant is a mistake. |
| 2020-11-03 09:54:19 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd) |
| 2020-11-03 09:54:20 | <c_wraith> | kuribas: it's *very* easy to use. The complexity isn't hidden away exactly, though, as it relies on things like IncoherentInstances |
| 2020-11-03 09:54:50 | <maerwald> | But ppl don't choose their tools based on careful cost-benefit analysis, especially in haskell. They base it on the latest reddit thread about dependent types :) |
| 2020-11-03 09:55:24 | <kuribas> | I absolutely agree that a lot of haskell is overly complicated, for example database libraries. |
| 2020-11-03 09:55:32 | <maerwald> | It's almost as if haskellers get anxiety attacks if they don't keep up with the latest esoteric approaches |
| 2020-11-03 09:55:42 | → | ByronT joins (~ByronT@154.13.1.56) |
| 2020-11-03 09:55:53 | <kuribas> | maerwald: I think it's more like having a nice new shiny toy to play with |
| 2020-11-03 09:56:09 | → | o1lo01ol1o joins (~o1lo01ol1@bl8-213-81.dsl.telepac.pt) |
| 2020-11-03 09:56:21 | <maerwald> | for some, for others its burnout, trying to keep up with the design space... and it's already too large imo |
| 2020-11-03 09:56:42 | <kuribas> | I just think that many extensions, like overloadedLabels, type-applications, aren't that complicated, mostly syntactic sugar. |
| 2020-11-03 09:57:07 | <maerwald> | But most programmers only care about a use case they can tackle with a new language feature. They don't consider the whole design space the feature opens and what the impact on the ecosystem is |
| 2020-11-03 09:57:16 | × | z0 quits (~z0@188.250.0.59) (Ping timeout: 246 seconds) |
| 2020-11-03 09:57:40 | <kuribas> | maerwald: well, there is no shortage to java jobs, so if you want a simple language, that mostly does the job, you can go to java. |
| 2020-11-03 09:57:54 | <maerwald> | That's a way to make a language fail. But we can argue about whether or not C++ is a failure. I consider it one |
| 2020-11-03 09:58:14 | <maerwald> | kuribas: Java isn't simple at all |
| 2020-11-03 09:58:48 | <maerwald> | Getting generics right in Java isn't easy. Inheritance is massively complicated |
| 2020-11-03 09:59:14 | → | z0 joins (~z0@188.251.73.190) |
| 2020-11-03 09:59:34 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd) (Remote host closed the connection) |
| 2020-11-03 09:59:38 | z0 | is now known as Guest77983 |
| 2020-11-03 09:59:56 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd) |
| 2020-11-03 10:00:57 | <kuribas> | whatever language you pick, you need to take a subset that fits beset with your workflow. |
| 2020-11-03 10:01:01 | <maerwald> | Simple also doesn't mean "dumb". How many ppl know that you can use guards in a case expression? You don't see it often. Many don't know all haskell2010 features. |
| 2020-11-03 10:01:51 | → | acidjnk_new2 joins (~acidjnk@p200300d0c718f623ecaa4caf6803be45.dip0.t-ipconnect.de) |
| 2020-11-03 10:01:55 | <dminuoso> | c_wraith: IncoherentInstances? |
| 2020-11-03 10:01:56 | <kuribas> | also, if you use "simple" haskell, then you are limited to "simple" libraries. |
| 2020-11-03 10:01:59 | <dminuoso> | Why/how is this useful? |
| 2020-11-03 10:02:14 | <dminuoso> | Ive been trying to understand the justification for that extension |
| 2020-11-03 10:02:39 | <int-e> | > let x | let y = 42 in y in x |
| 2020-11-03 10:02:41 | <maerwald> | I'm not arguing for either. I'm arguing that ppl have no real process on how to choose complex vs simple haskell for a problem at hand. |
| 2020-11-03 10:02:42 | <lambdabot> | <hint>:1:25: error: <hint>:1:25: error: parse error on input ‘in’ |
| 2020-11-03 10:02:47 | <c_wraith> | Think of it as "even more overlapping instances" |
| 2020-11-03 10:02:54 | <int-e> | > let x | let y = 42 = y in x |
| 2020-11-03 10:02:57 | <lambdabot> | 42 |
| 2020-11-03 10:03:00 | <maerwald> | simple vs complex haskell is a nonsense decision |
| 2020-11-03 10:03:06 | <dminuoso> | c_wraith: Sure, but IncoherentInstances gives me in effect random choice of instances. |
| 2020-11-03 10:03:28 | <dminuoso> | This would make sense if the instances are equivalent, but at that point why have them at all |
| 2020-11-03 10:03:41 | <int-e> | (That we have `let` inside guards is one Haskell2010 feature I was blissfully unaware of until... hmm, 2 months ago?) |
| 2020-11-03 10:04:00 | <dminuoso> | int-e: Indeed, Im quite fond of it :) |
| 2020-11-03 10:04:15 | <[exa]> | oh wow |
| 2020-11-03 10:04:21 | <c_wraith> | dminuoso: not when you carefully set up your instances so that the only type variable that's treated incoherently also doesn't matter to the behavior. |
| 2020-11-03 10:04:28 | → | heatsink joins (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) |
| 2020-11-03 10:04:32 | <int-e> | let x | y <- 42 = y in x -- I prefer these most of the time |
| 2020-11-03 10:04:50 | ← | minus[m] parts (minusblobc@gateway/shell/matrix.org/x-hhdwstlyzyfgkvud) ("User left") |
| 2020-11-03 10:04:58 | <dminuoso> | int-e: That requires an extension *and* has subtly different meaning. It can more easily lead to bugs. |
| 2020-11-03 10:04:59 | <maerwald> | kuribas: but what I read in the current reddit thread is somewhere between naive and arrogant, imo |
| 2020-11-03 10:05:23 | <c_wraith> | dminuoso: pattern guards are part of Haskell 2010, too |
| 2020-11-03 10:05:26 | <dminuoso> | Oh |
| 2020-11-03 10:05:36 | <int-e> | dminuoso: well, the let thing can also lead to subtle bugs... for pretty much the same reason. |
| 2020-11-03 10:05:37 | <merijn> | dminuoso: Everyone always forgets that |
| 2020-11-03 10:05:42 | <dminuoso> | int-e: Say, you have some `newtype T = T Int`, with some `let x | letT t <- x ...`, if you later refactor that into a data type, it will compile just fine but might not mean what you want it to |
| 2020-11-03 10:06:02 | <dminuoso> | In that example no, because a let will generate missing pattern errors |
| 2020-11-03 10:06:08 | <dminuoso> | uhh |
| 2020-11-03 10:06:13 | <dminuoso> | `let x | T t <- x ...` |
| 2020-11-03 10:06:24 | <dminuoso> | `let x | let T t = x ...` |
| 2020-11-03 10:06:33 | <dminuoso> | If you switch T from newtype to data, one of them will warn the other will not |
| 2020-11-03 10:06:43 | <merijn> | I like how the survey blindly copies all GHC -X flags as extensions and thus includes things that are, in fact, already enabled by default because their Haskell2010 :p |
| 2020-11-03 10:07:10 | <int-e> | Well, I did have variable patterns in mind. |
| 2020-11-03 10:07:15 | <merijn> | maerwald: I agree. I see value in "simple Haskell", it's just that blindly saying "these extensions are ok" and "these are not" is way to simplistic for defining simple Haskell :p |
| 2020-11-03 10:07:44 | <merijn> | It's mostly a matter of "do these extensions 'pull their weight'", which unfortunately isn't something you can define a simple universal heuristic for |
| 2020-11-03 10:07:50 | <idnar> | dminuoso: do you mean switch and add more constructors? |
| 2020-11-03 10:07:56 | <dminuoso> | idnar: Right |
| 2020-11-03 10:08:04 | <int-e> | In any case, the point was that it's really easy to miss a corner of the Haskell syntax for years without missing anything. |
| 2020-11-03 10:08:05 | <kuribas> | merijn: that's my take on it too. |
| 2020-11-03 10:08:06 | <idnar> | dminuoso: ahh |
| 2020-11-03 10:08:42 | → | wwwww joins (~wwwww@unaffiliated/wwwww) |
| 2020-11-03 10:08:45 | × | heatsink quits (~heatsink@107-136-5-69.lightspeed.sntcca.sbcglobal.net) (Ping timeout: 240 seconds) |
| 2020-11-03 10:09:08 | <kuribas> | merijn: avoid fancy haskell if you can, use it if you can't |
| 2020-11-03 10:09:12 | <maerwald> | I think snoyman approaches the problem from the right angle. Problem focused. But I just think his decisions are mostly wrong :) |
| 2020-11-03 10:09:30 | <yushyin> | haha |
| 2020-11-03 10:10:12 | <[exa]> | merijn: people can still vote against the defaults :] |
| 2020-11-03 10:14:15 | <merijn> | [exa]: I meant that they are not extensions |
| 2020-11-03 10:14:26 | <idnar> | regarding fancy Haskell, it's perfectly possible to make an overcomplicated inscrutable mess without extensions; if you can't easily bring a junior colleague up to speed on the code you're writing (in any language) then consider simplifying the code and/or revising your hiring practices |
| 2020-11-03 10:14:49 | <merijn> | [exa]: Like -XPatternGuards is not an extension in Haskell2010. It's an extension to Haskell98 which (hopefully) no one writes anymore |
| 2020-11-03 10:15:03 | <maerwald> | idnar: not hiring practices... mentoring practices |
| 2020-11-03 10:15:46 | <idnar> | maerwald: well, both :) |
| 2020-11-03 10:15:48 | <kuribas> | idnar: not making an inscrutable mess should be a no-brainer in any language, but sadly it isn't... |
| 2020-11-03 10:15:48 | <maerwald> | if you can't get a junior up to speed, then that's a management and team failurea |
| 2020-11-03 10:16:55 | <int-e> | kuribas: I'm not sure what you mean by no-brainer... it usually requires quite some thought :P |
| 2020-11-03 10:17:18 | <kuribas> | I think getting someone up to speed with an application is way easier in haskell, due to the type system. |
| 2020-11-03 10:17:28 | <kuribas> | int-e: right :) |
| 2020-11-03 10:17:45 | → | lucente joins (~lucente@31.170.86.76) |
| 2020-11-03 10:18:02 | <kuribas> | int-e: I guess what I meant was, taking the effort to clean up technical dept... |
| 2020-11-03 10:18:06 | <[exa]> | merijn: yeah, but it will show how many people may be unaware of the fact |
| 2020-11-03 10:18:14 | × | cosimone quits (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd) (Remote host closed the connection) |
| 2020-11-03 10:18:21 | <kuribas> | int-e: the effort itself is non trivial of course |
| 2020-11-03 10:18:38 | → | cosimone joins (~cosimone@2001:b07:ae5:db26:d849:743b:370b:b3cd) |
| 2020-11-03 10:18:40 | <int-e> | kuribas: I knew what you meant. |
| 2020-11-03 10:18:57 | <lucente> | I'm having hard time solving this tulpa problem: [(String, Int)] -> [String] where I'm checking whenever [("A", 100)] whenever the Int is greater that 0 I add its tulpa's string to an output. Example [("A", 100), ("B", -1), ("C",36) = ["A", "C"] |
| 2020-11-03 10:18:59 | <__monty__> | I agree, I can't count the number of times I've had to look for a function in a python project, which turns out to be a __call__ method on an object that's "cast" to something else three times before use 😭 |
| 2020-11-03 10:19:13 | <hc> | win3 0 |
| 2020-11-03 10:19:15 | <hc> | sry |
| 2020-11-03 10:19:43 | <idnar> | kuribas: yeah, it seems like people don't want to take responsibility for the social aspects of programming, but instead replace that with some mindless overly simplistic rules |
| 2020-11-03 10:20:08 | × | plutoniix quits (~q@175.176.222.7) (Quit: Leaving) |
| 2020-11-03 10:20:48 | <__monty__> | lucente: Maybe split the problem into pieces. Can you just get rid of the tuples with a value <= 0? |
| 2020-11-03 10:20:48 | × | ambiso9 quits (~ambiso@209.182.239.205) (Quit: The Lounge - https://thelounge.chat) |
All times are in UTC.