@ireneista @multioculate @emma I would argue that the problems these systems are solving are complicated, and so any system that solves them must also be complicated. To give just one example, one cannot understand software that flies an airplane with...
-
@alwayscurious @multioculate @emma he was extremely well paid so it's not (3). we agree that (1) and (2) are relevant but at some point you also have to look at the amount of effort that's been spent on it, and trust the assessment of the people who've worked in it, and say that the code itself is at least partly to blame
-
@alwayscurious @multioculate @emma we specifically pointed out the overlap between aviation and military up-thread, so, thank you for pointing it out back to us we guess, but it doesn't make us feel like you're listening
-
@alwayscurious @multioculate @emma also the goal here, just to once again re-state the thing we started from, is to have code that can be put away and not a thing that needs active maintenance for a long period of time, decades
and then dusted off and maintained again when new needs arise that force that
-
@alwayscurious @multioculate @emma that fundamentally excludes large scale ongoing training programs as a solution
-
Demi Marie Obenourreplied to Irenes (many) last edited by
@ireneista @multioculate @emma Do you mean training on the specific codebase, or training on software development and/or the underlying problem domain?
-
Irenes (many)replied to Demi Marie Obenour last edited by
@alwayscurious @multioculate @emma the codebase and problem domain
-
Demi Marie Obenourreplied to Irenes (many) last edited by
@ireneista @multioculate @emma Codebase I agree with, but how can someone jump into code without first understanding the problem the code is trying to solve?
My first programming internship involved writing simulations, and my main problem was not the programming (even though I was a very new programmer), but rather insufficient knowledge of numerical algorithms and the underlying problem domain.
-
Irenes (many)replied to Demi Marie Obenour last edited by
@alwayscurious @multioculate @emma that's why this is an unsolved problem! we're trying to describe the problem, as a step towards the world maybe someday having a solution to it
-
@alwayscurious @multioculate @emma you know that thing where, when you try to turn an explanation from a textbook into code, you immediately discover a ton of decisions the textbook glossed over?
-
@alwayscurious @multioculate @emma doesn't matter what field the text is in; the knowledge that experts in the field have is still a strict subset of the knowledge that is needed to formalize it into code. it's honestly kind of impressive that code for difficult science and engineering tasks gets written at all.
-
Demi Marie Obenourreplied to Irenes (many) last edited by
@ireneista @multioculate @emma Can you explain fruther? I haven’t dealt with textbooks since college, so my memory of that isn’t too great.
-
Irenes (many)replied to Demi Marie Obenour last edited by
@alwayscurious @multioculate @emma for example, we once attempted to write some speech synthesis code that relied on doing an inverse Fourier transform, based on math references that described the Fourier algorithms and on a couple textbooks in phonetics (which is a branch of linguistics)
-
@alwayscurious @multioculate @emma a thing we discovered is that the math people are very clear that a Fourier transform of a sound-like signal involves some sampling function that's applied in a sliding window over time, and that you get considerably different-looking spectrograms from the same signal depending on that function
-
@alwayscurious @multioculate @emma the linguistics people don't seem to know that's a thing at all. like we're sure if you talked to grad students who'd have to do it, they'd tell you oh you have to put about 15 milliseconds as the parameter into the sound editing program or you don't get a spectrogram that looks good and shows the formants clearly.... but the textbooks and even research papers in that field don't discuss it at all
-
@[email protected] @[email protected] @[email protected] @[email protected] One of my biggest blockers from ever finishing a certain paper (other than my ADHD, which, in hindsight, was a huge one) was the amount of detail I felt it needed vs. the amount of detail the corresponding author thought it needed. To wit, I don't think the methods would have been reproducible without explicit detail and the corresponding author always just wanted that section shorter. It was a nightmare.
-
@[email protected] @[email protected] @[email protected] @[email protected] I'm also reminded of the difficulties I had implementing a method from a paper I was a co-author on (because I supplied data, and was also part of the editing process)...