yozzeff thinks

Me afraid of javascript?

2006-05-20T15:19:00.000+02:00

kevin wonders why people try to avert writing javascript.
especially when they use some sort of transformation/compiler
from another dynamic language to javascript.

problems?

he names a few problems when working with js

you are not shielded from the differences of
the browsers (this is only possible thru the library you use)

debugging javascript in the browser is a major PITA.

if your transformation tool is buggy you are
back to square 1 and you need then to know your
transformation and javascript on top

but are these the real problems of javascript development?
actually i dont think so!

modularization

what javascript is really missing are modularization features
enabling you to do large scale development.
namely javascript as of today is missing

namespaces

type definitions

namespaces allow for modularization in the large whereas typedefinitions (aka classes) allow for modularization in the small.

of course you can easily emulate those features with js.
but what is missing is the mental framework for doing this.

syntax follows semantics

the sameness of every construct you are touching
when working with prototype based languages makes
it quite hard to distinguish between small and large modules;
between important and not so important sourcecode elements

one reason i think that prototyped based languages never
quite took off is that they are sort of restricting
despite their dynamicism (actually i only know javascript
and self). keywords can have a quite liberating effect
even thou they do restrict you.

new keywords?

please dont take this a plea for new keyswords in
javascript. rather it is a plea to give me the tools to be
able to create new keywords in javascript if i feel so.
that is give me syntactic macros.

at the moment i use javascript libraries only in small
doses when doing a bit of rails development. if i had
to develop a large webbased application i'd rather
use actionscript 3.0.
i have ported a quite large application just a few
weeks ago from qooxdoo to actionscript in about
1/5 of the time it took me with qooxdoo.
the reason was not so much qooxdoo
(a very cool ajax-gui-framework) but having so much
javascript files without any support for modules
made the whole thing a real pain.
flexbuilder of course helped as well :-).

static typing vs. dynamic typing

2006-03-13T21:48:00.000+01:00

that debate about strongly typed languages vs weakly (or dynamicly) typed languages will probaly never end.

XOR

the reason being that both camps usually present their arguments as a XOR relation. meaning you either use a strongly typed language or you dont use any types at all.

the problem thou is that both are wrong even thou i admit that the dynamic camp is usually more open minded - certainly due the fact, that proponents of dynamic languages often have switched sides from for example java to ruby or python so they usually _know_ about the attributes of typed as well as of untyped languages. the camp of typed language diehards on the other hand (especially java guys) have often never used any dynamic language in earnest - but nevertheless claim superiority. which bags the question on which facts.

No Value on Its On

now if you ask me ... being typed or untyped is no value in itself. other attributes define if typed is a postive trait or if it is a negative trait.

a big system might be much better off if its typed whereas small and medium systems might be better off if untyped.

2type || !2type

now of course the question remains when is a system
big and when is system small?
let me give you 2 measures (which are of course incomplete):

- lines of code (LOC)
- number of developers

problem nobody would argue if i say that any system that is a million lines of code is pretty big - regardless of language used; whereas a team of 3 developers is rather small.

now the problem with small projects is that they tend to grow. especially the successful ones grow and grow and suddenly your system is 250k LOC and 15 developers and you realize that the informal ways of communication you have used do not scale. especially the communication between the subteams breaks all the time.

Formalizing

its time to start formalizing communication paths between devlopment groups. the easiest way on formalizing communication between teams is to add type information to your external interfaces.
now before all you java guys start to shout: "we knew it all the way" please reread the last sentence. i am talking about explicit external interfaces that a team and group publishes to the outside world for consumption. that usually includes services and facades and classes used for data exchange.
your internals can stay untyped and often it is far better if they do. especially if that module is still under heavy development or refactoring.
but then the same advices goes to your dynamic typers - especially you python guys opposing any addition of optional type information into python 3000.
please! documentation is NO substitue for enforced type checking. you are kidding yourself if you belive that.

Workarounds

now good thing with some of the dynamic languages is that you can overcome that point where you should start adding type annotations. all languages that offer decent meta facilities can very well create their own optional static typing system. ruby and python 2.4+ fall into this camp whereas javascript is not capable of such a feat.

the problem with java on the other hand is that it can not "scale down".
it is simply not possible to have parts of your program "untyped" - you can hack around it with reflection and xml and the like but ist
ugly - ugly - UGLY!

Solutions?

so what can we do about all of this? well, basically nothing. there are a few languages out there that do optional typing (boo for example - a python clone). some languages like scala or nemerle are at least trying to do type interference which spares you at least the pains of java generics. but most of these languages are even more obscure than ruby had been 3 years ago (meaning that almost nobody knows them).
i wish for a optional typed ruby or a java where i could drop type infos. that would be nice.

