"New features in LispWorks 7.0 include a Java interface and improved Unicode support. There are new ports to ARM Linux and PowerPC/AIX, a 64-bit Professional Edition, and new Editions for hobby users at lower prices. Additionally, our new products LispWorks for Android Runtime and LispWorks for iOS Runtime target 'headless' Lisp libraries which you can incorporate into mobile apps."
While there is some overlap with the new mobile portion of LispWorks 7, mocl isn't in the same league. Allegro CL would be the proper competitor to LispWorks.
I've asked their support folks whether they've plans to support mobile GUI too. I'm busy using Common Lisp to build a (hobbyist) home automation system and would love to develop mobile UIs in the same language ...
I have tested with the iOS Beta version while writing a 3D sports simulation game. I have missed these: a full object DB with a query language. Right now I use rucksack which serves my needs. Very productive to not have to deal with Core Data!!!
The other thing I miss is live edits, though using TCP sockets while having the device on the same network will work. But I don't know how to overcome iOS security restrictions which prevent compilation of new code.
Being able to write AI for a game and all game logic in CL is complete fun, as usual.
Their support folks got back to me - promptly - to say that a) they're still considering whether to provide GUI bindings, and b) that one can call the required Java APIs from Lisp, so GUIs wouldn't be too big a deal anyhow.
Good to see LispWorks still going - I used it from '89 to '95 running on Sun and DEC Alpha workstations. Oddly enough one of the projects I worked on had a user interface written in PostScript (NeWS) driven by a Lisp backend - Harlequin, the original publishers of LispWorks ended up going into the PostScript RIP business.
I second that. Many years ago I worked on their documentation in return for a little money and a discount on licenses. For customer projects it is good to have a vendor like LispWorks or Franz backing you up.
For cost reasons, I use SBCL or Clojure for my own projects.
Holy hell why is this still so expensive? 64-bit Lispworks is $3000 when visual studio professional is $1200? Visual studio community is FREE for COMMERCIAL USE in small teams! What student has 500 bucks to throw at something that can't even distribute binaries?
That's an $11,000 woodwind instrument right there, and worth every cent if you are, or aspire to be, a professional oboist.
As Erik Naggum put it:
"why are we even _thinking_ about home computer equipment when we wish to attract professional programmers? in _every_ field I know, the difference between the professional and the mass market is so large that Joe Blow wouldn’t believe the two could coexist."
Yeah but if you're a company the price of something is completely different. Maybe that server needs really excellent realtime performance for some really specific business need (finance?) I just don't understand how 500 bucks is a hobbyist price for a piece of software.
It seems that for this particular piece of software, there is no cheaper way to produce it. It's a compromise of pricing a product to keep it attractive and being able to do sustained business from the UK, where a team of developers is more expensive that in some other parts of the world.
$500 is affordable for a lot of people. An iPhone 6 costs more. A vintage Symbolics Lisp Machine just was sold for $5150, more than ten times compared to a hobbyist LispWorks license.
Sooooo ... tell me about conditions & restarts in Clojure these days ;-P
On a serious note, a good friend of mine recently evaluated Clojure and fell in love with it. Interestingly, he loves it for the same reason I didn't: the JVM.
He saw his life being made easier by great Java integration, I saw the language and tooling being hindered by having to target the JVM. I think we're both right :)
As a serious (though former) Common Lisper, I recommend you take a look at Clojure. Rich Hickey's presentations are a great starting point.
I did, and I haven't looked back — things that I thought would be complete road-blockers turned out not to be a problem at all (no CLOS, no conditions&restarts, Lisp-1, empty list not the same as nil, JVM). And there were things that made life soooo much better (concurrency primitives, STM data structures, ClojureScript, and, yes, JVM (it's better than you think)).
Even if you don't start using it, it's worth taking a look.
I didn't realize Clojure had detractors such that it's a risk to even mention it while endorsing other languages. Can't say that sort of hostility is at all interesting around here.
Yes, abandon something that's been making money for 30 years and throw away decades of domain expertise because it's not fashionable. Great idea.
Not that clojure is a bad language(I actually like it quite a bit), but compared to the professional common lisp world, it's a baby. CL has an extremely high-quality and stable specification, dozens of very good implementations for pretty much every platform(whit several ones that are decades old, and several ones that are brand new), a community that simply refuses to die, and use cases where clojure would be completely inadequate. Not to mention the assertion that non-clojure lisps are not going anywhere is completely false, both common lisp and racket(hell, even elisp) are growing in their niches and developing their ecosystems. Books and libraries are being written, products are being developed, conferences and meetups are organized, businesses are started and research is being done.
With zero snark, because I've never had the (apparent) pleasure of working with a lisp, what are the use cases for Common Lisp? It barely registers when talking about building APIs and production cloud platforms for game services, which is my current wheelhouse. Clojure comes up, of course...
1. Decision systems for stock and commodities trading.
2. Flight scheduling and flight price optimization.
3. Social network analysis and advertising impact analysis.
What all of these problems have in common is that they involve crunching a fuckton (the technical term) of data, sometimes in real time, and making decisions based on it. Some of the problems are NP complete and use genetic algorithms and other techniques to approximate ideal solutions. These are extremely hard problems.
It's also worth noting that many of these systems were started in the 80s and 90s and encode a lot of research and business logic which simply isn't yet available elsewhere.
I'd love to work on one of these systems, but unfortunately I've only been working in industry a mere decade and the competition in that area has mostly 2-3 times that level of experience.
Specific domains where clojure might not do so well are probably the same domains where the JVM is impractical, for example embedded or low-level programming, anything where you have to interact heavily with the world outside of the JVM and have a small footprint.
Obviously mobile looks like an area where common lisp has better options(with this announcement that makes two commercial implementations, the other one being mocl: https://wukix.com/mocl).
If you want to write native(non-swing) guis LispWorks has that covered, and the open source gtk/qt bindings, while a bit unlispy work very well. Racket has a pretty cool framework too.
There is also the fact that a lot of programmers, rationally, or irrationally, simply dislike the JVM. Pretty much everything I dislike about clojure has more to do with the JVM than the core design itself.
Both lispworks and franz maintain success lists, so you can look at some of these projects if you want to see some areas where lisp has done fine:
My understanding (as a Lisp beginner but with 15+ years commercial development experience) is that Common Lisp has more powerful macro systems, better tooling and better error handling. Some commercial Common Lisp implementations are also known for good, portable GUI frameworks.
Clojure has better support for concurrency, very good JVM integration, and a better story around Javascript courtesy Clojurescript (vs. Common Lisp's parenscript).
While some people seem quite strongly averse to Clojure (see e.g. http://www.loper-os.org/?p=42) my opinion - again, that of a Lisp beginner - is that they both have their uses.
It's certainly possible to build web front-ends and API-based back-ends using Common Lisp. I know because I'm doing it now :)
Common Lisp hits some kind of sweet spot for developing very specialized software. If you think you need to build huge specialized software framework or special programming language from ground up to start solving the problem, you might need Common Lisp.
Common Lisp is very programmable language that can still deliver decent speed.
They are going after professionals who have been spoiled by commercial Lisp implementations for years and decades now.
I doubt that Clojure is going anywhere with that demographic.
And I'm absolutely certain that the existing Clojure audience wouldn't shell out a few thousand dollars.
Especially since Lispworks is building a language implementation and ecosystem (KnowledgeWorks, CommonSQL, CLIM) where the IDE is just a relatively minor component.
What's New blurb:
"New features in LispWorks 7.0 include a Java interface and improved Unicode support. There are new ports to ARM Linux and PowerPC/AIX, a 64-bit Professional Edition, and new Editions for hobby users at lower prices. Additionally, our new products LispWorks for Android Runtime and LispWorks for iOS Runtime target 'headless' Lisp libraries which you can incorporate into mobile apps."
Brief release notes: http://www.lispworks.com/news/news34.html
More complete release notes: http://www.lispworks.com/documentation/lw70/RNIG/html/readme...
Price Information for customers in North America and the rest of the world except Europe, India, China (PRC) and Taiwan:
The IDE: http://www.lispworks.com/buy/prices-1c.html
The "Hobbyist" editions of the IDE: http://www.lispworks.com/buy/prices-1h.html
The mobile run times, which require the IDE: http://www.lispworks.com/buy/prices-lw4mr-1c.html
(The pricing pages suggest that the mobile runtime licenses are annual whereas the license for the IDE is for a single version and doesn't expire.)
And last but not least, the IDE edition comparison table: http://www.lispworks.com/products/features.html