On 19 October 2012 18:47, Dale Henrichs <dhenrich@vmware.com> wrote:
Igor,
"But my aims is slightly different." and so are mine ...
I think that we can agree on this point and move on...
:) i cannot agree on one point: JSON is harder to read to me, comparing to smalltalk literal syntax. This is a reason for dismissing 'human friendliness' comparison, because it is very subjective :) But what i want to repeat: uniformity has the value. When users, to read code, need to know single language, it is better than need to know 2 , 3 or more. So, unless there is no way to express meta (and other) information using same language, only then i won't argue why we need to use different language for information we store. A good example where you cannot do that is C projects, which contain makefiles, config files , and other. Out of curiosity, can you read this (exert from configure script): as_fn_mkdir_p () { case $as_dir in #( -*) as_dir=./$as_dir;; esac test -d "$as_dir" || eval $as_mkdir_p || { as_dirs= while :; do case $as_dir in #( *\'*) as_qdir=`$as_echo "$as_dir" | sed "s/'/'\\\\\\\\''/g"`;; #'( *) as_qdir=$as_dir;; esac as_dirs="'$as_qdir' $as_dirs" as_dir=`$as_dirname -- "$as_dir" || $as_expr X"$as_dir" : 'X\(.*[^/]\)//*[^/][^/]*/*$' \| \ X"$as_dir" : 'X\(//\)[^/]' \| \ X"$as_dir" : 'X\(//\)$' \| \ X"$as_dir" : 'X\(/\)' \| . 2>/dev/null || $as_echo X"$as_dir" | sed '/^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/ q } /^X\(\/\/\)[^/].*/{ s//\1/ q } /^X\(\/\/\)$/{ s//\1/ q } /^X\(\/\).*/{ s//\1/ q } ..... as to me if we take negative infinity , and then raise it to power of positive infinity, then it will be close to "human readability" of this code. But C guys have no choice: they cannot express metainformation in C.. (or just too lazy).. But with smalltalk, we can. So why we need to use weird syntax, and weird DSLs, if we can just keep using smalltalk, and benefit (greatly) from uniformity and simplicity it has? Remember the turtles? They have to go all the way down :) -- Best regards, Igor Stasenko.