Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Programming

Meet Lux, A New Lisp-like Language (javaworld.com) 205

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.
This discussion has been archived. No new comments can be posted.

Meet Lux, A New Lisp-like Language

Comments Filter:
  • by tietokone-olmi ( 26595 ) on Sunday January 15, 2017 @12:57PM (#53672387)

    We don't need another "bad ML in Lisp's clothes" language.

    • Or a bad common lisp in Haskell clothing?

    • Thank you. To which I add "Kill it, kill it! Burn it with fire! Stop it before it breaches quarantine!"

      • by NoNonAlphaCharsHere ( 2201864 ) on Sunday January 15, 2017 @01:38PM (#53672655)

        [W]hereas Clojure is dynamically typed, as many Lisp-like languages have been, Lux is statically typed to reduce bugs and enhance performance

        "Kill it, kill it! Burn it with fire! Stop it before it breaches quarantine!"

        Shoot it with silver bullets, drive a wooden stake through its heart, burn the body, sprinkle the ashes with salt and holy water, seal the ashes into an iron urn covered with runes, weld it shut and bury it at a crossroads under the full moon. Then dust off and nuke the site from orbit. Even after that, I'm going to have a hard time falling asleep.

  • by ffkom ( 3519199 ) on Sunday January 15, 2017 @01:07PM (#53672453)
    ... 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? :-)
    • Can we bring back HD-DVDs and the DIVX videodisc format while we are at it?

    • by murdocj ( 543661 )

      How about another USB connector standard?

      • Not until we solve the mystery of how the first insertion is wrong 90% of the time when in theory it should be 50%. A working theory of this could lead to free energy, faster-than-light travel, or gas station sushi that won't make you sick.

        • by hoggoth ( 414195 )

          What really gets me is how most of the time I insert the USB connector correctly only on the THIRD try. That's proof of hyperdimensional geometry right there...

      • by DrXym ( 126579 )
        With USB C we may finally be at the point of having a connector that doesn't need replacing any time soon. It's amazing to think how many lifespans must have been wasted by people trying to plug a USB connectors into the socket the wrong way around.
    • Re: (Score:3, Insightful)

      by Tough Love ( 215404 )

      Or does the world urgently need another random person on the internet to post random angst to an article that they have not read and most likely would not understand if they did?

    • Re: (Score:3, Insightful)

      by PoopJuggler ( 688445 )
      You couldn't be more wrong. New programming languages is exactly what we need especially as we approach the end of "Moore's Law" with the discrete type of fabrication we do nowadays. Sooner or later the world will realize that in order to build really complex software, on the order of functioning neurological networks or quantum systems, we will need to evolve the languages we use to describe those systems so that we can describe them quickly. The software we write currently is dogshit compared what we coul
      • Compare programming a 6502 in assembly back in 1980 to programming in Java nowadays. Using modern languages and compilers you can write code 1,000,000 times faster, clearer and more complex in the same amount of time.

        So that what used to take a week to write in 6502 asm now takes less than a second to write in Java? Not disagreeing with your post, just taking issue with your scaling factor in the interest of making a better argument. Agree that OP couldn't be more wrong.

        • by arth1 ( 260657 )

          So that what used to take a week to write in 6502 asm now takes less than a second to write in Java?

          But it doesn't. You'll spend a week upfront gathering the necessary black box libraries, and a day to write all the glue needed to write your one-line program.

        • Comment removed based on user account deletion
      • by ffkom ( 3519199 )
        You do realize that LISP is one of the older programming languages, around for decades, and apparently, its popularity stagnates on a pretty low plateau?
        Dozens of LISP-derivatives have also been invented over the years, and yet not even GPUs or other architectures (that one could think to better fit the LISP way of applying side-effect-free code to lists of things) is written in any of those derivatives at a significant scale.
        If you look at newer languages that have become popular in the past 10 years, th
        • Add to that, anyone who says that static typing improves performance clearly hasn't been paying attention to the last 30 years of compiler research. The StrongTalk team disproved this hypothesis quite soundly for any language that includes subtyping. The problem is that static type annotations must be conservative. They give you loose guarantees that are always true, but for optimisation you care about what tight guarantees that are usually true. Profiling (which JIT environments do at run time and AoT
        • You do realize that LISP is one of the older programming languages, around for decades, and apparently, its popularity stagnates on a pretty low plateau?

          To me, there is another reason why LISP would never gain popularity these days -- recursive. To be efficient in this language, one should be able to think and program in recursive which requires a complete understanding of what is to be done or the program could easily go into an infinite loop. Most newer (so called) programmers nowadays can't think or program it that way. Instead, they think and program more in iterative way. Also, recursive has a down side which is limited memory. In order to be able to p

      • You might be interested in Viewpoint Research Intitute's [vpri.org] (headed by Alan Kay) experiments with "language-based code compression". They believe that useful functionality of contemporary software should be expressible in much lesser amount of (much higher-level) source code. I also remember an Adobe executive stating something to the same effect (that, e.g., Photoshop's functionality should be ideally expressible in something like 10000-20000 lines of highly mathematical code).
      • by epine ( 68316 )

        Compare programming a 6502 in assembly back in 1980 to programming in Java nowadays.

        I see your 1978 and raise you a 1970.

        '''Prolog''' is a general-purpose logic programming language associated with artificial intelligence and computational linguistics.

        Prolog has its roots in first-order logic, a formal logic, and unlike many other programming languages, Prolog is declarative: the program logic is expressed in terms of relations, represented as facts and rules. A computation is initiated by running a query o

        • Prolog failed because the syntax is horrifying and the evaluation method is...weird. I wrote an entire compiler in Prolog once, it worked and worked well, but it was just a functional program with bad syntax. The compiler would have been better if written in Haskell (which, incidentally, the compiler was for, as I did not have a Haskell-like compiler at the time).

    • There's no possibility for a better programming language! We already have the ultimate programming language - why would we want another?!

      (BTW, what is the language which we're supposed to be happy with?)

    • As long as they don't have billions of dollars and lobbyists galore forcing the public to use it, who cares?

  • sorry (Score:5, Insightful)

    by ooloorie ( 4394035 ) on Sunday January 15, 2017 @01:17PM (#53672521)

    first targeted the Java Virtual Machine, but will be a universal, cross-platform language

    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.

    • If you want to develop a new language these days, start by targeting the LLVM.

      Or Scheme, if you don't want to drag tens of megabytes of C++ code around.

  • by jellomizer ( 103300 ) on Sunday January 15, 2017 @01:31PM (#53672599)

    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.

    • 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.

      That's not the experience we had at Ericsson [erlang-factory.com].

      I can't help but think that you haven't really been involved in designing, building, fielding, and maintaining large systems based on FP. I have. With Erlang [erlang.org] in particular we saw a four [erlang.se] to ten fold increase in productivity.

      And "too dense to fix" didn't even show up on the radar as a problem. Not by a long shot. Quite the opposite in fact, not having to wade through page after page of boiler plate (that could still trip you up, mind you) does wonders for focusing

  • My "(" and ")" keys haven't got enough wear on them. This will help level out the wear pattern on my keyboard. Thanks!
  • 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.
  • What is this new language good for?
  • 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.
  • 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!")))

Children begin by loving their parents. After a time they judge them. Rarely, if ever, do they forgive them. - Oscar Wilde

Working...