| --- Log opened Wed Oct 02 00:00:11 2019 |
| 00:00 | <&McMartin> | Whoa |
| 00:00 | <&McMartin> | "Syntactic support for async-await is now available in the Rust beta channel" |
| 00:09 | <&McMartin> | Oddly enough, and despite utterly lacking it, it's Golang that's convinced me that we're probably good enough to get away with async-await generally |
| 00:09 | <&McMartin> | Because we clearly have worked out "shitloads of cheap coroutines", which is what you need for that. |
| 00:14 | <&jeroud> | Erlang did that a quarter-century ago.~ |
| 00:15 | <&McMartin> | Scheme considers it an array of continuations and likewise extremely unimpressed |
| 00:15 | <&McMartin> | This is why neither Erlang nor Scheme gets invited to parties~ |
| 00:16 | <&jeroud> | McMartin: But https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ has some very interesting ideas. |
| 00:16 | <&McMartin> | I think my serious answer is "We've known it was theoretically possible for a very long time. Go is the language that convinced me that any jackass can get it working if properly resourced" |
| 00:16 | <&McMartin> | And that it isn't a case of "with sufficient thrust, pigs fly just fine" |
| 00:16 | <&McMartin> | Or isn't anymore. |
| 00:17 | <&McMartin> | After all, my objection to async/await is fundamentally no different to the old objections to symbolic assemblers. |
| 00:23 | <&McMartin> | jeroud: I'm going to get mad at this article a lot about its history and theory, I can tell~ |
| 00:24 | <&McMartin> | Python's "with" is not some amazing modern invention made possible by structured programming, it's a weaker version of Lisp's unwind-protect |
| 00:24 | <&McMartin> | (Lisp also isn't invited to parties~) |
| 00:24 | <&McMartin> | He brings up exceptions but fails to note that they actually produce the exact problem he held made goto infeasible |
| 00:25 | <&jeroud> | McMartin: Sure, njs is using the languages he's familiar with (and expects his audience to be familiar with) as background. |
| 00:27 | <&McMartin> | "Before, we said that we were "guaranteed" that the file will be open while the ... code is running, and then closed afterwards. But what if the ... code spawns a background task? Then our guarantee is lost: the operations that look like they're inside the with block might actually keep running after the with block ends, and then crash because the file gets closed while they're still using it" <-- probably |
| 00:27 | <&McMartin> | true in Go, but false in the general case for at least two reasons, one of which applies to Go |
| 00:28 | <&McMartin> | (You can prove syntactically that that `file_handle` doesn't escape; any RAII-like system combined with thread-safe garbage collection allows the relevant guarantees otherwise) |
| 00:28 | <&McMartin> | And as you said, "using the languages he knows" |
| 00:28 | <&McMartin> | The ARC system in Objective-C and Swift manages this for memory resources and it can do RAII-like things if necessary. |
| 00:29 | <&jeroud> | He's also generalizing a lot to avoid getting lost in the weeds. |
| 00:29 | | * jeroud thinks. |
| 00:29 | <&McMartin> | I don't consider "every iPhone app" the weeds, but then, I wouldn't. |
| 00:29 | <&McMartin> | More seriously, and this would require research I don't have time to do |
| 00:30 | <&McMartin> | I suspect he may have reinvented Ada's "rendezvous" primitive |
| 00:32 | <&jeroud> | https://vorpus.org/blog/some-thoughts-on-asynchronous-api-design-in-a-post-asyncawait-world/ might be a better starting point. It predates his implementation of those ideas, but goes into a lot more depth about the various properties of callback vs async/await concurrency models. |
| 00:32 | <&McMartin> | I'm in favor of this, as Ada's gotten the last laugh on a huge number of topics while being constantly derided |
| 00:34 | <&jeroud> | The broad idea there is "spawn() is the concurrency equivalent of GOTO and has all the problems of GOTO, here's what I think we could do to make it more structured". |
| 00:38 | <&McMartin> | Yeah |
| 00:38 | <&McMartin> | And the argument is implying that he's strictly adding power with this rendezvous operation, so I went to check the JS promise library, which I now consider the definitive one for "mainstream use" |
| 00:38 | <&McMartin> | The primitive he's missing in Python is Promise.all(). |
| 00:39 | <&jeroud> | I think this is less clear-cut than GOTO (and not just because the GOTO thing was settled long before I wrote my first line of code) and there's still a whole lot of distributed systems stuff off to the side that he's ignoring. |
| 00:39 | <&McMartin> | (Personal bias caveat: he seems to think exceptions are actually good and make structuring clean black boxes easier, and I disagree with pretty much maximum possible vehemence. There is only one modern programming construct I think is worse than exceptions when it comes to being The Principle of Maximum Surprise, and it is nowhere near as prevalent.) |
| 00:40 | <&McMartin> | (And by modern I of course mean "Common Lisp has had it for decades", but hidey-ho) |
| 00:40 | <&jeroud> | The premise of the argument isn't "let's add if/while/call", it's "let's get rid of GOTO". |
| 00:40 | <&McMartin> | Right, but he clearly considered exceptions to be part of getting rid of GOTO |
| 00:42 | <&McMartin> | as opposed to "a kind of GOTO that interoperates with precise destructors/with statements/unwind-protects" |
| 00:43 | <&jeroud> | My experience with exceptions seems to have been much friendlier than yours. |
| 00:44 | <&jeroud> | But I've only ever used them in Java-style and Python-style languages. |
| 00:45 | <&McMartin> | Java made an attempt to solve this, but only went halfway. |
| 00:46 | <&McMartin> | The problem with Java is that if you call a function, you have literally no idea whether or not you need to wrap it in a try block, beyond its documentation. |
| 00:46 | <&McMartin> | A subset will tell you -- the checked exceptions |
| 00:46 | <&McMartin> | Checked exceptions went over like a lead balloon |
| 00:46 | | * jeroud nods. |
| 00:46 | <&McMartin> | So the question is "if I call this function, will execution resume at the next statement", right? GOTO breaks that and that's why GOTO is unconscionable? |
| 00:47 | <&McMartin> | Any program that allows exceptions explicitly revokes that guarantee. |
| 00:47 | <&jeroud> | But it revokes it in a much more controlled way than GOTO does. |
| 00:47 | <&McMartin> | Third party libraries tend to be extremely lackadaisical about marking what operations might in fact result in an unchecked exception being thrown. |
| 00:47 | <&McMartin> | Yes, in practice, it revokes it by calling abort() =P |
| 00:48 | <&McMartin> | This is a bigger deal when you aren't Erlang. |
| 00:48 | <&McMartin> | My preferred approach, for the record, is Haskell's Either type, which Rust has copied as its Result<T, E> generic. |
| 00:49 | <&McMartin> | Essentially an error code that the compiler forces you to check. |
| 00:49 | <&jeroud> | And I should note that trio (his async framework) is extremely careful about when sequence/cancellation points can appear. |
| 00:49 | <&jeroud> | Yeah, result types are better than exceptions the same way option types are better than nulls. |
| 00:50 | <&McMartin> | I'd say that with s/exceptions/error codes/ |
| 00:51 | <&jeroud> | And Rust's ? operator makes them extremely ergonomic. I do not miss exceptions at all in Rust. |
| 00:52 | <&McMartin> | Yup. |
| 00:52 | <&McMartin> | Swift pretends to have exceptions, but they translate to unchecked Result types in Objective-C. It is useful, hilarious, and tragic all at once. |
| 00:53 | <&jeroud> | True, but I think it applies to exceptions as well. You can never be burned by an untrapped exception because the compiler requires you to handle or explicitly pass up the stack. |
| 00:53 | <&McMartin> | Yup. |
| 00:54 | <&McMartin> | Meanwhile, you can use panics to recreate exceptions if you have to, but you won't. |
| 00:54 | <&McMartin> | Except in Golang, where you *totally will* |
| 00:54 | <&jeroud> | Because checking for an error is three lines of boilerplate. |
| 00:55 | <&jeroud> | Go's panics are horrifically unergonomic exceptions. Rust's panics are actually panics. |
| 00:57 | <&jeroud> | (The difference being that Rust gives you a toolbox full of things you'd much rather use, whereas Go gives you optional extra return values and an apathetic compiler.) |
| 00:58 | <&jeroud> | (Oh, and a bunch of special cases in the compiler and builtin functions.) |
| 00:59 | <&McMartin> | (Also := vs =, which the compiler *does* aggressively enforce, because Go is as we all know all about not having to restate yourself in finicky ways until a compiler is satisfied.) |
| 01:01 | <&jeroud> | (I've always considered it a mark of extremely poor design when you need to break your own semantic rules just to have a working implementation.) |
| 01:02 | <&McMartin> | (The degree to which Rust does not do that -- even if I consider `unsafe` to be breaking its own rules -- is the thing that first earned my respect) |
| 01:02 | <&jeroud> | (Rust doesn't have to break any rules because it has macros and unsafe, both of which are available to library code.) |
| 01:03 | <&McMartin> | (Yeah, it's important to note that I was actually a researcher during and just after the era where the work that informs Rust was done. Rust is the first serious implementation of a real standard library hewing to those rules and not requiring unsafe for most of it.) |
| 01:03 | <&McMartin> | (Doing it at all was impressive enough; doing it without unsafe except for the base memory management is gobsmacking in ways that it is hard to express here in 2019.) |
| 01:05 | <&jeroud> | (OCaml has one tiny rulebreak, which is a builtin function somewhat akin to unsafe in purpose: Obj.magic is an identity function with a completely generic return value.) |
| 01:06 | <&McMartin> | (Yeah. I don't grant OCaml or SML/NJ's stdlib the dignity of "full modern stdlib", at least not in their state in the early aughts.) |
| 01:07 | <&jeroud> | (So you can Obj.magic anything into anything else. It's an incredibly powerful footgun that is utterly indispensable for certain kinds of FFI work.) |
| 01:07 | | * McMartin nods |
| 01:07 | <&McMartin> | I've tried on several occasional to use OCaml for stuff, but at this point anything I'd consider doing in OCaml I'd do in Rust instead. |
| 01:08 | <&McMartin> | *occasions |
| 01:08 | <&jeroud> | Yeah. |
| 01:08 | <&ToxicFrog> | McMartin: I have hella exceptions to async-await and I'm very sad that Rust is adopting that rather than proper coroutines |
| 01:09 | <&McMartin> | Adopting proper coroutines would involve changing the implementation of the already existing multithreading primitives, would it not? |
| 01:10 | <&jeroud> | I really like OCaml, but I decided long ago that it's not particularly practical to use in production. |
| 01:10 | <&McMartin> | This has made me cranky because it has a number of production uses, but they're all in places that reinforce my prejudice about what it doesn't scale to |
| 01:11 | <&McMartin> | Which is annoying because its obvious innovation nobody copies isn't *obviously* a bad idea, but also has no publically available examples of excellent use, and the talks about propriatery usage sounds like they don't go near that part anyway. |
| 01:12 | <&jeroud> | What's the obvious innovation? |
| 01:12 | <&ToxicFrog> | McMartin: it probably would, yes, but "we can't do it right without a lot of work so we'll do it badly instead" is what got us the total shitshow that is async/await in JS, so |
| 01:12 | <&McMartin> | "ML Structures and Functors: surely they are good for something, right?" is a terrible talk title. But it's the one I want desperately to hear. |
| 01:12 | <&jeroud> | Remind me what Structures are? |
| 01:13 | <&McMartin> | ToxicFrog: Possibly relevant: My experience with actual sync/await is from C#, where it is fine and also On Top Of The Library instead of core to it. |
| 01:13 | <&McMartin> | jeroud: Basically namespace-like things, which can become template-like things when Functorialized. |
| 01:13 | <&jeroud> | OCaml's Functors are basically functions that return modules. |
| 01:14 | <&McMartin> | Yeah. Structures are basically those modules, without the function part. |
| 01:14 | <&McMartin> | They are described as the things that let ML program in the large |
| 01:14 | <&ToxicFrog> | Re exceptions -- I do think they have a place; the compiler forcing you to manually check every return code results in a large amount of tedious boilerplate to implement things like "yes, if I can't allocate memory the program should crash", usually while throwing away useful information about the error instead; and if you have return codes but the compiler doesn't enforce that your program |
| 01:14 | <&ToxicFrog> | just ends haunted, which is even worse. |
| 01:14 | <&jeroud> | And it's how things like maps and sets work. |
| 01:14 | <&ToxicFrog> | McMartin: I haven't used them in C#, but in JS the problems with them are mostly (but not completely) described by "what colour is your function?" |
| 01:14 | <&McMartin> | I have never seen any example of them actually serving to program in the large, instead of defining medium-sized data structures. |
| 01:15 | <&McMartin> | ToxicFrog: Yes. That article -- which says the right thing is to go back to threads, which is some serious grass-is-greener shit if ever I saw any -- also touches on C# there, and notes that C# doesn't have this problem specifically because no library functions are red. |
| 01:16 | <&ToxicFrog> | McMartin: yeah, I disagree with its conclusion ("abandon async/await in favour of OS threads") but I agree with its analysis of the problem. |
| 01:16 | <&McMartin> | (And acknowledges in passing that async/await as C# does it also doesn't have the problem because red functions are not particularly harder to call, as it involves adding two tokens to some of your functions) |
| 01:16 | <&ToxicFrog> | That only helps until you want to write an async function yourself, and now you're back in hell. |
| 01:17 | <&McMartin> | Yeah, I don't consider it a huge imposition to write a sync library and then an async wrapper around it. |
| 01:17 | <&ToxicFrog> | But now everything that wants to call the async wrapper needs to be properly async-annotated itself... |
| 01:17 | <&jeroud> | I have found async/await in Python to be significantly nicer than the alternatives. |
| 01:18 | <&McMartin> | Yeah, see, when you apply this to C#, this is like objecting to the "public" keyword. |
| 01:18 | <&McMartin> | Since it also propagates like that~ |
| 01:18 | <&jeroud> | But I have used the "defer to thread" equivalent in a bunch of places. |
| 01:18 | <&McMartin> | Oh, also, I'd need to check on it |
| 01:18 | <&McMartin> | but I *believe* that sync functions can call async functions in C#. |
| 01:18 | <&McMartin> | They return a promise in that case, which you can then block on. |
| 01:20 | <&McMartin> | As long as you have a decent set of combinators, I'm also OK with promise-based programming, though, so. |
| 01:20 | <&jeroud> | The key to making function colour work is to never have any sync functions that block for any meaningful amount of time. |
| 01:20 | <&McMartin> | The recent articles have convinced me that Promise.all() is an absolute requirement. |
| 01:21 | <&jeroud> | What does that do? |
| 01:21 | <&McMartin> | Takes a list of promises P1-Pn and returns a promise Q. If any of P1-Pn fail, Q fails with the first failure received. If all of P1-Pn succeed, Q succeeds with the unit value. |
| 01:21 | <&McMartin> | Or possibly a tuple of all success results from P1-Pn. |
| 01:22 | <&jeroud> | From the name, I'd expect something like "wait on a bunch of promises and return when they're all done". |
| 01:22 | <&McMartin> | That is indeed what it does. |
| 01:22 | <&jeroud> | Yeah, that. |
| 01:23 | <&McMartin> | A nursery in the first article you linked is a Promise_all that can be added to over time and that which puts the cleanup code in both the success/fail branches of Q. |
| 01:23 | <&jeroud> | I have never encountered a promise-based system without it. |
| 01:23 | <&McMartin> | C++11, alas, which also doesn't have asynchronous futures. |
| 01:23 | <&McMartin> | But has "futures"/promises nevertheless |
| 01:23 | <&McMartin> | But the only way to get the value out is with a synchronous blocking operation. |
| 01:24 | <&McMartin> | Less flippantly, a lot of handmade systems designed to make traditional async io usable end up having incomplete promise systems as their API. |
| 01:24 | <&McMartin> | One would expect those to fade away as the code is refactored to actually use available async APIs. |
| 01:25 | | * iospace mauls McMartin |
| 01:25 | <&McMartin> | OTOH, as noted, with appropriate use of RAII and heap-aware refcounting systems, the specific problems nurseries were created to solve won't come up, as each promise will retain its resources independently without a central abstraction point. |
| 01:26 | | * McMartin sends The Geese to misplace all of iospace's stuff |
| 01:27 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 01:27 | | * iospace finds her stuff now masterfully organized |
| 01:27 | <@iospace> | :V |
| 01:29 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| 02:08 | <@celmin|away> | [Oct 01@7:24:09pm] McMartin: Python's "with" is not some amazing modern invention made possible by structured programming, it's a weaker version of Lisp's unwind-protect |
| 02:08 | <@celmin|away> | [Oct 01@7:28:02pm] McMartin: (You can prove syntactically that that `file_handle` doesn't escape; any RAII-like system combined with thread-safe garbage collection allows the relevant guarantees otherwise) |
| 02:08 | <@celmin|away> | Python's "with" basically is an RAII-like system, right? |
| 02:09 | <&McMartin> | The differences are enough to break that use case. |
| 02:13 | <@celmin|away> | McMartin: (Personal bias caveat: he seems to think exceptions are actually good and make structuring clean black boxes easier, and I disagree with pretty much maximum possible vehemence. There is only one modern programming construct I think is worse than exceptions when it comes to being The Principle of Maximum Surprise, and it is nowhere near as prevalent.) |
| 02:13 | <@celmin|away> | Now I'm curious... what is that one construct? |
| 02:14 | | celmin|away is now known as celticminstrel |
| 02:14 | <&McMartin> | Aspect-Oriented Software Development. The thing Common Lisp had as before/after annotations on its multimethods. |
| 02:15 | <&McMartin> | It is almost literally an OOP implementation of COME FROM |
| 02:15 | <@celticminstrel> | I seem to vaguely recall once reading a proposal for aspects in C++... |
| 02:29 | <@celticminstrel> | So anyway, I seem to recall comparing JS and Lua once and finding that there are one or two things I prefer about JS, but I can't remember what they were anymore... |
| 02:34 | < catalyst> | exceptions are the logical extension of the logic that leads to you not wanted to deal with error cases all the way up the chain of calls |
| 02:34 | < catalyst> | but, honestly, they're vastly over-used by most programming languages |
| 02:47 | | catalyst [catalyst@Nightstar-5dv16h.cable.virginm.net] has quit [[NS] Quit: Leaving] |
| 02:47 | <@Alek> | arg. |
| 03:35 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has quit [[NS] Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] |
| 03:58 | | Reiv [NSkiwiirc@Nightstar-ih0uis.global-gateway.net.nz] has joined #code |
| 03:58 | | mode/#code [+o Reiv] by ChanServ |
| 05:50 | | celticminstrel [celticminst@Nightstar-ocfc15.dsl.bell.ca] has quit [[NS] Quit: And lo! The computer falls into a deep sleep, to awake again some other day!] |
| 08:24 | <@ErikMesoy> | My coworker is very annoyed that he can't run my java file. Investigation has revealed that he's running Java 9 according to cmd java -version, trying to run a thing I created in Java 13. He goes to to switch/upgrade, and in the process discovers that his environment variables point to /java_11/bin/. Control Panel -> Uninstall meanwhile detects Javas 9 and 10. |
| 08:26 | <&McMartin> | Does your Java 13 thing actually require Java 13 features, or can you set targetsdk at build time? |
| 08:27 | <&McMartin> | (If you have not, I would observe that it is Polite to target Java 8 if you aren't using anything later than that, as 8 is the last one with proper open licenses.) |
| 08:29 | <@ErikMesoy> | I shall look into finding how to set that, because I don't think I'm using anything very advanced, I just picked up latest stable version by default. Meanwhile coworker has opened Apps Overview to see if he got rid of the profusion of Javas, and _that_ screen has found a Java 8 somewhere on his computer. |
| 08:30 | <@ErikMesoy> | It seems to be just "-target 8" at terminal, warning but not error. |
| 08:30 | <@ErikMesoy> | That was painless. If it works. |
| 08:36 | <@ErikMesoy> | --release 8 isn't even a warning. Nice. |
| 08:52 | <@ErikMesoy> | Fascinating. Coworker has resorted to asking for my source file, and he can *compile* that but not then *run* it on his machine somehow. He's blaming Windows for being general trash and blaming me for stubbing a file in N++ instead of using a proper IDE. I'm blaming him for having 5+ versions of Java installed and trashing his own setup. |
| 09:04 | <&McMartin> | The acid test is to install openjdk8 on some VM and see if it runs there. |
| 09:33 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 09:33 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 09:57 | | You're now known as TheWatcher[d00m] |
| 12:16 | | You're now known as TheWatcher |
| 13:18 | | Degi [Degi@Nightstar-p7dg31.dyn.telefonica.de] has joined #code |
| 13:20 | | celticminstrel [celticminst@Nightstar-ocfc15.dsl.bell.ca] has joined #code |
| 13:20 | | mode/#code [+o celticminstrel] by ChanServ |
| 13:20 | | You're now known as TheWatcher[d00m] |
| 13:35 | | Degi [Degi@Nightstar-p7dg31.dyn.telefonica.de] has quit [Connection closed] |
| 13:35 | | Degi [Degi@Nightstar-p7dg31.dyn.telefonica.de] has joined #code |
| 13:35 | | celticminstrel is now known as celmin|away |
| 13:44 | | Degi [Degi@Nightstar-p7dg31.dyn.telefonica.de] has quit [Connection closed] |
| 13:45 | <&jeroud> | Aside from result types, what error management mechanisms are better than exceptions? |
| 13:46 | <&jeroud> | Because I'm pretty confident that checking return values everywhere (C-style and Go-style both) is worse. |
| 14:03 | | Degi [Degi@Nightstar-p7dg31.dyn.telefonica.de] has joined #code |
| 14:19 | | Degi [Degi@Nightstar-p7dg31.dyn.telefonica.de] has quit [Connection closed] |
| 16:13 | | You're now known as TheWatcher |
| 16:17 | <@TheWatcher> | Obviously the most bestest error management mechanism is to ignore problems and continue regardless~ |
| 16:19 | | * TheWatcher nods sagely |
| 16:20 | <@TheWatcher> | If it's good enough for the government, it should be good enough for anyone! >.> |
| 16:22 | | catalyst [catalyst@Nightstar-5dv16h.cable.virginm.net] has joined #code |
| 16:23 | <@ErikMesoy> | Last week, coworker and I agreed to cooperate on a joint Java project as a part of Internal Workplace Continual Competence Improvement, aka, make sure your fucking-around time between assignments is spent on something with a resume-friendly keyword. So we're building a space game in Java. |
| 16:24 | < catalyst> | spaaaaaaace |
| 16:24 | <@TheWatcher> | catalyst: what is best error management mechanism in life? |
| 16:24 | <@ErikMesoy> | Coworker took the lead to standardise tools, telling me to install IntelliJ IDE, configure GitHub, and he's been spending his time looking into Maven and Gradle and I-would-say-a-silly-fake-name-but-someone-has-no-doubt-named-their-tool-that. |
| 16:24 | < catalyst> | TheWatcher: well, for most of the history of life, death has been |
| 16:25 | <@TheWatcher> | ... well, that went dark quickly. |
| 16:25 | < catalyst> | the things that work life and thrive and the ones that don't die |
| 16:25 | < catalyst> | live* |
| 16:25 | <@TheWatcher> | ErikMesoy: so, the difficult question: |
| 16:25 | < catalyst> | you could argue that if a case is exceptional enough to require an exception and not normal code paths, you should let the process die in as graceful a way as possible and reset the system :P |
| 16:26 | <@TheWatcher> | What're you calling it? |
| 16:26 | <@ErikMesoy> | Untitled Space Game. |
| 16:26 | < catalyst> | HONK |
| 16:27 | <@ErikMesoy> | Coworker has now spent most of the past week looking at various game design frameworks and helper tools like Tiled and LWJGL. So far he's rejected them all and gotten nowhere. I've suggested "How about Swing, the builtin?" and he looked at it and thought it was an ugly, too-lightweight thing fit for dialog boxes but not game interfaces. |
| 16:27 | <@TheWatcher> | FFS, just use Unity and say you're learning c# >.> |
| 16:28 | <@ErikMesoy> | Since then he's spent two more days looking at frameworks and rejecting them all as he wrestles with his IDE and his frameworks, I've been cowboy coding swing in Notepad++ and made a GUI, internal variables, active buttons, help menu, shown graphics, randomly generated starmap, drawn hyperlanes, automatic resize redraw. |
| 16:29 | <@ErikMesoy> | Almost all the features I've demoed up have come from an exchange with coworker where says something is proabably impractical in Swing since it's a lightweight builtin and not a proper library, then I go do it in Swing. |
| 16:29 | <@ErikMesoy> | Spite: the great motivator. |
| 16:30 | < catalyst> | x) |
| 16:31 | < catalyst> | tfw I'm building a game engine from scratch |
| 16:32 | < catalyst> | though that is mostly to learn the fundamentals of how the graphics tech works and make sure I have optimised mathematical primitives |
| 16:56 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has joined #code |
| 17:56 | <&jeroud> | I don't like writing game engines very much. |
| 17:56 | <&jeroud> | But I've only ever built them in somewhat inappropriate languages. |
| 17:57 | <&jeroud> | https://github.com/CTPUG/pyntnclick is the most successful. |
| 18:28 | | catalyst [catalyst@Nightstar-5dv16h.cable.virginm.net] has quit [Connection closed] |
| 20:37 | <&McMartin> | 08:26 <@TheWatcher> What're you calling it? |
| 20:37 | <&McMartin> | 08:26 <@ErikMesoy> Untitled Space Game. |
| 20:37 | <&McMartin> | 08:26 < catalyst> HONK |
| 20:37 | <&McMartin> | SPACE GOOSE |
| 20:37 | <&McMartin> | LOOSE TO VAMOOSE |
| 20:38 | <&McMartin> | 05:45 <&jeroud> Aside from result types, what error management mechanisms are better than exceptions? |
| 20:39 | <&McMartin> | Nothing comes to mind, though "checked exceptions" might be it. |
| 20:39 | <&McMartin> | ( |
| 20:39 | <&McMartin> | (I think "result types" are actually part of "checking return values everywhere" though, so) |
| 20:40 | <&McMartin> | (My objection to exceptions is less about ergonomics and more about analyzing the relevant code. Result types can be made as unergonomic as Go just by removing try! and ?.) |
| 20:40 | <&jeroud> | Result types are return values that you cannot fail to check. (Unless you call for side effects only, and even then the compiler can reliably catch it.) |
| 20:41 | <&McMartin> | Yeah. Modern C compilers all have annotations that yell at you when you don't do the check on those functions, and apply them to the standard library. |
| 20:41 | <&McMartin> | One can imagine faking it more thoroughly than people do. |
| 20:42 | <&McMartin> | And likewise, though, checked exceptions are exceptions that the compiler reliably enforces the rule that you must catch or explicitly rethrow them. |
| 20:42 | <&McMartin> | Which does relocalize the result; that way you no longer have to worry about some black box function calling six more functions and one of them doing a surprise nonlocal return. |
| 20:44 | <&McMartin> | This neatly defangs my primary objection to them, but in practice makes them even less ergonomic. |
| 20:45 | <&McMartin> | It also elides the use of exceptions explicitly *as* a nonlocal return, to implement backtracking in tree searches &c |
| 20:45 | <&McMartin> | Which as far as I can tell is only idiomatic and nondisastrous in ML. |
| 20:47 | <&McMartin> | (Which lack with statements and destructors, so try blocks and throws can use stack-cutting instead of unwinding, and have less register state than the C runtime needs for setjmp; as such, Ocaml could compile both try and throw into two x86 instructions each) |
| 20:48 | <@ErikMesoy> | Whoever did the marketing for Untitled Goose Game really deserves a raise. |
| 20:51 | <&McMartin> | Swift's 'exceptions' are actually restructured checked return values and I don't have my head around them yet. |
| 22:01 | <@abudhabi> | Man, every time I do some random stuff in python, I have to google the basics for just about everything, because I use it so infrequently I forget the syntax. |
| 22:37 | | Emmy [Emmy@Nightstar-9p7hb1.direct-adsl.nl] has quit [Connection closed] |
| 23:01 | | macdjord [macdjord@Nightstar-rslo4b.mc.videotron.ca] has joined #code |
| 23:01 | | mode/#code [+o macdjord] by ChanServ |
| 23:03 | | mac [macdjord@Nightstar-rslo4b.mc.videotron.ca] has quit [Ping timeout: 121 seconds] |
| 23:48 | | Pink [user1@Nightstar-g7hdo5.dyn.optonline.net] has joined #code |
| 23:50 | | Pinkhair [user1@Nightstar-g7hdo5.dyn.optonline.net] has quit [Ping timeout: 121 seconds] |
| --- Log closed Thu Oct 03 00:00:12 2019 |