> > > * Browser-side AJAX-y apps, both underlying browser stuff and layered > frameworks/libraries. Developing for this is largely about cursing > frequently -- every time you're reminded that people who have little idea > what they're doing have now determined the platforms that everyone must > build upon. Not only are the platforms bad, but way in which most > developers now think about software development is a step backwards from > what it was before: institutionalizing a mixture of clerical bureaucracy > and cargo-cult kludging methodology.
I think this is basically the main advantage that Clojure has, besides the unwillingness of pointy-haired bosses to part with the JVM. The Clojure library ecosystem has a number of very powerful and theoretically easy to use libraries for web development, and you can stick to one language on front to back. The downside of this comes in the fact that all this power tends to come in the form of that most evil of combinations: heavy abstraction, plus virtually nil documentation. No one seems to document anything in the world of Clojure. You will frequently find yourself having to divine functions from source code and test examples, and nothing will ever be explained. Mostly you have to guess a lot. In that respect, I actually found just doing an old-school back-end-only app in Racket somewhat more pleasant, save for the advantages of live-reloading you get with ClojureScript's Figwheel. On the whole though, I feel your pain about web dev in general. The whole thing feels like a tower-block built on gaffer tape. I feel like the pain is largely unavoidable no matter what direction you go. On Fri, Jul 24, 2015 at 3:57 AM, Neil Van Dyke <n...@neilvandyke.org> wrote: > Hendrik Boom wrote on 07/23/2015 08:15 PM: > >> I've heard that half-life waswritten in a versino of Lisp. But the >> battles in half-life tend to be short, so they explicitly called the >> garbage collector between battles. >> > > And now HL3 is merely delayed by a *really* long deferred GC cycle? :) > > But seriously, I'm idly toying with a game idea that needs uninterrupted > smooth fast action (physics, graphics, world model, networking, > controlling) for up to 5 minutes. A multiplayer game session is longer than > 5 minutes, but is split into parts of up to 5 minutes, with brief > GC-friendly gameplay pauses between the parts, and afterwards you return to > the GC-friendly multiplayer lobby. An issue with this sort of thing in > GC'd languages is that you know you're going to have to deal with GC > somehow, and you'll have to prove viability empirically, after considerable > investment; but if you were using C/C++, what you have to prove empirically > after considerable investment is that you can do it without memory bugs. > > Neil V. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