playboy bunnies and the ruby community

2005-10-31T20:40:00.000+01:00

eric has some problems with some things martin fowler said about the ruby community vs. the python community in his blog

what was really said

now if he read martins blog entry really and slowly he might notice that martin does say that he does not know if the ruby community is nicer than the python community but that he has noticed that the ruby community is nicer that most other online communities.
this of course could include python but not necessarily so.

observations

as far as i can tell it is definitly true that the ruby community is a very nice one and especially so if you compare it to other communities.
have a look on any thread on theserverside.com or on java lobby.
or have a look at hibernate forums. many of them are populated by rude and/or arrogant people.
my experiences with python people are as equally conforting as those with ruby people. be it online or offline.

what eats them

what i also observe thou is that python people are getting easily ungentlemen like if you start talking RoR.
they simply do not understand the hype especially as python has all of that too.
sorry guys but sometimes timing and a little bit of luck is all it needs. ask digital research and microsoft about it.
maybe the biggest issue here is that pythons are used to eat and not be eaten.

conclusion

as far as i am concerned - i like both communties - especially in
contrast to any java community (and particulary to the hibernate guys).
sure eric is right: bunny rabbits are even nicer than ruby people. BUT any playboy bunny is even nicer that a rabbit bunny.
belive me if i had the chance to spend a night with one of these bunnies i wouldnt frett a minute for not having any one of you nerds around me.
be it nice ruby or python people.
so please get a life - and me too.

teclarative.rb (information underflow)

2005-10-20T15:42:00.000+02:00

christian has blogged about my talk on euruko.
it was about teclarative.rb. a domain specific language
for declarative testing. now as people read chris's
blogg they start asking for more information.

the short answer

sadly there is not much of that at the moment. for
the talk i created of course a set of slides which
i have converted to PDF and which you can download
here
but there is only a slight chance that you
will find the slides usefull as i was creating them
according to the takahashi method.
this methods lends itself very well to live presentations
(at least that was my impression when doing the talk) but it
falls absolutely short when giving it to people that have not
attended the talk.

polishing

so for all the interested parties:
please give me a few more days to polish the library
as well as create some decent documentation.
i will announce on this blog and on comp.lang.ruby.

ruby geeks gathering (euruko 2005)

2005-10-17T08:30:00.000+02:00

so its done. 2 days of nerdy talk by nerds with nerds.
and beer of course as this was in munich.

organisation

or the lack thereof. at least that was my first impression when
i looked at the conference page and when the conference started.
but stefan who was the chair of the conference did very well.
he organised the tracks ad hoc by giving index cards
to the participants to write the name and a short description
of their talk(s). after doing that all of us discussed the
concrete schedule and after everybody introduced himself
(there where about 40 of us) the talks began.

the good and the ugly

as ever when going to a conference
- especially to technology conference -
the quality of talks ranges from pretty lame to almost brilliant.
same of course is true for the speakers themselves.
there are speakers who are gifted and ... well ... uhm ... yes.

interesting stuff

kingsley did a very interesting talk
about using selenium as a testing framework on agile projects.
thou i am not that much into agile projects i found he's talk
enlightning. this will enable me to push ruby into our company
as the benefits can be hardly argued.
also rob's talk about his jedit plugin was quite nice. i will
certainly us the plugin on my ladies notebook
(that is the one for traveling :-) )

outstanding stuff

chris did a presentation on a
framework he wrote that does AOP. actually he calls
it contextR but it does quite a bit of aspectizing.
not only was the topic the most interesting one on the
whole conference (and judging the real long applause
he got the other participants felt the same) but
the presentation and the style where excellent as well.
the only issue i have is:

no, not that the performance of contextR is
horrible (that will be hopefully fixed)

no, also not that some constructs are missing for doing
AOP in a more pleasing way (a pointcut language
and the like wouldbe really good but that is easily fixed to)

no the issue i have is: that kid is as half as old as i am - but
at least twice as good as me.
man, do i feel old!
so find his presentation here

anyways i am looking forward to euruko 2006 and meeting you there again.

xml backlash

2005-10-09T16:25:00.000+02:00

code monkey is wondering why there is such a backlash
against xml in the java community recently and he asks
some questions at:
http://jroller.com/comments/coderant?anchor=another_xml_monster

to answer the easiest question first: no!
nobody expects you to code all those declarative things in java.
that be complete madness.

but fact is that xml is and has been abused way
to much in the last few years.
often this is not necessarily an issue of xml but an
issue of the api design that exposed thru the xml.
ejb and its host of xml files are certainly the showcase for it.

