Hacker News new | past | comments | ask | show | jobs | submit | wukix's comments login

Did you reach out to me when you were using mocl? Surprised to hear this. AFAIK most users get up and running w/o much trouble.


Not Clojure, but Lisp for iOS/Android/OSX: https://wukix.com/mocl


Sorry if the documentation is lacking; you can put anything you want in an attribute. Defattributes is simply a convenience macro that defines validation functions (as well as row getter functions) that you can use if you want, or not.

Generally SQL parameterization interfaces (in mainstream languages) involve syntax like:

  execute("SELECT * FROM FOO WHERE BAR = ?bar AND BAZ = ?baz", {'bar': bar, 'baz': baz})
At best you have something cleaner in languages with string interpolation, but the use of string interpolation itself is debatable. I stand by the claim that those approaches lack elegance, but if it's really "SQL Interface 101" to do it better, please share some examples. I'd be curious to see them.


Non-lispers don't always realize that more parens can actually be a feature :)


Lispers don't always realize that too many parens/brackets is a code smell in almost any other language. It makes people unnecessarily wary of (stuff (like 'this)).


Its().just().the().same().for().us().lispers().abstractFactoryFactory()


And I wouldn't want to write sql like that ;)


Why not both?


Quasiquote is going into Java 9.


I dunno. If I have a "complex" condition with more than two parts to it, I prefer to be liberal with parenthesis, rather than expect any future maintainer to remember all the operator precedence rules.


LambdaLite creator here. I just wanted to point out, in case it is not clear, that LambdaLite doesn't really introduce a new query language per se. The syntax is just "write any Lisp code you want" because actual Lisp closures are used where expressiveness is needed. Hopefully, this means the learning overhead is actually less: instead of needing to know both Lisp and SQL, you only need to know Lisp. (Disclaimer: obviously there is still an API to learn, but that would be the case with any SQL client library too.)


Since we're on the subject of floating-point numbers in Lisp/Scheme: https://wukix.com/lisp-decimals

This uses the Lisp ratio type in place of floats, to avoid the usual float issues.

ntoronto, any thoughts?


ratio's are good to have in any language, or as a library, but surely it's slower, and more memory is wasted (also hard to argue about how much exactly), and it still has to settle at some approximations for irrational numbers like PI which is used quite a lot when floating point numbers are (or at least in my experience).


All correct, for exact rationals. Racket's exact rational arithmetic tends to take about 1000x the amount of time floating-point arithmetic takes to compute similar functions, and creates a lot of garbage on the heap. It gets worse, though: with long-running computations, exact rationals' numerators and denominators tend to grow without bound, unless you explicitly round them to a fixed precision. If you take the latter path, you might as well use bigfloats, which wrap MPFR's multi-precision floats, and are faster.

Just looking at the Wu-Decimal page, though, I can't tell whether they're internally exact rationals or base-10 floats. If they're base-10 floats, they have all the same issues base-2 floats have. If they're internally exact rationals, I wonder what they do for division, which the set D isn't closed under.


Wu-Decimal uses exact rationals (they aren't base 10 floats). Division works according to normal Lisp semantics, since the CL ratio type is used for arithmetic. Let's say you divide something by 3 and now you have infinitely repeating digits: then it is no longer in set D, and Wu-Decimal no longer considers it to be of decimal type. Instead, it is treated as a fraction, again per standard CL semantics. The "Printing" example tries to clarify this (notice that 1/2 prints as '0.5' but 1/3 remains '1/3').


I've monkeyed with a lot of numeric representations, and every one of them involves tough theoretical and practical trade-offs. Returning an exact rational as the result of division sounds reasonable.

My favorite representation so far pairs a signed float in [2^-512,2^512) with a signed integer to extend the exponent range. The idea is to avoid overflow and underflow, particularly when multiplying thousands of probabilities.

(On average, adding a few thousand log probabilities or densities and then exponentiating the sum yields a number with about 9 digits precision. Worst case for adding log probabilities and exponentiating is about 8 digits precision, and for adding log densities it's 0 digits. Multiplying the same number of probabilities or densities retains about 13 digits in the worst case.)


If they're base-10 floats, they have all the same issues base-2 floats have

Nitpick: although base 10 floats have similar issues related to being of limited precision, they are superior to base 2 floats in the aspect of representing decimal numbers without the binary approximation: e.g. 1/10 is nonrepeating as 1.0 x 10^-1 but infinitely repeating as binary, so for IEEE 754 binary32 you get 1.10011001100110011001101 (1.60000002384185791015625) x 2^-4.


Yes, but they're about as bad for representing base 12 numbers, so it evens out.


I am the founder a developer tools startup and I've thought a lot about the future of programming. To be honest, the developer tools market is extremely competitive ("everything must be free") and it is not for the faint of heart. That said, if anyone wants to chat sometime in the Bay Area about future dev tools and/or startups around them, I'd be happy to meet. (contact info at https://wukix.com/contact)


Hi Wes! I enjoyed your talk on Mocl at the Bay Area Lisp meetup last year.


Thanks! I hope there is another BALisp meetup soon. The recent Parallac thing was cool, although it clearly needed more Lisp :)


Lisp is another option: https://wukix.com/mocl for iOS, Android, and OS X


the language is so fundamentally good -- Mature, robust, standarized, performant, compiled, gradually-typed -- that it is worth sticking with it, it is worth working to expand its ecosystem

This is why I created https://wukix.com/mocl. CL has a ton of merits. It's unfortunate that people pass over CL because it's "old" or whatever (a worthless criterion if there ever was one). The language is great, and with a little house cleaning, CL can seriously kick ass.


Wow, I haven't seen the licensing model to use a language in a while. Many researchers are migrating away from MATLAB for that reason, and new projects are often not initiated in MATLAB unless it incorporates legacy code. How's this business model holding up?


Nitpick: It's not licensing for a language, it's licensing for a specific tool. Common Lisp itself is not proprietary (having a standard) and code can be portable across implementations.

To answer your question, I would say that the business model (of charging for licenses) is fine in principle, but developer tools is a very difficult business to be in.


Have you considered a student price, I like the idea of having CL on my phone (and eventually tablet) but the price is a bit step for me (and presumably other students) especially to get source code access.


That looks pretty cool. Did y'all reimplement Common Lisp, of take advantage of one of the BSD-licences ones?

Is your focus primarily on OSX/iOS, or equally on Android?



Join us for AI Startup School this June 16-17 in San Francisco!

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

Search: