You get both sides (yes, you might limit some who would otherwise try it out).

I think requiring people to compile to try out such a still-fraught, alpha-level feature isn't too onerous. (And that's only from official sources; third parties can offer compiled versions to their hearts' content!)

1. Break down the steps. Can you find a recipe of steps for achieving the thing? Then start with the first step. Maybe that's a small enough task. Maybe you don't have to perform all steps in order, and you can find a small-enough step to do next.

2. Isolate the fundamental challenges. There is often a tough nut to crack within the problem. Can you isolate that from the rest of the project, and turn it into its own thing (I like to cast this as a "toy" problem)? When I say "isolate," I mean to remove all unnecessary complexity to getting at the fundamental issue. Suppose I want to figure out how to create a robust messaging network. There might be user interfaces and caching and different kinds of messages and different networks and different failure mechanisms and performance issues and ... So just create a "toy" at each step: First, simply send & receive a message. Don't worry about performance or worry much about robustness. You now have a small task but whose completion achieves a fundamentally necessary part of the larger task. Finishing that will feel good--you have something that works!--and you've made real progress. You might find examples of others doing something similar to this basic task as well, so you can work on your own but then compare notes to others to gain insights on why others have solved similar problems differently than how you solved it (you might have come to something better, or not; either way, you now have understanding of the fundamental problems involved). Now you can grow that toy or take what you learned from the toy and apply it to the larger task.

3. Similar to 2, but maybe a different POV: The physics joke is approximating a cow as a perfect sphere to study its dynamics. Simply the hell out of a problem! Maybe it feels ridiculously simple. Fine; now you are working with something completely tractable. You can then add in complexity to your model one wrinkle at a time.

4. Do something that's actually easy even if i might not be "significant" from the "big challenges to getting this project working" POV. Maybe you've been frustrated for a week or two trying to solve the tough-nut-to-crack bit of the problem. Even your toy problem remains (what feels hopelessly) broken! Switch over to creating the GUI or something superficial but that is easily tractable yet yields something satisfying to you when you finish. Simply stepping away from the hard problem for a day or two can re-motivate you when you come back to the hard problem. That time can also give your mind time to process solutions in the background (many people--myself included--have an "a ha!" moment when not thinking directly about a hard problem). And you are still being productive, moving towards the end goal. You had to make a GUI anyway at some point. Might as well be when you are stuck on the hard thing and feeling frustrated.

Getting good at breaking down problems took me many years. I credit my physics education as being particularly helpful (training thinking of problems & solutions in their extremes and always connecting solutions back to "does it make sense"). But much of the above is also learning my own psychology of how I work and what/when/how I am motivated to work and in the best position psychologically to solve a problem. I expect this isn't too different for many people, but the details can vary from person to person.

I work in a small business where we do hardware, software, help the marketing folks, and do a little IT work where needed. I want someone who is curious, energetic, and enjoys taking on whatever challenge presents itself. They'll start in a pretty well-defined role in a well-defined domain, and I'll give them support in that role. But they will have every opportunity to branch out from there, and I believe the kind of employee I seek—as well as the company—will benefit if the employee fits this technical culture. I want to scare off people who want to be pigeon-holed and fed repetitive tasks.

To that end, I also like to discuss with candidates projects they've worked on in the past, rather than offer up new challenges I present to them. Our normal work week doesn't involve isolated puzzles or single activities that one finishes in an hour. Finishing a project takes a long time & requires acquiring new knowledge, skills, and understanding, so I want to explore in depth something the candidate had a long time to work on where this process did (or did not) transpire.

My POV is that I want to find a postdoc (or someone who could grow into this paradigm), not a clever parrot.

Was an earlier headline or subtitle here on HN what was misleading, but then that was changed to not be misleading?

Half as many, of course, if you use a signed integer. If you don't need nanoseconds, then use microseconds and you get 292 thousand years to work with.

