Everything sux

Wednesday, August 25, 2004

Java non è figo

Affermare che Java non sia figoso significa dire che la gente preferisce sparlarne piuttosto che usarlo.

Ciò ha sicuramente ragioni sociali ('è molto diffuso') che ovviamente non ne giustificano i difetti ('pure internet explorer').
La non figosità di java sta nel suo essere pensato per essere un semplice passo in avanti dal C verso LISP(citando g. steele) per l'utente mediocre.
Non si intenda che tutti gli sviluppatori java siano mediocri o che lo sia il linguaggio in se, ma solamente che il linguaggio possiede una serie di meccanismi (sintassi più che prolissa, assenza di funzionalità, libreria standard strutturata in un certo modo) pensati per limitare il modo di pensare dell'utente. Concettualmente non si è poi molto lontani dal monomorfismo del Pascal.

Questo è quello che rende java non figoso.


Inoltre il codice java potrebbe facilmente essere più leggibile. L'autoboxing potrebbe essere fatto meglio, si potrebbe omettere qualche dichiarazione di tipo o permettere l'overload degli operatori e molte altre cose che lo renderebbero più leggibile.

E per aggirare le mancanze del linguaggio (ad esempio il MMD) si deve scrivere molto codice che non aggiunge nulla alla funzionalità del programma, ma serve solo a renderlo più oscuro.

Se proprio si ama la jvm con annesse librerie, strumenti etc etc etc Io consiglio Nice (nice.sf.net).

Sunday, August 22, 2004

Perl6, Intercal, and how everything is one thing

Dan Sugalsky is a man you can trust to find strange stuff.

Given that he is the architect (or designer or leader or Project OverLord or whatever is the word more en vogue in the computer industry today) of the Perl6 VM, you can bet that strange stuff will appear in it sooner or later.

I mean, having a brainf**k interpreter was nice, everybody loves brainf**k.
But this thing is cooler: Given that perl6 will have multimethod dispatch, parrot will have MMD too. And they can do MMD on the return value of a function too. And this mean they can easily do Intercal. Ph34r P4rR07 l337Z0Rz

Saturday, August 14, 2004

PHP problemi infiniti

Per qualche curiosa motivazione personaggi vari sostengono php.


Sebbene php abbia rappresentato un'innovazione nell'ambito dello sviluppo web, a suo tempo, il motivo valido per usarlo adesso è... beh.. arduo da rintracciare.

Giacché più e più volte il flame "php sux/php rulez" si ripresenta, raccolgo qua dei pensieri a riguardo, affinché siano usati dai detrattori del linguaggio come promemoria, ed ai fautori come stimolo. Nelle speranze dell'Autore, tale lista potrà tagliare nettamente la lunghezza di numerosi flame, ove questi non aggiungano nulla alle discussione passate. Parlo di php5, invero.

  1. php non ha namespace. Qualunque linguaggio che debba essere usato per un compito complesso dovrebbe fornire un metodo per segregare funzionalità diverse in spazi diversi da quello globale. PHP, simpaticamente, non lo fa.
  2. php ha un sistema ad oggetti ridicolo, in quanto:
  3. non esiste la possibilità di manipolare le metaclassi
  4. non esiste la possibilità gestire l'inizializzazione e l'allocazione di un oggetto distintamente, e numerose hot head di php non sanno neanche cosa significhi.
  5. non esiste una convenzione ne' forzata tramite sintassi ne' a livello sociale nel dare nomi a librerie, variabili, classi.
  6. Non c'è supporto per la metaprogrammazione a nessun livello.
  7. Non ci sono funzioni di ordine superiore, currying, e lambda. Manipolare una funzione in php significa fare l'eval ogni volta
  8. non c'è supporto per le coroutine
  9. non c'è supporto per directed coroutine (i generatori di python)
  10. non c'è call-with-current-continuation
  11. non ci sono eccezioni resumabili
  12. è impossibile estendere php in php (cfr tcl o lisp o in qualche misura ruby/python/smalltalk)
  13. SimpleXML è stato scritto da una manica di ubriachi. Ad esempio non è possibile gestire tag con nomi non nell'intervallo a-z.
  14. non c'è supporto per multilingualization, ovvero la possibilità di manipolare encoding vari in modo univoco. Addirittura non si possono usare encoding a più di otto bit.
  15. non esistono ne' mixin ne' trait ne' ereditarietà multipla, quindi mostruosa duplicazione del codice.
  16. hanno inventato un sistema di controllo dei tipi che avviene per ogni chiamata a funzione, ogni volta, controllando il tipo dei parametri. Vi lascio intuire che performance.
  17. lo zend engine è notoriamente un colabrodo a livello di sicurezza.
  18. php è un interprete lento, cercate sui benchmark del Grande Shootout o di scutigena.
  19. non c'è ottimizzazione delle tail call
  20. le classi non sono modificabili a run time
  21. le classi non si sa se siano oggetti, gli autori di php a riguardo non rispondono
  22. php non è completamente ad oggetti. Se pensate che non essere full OO sia un vantaggio in termini di semplicità, vi prego di postare un esempio, e ve lo mostrerò più semplice.
  23. non c'è DBC e dato #12 non si può infilarcelo
  24. per qualche strano motivo gli array sono degli hash
  25. il sistema di controllo d'accesso è antiquato
  26. non c'è un sistema di sicurezza degli script builtin (vedi #17)
  27. il sistema di type check è ridicolo per la sua imprecisione. Lo avessero lasciato completamente dinamico sarebbe meglio.

