I think this is looking at the situation backwards. I don't want BigInts, why should I want *them*? Nor longs or whatever for that matter. What I want is a numerical tower and a language that can handle it correctly, without blowing up, and if possible with clean code. I can type 9223372036854775807 or something bigger in a spreadsheet and get 9.22337203685478E+018, and take it from there. Now, I don't know if spreadsheet programmers *want* doubles, but something correct (if less precise) must be done depending on what *I, the user* wants to do.
Now we face the choice of putting limits on what our users can do, use a different set of operators, or decide that we "want" BigInts. Again, this isn't about wanting bigints, that's a red herring. Part of the problem is the complex, confusing, and sometimes quite mysterious Type System that's been creeping into Clojure for the sake of performance. Another is the conflicted attitude of being an untyped language: a kind of guilty pleasure with the remorse it brings of all those reflective calls and boxing/unboxing, whose negative effects on performance supposedly makes the language lose credibility. If a Type System is what it takes to establish Clojure in the server/ enterprise market, maybe this is be start of a family of languages, with one simple and elegant and another pragmatic and subordinated to the demands of business, a la Microsoft C++ with COM or something that ugly. On Jan 15, 8:48 am, Lee Spector <lspec...@hampshire.edu> wrote: > On Jan 15, 2011, at 8:29 AM, Saul Hazledine wrote: > > > It would help people like me understand the debate if some mainstream > > examples of applications requiring (seamless) BigInteger support could > > be identified. > > I doubt that many will consider this "mainstream," but I evolve programs > using genetic programming techniques and I've found that in this context > BigIntegers can arise in all sorts of unexpected and weird and wonderful and > sometimes adaptive ways. > > I still haven't figured out exactly what the 1.3 changes will mean for this > work -- maybe it'll be fine or even better -- but I've liked not having to > think about integer sizes much at all previously (as in Common Lisp, where > the handling of complex numbers is also nice). > > -Lee -- 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 Note that posts from new members are moderated - please be patient with your first post. 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