TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Bad scientific code beats code following "best practices" (2014)

230 pointsby luuover 1 year ago

56 comments

lynndotpyover 1 year ago
Scientist and programmer here, and my experiences are the opposite. I value keeping things &quot;boringly simple&quot;, but I desperately wish there was any kind of engineering discipline.<p>First is the reproducibility issue. I think I&#x27;ve spent about as much time simply _trying_ to get the dependencies of research code to run as I have done writing or doing research in my PhD. The <i>simple</i> thing is to <i>write a requirements.txt file</i>! (For Python, at least.)<p>Second, two anecdotes where not following best practices ruined the correctness of research code:<p>- Years ago, I was working on research code which simulated a power-grid. We needed to generate randomized load profiles. I noticed that each time it ran, we got the same results. As a software engineer, I figured I had to re-set the `random` seed, but that didn&#x27;t work. I dug into the code, talked to the researcher, and found the load-profile algorithm: It was not randomly generated, but a hand-coded string of &quot;1&quot; and &quot;0&quot;.<p>- I later had the pleasure of adapting someone&#x27;s research code. They had essentially hand-engineered IPC. It worked by calling a bash script from Python, which would open other Python processes and generate a random TCP&#x2F;IP socket, the value of which was saved to an ENV variable. Assuming the socket was open, the Python scripts would then share the socket names of other filenames for the other processes to read and open. To prevent concurrency issues, sleep calls were used throughout the Python and Bash script. This was four Python scripts and two shell scripts, and to this day, I do not understand the reason this wasn&#x27;t just one Python script.
评论 #38894386 未加载
评论 #38893759 未加载
评论 #38895018 未加载
astrobe_over 1 year ago
This is partly because, in my opinion, some &quot;best practices&quot; are superstitions.<p>Some practice was best because of some issue with 80s era computing, but is now completely obsolete; problem has been solved in better ways or has completely disappeared thanks e.g. to better tooling or better, well, practices. e.g. Hungarian notation. Yet it is still passed down as a best practice and followed blindly because that&#x27;s what they teach in schools. But nobody can tell why it is &quot;good&quot;, because it is actually not relevant anymore.<p>Scientific code has no superstitions (as expected I would say), but not for the best reasons; they didn&#x27;t learn the still relevant good practices either.
评论 #38890343 未加载
评论 #38890159 未加载
评论 #38890479 未加载
评论 #38893703 未加载
评论 #38894535 未加载
评论 #38893922 未加载
评论 #38890542 未加载
jusssiover 1 year ago
Two more to the scientists&#x27; tab:<p>1. No tests of any kind. &quot;I know what the output should look like.&quot; Over time people who know what it should look like leave, and then it&#x27;s untouchable.<p>2. No regard to the physical limits of hardware. &quot;We can always get more RAM on everyone&#x27;s laptops, right?&quot;. (You wouldn&#x27;t need to if you just processed the JSONs one at a time, instead of first loading <i>all</i> of them to the memory and then processing them one at a time.)<p>Also the engineers&#x27; tab has a strong smell of junior in it. When you have spent some time <i>maintaining</i> such code, you&#x27;ll learn not to make that same mess yourself. (You&#x27;ll overcorrect and make another, novel kind of mess; some iterations are required to get it right.)
评论 #38890725 未加载
评论 #38890035 未加载
评论 #38892228 未加载
gregopetover 1 year ago
Sounds like the non-programmers are good at what they are supposed to be good at (solving the actual problem, if perhaps not always in the most elegant manner) while the programmers should be producing a highly maintainable, understandable, testable and reliable code base (and potentially have problems with advanced algorithms that rely on complicated theorems), but they are not. The OP has a case of bad programmers - the techniques listed as bad can be awesome if used with prudence.<p>A good programmer has a very deep knowledge of the various techniques they can use and the wisdom to actually choose the right ones in a given situation.<p>The bad programmers learn a few techniques and apply them everywhere, no matter what they&#x27;re working on, with whom they are working with. Good programmers learn from their mistakes and adapt, bad programmers blame others.<p>I&#x27;ve worked with my share of bad programmers and they really suck. A good programmer&#x27;s code is a joy to work with.
评论 #38889392 未加载
laserbeamover 1 year ago
I agree with the feelings of the author, most software is overengineered (including most of my software).<p>That being said, most scientific code I&#x27;ve encountered doesn&#x27;t compile&#x2F;run. It ran once at some point, it produced results, it worked for the authors and published a paper. The goal for that code was satisfied and than that code somehow rusted out (doesn&#x27;t work with other compilers, hadn&#x27;t properly documented how it gets build, unclear what dependencies were used, dependencies were preprocessed at some point and you can&#x27;t find the preprocessed versions anywhere to reproduce the code, has hardcoded data files which are not in the published repos etc.). I wouldn&#x27;t use THAT as my compass on how to write higher quality code.
评论 #38890886 未加载
评论 #38894331 未加载
jakobnissenover 1 year ago
I&#x27;m a scientist programmer working in a field comprised by biologists and computer scientists, and what I&#x27;ve experienced is almost exactly the opposite of the author.<p>I&#x27;ve found the problems that biologists cause are mostly:<p>* Not understanding dependencies, public&#x2F;private, SCM or versioning, making their own code uninstallable after a few months<p>* Writing completely unreadable code, even to themselves, making it impossible to maintain. This means they always restart from zero, and projects grow into folders of a hundred individual scripts with no order, depending on files that no longer exists<p>* Foregoing any kind of testing or quality control, making real and nasty bugs rampant.<p>IMO the main issue with the software people in our field (of which I am one, even though I&#x27;m formally trained in biology) is that they are less interested in biology than in programming, so they are bad at choosing which scientific problems to solve. They are also less productive when coding than the scientists because they care too much about the quality of their work and not enough about getting shit done.
评论 #38891546 未加载
评论 #38891454 未加载
评论 #38891599 未加载
评论 #38891224 未加载
评论 #38891241 未加载
评论 #38891906 未加载
评论 #38892953 未加载
评论 #38893516 未加载
评论 #38893326 未加载
评论 #38892085 未加载
评论 #38891202 未加载
评论 #38892247 未加载
mglzover 1 year ago
I just handed in my PhD in computer science. Our department teaches &quot;best practices&quot; but adherence to them is hardly possible in research:<p>1) Requirements change constantly, since... it&#x27;s research. We don&#x27;t know where exactly we&#x27;re going and what problems we encounter.<p>2) Buying faster hardware is usually an option.<p>3) Time spent on documentation, optimization or anything else that does not directly lead to results is directly detrimental to your progress. The published paper counts, nothing else. If a reviewer ask about reproducibility, just add a git repository link.<p>4) Most PhD students never worked in industry, and directly come from the Master&#x27;s to the PhD. Hence there is no place where they&#x27;d encounter the need to create scalable systems.<p>I guess Nr. 3 is has the worst impact. I would <i>love</i> to improve my project w.r.t. stability and reusability, but I would shoot myself into the foot: It&#x27;s no publishable, I can&#x27;t mention it a lot in my thesis, and the professorship doesn&#x27;t check.
评论 #38895293 未加载
评论 #38894597 未加载
quickthrower2over 1 year ago
I agree. Been doing devops recently but back at some coding at work and I wrote the function as simple as I could, adding complexity but only as needed.<p>So it started as a MVC controller function that was as long as your arm. Then it got split up into separate functions, and eventually I moved those functions to another file.<p>I had some genuine need for async, so added some stuff to deal with that, timeouts, error handling etc.<p>But I hopefully created code that is easy to understand, easy to debug&#x2F;change.<p>I think years ago I would have used a design pattern. Definitely a bridge - because that would impress Kent Beck or Martin Fowler! But now I just want to get the job done, and the code to tell a story.<p>I think I pretend I am a Go programmer even if I am not using Go!
评论 #38890558 未加载
Nursieover 1 year ago
Yeah nah.<p>There was the flawed model out of Imperial College (IIRC) during the early covid days that showed up how wrong this attitude is.<p>It was so poorly written that the results were effectively useless and non-deterministic. When this news came out, the scientists involved doubled down and instead of admitting that coding might be hard, and getting in a few experts to help out might be useful, actually <i>blamed software engineers for how hard it is to use C++</i>.
dahartover 1 year ago
In other words, programmers tend to over-engineer, and non-programmers tend to under-engineer. Despite all the arguments here about who’s making the biggest messes, that part is not surprising at all.<p>Both are real problems. Over-abstraction and over-engineering can be very expensive up front and along the way, and we do a lot of it, right? Under-engineering is cheaper up front but can cause emergencies or cost a lot later. Just-right engineering is really hard to do and rarely ever happens because we never know in advance exactly what our requirements and data really are.<p>The big question I have about scientific environments is why there isn’t more pair-programming between a scientist and a programmer? Wouldn’t having both types of expertise vetting every line of code be better than having each person over&#x2F;under separately? Ultimately software is written by teams, and it’s not fair to point fingers at individuals for doing the wrong amount of engineering, it’s up to the entire team to have a process that catches the wrong abstraction level before it goes too far.
评论 #38892569 未加载
dkarlover 1 year ago
Programmers want to embed domain terms everywhere. They look at scientific code and expect to see variables names containing &quot;gravity,&quot; &quot;velocity,&quot; etc.<p>Scientists need code to conform to the way they examine, solve, and communicate problems. I asked for an explanation of a particular function and was sent a PDF and was told to look at a certain page, where I found a sequence of formulas. All of the notation matched up, with the exception that superscripts and subscripts could not be distinguished in the code. To a programmer, the code looked like gibberish. To the scientists working on the code, it looked like a standard solution to a problem, or at least the best approximation that could be given in code.<p>You see the inverse problem when it comes to structuring code and projects: programmers see standard structures, expected and therefore transparent; scientists see gibberish. Scientists look at a directory called &quot;tests&quot; and think of a variety of possible meanings of the word, none of them what the programmer intended.
评论 #38891813 未加载
cneweyover 1 year ago
While I think there are a couple of valid points, in general my feeling is that the author is setting up a straw man to attack.<p>Most of the “programmer sins” are of the type that more seasoned engineers will easily avoid, especially those with experience working with scientific code. Most of these mistakes are traps I see junior developers falling into because of inexperience.
YouWhyover 1 year ago
I think we have a case of survivorship bias.<p>A considerable majority of the science-non-SWE crowd are de facto incapable of writing more than 100 lines of runs-in-my-notebook code.<p>Hence, if a change&#x2F;bug is necessary, it is much likelier to fall under a SWE jurisdiction, and hence is much more likely to be industrial code.<p>Add to that a further confounder (tiptoeing a &quot;no true Scotsman&quot; here): academia is not a first choice of workplace for strong SWEs.
bearsnowstormover 1 year ago
Read this on mobile and the identifier longWindedNameThatYouCantReallyReadBTWProgrammersDoThatALotToo overflowed into the margins - I regard this not as a bug but a feature which helped make the author’s point :-)
评论 #38889366 未加载
austin-cheneyover 1 year ago
&gt; Invariably, the biggest messes are made by the minority of people who do define themselves as programmers.<p>After 15 years of writing JavaScript professionally I know that is a lie. The biggest messes are made by the majority of people hired that cannot really program.
评论 #38890881 未加载
评论 #38892410 未加载
jurschreuderover 1 year ago
This is so true I don&#x27;t think I ever read something so true.<p>It&#x27;s not even scientists vs software developers. It&#x27;s people who are really into software development and clean code.<p>They say the program needs a total rewrite and proceed to add 20 layers of inheritance and spreading out every function over 8 files.<p>Ever since I make sure to repeat my mantra every week to developers:<p>How maintainable code is is measured in how many files you have to edit to add one feature.
评论 #38889218 未加载
评论 #38889130 未加载
评论 #38889863 未加载
评论 #38890389 未加载
评论 #38892115 未加载
评论 #38892917 未加载
评论 #38889146 未加载
评论 #38889108 未加载
评论 #38893236 未加载
评论 #38889101 未加载
评论 #38889106 未加载
fulafelover 1 year ago
&gt; Simple-minded, care-free near-incompetence can be better than industrial-strength good intentions paving a superhighway to hell. The &quot;real world&quot; outside the computer is full of such examples.<p>Overengineering is insidious - &quot;It is difficult to get a man to understand something, when his salary depends upon his not understanding it&quot;. A team can sell a solution better than a single person fixing something without making a big deal out of it. You get organizational clout and inertia on your side when you make something big and expensive.<p>And then complex systems are by nature hard to reason about and by extension hard to critique.<p>So many things come down to &quot;complexity is the enemy&quot;.
评论 #38889045 未加载
评论 #38889048 未加载
scjover 1 year ago
Best practices tend to be overkill for small codebases that have few users, which encompasses the majority of scientific code.<p>Sheer tenacity is typically sufficient for scientific codebases.
wilgover 1 year ago
Is this article just two strawmen fighting?
nickm12over 1 year ago
&gt; I&#x27;ve been working, ... in an environment dominated by people with a background in math or physics who often have sparse knowledge of &quot;software engineering&quot;. ... Invariably, the biggest messes are made by the minority of people who do define themselves as programmers.<p>Interesting switch in language here from &quot;software engineering&quot; to &quot;programmers&quot;. There is of course a long history of debate on these terms, whether there is a meaningful distinction, and what qualifies as engineering versus programming.<p>Wherever you stand on this debate, there are a number of practices of software developers that tend to be used more towards the &quot;engineering&quot; side. Two of the most essential in my mind are peer code reviews and automated testing of changes (with tests, linters, type-checkers, code formatters, profilers, fuzzers, etc.).<p>This post doesn&#x27;t talk about any of these practices or whether the so-called &quot;programmers&quot; messing up the scientific code are using them. I&#x27;d say if the people messing up the code are not actually advocating for using software development tools to write better code they are not actually applying software engineering practices to their code.
评论 #38890809 未加载
MichaelRoover 1 year ago
I&#x27;ve seen this:<p>- Multiple&#x2F;virtual&#x2F;high-on-crack inheritance:<p><pre><code> add each function&#x2F;class has 7 template specialization parameters and 3 macros which expand to templates which expand to macros </code></pre> - Lookup using dynamic structures from hell – dictionaries of names where the names are concatenated from various pieces at runtime, etc.<p><pre><code> think maps of maps of maps loaded from configs of configs </code></pre> - Dynamic loading and other grep-defeating techniques<p><pre><code> obviously everything has to be a &quot;plugin&quot; </code></pre> - A forest of near-identical names along the lines of DriverController, ControllerManager, DriverManager, ManagerController, controlDriver ad infinitum – all calling each other<p><pre><code> a 1000 times yes! yes!!! DriverController inherits from ControllerManager which extends ManagerController which contains a DriverManager which agregates 3 ControllerManager from diferent namespaces. I&#x27;ve seen a DriverController function going through 12 levels of stack passed between 3 threads to eventually call back a function from the same DriverController </code></pre> - Templates calling overloaded functions with declarations hopefully visible where the template is defined, maybe not<p><pre><code> if a template technique exists, it had to be used! </code></pre> - Decorators, metaclasses, code generation, etc. etc.<p><pre><code> Of course they define their own DDL with xmls parsed by a combination of Python and awk which generates C++ macros which are used in templates to dynamically load plugins which hold maps of maps of function pointers to create3 events dispatched on a pool of threads</code></pre>
评论 #38891490 未加载
Spiwuxover 1 year ago
I really do not understand these memes about overengineered FactoryFactoryFactories. I have 10 YOE, did I just get lucky? I&#x27;ve worked at enterprise Java shops as well, but even there I&#x27;d call the software pragmatic. Are these overengineered monstrosities REALLY still a thing, or is it &quot;just&quot; people suffering in legacy projects? Even the juniors I worked with were following KISS and YAGNI.
评论 #38890400 未加载
评论 #38890354 未加载
fifiluraover 1 year ago
This is the battle I am currently fighting.<p>Specifically when working with numbers (something scientists do), i feel it is more important to know the numbers and have an intuition of what is important to get right and what is less important. Rather than spreading unit tests and the following abstractions all over the place.<p>But scientists can create a hot mess too. This is when they don&#x27;t care about the code enough to minify it. I.e. reducing the code to what is necessary.<p>Number of lines of code matter.<p>So the perfect blend here is not necessarily the person that follows all engineering practices. But the person has the domain knowledge but that knows enough about software practices to be able to write concise code.<p>If you are either missing out on the domain knowledge - or the ability to reduce the code - then it will derail.<p>Shipping the notebook to engineering department will not be the solution. They will break the code into pieces, follow best practices but miss out on the important.<p>And another aspect of this practice is that if someone finds a problem, the scientist will not be able to modify or re-run the engineered version of the notebook.
Roark66over 1 year ago
&gt;Multiple&#x2F;virtual&#x2F;high-on-crack inheritance 7 to 14 stack frames composed principally of thin wrappers, some of them function pointers&#x2F;virtual functions, possibly inside interrupt handlers or what-not Files spread in umpteen directories<p>Scientific code? You just described 99% of &quot;enterprise&quot; java code above.
评论 #38890115 未加载
TrackerFFover 1 year ago
Only thing I&#x27;ve struggled with, is when real software engineers whip up &quot;enterprise&quot; code for even the simplest and most trivial programs. If you&#x27;ve heard of the infamous &quot;enterprise hello world&#x2F;fizzbuzz&quot;, then imagine that type of structure.<p>I guess it stems from the ideology that it is better to do lots of groundwork now, in case the program blows up and needs to scale. Which is somewhat true...but in the world I work in, it is only true for maybe 1% of programs we write.<p>So in the majority of cases, if I need to fork some software at work and do easy modifications, I do prefer the one-file programs, compared to some behemoth where almost everything is boilerplate, spread over multiple source files, folders, etc.
dash2over 1 year ago
Ulp. As a scientist who is a hobby &quot;programmer&quot;, this struck close to home. I&#x27;ve got one project[1] with a huge mess of functions calling each other. It started out with good intentions, but then gradually descended as I wrote more and more hacks to add new analyses &amp; robustness checks. I swear I meant well!<p>I think there&#x27;s a genuine tension between writing good code and &quot;shipping&quot; a paper. At least, when I program &quot;as a programmer&quot; I think my code is mostly higher quality.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;hughjonesd&#x2F;why-natural-selection&#x2F;blob&#x2F;master&#x2F;_drake.R">https:&#x2F;&#x2F;github.com&#x2F;hughjonesd&#x2F;why-natural-selection&#x2F;blob&#x2F;mas...</a>
LudwigNagasenaover 1 year ago
I will believe that when scientists will stop being too embarrassed to publish their code. Do people not remember mrc-ide&#x2F;covid-sim?
评论 #38892406 未加载
briantakitaover 1 year ago
Some people incorporate antipatterns into their practice &amp; reinforce these antipatterns with years of experience. All fields have this issue. Bad professional scientists are often worse than effective amateur scientists. Having good first principles with little experience often beats plenty of experience with bad first principles.<p>I have learned to appreciate codebases which break some rules &amp; yet are easier to maintain for some reason(s) Distilling the reason(s) identifies areas where I can modify my technique...or at least help identify questions &amp; alternatives to some techniques that I regularly use.
cube00over 1 year ago
When scientific code is not required to be published with its research literature who really knows how bad it is?
评论 #38889330 未加载
quirkotover 1 year ago
Good code is the simplest code you can write to get the job done.<p>Getting too excited about techniques is a form of scope creep
评论 #38890022 未加载
diracs_stacheover 1 year ago
Not sure what the exact context the blog refers to (they are a scientist turned software engineer?, their field is data&#x2F;software intensive and see this as an improvement area?). Our team does engineering test and evaluation that include aspects of R&amp;D and struggle with this. Scientists have academic approaches (must have sufficient sampling&#x2F;statistical significance, sometimes delaying findings&#x2F;reports checking additional aspects when a sanity check will suffice) but it does give rigor. On the software side, we definitely have spaghetti code, tools that rely on some file sitting in someone&#x27;s H-drive, and plug-ins built by someone&#x27;s old collaborator with little documentation. This is juxtaposed by the PM types that must be agile (fine when tasks are understood and defined enough to go nicely into a sprint, not always the case). Better communication on both sides would probably alleviate some of this but that is the great challenge in any group.
renewiltordover 1 year ago
Cost is paid during development and maintenance. Value is reaped during usable life. The two periods overlap. Then subtract value from cost and integrate. Maximize that number.<p>Easily leads to conclusions of &quot;you don&#x27;t need this to scale&quot; vs &quot;build this to scale&quot; and &quot;you need to make this extensible&quot; vs &quot;just ship the hacky thing&quot;.<p>Just need to know what your params are and place uncertainty on it.<p>Once I wrote a program in a day. Did a kind of pricing. Hacky af. Just tech demo. Over time people start depending on it. One year later it breaks. Too many products priced, internal ring buffer only has few slots. Pricing stalls for all products.<p>&quot;This is a company-killing issue!&quot; Everyone yells. Sure, my mistake. I let thing get depended on without productifying but original choice was fine since it allowed iteration on something else that made money. Just when situation changes you gotta adapt.<p>No rules about that except just short loop on quality required and time spent.
zeraholladayover 1 year ago
I think a lot of developers naively rely on &quot;software design&quot; principles. They often can&#x27;t state their reasons for adopting these principles and assume these principles are self-evident. This can be a problem when these principles conflict with external priorities, or when a complex &quot;principled&quot; design is used instead of an obvious, intuitive design. There&#x27;s also a certain amount of trendiness to software design, so trends can be applied haphazardly.<p>That being said, I&#x27;ve also seen plenty of &quot;scientific code&quot; that&#x27;s totally incomprehensible even to the point where the scientist who wrote the code can&#x27;t debug it. So there&#x27;s an extreme in the other direction.
alexeizover 1 year ago
A lot of scientific research code is execute-once-throw-away code. Once the code obtains a result you can put into your research paper, it has served its purpose and it&#x27;ll never be used again. There is no need for any kind of abstraction, software design, architecture or development best practices. You&#x27;re not going to be supporting this code or extending it in the future. If you&#x27;re a software developer, the way researchers write code rubs you the wrong way. But you have to accept the reality. Applying software development principles to scientific code is just a waste of time.
alexmolasover 1 year ago
Now I dare you to add some new functionality on a bad designed software. Ask a scientist to change a little bit the initial hypothesis and update the code accordingly, and watch them cry while rewriting all the code.
评论 #38890574 未加载
rukshnover 1 year ago
A former physicist at our organization wrote a tool t convert a diagram into an algorithm in a domain specific language.<p>He made it to make his own life easier, and never considered any best practices, everything was a thousands of lines of jupyter notebook, it was not modular, painful to customize but just got the work done, and was kinda a black box in way the way it generated the outputs.<p>Since then we&#x27;ve tried to re-write it with good programming principles, but still we were not able to re-create what he did. So yah sometimes done is better than perfect.
hannofcartover 1 year ago
I&#x27;m not so sure that this claim is valid as a general observation.<p>Multiple times in my career, I have seen scientific code written by academics dramatically sped up by developers who used parallelisation, vectorisation using SIMD etc.<p>So in terms of performance, naively written scientific code is generally easy to beat in terms of performance for a reasonably adept programmer.<p>That said, &quot;enterprisey&quot; Java&#x2F;.NET software engineering shops can indeed make scientific code sub-optimal sometimes. Have come across that sometimes too but I wouldn&#x27;t generalize.
edu_guitarover 1 year ago
One notable difference between scientific code and regular software development is that the code scientists write is an implementation of well defined&#x2F;documented mathematical models, while in a, say, web application, there is no reference paper or research, the code _is_ the reference. That&#x27;s why best practices are important, not for the person writing a piece of software now, but for the future. If you need to change scientific code, papers and specification make otherwise confusing structure more manageable.
amadeuspagelover 1 year ago
&gt; Files spread in umpteen directories<p>Tools and frameworks encourage this. Git and VS code are build around directories. In VS code the first thing in the sidebar is the explorer. When you press Ctrl+P you see an overview of files. File-System based routing.<p>But directories lack a crucial feature compared to text: Ordering. If I put everything in one file, I can order it in a way that makes sense. If I put everything in different files and directories, it&#x27;s all going to be ordered alphabetically.
dangover 1 year ago
Related:<p><i>Why bad scientific code beats code following “best practices” (2014)</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12377385">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=12377385</a> - Aug 2016 (261 comments)<p><i>Why bad scientific code beats code following &quot;best practices&quot;</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7731624">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=7731624</a> - May 2014 (168 comments)
niemandhierover 1 year ago
Scientific programming and industry programming are distinct disciplines.<p>For scientific code certain things are just not important, hence you do not deal with them:<p>- Observability: You just care for the result of the run, not for the state of the running system - Security: Your code is running in isolation, used by yourself<p>The result looks horrible to a normal programmer, even if it’s well maintainable, but it is exactly what is needed to do the job.
评论 #38891066 未加载
collywover 1 year ago
Worst code I have seen has been written by self taught bioinformaticians.<p>But, a lot of the time these scripts are used as one offs, to generate a result, then are done with, so quality doesn&#x27;t need to be the same as with a server running 24&#x2F;7.(Sadly the ones I had to fix were being run regularly).
jmilloyover 1 year ago
Fortunately the list of &quot;bad&quot; code features attributed to each group is listed clearly. The title simply needs to read &quot;Bad scientist code beats bad programmer code&quot;, or &quot;A list of bad practices that programmers often think are good&quot;.
jayd16over 1 year ago
If the non programmers commit correctness bugs and the programmers are just using patterns you don&#x27;t like, maybe try to understand the patterns instead of balk at them.
评论 #38889066 未加载
评论 #38889190 未加载
ben_wover 1 year ago
&gt; Many programmers have no real substance in their work – the job is trivial – so they have too much time on their hands, which they use to dwell on &quot;API design&quot; and thus monstrosities are born.<p>Definitely getting this vibe from modern frameworks and design patterns.<p>I want to like SwiftUI, but the WYSIWYG editor doesn&#x27;t even work for the default projects for me. Storyboards were great for creating everything UI except tables and collections, where it was still functional just meh. The reactive UI in SwiftUI… mostly works, but sometimes doesn&#x27;t, and when it doesn&#x27;t I can&#x27;t debug it because it&#x27;s a magic black box; you can get similar results with a small amount of extra code in UIKit { didSet } on your model property and each input control, and while boilerplate isn&#x27;t great, it&#x27;s better than magic which only works 98% of the time.<p>I&#x27;m trying things in JS in my spare time, no libraries or frameworks, and it&#x27;s easier and faster than getting anything done in XCode. And that&#x27;s <i>despite</i> the Swift language itself being one I prefer over JS, and that I&#x27;m doing the development in BBEdit which is a text editor not a full IDE.<p>But this isn&#x27;t just about Apple; the reason I&#x27;m not using any JS framework and libraries is that every single talk I&#x27;ve seen about web development has exactly the same problem, piling on layers of stuff to fill in the gaps missed (or created) by the previous layer of abstraction.
评论 #38890778 未加载
davidd_1004over 1 year ago
Most scientific code breaks when anyone but the author of the paper tries to run it
smrtinsertover 1 year ago
The list of issues are mistakes juniors make, not best practices
r9295over 1 year ago
I wonder why people complain about the replication crisis.
puttycatover 1 year ago
OP is using a strawman caricature of a programmer to make his point. While such bad (often junior) programmers exist, there also exist many reasonable ones who won’t commit all these over the top abstractions while also not falling into the &quot;scientific&quot; programming pathologies.
analog31over 1 year ago
I&#x27;m a scientific coder, though I work in industrial R&amp;D feeding product development. My work doesn&#x27;t get published. I&#x27;ve studied good programming practices for 40 years, and I try to behave myself.<p>One thing I&#x27;ve noticed is that programming practices have evolved, not so much to make them better than before, though that&#x27;s conceivable. But because practices have to keep up with rising complexity of the code itself, and also of the operating environment and the social environment (e.g., work teams, open source projects, etc).<p>Scientific programs tend to be easily 20 years behind software development in terms of complexity, and I think we can benefit from using older techniques that were simpler and easier to learn. I learned &quot;structured programming&quot; via Pascal, and to this day if I hew to the same practices that I learned in my Pascal textbook, my program will probably do what it needs to do and be tolerably maintainable.<p>Perhaps those practices have to come from the mouths of scientists. The software engineers have moved on, and are only interested in the latest and greatest toys. I don&#x27;t blame them -- they have to own their careers and follow their interests just like we do.<p>I mentor younger scientists who come out of fields such as chemistry, and are beginners at coding. So I literally get to explain such basic things as putting code inside subroutines, and avoiding global variables. I haven&#x27;t had to tell anybody about GOTO&#x27;s yet.<p>About reproducibility: My parents were both scientists, though my mom spent a few years in mid-career teaching programming at a community college. I learned the scientific method sitting on my mommy&#x27;s knee. &quot;Reproducibility&quot; was certainly a guiding principle, but it was also expected that reproducing a result would require some effort -- perhaps fabricating your own equipment from available materials, and gaining skill on a technique. You might get it wrong many times before finally getting it right.<p>What we expect now is &quot;pushbutton&quot; reproducibility, meaning that a project replicates itself from start to finish at the push of a button. This is a much higher standard than any scientist is trained to expect, even if software engineering requires it. A software project has to be at least 99% that way, or it would be unworkable, due to the high degree of complexity. The tradeoff is that it also <i>requires</i> complexity to make things that way.<p>I expect my results to be reproducible, but not pushbutton-reproducible. To overcome this issue, I&#x27;d rather spend my time documenting my code and its theory of operation, than making it bulletproof. Nothing that I write goes directly into production, and I expect the theory of operation to be more valuable to a project than my code. Often, the code just automates an experiment to test the theory, so it&#x27;s a middleman rather than a product.
a-dubover 1 year ago
numerical code isn&#x27;t like application code. the rules of application code don&#x27;t always apply. for example, i think one character variable names are totally fine if they come from equations or papers where in most applications it&#x27;s generally frowned upon.<p>this is why i&#x27;m a little skeptical of languages that blur the lines. sometimes ideas from application programming can complicate numerical code and sometimes numerical programmers don&#x27;t fully understand the systems abstractions they&#x27;re building on and end up reinventing wheels to avoid simpler solutions they feared or didn&#x27;t know existed.<p>the moral of the story is to keep an open mind, to not be a zealot and to avoid dogmatic thinking.
Yasurakaover 1 year ago
Java and its consequences have been a disaster for the human race.
palataover 1 year ago
TL;DR: a counter-productive rant against software engineers, claiming that bad code from software engineers is worse than bad code from scientists.<p>Did you consider hiring an experienced software engineer as a lead?
评论 #38889152 未加载
评论 #38888976 未加载
评论 #38888972 未加载
评论 #38892332 未加载
lll-o-lllover 1 year ago
Meh.<p>Who actually works as a software dev at one of these academic institutions? The pay is beyond terrible. Presumably you have either:<p>- Young and keen. Young and keen are the source of all kinds of terrible things. That’s why you need old and bitter to balance it out. Old and bitter is off working for much more money in a boring corporate.<p>- Side hustlers&#x2F;other incompetents. “I’m now a software dev!”<p>It’s not that proper software shops don’t struggle against “complexification” and all manner of other deviant behaviours. There are so many ways to turn software into hell - “All happy families are alike; each unhappy family is unhappy in its own way.” But if this is your problem, the problem isn’t “the software industry” or “best practice” or “devs jobs are so easy they just have to make up complexity”. The problem is incompetence. Managerial&#x2F;leadership incompetence.
senorribover 1 year ago
Every year that passes these “SWE is an idiotic field” posts come earlier. So annoying…
9devover 1 year ago
Oh look, another tiring craftsmanship debate that other disciplines long figured out!<p>A, say, physicist writing bad code could equally well be building a pergola for his garden. He doesn’t really know woodworking but god be damned if he couldn’t calculate the forces acting on the beams, and then add some screws - how hard can it be! And probably, he’ll even get the thing up, and it doesn’t look too bad even. Now get a carpenter over, and they will be horrified about all the things the scientist did unusually, did not account for, or just plain wrong. ”Wall Screws you still had around?? How could you not know you’d need structural screws for that?“, he will scream. However, the thing does roughly what the scientist supposed it should do. Until the winter, that is, when the wood expands due to humidity and cracks appear, and he finally needs a professional to fix the problems.<p>It’s the same story, really: It is a software engineer’s job to build quality software. A scientists job is to solve problems. There’s a clear boundary here, where the latter will deliver a concept to the former, who will eventually create a production-grade implementation off of that. Neither does a scientist have to build proper software, nor does a developer have to do cutting-edge research.<p>And all the words wasted on how one of them might be doing something badly is on he wrong path.
评论 #38890797 未加载
评论 #38890561 未加载
评论 #38890428 未加载
评论 #38890522 未加载
评论 #38891226 未加载
评论 #38890581 未加载
评论 #38890884 未加载
评论 #38890219 未加载
评论 #38891478 未加载
评论 #38890149 未加载
评论 #38890308 未加载
评论 #38890831 未加载
评论 #38891516 未加载
评论 #38890872 未加载
评论 #38890437 未加载
评论 #38891483 未加载
评论 #38890300 未加载