Talk:OpenSCAD

more references

I (and apparently others as well) think this article needs more references.

A recent edit added 3 sentences about OpenSCAD, sentences that I thought were supported by one source reference per sentence, each to a different printed paper book.

That entire edit, source references and all, was reverted.[1]

I understand that there are certain standards of what can be used as a WP: reliable WP: source in a Wikipedia article.

Was there something about those 3 references that made them not qualify as reliable sources? --DavidCary (talk) 17:04, 24 October 2013 (UTC)

Many articles -- for example, platypus -- make some pretty odd statements and dubious claims. My understanding is that such text is welcome on Wikipedia if it is verifiable (WP: Verifiability). So when I see someone delete a statement with the comment "dubious claims" or "an odd statement", but that statement appears to be supported by a reliable source, I think it is appropriate to revert that deletion.

My understanding is that, after such a revert, the next step in the WP:BRD process is a discussion on this talk page.

Am I missing something that may be clearly WP: OBVIOUS to you? --DavidCary (talk) 05:03, 5 March 2014 (UTC)

What you're missing is a WP:CONSENSUS to include the material in the article. You should not just reinsert your material.

Here's the text you just reinserted:

The ".scad" scripts behave like open source software: compared to most other CAD file formats, it is much easier to distribute CAD drawings, allow people to independently make different incremental improvements, and then merge (revision control) all the improved CAD drawings together such that the combined CAD drawing that includes all the improvements.

I have problems with these claims. The proceedings of a symposium is probably a primary rather than a secondary source. Primary sources report information from a more involved position and lack a larger perspective. I don't like the comment that scripts behave like open-source software claim. All scripts/programs can behave that way; they can also be closed-source. Sharing is not unique to programming languages. People can share CAD drawings (and can put them into content neutral formats such as IGES). Lots of people making incremental improvements is a wouldn't-it-be-nice-if claim, but it ignores the problem of merging lots of changes. What if everything isn't an "improvement"? What if two improvements conflict? How is that sorted out? More particularly, does having lots of people make small changes make a lot of sense? People can share CAD drawings and make improvements to them. There may not be the ASCII-text based availability of software revision control, but the community can make improvements. Where's a secondary source that evaluates the two approaches and rates the merits? What we have now is the claim that something is a good idea. Glrx (talk) 01:53, 6 March 2014 (UTC)

Glrx (talk) 01:53, 6 March 2014 (UTC)

I'm a little confused here. I agree with Glrx that merging is impossible when two improvements conflict. I also agree that, when two different people, using normal programming languages, independently make small improvements to the source text of some piece of software, ASCII-text based software revision control makes merging relatively easy. I also agree that this is not unique to programming languages.

I also agree that secondary sources are better than primary sources, and it would be nice to have a secondary source that evaluates the two approaches and rates the merits, but my understanding of the WP:PRIMARY policy is that primary sources are also acceptable.

I also agree that the proceedings of a symposium are often a primary source, although I don't see how that is relevant. (Is that maybe an allusion to the WP:PRIMARY policy, or maybe the Wikipedia: Independent sources essay?)

I feel that if one reliable source makes some claim that ignores some problem, the WP:YESPOV policy implies that it is better to add text to the Wikipedia article to address that problem, rather than delete the claim and the reference backing it.

Glrx points out some of the difficulties in merging two drawings in OpenSCAD format. As far as I can tell, those difficulties are the same difficulties that occur when merging two independently-edited source code files written in pretty much any other programming language. They are sorted out in exactly the same way they are sorted out in any other programming language. While I think Wikipedia should have detailed answers to those questions, I think the merge (revision control) article is a better place for those answers than this talk page.

I feel that a well-written encyclopedia article about any particular CAD system should mention things that make it unusual, different from most other CAD systems. Even if millions of other non-CAD systems have those "unusual" characteristics. And also say a few words about the implications of those differences, even though they may be WP:OBVIOUS to any programmer.

My understanding is that this approach of writing a description of a shape in a text editor using a programming language with variables, functions, "include" statements, etc. -- rather than drawing a shape more-or-less directly on the screen -- is one of the biggest differences between OpenSCAD and most other CAD systems. I feel the implications for merging are pretty WP:OBVIOUS to me and anyone else who has used ASCII-text based software revision control. --DavidCary (talk) 08:21, 18 March 2014 (UTC)

The statement is in WP's voice and claims that SCAD is better than most other CAD formats.

We don't have a secondary source telling us the claimed features are significant. We have a biased journal article claiming it is a great idea.

Generally, it's a bad idea to have several people changing the same part at the same time. CAD drawing control can be done with check in/check out. The claim seems to address a non-problem.

Glrx (talk) 22:05, 26 March 2014 (UTC)

Aha, I think I see how I messed up.

You spotted me writing "... compared to most other CAD file formats, it is much easier to distribute CAD drawings ...", which you are convinced is wrong, yes?

Yes, it's not any easier to distribute ".scad" files than files in any other format.

Sorry. I don't know what I was thinking when I wrote that.

I hope you agree with me that given any two significantly different CAD systems, or given "the same" part stored in two significantly different file formats, there are almost always some one task that is much easier in one of them, and almost always some other task that is much easier in the other.

I agree that several people changing the same part at the same time -- when merging those changes afterward is difficult or impossible -- is a bad idea.

I agree that "check in/check out" is one way to do CAD drawing control that avoids that problem.

You may be surprised to hear what Ben Collins-Sussman says about about "check in/check out" (which he calls the "lock-modify-unlock model") in the "Versioning Models" section of the "Version Control with Subversion" manual (p. 2-7). Also, what Joel Spolsky says about "the most common case".

I hope you agree with me that both Ben Collins-Sussman and Joel Spolsky seem to be saying that when two people simultaneously change their own local copy of a guacamole recipe, merging those changes afterward is usually easy.

And so Ben Collins-Sussman and Joel Spolsky seem to be saying that two people changing the same guacamole recipe at the same time -- since merging those changes afterward is easy -- is not such a bad idea.

OpenSCAD makes some things much more difficult than other CAD systems, but one advantage -- what some call "The key advantage"[2] of OpenSCAD -- is merging.[3][4][5][6][7][8]

I hope you agree with me that those people seem to be saying that "SCAD is better than most other CAD formats" for one particular task -- merging -- and worse than most other CAD formats for certain other tasks.

--DavidCary (talk) 00:37, 5 April 2014 (UTC)

"variables"

When a named label for some data is immutable, calling it a "variable" is just an idiocy.. variables vary.. constants are constant.. 98.128.228.64 (talk) 07:16, 3 March 2024 (UTC)