Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Come on, man. If you're doing something worthwhile, it likely takes 2-3 months (if you're lucky) to just understand the problem. Common Lisp is an amazing language and development environment, but it won't help you actually solve the problem any faster, only to implement the solution. No silver bullets and all. I love Common Lisp, but the whole "code this in a weekend" thing has got to stop. Good software takes a damn long time to develop in any language, because the language isn't the bottleneck.


Right, however don't forget there is a continuum of software types. The great majority of the code I write is customization of previous software for a new client. If you write enough business software, you will find out there are about 5-10 main components that they all have, and each new project differs only in how they're assembled, and the per-client business rules used to orchestrate them.

For example, it took me months to implement a decent RBAC system in CLOS; prototyping it literally took hours, just reading the wikipedia page. However, I had to refine that after every client, not just customizing it for the client, but iterating over it to make future customization unnecessary.

Billing, accounting, collaboration, knowledge management, human resources, lead management, CRM, inventory, etc. Do web-based implementations of those for a year and you will end up with the core necessary to ship any business software product in a very short time, assembling from your own repo. Augment that with web APIs (which I happily pay for) and you're there.

Another thing that I have become expert at is using other people's software. I am a hopeless cliki addict, mainly because I rarely code to scratch an itch; I have been writing Lisp code for years now, and for the last year, that's what I did full time :-) I have come to know huge libraries so intimately, including their quirks, that I can patch together something fairly quickly and get it out of the door.


That first 80% always takes only 20% of the time, and that's the first month for you. Some languages seem to let you do that month of work in three weeks, or two weeks, or with a framework it might take a week. But that last 20% is the part that always takes 80% of the time, and it often seems like whatever language you use, there are always the same, small, insidious errors and tweeks that need to be done.


Sure, there's some hyperbole in his post… but don't underestimate the ability of good technology and a REPL to aid you in actually understanding the problem, or the available technology, or how you might solve it.

As a recent example, I find Clojure's REPL to be invaluable when wrapping my head around Java libraries. The features of a Lisp make sketching and exploring easier, and that's part of understanding the problem.

I forget the exact quote, but it's something like "I never learned to see properly until I tried to draw". Pertinent.


I agree with both of you. Mahmud at that point was talking about all those projects that aren't worthwhile, by your (our) crazy definition.

Edit: but yeah, the "coding over a weekend" thing annoys the hell out of me too... but that's orthogonal to Lisp.


I worked 8 months on a small-business management package in MFC/C++ using the "RAD" Visual Studio 6. That was the last piece of major code that I have written in something other than Lisp. Immediately after that, I wrote a similar package in CL with a web-based interface, using the free allegro serve; this one took me about a month, though it was functional after the first week.

I know what you're thinking; the previous project gave you the hindsight necessary to implement the second so quickly. Well, not really. The stuff I did in Lisp where things that have been on my requirements for the first project but was never able to implement without huge investments in time. MFC is the most brittle, most fickle and fidgety POS of all time; it generates the boilerplate for you and it expects to you to use its skeletons just the way they are. It took me months to experiment with the various data access APIs, ADO, DAO, and ODBC, moving from one to the next as problems arose, and each change of backend requiring a complete code overhaul.

Now I write database code in native idiomatic code; I can change the backend with a feature. I would sometimes forget to #+postgres on deployed code and find everything working but not see any change in the postgres logs, just to realize I have :sqlite3 pushed into my features ;-)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: