Slashdot Mirror
Meet Lux, A New Lisp-like Language (javaworld.com)
Drawing on Haskell, Clojure, and ML, the new Lux language first targeted the Java Virtual Machine, but will be a universal, cross-platform language. An anonymous reader quotes JavaWorld:
Currently in an 0.5 beta release, Lux claims that while it implements features common to Lisp-like languages, such as macros, they're more flexible and powerful in Lux... [W]hereas Clojure is dynamically typed, as many Lisp-like languages have been, Lux is statically typed to reduce bugs and enhance performance. Lux also lets programmers create new types programmatically, which provides some of the flexibility found in dynamically typed languages. The functional language Haskell has type classes, but Lux is intended to be less constraining. Getting around any constraints can be done natively to the language, not via hacks in the type system.
There's a a 16-chapter book about the language on GitHub.
There's a a 16-chapter book about the language on GitHub.
We don't need another "bad ML in Lisp's clothes" language.
Could it be... SATAN ?
Lawrence Person (lawrencepersonh@gmailh.com (remove all "h"s to mail)
http://www.lawrenceperson.com/
... yet another programming language. Next, please work on a new HDMI standard, another E-car charging plug and why not invent another lens-mount for cameras, while you're at it? :-)
This may be nice for Java developers, but I can't think of any significant language that started off targeting the JVM and then successfully moved to another platform. That's because languages targeting the JVM get bogged down by the limitations of the JVM and the get entangled in the Java libraries.
If you want to develop a new language these days, start by targeting the LLVM.
Functional Languages are really cool in theory. However I find that for Real World development. Your code is often too tight for proper maintenance. Where Procedural and OOP is much better at fixing issues.
While yes *you* are the greatest developer in the world, and can write code better than everyone else in the world. It doesn't stop the people who pays your bills from giving you bad specifications, or come across problems that were not thought of before.
In my decades of experience, I have found to be nimble you need to keep humble and figure that your code will not end up like it was planned, so you need to put in hooks for expansion and think on solving issues that are not asked for. As well assuming that they may be some data that could cause your code to break and you will need to fix it quickly.
Functional Languages often become a bit too dense to fix. And god help you if you want to unload that project to someone else so you can work on something more interesting.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
How hard is it to see that automatically detecting bugs at compile time is superior to running into them at random at runtime?
I use Racket for end-user applications and have also heard good things about chicken scheme. Racket is pretty complete and allows you to write powerful GUI applications easily if you can live with a noticeable application start time of >1 seconds and don't need the latest platform-specific gimmicks like animated tray icons or similar things. Proper deployment is a bit unnecessarily complicated and the Racket developers have not always clearly separated their own framework for the DrRacket GUI from what you need for general application development, but overall it's a very good language and tool. It doesn't feel more lightweight than CommonLisp, though, just a bit more convenient in many respects and module system in particular.
Anyway, I should say that the focus on runtime-checking and loose typing is more of a disadvantage than an advantage. It encourages abstractions like using symbols as selectors rather than static enumerations, and these habits have no advantages. They produce runtime errors that slip easily even through extensive unit tests. Personally, I'd prefer to use a simple and straightforward Algol-clone with much of the expressivity of LISP (as many entities as possible should be 'first-class') but nevertheless a strong focus on compile-time checking and zero-cost abstractions, but haven't found a suitable language yet that also supports cross-platform GUIs.
A programmer who knows nothing beyond the likes of those is not well rounded and better get adjusted to the idea of being a galley slave for their entire career.
If you aspire to the boardroom, I strongly suggest you learn a bit of PowerPoint, excel, and basic business understanding, The language used at that level is all P/L calculations, by which I don't mean PL/I, but "Profit and Loss".
Insofar as fad languages are concerned, their main problem besides their terrible tool support, microscopic communities, non-existent code/library base to solve common problems, and lack of a clear niche that really only they fill best - is that the vast majority of actual programming work lies in understanding requirements and coming up with a reasonable set of approaches, designs, and patterns to fill them. For that, you don't need intellectual masturbation. You need to be smart and experienced enough to actually understand how to create a fully realized architecture actually capable of working, and not immediately falling over under load (with inscrutable error messages).
Really, the only use that so many different hobby languages provide is a form of job lock-in, and a gateway keeping out people who aren't smart enough to solve the company's real problems.
// Senior/Enterprise Architect
One or two places deciding to use Ruby or Eiffel isn't a sufficient enough base to make me wrong. Ruby was a flash in the pan and is basically dead.
I still have more fans than freaks. WTF is wrong with you people?