atrettel

Location: Maryland, United States

Remote: Open to remote, hybrid, and in person

Willing to relocate: Yes

Technologies: C, C++, Fortran, Java, Message Passing Interface (MPI), OpenMP, Python (Matplotlib, Numpy, Pandas, Scipy), SQL (especially SQLite)

Résumé/CV: Available upon request

Email: https://www.andrewtrettel.com/hnjobs.png (to prevent spam, my email address is in the linked image)

GitHub: https://github.com/atrettel

Website: https://www.andrewtrettel.com/

Hi, I'm Andrew Trettel. I'm a scientist with a PhD in mechanical engineering looking for any potential opportunities outside of academia and research labs.

I am open to many different roles, including being a software developer or data scientist. I have over a decade of experience in scientific research, especially on the numerical side. I have years of experience in writing software for and running large simulations on high-performance computing (HPC) systems. I have also developed software for non-scientific purposes, like creating user interfaces for desktop applications and writing command-line tools. I have extensive experience using commercial and noncommerical computational fluid dynamics (CFD) codes. I have years of experience working with large datasets, including the tasks of calculating statistics and developing hypotheses/models/theories from data.

I've worn many hats over the years and love learning new and interesting topics.

I wish that I could agree with you that "There is always room for people who know what they are talking about." I think that you are right in the long term. Eventually we will return to a world that values people who know what they are talking about.

In the short term, I have seen a lot of managers and other higher-ups talk about how we do not need to worry about low-level details anymore. In their minds, we are now all designers and architects, so we do not think about the small implementation details that ultimately do matter for performance and reliability.

People who know what they are talking about worry about all of the details from the big picture down to the small scales. We can still operate using abstractions like designers and architects, but we must know enough to choose the right abstractions that account for the concrete details properly. I've discussed this point earlier this year [1] using the tree swing diagram [2].

[1] https://news.ycombinator.com/item?id=46422597

[2] https://en.wikipedia.org/wiki/Tree_swing_cartoon

What you wrote reminds me of the controversy around Robert Millikan's oil drop experiment [1]. It measured the charge of an electron. Later experiments confirmed the real value was slightly higher than Millikan reported. Many researchers who could not replicate Millikan's value just assumed that they did something wrong rather than questioning Millikan's value. It took a few decades, but fortunately science caught up with this. I often think about this when I see a colleague struggling to replicate something.

[1] https://en.wikipedia.org/wiki/Oil_drop_experiment#Millikan's...

I agree. I would have thought that the author would have discussed the incentives and then show how changing the incentives would lead to a better outcome. Instead the article just ends nebulously by saying "I am not sure how to fix this problem". I find that pretty confusing as a reader. The first sentence of the article implies a particular kind of solution, so it would at least make sense to discuss how changing the incentives might help. I am no fan of "publish or perish", so I would have loved to read about some alternatives.

And induction gets hot immediately. And it is easier to clean. And it is less likely to cause fires. It's just a better technology all around when compared to gas stoves. The only issue I personally have with it is that it is not compatible with all cookware.

I agree that visualization does not need to be perfect. One issue is that "correct visual output" depends on your expertise level. A visualization that is good to teach undergrads may be frustratingly bad to experts and researchers. Standards like "looking right" depend on the audience's ability to spot nuances and how focused they are on the fine details. If you want a visualization to work for the range of people from beginners to experts, you do need to focus a bit more on what it means for something to "look right" for multiple audiences, since the errors in the fine details may hinder a visualization's usefulness for more advanced audiences.

I get what you are saying, but my issue is not that it runs a script. My issue is that curl piped into a shell does not verify that the download is from the original source before running the script.

A .deb file has many advantages over curl piped into a shell. You can check the contents before installation, you can potentially verify the authenticity of the .deb file, and dpkg makes it possible to uninstall the package later since it keeps track of what it installed in an organized manner.

I won't say that I would feel safer with a .deb file. That depends on the source, what the package does, and other factors. Security is about tradeoffs. I personally find the tradeoffs associated with a .deb file better than the tradeoffs of curl piped into a shell, but I myself do not install .deb files in the first place since I get almost everything that I need from package repositories.

You raise a good point. This is why people sign the checksums. The signature confirms that authenticity of the checksums. That somewhat moves the goalpost, though, since it then depends on where you got the source's public key, but it is still a more secure practice overall. The advantage of having the public key is that you only need to get it once and you can check many downloads later.

It is also possible to have a signed file that you can use to check the authenticity of a downloaded file directly without having to use checksums. Rust [1] does it that way for its other installation methods.

[1] https://forge.rust-lang.org/infra/other-installation-methods...

Curl does verify certificates [1]. That does confirm that your connection is to the right server, but it does not confirm that the files were unmodified.

