Real time is a special application domain. I am not sure that most people want to work in this domain (I did for several years with VMS and a power utility).
As for start up time for small utility commands I disagree, this is something that could change if we start to use the hardware a bit more wisely one day. I work with Ubuntu and all my frequently used tools are copied to RAM (/tmpfs) at boot time. My Java environment is there, Clojure, Eclipse, frequently used librairies... On top of that there's a daemon running to spot my frequently accessed files and serve them from RAM transparently. It takes me less than 1.3 secs to get the REPL prompt. Combine that with the approach of having a Clojure server in the background and that's it. Server is not there ? It gets started automatically in less than 2 sec. and runs your stuff, it's already started ? Well, it runs your commands immediately. Ok, I have 6 gigs of RAM and a quad core (Q6600) and disk mirroring but I cannot consume more than 60% of the RAM and 10% of the swap space. I run Oracle server, ActiveMq, Terracotta2, two copies of Eclipse most of the time and our application services on my desktop concurrently. As to how I can get this machine down on it's knees begging me to stop, well I did not find a way in my day to day work yet. With a dual core and 3gig of RAM at entry level prices, there are no excuses to have a slow environment. You just have to figure a nice way to use the power at your disposal. I am always ashamed when I see the kind of desktops developers get from their employers. I saw many sites where developers have desktops not more powerful than the average office user. That's poor planning. The time spent waiting by the developer after the hardware is a significant hidden cost but it seems that no manager wants to tackle this issue and defend a wiser buying strategy to get power where it's needed... no top executive needs a quad core desktop with tons of RAM. On one project just by changing to this Ferrari, I shrank the build->restart-application->ready to test cycle from 90 seconds to 8. When I started to code, computers were less powerful than the standard pocket calculator but we were doing a lot my designing accordingly. It's far more easier today given the amount of resources we have.... Luc On Fri, 2009-03-06 at 10:39 -0800, Dimiter "malkia" Stanev wrote: > Clojure is not good for: > - Real time application development, due to the JVM being soft-real > time. For example it can't be used for high-performance video pc/ > console games, but it could be used for lots of turn-based games. Then > again anything done with XNA on the XBOX could be done with Clojure :) > (XNA is some form of Compact .NET for the XBOX). > - Writing small utility programs, as it requires certain things to > be installed properly (For example using "java -serever" with the > correct JVM). For example I can't see myself deploying small utility > application at work written with Clojure, as it would make people > screaming, why they have to install this and that. That won't be the > case with big and important application (noone would mind the hidden > JVM that I might put along with it). > > On Mar 6, 5:15 am, Joshua Fox <joshuat...@gmail.com> wrote: > > Is it fair to say that Clojure shines in algorithmic processing, string > > processing, concurrency management, but that there are better choices in > > other areas: > > - "Application" programming , where the key challenge is fitting a standard > > three-tier application to the business domain. > > - "Enterprise" programming, where the challenge is gluing together > > overweight and fragile libraries, and one should always use exactly the set > > of software which the API creators envisioned? > > > > Rich himself has suggested something along these lines, but I wonder what > > others think. > > > > Joshua > > > -- Luc Préfontaine Off.:(514) 993-0320 Fax.:(514) 993-0325 Armageddon was yesterday, today we have a real problem... --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en -~----------~----~----~----~------~----~------~--~---
