tecznotes

Michal Migurski's notebook, listening post, and soapbox. Subscribe to this blog. Check out the rest of my site as well.

Jan 23, 2005 5:22am

on development frameworks

I've been following the chatter about Ruby On Rails for the past few months with some interest: I'm primarily a PHP developer because it's the first language I learned in any serious capacity, and has continued to serve me well for five years running. My ears always prick up when I hear about someone's favorite development environment, so I occasionally buy books on topics like JSP, Python, or even Lisp to keep myself informed on what I've been missing out on, and whether it's time for a switch.

Today, Jason at 37Signals posted a pithy response to Geert Bevin's criticism of RoR, and I feel as though something may have been lost in the shuffle. Geert makes two good points about development frameworks:

It's utterly ridiculous to compare how long it took you to bash a simple application together. ... I think that driving a web application from a database structure is totally backwards.

...which reminds me why I always seem to stick with PHP, no matter how good the books I read sound. RoR's breathless evangelism shows how fast and easy it is to write a web application, but glosses over two reasons that I shy away from frameworks-du-jour:

  1. Frameworks are often advertised on the basis of their design philosophy, and seem to promise that this will effortlessly translate into elegantly-architected applications. Not so: any framework flexible enough to handle all the potential situations in which it may find itself will also be flexible enough to support terrible design decisions on the part of its users.
  2. Design is what happens after a framework or environment has been chosen. PHP is often derided as a primitive or childish language, but I've found it flexible enough to support pretty much all the weird stuff I need it to do with a minimum of fuss, which includes building personal frameworks not unlike RoR.

If I were man enough, I guess I'd be a Perl guy.

March 2024
Su M Tu W Th F Sa
     
      

Recent Entries

  1. Mapping Remote Roads with OpenStreetMap, RapiD, and QGIS
  2. How It’s Made: A PlanScore Predictive Model for Partisan Elections
  3. Micromobility Data Policies: A Survey of City Needs
  4. Open Precinct Data
  5. Scoring Pennsylvania
  6. Coming To A Street Near You: Help Remix Create a New Tool for Street Designers
  7. planscore: a project to score gerrymandered district plans
  8. blog all dog-eared pages: human transit
  9. the levity of serverlessness
  10. three open data projects: openstreetmap, openaddresses, and who’s on first
  11. building up redistricting data for North Carolina
  12. district plans by the hundredweight
  13. baby steps towards measuring the efficiency gap
  14. things I’ve recently learned about legislative redistricting
  15. oh no
  16. landsat satellite imagery is easy to use
  17. openstreetmap: robots, crisis, and craft mappers
  18. quoted in the news
  19. dockering address data
  20. blog all dog-eared pages: the best and the brightest

Archives