Logs: freenode/#haskell
| 2021-04-07 00:11:36 | × | usr25 quits (~usr25@unaffiliated/usr25) (Read error: Connection reset by peer) |
| 2021-04-07 00:14:55 | → | cads joins (~cads@ip-64-72-99-232.lasvegas.net) |
| 2021-04-07 00:17:36 | → | renzhi joins (~renzhi@2607:fa49:653f:a800::4223) |
| 2021-04-07 00:20:02 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-07 00:20:04 | × | mrchampion quits (~mrchampio@38.18.109.23) (Read error: Connection reset by peer) |
| 2021-04-07 00:21:37 | <pie_> | whats the current way to interface haskell and python? |
| 2021-04-07 00:22:35 | × | Aquazi quits (uid312403@gateway/web/irccloud.com/x-bmhbjzvaxfjgfshr) (Quit: Connection closed for inactivity) |
| 2021-04-07 00:23:37 | → | mrchampion joins (~mrchampio@38.18.109.23) |
| 2021-04-07 00:23:43 | × | tzh quits (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) (Ping timeout: 260 seconds) |
| 2021-04-07 00:23:45 | × | Guest96189 quits (~textual@mskresolve-a.mskcc.org) (Ping timeout: 260 seconds) |
| 2021-04-07 00:24:30 | × | aerona quits (~aerona@2600:6c54:4600:f300:17d9:d4ff:325b:67dc) (Quit: Leaving) |
| 2021-04-07 00:25:08 | × | royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 265 seconds) |
| 2021-04-07 00:25:39 | × | zebrag quits (~inkbottle@aaubervilliers-651-1-244-162.w83-200.abo.wanadoo.fr) (Quit: Konversation terminated!) |
| 2021-04-07 00:26:01 | → | zebrag joins (~inkbottle@aaubervilliers-651-1-244-162.w83-200.abo.wanadoo.fr) |
| 2021-04-07 00:26:06 | <pie_> | ok this looks recent enough https://libredd.it/r/haskell/comments/ec81iq/best_way_to_call_python_36_code_from_from_haskell/ |
| 2021-04-07 00:26:14 | <pie_> | though thatts in the other direction |
| 2021-04-07 00:26:42 | <Axman6> | not sure there is a particularly well known solution for doing that |
| 2021-04-07 00:27:36 | → | Codaraxis_ joins (~Codaraxis@141.98.255.144) |
| 2021-04-07 00:29:15 | <pie_> | *nod* |
| 2021-04-07 00:29:21 | → | tzh joins (~tzh@c-24-21-73-154.hsd1.wa.comcast.net) |
| 2021-04-07 00:29:49 | × | Codaraxis quits (Codaraxis@gateway/vpn/mullvad/codaraxis) (Ping timeout: 268 seconds) |
| 2021-04-07 00:32:32 | → | zaquest joins (~notzaques@5.128.210.178) |
| 2021-04-07 00:33:06 | × | cole-h quits (~cole-h@c-73-48-197-220.hsd1.ca.comcast.net) (Ping timeout: 240 seconds) |
| 2021-04-07 00:40:07 | × | star_cloud quits (~star_clou@ec2-34-220-44-120.us-west-2.compute.amazonaws.com) (Ping timeout: 265 seconds) |
| 2021-04-07 00:40:45 | × | mmmattyx quits (uid17782@gateway/web/irccloud.com/x-kuttqhjrmgrkynne) (Quit: Connection closed for inactivity) |
| 2021-04-07 00:40:59 | × | paddymahoney quits (~paddymaho@cpe9050ca207f83-cm9050ca207f80.cpe.net.cable.rogers.com) (Remote host closed the connection) |
| 2021-04-07 00:44:49 | × | Foritus quits (~buggery@cpc91316-watf11-2-0-cust68.15-2.cable.virginm.net) (Quit: ლ(ಠ益ಠლ) .:. <Ashley> my porn is hidden in a folder called "BBC Micro Emulator") |
| 2021-04-07 00:46:03 | × | acidjnk_new quits (~acidjnk@p200300d0c72b9510b1ed14260384c0cf.dip0.t-ipconnect.de) (Ping timeout: 258 seconds) |
| 2021-04-07 00:46:08 | → | merijn joins (~merijn@83-160-49-249.ip.xs4all.nl) |
| 2021-04-07 00:48:08 | → | rajivr joins (uid269651@gateway/web/irccloud.com/x-bfdpumpohvpxzdht) |
| 2021-04-07 00:51:05 | × | Techcable quits (~Techcable@168.235.93.147) (Quit: ZNC - https://znc.in) |
| 2021-04-07 00:51:26 | × | viluon quits (uid453725@gateway/web/irccloud.com/x-vxyigueamtfqricd) (Quit: Connection closed for inactivity) |
| 2021-04-07 00:55:49 | → | Techcable joins (~Techcable@168.235.93.147) |
| 2021-04-07 01:00:55 | → | solvr joins (57e3c46d@87.227.196.109) |
| 2021-04-07 01:06:34 | → | drbean_ joins (~drbean@TC210-63-209-95.static.apol.com.tw) |
| 2021-04-07 01:07:38 | <solvr> | "Almost all classical data structures require mutability, and for a good reason - it gives us far cheaper resource use than destroy-and-create does. [...] Purely functional data structures are really cool, but they're cool like a dancing bear is cool. I.e. it's not impressive that the bear dances well, but the fact the bear dances at all." |
| 2021-04-07 01:08:52 | → | royal_screwup21 joins (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) |
| 2021-04-07 01:09:19 | → | vicfred joins (vicfred@gateway/vpn/mullvad/vicfred) |
| 2021-04-07 01:10:57 | × | whataday quits (~xxx@2400:8902::f03c:92ff:fe60:98d8) (Remote host closed the connection) |
| 2021-04-07 01:12:03 | → | whataday joins (~xxx@2400:8902::f03c:92ff:fe60:98d8) |
| 2021-04-07 01:12:53 | <wrunt> | nonsense |
| 2021-04-07 01:13:17 | <wrunt> | purely functional data structures don't require destroy-and-create |
| 2021-04-07 01:13:41 | × | royal_screwup21 quits (52254809@gateway/web/cgi-irc/kiwiirc.com/ip.82.37.72.9) (Ping timeout: 240 seconds) |
| 2021-04-07 01:13:43 | <Axman6> | yeah that's complete nonsense, particularly in the concurrent world we live in. mutation makes concurrency extremely difficult |
| 2021-04-07 01:14:00 | <dibblego> | More importantly, why is that nonsense here in this channel? |
| 2021-04-07 01:15:56 | <Axman6> | need to share a hashmap between any number of threads which may all read and write arbitrarily? IORef (HashMap Key Value) is infinitely easier to reason about than HashTable Key Value which uses mutation, with the former being able to produce arbitrarily complex, consistent mutations whith the latter making that almost impossible without resorting to locks |
| 2021-04-07 01:16:00 | <pjb> | wrunt: the destroy is in the garbage collector. |
| 2021-04-07 01:16:19 | <solvr> | Don't functional data structures require destroy and create. |
| 2021-04-07 01:16:35 | <Axman6> | no |
| 2021-04-07 01:17:08 | <dibblego> | mutable data structures do though |
| 2021-04-07 01:17:17 | <pjb> | Immutability renders array virtually useless. Most sophisticated algorithms are designed arround array and array mutation. Basically you can take all Knuth and throw it to the trash can with purely functional programming languages… |
| 2021-04-07 01:17:27 | <Axman6> | and the fact they do not makes them infinitely more usable, you can efficiently retain the entire history of a structure with the only extra allocations being the minimal difference between each version. this comes for free |
| 2021-04-07 01:18:45 | <solvr> | Yes it's for free. Except the part where it's not "free" in terms of memory or CPU resources /s |
| 2021-04-07 01:18:50 | <Axman6> | to get that sort of behaviour with mutable structures, you have to work very hard to store all the modifications and have a way to run them in reverse. for us, an undo tree of changes to some state is just [SomeState] |
| 2021-04-07 01:18:56 | <pjb> | minimal differences doesn't improve things: you still have to either copy all the rest, or shadow the data structure behind a O(n) chain of differences. |
| 2021-04-07 01:19:38 | <Axman6> | pjb: not sure what you mean, consequtive versions of the structure will share the majority of their structure |
| 2021-04-07 01:19:43 | <pjb> | And even if O(log32(n)) is good enough for must uses, it still is not O(1)… |
| 2021-04-07 01:20:10 | <solvr> | Axman6, regarding the "concurrent world we live in". Having lots of shared state between concurrent structures is actually a poor factoring. |
| 2021-04-07 01:20:11 | × | merijn quits (~merijn@83-160-49-249.ip.xs4all.nl) (Ping timeout: 240 seconds) |
| 2021-04-07 01:20:25 | <Axman6> | but also some necessary |
| 2021-04-07 01:20:47 | <Axman6> | usually the solution it so push that sharing into an even more complex system, like a database |
| 2021-04-07 01:21:02 | <dibblego> | I swear this discussion was had 20 years ago, everyone learned, and we all moved on. |
| 2021-04-07 01:21:11 | pie_ | is learning |
| 2021-04-07 01:21:35 | × | xff0x quits (~xff0x@2001:1a81:5274:b300:73fd:d48e:9253:e66b) (Ping timeout: 260 seconds) |
| 2021-04-07 01:22:12 | <solvr> | dibblego, we didn't learn a thing. |
| 2021-04-07 01:22:40 | <solvr> | dibblego, if we had, we'd probably be using Erlang offshoots now, which combine OOP and FP into a single system, more or less |
| 2021-04-07 01:23:11 | → | xff0x joins (~xff0x@2001:1a81:52ae:6200:6f5d:6ce6:85f6:1960) |
| 2021-04-07 01:24:14 | <Axman6> | there was a paper ages ago, I thing written by SPJ et al. which looked at the implementation of lock free structures and compared their performance. The highest performance implementation ended up being an immutable structure wrapped by an IORef, because all updates ended up being an atomic compare and swap, and the evaluation of the changes could be shared between all threads trivially |
| 2021-04-07 01:25:14 | <dibblego> | yeah that bit disappoints me, the not learning thing |
| 2021-04-07 01:25:16 | <solvr> | Axman6, performance can only be judged in context. So I'm not sure "highest performance" tells us a lot without context. |
| 2021-04-07 01:25:23 | <dibblego> | Axman6: there were also papers before that |
| 2021-04-07 01:25:39 | <Axman6> | solvr: read the paper then |
| 2021-04-07 01:25:52 | <solvr> | Axman6, you didn't even link a paper :) |
| 2021-04-07 01:25:56 | × | stree quits (~stree@68.36.8.116) (Ping timeout: 268 seconds) |
| 2021-04-07 01:26:27 | → | Foritus joins (~buggery@cpc91316-watf11-2-0-cust68.15-2.cable.virginm.net) |
| 2021-04-07 01:27:10 | <dibblego> | better than read a paper: write a JIT hotspot compiler, then come tell me about the performance improvements from all those mutable data structures |
| 2021-04-07 01:27:12 | <Axman6> | I think it was https://simonmar.github.io/bib/papers/concurrent-data.pdf |
| 2021-04-07 01:27:14 | <solvr> | Axman6, highest performing algorithms are often about choosing boundaries between shared and non-shared state, including across threads. |
| 2021-04-07 01:27:46 | <solvr> | Axman6, so imagining a world where everything is shared between threads is just an artificial restriction that's already way worse than what's possible |
| 2021-04-07 01:28:04 | <Axman6> | I never claimed that is a world we should imagine |
| 2021-04-07 01:28:32 | <solvr> | Axman6, sure but we do keep coming back to things like sharing state, lock-free structures and so on |
| 2021-04-07 01:28:36 | <solvr> | All of this is about shared state |
| 2021-04-07 01:28:37 | <Axman6> | but sharing between threads is often a very natural way to build concurrent apps which can reduce resource usage |
| 2021-04-07 01:29:37 | <solvr> | Axman6, it's not very natural. Encapsulation and message-passing is even more natural, I'd argue. Like you and me now, in this chat. We're not sharing a lock-free brain. We're exchanging messages and keeping our state local. |
| 2021-04-07 01:30:11 | <Axman6> | so you trhing that a web server which supports caching should have every thread maintain its own cache? |
| 2021-04-07 01:30:59 | <solvr> | I think that's a very specific statement, without context. So I can't tell what this hypothetical server should do. But some of its cache would be local yes. |
| 2021-04-07 01:31:20 | <solvr> | You CPU also has lots of cache that's device local, CPU local, core local, and so on |
| 2021-04-07 01:31:28 | <solvr> | It's like a tree. |
| 2021-04-07 01:31:33 | <Axman6> | to each thread? why not share the cache between all threads? the |
| 2021-04-07 01:31:41 | <Axman6> | I am very aware of that |
| 2021-04-07 01:31:48 | × | renzhi quits (~renzhi@2607:fa49:653f:a800::4223) (Ping timeout: 246 seconds) |
| 2021-04-07 01:31:57 | <solvr> | Well ask yourself why. |
| 2021-04-07 01:33:17 | <Axman6> | much of my major at university was in high performance computing... I understand the affects of caches and memory hierarchies |
| 2021-04-07 01:33:48 | <Axman6> | anyway, do you have some argument you're trying to make or just troll? You've come in here making controvercial, demonstratably false claims, did you have a point to make? |
| 2021-04-07 01:34:37 | <solvr> | Axman6 it wasn't my statement, it was Brian Goetz in this talk: |
| 2021-04-07 01:34:38 | <solvr> | https://www.youtube.com/watch?v=HSk5fdKbd3o |
| 2021-04-07 01:34:51 | <solvr> | Where he actually points out OOP+FP are quite complementary |
| 2021-04-07 01:34:51 | <Axman6> | controversial* |
| 2021-04-07 01:35:53 | <solvr> | I think it's a good talk, and he mentions Erlang as a mental model a few times. |
| 2021-04-07 01:35:58 | <solvr> | It's a great mental model IMHO. |
All times are in UTC.