Hi Ken Collins

Short answer: I started this project because I want to improve vim.sf.net which
was written in PHP.

long answer:

Of course I'll happily reply to your request. If you have more questions just 
ask.

I was fed up with bad template engines. Smarty, pure PHP - they all can
lead to hard readable code. My intention was to improve vim.sf.net
because I use Vim the whole day long even though I hate and love this
editor at the same time.

My goal is to add some features such as collaborative maintainance of scripts,
improve the rating system so that you have to put a comment if you downrate 
scripts
(which will provide feedback to the author) and things like this.

Now it happens that the Vim homepage has been written in PHP :(

If you show up asking for changes yelling out "I want to rewrite everything" it
may be the best thing to do at the first glance. But taking into account the 
age of Vim
and that I may switch to another editor (such as Yi) in the future makes me
think that its wiser to keep using sourceforge's hosting.
Then PHP is served by a apache module which takes less resources than a Ruby 
CGI app.
And it happens that I konw PHP well.

Seeing code like this:

  if (!$db) {
    $cache->setLifeTime(999999);
  } else {
    $cache->setLifeTime(600);
  }
  if (!$cache->start('recentScripts')) {
  ?>

  <table cellpadding="3" cellspacing="0" border="0" width="100%">
  <tr><td colspan="2"><img src="<?=$IMAGES?>/spacer.gif" width="1" height="10" 
alt=""></td></tr>
  <tr>
  // more HTML omitted

  <?php
    $cache->end();
  }
  ?>

made me want to change more than just add my features. So I started spending 
hours
on cleaning up SQL, dropping escaping GET/POST inputs so that escaping is done
where it should: At the places where SQL is constructed.

Then you can review code easily and say at the end: Yes: Its unlikely that SQL
injections take place.

Now after tidying up SQL I didn't want to continue the PHP style - which would
require every dev to think about quoting over and over again.

Its not only about the time I spend on the project. Its also about the time
people will spend after me.

I then looked for HAML and PHP, found all the libraries (open source) out
there. I downloaded them. I thought "Hey they work!  Cool".
Then I had a closer look starting my own tests:
Do they escape HTML ? Do they support != and = ?
Then almost all dropped out.
Can they be fixed ? Yes. phamlp can be fixed easily. Then I noticed that
attribute handling didn't work. Looking at the code more closely revealed why:
phamlp was using one huge (unreadable regex).

>From Ruby you know that you can't parse nested () using regex. PHP regex can 
>do this.
However this feature was not used - and can't be used in the way regex were 
used.

So it was yet another experience: Many open source PHP libs suck. Why do so 
many exist?
But why is there only one "rails" ?
I experienced that when trying to use a YAML library in the past. It only 
"almost"
worked - and I spend several hours trying to find my way through regex trying
to fix my use case.

And I ask myself all the time again: Why do employers ask for PHP coders? Why ?
Why? why? Why do they use PHP?
Use Ruby and those libs are much more likely to work.

Why is it me telling PHP coders about Exceptions? About git (or the like)

The point is: Good PHP coders (which know more than PHP) prefer those other
languages - languages which have either some typing or at least error handling
which provides try .. finally like statements - or languages supporting
closures (eg JS, HaXe, Ruby) so that you can write things like

withCache 10days {
  ...
}

rather than repeating yourself all the time.

So my haml-to-php.com targets this audience:
- users who know how it should be done but can't use Ruby or the like for
  whatever reasons.

They know the difference. And they pay $20 instead of spending days on writing
and testing a HAML library themselves.

For everyone else: Skip PHP. Go Ruby (or the like). 

Ok - I agree PHP 5.3 now has closures. But you have to list vars to be taken
into the subscope explicitly.

So no matter how you look at it: You end up writing more code taking more time.

By that site I try to get a constant income - so that I can continue work on 
projects like
http://gitorious.org/nixpkgs-ruby-overlay/ which package all ruby packages 
known by gem for 
the Nixpkgs distribution system (www.nixos.org).

I did the same for Haskell. And an experimental similar implementation exists
for Python.

I'd like to create a open source buildfarm based on NixOS/Nixpkgs - explore how
SAT solver could be used in this context and improve urweb or the GHC JS
backend...

I want to write a new job market (similar to elance, guru and the like) - but
which is more simple and which has a fair payment: some dollars only for
publishing a job.

I really don't get why coders should spend money on applying only.

However those topics all take so much time that no time is left for earning 
money.
That's why I want a regular income - by selling some code to PHP users to show
them that there is something else than what they know: It's called HAML and a
different community was using it for years ..
Maybe I should say this more clearly on the homepage.

I've only found two advantages of PHP over Ruby:
1) recursive regex
2) xdebug also works with latest PHP version while ruby-debug19 does not yet.

However 2) will be fixed somewhen and 1) could be fixed easily because
interfacing with C code is well known for Ruby programmers.

Sorry for this outburs... It only reflects some of the damage PHP did to me
overall in the past by wasting my time for many reasons.

Marc Weber

-- 
You received this message because you are subscribed to the Google Groups 
"Haml" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/haml?hl=en.

Reply via email to