|
My original post was mostly about immutability in the context of cruddy server apps that interact with external and internal services and databases to collect and present info to be shown to customers aka 90% of what all of us do. Idgaf if the collections I use are implemented with internal mutable state or not as long as they give me immutable maps and filters and groupBys I've done production haskell, scala, and java and never made a data type more complicated than a record that gets serialised to or from json, xml, or Sql. Except for that one time I interacted with a linear solver and had to output and parse its weird text format Or the time a vendor insisted that we submitted records to them by emailing xlsx files. Basically what I'm saying is that algo work is for hobby projects and library writers and being a server programmer (especially in finance) is generally just data piping in my experience
|
#
?
Apr 13, 2017 12:13
|
|
|
|
| # ? Jun 2, 2024 23:51 |
|
|
The Laplace Demon posted:Characterizing the techniques in Okasaki as "no no, overall this is still O(1) per operation despite the cost of reversal being O(n)" is straight up incorrect. The final queue implementation is legit O(1) on every operation. The trick is to perform a step or two of reversing the second stack every time a new element is added to or removed from the queue through clever usage of lazy evaluation. That way the memoization you're talking about is only a constant factor speedup. yeah you're right. I just double-checked the book. I think I got confused when they compare the banker and physicist method and remove wholesale lot of optimizations there and leave most monolithic operations in place, but I missed/did not remember the cache they have added on for its front elements in there.
|
|
#
?
Apr 13, 2017 12:33
|
|
|
gonadic io posted:Basically what I'm saying is that algo work is for hobby projects and library writers and being a server programmer (especially in finance) is generally just data piping in my experience Uhhhh your wrong because why else would cs algo questions be the standard process to interviewing programmers?? hmm did you ever thing about that!! 
|
|
#
?
Apr 13, 2017 23:44
|
|
|
perhaps trivial CRUD poo poo is 90% of application projects in industry. people still manage to make them run slowly.
|
|
#
?
Apr 14, 2017 04:15
|
|
|
how complex is jira in that crud continuum? because I don't understand how our company jira take ~3 seconds for a new page to load otoh, slow loading internal apps likely means it was contracted out to the lowest bidder code farm, so business as usual. i interact with this proprietary 3rd party thing that as far as I can tell inserts a row into an oracle table and returns the ID. I'm also the only user because my external_key column is completely in sequence still somehow takes more than 1 minute for a single call and 2 minutes if you request an array of 10 it also cannot handle more than 1 concurrent request at a time. sending 3-4 async calls apparently clobbers some shared data. MeruFM fucked around with this message at 09:06 on Apr 14, 2017 |
|
#
?
Apr 14, 2017 09:02
|
|
|
MeruFM posted:how complex is jira in that crud continuum? jira is used by tons of people and made by atlassian or whatever, they make a whole suite of poo poo tools to piss you off
|
|
#
?
Apr 14, 2017 14:11
|
|
|
jira was a bug tracker that people started tracking work in and they just kept growing it from there
|
|
#
?
Apr 14, 2017 14:23
|
|
|
It makes sense to me to track work and bugs in the same place, because fixing bugs is work.
|
|
#
?
Apr 14, 2017 14:25
|
|
|
jira is very good
|
|
#
?
Apr 14, 2017 15:51
|
|
|
Bloody posted:jira is very good yeah, but most people trying to set it up aren't so 
|
|
#
?
Apr 14, 2017 15:59
|
|
|
jira is kind of terrible and you can see a lot of the features came from teams competing against each other instead of trying to come up with poo poo that makes sense and fit together
|
|
#
?
Apr 14, 2017 16:21
|
|
|
jira is much better than every alernative i've used
|
|
#
?
Apr 14, 2017 16:27
|
|
|
mostly jira is one of those things with a 1,000 features (configurations and integrations etc.), which seems silly when you are only using 100, but it turns out you are using a mostly different 100 than others
|
|
#
?
Apr 14, 2017 17:55
|
|
|
features i use: open ticket assign to watch filter tickets features management wants me to use: 500 other things features that might be cool but whoever is running jira can't get their act together: enterprise github integration
|
|
#
?
Apr 14, 2017 18:32
|
|
|
fleshweasel posted:perhaps trivial CRUD poo poo is 90% of application projects in industry. people still manage to make them run slowly. it's not slow because their data structures aren't savagely optimized enough
|
|
#
?
Apr 14, 2017 18:37
|
|
|
the talent deficit posted:it's not slow because their data structures aren't savagely optimized enough if they do have bespoke data structures, that could well be causing the slowdown lol. the solution is almost certainly not to savagely optimise them ofc
|
|
#
?
Apr 14, 2017 18:59
|
|
|
comedyblissoption posted:mutability might not be bad at all if you do it like rust this is by far the most important one and in practice seems to eliminate vast swathes of pointless mutability that makes it hard to have any idea where values come from
|
|
#
?
Apr 14, 2017 23:03
|
|
|
comedyblissoption posted:here's a good article about how non-aliased mutability improves program understanding evan, the guy who writes elm, gave a talk last year about how concurrency is hard and mutable state is basically the same thing as concurrency and it reminds me of this article
|
|
#
?
Apr 15, 2017 02:05
|
|
|
my company uses jira as the primary data store and web hook triggerer for an application
|
|
#
?
Apr 17, 2017 15:40
|
|
|
my favorite part about JIRA is taht it uploads 6+ MBs of javascript whenever i fire it up
|
|
#
?
Apr 17, 2017 15:48
|
|
|
Flat Daddy posted:my company uses jira as the primary data store and web hook triggerer for an application and the weird thing is, despite feeling dread every time i load up jira, i am not even that sure that this is a bad idea. it just does a lot of stuff. business people are able to work with it. it is sort of like excel in serving a role as the interface a lot of people understand, while they simultaneously in principle use very little of what the system itself *does*
|
|
#
?
Apr 17, 2017 15:52
|
|
|
comedyblissoption posted:here's a good article about how non-aliased mutability improves program understanding So how does this relate to accessing concurrent mutable state, not through locks, but through something like software transactional memory?
|
|
#
?
Apr 17, 2017 18:54
|
|
|
Bloody posted:jira is very good our generation's lotus notes
|
|
#
?
Apr 18, 2017 16:10
|
|
|
JawnV6 posted:so when you pass a giant blob of data off to a function and it returns a BRAND NEW object with w/e 1-bit change you wanted, is there any acknowledgment of the runtime actually copying and shuffling all this data around behind the scenes to keep up the "immutable" fiction? or is that like ladder step 4: why is my performance poo poo works well enough for postgres 
|
|
#
?
Apr 18, 2017 16:19
|
|
|
Zemyla posted:So how does this relate to accessing concurrent mutable state, not through locks, but through something like software transactional memory? (they work with locks) tef fucked around with this message at 16:29 on Apr 18, 2017 |
|
#
?
Apr 18, 2017 16:21
|
|
|
it's probably better to use stm because unlike locks, well, we have a better track record with transactions
|
|
#
?
Apr 18, 2017 16:31
|
|
|
my understanding is that STM was deemed mostly very difficult to make work right in F# without the purity that Haskell enforces, since side-effects could be troublesome when transactions didn't go on the happy path every time.
|
|
#
?
Apr 18, 2017 16:44
|
|
|
yes, it would be very tempting to execute things during the transaction that aren't actually transactional the bigger problem is that in my experience programmers naturally tend to make enormous transactions which are probably just doomed to never actually be applied, at least not with the optimistic implementation strategy that allows tm to have desirable performance. tm degrades like poo poo under contention that said, hardware tm would be fantastic, not because tm is in any way a good end-user programming paradigm but because it would be a huge boon for concurrent data structures in non-gc environments. e.g. you could actually write a simple concurrent linked list where the node memory is arbitrarily owned. oh, did i allocate a node on my stack, insert it into the concurrent queue, then splice it out later and immediately re-use the memory for something completely different while you were iterating the list, causing all of your reads to go completely wild and probably crash? whatever, just unwind your transaction and start over
|
|
#
?
Apr 18, 2017 17:10
|
|
|
Most models of parallelism in functional programming isn't very fast at all (STM included), and only the most optimistic papers claim otherwise. At least they make it easier to get parallel things right. Maybe in ten years, high-performance functional programming will be more than an academic plaything.
|
|
#
?
Apr 18, 2017 17:15
|
|
|
Athas posted:Maybe in ten years, high-performance functional programming will be more than an academic plaything. Wow look at this post from the 70s
|
|
#
?
Apr 22, 2017 15:43
|
|
|
Wheany posted:Wow look at this post from the 70s, 80s, 90s, and today on 98.7 the peak
|
|
#
?
Apr 22, 2017 21:22
|
|
|
|
|
#
?
Apr 23, 2017 01:01
|
|
|
|
|
#
?
Apr 23, 2017 04:17
|
|
|
rjmccall posted:yes, it would be very tempting to execute things during the transaction that aren't actually transactional yeah, and people also access code outside of the lock my point was that transactions are easier to compose than locks by design, and that higher level code benefits immensely from it i don't think you're arguing against it, i just kinda wanted to be clear about me saying "so that thing in 'how computers stop and what can be done about it'? it's good advice" but i've been a database janitor for 2 years, i really like transactions quote:the bigger problem is that in my experience programmers naturally tend to make enormous transactions which are probably just doomed to never actually be applied, at least not with the optimistic implementation strategy that allows tm to have desirable performance. *opens up a session transaction* *postgres stops cleaning up old data* yeah it's a shitshow especially on mvcc implementations there are systems without session transactions (i think faundadb just launched), and well, databases that use undo logs instead of old values (innodb i think), force old transactions to to abort execution quote:tm degrades like poo poo under contention i've heard this a lot but tbh optimistic locking isn't the worst under contention, but a hot key is going to gently caress over most implementations  that said, the bw-tree/llama magic behind hekaton and documentdb is pretty good, so i hear. quote:that said, hardware tm would be fantastic, not because tm is in any way a good end-user programming paradigm but because it would be a huge boon for concurrent data structures in non-gc environments. hardware tm would be interesting but for me, writing distributed stuff, well, punting the issue of persistence to a transactional store is kinda nice
|
|
#
?
Apr 24, 2017 16:43
|
|
|
transactions are a great paradigm for databases, definitely agree there. i have not really thought about tm as a database implementation technology. just saying that i think stm is really problematic as a general-purpose synchronization system, in part because it's such an elegant-feeling design
|
|
#
?
Apr 24, 2017 16:59
|
|
|
|
|
#
?
Apr 24, 2017 17:26
|
|
|
rjmccall posted:transactions are a great paradigm for databases, definitely agree there. i have not really thought about tm as a database implementation technology. just saying that i think stm is really problematic as a general-purpose synchronization system, in part because it's such an elegant-feeling design oh, i hear you on this, you don't get to drop it in and magically get performance, but at least you get safety. when i'm talking about stm over locks, i'm not talking about pipelining stuff, paralellism, but sharing state under concurrent but mostly independent update, which is handwaving i guess. but my preference for a stm like thing over locks is more that i mean 'things that are unsafe to compose should be wrapped in interfaces that provide safe composition' a coarse level, i'm arguing for atomic queues, lists, etc over homebrewing locks, but i also mean that you should really use something to compose those atomic operations safely, and locks aren't great at it but if you end up doing multi-key operations, well, or, you've implemented something like multiple compare and swap you're 80-90% of the way to a stm-alike operation
|
|
#
?
Apr 24, 2017 18:40
|
|
|
has anyone even delivered correct/performant stm? like it was hot new research when i was in school, but intc botched the first shipment, ll/sc isn't stm
|
|
#
?
Apr 24, 2017 18:59
|
|
|
tsx is hardware transactional memory  that's all i really want, i want a load/store buffer that can support like 6 operations and which just fails if one of the operations would have trapped, so that i can make simple lockless data structures through random memory without a gc
|
|
#
?
Apr 24, 2017 19:13
|
|
|
|
| # ? Jun 2, 2024 23:51 |
|
|
i think stm only ever made sense in the "incredibly optimistic" category, as in software that in principle had to have a lot of locks, but even if you removed them all it still usually ran for a good bit before anything bad happened. that is, i think most formulations of stm had very low overhead if you actually never rolled back any transaction which, in principle likely is a fair portion of a fair bit of software, but the moment you actually put it under contention it collapsed entirely, and it is really hard to actually look at most software and go "ah, here is the one lock that will actually content, the other 9,999 can be dropped with stm"
|
|
#
?
Apr 24, 2017 19:14
|
|