on Eiffel

i've been messing with eiffel for the past week or so.

i think i like it, but i'm not sure. it is a substantial improvement over C++, but i'm not sure that's saying much.

getting used to eiffel has proved unsettling. i know a lot of languages coming from various design philosophies, so i didn't expect that i'd find it so jarring. it made me very aware that the languages i use regularly sharing some level of algol blood all look like C to one degree or another (in terms of nomenclature and syntax). perl and python and c++ all look roughly like each other if you squint.

on the other hand you have languages like APL and J which are easy to accept on their own terms because they don't look like much like anything else: you expect they'll be different.

eiffel though occupies a curious position [1]: even though i have experience with pascal and it's ilk, i found myself fighting to write C code (or C++ or python or perl code) in eiffel. i guess i couldn't decide if i wanted to dislike the language because of its resemblance to pascal and it's pedantic attitude ( not quite all the power of C along with lots of padding and helmets and gloves and disclaimers ) or to think of it as a tool providing features which naturally lead to software-engineering best-practices (ie it's not just C for the complete klutz like pascal). i decided to try to adopt the idiom rather than trying to fight it (certainly i would scoff at anyone trying to write C code in lisp).[2]

so i think i like it. especially for writing any code which is complex enough that you would want to sit down and design. [3]

regarding different languages, i like lots of different ones. this is sometimes distressing because i feel i should have a favorite that is 'best' and that i use for everything. but that's dumb. some are useful for different things (matlab v C), and some are useful for the same thing (python vs perl). i think all other things being equal (and i have the choice) sometimes i just want to write something in python or lisp or C depending on my mood or for a change of pace. and i think that's cool

so observations about eiffel

• arrays starting from 1? dammit i spent 10 years in school to learn how to count from 0 and now you want me to count from 1? (matter of taste, but dijkstra showed that counting from 0 is in general more consistent. also screws with implementing numerical algorithms ; going against common practice increases the possibility for confusion though). (i bet there's some way to change this, since there is no special array syntax)

• this 
     PROGRAM is do 
  	my_pants
  	hmmm_some_iteration_might_be_nice
  		iterate
  		end --
          huh
          yeah
     end --  program
  

  huh? i thought we all agreed that cobol is silly.

  (NB that code is a parody)

• one class per file? are you some sort of nazi?
• pre/post conditions - cool
• you don't need parens for an empty arg list in a funcall...uhh how am i supposed to know it's a funcall? maybe if i start all the function names with '&'
• !! is the new 'new' operator? so now you decide cobol *was* silly? also, saying bang-bang is fun.
• locals declared in separate section? you're not my real father! *run to room slam door* *CRY*

• 'functionname is do ... end'

  oh so that's where all the extra understood verbs from latin ended up.

• /= is the new != ? 9 out of 10 cool kids agree: != is !=
• explicit short-circuit boolean ops ('and then', 'or else') interesting, but a bit chatty.
• := assignments: it's a pinky workout!
• the compiler is not the gcc (which we know and love).
• easy C usage ... cool
• hmm the docs suck (they aren't organized well)... i guess i need to buy the book.

• 'inspect foo when... when... else... end '

  ohh someone had their thesaurus handy. (though the switch and case of C never made any particular sense to me)

• compilation looks at the entire program at once (which can do much better optimization of functions etc) -- yay, no more suffering the run-time inefficiencies of C to make writing code easier.
• no header files: but how am i going to remember the members of my class if i don't type them out twice?
• etc...

1. i remember seeing a well circulated story on research showing that people find it easier to react positively towards visual representations of people if those representations are either completely unlike people or really close to people. however, those visual representations which occupy the middle ground of that continuum are more likely to elicit negative reactions.
2. even though i still harbor some of the real-men-use-fortran attitude towards pascal, the punks in CS intro class who kept wanting to point out they knew C and complain that this is how things were done in C and why are we learning a useless language like pascal really annoyed the piss out of me: the class was in pascal, get over it.

3. people calling themselves software engineers should be beaten daily. also i'd love to hear this out of an architect, "i would use it for any bridge that is large enough that you'd actually want to sit down and design it on paper first". i'm not trying to make an analogy or a point about programming (i like to hack and i think its ok though somtimes i miss noticing when a hack is big enough to require some planning and i don't know off hand how to do it). i only want to say 1. software engineers don't take the PE test and 2. taking statements from one context and putting them into another is sometimes funny.

4. i *heart* run-on sentences.