In general I like to write code to define objects, but there are some situations where a graphical editing UI would be nice. ie- Curve and polygon design.
You can sort of imagine a hybrid approach where you could crack open a mini editor to design a curve and then use it to generate code (table of numbers) which you could then extrude/sweep/loft or whatever.
A hybrid approach where you could "sketch" with SolveSpace, but then generate OpenSCAD style code that you could later edit would be amazing.
The main advantage of OpenSCAD is that it doesn't "blow up" when you change a variable to be out of some range where things work. In OpenSCAD, you can put it back if it does cause a problem.
Changing a dimension in SolveSpace sometimes throws off the whole design. SolveSpace's precision, constraints, and great keyboard user interface make it a fun program to design parts in. It is among the best open source tools out there.
I started with OpenSCAD but:
a) found the language to be clunky
b) had a hard time doing chamfered unions between objects (needed for sand casting patterns).
So - I wrote my own tool/library in Go and it's essentially replaced my OpenSCAD usage.
SDF = signed distance function. A function mapping a 2d/3d coordinate onto a scalar. The scalar is the shortest distance from that point to the surface of the object. (+ve outside, -ve inside)
CSG = constructive solid geometry: Take primitive 3d shapes and do unions, differences, intersections on them to build more complex shapes.
Fairly obviously the union of 2 sdf functions is going to be the minimum of those values. That pretty simple.
Intersections and differences are not much more complex....
You sequence the motor, get a pick up from the light sensor and then turn it into a note trigger. It'd be simpler to sequence an array rather than a motor and generate a trigger based on array content.
But sure. Art. It's a piece of kinetic sculpture....
Right - they statically link which means that you typically don't have to worry about shared object dependencies when moving the binary around. You just have big binaries. If you use cgo (integration with C-code and C based libraries) then you are back to *.so versioning problems.
Premise: It's more important to be productive than to have fast code.
Conclusion: Use Python.
Is the premise true? For many cases- yes, but it depends. If you are running an application on the cloud and your metric is $/user/year and you have many users then saving some compute resources for each user gets attractive and you don't want to just throw another VM at it.
Is the conclusion true? Garbage collection gives big productivity gains. Other languages have GC. It's not nice to see your Python code die after a few days because you messed up the type passed to a function. Other languages fix that at compile time. Multicore is now. Other languages are built with better multicore awareness.
As an engineer hiring engineers, if a candidate gives me a guthub url then I'm going to take a look. There are too many people coming through the door who are marginal coders, so if I can get a sense of what they do for something other than a white board problem then that's a good thing.
>Even something seemingly simple such as saying "is point C to the left or right of the line A->B" is very hard in floating point.
Is it? ie - construct a normal and take a dot product. That'll work the vast majority of the time. Near the line you'll start running into the FP precision limits. With 64 (...or even 32) bit floats that sort of distance is likely way smaller than anything that represents a practical distance, so just call it and say you are on the line. Of late I've been messing about with problems of this nature and I can't say it's been all that difficult. https://github.com/deadsy/sdfx
It comes back to bite you in a hurry. You don't need arbitrary precision to represent arbitrarily small things but to not have algorithms break down. Simple things like "is p inside the polygon" changes from true to false by moving both point and polygon 1 unit to the right. See under the heading "geometric predicates can FAIL" here http://groups.csail.mit.edu/graphics/classes/6.838/S98/meeti...
You are right that this happens only in edge cases. But you don't want that in a cad program if you have anything doing e.g point-in-polygon, triangulation or other such algorithms.
I know from experience that you really should bake this into the very foundation of a cad package (if you see 2003 me, let him know)
There are other tooth forms that also satisfy the fundamental law of gearing (constant ratio of angular velocity). E.g. cycloid gearing used typically in mechanical clocks. The involute is popular because its easy to manufacture. It can be auto-generated on a gear hobbing machine- probably less important now with CNC machines, but very important in a pre-digital machine era. The involute is also less sensitive to gear center to center spacing.
When I was in Stuttgart I made a point of visiting the one they have in the Rathaus. It's an interesting mechanical design, but definitely assumes some personal responsibility on the part of the user. Keep your hands to yourself as you go around the top and bottom...
https://github.com/deadsy/sdfx
In general I like to write code to define objects, but there are some situations where a graphical editing UI would be nice. ie- Curve and polygon design.
You can sort of imagine a hybrid approach where you could crack open a mini editor to design a curve and then use it to generate code (table of numbers) which you could then extrude/sweep/loft or whatever.