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.
Generic heart disease runs in the family. Every male in my family basically dies of it, it doesn't matter how fit they are or how much they lift or run. Hasn't mattered. This goes back 5 or 6 generations.
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.
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.
> I choose what seems like the "dumb" solution at first glance: a trie (prefix tree).
> There are "smarter" solutions like... hash tables.... 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.
Strangely, my own software-related answer is the opposite for the same reason.
I was implementing something for which I wanted to approximate a https://en.wikipedia.org/wiki/Shortest_common_supersequence , and my research at the time led me to a trie-based approach. But I was working in Python, and didn't want to actually define a node class and all the logic to build the trie, so I bodged it together with a dict (i.e., a hash table).
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].
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.
I agree with you. But, talk too long or too fulsomely about "abstractions" or "principles" and you'll lose the brick layers. They're paid by the course, generally. Trust them to make the site adjustments, but always verify that it's not a bad-bad-thing.
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.
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.
It is also a bit funny that the author complains about older Fortran programs requiring SCREAMING_CASE, when if anything this is an improvement over previous and current practices. Too many Fortran codes have overly terse variable names that often were just single characters or impenetrable abbreviations for obscure terms. I have had to create cheat sheets for each program to figure out what each variable was.
Sun Microsystems had a great quote about this back in the day [1]:
> Consistently separating words by spaces became a general custom about the tenth century A.D., and lasted until about 1957, when FORTRAN 77 abandoned the practice.
Huh, I remember actually being taught this at school, but they never bothered to give (or I never bothered to remember) an example of a programming language that actually named void functions differently or indeed why it couldn't just be a void function. Looking at it now, it seems to be a difference inherited from mathematics, which would also explain why it's in Fortran too.
The main difference between functions and subroutines in Fortran and other ancient programming languages is not the fact that subroutines do not have a return value.
The functions of Fortran are what would be called pure functions in C (which can be marked as such with compilers that support C language extensions, like gcc).
The pure functions cannot modify any of their arguments or any global variable, and they must be idempotent, which is important in program optimization.
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.
What practical difference ever existed, beyond the fact that a subroutine does not return a value? AFAIK variable scope was handled identically. Recursion was likewise identical (forbidden originally).
The very important difference is that what are called functions in Fortran are called pure functions in other languages, i.e. functions that do not modify their arguments or global variables and which are idempotent, helping program optimization.
This means that Fortran functions are functions in the mathematical sense. In most early programming languages "functions" were functions in the mathematical sense, while other kinds of subprograms were named procedures or subroutines. The use of the term "function" for any kind of procedure has been popularized mainly by the C language, even if there were earlier languages where all procedures could return a value and even where any program statement was an expression, starting with LISP.
Many C/C++ compilers, e.g. gcc, support language extensions allowing functions to be marked as pure. This is always recommended where applicable, for better program optimization.
This difference is much more important than the fact that subroutines do not return a value.
Many of the "functions" of C/C++ must be written as subroutines in Fortran, with an extra argument for the result, but because they modify some arguments or global variables, not because they were written as "void" functions in C/C++.
Functions return a value, subroutines do not. So functions can, at the whim of the compiler, cause an extra copy.
Style wise, many prefer to reserve functions for things that resemble mathematical functions (i.e. only intent(in) and pure). In some sense a little bit similar to how people tend to use lambdas in python.
In a well designed programming language, the compiler should always decide at its whim, whether input or output parameters need an extra copy or not, i.e. if they should be passed by value or by reference.
The programmer must only specify the behavior of the parameters, i.e. if they are input, output or input-output parameters, like in Ada.
The fact that a parameter is the result is just a matter of syntax, not of semantics. Any other output parameters should behave exactly like the result. This means that for any output parameter, like also for the result, the compiler must decide between receiving the output value in a register or passing an extra pointer on input that is the address of a memory area where the function must write the output value.
Functions, the way we use them in mathematical equations, have a particular syntax. The point of functions in Fortran is to mimic this as closely as reasonably possible (consider it is a language with a long history).
Giving the user low-level control of how memory is used can be very useful for writing fast code. The compiler is not omniscient. Providing the choice is not bad language design.
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.
Fortran functions correspond to "pure" functions in C/C++ and other languages, i.e. idempotent functions that do not modify arguments or global variables.
If a C/C++ function is converted to Fortran, it must be rewritten as a subroutine, unless it is a pure function.
Not all C/C++ compilers support the language extension of marking functions as pure, and even with such compilers many programmers are lazy, so they forget to mark as pure the functions where this is applicable, even if this is recommended for improving program optimization and verification.
Fortran function were pure functions because this is the mathematical sense of the term "function". The extension of the meaning of the word "function" for any kind of procedure happened decades after the creation of Fortran.
The distinction between a "void" function and other functions has negligible importance. On the other hand the distinction between "functions" in the C language sense and "pure functions" is very important and programmers should better mark as "pure" all the functions for which this is true. This is at least as important for program optimization and for checking program correctness as declaring a variable with the correct type.
> Fortran functions correspond to "pure" functions in C/C++ and other languages, i.e. idempotent functions that do not modify arguments or global variables.
This is nonsense. Fortran functions aren't pure. They can have side effects.
HPF/Fortran '95 added the PURE attribute for subprograms, but it's not the default.
Functions are called only within the context of expression evaluation, and Fortran allows a compiler to perform algebraic transformations on expressions. If you write X=Y*F(Z) and we can determine that Y is zero, the function call can be deleted. So side effects in functions are somewhat risky.
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.
I find it annoying in Java when uppercase is used because its an acronym. URL or UUID. No man, just Url/Uuid. No need to yell just because its an acronym.
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.
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.
[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC6306777/