7 ms·

"The question is where will we be in five years, the answer is using Common Lisp, because of language features" says the author in the comments. This was 8 yea

• meric 10y ago
  I'm developing a language that's a superset of Lua and Lisp. It's still in its infancy, but here's an example of a Lisp/Lua function in a module that can be imported as a (+...) macro that expands into Lua `a + b + c + ...` expression. https://github.com/meric/l2l/blob/rewrite/l2l/macro/arithmetic.lisp https://github.com/meric/l2l/blob/rewrite/l2l/macro/arithmet... The idea is programmers will write in Lua whenever readability is prioritised, and when homoiconicity is required, for example in the use of domain specific languages, lisp can be switched to. The lisp part can be used to produce macros that expand into Lua. Would be great to know your thoughts!
  • zvrba 10y ago
    You know about metalua, right? http://metalua.luaforge.net/ http://metalua.luaforge.net/
    • meric 10y ago
      Yes, I wanted a version of Lua with Macro's that reused familiar syntax (for lispers), that can run on LuaJIT, and is implemented in Lua completely.
      • groovy2shoes 10y ago
        https://github.com/baguette/lemma https://github.com/baguette/lemma I've unfortunately let it languish for the last few years, but I'm about to pick back up a bit for the 2016 Lisp Summer Game Jam. I've got a handful of big, backward-compat-breaking changes in the queue, but it should start to stabilize again within a couple of weeks.
• Frondo 10y ago
  Heh, yeah. Lisp has powerful features, I'm sure, but something that's always stumped me is, if that power mattered for delivering better code, would we have to strain so hard to find examples of why it's better? Paul Graham's viaweb story, well, that's great, but why wasn't there a whole cohort of super-powered startups winning the day with lisp in the original dot com boom? Why are there so few big wins with lisp? The "lisp is powerful" story just doesn't seem like the whole story, when there are so few successes on the ground compared to C, C++, Python, Perl, PHP, Ruby, VB, you name it.
  • gkya 10y ago
    You confuse powerful with popular. Many startups don't need powerful tools, other than a CRUD framework and JQuery. Also, existence and abundance of libraries is a factor, and Lisp didn't get much love from the OSS web folks til recently.
    • Frondo 10y ago
      Well, no, I'm not confusing powerful and popular. I'm asking why, for all lisp's power, there's almost no examples of that power actually doing anyone any good. Is it because most projects don't need something powerful? The benefits of that power aren't actually that great compared to the rest of the lisp baggage? We have this trope of the smug lisp weenie and there's definitely a whiff of high wizardry around lisp, but who's actually shipping anything with it?
      • snaky 10y ago
        > doing anyone any good There's a difference between doing and talking about. Compare an amount of noise from Rust crowd to anything useful being done in Rust. Let's look at only one product implemented in Lisp, by only one vendor, and it's users in only one industry - http://allegrograph.com/healthcare/ http://allegrograph.com/healthcare/. Pfizer, Mayo Clinic, GSK, Novartis - should we stop with that 'doing anyone any good' mantra?
        • 10y ago
• mbrock 10y ago
  I like niche stuff. What language doesn't result in unmaintainable code, really? And let me just say... it's a bit rude to spread this rumor that Lisp is anti-social and bad for business when you've barely even tried it. Seriously. "Prove me wrong" is not a good way to discuss. See for yourself instead: learn Lisp and try to use it to write maintainable code.
  • tempodox 10y ago
    I think you touch an interesting area. For me, figuring out how to make code maintainable (including error handling) is still an area of research, and I'm not a newbie. At least Lisp, with its metaprogramming facilities, gives you some good tools for experimenting. And I do think that the experimental character of the original problem space when Lisp was discovered plays an important role there.
    • mbrock 10y ago
      Agreed. I think creating maintainable code is for various reasons very difficult, and I have barely seen any projects that succeed, especially not commercial software. Based on my experience, I could say that unmaintainable software results from using Java, JavaScript, Ruby, shell, and so on... but I don't like to blame the languages. Instead, I think it's simply that no language by itself can enforce properties that lead to maintainable software. For example, Java is very clean and simple, but that doesn't mean that typical Java code bases are clean or simple. Programmers will eventually always find a way to introduce strange complexity, inappropriate metaphors, incomprehensible abstractions, befuddling reuse, overly clever tricks, etc. If we really want to learn to make maintainable software, we should probably stop focusing on language features (and boring language wars) and think more about stuff like Eric Evans's concept of ubiquitous language... and, yeah, experiment with ways of writing clear code in whatever languages we use.
