[Question]
  [
You task for today: draw a dragon curve!
In case you don't know what a Dragon Curve is, [here](https://youtu.be/EdyociU35u8) is an introductory ViHart video (Really cool, please watch!)
Your task: draw a dragon curve, iterated at least 9 times. You don't have to show iterations 1 through 9, you just have to show the final curve produced after completing (at least) 9 iterations. The curve must be drawn as straight lines connecting the points on the curve; the output should match one of the images below that shows 9 or more iterations (up to reflection, rotation, scaling, and variation in line width, line color, and background color). Your output must be large enough that the individual lines and the "boxes" that they form can be distinguished from each other; if two lines don't intersect in the curve, they shouldn't occupy the same or adjacent pixels in the output (there should be at least one pixel of the background visible between them). You can either display the image to the screen or saved the image to a file is accepted. The output must be graphical - it can't be ASCII art.
The shortest code in bytes wins, *however* include directives for libraries shouldn't be included in the byte count, and you may use graphics libraries or other libraries written for your language of choice if they were written before the posting.
Please include an image of the output of your program.
[![enter image description here](https://i.stack.imgur.com/0W85S.png)](https://i.stack.imgur.com/0W85S.png)
**Skip this paragraph if you watched the video:** For those of you who decided not to watch the video, the first 12 iterations of the dragon curve are shown below. For the purposes of this task, a dragon curve is a curve generated by the following rule: take the end-point of the current curve, create a second curve rotated 90 degrees around that end-point so that the end-point of the original curve is the starting point of the new curve, and join the two curves into a single curve where they meet. In the images shown below, each new iteration is generated by rotating the previous iteration 90 degrees clock-wise around the end-point each iteration. When the curve is displayed on the screen, it's not obvious which end counts as the "end-point", however when the curve is stored as a array of points, it's easy to define the "end-point" as the last point in the array.
Ascii art is appreciated, but not accepted: This is graphical output, not ascii-art.
  
[Answer]
## Python 2/3, ~~169~~ ~~167~~ ~~150~~ ~~111~~ ~~98~~ 78 Bytes
*Note that the import is not included in the byte count, according to the challenge specs.*
Thanks to @AlexHall for saving 39(!) bytes and @nedla2004 for another 13
```
from turtle import*
o=[90]
for z in o*9:o+=[90]+[-x for x in o[::-1]]
fd(5)
for i in o:rt(i);fd(5)
```
Starts by generating a list or right (90) and left (-90) turns, then goes through the list and moves the turtle.
Generated Output:
[![enter image description here](https://i.stack.imgur.com/tcDDZ.png)](https://i.stack.imgur.com/tcDDZ.png)
EDIT: If this is too boring too watch, add `speed(0)` right before the first `fd(5)`. It will run the same, except the turtle will move much faster.
[Answer]
**x86, MSDOS, 16 bytes**
I wrote this a while ago, to my knowledge the smallest routine for producing a dragon fractal. It uses no real iterations, rather plots every contained discrete pixel inside the fractal directly, showing the *final* image. It's included with many other tiny productions in [this pack](http://www.pouet.net/prod.php?which=68474). The 16 byte version was the end of my effort to get the dragon fractal as small as possible, starting 2014 with [this 32 byte production](http://www.pouet.net/prod.php?which=63522).
Hex
```
14 10 19 CA D1 FA 10 DE 01 D1 CD 10 B4 0C EB F0
```
Code
```
S: 
adc al,0x10
sbb dx,cx       
sar dx,0x01 
adc dh,bl
add cx,dx
int 0x10
mov ah,0x0C
jmp short S
```
[![screenshot](https://i.stack.imgur.com/vcQ2n.png)](https://i.stack.imgur.com/vcQ2n.png)
[Answer]
# Logo, 43 bytes
```
for[i 1 512][fd 9 lt :i/(bitand :i -:i)*90]
```
Try with interpreter at <http://www.calormen.com/jslogo/#>
This uses the same principle as my [previous ASCII art answer](https://codegolf.stackexchange.com/a/53064/15599) and the formula on at [wikipedia](https://en.wikipedia.org/wiki/Dragon_curve) except I reversed the direction to match the image in the question:
> 
> First, express n in the form `k*(2^m)` where k is an odd number. The direction of the nth turn is determined by k mod 4 i.e. the remainder left when k is divided by 4. If k mod 4 is 1 then the nth turn is ~~R~~ L; if k mod 4 is 3 then the nth turn is ~~L~~ R
> 
> 
> 
`bitand :i -:i` finds the least significant bit of `i`. We divide `i` by this to shitft `i` right the required amount, giving the required odd number `k`. There is no need to distinguish between left and right turns; we just turn left by `k*90` degrees and rely on the fact that rotation is a modulo 360 operaton to perform the modulo for us.
**Output**
use `ht` to hide turtle if required.
[![enter image description here](https://i.stack.imgur.com/Lf0jP.png)](https://i.stack.imgur.com/Lf0jP.png)
**Output (modified)**
The following shows how the curve is a single strand.
```
bk 6 for[i 1 512][fd 6 rt :i/(bitand :i -:i)%4*45-90 fd 3 rt :i/(bitand :i -:i)%4*45-90]
```
[![enter image description here](https://i.stack.imgur.com/g2pfr.png)](https://i.stack.imgur.com/g2pfr.png)
[Answer]
# Underload, 196 bytes
```
()()(<svg width="99" height="147">)S(<g transform="translate):S((33,33)">)S((3,0)rotate)*a(*a(~*)*~("><path d="M0h3" stroke="#"/>)~*a(*)**:(-90)a~^~(90)a~^)*::*:**:*^S(</g>)(:*)::*:**:*^S(</svg>)S
```
I thought it might be interesting to try this challenge in a low-powered esolang; Underload does fairly well for a language with such a low number of commands.
The output is an SVG file with very heavily nested tags, and some golfing shortcuts. So far, I haven't found a browser that can display it (Firefox hangs for several minutes trying to load it, and both Firefox and Chromium give a blank screen). Most image processing programs can't load it either (making it hard to convert to another format), but I managed to load it in the image viewer Eye of Gnome (which is part of the default install on Ubuntu). So I took a screenshot of the image so that you can see it (the actual image has a transparent background, but you can't really screenshot transparent):
[![Screenshot of a dragon curve in Underload](https://i.stack.imgur.com/CTfsD.png)](https://i.stack.imgur.com/CTfsD.png)
We need to specify the image size explicitly. Picking an appropriate orientation for the image, drawing everything at the minimum legal size, and doing the minimum number of iterations specified by the challenge, gives us an image that *just* fits into 99 pixels wide, saving a byte. It's nice when things work out like that.
The general algorithm used for drawing the image is to maintain two variables (Underload doesn't name variables, but I thought of them as *x* and *y*), both initially empty. Then we repeatedly replace (*x*, *y*) with (*x*, turn left and move forward, *y*) and (*x*, turn right and move forward, *y*). After ten iterations, both *x* and *y* hold a nine-iteration dragon curve.
There are a few micro-optimizations and Underload-specific tricks, too. In order to avoid too much messing around with the top of the stack, each loop iteration, we start by combining *x* and *y* into the function "return the string created by concatenating: *x*, a turn instruction, the function argument, a move-forward instruction, and *y*." This function only takes up one space on the stack, so we can duplicate it, call it with `-90` as an argument, swap the return value under the duplicate, and call it with `90` as an argument, to get hold of new values for *x* and *y* without ever needing to touch more than the top two elements of the stack (which are by far the most commonly accessible). This function is code-generated at runtime. The generator itself is also code-generated at runtime, in order to allow it to reuse the string `<g transform="translate` that's also used to set the origin of the image. We generate all the open tags first, and then because all the close tags are just `</g>`, we can output 1024 close tags via simply repeating the string, without worrying about matching them to the open tags. (Writing numbers efficiently in Underload is an interesting problem in its own right; `(:*)::*:**:*` is probably the most efficient way to write 1024, though, translating to "2 to the power of (1 + 2×2) × 2".
Underload doesn't have any graphics libraries, so I produce SVG using a combination of drawing lines in a fixed position, and rotating the image around a given point; instead of turning the pen, we turn the paper. The idea is that by drawing a line, rotating the entire image, drawing another line, rotating the image again, etc., we can effectively simulate turtle graphics without having to do any arithmetic or use any graphics libraries, as all the lines are drawn in the same location. Of course, that means that we have some very heavily nested rotate-the-image tags, which confuses many SVG viewers.
Styling the image would count against the byte count, so I needed to give the minimum styling needed to display the image. This turns out to be `stroke="#"`, which more or less translates as "the line needs to be some color"; this seems to be expanded to drawing it in black. (Normally you'd specify the color as, say, "#000".) The background is transparent by default. We don't specify a stroke width, but the choice picked by Eye of Gnome leaves everything visible.
Many Underload interpreters struggle with this program, e.g. the one on Try It Online crashes, because it generates some very large strings internally. [The original online Underload interpreter](http://esoteric.voxelperfect.net/files/underload/underload.html) works, though. (Interestingly, the very first interpreter was online, so the language was usable online before it was usable offline.)
Something I'm slightly uneasy about is that there only seem to be 1023 line segments here, and we'd expect 1024. It could be that one of the segments at the end isn't being drawn with this algorithm (it'd be drawn on the next iteration instead). If that's disqualifying, it may be possible to adapt the program, but it might well end up considerably longer. (It's not like this challenge is going to win the competition anyway; there are already several shorter entries.)
[Answer]
# [LindenMASM](https://github.com/kade-robertson/pylasma), 51 Bytes
LindenMASM was a language I created for a challenge a while ago that will forever live in the Sandbox. It makes use of the concept of [Lindenmayer systems](https://en.wikipedia.org/wiki/L-system) to draw things like Dragon curves, fractal plants, Sierpinski triangles, etc.
The source code is as follows:
```
STT
AXI FX
INC 9
SET F 0
RPL X X+YF+
RPL Y -FX-Y
END
```
To set this up for `n = 6` for example:
```
STT
AXI FX
INC 6
SET F 0
RPL X X+YF+
RPL Y -FX-Y
END
```
This produces the following image via Python 3's `turtle`:
[![6 generations](https://i.stack.imgur.com/6igZ9.png)](https://i.stack.imgur.com/6igZ9.png)
There may be a slight numbering difference for iterations, as in the Lindenmayer system the first iteration is a single line. Here's what it looks like for `n = 10`:
[![10 generations](https://i.stack.imgur.com/jAROs.png)](https://i.stack.imgur.com/jAROs.png)
Just for fun, here's what it looks like with 15 generations (with an added instruction `MOV 2` to make it a bit smaller):
[![15 generations](https://i.stack.imgur.com/Mn6GZ.png)](https://i.stack.imgur.com/Mn6GZ.png)
Once you get up to 20 generations (with `MOV 0.5`) you can't really see the lines anymore, and it takes a LOT of steps to create (pairs of `+-` and `-+` are not optimized out). Here's what you get:
[![20 generations](https://i.stack.imgur.com/dviUy.png)](https://i.stack.imgur.com/dviUy.png)
*Note that the current interpreter may present graphical issues for smaller amounts of generations, i.e. possibly not drawing to the screen. Unfortunately when this interpreter was created there were no issues, a possible change in Python 3 could have caused this or it could just be my system*
[Answer]
# [MATL](https://github.com/lmendo/MATL), 26 bytes
```
0J1_h9:"tPJ*h]hYsXG15Y01ZG
```
If different scales in the two axes are accepted, the code can be reduced to 19 bytes:
```
0J1_h9:"tPJ*h]hYsXG
```
The figures below correspond to the equal-scale (26-byte) version.
The code above produces the 9-th (0-based) iteration, that is, the tenth image in the challenge:
[![enter image description here](https://i.stack.imgur.com/Cwf31.png)](https://i.stack.imgur.com/Cwf31.png)
For other values change the `9` in the code, or replace it by `i` to take the number as user input. For example, the result for `13` is:
[![enter image description here](https://i.stack.imgur.com/MkDCY.png)](https://i.stack.imgur.com/MkDCY.png)
### Explanation
This uses a loop to gradually build an array of the *steps* followed by the curve in the complex plane. For example, the first two steps are `1j` (up) and `-1` (left).
In each iteration, the array of steps so far is copied. The copy of the array is *reversed*, *multiplied* by `1j` (to rotate 90 degrees), and *concatenated* to the original.
After the loop, a *cumulative sum* of the steps gives the actual points, which are then plotted in the complex plane.
```
0                          % Push 0
 J1_h                      % Push array [1j, -1]. This defines the first two steps
     9:                    % Push [1, 2, ..., 9]
       "                   % For each
        t                  %   Duplicate the array of steps so far
         P                 %   Reverse
          J*               %   Multiply by 1j
            h              %   Concatenate horizontally to previous steps
             ]             % End
              h            % Concatenate with the initial 0
               Ys          % Cumulative sum
                 XG        % Plot. Complex numbers are plotted with real and imag as x and y
                   15Y0    % Push string 'equal'
                       1ZG % Set equal scale in the two axes
```
[Answer]
# Mathematica 86 bytes
```
{1,-1}
r=Reverse;Graphics@Line@Nest[Join[l=Last@#;h=#-l&/@#,r[r@#%&/@h]]&,{{0,0},%},9]
```
How it works:
`{1,-1}` Outputs `{1,-1}`. It basically "pushes it to the stack". This value can be recalled with `%`. `r=Reverse` basically just renames the Reverse function because I use it twice in the code. The `Graphics@Line@` just takes a list of points and draws a line connecting them. The real meat of the problem happens in this code segment: `Nest[Join[l=Last@#;h=#-l&/@#,r[r@#%&/@h]]&,{{0,0},%},9]`.
Lemme tell you - that segment is complicated as f\*\*\*\*\*\*ck. Here's what `Nest` does: `Nest[f,x,9]`outputs the result of calling `f[f[f[f[f[f[f[f[f[x]]]]]]]]]`.
In my code, this first argument `f` is: `Join[l=Last@#;h=#-l&/@#,r[r@#%&/@h]]&`, the second argument `x` is `{{0,0},%}` (which evaluates to `{{0,0},{1,-1}}`), and the third argument is `n`, which is just 9 (which will just apply the first argument to the second argument 9 times).
The most complex part of all is this first argument: `Join[l=Last@#;h=#-l&/@#,r[r@#%&/@h]]&`, which is a giant mess of almost pure syntactic sugar. I was *really* abusing mathematica's syntactic sugar for this one. That line of code represents mathematica's version of an anonymous function, except to shorten things I actually defined two separate anonymous functions within that anonymous function. Yep, that's legal, folks. Let's break it down.
`Join` takes two arguments. The first is `l=Last@#;h=#-l&/@#`, and the second is `r[r@#%&/@h]`.
**The first argument of Join:** Inside the "main" anonymous function, `#` is a list of all the points at the current iteration in the curve. So `l=Last@#;` means "Take the point in the list of points you recieved as input, and assign that point to the variable `l`. The next segment, `h=#-l&/@#`, is a little more complex. It means "You have a function. This function takes a point as input, subtracts `l` from it, and returns the result. Now, apply that function to every element in the list of points you received as input to generate a list of shifted points, and assign that new list to the variable `h`.
**The second argument of Join:** `r[r@#%&/@h]` has literally the most complex syntax I've ever written. I can't believe any code segment could contain something like `@#%&/@` - it looks like I'm cursing like a cartoon character in the middle of a program! But it's possible to break it down. Remember - `r[x]` takes a list of points and returns that list in reverse order. `r@#%&` is an anonymous function that reverses it's input, then multiplies it by the value storied in `%` (which is `{1,-1}`), and returns the result. Basically it rotates it's input 90 degrees, but in code as short as I could possibly write. Then `r@#%&/@h` means "Output a new list that is every point in `h` rotated 90 degrees."
So overall, `Join[l=Last@#;h=#-l&/@#,r[r@#*%&/@h]]&` is a function that takes a list of points as an input, and adds on that same list of points rotated 90 degrees to get the next iteration of the curve. This is repeated 9 times to get the dragon curve. Then it's the resulting list of points is drawn to the screen as a line. And the output:
[![enter image description here](https://i.stack.imgur.com/r6vjg.png)](https://i.stack.imgur.com/r6vjg.png)
[Answer]
# Python 2, 43 bytes
This answer is 43 bytes not including the import statement and it's largely based on [Level River St's Logo answer](https://codegolf.stackexchange.com/a/100602/47581) and their use of `i/(i&-i)` in their code. [Try it online at trinket.io](https://trinket.io/python/56979696a6)
```
from turtle import*
for i in range(1,513):fd(9);rt(90*i/(i&-i))
```
Here is a picture of the output.
[![enter image description here](https://i.stack.imgur.com/pO2PX.png)](https://i.stack.imgur.com/pO2PX.png)
[Answer]
# Mathematica, ~~56~~ 55 bytes
```
Graphics@Line@AnglePath[Pi/2JacobiSymbol[-1,Range@512]]
```
[![enter image description here](https://i.stack.imgur.com/Nrrmi.jpg)](https://i.stack.imgur.com/Nrrmi.jpg)
Explanation: [OEIS A034947](http://oeis.org/A034947)
Just for fun, here is a colored version of the 19th iteration.
[![enter image description here](https://i.stack.imgur.com/1550R.png)](https://i.stack.imgur.com/1550R.png)
[Answer]
# HTML + JavaScript, 182
```
<canvas id=C></canvas><script>c=C.getContext("2d")
C.width=C.height=400
s=n=9
x=y=200
for(i=d=0;i<=1<<n;d+=++i/(i&-i))
c.lineTo(x,y),
d&1?y+=d&2?s:-s:x+=d&2?-s:s
c.stroke()</script>
```
[Answer]
## Mathematica, 63 bytes
Using `AnglePath`
```
Graphics@Line@AnglePath[Pi/2Nest[Join[#,{1},-Reverse@#]&,{},9]]
```
[![Nine iterations](https://i.stack.imgur.com/bT3OF.png)](https://i.stack.imgur.com/bT3OF.png)
[Answer]
# Haskell + diagrams, 179 bytes
```
import Diagrams.Prelude
import Diagrams.Backend.SVG
d 1=hrule 1<>vrule 1
d n=d(n-1)<>d(n-1)#reverseTrail#rotateBy(1/4)
main=renderSVG"d"(mkWidth 99)$strokeT(d 9::Trail V2 Double)
```
Output is a 99 pixels wide svg file with transparent background (an image 9 pixels wide would have a stroke too thick to recoqnize anything). Here it is rescaled and composed over a white background:
[![Dragon number nine](https://i.stack.imgur.com/IBeEP.png)](https://i.stack.imgur.com/IBeEP.png)
[Answer]
# [tosh](http://tosh.tjvr.org), 518 bytes
tosh is [Scratch](https://scratch.mit.edu), but with text instead of blocks. At 518 bytes, this answer is probably even worse than Java.
This answer uses the same logic as [@Theo's Python answer](https://codegolf.stackexchange.com/a/100566/46900), but with strings of "L" and "R" instead of numbers, as Scratch's (and thus tosh's) list capabilities are awful.
You can run it as a Scratch project [here](https://scratch.mit.edu/projects/132243830/). (tosh compiles to Scratch projects)
```
when flag clicked
set path to "R"
go to x: -50 y: 100
point in direction 90
pen down
set pen size to 2
clear
repeat 9
    set path copy to path
    set path to join (path) "R"
    set i to length of path copy
    repeat length of path copy
        if letter i of path copy = "R" then
            set path to join (path) "L"
        else
            set path to join (path) "R"
        end
        change i by -1
    end
end
set i to 0
repeat length of path
    change i by 1
    if letter i of path = "R" then
         turn cw 90 degrees
    else
         turn ccw 90 degrees
    end
    move 7 steps
end  
```
## Explanation:
```
when flag clicked
set path to "R"
go to x: -50 y: 100
point in direction 90
pen down
set pen size to 2
clear
```
This first part makes the program run when the green flag is clicked (`when flag clicked`), sets the path variable to "R", and gets the sprite and stage in the proper state to be ready to draw.
```
repeat 9
    set path copy to path
    set path to join (path) "R"
    set i to length of path copy
    repeat length of path copy
        if letter i of path copy = "R" then
            set path to join (path) "L"
        else
            set path to join (path) "R"
        end
        change i by -1
    end
end
```
Now we get to the path generation code. It uses the same logic as [@Theo's Python answer](https://codegolf.stackexchange.com/a/100566/46900), except with strings of "R" and "L" instead of numbers, and we use nested loops instead of list comprehensions.
```
set i to 0
repeat length of path
    change i by 1
    if letter i of path = "R" then
         turn cw 90 degrees
    else
         turn ccw 90 degrees
    end
    move 7 steps
end  
```
Finally, we draw the path by going through each letter of the path variable and turning left or right depending on the letter.
]