Any other screenwriters?
Rick Johnson
rantingrickjohnson at gmail.com
Sat Mar 9 18:07:02 EST 2013
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/
More information about the Python-list
mailing list