targafarian
I do a lot of what I need symbolically in SymPy for dynamics analysis. Past that, I can't speak for it. At University I used Mathematica, but I just don't need all it can do at this point, so once again Python has proven to be "good enough." Matlab will be a similar story (e.g., I've never seen a good alternative to Simulink in Python).
But for everything else outside very specific domain tasks? Mathematica and Matlab are terrible for a lot of reasons. So I'll go out of my way to stay within the Python ecosystem, though I'm not afraid to pull out the specialty tools when I just can't make Python do the task near as well and/or nearly as quickly.
The moment you have to interact with the physical world or humans (psychological, imaginative, aesthetic, etc), there are often undiscovered or changing rules—or no rules at all. Or systems are subject to perturbations beyond a defined scope.
The other thing I believe is software developers are experts at doing the things that allow them to make doing those very things easier and more automated. And they do this in public, perfectly documented online.
Both because of the things I described above and because software developers have created the largest machine-accessible training set for plying their trade of any trade, ML—that is ultimately interpolating massive datasets to do things—is unsurprisingly uniquely successful for software tasks.
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):
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.
I am not a professional programmer, but I get a lot of work done very productively in Python (or at least I thought I was being productive; in light of how you speak to me, it sounds like I'm actually not being as productive as I thought I was, rather I'm in some world believing fake insinuations that what I'm doing is being productive...).
Are you writing an IO-bound task? Then asyncio[2] (even if just viewed as an interface: e.g., you can make it even more performant by using uvloop[3]) is a great way to achieve performant concurrency. As Raymond Hettinger likes to point out, even if you throw away the GIL, you will have to implement locks on shared resources (unless you're writing embarrassingly parallel codes--in which case either you can invoke them separately or use the multiprocessing module to great effect, or see how I do it easily below), and by the time you get all the locks implemented in your GIL-less world (locks which are error-prone), you've given up the performance you thought you'd get due to throwing away the GIL.
Are you writing a CPU-bound task? I've only encountered this in scientific computing, as I'm a scientist, and for this (as another commenter mentions) I either use numpy[4] (strictly within a numpy call, the GIL is not held) or numba[5] (by default the entirety of your numba-fied functions do not hold the GIL). Therefore, I can either use Python threads or asyncio or Numba's built-in parallelism[6,7] (summary: some numpy routines for working with arrays of values are auto-parallized if called within a numba-fied function, and you can explicitly parallelize your own loops via `for i in numba.prange(N):`; in any case, then decorate the function with `@numba.njit(parallel=True)`) to run these numerical routines in parallel. I easily get 100% of all my CPU's threads doing work this way.
I have parallelized numba-fied functions both via numba.prange and via python threads (yes, threads) in the past few weeks to speed up 20-60 minute-long-running codes, and even though I've done this before, I was still very pleasantly surprised at how easy it was, and I got very nearly a 16x speedup on my 16-thread laptop, which made my code practical for interactive data exploration and building up simulations to help me understand some things I was observing, which is where Python really shines for me.
Also note that writing a routine in numba provides a straightforward path to putting your numerical codes on GPU[8,9], too, if the that model makes sense for your algorithm (though I've primarily used PyCUDA for this, which worked well).
Are you writing something that needs to use distributed (e.g., cluster) based resources? Then dask (dask.distributed) is a great way to go, with a similar interface to the Python standard-library `futures`. Runs all the same code and you get the same forms of parallelism, but distributed across computers.
In any case, do you get to FORTRAN or C speeds? Probably not, but close enough, and with the benefits (and costs) of using Python code.
[1] talk by Raymond Hettinger: https://www.youtube.com/watch?v=9zinZmE3Ogk [2] asyncio: https://docs.python.org/3/library/asyncio.html [3] uvloop: https://github.com/MagicStack/uvloop [4] numpy: https://scipy-cookbook.readthedocs.io/items/ParallelProgramm... [5] numba: https://numba.pydata.org/ [6] parallelizing numba: overview blog post: https://www.anaconda.com/blog/parallel-python-with-numba-and... [7] parallelizing numba, docs: https://numba.pydata.org/numba-doc/dev/user/parallel.html [8] numba on gpu, example: https://github.com/numba/numba-examples/blob/master/examples... [9] numba on gpu, docs: http://numba.pydata.org/numba-doc/dev/cuda/index.html
In practice, I've only seen bad code drawn in LabVIEW; it was shocking for me to see a "good" code example once. But then fixing bad code (i.e., refactoring) is only pain and suffering compared to text-based languages.
> quite obvious visually
Agreed, you can see how confusing it is, but unfortunately that never stopped anyone from doing it that way in my experience.
The only saving grace of LabVIEW is that you can now interface via C/C++ and avoid G (their "graphical programming language") altogether.
mypy and types are only "hoops" in comparison to non-annotated Python (in terms of added syntax / coding effort), yet compared to explicitly typed languages where you have to declare types, that's just standard thing you have to do so there is no extra effort in comparison to these other languages (and then the judgment that it only works "half as well" is controversial (Edit: or at least needs qualification)).
But you can also use site:wikipedia.org syntax in DDG to search any particular website, just like in Google.
So don't criticize bangs for not being good at everything "site:" allows you to do, they're different tools; use the right tool for the job. DDG gives you many of the same tools that Google gives, but adds many other tools.
And DDG has shown willingness to add more tools; just find/remember the (small) subset of these that helps you out, and someone else can find/remember those tools that help them out, and you each have good user experiences.