Bayle Shanks's website: notes-computer-programming-programmingLanguageDesign-prosAndCons-ruby

http://blog.clifreeder.com/blog/2013/04/21/ruby-is-too-slow-for-programming-competitions/

misc

nossralf 10 hours ago

link

Topaz [1] is a Ruby implemented using RPython (so it uses the same JIT mechanisms as PyPy?).

[1] http://docs.topazruby.com/en/latest/blog/announcing-topaz/

" If a language cannot define lazy function it simply lacks in abstraction power. I think any kind of fragment of the language should be nameable and reusable. (Haskell lacks this ability for patterns and contexts; a wart in the design.) So if you notice a repeated expression pattern, like

    if c then t else False

and cannot give this a name, like

    and c t = if c then t else False

and then use it with the same effect as the orginal expression, well, then your language is lacking.

For some language constructs the solution adopted by Smalltalk (and later Ruby), i.e., a very lightweight way on constructing closures is acceptable. So, for instance, I could accept writing

    ... myAnd x {y} ...

(In SML you could make something using functors, but it's just too ugly to contemplate.)

---

" I do think the future of software deployment is in small, containerised VMs and so-called PaaS?, as what we're all doing right now has to end, some time.

Non-deterministic deploys of code from (usually) un-tagged source control, with production environments needing all kinds of eccentric heavy weight tools to help with mutating assets to solve problems that are mostly a product of poor framework in the first place design can't go on forever.

Whilst I think Rails is a great framework (and by and large most users of Capistrano are Rails users), it's asset pipeline is a poorly thought out idea which causes a myriad of problems. Whilst I love Ruby as a language, it's failure to standardise on an interpreter has lead to horrible situations with people using rvm and rbenv and chruby in production where things really ought to be more specified.

These problems are problems of other tools, problems of poor design, and problems of poor education. People are often using rvm and rbenv in production environments because Ruby is pathologically difficult to install correctly on modern Linux distributions; and more often than not people choose LTS versions of their distribution, and then throw those guarantees out of the window by replacing system components with bleeding edge versions of turbo-GC hacked version of their required interpreters.

...

Ruby Gems is an awful platform. I feel crushed by the burden for making things secure, both making things difficult to use wrongly, and making them safe to use. Ruby Gems makes signing gems overly difficult, uses non-standard methods, and nobody bothers to validate them anyway.

...

I'll be encouraging everyone I meet to find a better way to deploy software, using containers, or switching to a language better suited to deployment, where Gem bundlers aren't required to get all the load paths fixed, and where concatenating a few css files, and minifying Javascript doesn't take 10 minutes.

" -- Lee Hambley, lead Capistrano dev, https://groups.google.com/d/msg/capistrano/nmMaqWR1z84/hdjAGIGbwdYJ

---

avodonosov 2 days ago

link

The reason to bet on Julia is disassembling a function? This is a standard feature in Common Lisp (ANSI standardized in 1994)

  CL-USER> (defun f(x) (* x x))
  F
  CL-USER> (disassemble 'f)
  L0
           (leaq (@ (:^ L0) (% rip)) (% fn))       ;     [0]
           (cmpl ($ 8) (% nargs))                  ;     [7]
           (jne L33)                               ;    [10]
           (pushq (% rbp))                         ;    [12]
           (movq (% rsp) (% rbp))                  ;    [13]
           (pushq (% arg_z))                       ;    [16]
           (movq (% arg_z) (% arg_y))              ;    [17]
           (leaveq)                                ;    [20]
           (jmpq (@ .SPBUILTIN-TIMES))             ;    [21]
  L33
           (uuo-error-wrong-number-of-args)        ;    [33]

kisielk 2 days ago

link

This is also possible to a degree in Python, though you only get the bytecode:

    >>> def f(x):
    ...     return x * x
    ...
    >>> import dis
    >>> print dis.dis(f)
      2           0 LOAD_FAST                0 (x)
                  3 LOAD_FAST                0 (x)
                  6 BINARY_MULTIPLY
                  7 RETURN_VALUE

sitkack 2 days ago

link

And the bytecode is just calling polymorphic methods. All the real work is done in the object implementations of type(x). I was very bummed years ago to realize how shallow the bytecode representation in Python is. There is no sub-terpreter, just C.

steveklabnik 2 days ago

link

You can get the bytecode in Ruby too: http://www.ruby-doc.org/core-2.1.0/RubyVM/InstructionSequenc...

http://www.randomhacks.net/2005/12/03/why-ruby-is-an-acceptable-lisp/

Ruby vs. Lisp:

[1,2,3].map {

n*n }.reject {

n%3==1 }

(remove-if (lambda (n) (= (mod n 3) 1)) (mapcar (lambda (n) (* n n)) '(1 2 3)))

" Ruby itself started out as "matzlisp", a Scheme dialect (as still evidenced by many things like Bignums, the numeric tower, callcc, immediate types packed into VALUE, symbols, and the general feel of the C API). " -- http://on-ruby.blogspot.com/2007/01/will-rubinius-be-acceptable-lisp.html

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/179642

" From: Yukihiro Matsumoto <matz ruby-lang.org>

...

Ruby is a language designed in the following steps:

take a simple lisp language (like one prior to CL).
remove macros, s-expression.
add simple object system (much simpler than CLOS).
add blocks, inspired by higher order functions.
add methods found in Smalltalk.
add functionality found in Perl (in OO way).

So, Ruby was a Lisp originally, in theory. Let's call it MatzLisp? from now on. ;-) "

http://www.tutorialspoint.com/ruby/ruby_operators.htm

http://ruby.about.com/od/oo/ss/Overloading-Operators.htm

jarrett 3 days ago

link

My take on Ruby vs Python is this:

While Python has a healthy web dev ecosystem, Ruby's feels much larger to me. That's almost certainly because Rails is so wildly popular. And Rails is an excellent, mature framework. So for web dev, I would consider Ruby the winner.

Python is the clear winner for scientific computing. That's not really due to anything inherent in the language. It's an ecosystem thing. If you were using Fortran before, you might be working in a problem domain where Python dominates.

Both are excellent for miscellaneous scripting work. E.g. reading in a CSV file and doing something with each row; batch-processing a bunch of images; renaming 1000 files according to some ruleset; gathering some system data and sending nightly status emails.

In terms of syntax and features, they're very very similar. Python has meaningful whitespace, which you may like or dislike. (I think it's good for enforcing proper formatting, but you're free to disagree.) Ruby has multiple ways of expressing the mathematical concept of a function (methods, blocks, and procs), which has its pros and cons. Both have metaprogramming facilities, though I find Ruby's more pleasant. If I remember correctly, it was in large part the metaprogramming that made DHH pick Ruby for Rails.

toyg 3 days ago

link

> While Python has a healthy web dev ecosystem, Ruby's feels much larger to me.

It's funny because I actually feel the opposite: Ruby is mostly a niche language for the web community, whereas Python is now mainstream in so many different areas (graphics, scientific, sysadmin, financial...).

I've yet to see a non-webdev tool embedding Ruby as a scripting language, while Python is now featured in office suites, spreadsheets and enterprise software. Anywhere simple and clear syntax is more valued than metaprogramming features, Python is likely to appear at some point.

jarrett 3 days ago

link

I think we have almost the same opinion, actually. I said Ruby's "web dev ecosystem...feels much larger to me." I agree that Ruby's strongest niche is web dev. And I think it has an edge of Python there. Outside web dev, I don't see Ruby dominating any particular niche.

pmontra 3 days ago

link

Ruby is perhaps more dominant than Python in web development. Not that Rails is necessarily better than Django, but it seems there are more Rails developers than Django ones. However Ruby seems to be pretty much confined to web development and deployment tools. It also makes great DSLs thanks to its block syntax. However in general Python is more popular than Ruby.

One reason is that Python is used for system programming (e.g: the Linux apt system), desktop applications, big data (thanks to numpy) so you might find it a better investment for general purpose software development.

Another reason, which maybe explains the first one, is that Python looks more similar to C++/Java. Basically it's a simplification of those languages (the {} pair traded for a single colon, no type declarations, etc) plus some handy shortcuts. Ruby is from a somewhat different lineage (Smalltalk) and it shows in many places (e.g. the do

variable

... end blocks). It can be used to write more natural language looking programs and combining that with some metaprogramming sometimes both amazes and unsettles programmers that come close to the language for the first time.

I suggest that you learn a little of both of them, working on the problem you want to solve, and decide by gut feeling what you would like to work with. I went the Ruby way because I can't stand some of the syntax of Python, not that Ruby is perfect.

---

http://augustl.com/blog/2008/procs_blocks_and_anonymous_functions/

---