August 17th, 2007
My presentation from JavaBin
If someone is interested in the presentation I did at javaBin in Bergen and Oslo, it can be found here.
If someone is interested in the presentation I did at javaBin in Bergen and Oslo, it can be found here.
Since the current world is moving away from languages in the classical imperative paradigm, it’s more and more important to understand the fundamental type differences between programming languages. I’ve seen over and over that this is still something people are confused by. This post won’t give you all you need – for that I recommend Programming Language Pragmatics by Michael L. Scott, a very good book.
Right now, I just wanted to minimize the confusion that abounds surrounding two ways of categorizing programming languages. Namely strong versus weak typing and dynamic versus static typing.
The first you need to know is that these two typings are independent of each other, meaning that there are four different types of languages.
First, strong vs weak: A strongly typed language is a language where a value always have the same type, and you need to apply explicit conversions to turn a value into another type. Java is a strongly typed language. Conversely, C is a weakly typed language.
Secondly, dynamic vs static: A static language can usually be recognized by the presence of a compiler. This is not the full story, though – there are compilers for Lisp and Smalltalk, which are dynamic. Static typing basically means that the type of every variable is known at compile time. This is usually handled by either static type declarations or type inference. This is why Scala is actually statically typed, but looks like a dynamic language in many cases. C, C++, Java and most mainstream languages are statically typed. Visual Basic, JavaScript, Lisp, Ruby, Smalltalk and most “scripting” languages are dynamically typed.
See, that’s not too hard, is it? So, when I say that Ruby is a strongly, dynamically typed language, you know what that means?
C is a actually an interesting beast to classify. It’s the only weakly, statically typed language I can think of right now. Anyone has any more examples?
To find out more, read the book above, or look up “Type systems” on Wikipedia.
I’m right now in Bergen, but I’m flying to Oslo later today – I’ll basically land and head directly to the javaBin meeting. Afterwards I’m up for beers or something, if someone wants to.
On Friday I’m heading for Sweden. For purely recreational purposes. I’ll be in Gothenburg, Malmö and Stockholm for a week or so, so if someone feels like saying hi, do tell. I always like good discussions about programming languages. And other things as well, in fact.
Now, this is totally awesome. Jay found a way to implement generic comprehensions in Ruby. In twenty lines of code. It’s really quite obvious when you look at it. An example:
(1..100).find_all &it % 2 == 0
%w'sdfgsdfg foo bazar bara'.sort_by(&its.length).map &it.reverse.capitalize
%w'sdfgsdfg foo bazar bara'.map &:to_sym
%w'sdfgsdfg foo bazar bara'.map &it.to_sym
Now, the last two lines are what I like the most. The Symbol to_proc tric is widely used, but I actually think the comprehension version is more readable. It’s even better if replacing “map ” with “collect”.
This is actually real fun. You can link how many methods you like – you can send arguments to the methods, you can send blocks to them, you can link and nest however you want. It apples for Arrays, Sets, Hashes – everything you can send a block to can use this, so it’s not limited to collections or anything like that.
I think it’s really, really cool, and it should be part of Facets, ActiveSupport, hell, the Ruby core library. I want it there.
Now, the only, only, only quibble I have with it… He choose to call it “The Methodphitamine”. You should actually use ‘require “methodphitamine”‘. It’s a gem. I love it. But I hate the name. So, read more in his blog, here: http://jicksta.com/articles/2007/08/04/the-methodphitamine.
So, I had a great time at the London RUG tonight, and Jay Phillips managed to show me two really neat Ruby tricks. The first one is in this post, and the next one is about the second.
Now, Ruby has a limited amount of operator overloading, but that is in most cases limited by what is predefined. There is actually a category of operators that are not available be the regular syntax, but that can still be created. I’m talking about almost all the regular single operators followed by either a plus sign or a minus sign.
Right now, I don’t have a perfect example of where this is useful, but I guess someone will come up with it. You can use it in all cases where you want to be able to use stuff like binary ++, binary –, /-, *+, *-, %-, %+, %^, and so forth.
This trick makes use of the parsing of unary operators combined with binary operators. So, for example, this code:
module FixProxy; end
class String
def +@
extend FixProxy
end
alias __old_plus +
def +(val)
if val.kind_of?(FixProxy)
__old_plus(" BAR " << val)
else
__old_plus(val)
end
end
end
puts("Foo" ++ "Baz")
will actually output “Foo BAR Baz”.
I’m pretty certain someone kind find a good use for it.
Anyone showing up for the London RUG tonight? Seems like it will be interesting: Ruby2Ruby and ParseTree, and also Jay Phillips about Adhearsion (which is really cool).
I will not be presenting, so don’t worry about that. =)
Hope to see you there.
So, it seems someone stepped up to the challenge and started working on ActiveHibernate from me initial idea. The code got pushed online a while back and I have finally had the time to look at it. Over all it looks really nice.
Of course, it’s very early times. I’ve submitted some patches making the configuration aspect easier and more AcitveRecord like – but it’s going to be important to have access to all the features of Hibernate too. When in the balance, I don’t think we should aim for total ActiveRecord equivalence.
Read more here and find the Google Code project here.
I would encourage everyone interested in a merger between Rails and Hibernate to take a look at this. Now is the time to come with advice on how it should work, what it should do and how it should look like.
I am a speaker at RailsConf Europe in Berlin. I’m going to talk about JRuby on Rails at ThoughtWorks. Hopefully many of you’ll make it there! As far as I know, it seems the whole core JRuby team may be together for the first time ever, so it’s going to be a great conference for JRuby.
See you in Berlin!
It’s very nice. Each time I get an update from Tor Norbye’s blog with screenshots from the NetBeans Ruby support I see a new interesting feature. What I saw this time (here) was that the gotcha from my entry called “Ruby is hard” can now be detected by NetBeans. It’s not really too hard, since NetBeans have the parse trees. But it’s still a very nice feature to have in your editor.
But I ain’t switching from Emacs yet…
I have been doing Ruby programming for several years now, and been closely involved with the JRuby implementation of it for about 20 months. I think I know the language pretty well, and I think I have for a long time. This has blinded me to something which I’ve just recently started to recognize. Ruby is really hard. It’s hard in the same way LISP is hard. But there are also lots of gotchas and small things that can trip you up.
Ruby is a really nice language. It’s very easy to learn and get started in, and you will be productive extremely quickly, but to actually master the language takes much time. I think this is underestimated in many circles. Ruby uses lots of language constructs which are extremely powerful, but they require you to shift your thinking – especially when coming from Java, which many current Ruby converts do.
As a small example of a gotcha, what does this code do:
class Foo
attr_accessor :bar
def initialize(value)
bar = value
end
end
puts Foo.new(42).bar
If your answer is that it prints 42, you’re wrong. It will print nil. What’s the necessary change to fix this? Introduce self:
class Foo
attr_accessor :bar
def initialize(value)
self.bar = value
end
end
puts Foo.new(42).bar
You could argue that this behavior is annoying. That it’s bad. That it’s wrong. But that’s the way the language works, and I’ve seen this problem in many code bases – including my own – so it’s worth keeping an eye open for it.
Why does it happen? Well, the problem is this, when the Ruby parser finds a word that begins with an underscore or a lower case letter, and where that word is followed by an equals sign, there is no way for the parser to know if this is a method call (the method foo=) or a variable assignment. The fall back of the parser is to assume it is a variable assignment and let you specify explicitly when it should be a VCall. So what happens in the first example is that a new local variable called “bar” will be introduced and assigned to.