| --- Log opened Thu Feb 09 00:00:39 2017 |
| 00:45 | | LadyOfLight` [catalyst@Nightstar-o0v30k.dab.02.net] has joined #code |
| 00:45 | | LadyOfLight [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has quit [[NS] Quit: Leaving] |
| 00:49 | | Derakon[AFK] is now known as Derakon |
| 00:52 | | LadyOfLight` is now known as LadyOfLight |
| 01:03 | | AverageJoe [evil1@Nightstar-lc3.hbj.189.210.IP] has joined #code |
| 01:34 | | * ToxicFrog gets sucked into writing install scripts for Oblivion mods |
| 01:36 | | AverageJoe [evil1@Nightstar-lc3.hbj.189.210.IP] has quit [Operation timed out] |
| 01:37 | <&ToxicFrog> | things I had not previously seen: languages with case sensitive mixed case keywords and extremely permissive parsers |
| 01:37 | <&ToxicFrog> | So, for example, this is valid: If <condition> Return EndIf <all the rest of your code> |
| 01:37 | <&ToxicFrog> | And this is also valid, but will never run your code: If <condition> Return Endif <all the rest of your code> |
| 01:38 | <&ToxicFrog> | Because if the condition is true, it returns, and if the condition is false, it reaches end-of-file looking for an EndIf (note case) and, not finding one, goes "oh, I guess that's the end then" and proceeds as if the script had exited normally. |
| 01:39 | <~Vornicus> | Um. |
| 01:39 | <&ToxicFrog> | I would bet cash money that this is a bespoke language the Wrye Bash author hacked together in an afternoon |
| 01:42 | <&ToxicFrog> | Anyways. Got the install script for the MB addons/patches working, that's probably enough hacking on it for one night. |
| 01:43 | <&ToxicFrog> | (my goal here is to make it easy -- or at least, less hard -- to install Morroblivion) |
| 01:44 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has quit [Connection closed] |
| 01:48 | | AverageJoe [evil1@Nightstar-lc3.hbj.189.210.IP] has joined #code |
| 01:49 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has joined #code |
| 01:49 | | mode/#code [+o Alek] by ChanServ |
| 02:11 | | AverageJoe [evil1@Nightstar-lc3.hbj.189.210.IP] has quit [Ping timeout: 121 seconds] |
| 02:49 | <&[R]> | I don't get why you wouldn't just use LUA or something else already written now-a-days. |
| 02:56 | | AverageJoe [evil1@Nightstar-lc3.hbj.189.210.IP] has joined #code |
| 03:51 | | AverageJoe [evil1@Nightstar-lc3.hbj.189.210.IP] has quit [[NS] Quit: Leaving] |
| 05:05 | | Derakon is now known as Derakon[AFK] |
| 06:02 | | LadyOfLight` [catalyst@Nightstar-je4.159.132.82.IP] has joined #code |
| 06:05 | | LadyOfLight [catalyst@Nightstar-o0v30k.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 06:14 | <@macdjord|slep> | ToxicFrog: .... AHHHHHHHHHHHHHHHHHHHHHH! |
| 07:13 | | celticminstrel is now known as celmin-of-nod |
| 07:20 | | Kindamoody[zZz] is now known as Kindamoody |
| 07:34 | | LadyOfLight` is now known as LadyOfLight |
| 08:15 | | himi-cat [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 08:22 | | Kindamoody is now known as Kindamoody|afk |
| 08:32 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
| 08:32 | | mode/#code [+o himi] by ChanServ |
| 08:38 | | LadyOfLight` [catalyst@Nightstar-je4.159.132.82.IP] has joined #code |
| 08:38 | | LadyOfLight [catalyst@Nightstar-je4.159.132.82.IP] has quit [The TLS connection was non-properly terminated.] |
| 08:39 | | LadyOfLight` is now known as LadyOfLight |
| 08:46 | | ion [Owner@Nightstar-6grqph.vs.shawcable.net] has quit [Ping timeout: 121 seconds] |
| 08:49 | | ion [Owner@Nightstar-6grqph.vs.shawcable.net] has joined #code |
| 08:49 | | mode/#code [+o ion] by ChanServ |
| 09:13 | | ion [Owner@Nightstar-6grqph.vs.shawcable.net] has quit [Ping timeout: 121 seconds] |
| 09:16 | | ion [Owner@Nightstar-6grqph.vs.shawcable.net] has joined #code |
| 09:16 | | mode/#code [+o ion] by ChanServ |
| 09:39 | | ion [Owner@Nightstar-6grqph.vs.shawcable.net] has quit [Ping timeout: 121 seconds] |
| 09:41 | | ion [Owner@Nightstar-6grqph.vs.shawcable.net] has joined #code |
| 09:41 | | mode/#code [+o ion] by ChanServ |
| 09:52 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 09:53 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
| 09:53 | | mode/#code [+o himi] by ChanServ |
| 10:35 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has quit [Operation timed out] |
| 12:32 | | LadyOfLight` [catalyst@Nightstar-tra4ap.dab.02.net] has joined #code |
| 12:35 | | LadyOfLight [catalyst@Nightstar-je4.159.132.82.IP] has quit [Ping timeout: 121 seconds] |
| 12:48 | | LadyOfLight` is now known as LadyOfLight |
| 13:11 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 13:46 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has quit [Ping timeout: 121 seconds] |
| 13:50 | | Alek [Alek@Nightstar-cltq0r.il.comcast.net] has joined #code |
| 13:50 | | mode/#code [+o Alek] by ChanServ |
| 15:38 | | macdjord|slep is now known as macdjord|wurk |
| 17:43 | < LadyOfLight> | ...I am coding C++ in a Reduct-ive style now |
| 17:43 | < LadyOfLight> | Hm |
| 17:44 | < LadyOfLight> | Oh shit I should go get ready for soccer |
| 17:46 | < LadyOfLight> | Also so far as I can tell, it is similar to idiomatic python |
| 17:49 | | celmin-of-nod is now known as celticminstrel |
| 18:23 | | Vornicus [Vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 18:23 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 19:03 | | LadyOfLight` [catalyst@Nightstar-c96k85.dab.02.net] has joined #code |
| 19:05 | | LadyOfLight [catalyst@Nightstar-tra4ap.dab.02.net] has quit [Ping timeout: 121 seconds] |
| 19:32 | <&McMartin> | https://github.com/ksimka/go-is-not-good |
| 19:32 | <&McMartin> | Some of these are pettier than others |
| 19:45 | < LadyOfLight`> | IMO Go has a neat implementation of concurrency primitives and seems alright as a server scripting language |
| 19:45 | <&McMartin> | "High-performance reference implementations of experimental network protocol servers" does seem to be the niche it excels at the most |
| 19:46 | < LadyOfLight`> | But I wouldn't describe it as revolutionary (and to be fair neither do they) |
| 19:46 | <&McMartin> | Yeah, the issue I have on that isn't so much "not revolutionary" and more... |
| 19:46 | <&McMartin> | ... well, like someone had woken up from a 45-year coma and decided to make a modern programming language after attending a one-hour seminar on What They Missed In Language Design |
| 19:48 | < LadyOfLight`> | That's largely because rpike can't let Plan 9 go x) |
| 19:49 | <&McMartin> | I do note a category of objection here is "pseudointellectual arrogance of Rob Pike and everything he stands for" |
| 20:07 | | LadyOfLight [catalyst@Nightstar-c96k85.dab.02.net] has joined #code |
| 20:07 | | LadyOfLight` [catalyst@Nightstar-c96k85.dab.02.net] has quit [The TLS connection was non-properly terminated.] |
| 20:20 | | LadyOfLight` [catalyst@Nightstar-bt5k4h.81.in-addr.arpa] has joined #code |
| 20:24 | <@Namegduf> | Would there be a way for someone to approach the idea of trying a different direction of development diverging from an earlier point to the one most languages took which wouldn't appear arrogant to you, or is the general idea of trying an alternative path unacceptable? |
| 20:27 | | * Namegduf can pretty well get why someone might think PHP, Python, and Ruby's gains to productivity might be better attempted in other ways, and isn't fond of the idea that the only reason anyone could have for trying that would be ignorance, especially since it pretty clearly wasn't actually literal ignorance. |
| 20:29 | <@Namegduf> | I don't like what seems to be a lot of hostility to experimentation by people who have always been fastidiously polite |
| 20:30 | <&jerith> | Namegduf: Very few people are objecting to experimentation or alternative paths. |
| 20:30 | <@Namegduf> | McMartin appears to be one of those people |
| 20:30 | <@Namegduf> | Unless there is some way they could have accomplished their experimentation that wouldn't have been arrogant and offensive |
| 20:31 | <&jerith> | Most of the serious, well reasoned objections to Go are based on things that we have already learned are not very good ideas. |
| 20:32 | <@Namegduf> | To be honest I've never seen any of those serious well reasoned objections be any better than "no metaprogramming lol", and I think accusing someone who disagrees with reasoning on that level of being arrogant for disagreeing is a bit uncalled for. |
| 20:32 | <@Namegduf> | They've not gone on long tirades about how everyone else is stupid. |
| 20:32 | <&jerith> | There's a very big difference between taking an alternative path and taking a path that we have been down before and decided to turn away from. |
| 20:33 | <~Vornicus> | Which is to say that the problem with Go isn' that it's different per se, but that it's different in ways that people who actually study language design know are bad plans |
| 20:33 | <@Namegduf> | I don't think you can plausibly argue that Go was not developed by people who actually study language design. |
| 20:33 | <&jerith> | Take, for example, the lack of proper generics in the type system. |
| 20:34 | <@Namegduf> | I've also not seen anywhere near this kind of hostility directed at people who clearly /do/ actually ignore all taste and good sense, like e.g. the PHP devs. |
| 20:34 | <&jerith> | It makes it *impossible* to safely write a whole category of functions. |
| 20:35 | <@Namegduf> | They disagree as to the importance of that. Is that intolerably arrogant such that anyone making a language with those traits should be accused of psuedointellectual arrogance for that alone? |
| 20:36 | <@Namegduf> | I mean, languages /without type safety at all/ don't get that treatment, and they can't safely write /any/ functions (by that standard of safety) |
| 20:36 | <&jerith> | Implicit signature-based interfaces are an horrendous idea, as demonstrated by some awful APIs in the standard library. |
| 20:37 | <&jerith> | Namegduf: Languages without type safety are all are typically languages that have been around for decades. |
| 20:37 | <@Namegduf> | Ruby? |
| 20:37 | <@Namegduf> | Python? |
| 20:37 | <&jerith> | Those are dynamically typed, which is a completely different thing. |
| 20:37 | <~Vornicus> | (python has, for the record, been around since 1993, which is just short of 2.5 decades) |
| 20:38 | <@Namegduf> | They still can't safely write those same functions (or any others). |
| 20:38 | <@TheWatcher> | (and Ruby since 95) |
| 20:38 | <&jerith> | If I want to write a map() function in Go, I either have to write it for a specific type or I have to perform unsafe casts that the compiler warns me about. |
| 20:39 | <@Namegduf> | Untrue; the compiler warns about nothing. |
| 20:39 | <&jerith> | Namegduf: Counter-untrue, unless that has changed in the several months since I attempted to do this very thing. |
| 20:40 | <&jerith> | It wasn't *quite* as trivial a function as map(), but it was in that ballpark. |
| 20:40 | <@Namegduf> | Go has no compiler warnings *at all* |
| 20:40 | <@Namegduf> | It was a philosophical choice they made. |
| 20:40 | <@Namegduf> | It either errors or builds. |
| 20:40 | <@Namegduf> | Because people ignore warnings. |
| 20:41 | <@Namegduf> | This is a popular point of complaint, actually; https://golang.org/doc/faq#unused_variables_and_imports |
| 20:44 | <&jerith> | Maybe it was a linter that complained, then. |
| 20:44 | <@Namegduf> | Could be. |
| 20:45 | <&jerith> | Either way, I had to write code that static analysis cannot prove to be safe. |
| 20:45 | <@Namegduf> | Sure. |
| 20:46 | <&jerith> | https://golang.org/pkg/os/#Signal |
| 20:46 | <@Namegduf> | But I'm pretty sure there is not actually a superconsensus amongst all People Who Know Anything About Language Design that one should never ever have to write code that cannot be proven correct by static analysis such that anyone who dared profane that order is clearly an arrogant fool. |
| 20:47 | <@Namegduf> | Otherwise no one would be using dynamically typed languages, let alone /developing/ them. |
| 20:47 | <&jerith> | Namegduf: That's very much not the point. |
| 20:47 | <&jerith> | The point is that the static type system doesn't actually do the job a static type system should do. |
| 20:48 | <@Namegduf> | Not under all circumstances, no. |
| 20:48 | <&jerith> | And that's okay in a language from the 80s when compiling was expensive. |
| 20:48 | <@Namegduf> | Frankly I'd trade that for the non-nilable strings; I think you'd come out on top in terms of correctness for that alone. |
| 20:48 | <&jerith> | But we've had type systems that can provide those guarantees for *decades*. |
| 20:48 | <@Namegduf> | Because that's a way more common problem in e.g. Java. |
| 20:48 | <&jerith> | Ah, nil. |
| 20:49 | <@Namegduf> | Someone forgetting a null check. |
| 20:49 | <&jerith> | Another thing that a proper type system can get rid of. |
| 20:49 | <&jerith> | Rust is a great example of a language that plays in the same space as Go and Does This Right. |
| 20:50 | <@Namegduf> | Well, it will once it's finished. |
| 20:50 | <@Namegduf> | Right now it doesn't have access to epoll, apparently. |
| 20:50 | <&jerith> | It's finished enough to write useful software in. |
| 20:50 | <@Namegduf> | So you don't exactly want to be writing servers in it. |
| 20:50 | <&jerith> | It's still growing libraries. |
| 20:52 | <@Namegduf> | Rust only got as solidified as it is- which isn't very- much, much after Go. I don't think they're incredibly arrogant for lacking the ability to time travel, and I wouldn't think they were incredibly arrogant for trying to make a simple to grok language as an alternative approach even if Rust had been around at the time. |
| 20:52 | <&jerith> | But either way, parametric polymorphism has been around for over 30 years. |
| 20:53 | <@Namegduf> | Sure. They were unhappy with available forms of it, having seen how badly C++ templates turned out in practice. I think that's something that can reasonably be disagreed with and even be reasonably thought stupid, but "psuedointellectual arrogance", really? |
| 20:54 | <@Namegduf> | When the competing languages at the time it was developed were mostly "kitchen sink of features" dynamically typed messes? |
| 20:54 | <@Namegduf> | (And Java) |
| 20:54 | < LadyOfLight`> | (Which is just a mess~) |
| 20:54 | <&jerith> | C++ templates are very much not parametric polymorphism. |
| 20:55 | <@Namegduf> | Specifically, they were unhappy with expansion at compile time, and the versions which didn't require that had other tradeoffs they were unhappy with. |
| 20:55 | <&jerith> | You can make nulls go away just by introducing an option type. |
| 20:56 | <&ToxicFrog> | "I've also not seen anywhere near this kind of hostility directed at people who clearly /do/ actually ignore all taste and good sense, like e.g. the PHP devs." |
| 20:56 | <@Namegduf> | Is every other language developer who failed to eliminate null a psuedointellectual arrogant person? |
| 20:56 | <&ToxicFrog> | (a) you haven't been paying attention, then |
| 20:57 | <&ToxicFrog> | and (b) at this point, no-one expects the PHP devs to know any better; people hold Rob Pike to a higher standard |
| 20:58 | <&ToxicFrog> | Namegduf: what other high-profile languages released in the past decade and claiming to be The Solution To C++ did? |
| 20:58 | <@Namegduf> | To be honest it looks more like "A person in low standing disagreeing isn't a problem, a person in high standing disagreeing that language feature X is important needs to be loudly knocked down for it" |
| 20:58 | <&ToxicFrog> | I've used Go at work a bunch, and honestly McM's description of it as "like someone had woken up from a 45-year coma and decided to make a modern programming language after attending a one-hour seminar on What They Missed In Language Design" rings pretty true to me |
| 20:59 | <@Namegduf> | I don't remember seeing "The Solution To C++" anywhere. If anything it was aiming to be the solution to Java, but it didn't arrogantly proclaim that, either. I think it's questionable when people need to make up quotes to justify their position. |
| 20:59 | <&ToxicFrog> | Go was explicitly intended to replace the use of C++ and Java in google production. |
| 21:00 | <&ToxicFrog> | It has done neither, but it has ushered in a new clusterfuck of language noninteroperability by being hard to call C++ from and impossible to call into from C++. |
| 21:01 | <&ToxicFrog> | (my team needs to interoperate with another team that does as much as they can get away with in Go, while we are responsible for a huge legacy C++ codebase. This is extremely painful.) |
| 21:01 | <&ToxicFrog> | (also, their Go code has reams and reams of repeated boilerplate made necessary by the lack of generics) |
| 21:02 | <&ToxicFrog> | Like, would I rather use Go than C++ or Java? Absolutely. Would I rather use a mix of Go, C++, and/or Java rather than any one of those languages individually? No. Would I rather use Go than Clojure, Rust, Scala, or Haskell? Hell no. |
| 21:02 | <@Namegduf> | Mixes are painful, yes. |
| 21:03 | <@Namegduf> | Rust isn't really viable for most of what Go is used for I think, because of its unsuitability yet for network servers. |
| 21:03 | <&ToxicFrog> | (do I actually find programming in any of those three languages enjoyable? no) |
| 21:05 | <@Namegduf> | Unless that came along very recently. |
| 21:05 | | Kindamoody|afk is now known as Kindamoody |
| 21:06 | <&McMartin> | Rust and Go are not directly competing, becuase Go has an interrupting GC and Rust does not |
| 21:06 | <&McMartin> | That's just a design decision |
| 21:06 | <&McMartin> | But Go's polymorphism can be summarized as "OO is bollocks, let's throw it out and then reimplement half of it poorly" |
| 21:06 | <&ToxicFrog> | Sadly most of the Go code I need to work on is not servers but stand-alone tools used to take the protobufs from one place and put them in another place |
| 21:07 | <&McMartin> | This offends the people that know only OOP, but even if you don't, Go ripped out OOP from its design and then didn't fill the hole with something good enough to do the same tricks. |
| 21:07 | <&McMartin> | Then there's the automatic-semicolons thing, which is sufficiently awful that yes, they're getting more flak than PHP devs |
| 21:07 | <&McMartin> | Because when Pike and Kernighan design the language they are expected to know better than that |
| 21:08 | | Reiv [NSwebIRC@Nightstar-ih0uis.global-gateway.net.nz] has quit [Ping timeout: 121 seconds] |
| 21:08 | <@Namegduf> | The other thing is that compared to pretty much all these languages it was taking a shot at minimalism-without-needing-you-to-build-a-not-actually-minimal-DSL-on-it, and I think that kind of inherently involves throwing out and being reluctant to readd a lot of conventional features, and I don't like the idea that attempting to do that is apparently to be shunned. |
| 21:08 | <@Namegduf> | Because Everyone Knows you need a 100 page laundry list of OO semantics. |
| 21:08 | <&McMartin> | You don't |
| 21:09 | <&McMartin> | I can do things in non-OO languages that are OO-y and I could do them without tripping as much as I did in Go |
| 21:09 | <&McMartin> | Becuase the way interface implementation works is kind of wonky and interacts with its type inference in an awkward way |
| 21:09 | <@Namegduf> | Even if Go was a /bad/ attempt at that idea, I'd like people to make a better one |
| 21:09 | <@Namegduf> | Which isn't really compatible with the fundamental idea of trying it to be deemed heretical |
| 21:10 | <&McMartin> | The problem with Go is not that it is *heretical* |
| 21:10 | <&McMartin> | It sounds like you missed the actual point of my intended metaphor |
| 21:10 | <&McMartin> | Which is that you take some people who were last *really* up on things many years ago |
| 21:10 | <&McMartin> | And then the world evolved in ways distasteful to them |
| 21:11 | <@Namegduf> | With Java and dynamic languages dominating, I think that was understandable |
| 21:11 | <&McMartin> | And with two exceptions, one of which is *very important*, the things that Go has that C doesn't feel... half-hearted |
| 21:11 | <&McMartin> | They threw out exceptions, but then they didn't *actually* throw out exceptions |
| 21:11 | <&McMartin> | They made it easier to return an error code but then they made it just as easy to disastrously ignore it |
| 21:12 | <&McMartin> | (The two exceptions are low-level access to coroutines, which is why it excels where it *does* excel, and the channel abstraction for cross-"thread" communication, which is A Very Big Deal) |
| 21:13 | <&McMartin> | Rust also tried to not have exceptions and found that they had to have exceptions after all, but they could minimize their use |
| 21:13 | <&McMartin> | Rust also did error codes The Correct Way |
| 21:14 | <@Namegduf> | Rust is a bit of a PITA to do anything with, though, as one of its tradeoffs |
| 21:15 | <@Namegduf> | I hear they've made it /less/ horribly verbose since last I looked |
| 21:15 | <&McMartin> | The last anti-Rust rant I heard was actually anti-Builder-Pattern |
| 21:15 | <&McMartin> | Rust being a PITA to do anything with is actually sold as a feature~ |
| 21:16 | <&ToxicFrog> | I find that with Rust I spend more time arguing with the compiler but still less time programming overall, because I spend less time arguing with the *language* and have to write less boilerplate |
| 21:16 | <@Namegduf> | I'm not anti-Rust, I find "complicated and admittedly painful to setup type safety that enforces correctness" to be an interesting approach |
| 21:17 | <@Namegduf> | I just don't see the hostility to people who tried a simpler approach and especially the attitude that doing anything less than exactly what Rust did, all features and complexity included, made them obvious idiots |
| 21:17 | <&ToxicFrog> | McMartin: in re channels, I agree that they're important but I'm not sure that the fact that Go specifically has them is as much of A Big Deal as you make it sound, since they've been around as a language feature elsewhere for at least 30 years (and around as C/++ libraries on top of other threading models for at least 20) |
| 21:18 | <&jerith> | I haven't done very much Rust yet, but I haven't had to fight the type system at all. |
| 21:18 | <&McMartin> | OK, so, in case this isn't clear, my objections to Go aren't "it doesn't include the features of my favored paradigms" and more "What did you do this like that, you know better than that" |
| 21:18 | | * ToxicFrog departs for hair adjustment and cricket acquisition |
| 21:18 | <&McMartin> | jerith: You can't implement at trait on Vec<T> yet, which is pretty devastating |
| 21:19 | <&McMartin> | ToxicFrog: It's important because it locked people in so people actually frickin' used it |
| 21:19 | <&jerith> | I *have* had some arguments with the borrow checker, but that's something a GC language wouldn't need. |
| 21:20 | <&McMartin> | When I lest stepped away from Rust I was trying to make myself understood to the macro system, and that didn't end well |
| 21:21 | <&McMartin> | But I wasn't familiar enough with the system to be confident that the problem wasn't with me, or with macros generally |
| 21:34 | <&jerith> | Is Rust's lifetime and ownership stuff a genuinely novel language feature? |
| 21:34 | <&jerith> | Or has some other language already done that? |
| 21:35 | <&McMartin> | Compilers for other languages included those notions by trying to infer it |
| 21:35 | <&McMartin> | Which was always a bit frought |
| 21:35 | <&McMartin> | One of Rust's immediate inspirations was the C dialect Cyclone, which I believe included the lifetime stuff |
| 21:36 | <&McMartin> | Ownership has been a memory management discipline in C and C++ for as long as I've been a formally trained programmer at the very least |
| 21:36 | | himi [sjjf@Nightstar-v37cpe.internode.on.net] has joined #code |
| 21:36 | | mode/#code [+o himi] by ChanServ |
| 21:36 | <&McMartin> | I've always liked the formal definition of "ownership", too |
| 21:36 | <&McMartin> | A owns B if A destroys B in every possible run of the program. |
| 21:36 | <&McMartin> | pwn3d |
| 21:37 | <&jerith> | By "memory management discipline", do you mean "something the programmer has to manage by hand"? |
| 21:37 | <&McMartin> | Correct |
| 21:37 | <&McMartin> | You would do this instead of implementing your own reference counter |
| 21:37 | <&McMartin> | (Which would then need to call lock/unlock or retain/release or whatever by hand, aka The Traditional ObjC approach) |
| 21:39 | <&jerith> | I think this makes it the first actually novel language feature I've seen in any language I've actually written code in. |
| 21:39 | <&jerith> | (Unless there are others that I don't notice because they're so derivative of everything that came after them.) |
| 21:39 | <&McMartin> | Heh |
| 21:39 | <&McMartin> | Well |
| 21:40 | <&McMartin> | It's a generalization of a C++ idiom involving constructor and destructor order |
| 21:40 | <&McMartin> | Where you enforce lifetimes via inclusion as a field or declaration on a stack |
| 21:43 | <&McMartin> | There are some places where Rust does the "half-hearted" thing, but those are messy enough that I'm not sure how much of it is because of implementation assumptions baked into the more general cases |
| 21:44 | <&McMartin> | The thing that Rust has that I've seen nowhere else is "move semantics everywhere by default" |
| 21:46 | <&jerith> | It's also the first primarily imperative language I've seen with immutable-by-default. |
| 21:47 | < LadyOfLight`> | Rust is a language that I would characterise as 'C++ but with the correct defaults' |
| 21:47 | <&McMartin> | I have come around to that view |
| 21:47 | < LadyOfLight`> | McMartin: I've started writing C++ with move semantics by default |
| 21:47 | <&McMartin> | I first learned Rust when my experience with C++ was all of the C++98 variety |
| 21:47 | < LadyOfLight`> | I wrote a number of classes yesterday that just casually took vector<Thing>&& in their constructors |
| 21:47 | <&McMartin> | So my experience with idiomatic C++11 was "oh, now it is Rust, but the training wheels are off" |
| 21:48 | | * LadyOfLight` nods |
| 21:48 | <&McMartin> | There are a few other things. Rust doesn't have "true" objects, and it's noticed that that's a problem |
| 21:48 | <&McMartin> | (It turns out that variadic types are only a complete replacement for single inheritance in proofs of equivalence~) |
| 21:48 | < LadyOfLight`> | I like Rust, but I worry that a) it's still the wrong fundamental approach and b) it's not better enough than C++ (though it is certainly better at that than D) |
| 21:49 | <&McMartin> | I would consider Rust to have fully succeeded if it ends up as well-established as, oh, Erlang |
| 21:49 | <&McMartin> | Which is a taller order than it might sound, but also where I'd be surprised if it gets further than that |
| 21:50 | <&jerith> | LadyOfLight`: I'm curious about your (a). |
| 21:50 | <&McMartin> | jerith: If you aren't counting Wacky Academic Languages, JavaScript should meet your requirement~ |
| 21:50 | < LadyOfLight`> | jerith: that will takea while :) |
| 21:51 | <&McMartin> | Actually, jerith is one of the people I should also ask this: are there any published studies of OCaml development in the large? |
| 21:51 | <&McMartin> | (As in, we had this great big problem, so here's how we decomposed it) |
| 21:52 | <&jerith> | McMartin: Does Jane Street Capital count? |
| 21:52 | <&jerith> | They've given a bunch of talks about things. |
| 21:52 | <&McMartin> | Possibly |
| 21:52 | <&McMartin> | I'm looking for something like "OK, you've got struct and functor. Here's how we broke down a non-toy problem into those" |
| 21:53 | <&jerith> | https://www.youtube.com/watch?v=G6a5G5i4gQU seems to be what you're after. |
| 21:53 | <&McMartin> | Thank you, filed |
| 21:53 | <&McMartin> | Lunch is wrapping up, I'll watch it after work |
| 21:55 | <&jerith> | I recall it being more focused on design and such than practical implementation, but they did implement the thing several times before they got it right. |
| 21:57 | <&jerith> | Yaron Minsky's talks often have a general theme of "OCaml is a very flexible language, don't ignore bits of it because they're not 'functional' enough". |
| 21:58 | <&jerith> | With an occasional "except the object system, even the guy who designed it doesn't use it". |
| 22:05 | <&McMartin> | Heh |
| 22:05 | | * McMartin pulls down that one and also the one labeled "Effective ML" |
| 22:06 | <&McMartin> | This Incr type looks a hell of a lot like Monad |
| 22:13 | <&McMartin> | Ah, 15 minutes in he points that out, OK~ |
| 22:28 | <&McMartin> | "So that seems a little bad, until you think about it and realize that it's *horrifically* bad" |
| 22:36 | <&McMartin> | "bind-infested code" |
| 22:36 | <&McMartin> | This isn't what I was looking for, but it *is* fun. |
| 22:52 | | * Vornicus discovers that there are 15 different symmetries for a black & white square |
| 22:54 | <&McMartin> | Heh. the rant here about closures is basically "encapsulation is bad" |
| 22:54 | | * Vornicus sets about drawing them nicely, for future reference |
| 22:55 | | * Vornicus needs to pull the basketball stuff into a different blog or something. wonders how easy that is. |
| 22:55 | <&McMartin> | ??? |
| 22:57 | <~Vornicus> | I have a blog, which is currently used exclusively for NCAA basketball bracket tournament announcements |
| 22:58 | <~Vornicus> | But now I have a lovely piece of analysis and I don't really feel like putting the tournament stuff "out in the world" next to the programming stuff |
| 22:59 | <~Vornicus> | As for the more directly on topic thing |
| 23:00 | <~Vornicus> | Consider a black & white square, that you can rotate, reflect about the midline, and swap colors on |
| 23:01 | <&McMartin> | Aha, OK |
| 23:01 | <&McMartin> | You're classifying kinds of possible symmetries any b&w square could have |
| 23:03 | <~Vornicus> | Of which there are 15 types. |
| 23:03 | <&McMartin> | I had first parsed this as "A-HA, I have constructed a B&W square that has 15 different kinds of symmetry" |
| 23:05 | <~Vornicus> | which is a little different |
| 23:05 | <~Vornicus> | derp, correction, 14 types. :( |
| 23:34 | <&ToxicFrog> | &McMartin | ToxicFrog: It's important because it locked people in so people actually frickin' used it -- possibly my concurrency experience is atypical, then, because both in school and in industry it was very heavy on CSP-style channel usage and not so much about shared memory and locking |
| 23:35 | <&McMartin> | Yeah, I spent a soul-crushing amount of time in the semaphore mines |
| 23:35 | <&McMartin> | (Which is actually any amount more than three months) |
| 23:37 | <&ToxicFrog> | Yeah, my experience with shared-memory concurrency was basically one course in second year |
| 23:37 | <&ToxicFrog> | And everything else was either Erlang, MPI/Pilot (C, but you use channels because you have no guarantee your workers are all in the same process or even on the same machine) |
| 23:38 | <&ToxicFrog> | CacheOS (C++ with no memory protection, and you use channels because to do otherwise invites horrifying madness, and also it turns out that when you're writing the entire OS from scratch you can make them very, very fast) |
| 23:38 | <&McMartin> | For me, it's UQM (which used SDL_thread, which was a very thin wrapper around pthreads or something equivalent) and C++98 with acceptable libraries (built around mutexes) |
| 23:39 | <&ToxicFrog> | Bash might count, since any highly concurrent bash script is probably using pipes all over the place |
| 23:39 | <&McMartin> | I'm still kind of in that state even now, but since this code is architected in a "series of asynchrous tasks" kind of style, I can often ensure that important bits of memory are never shared |
| 23:40 | <&ToxicFrog> | Or IMAP5, where you're programming in asm or a custom C subset and you're still using channels because that's how the chip hardware is actually laid out |
| 23:41 | <&ToxicFrog> | And that's basically all of high school and university there, and now that I'm at Google it's either goroutines or C++ concurrency libraries that look an awful lot like processes communicating over typed channels. |
| 23:41 | <&McMartin> | Which is good times, yes. |
| 23:41 | <&ToxicFrog> | So my exposure to pthreads was basically "this is kind of cool but it's clearly not something anyone uses in production these days" |
| 23:41 | <&McMartin> | Yeah, not so much. :/ |
| 23:42 | <&ToxicFrog> | And then implementing a toy CSP library for Lua on top of pthreads, where each thread gets its own isolated lua VM. |
| 23:42 | <&ToxicFrog> | Which was actually a lot of fun. |
| 23:42 | <&McMartin> | Yeah |
| 23:42 | <&ToxicFrog> | (I believe I called it Surtr, for reasons which I no longer remember) |
| 23:42 | <&McMartin> | AFAICT all of these things are ultimately built on top of pthreads |
| 23:44 | <&McMartin> | The entire Java and ObjC multithreading systems are built around recursive mutexes |
| 23:44 | <&ToxicFrog> | C++ producers probably are, MPI definitely is, Pilot is built on top of MPI |
| 23:44 | <&ToxicFrog> | CacheOS definitely was not because we built the entire OS from the ground up and it wasn't even libc89 compliant, let alone POSIX |
| 23:44 | <&McMartin> | heh heh |
| 23:45 | <&McMartin> | Yes, that does not count. |
| 23:45 | <&ToxicFrog> | And bash is fork/exec :P |
| 23:45 | <&ToxicFrog> | (and IMAP5 was an embedded system) |
| 23:45 | <&McMartin> | bash is not shared-memory multiprogramming, IIRC |
| 23:46 | <&McMartin> | Except as a possible implementation detail (memory being copy-on-write and never written) |
| 23:46 | <&ToxicFrog> | (I guess the caches were technically "embedded systems" as well but when it's amd64 architecture and has more beef than my gaming rig it doesn't really feel like it) |
| 23:46 | <&ToxicFrog> | It's not, no, but as mentioned earlier highly concurrent bash scripts using pipes for communication end up looking pretty CSPish. |
| 23:46 | <&ToxicFrog> | (whether doing this in bash is at all advisable is a different question) |
| 23:46 | <&McMartin> | Heh |
| 23:46 | <&McMartin> | Yeah, I think my thesis here is that CSP code I'm familiar with is rather pointed about not obviously sharing memory |
| 23:47 | <&McMartin> | And, well |
| 23:47 | <&McMartin> | A lot of my retrocoding is interrupt-driven |
| 23:47 | <&McMartin> | That's not awesome but it turns out that it's easier to reason about than threading/mutexes |
| 23:47 | <&McMartin> | Anyway, yeah |
| 23:48 | <&McMartin> | I have basically never in my career gotten to use CSPs beyond toy problems |
| 23:48 | <&McMartin> | This has a great deal to do with what my software has had to work with |
| 23:49 | <&ToxicFrog> | Right, whereas I have never really done retrocoding |
| 23:50 | <&ToxicFrog> | And even my embedded system experience was on a funky architecture where the concurrency primitives were "activate a core and run this function on it", "send a message to a core" and "wait for a message from another core" |
| 23:50 | <&McMartin> | Right, but, well, 1998 isn't that retro~ |
| 23:50 | <&ToxicFrog> | And the cores had total memory isolation from each other |
| 23:50 | <&McMartin> | But there was a lot of "OK, create a thread pool to do work on" -> "schedule work to run on those threads" |
| 23:50 | <&McMartin> | Which is the default mechanism for pretty much everything in desktop and mobile GUI applications |
| 23:50 | <&ToxicFrog> | So even my embedded work ends up being message-passing rather than shared-memory. |
| 23:51 | <&McMartin> | And then there's "Hi, you're interfering with Windows NT or something POSIX-compliant and need to handle other people running code that uses pthreads" |
| 23:51 | <&McMartin> | Well, so, the first thing you do when you have to work with threads and shared memory is share some memory for use as your message queue~ |
| 23:52 | <&McMartin> | That's where which retro you are gets wacky |
| 23:52 | <&McMartin> | If you don't have long-running background tasks, your Desktop GUI application (or your iOS application; I'm not sure about Android) is single-threaded. |
| 23:53 | <&ToxicFrog> | I did use pthreads in school, I know the basics :P |
| 23:53 | <&McMartin> | Well, so |
| 23:53 | <&McMartin> | People *do* do things like have effectively global data structures that *aren't* message queues and then control access to them with locks |
| 23:53 | <&McMartin> | This is pretty common for, like, Java collection classes |
| 23:54 | <&McMartin> | And it's something of a tragedy when you have to |
| 23:56 | <&McMartin> | UQM's thread structure basically smashes everything into three threads |
| 23:56 | <&McMartin> | There's the one that reads input and renders graphics |
| 23:56 | <&McMartin> | There's one that does OGG and MOD decoding |
| 23:56 | <&McMartin> | And then there's "everything else" |
| 23:56 | <&ToxicFrog> | Why are input and graphics in the same thread? |
| 23:57 | <&McMartin> | Because that's how X11, Windows, and macOS all work, more or less |
| 23:57 | <&McMartin> | All of them use a single event queue for "the user pressed/released a key" and "you need to redraw this window" |
| 23:57 | <&McMartin> | In macOS specifically, event processing and UI update operations are always constrained to the thread that has main() in it |
| 23:58 | <&McMartin> | In Windows this is merely Highly Recommended. |
| 23:58 | <&McMartin> | I've only used two X11 toolkits extensively (SDL and Qt4) and both also impose this requirement. |
| --- Log closed Fri Feb 10 00:00:37 2017 |