Older blog entries for async (starting at number 110)

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.

You owe it to yourself to read these entertaining spams i received a few weeks ago.

for added fun and amusement i suggest doing a google search for this guy's other pages and reading them.

kaeru :

hi, i noticed your article on creating and applying patches. it looks helpful. one issue though: the output you show isn't a unified diff.

the output i get for your example is:

--- db.py       2004-05-20 05:46:43.000000000 -0400
+++ db-mod.py   2004-05-20 05:46:53.000000000 -0400
@@ -1,13 +1,13 @@
-        from pyPgSQL import PgSQL
+       from pyPgSQL import PgSQL
  
         ## note this code is for demo only, don't follow it :)
  
         def initialize():
             try:
                 db = PgSQL.connect (host='localhost',database='test',user='kaeru')
-            except connectionFailed:
-                print "This is a useless exception message and won't help you."-            return db
+                return db
+            except StandardError, detail:
+                print detail
  
         def getPlayers():
             db = initialize()

the unified meaning that both the added and removed sections are shown in the single listing.

unless i'm missing something.

you might consider expanding a bit on the -p option if you have time, since it gets a good amount of use.

thanks for the article; it's always good to have links to give folks on basic skills sorts of things.

elanthis: oh, i think i understand how you mean now. yeah i'd be interested to hear how that would be handled. sounds like funky graph theoretic stuff. maybe by keeping track of depth; it would only be a heuristic though.

elanthis :

some quick thoughts on your post.

you are thinking too much in the mode of C/C++:

