Stellarium: Software which renders realistic skies in real time

How hard is it for a developer make this particular change?

And I mean literally observe this up close: navigating the directory structure, reading the docs, typing the code, running the app to check if everything works as expected.

Was it easy? What can change about the code, tests, docs, etc so future changes can be easier?

That's what really matters. Other measures are just proxies to the above analysis.

What I do see every day is "oh yeah, this method / file is pretty big, lets add one more thing to it anyways, I dont have time to refactor", and things grow and grow out of control.

I think one basic, and yet rare ability of a professional software engineer, and the skill that should separate you from a hobby programmer, is writing your code in a way which can scale and grow. The strategy for this cannot just be "let me put everything in one file, class, method and lets just see what happens".

That can be an OK first draft approach, but there needs to be a second step. And ultimately, if you set the architectural pattern of "big hairball", everyone else will happily follow it since its not their fault the architecture is like that - they are just adding one more thing. That can be OK for a first draft, but you will have to go back and introduce architecture and modularity at some point, or watch the project collapse under the weight of its own mess.

Once you see enough of those failures, you can start sensing basic patterns for introducing modularity, boundaries and structure to a project, to its modules, and to its classes and methods. As you keep flexing that muscle, in my experience, the "this code is best written as a huge single method" approach basically never seems like a good idea anymore.

"The building of the program is the same as the building of the theory of it by and in the team of programmers"

https://pablo.rauzy.name/dev/naur1985programming.pdf

But I bring up choice of (programming) language as an issue, because in many languages, once you need to operationalize your codebase — make it efficient and scalable, optimizing it with respect to real use in the field, then you'll begin to need things like:

• static data in user-defined complex data structures (incl. ones like graphs with cycles) burned into the program at compile time

• memoization / dynamic programming caches to accelerate costly computations of otherwise-pure functions, esp. for computations done to instances of data structures but where the memoization only helps if done globally across all data structures

• ADTs that are actually implemented in terms of multiple different underlying data structures depending on the properties of the data itself; where, upon mutation of the data, the implementation — and thus the representation of the data — can be swapped out transparently (think: lists in CPython; or Integers vs BigIntegers in Ruby; or most data structures in Redis with their "ziplist" variants)

...and so forth; then often the language will start actively fighting you, as the language has been designed to do everything at runtime; and especially has no consideration for mixing compile-time, runtime-memoized, and runtime-pure sourced data using the same set of algorithms. So you have to write two or three different implementations of the same code, and store your static data in special ways, and mess up your ADTs with indirections, and your data structure constructors with heuristics, and define global caches where much of your data actually lives, turning your concrete modules inside out and making it very hard to reason about them... and so on.

This all gets fixed if you define a DSL. You're basically turning all of the above operationalized logic, into just an opaque "platform" runtime. But you still do have to maintain that "platform."

But some programming languages are already essentially such an operationalized "platform" runtime! Though, such languages are almost always only operationalized for specific use-cases. They're not quite domain-specific languages (insofar as a domain is a vertical); but they are always extremely "opinionated" languages.

Dread Lord Phlux, HellFire Guild - Napa Shard. (and others) have tons of stories)

-

Would be interesting to grab the openGIS point maps of that section of colorado and make that the mesh - since your doing Stellarium for the sky.

There is also that guy that made the tool to grab the 3D tiles from google earth for converting to meshes...

As I said, don’t mind here and there… it’s helpful. But nag me and get replaced.

I could also google “stellarium project images” but I think my point is that I would expect projects to be as explicit as possible about “this is what we make.”