Se ritenete che Queste motivazioni siano errate o incomplete vi prego di commentare.

Java,C,C++ sux, types do not

Ok, Peter William Lount and james robertson are playing the 'oh type sux' game again.
Let me state I have great respect for both, before I go on bashing them ;)
And thid message does not imply I don't like smalltalk. I happen to prefer ruby and Slate in the dynamic/agile/buzzworld-of-the-day language world, but smalltalk rock. Now, onto the rant:


In the end, I think I understood what they mean. they mean
"I used c++ and java and was disappointed, thus static typing sux"

This is quite agreeable, I won't ever try to say it's wrong.
But it misses the point. I'd like to answer to P.W.L on his kind_of blog but comments are not allowed there. Please do switch to the cincom blog service ;P

Now, the message:

  1. I know that nil can get some messages, I just wrote wrong, so I'll skip this.
  2. the fact that you use multi type variables adds nothing to the discussion, you can have multitype variables in any non stupid static language. You can have them in perl6 too.
    This is quite easy: type mytype= sometype or niltype (see Haskell, or perl6's junctions). See, even if you don't have type creation of such an high level, you have nullable types in Nice or C# too.
  3. I ignore the C and Java rant. I agree with you.
  4. The environment is the language with ST so you get instant error-correct. The java guy use to say that IDEA does typing for them. I don't like this way of thinking.
  5. The next para is about things you can do with proper dynamic systems. I just make you notice that some static-strong or static-soft languages (i.e. Haskell and CL) do have types expressed in the language itself. This mean you can get "extensible runtime type safety validations with full semantic expressiveness of the language" at compile time. Yes, the 'runtime at compile time' is a joke, don't bother to correct me.
  6. #doesNotUnderstand: is a nice mechanic but if you look for a moment out of smalltalk (and ruby, with his #method_missing ) you may discover that almost any language allows you to write a proxy object with a one liner. IIRC even that cranky java thing has DynamicProxy to do this.
  7. "Smalltalk is a language that is highly extensible. It allows you to build your own custom language capabilities within it's range of expandability - which is much wider and thus more powerful than typed variable languages" I'm still afraid you are trying to say "then java's one". You can declare types in CL or Dylan, yet they're quite extensible, ain't em?
Mr. robertson is quite clear:
verbat,
The problem is that the cost of static typing (in terms of expressiveness and flexibility - is
higher than the benefit. Having used the common static languages (Java, C, C ) and
Smalltalk, I can tell you that the cost isn't worth it.

Perfect, agreed. Java,C and C++ are not expressive.
Does this mean 'static typing is bad? Not at all. Did you consider what I was saying? I said:
If I was going to give you a compiler that compiles all your smalltalk code *except* those that generates MNU (yet allowing it if doesNotUnderstand: is implemented)

I translate: "if we had a type system as expressive as ST's one but plus static error detection (and this does not only relates to type checking, it involves array bound checking, property assertion a-la DBC or pseudotype assertion a-la Haskell, checking for primality, oddity or the likes) would you use it?"

I would do this, and I think you would too.


Wednesday, August 11, 2004

As usual: type system debate

It's impressive how many thing people have to say about typing.
There must be a reason for this, something that relates to a fundamental need of the human being.

Anyway, james robertson, ian bicking and ryan loweLink

Are playing with the usual "oh types sux" or "oh type rulez". They're nice and smart guys so worth reading, prolly.

Btw, here is my take on this:
type do exist. It does not matter how long you're saying that Ruby or ST or Python or Io allows you to avoid them. You're just ignoring them. But in the mnomento you're writing:

sc= SortedCollection new

you're using a type. In the rest of the program you'll be expecting to have a SortedCollection.

So you're declaring a type. And then you are using that type in a conforming way, because if you don't you0ll get an exception. this extends to languages like ruby or python (or CLOS) where you can add methods to a single object. You're still using that object's type.

Now add this, what would you do if I was going to tell you "well, go on doing like this, I'll add an expressive type system that you won't even notice. It will just add safety and early catching of errors".

Now, we do not have such a type inference engine yet, but we're on the track.
Take a look at Nice or haskell. They're not there yet, but some day some language will be.

Then the congepture will be demonstrated: "dynamic typing is just an expressive static type system"



Monday, August 09, 2004

LL1 videos

This are the videos from the Lightweight Languages conference at mit in 2001.
Nice people and interesting arguments, you really should take a look at these.
BTW, it is nice that the concept of LL is getting momentum. The LL conference @ mit has a twin in Japan, the Lightweight Language WeekEnd.
I Wonder when IT in italy will be advanced enough, or old enough to get things like this.

Friday, August 06, 2004

.net guys got Coroutines ?

It does not seem so.
But at least they seem to be getting something.Iterators in C# works almost like coroutines.

Well, I hear you saying, we had coroutines in Lua for decades. Right, but at least is a good thing that some of the curly braces languages are finally getting them.

This post is a nice intro to iterators in C#. The author did not got the subtle difference beetween coroutines, semicoroutines and continuations, but well, it's a nice article anyway :)

Wednesday, August 04, 2004

PHP6 on parrot

Ok, parrot may become something really important.
Leo and Dan are killer coder, so this may actually happen.
Rasmus Leerdorf of php fame wants to go on parrot too.
He talks about php6, but I can't really think of what php6 is going to be. php5 is nowhere near innovation, and it broke enought stuff anyway. What should I look for in php6 ?

porc

putt