Topic: DesignScript - A new programming language and environment for AutoCAD

[Jeff H]

God help us
Link
 

[MP]

wow, I think my uterus just quivered

[gile]

Some more here and the first feedbacks there.

From the first tests I did, it looks interesting for some tasks but quite limited to geometry similations and analysis.
The language is nice (very high level) and the syntax looks like a mix of C#, F# and Python but it is not, IMO, so easy for non programers.

[Jeff H]

Looks like written .NET
Once downloaded and run the msi
go to
C:\ProgramData\Autodesk\ApplicationPlugins\DesignScript.bundle\Contents\Win64
and start opening them in Reflector or ILSpy.
 
Looks like only supported on 64bit

[gile]

A simple exemple, 10 lines of code to generate a surface in AutoCAD:

Code: [Select]

import("ProtoGeometry.dll");
import("Math.dll");

numPts = 97;
numWave = 24;
height = 0.05;

x = Math.Cos(0 .. 360 .. #numPts);
y = Math.Sin(0 .. 360 .. #numPts);
z = Math.Sin(0 .. 360 * numWave .. #numPts) * height;

spl = BSplineCurve.ByPoints(Point.ByCoordinates(x, y, z));

surf = Surface.CreateFromCurve(spl);


Now, playing with the numWaves and height parameters to generate different surfaces.
With numWaves = 4 and height = 1

[TheMaster]

God help us
Link

Have you read my recent comment there?

Anyway, back to the question: why did Autodesk choose to reinvent the wheel by creating another programming language? This question was clearly asked a lot when we first started developing it, but the ultimate answer is that it’s unlike anything we have today – in AutoCAD or even elsewhere, I suspect.

The primary reason it’s so different is its associative nature.

I gotta say, I'm not impressed by what amounts to a very badly-done hype-job that Kean seems to be doing with his talk about DesignScript, based on a patently-false claim that this new scripting language is, in some way, distinct and unlike anything that currently existed before it (e.g.,  it is 'associative').  LMAO  Apparently, Mr. Walmsley hasn't had much experience with the use of formulas in the computational definition of numerical models in Excel worksheets.

One might call that ridiculous claim of originality regarding "associativity" an insult to the computer science community collectively, and in partular, to people like the late John McCarthy, Alonzo Church, Alan Turing, John Von Neumann, et,al., as well as the designers of almost every programming and scripting language in existence today, having roots in the work done by those distinguished individuals. But we can't say that, because Kean doesn't posses anywhere near the technical qualifications needed to insult people like that.

It's not uncommon to see misguided neophytes invent new terms to describe things that have existed for ages, and then in a somewhat sleazy fashion, mis-use them as a pretext in some sort of claim of originality - that they've invented (or 're-invented' perhaps?) something that already exists. That's precisely what's going on here, in case you didn't know.

I posted a simple snippet of LISP to make that very point, which is that every programming and scripting language known to man, starting with the formulas entered into VisiCalc, Lotus123 and Excel spreadsheet cells, up to and including every major programming language in widespread use today, is no less 'associative' than DesignScript is.

This opportunistic hyping with false claims of originality seem to be mostly rooted in a misunderstanding of some very simple concepts, like the one that underlies the implementation of properties in .NET/CLR (e.g., syntactic sugar that serves as a facade for what are in reality, functions or methods), and the simple fact that DesignScript 'variables' are really not variables at all, or at least not according to the conventional definition.

DesignScript 'variables' are in-reality, functions dressed up to look like variables (but still act like functions nonetheless), and those functions are what have been mislabeled as 'associative variables'. As I'm sure most understand, variables are traditionally thought of as memory storage locations that hold static values. That is not the case with DesignScript's variables.

To debunk the mythical claim about 'associativity', you can think of it this way: Given the DesignScript source:

Code - C#: [Select]

1.  
2. x = 0
3. y = x + 1
4.  
5.  

What is actually happening is that the compiler is defining a function rather than assigning a static value to a storage location. DesignScript takes what you write on the right side of the assignment operator (=), and defines a function whose body contains that expression. And, when the 'variable' is referenced within another expression, the result of calling that function is returned. Whether the result of the function is cached in cases where there can be no side effects that would change the value, is an implementation detail that is not even worth mentioning, but this is basically what's going on in this new, breakthrough scripting language that sends tremors down the very pillars of computer science.

And, to provide equivalence to other languages:

Code - C#: [Select]

1. public static class Variables
2. {
3.      public static int x = 0;
4.      public static int y  {get{ return x + 1;}}
5. }
6.  

The fact that Kean has taken what amounts to DesignScript's use of syntactic sugar, to make user-defined functions look and act like program 'variables', in both how the functions are defined and called, and has somehow confused that with what he has coined ('associativity'), or the false claim that DesignScript is the first and to-date only programming language that exhibits that characteristic 'associativity', is something that might get him a few laughs in computer science departments, but is otherwise little more than a very badly-done hype-job, that insults the reader's intelligence.

I find the hype job being done by Autodesk on this new technology as being far more offensive than anything written above.  And by the way, this is not a slam of DesignScript, which I'm sure is in its own right, and without the unnecessary, opportunistic co-opting and hype, a well-designed and useful tool.

[Jeff H]

Have you read my recent comment there?

Looks like they have been removed or i am not seeing any.

[TheMaster]

Have you read my recent comment there?

Looks like they have been removed or i am not seeing any.

http://through-the-interface.typepad.com/through_the_interface/2012/10/yasl.html#comments

[Kean]

Wow, Tony. I've clearly done something to upset you: sorry that you've taken whatever it is so badly.

Re-reading my post, I don't see anything that particular "hypes" (or over-hypes) the technology... I merely pointed out some of the rationale behind it - discussions that I happen to have been involved in way back before it became a properly resourced project - that I thought would be of interest to my blog's readers. If you look at the bottom of the post, I even provide this disclaimer:

"A final note… many of these comments and observations are based on my somewhat stale knowledge of what’s been happening with DesignScript, so please don’t assume what I’ve said here is 100% accurate."

Now I'll certainly be happy if people take a look at DesignScript and do interesting things with it, but other than that I don't work for our marketing organisation or even the team that created DesignScript. Of course I'm an Autodesk employee, but that doesn't mean I talk about Autodesk technology because I want the value of the few shares that I own in the company to increase. My prime motivation for blogging is to share what I know about technology (Autodesk or otherwise) and hopefully help people to solve real problems and inspire them to do interesting things.

Back on the topic of me "hyping" the technology... I expect DesignScript to be popular among the top architectural practices - relatively few of whom I suspect subscribe to my blog - but it remains to be seen what kind of reception it'll find elsewhere. I can see a number of areas it'd prove useful, but I don't want people to come away with the impression that this is "the next big thing" with respect to AutoCAD programming. AutoCAD happens to be the host organism best suited to DesignScript, for now, but it's more about getting the language in the hands of those who need it to solve their real-world design challenges: not about converting AutoCAD developers en masse to start using it (which would be inappropriate, IMO).

Kean

P.S. Tony's comments are all there on my blog: I only remove spam or comments that are genuinely offensive (thank you for not having crossed that line over there yet, Tony).

[Jeff H]

Just a suggestion, but I think Autodesk would get a better response if they hired Flavor Flav to do their new technology releases.
 
 
For you extremely white people Flavor Flav

[TheMaster]

Wow, Tony. I've clearly done something to upset you: sorry that you've taken whatever it is so badly.

Re-reading my post, I don't see anything that particular "hypes" (or over-hypes) the technology... I merely pointed out some of the rationale behind it - discussions that I happen to have been involved in way back before it became a properly resourced project - that I thought would be of interest to my blog's readers. If you look at the bottom of the post, I even provide this disclaimer:

"A final note… many of these comments and observations are based on my somewhat stale knowledge of what’s been happening with DesignScript, so please don’t assume what I’ve said here is 100% accurate."

Now I'll certainly be happy if people take a look at DesignScript and do interesting things with it, but other than that I don't work for our marketing organisation or even the team that created DesignScript. Of course I'm an Autodesk employee, but that doesn't mean I talk about Autodesk technology because I want the value of the few shares that I own in the company to increase. My prime motivation for blogging is to share what I know about technology (Autodesk or otherwise) and hopefully help people to solve real problems and inspire them to do interesting things.

Back on the topic of me "hyping" the technology... I expect DesignScript to be popular among the top architectural practices - relatively few of whom I suspect subscribe to my blog - but it remains to be seen what kind of reception it'll find elsewhere. I can see a number of areas it'd prove useful, but I don't want people to come away with the impression that this is "the next big thing" with respect to AutoCAD programming. AutoCAD happens to be the host organism best suited to DesignScript, for now, but it's more about getting the language in the hands of those who need it to solve their real-world design challenges: not about converting AutoCAD developers en masse to start using it (which would be inappropriate, IMO).

Kean

P.S. Tony's comments are all there on my blog: I only remove spam or comments that are genuinely offensive (thank you for not having crossed that line over there yet, Tony).

Hi Kean.  Yes, I think anyone that has invested significant time in the study and practice of API and language design would be offended by the suggestion that someone has invented something new, that was previously non-existent, when the fact is that what they've claimed to have 'invented' not only existed previously, but is so ubiquitous that it is taken for granted by most - it reminds me of Al Gore's invention (the internet).

Let me just make this as plain and simple as I can:. You showed a simple example of a DesignScript program that was supposed to demonstrate how that scripting language differed from all of the other languages currently in use for scripting  AutoCAD, in that DesignScript was 'associative'. In doing that, you directly implied that the other languages were not 'associative'.

That assertion is simply not true.

[Kean]

The post clearly states "The primary reason it’s so different is its associative nature."

Just like any innovation (let's not call it an invention - I hadn't used that term myself) there is often more than one factor that makes it of interest. I didn't say there haven't ever been associative languages - I've even programmed in one or two of them - but this is one very important differentiating factor (and I'll stand by that fact).

I used a simple piece of code to introduce the idea to people who may not be aware of the term, but the innovation around DesignScript's associativity starts to come into play when you use it to tie geometry together. More on that in future posts.

Kean

[dgorsman]

Interesting concept.  I dont' see an immediate need for it, but that doesn't mean it will never have *no* use somewhere.  Some of the more interesting ideas out there evolved from "... hey, lets try to do ___", even if the original concept had no practical application.  Gotta start somewhere.

[TheMaster]

The post clearly states "The primary reason it’s so different is its associative nature."

..... In comparison to the non-associative nature of the other languages?

Please....

Your example compared design script 'variables' to variables in other
programming languages, and that's an illegitimate comparison to start
with, because DesignScript variables are not 'variables' at all, as they
are defined in other programming languages.

You are taking what amounts to syntactical smoke-and-mirrors that
allows functions that take no parameters to masquerade as variables
in DesignScript, and rather than compare them to functions in other
languages, you erroneously compare them to static variables in
other languages, and that's the problem I have with your comparison
and example.

If you think about it, C# properties are functionally equivalent to what you
call 'variables' in DesignScript (which are most certainly not variables in the
traditional sense -  because code must execute to produce a value, whenever
the 'variable' is referenced, which is the functional definition of a function).

A distinctive syntax that changes how functions that take no parameters are
both defined and called, in and of itself does not qualify as innovative in my
opinion.

As for what DesignScript does with the expression graph it builds and uses to
do things (like check for cyclical references that would otherwise lead to a stack
overflow), that is not exactly new either. That's how most spreadsheet programs
like Excel have worked for decades - they model the expressions entered into cell
formulas as a graph and use that to evaluate cell values when a recalc is done, as
well as to detect cyclical references.

In case anyone isn't sure what we mean by cyclical reference, this is an
example:

Code - Text: [Select]

1.    a = b + 1
2.    b = a + 2
3.  

The above is an error because 'a' is dependent on 'b'
and 'b' is dependent on 'a'.

[Kean]

Tony,

a) I'm not an official spokesperson for (or even member of) the DesignScript team.
b) I said in my post there was room for inaccuracies.
c) We can waste time arguing over semantics, but I really have better things to do (as I'm sure you do).
d) If DesignScript does something useful for you, then great. If it doesn't, the same.

Kean