poor api design

usually the real issue is that those APIs are created with
no simple and useful default settings. so one has to specifiy
a host of xml elements and attributes.
that is certainly a reason why ruby on rails is gaining so much
traction: usefull defaults where RoR tries to deduct from context
a lot of information and of course that ruby is an
extremly nice language too :-)

it is a difference if i can specify a simple persisten class as


class Foo < ActiveRecord
end

and be done or if i have to write


<hibernate-mapping import="false">
  <class name="Foo" table="FOO" schema="myschema">
    <id name="id" column="id" type="string">
      <generator class="uuid.hex">
      </generator>
    </id>
    <property name="bar" column="BAR">
    <property name="baz" column="BAZ">
  </class>
</hibernate-mapping>

actually there is nothing that forbids hibernate (or any
other project) to have a set of well defined and
documented defaults that in the end would allow
for something like this


someHibernateManager.registerSchema("myschema");
someHibernateManager.addClass(Foo.class);

no hbm files what so ever.
if you for example now refactor the property "foo" to
"foobar" there is exactly one place to go. thats it!
alas this is no blog entry about hibernate - so lets
move on.

no breaking up of config files

the second issue is intrinsic to xml (or has been at
least until only very recently):
there where no defined ways to break up ones configuration
files into small and easy to handle packages. that usually
lead to having to build some sort of pipe designs
in order to merge the small config files into one before
being able to consume it.
all of this is of course doable. and i have done it more
than once .
finally this year XInclude has arrived. but of course only
very fresh and new libraries like XOM 1.1 support it.

no escape from the "declarative way"

sometimes (often?) defining something declarative
is simply not enough. not only once in my projects
the need arose to have for exaple a simple "IF"
contruct (and belive me where an IF lurks a WHILE
is hiding very closely).
lets see the hibernate conf file again


<hibernate-mapping import="false">
  <class name="Foo" table="FOO" schema="myschema">
    <id name="id" column="id" type="string">
      <generator class="uuid.hex">
      </generator>
    </id>
    <property name="bar" column="BAR">
    <if expression="deployment_server.name == 'TEST'">
       <property name="baz" column="BAZ">
    </if>
  </class>
</hibernate-mapping>

so you suddenly have to implement more or less a
fullblown programming language on top of your own
mini configuration language.
aah, i could use XSLT! sure! even more infrastructure i
have to build so that every config file is first
correctly preprocessed before being read and interpreted.
besides that writing an reading XSLT templates is
not exactly fun.

use a scription language for the JVM

so if you dont want to do your configuration in java
why dont you use a scripting language instead of XML.
i have written a bit about choosing one at:
http://yozzeff.blogspot.com/2004/12/choosing-scripting-language-for-jvm.html

your infrastructure needs will be far smaller and you
can concentrate more on the business task at hand.

of course a scripting language wont help you if your
api sucks and you expose it via jruby or groovy. then your
users will have to write loads of jruby config code and
you will experience a jruby backlash.

Choosing a Scripting Language for the JVM (Part I)

2004-12-27T16:01:00.000+01:00

So if you haven't lived somewhere in a cave for the last few weeks you might have noticed quite some discussion about the usage of languages other than java (the language) for the java virtual machine (JVM). I have been looking for a scripting language for over a year since i have quite some pains to ease.

Use Cases

My main reason for the usage of a scripting language is that i want an easy way for defining (declarative) small languages.
usually the response to that request is: why don't you use XML?
Actually our modest sized project (100k+ LOC java) is using XML (120k+ LOX) for that. And honestly it sucks! I had enough! I can't stand it any longer!
It hurts my eyes as well as my brain.
XML lacks (at the moment) any decend way for breaking up huge files into components. XInclude has been finalized only last week and there will be no implementations for quite some time (yes i know about elliots XOM, but that would force me to rewrite a great chunk of our existing code base)
XML lacks a variable concept - no really i don't want to solve that problem by using a even more complex and verbose technology (XSL).
And finally sometimes it is necessary to have an escape route out of the declarative approach. Again XLST is no solution to that.
So what i want is:

A concise syntax

Declarative look & feel

Variables

A way to modularize files

Fallback to a procedural way of definition instead of declarative

Let's have a look on an example of what i want to do:



foo = "AFOO"

bar = "BAR"



Parent

  child(foo)

  child("a_new_foo")

    grand_child(bar)

    include("/foo/bar/module1.mod")

  child("something different")

  include("/bar/foo/module2.mod")

