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? :-)
Is Scheme actually used for projects outside of college CS classrooms?
IIRC Scheme was positioned as the "lightweight Common Lisp" (in the sense of LDAP being Lightweight X.500) back in the '90s.
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.
Yup, a one way world of doing things. That's why penises and vaginas only operate one way.
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.
My "(" and ")" keys haven't got enough wear on them. This will help level out the wear pattern on my keyboard. Thanks!
Otherwise it looks interesting. However, I'd rather wish to see a new strongly-typed cross-platform language with garbage collector, very strict compile-time optimization (not dynamic at all), a built-in GUI toolkit and implicit block syntax.
"Lux is statically typed to reduce bugs and enhance performance"
Citation needed showing actual proof this is true and not just someone hating on dynamic typing.
"Wait. Something's happening. It's opening up! My God, it's full of apricots!"
How hard is it to see that automatically detecting bugs at compile time is superior to running into them at random at runtime?
Statically type languages fix half the problem. They cannot guarantee the program will execute correctly though. And since most problems arise during execution... you're back to square 1.5 instead of 1.
Citation needed showing actual proof this is true and not just someone hating on dynamic typing.
Just use your common sense. Let's take a simple statement:
a = b + c;
If b or c is floating-point type, the dynamic language interpreter will have to detect that at runtime (via an 'if' statement) before doing the actual floating point addition.
A compiled language will detect this at compile time, so at runtime, there is no need to check the types of b or c. It will simply run the floating point addition code, thus eliminating the two runtime type checks for b and c.
Nevertheless, whenever I have written something in Ada, it worked correctly the first time it compiled. The programs weren't very complicated, I admit, but still that has impressed me. However, it takes an endless time and many, many fairly informative compiler complaints to get even a simple program to compile...
If you think a "large" code base "takes > 1 hour to compile" then you have no comprehension of what a large code base looks like.
Even back in the Pascal days you could define functions whose input was "Integers in the range of 10 to 50 inclusive" and if the compiler couldn't prove that a particular function call was safe, it would tell you.
You are describing the weak guarantees available in the type systems you have used. Try using something like Haskell and then tell me that the type system doesn't prevent meaningful bugs.
I don't think it matters what server it would have been on. And FWIW, all the email leaks thus far did not originate from her supposedly insecure private email server.
Yes. Just like we're supposed to pretend Hillary's an honest populist who cares about the little people. Welcome to the Ministry of Truth.
Here is some small http://taktentus.herokuapp.com/
No more C++ and all those silly libraries, no more Python and the way too convenient coding there and its crazy tie-ins with stats and ML libraries. I want something that is poorly documented, celebrated only in a small academic circle, and makes me do everything from scratch and have little access to the underlying OS.
Screw productivity and ever finishing a damn thing.
Gee. Another language for the sake of creating a programming langauge.
And claiming it is wonderful.
Impressively worthless/idiotic.
But wait, there is more! It is an improvement on ! What a load of useless drivel.
Actual systems have state and access to limited physical systems (hard drives, USB keys, etc). "Pure" functional language weenies are utterly clueless.
I used to dream about an internet where it was normal for everybody to have their own e-mail/web/file server, in stead of being dependent on server farms owned by the ad industry. Situations like Clinton's would be routinely and preventatively solved by either just forwarding everything incoming/outgoing to archive@administration.gov.cc or in case of high security targets by replacing their private server by a vetted official server (just pull it out of the wall socket and plug in a new one, with current tech the whole thing does not need to be larger than a lightweight 8x8x5 cm^3 box).
The title is "Standards".
https://xkcd.com/927/
He doesn't need to say anything. It's already been thoroughly debunked and the only people repeating it are idiots who haven't gotten the word. The whole thing was a scam by a guy at 4chan. Once you actually look at the story it just falls apart on it's own. Even the NYT refused to print it.
ALL problems related to running software arise during execution, genius.
I don't know if it happened or not, but it is plausible. That alone scares the living shit out of me.
They may have done a really bad job with marketing, but Scala.js is considered production ready and more than a toy.
Scala Native, the first official effort to get Scala compiling via LLVM, is less than a year and a half old.
What is this new language good for?
If you want something to pee on you - let n1ggers and indo-chimps do it, don't discriminate. Also, sand n1ggers can shit standing up on the street, you might want that too.
Too bad americans have only butchy smelly sand n1ggers dressed in burkas left to serve as females.
First there was Pascal, which got a moderate following outside universities. Then came Modula, which nobody used because it was too strongly typed. Then there was a massive branching of language paradigms (object-driven, object-orientated, lists & sets, functional) which slowly moved over to business use. Then there was Haskell, which has a small following outside universities. A big problem with a new language is finding people to use it and share a code-base.
Recently Apple and Google created their own languages and used their global position to promote them. Another language means another library to learn, another compiler to install, and many times, also another development environment to install and learn. (Eclipse is removing some of that burden but it has a steep learning curve.) When a new language was a rarity, it was easy to crowd-source developers for it. Now there's a new language every month, there aren't sufficient developers available to make it popular.
That's what we sorely need - yet another silly language, so that its author can inflict his or her personal tastes on the rest of us. If anything is missing in the computing world, that is languages. While you are at it, throw in another development methodology - Agile is beginning to look old and tired, and a new fad is needed.
Before I judge Lux, I'm waiting for the Lux#.net implementation.
And a strongly typed language will not let you do it at all :), perhaps go as far as requiring you use a +. operator for adding floats, separate from the + operator.
Indeed, it appears Lux does that, in a drastic way. Even < and > are not spared (CAML is notorious for + and +. and annoying newcomers with its strictness, but its less-than and greater-than are very generic, so you'll write a sort that works on ints, floats, chars, bools and weirder things even if you didn't intend it to be generic). From the Lux book :
Whereas other programming languages often overload the math operators +, -, >, etc. for all numeric (and some non-numeric) types, Lux actual offers different versions for different types.
The Nat operators are as follows: n.+, n.-, n.*, n./, n.%, n.=, n.<, n.<=, n.>, n.>=.
The Int operators are as follows: i.+, i.-, i.*, i./, i.%, i.=, i.<, i.<=, i.>, i.>=.
The Real operators are as follows: r.+, r.-, r.*, r./, r.%, r.=, r.<, r.<=, r.>, r.>=.
The Frac operators are as follows: f.+, f.-, f.*, f./, f.%, f.=, f., f.>=.
The differences may look trivial, but since the numeric types are treated differently in Lux, you must be aware of which function-set you're using when working with your data.
Although, they then introduce sugar for the operators :
To make things easier, there is a module named lux/math/simple, which introduces unprefixed macros for all the common numeric operations.
Those macros analyse their inputs' types in order to automatically choose for you the correct functions in each case.
That way, you get the benefit of having polymorphic math operators, through the magic of meta-programming.
Oh, and you can definitely use those macros in conjunction with the infix macro!
So, check lux/math/simple in the documentation for the Standard Library and have fun with your mathy code.
Is gwt able to compile Lux into Javascript?
I used to dream about that, and a free and open Internet (capital "I"), a network of ideas and creation, transcending borders and national identities. I fully believed in the brave new digital world. But the dream died.
While that can (potentially) eliminate a class of bugs, I'd argue it's a relatively small set of possible bugs. I've seen a lot of people make the bold assumption that if it compiles, it must be right. A solid test suite to support the code is going to pay far bigger dividends than relying on the compiler.
Think of compiling as automatically generated unit tests. Do you feel better about it now?
One big advantage of the Lisp syntax is that it allows editing code at higher abstraction level in a uniform way. In Emacs one can use paredit mode to directly manipulate the structure of a Lisp program by splitting, joining, and moving s-expressions instead of editing code as a sequence of lines of text like it is done with most other programming languages.
Clojure’s syntax is not an improvement but a step backward as it undermines this advantage by not syntactically grouping everything that is grouped semantically (e. g. binding pairs in let) just to use fewer parentheses. And very unfortunately new Clojure-inspired Lisp dialects (like Lux) appear to inherit this syntactical deficiency.
Why should we care? Porn is ubiquitous, and you can see much kinkier stuff from your local web-pimp. Hop over to fetlife and you can find someone to do it with. If it's that he paid: again so what? Prostitution ts legal in (parts of) the US and Canada.
Oh the horror! Trump may have done something that I* do! But it's bad when he does it! (*Not saying you're into peeing hookers; likely your tastes would make Trump blush.)
But really, what does this have to do with Lux?
One of the nice things about lisp is that it is so clean. Lux appears verbose and cluttered with odd symbols.
Lisp:
(defun hello ()
"Hello, world!"
)
Lux:
(;module: {#;doc "This will be our program's main module."}
lux
(lux (codata io)
[cli #+ program:]))
(program: args
(io (log! "Hello, world!")))