• martinflack 10y ago
  Hmm. In many walks of life, popular != best. In fashion, cars, investing, and to some extent cooking, for example, the top performing adherent is doing things differently than the crowd. Lisp code can be very readable, but it takes a few years to learn how to write it that way. I spent many years in Perl 5 myself, and I found Common Lisp tricky at first but ultimately very satisfying. Two jedi mind tricks for the beginner: 1. Don't think of Common Lisp as the language you want. The language you want is one layer above CL, and fits the business domain you operate in. Build that. (Yes, this requires a little investment up front.) Then solve your problems in that "language". Because Lisp macros are powerful fully-transformative engines, you can do almost anything (less breaking a few simple syntax rules... but newbs often underestimate what can be broken/bent). 2. As silly as it sounds, the parentheses coming first does bother folks. Every editor does syntax highlighting now. Do two things: (a) color the parens close enough to your background color that they visually fade and "back off", but are still visible when you need to look at them - your code instantly looks a bit more like python, indentation sticks out; (b) used a structured editing mode that inserts closing parens, keeps parens balanced automatically, and offers neat structured editing hotkeys to copy/cut/paste/delete sexp's (expressions) as units. Both steps are extremely comfort-building and the ubiquitous parens remove a class of bugs. The greatest compliment to Common Lisp that I've seen over the past 8 years is the constant pilfering of language features to other mainstream languages. As for readability - like Perl, TIMTOWTDI, and even moreso in Lisp because one can write macros as utilities to greatly simplify the actionable code and have it blow out into lower-level code that does the mechanical dirty work. As a result of what I've said above, people working in CL do tend to write it slightly differently. You can see some evidence of that if you study different open source libraries, etc. It's not so much a rigid code style as an interest and ethos that binds the community. I'll leave with a little example of macros at work, via the old and venerable SERIES library, that allows one to specify loops in a semi-declarative style, that if executed literally would cause multiple passes; but which compiles to a single pass over the data sequence. The input is stock market "bars": (defvar *spy2006* '(("29-Dec-06" 142.08 142.54 141.43 141.62 45461200 141.62) ("28-Dec-06" 142.41 142.70 141.99 142.21 37288800 142.21) ("27-Dec-06" 141.87 142.60 141.83 142.51 39727100 142.51) ;; ... )) This is what you might code, which I humbly submit to you is very readable: (defpackage iteration-testing-series (:use :cl :series)) (in-package :iteration-testing-series) (defun combine-bars (bars) "Summarize a sequence of BARS into one bar." (series::let ((zbars (scan 'list bars))) (list (first (first bars)) (second (first bars)) (collect-max (map-fn 'float #'third zbars)) (collect-min (map-fn 'float #'fourth zbars)) (fifth (car (last bars))) (collect-sum (map-fn 'integer #'sixth zbars))))) That function is very easy for me to read. Partially expanded, it becomes the following, which is itself further expanded. Note that it was trivial for me to request this expansion, and that multiple macros are composable so that many features can be engage at once. I can write something high-level, but also observe the expansion down to low-level code all the way (SBCL can even trivially show me the resulting assembler code for my CPU). I am freed up to think at a high level - but I don't lose control over the low level. The following block may be daunting in size but if you know that SETQ is an assignment, and within the TAGBODY there are labels for GO which is like a goto, it should be possible for a programmer of other languages to follow. Not also the type declarations carried over for me automatically, which will allow for speed and debugging optimization, which in CL is a knob that I can turn - something I don't know exists in other languages. (LET* ((#:OUT-1014 BARS)) (LET (ZBARS (#:LISTPTR-1012 #:OUT-1014) (#:ITEMS-1019 0.0) (#:NUMBER-1017 NIL) (#:ITEMS-1026 0.0) (#:NUMBER-1024 NIL) (#:ITEMS-1032 0) (#:SUM-1030 0)) (DECLARE (TYPE LIST #:LISTPTR-1012) (TYPE FLOAT #:ITEMS-1019) (TYPE FLOAT #:ITEMS-1026) (TYPE INTEGER #:ITEMS-1032) (TYPE NUMBER #:SUM-1030)) (TAGBODY #:LL-1035 (IF (ENDP #:LISTPTR-1012) (GO SERIES::END)) (SETQ ZBARS (CAR #:LISTPTR-1012)) (SETQ #:LISTPTR-1012 (CDR #:LISTPTR-1012)) (SETQ #:ITEMS-1019 (THIRD ZBARS)) (IF (OR (NULL #:NUMBER-1017) (< #:NUMBER-1017 #:ITEMS-1019)) (SETQ #:NUMBER-1017 #:ITEMS-1019)) (SETQ #:ITEMS-1026 (FOURTH ZBARS)) (IF (OR (NULL #:NUMBER-1024) (> #:NUMBER-1024 #:ITEMS-1026)) (SETQ #:NUMBER-1024 #:ITEMS-1026)) (SETQ #:ITEMS-1032 (SIXTH ZBARS)) (SETQ #:SUM-1030 (+ #:SUM-1030 #:ITEMS-1032)) (GO #:LL-1035) SERIES::END) (IF (NULL #:NUMBER-1017) (SETQ #:NUMBER-1017 NIL)) (IF (NULL #:NUMBER-1024) (SETQ #:NUMBER-1024 NIL)) (LIST (FIRST (FIRST BARS)) (SECOND (FIRST BARS)) #:NUMBER-1017 #:NUMBER-1024 (FIFTH (CAR (LAST BARS))) #:SUM-1030)))
• Grue3 10y ago
  Well, I'm still using Common Lisp. If there was anything better, I'd have probably switched.
  • deleted 10y ago
    [deleted]
  • effie 10y ago
    Curious, what are you using it for? Would you say it is well suited for writing operating system helper tools (working with files, pipes, kernel api, calling other programs)? I like bash expressiveness a lot but sometimes I feel I could use a more powerful scripting language.
    • cassowary 10y ago
      I just discovered Turtle yesterday, a library for Haskell. Obviously I haven't used it much in that time, but superficially it looks amazing. See http://hackage.haskell.org/package/turtle-1.0.0/docs/Turtle-Tutorial.html http://hackage.haskell.org/package/turtle-1.0.0/docs/Turtle-... and http://www.haskellforall.com/2015/01/use-haskell-for-shell-scripting.html http://www.haskellforall.com/2015/01/use-haskell-for-shell-s... Here's an example: #!/usr/bin/env runhaskell {-# LANGUAGE OverloadedStrings #-} import Turtle main = do cd "/tmp" mkdir "test" output "test/foo" "Hello, world!" -- Write "Hello, world!" to "test/foo" stdout (input "test/foo") -- Stream "test/foo" to stdout rm "test/foo" rmdir "test" sleep 1 die "Urk!" Haskell is strongly typed: the first argument of `output` is a `FilePath`; the second is a `Text`. In some respects, strongly typed is the opposite of power tho, because there's all these things you can do, like accidentally (or deliberately) pass a Text to a function expected a FilePath without translating it first.
      • codygman 10y ago
        I think the real magic here is you can drop down (fly up?) to writing Haskell code alongside this bash like DSL and have sane flow control.
      • 10y ago
• posterboy 10y ago
  Clojure got reasonably popular around that time.