| --- Log opened Tue May 12 00:00:09 2020 |
| 00:02 | | bluefoxx [fuzzylombax@Nightstar-gmbj85.vs.shawcable.net] has joined #code |
| 00:14 | <@celticminstrel> | XD An engineer took a mythology class!? |
| 00:14 | <@celticminstrel> | WTH is that!? |
| 00:16 | <@celticminstrel> | XD Reusing a spreadsheet as a PRNG? I don't really get it tho. |
| 00:17 | <@celticminstrel> | …multi-armed bandits? That came out of nowhere. |
| 00:17 | <&McMartin> | The tendency of projects to codename their systems grandiose neoclassical things that aren't very obscure, presumably by analogy with Kerberos |
| 00:18 | <@celticminstrel> | Haha, "number of bugs" is no longer relevant. |
| 00:18 | <@celticminstrel> | "It is useless by itself" Pfft |
| 00:18 | <@celticminstrel> | Love the contradiction wrt accessibility. |
| 00:19 | <@celticminstrel> | "We hope you'll follow our example but btw it'll ruin you" |
| 00:27 | | catalyst [catalyst@Nightstar-oh8b7v.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 00:35 | | McMartin[zomg] [mcmartin@Nightstar-c25omi.ca.comcast.net] has joined #code |
| 00:39 | | McMartin[zomg] [mcmartin@Nightstar-c25omi.ca.comcast.net] has quit [[NS] Quit: Fixing IRC] |
| 00:39 | | McMartin [mcmartin@Nightstar-c25omi.ca.comcast.net] has quit [Connection closed] |
| 00:39 | | McMartin [mcmartin@Nightstar-c25omi.ca.comcast.net] has joined #code |
| 00:39 | | mode/#code [+ao McMartin McMartin] by ChanServ |
| 00:43 | | catalyst [catalyst@Nightstar-0k6uan.dab.02.net] has joined #code |
| 01:04 | | Kindamoody is now known as Kindamoody[zZz] |
| 02:23 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Connection closed] |
| 03:27 | | Kindamoody[zZz] [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Ping timeout: 121 seconds] |
| 04:31 | | Degi [Degi@Nightstar-runi3c.dyn.telefonica.de] has quit [Ping timeout: 121 seconds] |
| 04:31 | | Degi [Degi@Nightstar-sfak36.dyn.telefonica.de] has joined #code |
| 04:39 | | Kindamoody[zZz] [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
| 04:39 | | mode/#code [+o Kindamoody[zZz]] by ChanServ |
| 04:43 | | Kindamoody[zZz] [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Ping timeout: 121 seconds] |
| 04:44 | | celticminstrel [celticminst@Nightstar-nuu42v.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 06:58 | | catalyst [catalyst@Nightstar-0k6uan.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 07:12 | <&McMartin> | Those of you who have used, and loathed, Golang: I seek specifics of hatred beyond the general aesthetic problems. |
| 07:13 | <&McMartin> | I have jerith's complaints as to the insufficiency of its documentation and testing frameworks. |
| 07:13 | <&McMartin> | I'd like more details on what *specifically* it lacks on the testing side since my experience with server-level stuff is weak |
| 07:13 | <&McMartin> | (The insufficiency of its documentation has been easily demonstrated to me) |
| 07:44 | <&jeroud> | I have a pointed rant on the topic that I shall link to you when I get set up for the day. (I may have already done so back when I wrote it.) |
| 07:47 | <&jeroud> | But the TL;DR is that the language lacks tools for creating abstraction boundaries, so there's a lot of repetition and noise in pretty much all golang code. |
| 07:49 | <&jeroud> | The insufficiency of its test tooling is a symptom of the deeper design issues. |
| 08:03 | <&jerith> | https://gist.github.com/jerith/1a1f3b668c37212f6b3476f0761b4c7c -- the first half is what you're after, I think. |
| 08:12 | <&McMartin> | thanks |
| 08:13 | <&McMartin> | And yeah, I'm trying to build reasonable abstractions in it and keep them idiomatic but there's not a lot of options |
| 08:14 | <&McMartin> | Oh I do remember this |
| 08:36 | | catalyst_ [catalyst@Nightstar-6b35um.dab.02.net] has joined #code |
| 08:40 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 08:43 | <&jerith> | https://github.com/praekeltfoundation/vault-plugin-auth-mesos is the only nontrivial from-scratch golang program I've written and may contain some useful patterns. |
| 08:43 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 08:46 | <&jerith> | ... I've just remembered that the mostly-useless comments above every type and public function are there to make the linter happy. |
| 08:50 | <&jerith> | https://github.com/praekeltfoundation/vault-plugin-auth-mesos/blob/master/backend.go#L34-L39 is a pretty typical example of how certain things are inherently untestable. |
| 08:56 | <&jerith> | (Or rather, how the untestability interacts with certain common patterns and assumptions.) |
| 09:08 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 09:14 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 09:31 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 09:31 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 10:17 | | Kimo|autojoin [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
| 10:17 | | mode/#code [+o Kimo|autojoin] by ChanServ |
| 10:17 | | Kimo|autojoin is now known as Kindamoody |
| 10:41 | | Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has quit [Connection closed] |
| 10:42 | | Kindamoody [Kindamoody@Nightstar-eubaqc.tbcn.telia.com] has joined #code |
| 10:42 | | mode/#code [+o Kindamoody] by ChanServ |
| 11:05 | | Pink` [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 11:08 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 11:38 | | Pink` is now known as Pink |
| 13:26 | | catalyst [catalyst@Nightstar-0p3gif.dab.02.net] has joined #code |
| 13:27 | | catalyst_ [catalyst@Nightstar-6b35um.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 13:51 | | * Vornicus does even more terrible math: calculus on bezier surfaces! |
| 14:17 | <~Vornicus> | ...which appears to be utterly straightforward. Onward! |
| 14:34 | | celticminstrel [celticminst@Nightstar-nuu42v.dsl.bell.ca] has joined #code |
| 14:34 | | mode/#code [+o celticminstrel] by ChanServ |
| 15:19 | | Syloq [Syloq@NetworkAdministrator.Nightstar.Net] has quit [[NS] Quit: .] |
| 15:20 | | Netsplit Golgafrincham.Nightstar.Net <-> Traal.Nightstar.Net quits: @jeroud, @VirusJTG, @iospace, @ErikMesoy, Kizor, @McMartin, @crystalclaw, @gnolam, @Vornicus, @Alek, (+8 more, use /NETSPLIT to show all of them) |
| 17:18 | | jeroud [sid10043@Nightstar-h2b233.irccloud.com] has joined #code |
| 17:18 | | macdjord [macdjord@Nightstar-rslo4b.mc.videotron.ca] has joined #code |
| 17:18 | | Yossarian [yoss@Nightstar-d7h8ki.org] has joined #code |
| 17:18 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 17:18 | | Alek [Alek@Nightstar-o723m2.cicril.sbcglobal.net] has joined #code |
| 17:18 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 17:18 | | ErikMesoy [Bruker@Nightstar-0qvnm6.bb.online.no] has joined #code |
| 17:18 | | bluefoxx [fuzzylombax@Nightstar-gmbj85.vs.shawcable.net] has joined #code |
| 17:18 | | Reiver [quassel@Nightstar-ksqup0.co.uk] has joined #code |
| 17:18 | | catalyst_ [catalyst@Nightstar-v6lb30.cable.virginm.net] has joined #code |
| 17:18 | | VirusJTG [VirusJTG@Nightstar-42s.jso.104.208.IP] has joined #code |
| 17:18 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 17:18 | | crystalclaw [crystalclaw@Nightstar-12q9ui.xyz] has joined #code |
| 17:18 | | Tamber [tamber@furryhelix.co.uk] has joined #code |
| 17:18 | | iospace [quassel@Nightstar-50v6q2.members.linode.com] has joined #code |
| 17:18 | | Kizor [moryok@Nightstar-e0a4sm.utu.fi] has joined #code |
| 17:18 | | gnolam [lenin@Nightstar-ik80lk.priv.bahnhof.se] has joined #code |
| 17:18 | | JustBob [justbob@Nightstar.Customer.Dissatisfaction.Administrator] has joined #code |
| 17:18 | | McMartin [mcmartin@Nightstar-c25omi.ca.comcast.net] has joined #code |
| 17:18 | | ServerMode/#code [+aoooqooaoaooooooao jeroud jeroud macdjord Alek Vornicus Vornicus ErikMesoy Reiver Reiver VirusJTG VirusJTG crystalclaw Tamber iospace gnolam JustBob McMartin McMartin] by *.Nightstar.Net |
| 18:28 | <~Vornicus> | https://cdn.discordapp.com/attachments/474705430434807819/709816474956595312/unknown.png it is finished. |
| 18:34 | | * Emmy blinks |
| 18:34 | < Emmy> | is that what i think it is? |
| 18:37 | <~Vornicus> | what do you think it is |
| 18:41 | < Emmy> | actual 3d terrain in OTTD? |
| 18:41 | < Emmy> | or rather, a prototype of it |
| 18:41 | <~Vornicus> | It is exactly what you think it is, then |
| 18:53 | <~Vornicus> | 8 pages of notebook paper, 70 lines of lua, 180 lines of shaders, one texture, one heightfield, and for the first time I've actually used what I learned in calc 3 two decades ago in anger. |
| 19:18 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 19:20 | | catalyst_ [catalyst@Nightstar-v6lb30.cable.virginm.net] has quit [[NS] Quit: -a- Connection Timed Out] |
| 19:20 | | catalyst [catalyst@Nightstar-v6lb30.cable.virginm.net] has joined #code |
| 19:21 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 19:22 | < Emmy> | Heh. i always use my math in anger |
| 20:14 | <&ToxicFrog> | Ooooooooooooooo |
| 20:22 | <@TheWatcher> | Shiny! |
| 20:25 | < Emmy> | Fuck |
| 20:25 | < Emmy> | shit |
| 20:25 | < Emmy> | i made the second-most basic mistake in KSP |
| 20:25 | < Emmy> | I got to the moon |
| 20:25 | < Emmy> | i landed safely |
| 20:25 | < Emmy> | ...but forgot to bring enough fuel to get home X( |
| 20:34 | | catalyst [catalyst@Nightstar-v6lb30.cable.virginm.net] has quit [Ping timeout: 121 seconds] |
| 20:36 | < Emmy> | I did not math correctly. :( |
| 20:36 | | catalyst_ [catalyst@Nightstar-bv8m4t.dab.02.net] has joined #code |
| 20:37 | <&ToxicFrog> | welp |
| 20:37 | <&ToxicFrog> | time for a rescue mission! |
| 20:41 | <@TheWatcher> | ? |
| 20:41 | <@TheWatcher> | Is Jeb stranded in orbit? |
| 20:43 | <&McMartin> | Sounds like on the mun |
| 20:46 | | catalyst [catalyst@Nightstar-v6lb30.cable.virginm.net] has joined #code |
| 20:47 | | catalyst_ [catalyst@Nightstar-bv8m4t.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 20:58 | <~Vornicus> | one time I didn't have enough fuel for the reentry burn so I used jeb in an eva suit pushing on the front of the thing to get low enough for aerobraking |
| 20:58 | <~Vornicus> | like ten times |
| 21:03 | <~Vornicus> | and even then it took sewveral aerobraking runs, etc |
| 21:20 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 21:21 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 21:51 | < Emmy> | Yup, been there, but this time i can't even get off the moon |
| 21:52 | <&Reiver> | Vornicus: Hot damn, well done! |
| 22:04 | <~Vornicus> | Having now finished my anger I have a giant ass list of Features I want to add: I want to see about possibly sharpening it up by lengthening the velocity vectors, add some camera controls, picking... |
| 22:58 | <&McMartin> | jerith: OK, so if I understand your critique here, it's that you've been forced to skip error checking within the function because even in the error case you need to have the (not entirely usable) object returned? |
| 23:12 | <&jeroud> | No, I choose to skip the error checking because the only possible value is can provide there is to return nil instead of an initialised value and since I can't actually trigger a failure in tests I'd end up with untested (albeit trivial) error handler that reduces my test coverage number. |
| 23:13 | <&McMartin> | My initial reaction is "that sounds like a place where you design in a "if this ends up being able to fail later, have it panic since there's no way to continue if it fails"... am I missing something? |
| 23:13 | <&jeroud> | But if I return nil with an error at least the caller will explode dereferencing the nil if it doesn't bother to check for the error. |
| 23:13 | <&McMartin> | (besides "ew, exceptions", which I entirely understand and agree with) |
| 23:14 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Ping timeout: 121 seconds] |
| 23:17 | <&jeroud> | Both the caller and the setup code for the object I return belong to the framework, so I don't control that behaviour. |
| 23:21 | <&McMartin> | Aha, OK. |
| 23:21 | <&jeroud> | My options here are "return error from setup call along with potentially uninitialized object and hope the caller does the right thing" or "write the usual boilerplate conditional whose only purpose is to replace the potentially uninitialized object with nil, and live with a code path that cannot be tested because it's not possible to trigger a failure". |
| 23:22 | | * McMartin nods. |
| 23:23 | <&McMartin> | You've taught me a fair amount about how one can make things more testable by pushing things into separate functions. This function is small enough, and dealing as it does with literals, I see no real way to break it into multiple functions, unless, I suppose, one made the ability to call "Setup" somehow parameterized. |
| 23:23 | <&McMartin> | (If it's not clear, I'm not trying to challenge you here, but rather to work through it out loud) |
| 23:24 | <&jeroud> | (Neither of those are acceptable to me, so I chose the one that at least reduces the number of test coverage gaps I have to look at every time I touch that file to see if it's new or not.) |
| 23:25 | <&jeroud> | Yeah, golang makes factoring stuff out into separate functions much harder. |
| 23:26 | <&jeroud> | This is a complaint I have about Rust as well, albeit in a much weaker form. |
| 23:27 | <&jeroud> | Having to put type information in all function signatures increases the cost of breaking out little functions. |
| 23:28 | <&jeroud> | But in Rust I can at least make those generic and reuse them. |
| 23:29 | | * McMartin nods |
| 23:30 | <&McMartin> | My current hobby project went a little off the rails while I was seat-of-the-pants-ing it in C, so I switched to Golang both for drill and because it had static executables and PNG support batteries-included |
| 23:30 | <&McMartin> | Now I'm hitting its limits but in ways that are slightly more interesting to me, so now I'm trying to devise a discipline for semi-generic stuff that makes it work |
| 23:31 | <&McMartin> | ... when what I *should* do is take the lessons learned about how this should be designed back into C >_> |
| 23:32 | <~Vornicus> | I have found the restrictions and simplicity of glsl interesting and relaxing these past couple of weeks. It ...does help that I'm doing things it's designed to do |
| 23:32 | <&jeroud> | For that particular tiny function, there's no problem in Python (because setup throws an exception so there's no partial value to deal with) or Rust (because we return a result type that the caller must unwrap) or Elixir (because pattern matching on a result tuple is so ubiquitous that the static analysis tools complain about not doing it). |
| 23:33 | <&McMartin> | Vornicus: Hey, this means you can probably actually read over my terrain code! |
| 23:34 | <&McMartin> | (Which won't run from Dropbox, but: https://www.dropbox.com/s/z4frv49ivn7tr6m/terrain.html?dl=0 ) |
| 23:35 | <~Vornicus> | frankly I could've probably done that before reading literally any of the glsl spec, it's super crazy straightforward except for the column thing |
| 23:35 | <&jeroud> | McMartin: Learning golang and exploring its deficiencies is a worthwhile exercise in and of itself. |
| 23:35 | <&McMartin> | Right |
| 23:36 | <&jeroud> | Doing so in a production codebase with a deadline... not so much. |
| 23:36 | <&McMartin> | But remember, one of my schticks is "Disciplines exist to compensate for deficiencies", and the complaints I've heard about golang suggest that Golang's deficiencies are *fundamental* in ways I'm not as used to seeing. |
| 23:36 | <&McMartin> | I'm probably going to end up trying to build what in Rust would be a simple Vec<CustomEnum> |
| 23:36 | <&McMartin> | And (a) it's going to suck and (b) I'm not 100% convinced I can actually do it as stated, without warping it into something unrecognizable. |
| 23:37 | <&jeroud> | Hahahahahaha(good luck)hahahahaha. |
| 23:37 | <&McMartin> | My initial cut looks like it's going to be a []interface{} that you typeswitch on. |
| 23:37 | <&McMartin> | Which will look a lot like the awful Java "typesafe enums" that are neither particularly typesafe nor particularly enums |
| 23:37 | <&jeroud> | It can be done if you don't mind pages of unchecked cast warnings from the compiler. |
| 23:38 | <&McMartin> | ... this may have improved recently then |
| 23:39 | <&McMartin> | switch foo := bar.(type) { } at least claims to cast foo to the type in each case branch. |
| 23:40 | <&jeroud> | The type switch stuff works if you actually have the type information available, and that's not always the case. |
| 23:40 | <&jeroud> | Except I don't recall the details. |
| 23:40 | <&McMartin> | For the construct I am trying to mimic, I am basically OK with insisting ont hat. |
| 23:41 | <&McMartin> | (Since the construct I'm aiming for here is basically C discriminated-unions) |
| 23:41 | <&jeroud> | I know that when I tried to write a generic map() function a few years ago It Could Not Be Done, and I'm pretty sure it still can't. |
| 23:42 | <&McMartin> | If it wasn't clear, I wasn't trying to talk generic above |
| 23:42 | <&jeroud> | So your particular case might be doable, and I'd be interested in seeing the result either way. |
| 23:43 | <&McMartin> | I mean "I have a need for something I would normally represent in Rust, Haskell, or C as an enum (R/H) or discriminated union (C), and Go doesn't support those directly, nor does it really support the kind of OO that often replaces it in languages like Java" |
| 23:43 | <&McMartin> | So I want to make Go do it both ways, more or less, and then do it the enum way because if I have the choice that's the one I'll basically always choose. |
| 23:45 | <&jeroud> | Yeah, but storing things in collections and moving things across function boundaries are two places where the type system is the most hostile. |
| 23:45 | <&McMartin> | Yeah, I can imagine |
| 23:46 | <&McMartin> | I also want to investigate whether psychopathically aggressive use of interfaces, 90s-C++ style, lets you get around that |
| 23:46 | <&jeroud> | Although now I'm way past "this is a thing I know/remember" and deep into "I have vague feelings of dread based on past experiences". |
| 23:46 | <&McMartin> | but fuck 90s-C++ style |
| 23:46 | <&jeroud> | What do you mean by that? |
| 23:47 | <&McMartin> | class CFoo : public IFoo { ... } |
| 23:47 | <&McMartin> | Where IFoo is an abstract class whose interface exactly matches CFoo's |
| 23:47 | <&McMartin> | My experience so far with Golang suggests that the reason dealing with structs sucks so much is because they are not also interfaces, because that smacks of OOP and OOP is bad |
| 23:48 | <&jeroud> | Ah. The Golang Way is lots of single-method interfaces. |
| 23:48 | <&McMartin> | And even while I think OOP is bad, that part wasn't the problem. |
| 23:49 | <&McMartin> | Right, and then you'd return "slice of brand new interface that lists all the interfaces that the objects need to be" |
| 23:49 | <&McMartin> | Possibly with an extra layer of indirection. I forget if interface types are already pointers. |
| 23:49 | <&jeroud> | The thing is, mapping interfaces to objects is implicit and is based only on signatures. |
| 23:50 | <&jeroud> | More than one builtin interface has void "marker" methods just to differentiate this particular thing from all the other thing that have a Read() method. |
| 23:51 | <&McMartin> | Heh. That would do the trick for a thing I wasn't going to attempt. |
| 23:51 | <&jeroud> | Oh, and there's also the fun involving typed and untyped nils. |
| 23:52 | <&jeroud> | (Look at the process signal interface in the stdlib for an example of the marker method thing.) |
| 23:52 | <&McMartin> | Yeah. Because I'm trying to crowbar in a more limited construct, I have a couple of things going for me |
| 23:52 | <&McMartin> | - never nil |
| 23:52 | <&McMartin> | - set of valid alternatives is part of the public spec |
| 23:53 | < catalyst> | I thought the golang way was to take the best the 70s had to offer and paste whatever Rob's been thinking of the part few decades on top |
| 23:53 | < catalyst> | past* |
| 23:53 | <&McMartin> | - each element of the public spec is purely data and all of it is public |
| 23:53 | <&McMartin> | Because this is fundamentally a binary chunk parser where I want to return a collectino of "here yor chunx" |
| 23:53 | <&McMartin> | catalyst: Too vague to get a working spec out of |
| 23:54 | < catalyst> | hm? |
| 23:55 | <&jeroud> | Empirically, The Golang Way is to take a moral stand on something and then quietly walk halfway back on that while pretending not to. |
| 23:56 | <&McMartin> | catalyst: Basically I have a thing that I can do idiomatically in very similar ways in Rust, C, and Haskell, and then idiomatically in a much less similar way in Java, C#, etc. Golang can't do either, sensibly, directly. |
| 23:56 | <&McMartin> | But the key word there is "directly", and I'm hoping to devise mechanisms to express both techniques. |
| 23:57 | < catalyst> | ah, that's no good |
| 23:57 | <&McMartin> | (pattern-matching enum switch in Rust, multiple independent implementations of a single interface in Java) |
| 23:57 | < catalyst> | wait, go doesn't have enums? |
| 23:57 | <&McMartin> | Not the kind I want |
| 23:57 | < catalyst> | oh right, you want variants I guess |
| 23:58 | < catalyst> | doesn't go have anonymous interfaces? |
| 23:58 | <&McMartin> | Yeah. But Golang *does* have typeswitch, which means I can ignore interfaces and just use concrete public types to do what I want |
| 23:58 | <&McMartin> | Yep, my current initial plan is typeswitch on an anonymous interface that promises outside of the compiler's vision to only have elements of eight particular types |
| 23:58 | < catalyst> | this sounds like the kind of thing that makes me cry out in slow |
| 23:58 | <&McMartin> | Er, on an empty interface rather |
| 23:59 | <&McMartin> | Yeah, I'm aware that this is doing something not unlike writing your own vtable strutures in C |
| --- Log closed Wed May 13 00:00:10 2020 |