Everything sux

Monday, September 13, 2004

[C#] Why not

In risposta a questo

  1. pessimo motivo, come dice perlis "se imparare un nuovo linguaggio non cambia il tuo modo di pensare a che serve"?
  2. C# viene venduto da un bel po' come un java migliore. Giacché manca una confronto con, tanto per dire, VisualWorks, direi che è inutile gareggiare con un coniglio senza zampe anteriori. Ma è stupendo sapere che i .nettisti si sentono soggetti a scarsa considerazione da parte dei Javanesi. Potrebbero forse comprendere, un giorno, come si sente il resto del mondo della programmazione.
  3. Le motivazioni dei generic con type erasure sono in primis il mantenimento della compatibilità. La JVM non deve cambiare, il che significa mantenere la compatibilità con una quantità di installazioni (e di società che producono sw per la jvm o la manipolazione di bytecode) enorme. La MS non ha questo problema, il perché viene lasciato come esercizio per il lettore. In secundis (il motivo vero) il JCP non ha fatto altro che standardizzare un meccanismo già rodato da anni in Generic Java (e Pizza).
  4. Tre bis, in verità. Non si capisce cosa si intenda a questo punto. Prima si parla di conformismo a proposito di una feature che è unica in java, e per la quale lo stesso autore di C# sta cercando un'evoluzione migliore. Poi sembra ci sia una curva verso un generico "voglio fare quello che mi pare, tanto non sono sciocco" che suona vagamente come l'inno dei propositori di ruby o python.
  5. "ma vale veramente la pena costringere il mio cliente a spendere il 10-20% in più sull'hardware per poter far girare una applicazione talmente generica da poter funzionare ugualmente su Windows che su Linux o Mac?"
  6. Dipende, vale davvero la pena di scrivere un'applicazione lato server che girerà solo su una minima parte dei server la fuori? Vale davvero la pena di scrivere un'applicazione managed rispetto ad una nativa? Il simpatico ragionamento porta alla ovvia conclusione che si dovrebbe poter usare un linguaggio di alto livello, che non abbia problemi di portabilità, che compili efficentemente quanto il C.. Forse, Andrea, vuoi Ocaml e CMUCL ?

Pace e bene.

Wednesday, September 08, 2004

[ST+LISP] Problems with lisp and STrc

Stimulated from this

Python is growing. It added stuff. It will remove some, one day, I hope.

Even perl continued adding stuff for decades. Now with perl6 they will have almost everything ever thought in computer science, but IIUC basically it boils down to few concepts: objects and hygienic macros. They added and removed.

Ruby, which is a newer language, has been almost the same for ten years (It was lispish and smalltalkish from the beginning, but I think first-class class variables were added).
In version 2.0 it will change somehow, anyway. It will had some better method wrapping, maybe namespaces, and simplify other things.

But lisp and ST remained (mostly) the same. in the last 20 years.
And guess what? They did not succeed.
They just survived till now, with a small clique of people that love 'em.
C++ succeded, being that crappy mess that it is, COBOL did, and Java did.


Sure, I like ST+Lisp, I know CMUCL is faster than gcc, I know that VW is soooo much better than Eclipse, I know that "pure oo", "aop", "mmd" were ideas predated decades ago in ST & Lisp.

Yet they did not succeed.

This must force someone to reflect on why.
It relates to being so strange.
It relates to being so isolated from the rest of the world.
It relates to being too advanced for the '7o.

And in the end it relates to their very essence: Lisp and ST are so freaking mind twisting that people do not want to use them.
"wait I want!"
Sure you do, but not many people.
And they are this way because they need to be this way. This is how they predated AOP and so on.

But people want simplicity. I mean, if ST used a standard if: it would have been much more easy to understand. If there were no funny punctuation everywhere, too. If CommonLisp did not have stuff like rplacd or nconc. If variables used a more standard declaration.

Actually people want normality. They want to write
a and (b or c)
not
(and a (or b c))


And obviously they don't want to write:
Object subclass: #Foo
cause
class Foo

is so much more obvious.

What's wrong with little less purity? Nothing.
You can change things, if you're not strongly thight to a committee approved standard.
And you can anyway, see i ST, namespaces , the Morph interface in Squeak or Pollock in VW.

There are no bonus points for being the same language for 100 years. You name python decorators. They did not added a feature to the language. They took a common idiom and put it in a nice form, because people want this.
ST and Lisp answered lots of questions, just not what people were asking.

PS
ST+Lisp are still evolving imo. StrongTalk, Self, Slate, F-Script are there for ST. Not to mention the Traits paper,
Squeak's peculiarities, VW ones etc.
Goo, every Scheme's RFI, Arc and so on are meant to evolve Lisp.
The fact that the standards for SmallTalk-80 and CommonLisp do not evolve is unrelated

Saturday, September 04, 2004

[python] future problems with genexp

Yuk, you'd think that generator expressions do not break nothing.
Actually it seem they do

Thursday, September 02, 2004

I Wish I Was in Y3K

Actually I just wish I had python 3k.
As of current python 2.4 there are a lot of partially overlapping features that really should be cleaned up. Old style classes vs new style, list comprehension vs gen exp, dict.items vs dict.iteritems and so on.

And damn, there are things that are so utter stupid:


`foo`

is the syntax that almost any scripting language on earth uses too launch external commands. Ugly, I know.
Python has that too. And it means : repr(foo)
Why the hell?

Not to mention print as a keyword. Man, that is so nonsensish, but I could accept it if we did not have
print >>somefile


This, is the absurd thing. Anyway I don't even really feel assert is a good thing as a keyword, but I can quite accept it..

But, hey, did I talked about for..else ?
Yeah, I mean it:

for i in foo:
hoge
else:
fuga
What of a control statement is this? When damn the else is executed?


Well, this is quite obscure.
Luckily we can use the great

while (cond):
foo
else:
bar


Finally, not that I think this is much better but somewhat makes more sense:


try:
foo
except:
boo
else:
moo
finally:
goo

Try to guess when the else is executed. Please do not read the manual.

I guess Guido was drunk when thinking this. I mean there is no case/switch statement and there is this?

BTW I understand that you can't break all the code out there.
I just wish python was better thought out. Why introducing list comp and generators in the same release?
It is quite obvious that evryone wants gen comprehension!

Also, I really think that a simple lazy keyword could have been a better thing to put in instead of gen exp. Much more general, and useful. Several "strict" languages had something like this for a while, and it has proven useful and good. Maybe in year 3k..