0. When ruby parser encounters assignment statement on some term looking like a local variable (a = 1, b ||= 2 etc.), it creates such variable. That’s why it knows later that “a” is a local variable, not a method call.
1. Sometimes this leads to a confusion:
def x; :x; end
def y
x = 42 if false # assignment is not executed
x
end
y #=> nil (not :x as someone could predict)
2. But sometimes it helps a lot (
merb):
# partial will have a local variable named "some_option"
partial(template, object, :some_option => 1)
# in this case there won't be a local variable "some_option"
partial(template, object)
Inside the partial you cannot simply write
if some_option because it will raise NameError in case :some_option was not passed into the partial. However
if (some_option ||= nil) works in either case.
Note:
some_option || nil won’t work because it is not an assignment statement.
$ скл Олег Андреев
Олег Андреев
Олега Андреева
Олегу Андрееву
Олега Андреева
Олегом Андреевым
Олеге Андрееве
$ gem sources -a http://gems.github.com
$ sudo gem install yaroslav-yandex_inflect
# ~/.bashrc
alias inf="ruby -rubygems -e'require \"yandex_inflect\"; puts YandexInflect.inflections(ARGV.join(\" \"))'"
alias скл=inf
alias склон=inf
alias склонять=inf
alias склонение=inf
$ sudo gem update --system
Password:
Updating RubyGems
Updating rubygems-update
Successfully installed rubygems-update-1.3.1
ERROR: While executing gem ... (NameError)
undefined local variable or method `remote_gemspecs' for
#<Gem::Commands::UpdateCommand:0x11dfa8c>
There are always holy wars around Perl, Python, PHP, Ruby, Java and C#. We have enormous freedom on the server side comparing to a quirky browser environment. Why don’t we use Javascript on the server?
2-3 years ago server-side JS wouldn’t give us anything what wasn’t already available in other environments. But today we build rich applications with tons of code in javascript. Don’t we have some code to be shared with the server?
jQuery, prototype.js and MooTools may be used as a template engines, much flexible than <%%> and <??> tags, but also nicer and more lightweight than XSLT.
Selectors and transformations could be used both on the server side (to produce statically generated pages) and client side (for partial ajax updates).
Raw data interchange becomes easier. Also, you have common testing toolkit.
Recent JS implementations outperform Ruby, Python and Perl. Mostly, due to JS simplicity (no method_missing(), no classes and metaclasses etc.), but also because of enormous experience comparing with legacy server-side technologies. While Ruby, Python and Perl are used by X developers each, JS is used by (3*X + Y) developers plus hundreds of millions of mere mortals all around the world.
I believe, there’ll be web-server written for some open source JS engine very soon (Apache and Java don’t count).
Goto is not itself an absolute evil. Teaching youngsters to write a bad code is an absolute evil. Dirty tricks should be something what is clearly identified to be (sic!) “dirty”. Therefore they should be taught after good practices are successfully established.
Every programming language lacks some useful features, which other languages may provide. Many experienced programmers know several languages and try to port features and semantics from one language to another. It looks terribly wrong and inconvenient when one tries to write Java in Ruby, as well as vice versa. When you try to make a paper-like layout on the web for a newspaper you are shooting right into your foot and get nothing except buggy quirky page behavior and sleepless nights in fixing css bugs.
When you are trying to invent classes in JavaScript you end up with 10 different (incompatible) implementations with bizarre semantics (“where is the ‘this’?”).
The world is overcomplicated already. Meta programming (building all these frameworks, libraries and DSLs) is meant to extract and polish The Knowledge and minimize future efforts. Instead, we have to learn more and more things over time instead of keeping strong focus relying on our past achievements.
The first rule of thumb for a smart programmer: respect your language, choose appropriate tools for each task. Invent your own tools if you have to, but do not break already existing ones.
Thinking Forth helped me to realize the essential part of the Better Language. It is a scripting interface to libffi. That’s it.
The requirements for such interface are: portability, turing-completeness, single thread, simple grammar, no garbage collector (hence, no garbage).
Using this interface we could bootstrap a system environment for a language of our choice and easily connect important libraries like libcoroutine, llvm, libgarbagecollector and many others.