SSL/TLS/HTTPS is more about encrypting the traffic and ensuring that there was no tampering with the file between you and the server. The steps that I describe are more about ensuring that there was no tampering between you and the original source. Those are two separate problems. If you just rely on HTTPS, somebody can replace the file on the server with a modified version, and you would not know.

[1] https://curl.se/docs/sslcerts.html

The issue does not have to do with whether the download is a binary or source code. It has to deal with verifying the integrity of the download before installation.

Curl piped into a shell command provides no means to verify that the download is uncorrupted and unmodified before running it. For example, whenever I download software manually I check the downloaded file against the verified checksums to ensure that I have an unmodified version. Ideally I check this with gpg --verify on the signed checksum file (against the source's public key). This is a standard procedure for many organizations [1]. If you just download something and immediately run it without this step, you could potentially run a hacked version of the installation script.

[1] https://www.debian.org/CD/verify

I still have no comprehension of how curl piped into a shell command has become the default installation method for many projects (looking at you, Rust...). It breaks my brain as to how potentially unsafe it is.

Von Braun was not "just lucky" to get captured by the US. He and his immediate staff took active steps to get captured by the Americans [1].

[1] https://en.wikipedia.org/wiki/Wernher_von_Braun#Surrender_to...

I imagine that it could be usage, but it also could be fewer people caring to report issues on the weekends too for that matter.

The issue, in my experience, is that there is a lot of productive work that does not look productive at first glance. Long term work may not look productive for years until it suddenly is tremendously productive. And there is a lot of quiet and often thankless maintenance work that goes on largely unnoticed that helps others do their jobs well. Both have value despite superficially looking unproductive at times. I'd argue that both look productive at long time scales but unproductive at short time scales.

I've often described this as a bias towards easily taught ("teachable") material over more realistic but difficult to teach material. Sometimes teachers teach certain subjects because they fit the classroom well as a medium. Some subjects are just hard to teach in hour-long lectures using whiteboards and slides. They might be better suited to other media, especially self study, but that does not mean that teachers should ignore them.

Even if this line is true, and I am not saying that it is, running and other cardiovascular activities lower your resting heart rate [1]. So even if you believe that you only have a finite number of heart beats, running should in fact increase your lifespan.

[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC6306777/

I completely agree. The issue is that some misconceptions just never go away. People were talking about how bad lines of code is as a metric in the 1980s [1]. Its persistence as a measure of productivity only shows to me that people feel some deep-seated need to measure developer productivity. They would rather have a bad but readily-available metric than no measure of productivity.

[1] https://folklore.org/Negative_2000_Lines_Of_Code.html

I spent around 170 hours on this so far, with only 60% of that being coding. The rest was mostly research or writing.

Before I started the project, I was already vaguely familiar with the notion of an inverted index [1]. That small bit of knowledge meant that I knew where to start looking for more information and saved me a ton of time. Inverted indices form the bulk of many search engines, with the big unknown being how you implement it. I just had to find an adequate data structure for my application.

To figure that out, I remember searching for articles on how to implement inverted indices. Once I had a list of candidate strategies and data structures, I used Wikipedia supplemented by some textbooks like Skiena's [2] and occasionally some (somewhat outdated) information from NIST [3]. I found Wikipedia quite detailed for all of the data structures for this problem, so it was pretty easy to compare the tradeoffs between different design choices here. I originally wanted to implement the inverted index as a hash table but decided to use a trie because it makes wildcard search easier to implement.

After I developed most of the backend, I looked for books on "information retrieval" in general. I found a history book (Bourne and Hahn 2003) on the development of these kind of search systems [4]. I read some portions of this book, and that helped confirm many of the design choices that I made. I actually was just doing what people traditionally did when they first built these systems in the 1960s and 1970s, albeit with more modern tools and much more information on hand.

The harder part of this project for me was writing the interpreter. I actually found YouTube videos on how to write recursive descent parsers to be the most helpful there, particular this one [5]. Textbooks were too theoretical and not concrete enough, though Crafting Interpreters was sometimes helpful [6].

[1] https://en.wikipedia.org/wiki/Inverted_index

[2] https://doi.org/10.1007/978-3-030-54256-6

[3] https://xlinux.nist.gov/dads/

[4] https://doi.org/10.7551/mitpress/3543.001.0001

[5] https://www.youtube.com/watch?v=SToUyjAsaFk

[6] https://craftinginterpreters.com/

I recently wrote a command-line full-text search engine [1]. I needed to implement an inverted index. I choose what seems like the "dumb" solution at first glance: a trie (prefix tree).

There are "smarter" solutions like radix tries, hash tables, or even skip lists, but for any design choice, you also have to examine the tradeoffs. A goal of my project is to make the code simpler to understand and less of a black box, so a simpler data structure made sense, especially since other design choices would not have been all that much faster or use that much less memory for this application.

I guess the moral of the story is to just examine all your options during the design stage. Machine learning solutions are just that, another tool in the toolbox. If another simpler and often cheaper solution gets the job done without all of that fuss, you should consider using it, especially if it ends up being more reliable.

[1] https://github.com/atrettel/wosp

Location: Maryland, United States

Remote: Open to remote, hybrid, and in person

Willing to relocate: Yes

Technologies: C, C++, Fortran, Java, Message Passing Interface (MPI), OpenMP, Python (Matplotlib, Numpy, Pandas, Scipy), SQL (especially SQLite)

Résumé/CV: Available upon request

Email: [email protected]

GitHub: https://github.com/atrettel

Website: https://www.andrewtrettel.com/

Hi, I'm Andrew Trettel. I'm a scientist with a PhD in mechanical engineering looking for any potential opportunities outside of academia and research labs. I am open to many different roles, including being a software developer or data scientist. I have over a decade of experience in scientific research, especially on the numerical side. I have years of experience in writing software for and running large simulations on high-performance computing (HPC) systems. I have also developed software for non-scientific purposes, like creating user interfaces for desktop applications and writing command-line tools. I have years of experience working with large datasets, including the tasks of calculating statistics and developing hypotheses/models/theories from data. I've worn many hats over the years and love learning new and interesting topics.

Reading that particular section made me think of the tree swing cartoon [1]. I agree that the best engineers have likely been on the ground making concrete changes at some point, watching bricks being laid as you said, but I have encountered quite a few supervisors who seemingly had no idea how things were being implemented on the ground. As the post says, people on the ground then sometimes have to figure out how to implement the plan even if it ignores sound design principles.

I don't view that as a failure of abstraction as a design principle as much as it is a pitfall of using the wrong abstraction. Using the right abstraction requires on the ground knowledge, and if nobody communicates that up the chain, well, you get the tree swing cartoon.

[1] https://en.wikipedia.org/wiki/Tree_swing_cartoon

Disclaimer: I am not a lawyer. I am not your lawyer. This is not legal advice.

In the United States, the only patentable subject matter is processes, machines, manufactures, or compositions of matter [1]. Anything outside of those areas is not directly patentable. Some subject matter like mathematics and "mental processes" generally are categorized as "abstract ideas" that therefore are not directly patentable [2]. It is possible to patent something that contains an abstract idea, but it also has to have some "additional elements" that elevate it beyond merely claiming an abstract idea.

I suggest reading MPEP § 2106 [2] and looking at the first diagram given there titled "Subject Matter Eligibility Test for Products and Processes". That is the exact analysis that a patent examiner would use to determine if something is patentable subject matter or not (including for any claim with a prompt).

I strongly suggest that you talk to a lawyer if you want specific advice that answers your question directly. I'm not commenting on any copyright aspects.

[1] https://www.uspto.gov/web/offices/pac/mpep/s2104.html

[2] https://www.uspto.gov/web/offices/pac/mpep/s2106.html

The language enforced difference is that only functions can return a value, but other than that, they are quite similar and just called "procedures" generally. In my experience, Fortran programmers use them differently in practice, and that is more of a guideline than something enforced by the language itself.

They are pretty similar, but they are definitely used differently. For one, you have to "call" a subroutine in one statement, but you can use multiple functions on the same statement (since they can return values). Functions (usually) do not change their arguments, but subroutines often do. In some sense, functions are closer to how mathematical functions work but subroutines are closer to labels for certain procedures.

Yes, sorry for the confusion. To be clear, the quote is directly about spaces not being significant in the source code in general, but I was commenting more about how this mindset affects variable names in practice. At least in my experience, many codes would benefit from variables names that use underscores.

The article did not discuss this, but to me, one of the bigger differences between Fortran and more modern languages is the difference between functions and subroutines. Yes, they are not synonyms in Fortran and serve different purposes. I think this would trip up more people initially than the clunky syntax.

There is actually a lot of debate as to whether scientific discovery is driven by "heroes and geniuses" (as you argue) or by multiple people simultaneously and independently coming up with the same idea [1], often called "multiple discovery". Certainly both have occurred many times over.

That said, multiple discovery seems to be more common nowadays due to the rapid diffusion of information, which means that most people are operating in roughly the same information environment (initial conditions) when they start their research. It is interesting how often multiple discovery happens when you start to look closely at this.

[1] https://en.wikipedia.org/wiki/Multiple_discovery

It's not just for universities and for CFD. Slurm is the primary job scheduler at Los Alamos National Lab. I know other federal labs that use it too. It is just really popular in general.