Whenever a post from one group (such as the article) comes out, a post from the other (such as OP) will quickly appear. And everyone loves it :)
For what it's worth, I think that both perspectives are valid. It depends only on your goals.
I've noticed that people who can do this are disproportionately better at achieving their goals than those who can't, especially in engineering organizations. Exceptions of course for zealots and revolutionaries.
This usually only happens when one begins to make personal insults, i.e. "only a poor programmer would think that!"..
I'm not sure if persons with the skill are more disposed towards studying philosophy or the study of philosophy prompts the development and demonstration of that skill more, but hang out with the philosophy kids and you might come to refine this skill by social osmosis.
Yet it would not exist without the second group because it was started by an investment fund/startup incubator.
I agree with you, I love both perspectives and the passions they ignite. I am squarely in the first group, and I love reading about the real life realities of product design/management, pitching, etc.
People rarely switch from one to the other. It's part of our core ideals.
However, there is a large, vocal, percentage from both these groups that will always voice their opinion against an opposition opinion. It's not a competition and there's no correct answer. It's purely subjective.
Or else.
War begins!
A writer can have lots of poetry, personal expository essays, journals, unfinished drafts lying around OR s/he can "ship" a best-selling novel, publish a high-traffic blog or something.
Similarly, a painter would experiment with lots of techniques, colors, textures "on the side," again having lots of personal work lying around, yet would probably treat something s/he would put in an exhibition differently.
In the first case, you are experimenting, discovering, breathing; while in the second case you have to think hard about your audience, your readers, or your customers.
It's built-in.
There are also writers who can do all of these: my personal favourite is Robert Graves (possibly because once many years ago I got him to autograph his Selected Poems and his memoir Goodbye to all That).
I'm somewhere in the middle.
> HN is made up of two groups in ever constant warfare, the yin and yang, as it were-
> the group who thinks that programming should be fun, experimental and enjoyable, and
> the group that thinks that programming is a means to the end of getting a product to market and nothing more.
> For what it's worth, I think that both perspectives are valid. It depends only on your goals.
Because it was a hobby project, I went completely mad on it. I built my own SPDIF interface, from scratch, using an FPGA. I let the hardware broadcast the sound frames over Ethernet. I also re-implemented Sony's proprietary consumer electronics control protocol, in hardware as well (a microcontroller could have easily done that instead). I greatly overengineered a circuit board, despite having a functional "test setup" already that did the job more than well enough. I wrote largely unnecessary client software, using language extensions I've never used before.
The task at hand could have been solved with buying a cheap USB sound adapter from eBay and some manual work instead. Had I gone down that route, I probably would have completed the task in a fraction of the time that building this project took.
But I had so much fun along the way and learned so much about electronics, FPGAs, SoCs, static typing for python etc., all because it was a project for me and nobody else.
One big lesson I've learned, though, is that having an actual task you want to solve greatly helps you in finishing your project. I ran out of steam a number of times and the project fell to the wayside, but because the underlying task was not fulfilled yet, I always went back to it and quickly got completely focused on it again. Projects that I only did for playing around and learning most often got abandoned.
#1. One that I am very clear about how to implement. One that I want build, ship and grab users as fast as I can. The real goal of the project is to get it out their in the market and make a tiny dent in the universe ;)
#2. One that I am not very clear about what it's gonna become. This one I want to take it slow. Experiment. Play with tech that I haven't had a chance to flirt with. The goal is to enhance my toolbelt and learn new concepts/tech.
Clearly keeping these projects separate helps me keep things clear. I quickly take decisions and move fast with one. I play and experiment a lot, no matter what the outcome is, with the other one.
Turns out I was wrong in some earlier maths, and the curve I wanted to find the distance to wasn't an ellipse. I was able to generalise the method for arbitrary curves, and now I've solved my problem!
Relevant blog post: http://wet-robots.ghost.io/simple-method-for-distance-to-ell...
OT: I had the problem as part of my 1st day job in 1990 on Parasolid.
IIRC, there was more than one way of converting the problem into solving a quartic polynomial, which is solvable by radicals and so doesn't need Newton's method.
If the point is inside the evolute of the ellipse then the quartic has four real solutions, which gives two local minima and two local maxima of distance.
If the point is outside or on the evolute of the ellipse then the quartic has two real solutions, which gives one local minima and one local maxima of distance.
Having said that, all methods using quartic polynomials could be unstable if the ellipse was pathological, for example very long and thin. Maybe that would be a time to revert to Newton's method.
I try to avoid using quadratic solutions in code because of numeric instability issues. Granted I never implemented the direct solution, but the number of opportunities for catastrophic cancellation gave me shivers.
One approach is to use the rational quadratic parametrization of the ellipse and substitute that into the squared distance function to get a quartic.
>I try to avoid using quadratic solutions in code because of numeric instability issues.
Sensible!
Back then the quartic solver had been written already and extensively tested by someone else - probably for line X torus intersection.
Even so there were numerical problems introduced because the quartic was in power basis and so the coefficients didn't have geometric meaning. I guess phenomena like Wilkinson's polynomial could occur. [0]
If I was doing it today, I would probably proceed as follows:
1. special case for the point exactly on an axis.
2. otherwise, choose the quadrant containing the point and represent that as a rational quadratic Bezier curve. This parametrizes the quadrant from 0 to 1 and is guaranteed to contain the global minimum.
3. substitute the quadratic Bezier curve into the square distance function to get a Bernstein basis quartic polynomial.
4. differentiate to get a Bernstein basic cubic.
5. solve the roots of the cubic numerically in the range 0 to 1: either Newton's or clipping or some other hybrid numerical method. A good reference is [1].
[0] https://en.wikipedia.org/wiki/Wilkinson%27s_polynomial
[1] Shape Interrogation for Computer Aided Design and Manufacture by Nichola M. Patrikalakis and Takashi Maekawa
How the heck did "" get in there?
> 5. solve the roots of the cubic numerically in the range 0 to 1: either Newton's or clipping or some other hybrid numerical method.
Is there a reason not to use the cubic formula in this situation?
Something like
(E(t)-P).(E(t)-P)
>Is there a reason not to use the cubic formula in this situation?
Numerical stability in edge cases, which will occur for code exercised as extensively as Parasolid's.
I guess you could a Bernstein version of the cubic formula, though I've not seen one derived in the wild. It would be nice to have as well as Bernstein quartic formula. The Bernstein quadratic is easy.
The objectives for a side project are subjective, and so they should be. However I doubt most people truly have no intention to ever ship a side project or "don't care if nobody uses it", as admirable as that would be.
I look back at my naive, recently graduated self and remember how I truly wanted to ship my side projects but loved to play around with new toys so much that I rarely shipped anything. I wish I had read a few more articles like this that would have helped me strike a balance between trying new things but still having enough experience in the stack I'm using to actually ship.
In short, if you have a great idea you want to ship then deprioritise learning to stand the best chance of getting it out there!
I have no doubt that this effects the side projects developers choose, or how they present them. Places like HN will always to a certain extent push people to "launch" and monetize their projects.
Now, if you personal project is intended as a gateway to your bootstrapping of commercial venture you _must_ make completely different choices in what/how you build (lean, and minimum useful/viable project) tec.
The main reason I've wanted other people to use the things I've made is to learn more about what I've built and how it could be better.
But some projects are more innovative or productive than others. Maybe you should abstract those projects away from eachother? You could put them in seperate classes. You could have the productive project use the innovative project.
For my side projects, I actually want to go down rabbit holes. I will try the same thing 7 different ways and benchmark the hell out of them. I'll read all the documentation and every blog post I can find. Learn a new language just to see if its features make things ever so slightly easier. Learn a new framework, write a new framework, throw it away and write a new one.
The point isn't to ship code, it's to learn. Honestly I don't care if it ever ships. And even when I do release one, I don't care if nobody uses it except me.