What is the future of CadQuery? OCE or FreeCAD? JavaScript or Python or Haxe?
384 views
Skip to first unread message
thebluedirt
Feb 13, 2016, 11:57:50 AM2/13/16
to CadQuery
Hello, everyone:
After finishing a long running project, now I have some time to begin work on cadquery again. It is important to establish the roadmap for CQ, so that any contributors we can attract know the direction we want to go.
I will call the future version CQ2.0, since I know already it will be a major re-write.
There are two main decisions:
(1) What kernel will CQ be based on? The reasonable choices are OCE and FreeCAD.
(2) What language should CQ use? The candidates are python and javascript, or using Haxe to get both.
I'm quite worried about the resource implications of doing both of these. It may be possible to create a language specification, so that it if both versions evolve, they can share very similar approaches and code.
Another option might be to use http://haxe.org, that cross-compiles to both python and javascript.
This _could_ work, but i think it has a high probability of making both the Javascipt and the Python version suck. I've never used it so i have no idea. A CQ + Haxe + OCE combo might be cool, but its the ONE language that i'm pretty sure NOBODY reading this already knows. So that's kind of annoying.
I'm going to tentatively propose a two week conversation period for this discussion ( 2/27/16). At the end of that time, I'll just make a call if I have to, because at some point any decision is better than no decision.
Thanks for your thoughts!
After finishing a long running project, now I have some time to begin work on cadquery again. It is important to establish the roadmap for CQ, so that any contributors we can attract know the direction we want to go.
I will call the future version CQ2.0, since I know already it will be a major re-write.
There are two main decisions:
(1) What kernel will CQ be based on? The reasonable choices are OCE and FreeCAD.
VerbNurbs, unfortunately, doesnt appear to be a viable candidate. We have been waiting for a while to see if verbnurbs could become a viable kernel, but after a year that has not materialized. It still lacks the features we would need for current CQ functionality, and our development capacity is not enough to pull verbnurbs along.
We have been running into issues withe FreeCAD. Using FreeCAD as a basis was a good way to get started quickly. We get higher level, more useful functions, an already packaged installer for most platforms, and a nice GUI for free. But we also get a bunch of limitations with that as well. If we move to OCE, we will have a lot more flexibility, but we will have a lot more work to do as well.
We have been running into issues withe FreeCAD. Using FreeCAD as a basis was a good way to get started quickly. We get higher level, more useful functions, an already packaged installer for most platforms, and a nice GUI for free. But we also get a bunch of limitations with that as well. If we move to OCE, we will have a lot more flexibility, but we will have a lot more work to do as well.
(2) What language should CQ use? The candidates are python and javascript, or using Haxe to get both.
Obviously, today we use python. pythonOCC provides bindings to OCE, and FreeCAD supports python already, so python was the natural choice. JavaScript has some advantages too. One nice one is that it is much easier to sandbox, another is that it is much more popular, with the rise of node.js. CQ's syntax is inspired by Javascript, in fact.
Previously, the amount of work to build JS->OCE bindings made this out of the question with our resources. However, now, there is a project that we could extend: https://github.com/erossignon/node-occ it is not very active, but we could get some help, and his project at least has a basis.
Moving to javascript for CQ 2.0, however, would come with some concerns too. For one, all existing code would obviously break. The consequence, i'm sure, is that we'd effectively support two versions: a JS one and a CQ one. The other issue is that python has some VERY powerful scientific packages for python that are super-fast, well tested, and popular to mash up with CQ. The most notable example is numpy. JS ( correct me if i'm wrong ) does not have a numpy equivalent. I think that's a pretty big deal.
Previously, the amount of work to build JS->OCE bindings made this out of the question with our resources. However, now, there is a project that we could extend: https://github.com/erossignon/node-occ it is not very active, but we could get some help, and his project at least has a basis.
Moving to javascript for CQ 2.0, however, would come with some concerns too. For one, all existing code would obviously break. The consequence, i'm sure, is that we'd effectively support two versions: a JS one and a CQ one. The other issue is that python has some VERY powerful scientific packages for python that are super-fast, well tested, and popular to mash up with CQ. The most notable example is numpy. JS ( correct me if i'm wrong ) does not have a numpy equivalent. I think that's a pretty big deal.
I'm quite worried about the resource implications of doing both of these. It may be possible to create a language specification, so that it if both versions evolve, they can share very similar approaches and code.
Another option might be to use http://haxe.org, that cross-compiles to both python and javascript.
This _could_ work, but i think it has a high probability of making both the Javascipt and the Python version suck. I've never used it so i have no idea. A CQ + Haxe + OCE combo might be cool, but its the ONE language that i'm pretty sure NOBODY reading this already knows. So that's kind of annoying.
I'm going to tentatively propose a two week conversation period for this discussion ( 2/27/16). At the end of that time, I'll just make a call if I have to, because at some point any decision is better than no decision.
Thanks for your thoughts!
Dave Cowden
Feb 13, 2016, 1:03:26 PM2/13/16
to CadQuery
As a small addition, it appears at least once, compiling OCE with emscripten has been attempted:
https://github.com/tpaviot/oce/issues/458
https://github.com/tpaviot/oce/issues/458
--
cadquery home: https://github.com/dcowden/cadquery
post issues at https://github.com/dcowden/cadquery/issues
run it at home at : https://github.com/jmwright/cadquery-freecad-module
see it in action at http://www.parametricparts.com
---
You received this message because you are subscribed to the Google Groups "CadQuery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cadquery+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cadquery/b4daa9a4-0b4a-4744-b54d-a50228470007%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Jeremy Wright
Feb 13, 2016, 10:31:00 PM2/13/16
to Dave Cowden, CadQuery
I personally am very tied to the scientific and engineering packages that Python makes available to CQ.
Jeremy
To view this discussion on the web visit https://groups.google.com/d/msgid/cadquery/CAD%2Br_DzQ6r8dZUpODcULZE2mAB%2By_7ym34ZMw1JU8a0gSAahAQ%40mail.gmail.com.
hyOzd
Feb 14, 2016, 5:06:07 AM2/14/16
to CadQuery
I don't like the idea of switching to javascript. I don't like javascript as a programming language. It lacks a proper standard library. It's simple and easy to learn but its syntax is ugly. It's a mess in my opinion. I've used javascript a couple times only, nothing serious. I hate how even for the simplest tasks, I have to do a google search and answer isn't an obvious one but a hacked together solution. As opposed to this, when developing python, I always know a solution to my problem, but I do a search nevertheless just to see if there is an even simpler solution. And most of the time there is one. Please don't switch to javascript.
Besides, is there a problem with python or something missing?
By the way I've heard about Haxe, but I haven't used it other than for a couple tutorials. I got interested in it because it was cross platform (supports even html5) and it's syntax is based on ActionScript (which is the first programming language I've learned). I can't comment on its language features but, in my opinion, it is really unpopular. I'm afraid adopting it, could keep developers away from cadquery.
Besides, is there a problem with python or something missing?
By the way I've heard about Haxe, but I haven't used it other than for a couple tutorials. I got interested in it because it was cross platform (supports even html5) and it's syntax is based on ActionScript (which is the first programming language I've learned). I can't comment on its language features but, in my opinion, it is really unpopular. I'm afraid adopting it, could keep developers away from cadquery.
thebluedirt
Feb 14, 2016, 11:20:05 AM2/14/16
to CadQuery
As another point of reference, I know it is sometimes frowned upon to use language indexes, but the latest TIOBE language index shows Python still very strong:
( behind my favorite language, Java-- which is my 'daily driver' language at my day job
but seriously yes I think Jeremy's comments about python are very valid: cadquery seems to have appeal in more scientific, mathematical, and other type environments, for which python is very friendly.
Dave Cowden
Feb 14, 2016, 11:23:00 AM2/14/16
to CadQuery
--
cadquery home: https://github.com/dcowden/cadquery
post issues at https://github.com/dcowden/cadquery/issues
run it at home at : https://github.com/jmwright/cadquery-freecad-module
see it in action at http://www.parametricparts.com
---
You received this message because you are subscribed to the Google Groups "CadQuery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cadquery+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cadquery/0a63497d-fa8b-4c71-bfbd-14c229838cce%40googlegroups.com.
thebluedirt
Feb 27, 2016, 8:51:02 PM2/27/16
to CadQuery
Ok, after a few comments, I am pleased to announce the following about CQ 2.0:
1. We will stick with python, and we'll move from FreeCAD to pythonOCC/OCE kernel
2. CQ 2.0 will be a complete re-write of CQ. it will be syntax-compatible ( at least mostly ), but underneath completely re-written, due to changing the backend
3. I have created a CQ 2.0 branch, and the readme describes the direciton.
Your thoughts are welcome. Over the next few weeks, I plan to refine the direction and add more details about the implementation.
Reply all
Reply to author
Forward
0 new messages