Any other screenwriters?

[Rick Johnson]

On Friday, March 8, 2013 11:36:05 PM UTC-6, richard... at gmail.com wrote:
> Noted. But it seems to be the syntax the screenwriters and
> their programmers have settled on for now. It's all
> working pretty well. Just no Python or command-line
> implementations yet. I didn't post seeking help to make a
> new markdown system for screenwriters. That would surely
> be out of my league.

Well *everything* will perpetually be "out of your league" until you start challenging yourself to learn new things.

> Sorry if I was unclear. Sure. I have several programs like
> this and yes we use them once production starts, but it's
> nice to be able to work in your text editor for as long as
> possible. Faster. More versatility.

I agree.

> So everybody is looking for a fast way to make PDFs in
> screenplay format from simple markdown text.

Well, well. 

This is your golden opportunity Rick. You seem to have found a niche problem that needs solving, but more importantly, you have experience as a screen writer (and programmer (hobbyist or not)) giving you valuable insight into what features can improve the workflow of a simple ASCII markdown syntax. 

And, lucky for you, making the translation from Ruby to Python does not require you to become highly proficient with Ruby, NO, once you understand a few key differences you can start translating code into something usable.

I think the greatest barrier to learning Ruby is that it has too many ways to achieve the same result[1], which is opposite of Python's philosophy[2]. A few aspects that can trip you up are:

 * White-space is NOT significant

 * String literals delimited by using single quote chars
   are raw, and string literals delimited by double quote
   chars are not.

 * Module encapsulation is NOT automatic like in Python,
   instead, it must be explicitly declared using "module
   [code here] end" syntax! Another side effect of this is
   if you write (what you think is a function) in global
   namespace, you are actually writing a method for
   "Object", and since "Object" is inherited by almost
   everything in Ruby, now ALL those subclasses contain your
   new so-called "function"; Ha! Talk about an introspection
   nightmare! So be sure to encapsulate that code fella.

 * Ruby uses the "if-elsif-else" progression, whereas Python
   uses "if-elif-else". There is also a "case" statement
   available in Ruby.

============================================================
 * Object Oriented Programming
============================================================
Ruby is more Object oriented than Python (which can be a good thing!), for instance, no more global function nightmare! Objects have methods and methods exist where they should! 

    RUBY: sequence.map{|item| item+1}
    
    PYTHON_1: map(lambda item:item+1, sequence)
    
    # via list comprehension:
    PYTHON_2: [item+1 for item in sequence]
    
    # via generator expressions!
    PYTHON_3: (item+1 for item in sequence)
    
    Hmm, seems old Tim Toady is like a plague of, well... toads!
    
Another side effect of Rubys strong OOP is that you can intelligently chain:

    sequence.map{|x| x+1}.uniq.sort.length

...if you tried that in Python, it would be a mess only a devoted lisper could appreciate:

    len(set(map(lambda x:x+1, sorted(sequence)))) 
    
o_O ¡Ay, caramba!
    
============================================================
 * Ruby Blocks can be written many *MANY* ways
============================================================ 

Blocks in ruby will "most likely" use curly braces like this:
    
    sequence.each{|item| do_something_with(item)}

...but they could also legally use the "do..end" delimiters like this:

    sequence.each do |item| do_something_with(item) end

...or even look exactly like Python code!:

    for item in sequence
        do_something_with(item)
    end
    
Mama-Mia! That's three ways of accomplishing the exact same thing, and the worse part is, these could even be intermixed in the same script file!

============================================================
 REFERENCES
============================================================ 

[1] ThereIsMoreThanOneWayToDoIt (affectionately referred to as: "Tim Toady")
    http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it
    
[2] The Python Zen
    http://www.python.org/dev/peps/pep-0020/