Integers are just a bit easier than floats for timestamps in my experience (e.g., comparing floats to one another is fraught and you'll be fighting this at every turn in your code).

You can read more about the language and its high-level features here: https://fortran-lang.org

That website/community was created in part by the original author of the Python Sympy library, Ondřej Čertík. He is also working on his own Fortran compiler that you can use via webassembly to play around with Fortran; find links if you want to play here: https://lfortran.org

I've only dabbled a little, but I like the general idea, and I appreciate a F/OSS Fortran compiler being developed like this alongside actively seeking to grow the Fortran community & push the language & its libraries forward.

I expect more widespread adoption of Fortran to be quite a ways out, but what Ondřej is doing for Fortran is necessary (not sufficient) for such adoption to be the case.

Someday I'll do a project in Julia. But for some such projects, Rust seems fully guaranteed to be performant while Julia might or might not be, so I might still lean towards Rust (unless one of the high quality packages of Julia removes a lot of development time, which is a decent possibility).

It would be like interacting with other people who knew based on the average of everyone on Earth as opposed to dealing with the person you knew based on their own personality.

But it's easy to manage based on these kinds of broad generalities and, as the saying at least once went, no one gets fired for choosing IBM.

People use a great tool in a poor way and then broadly condemn the tool.

And any tool that is sufficiently flexible to be broadly useful can be used in very poor ways.

Jupyter is great, it gets me over the barrier potential for starting a task every time. I build and prove out an algorithm/task piece by piece. Once I'm happy, I move the meat of it to a function in a .py file, and move the code I used to test the algorithm to a unit test function. Delete the duplicated bits and replace with imports, and then what remains is a tutorial/demonstrator notebook using the function I wrote and maybe some nice plots to go along with that, that I wouldn't put in a unit test (nor that show up in docstrings). This can be converted to sphinx docs if the code gets big enough.

What a great tool for incrementally building software! In my world, I build brick by brick, not all at once. Jupyter is a key to that process.

You're "waiting" for him to personally call you or something?

You don't have to re-implement protocols to commit FCC (or pick your local reg agency) no-no's. See e.g. discussion by this HAM radio operator on his blog (doing legal things, but you can easily do this for non-legal things):

https://yo3iiu.ro/blog/?p=1301

I don't think it's the same thing as calling names; it's an important distinction to me to criticize actions and not people, and that's what your parent did.

Many here are criticizing the actions of GitHub/MS. That's fair, but we can also criticize the act of criticizing just the same.

(Again, I might agree with you if bringing "respect" into it could be seen as having a similar effect as name-calling in the sense that it makes the discussion more personal than it needs to be.)

(Meanwhile, you solely mention the PR aspect of this act, as if there is no other benefit in the equation. There are two general entities that will benefit from this, although some here seem to prefer no benefit whatsoever befall GitHub/MS and even want to turn this into negative PR. Anyway, assuming it does turn out to be net-positive PR for GitHub/MS, then 900 devs as well as GitHub/MS will benefit from this act.)

A company gives to open source projects.

People complain about how little it is, and generate negative PR for the donation.

For a company, negative PR is a punishment.

What's the lesson here? At least the lesson some in the HN community are teaching is that if you are a big company and you donate to open source projects, you will generate negative PR for yourself.

(We can assume and/or question their motivations, but to me, motivations are almost always irrelevant to an act of generosity. Feel good about yourself if you help others out! Garner positive PR if you help others out as a company! Why should positive things for the giver detract from an act of generosity? Got a problem with the system? That's a problem with the system, not the person or company being generous.)

But because they put $500k toward those people whose projects they rely upon, there is now a discussion of what a pittance it is (whether or not you append "good job, hopefully you do more in the future" doesn't change the critical tone you set with all your other words you said before you said that).

The lesson: Almost no act of generosity goes without criticism on social media or discussion sites.

(Note: I hold a pragmatic view of generosity. I don't care what a person or company's motivations are for being generous. PR? Great! Let's show it makes for great PR to be generous! Selfishness, bolstering one's sense of grandeur? Great, feel whatever you want about yourself, as others benefited! Trying to out-compete a rival or friend by giving more than they? Great competition to be in! Did GitHub give to one person? Great! Did they give to 900 people? Great! Did they give each person $10? Great! Did they give each person $550? Great!)

Sometimes you have a Python project already, you aren't planning to write a new project. In fact there's a ton of non cython python in existence, every time I use a new library, your solution is to rewrite it in cython?

Lots of ways to speed up python. It's great to have this option, which will work for some without having to change much of anything. Cython, Numba, C (etc.) extensions, ... All are good, too, where they fit into a project and development cycle.

Good in-person collaboration, sometimes accidentally overhearing someone else, is invaluable. At the same time, people can get off task and chit chat becomes a hindrance.

Sometimes we all know our role and what has to be done, we just have to get it done. Sometimes we don't know how to solve a problem.

Some employees don't have a good work environment at home. A Ph.D. student with a young special-needs child felt horrible ignoring his daughter while working on his dissertation at home (where his wife was caring for his daughter), bit coming into campus was far better for him, productivity-wise and psychologically.

I think the balance might be a dynamic one, in that what's best can change over time and task and stage of a task and stage of a person's career. And by employee, and by task.

Being a good manager must be immensely difficult, but also being an employee also requires adapting and compromising between all of these trade-offs.

There are various applications. Some that you hear about most might be a little overblown (but still maybe not). For example, quantum simulation is an application within the physics field that already makes these systems worthwhile to pursue, without any mention of breaking encryption and the other things mentioned. Quantum logic, i.e. quantum computing on the smallest scale, has been employed to make cutting-edge atomic clocks (which are undeniably a worthwhile pursuit, with countless applications in the real world).

Putting "scaling up quantum computing, the pieces of which have already been demonstrated" in the same sentence as perpetual motion and free energy (known to be in violation of laws of physics) is completely unjustified.