if you want to signal that you have searched and not found an object you could return a pointer to the NULL *object*, for example (as in python, None). what good is that? well accidently using it may still be an error, but not one that will go unnoticed as can happen so often in C (with invalid references, not NULL ones, but the point would be that you couldn't have a pointer that is invalid here.)

as far as not having cyclic references, it would be enforced statically (at compile time). ie no expression where you create two strong pointers from one would be allowed. (not in C where you can turn a pointer into an int or have pointer aliasing).

doing garbage collection and handling scripting languages, you'd make the memory manager/allocator hold the strong reference i would guess.

i'm not saying that any of these are good suggestions, or that the ideas are good (though they are interesting); i'm just pointing out how you might do them.

yay i made new softwares:

rsvn is a wrapper for subversion which associates shorter and more easily typed names for repository URL's.

here is the web page: http://arcsin.org/softwares/rsvn.html

Join Ross

"Grab the nearest book, open it to page 23, find the 5th sentence, post the text of the sentence in your journal along with these instructions."

please don't turn this into livejournal. if i understand the purpose of the game correctly, it's to be able to say something when you have nothing to say. which is why you get all sorts of quizzes and random tasks like seeing what chain-restaurant appetizer you are on places like livejournal: many people there (and who use weblogs in general) don't have anything interesting to say.

i/we probably aren't so much above that level, but we can pretend.

at least make it an interesting or at the very least creative task or challenge, like perl golf, or using gimp to manipulate some piece of fine or pop-art into social satire.

citeseer

it seems it is fixed; yay!

HOLY SHIT THEY FUCKED UP CITESEER

hp says:

In the meantime though, to me it looks increasingly like we need to go down the road of Python, XPCOM/UNO, GObject introspection, and other half measures; ....

i'm glad that people are leaning in this direction.

one issue that is bothering me with regard to java and mono:

java and mono are desirable because they make programming software easier in many ways. this is mainly a function of better abstraction mechanisms. both also rely on virtual machines, but this seems orthognal to the first point.

from my point of view having a virtual machine doesn't buy me anything and only adds software complexity, redundancy (with the normal toolchain), memory footprint overhead, and another set of compatibility headaches. it might be nice that you can run things on different platforms, but that has always been an option with free software.

the arguments in favor of virtual machines that i can think of off the top of my head include runtime optimization, runtime code creation, and restricted execution.

i am a big fan of dynamic languages like python, lisp and scheme that run on VM's so i don't have an axe to grind in this respect: i just don't see the benefit of foregoing mature tools that are already there to get to the point where we can say "it runs within about 10% of normal code" and theoretically it could run faster....

give me my high level language, with garbage collection, and the like happiness, and give me my neat-o virtual machines, but don't force me to buy one to get the other.

(DRAFT)
some random thoughts on gnome stuff (dunno how realistic it is):


i've been thinking more about the gnome language issue lately. 

two related issues exist here: the needs of the developers working on
the core of gnome (infrastructure), and the needs of the developers
working on applications.

the most flexibility exists with the application developers whose
choices generally affect only themselves.  they should be able to use
the language of their choice and every effort should be made to make
their lives easier (more on that later).

the choices infrastructure developers make affect everyone else, so
more caution is required.  at the same time, requiring infrastructure
developers only use C significantly increases the effort necessary to
write software and keeps them from taking advantage of higher level
language features.

therefore a balance must be struck: take every effort to make both
groups more productive without tying a large, foreign into gnome's
core (note: i don't think anyone is suggesting that mono or java be
used for the core of the platform, but i'm trying to suggest that
there is a middle ground between staying as things are now, and
draggining in mono or java).

given all this, my preference is to improve the object system, create
a convience layer for infrastructure developers, and take steps to
allow application developers to use any language they like.  (this is 
one of havoc's proposed solutions).

identifying some requirements: 

interfaces must be specified with less ambiguity:
	currently interfaces are largely defined by the C header files.  
	using C, most interfaces tend to be under specified, 
	for example:

		foo_bar_baz(foo ** arg0, blah_t * arg1, foo_t * flaz); 

	you don't know what the parameters are doing (in, out, or in/out).
	this creates a problem come time to write bindings for other
	languages, like python where if arg0 is an out parameter, arg1 is 
	an out parameter, you might find 

		( arg0, arg1 ) = foo_bar_baz(flaz)

	since we can pass back multiple values rather than use in/out
	parameters.

	an IDL or some other interface definition language would 
	be better suited.

binary interfaces should be specified: 
	this just means given an interface definition, we should 
	establish and adhere to a known set of calling conventions 
 	so that any language can call into any other language's 
	libraries (one way or another).  (this exists de facto,
	but i believe other issues must be specified).

i'm going to make the assumption that we will be using an object
oriented system one way or another.  i think this is a safe assumption.

it should be easy to subclass existing objects:
	(in order to customize behaviour and create components)

	the current gobject implementation makes it quite painful 
	to derive an object, (or create an object at all), which 
	significantly reduces the probability that people will 
	actually do it.  in many cases functionality which might 
	benefit from being made an object (and possibly reused)
	is instead created in an ad-hoc to speed development.

	under the current regime, only advanced users will do it or be
	able to do it.

objects should provide all pertinent metadata:
	ie function signatures, methods, objects, classes, etc
	(life cycle issues?)

	this helps automatically create bindings whether at runtime
	or compile time

objects should require no special effort to provide a component 
	(in or out of process)
	
	you should get corba (or whatever) bindings for free when you
	create the object (this will aid in allowing other languages
	to use it as well).  currently this is a bit painful because 
	C doesn't allow you to abstract away many of the details.
	
	one should be able to subclass these imported objects in the 
	language they are imported into (with restrictions most likely)  

	
a garbage collector should be provided (as well as a way to get around it).

life cycle/memory management issues should be enumerated and provided
	by metadata so that they can be handled (or at least warned against) 
	

the current system can provide (or already does provide) many of these
without major changes; the biggest barrier is the fact that C makes it
painful to use.  consider the case of using corba in which you have to
initilize your class's virtual method table and what not manually.

the relative lack of use by the community reflects this difficulty.

choosing from mono or java is a divisive issue, and both are in my
opinion poor choices for infrastructure work.  in both cases we tie
ourselves to something we cannot control (and it matters because unlike
C/C++, there are geniune benfits to having input to .net or java
platforms), both require a virtual machine (which don't seem to make
provisions for sharing vm's between multiple applications).  both also
represent a radical departure from what most of us (me) in the
community are used to.


D seems fits (my biases)
well, but currently compiler support is not mature (a gcc front end
for it has only recently appeared).

the compromise would choose would be a precompiler like gob2 which
will allow one to take advantage of the object system easily while
retaining C underneath.  there could in fact be several different
precompilers to suit various tastes.

the major issue is that these mini-languages must be documented and
versioned.

C++ is another possibility, but in my opinion a less desirable one
(with no further justification) .

------------------------

With respect to making developers' lives easier, there are several
issues that must be attacked.  First and foremost we must make sure
that doing the default/normal things are dead easy for a developer.
secondly we must effectively communicate what is available and how to
use it to the developers.  finally, we need a test by which we can
judge our success.

The first two points require us to figure out what developers
actually need to do and what technologies they could use to
accomplish those things.
	here's a laundry list of questions a developer might ask, or
stuff we should provide, etc:

UI:
	GUI interfaces (make them easy to build to the HIG)
	Internationalization (how?/why?/where?)
	Accessibility 
Storage: 
	when do you use the vfs layer?
	when should you not?
	what structured storage is available? when should i use it
IPC/Networking:
	how do i interact with other applications?
	how do i talk dbus or corba?
	how do allow my application to be scripted?

	how do i do DND, how do i do it right?
	how do i use mime types?
	how do i access shared bookmarks?
	how do i use the clipboard	

App Integration: 
	what does it mean for an application to be well-integrated?
	how do use the help system and browser?
	how do i install and remove my application properly?
Media: 
	what media services are available?
	how do i use them?
	how do i play audio? 
	when should i not use them? (less latency, better performance, etc)



most of these things can be done with the platform as is.  but it
tends to be hard.  if we want people to do it (if we want to make it
easier for us to do it), we have to make doing it as easy as possible
and require little or no effort to implement and get right.  for the
most part many of these features remain painful to use as a developer.

we should provide cookie cutter recipies for putting together
applications with minimal effort.  underneath, an experienced
developer should still have access to all the basic components so that
if need be they can customize or create whatever behaviour they need.


--------------------------------

how do we know when we're accomplishing what we've set out to?   
this assessment should be driven by the high level goals: 

	create a coherent and usable desktop for the user 
	create a coherent and usable platform for developers

ultimately, all technological choices should be measured against these
two goals.

these can be further divided substantially; and they must.  the easier
we understand what our goals are (and by "our" that might not mean the
entire "GNOME community", just that group that agrees on them),
the more clearly decisions can be made.

------------------------------------

many of these steps (better documentation, standardization, object
system extensions, etc) are not controversial and can be done (or
begun) today.

--------------------------------------

clearly we should all just relax.