Indention is important here as it describes parent-child relation ship. Include would mean expand the content of the file referenced right here.
So which language would be the best (nearest in syntax and semantics)?

Contenders

there were 3 contenders for a scripting language i was looking at

Jython

Groovy

JRuby

Of course there are quite some more languages for the JVM

Choosing a Scripting Language for the JVM (Part II)

2004-12-27T13:53:00.000+01:00

Jython

Actually i wasn't realy looking for a new language because i already had one: Jython.
Python and Jython are incredible fun to work with and i was enjoying hacking it every single time. But at the end of last year i had my very doubts about the future of jython. The last real relase has beed done at the end of 2001 (v2.1) and a alpha release has been done at the mid 2003 (v2.2) and then there was not very much volume on the mailing lists for the last 18 month.
All of this seems to change at the moment as Samuele seems to be close to a beta release for a Jython 2.2 and the email volume seems to have uncreased as of late.
But then again python lacks a features that i definitly want for my scripting language: it should lend itself rather well for the creation of small (declarative) languages. In short: P|Jython syntax is to complex for defining a concise language. This sounds sort of ridiculous as python has certainly the most concise syntax one can imagine. But the lack of a simple closure syntax or a macro mechanism makes defining languages on top of python a rather painfull exercise.
As long as you stay purely declarative it works somehow thou its errorprone if the users of the new language do not know about python. The above example might look like this in jython:



foo = "AFOO"

bar = "BAR"



Parent = [

child(foo),

{

  child("a_new_foo"):

  [

    grand_child(bar),

    include("/foo/bar/module1.mod")

  ]

},

child("something different"),

include("/bar/foo/module2.mod")

]

Actually python syntax leaks to much here. To many commas, to many brackets and braces. If you dont know what a list is in python and what its syntax is you are lost. And you have no easy way to escape. What if you like to have module1.mod included only on a certain condition?
Using the decorator syntax for Python 2.4 it gets better but not very much.



foo = "AFOO"

bar = "BAR"

child="child"

parent="parent"



@closure

def parent():

   @closure

   def child(arg=foo): pass

   @closure

   def child(arg="a_new_foo"):

     @closure

     def grand_child(arg=bar): pass

     def include(arg="/foo/bar/module1.mod"):pass

One could write a decorator function that executes a function directly after definition and which examines the argument declaration and builds up a tree
representation of the multiple functions. But to be honest: this is far to much XML alike.

Groovy

Groovy was very much all the hype across the first half of 2004. I fell for the hype to. Well its not all hype. Groovy has some interessting concepts to it. And to be fair. Groovy's AntBuilder and examples made the need for closures very much evident to me. And i very much like the way optional typing is planed.
But than again Groovy has a host of really serious problems which simply forbade it to introduce it into production system:

It's creators focus|focused far to much on saving keystrokes. This very often opened hard to solve syntax errors as it is not clear if the compiler and programmer speak the same language

Error reporting consists largely of java stacktraces

Groovy tries to be to many things at once

There was a long period where development stalled

To be fair things seem to improve right at the moment. A lot of syntactic (and therefore semantic) problems are worked on (thou results have not been
published entirely yet). There was a new beta a week ago and a lot of stacktrace issues seem to be solved.
Nevertheless i remain a sceptic right now. Groovy is far to perlish for my taste and i am still not convinced that all semantic issues have been resolved.
Maybe i am going to revisit Groovy in 6 or 12 month time from now. Meanwhile i have chosen the language i am going to use for now:

JRuby

Lets explain my selection of JRuby with the example i used at the beginning



foo = "AFOO"

bar = "BAR"



parent do

  child(foo)

  child("a_new_foo") do

    grand_child(bar)

    include("/foo/bar/module1.mod")

  end

  child("something different")

  include("/bar/foo/module2.mod")

end

This is as concise as I like it (you can even replace do and end with braces) and I can easily escape to imperative style if I need to.



foo = "AFOO"

bar = "BAR"



parent do

  child(foo)

  child("a_new_foo") do

    grand_child(bar)

    if arg[1] == "X" then

      include("/foo/bar/moduleZ.mod")

    else

      include("/foo/bar/moduleX.mod")

    end

  end

  child("something different")

  include("/bar/foo/module2.mod")

end

Of course JRuby has its own host of problems:

The development of jruby has stalled for over 2 years. But in march version 0.7 was released and version 0.8 is imminent any day.

Two-way-integration with java is still weak. Meaning if you use JRuby by executing it from your java program there are some workarounds you have to apply. But again java-integration should be improved very much in 0.8.

There's almost no documentation. I will try to improve that.

So lets see how my decission works out.