5 ms·

> But I'm willing to bet that a lot more developers will be able to understand this since this is in a programming language they understand well. This is one a

• arakyd 17y ago
  Yeah, he says that Lisp is too hard for the common man, and then sort of implies that this is because it doesn't use ALGOL derived syntax. I don't think that's the issue. It's not Mort who's fallen in love with ALGOL syntax, it's the CS graduate Elvis's who cling to their expensively acquired "skills" (priesthood memberships) with religious fervor (he says, as a CS student). I program in C#, and lambdas and delegates are nice (I can't use expression trees because the company I work for standardizes on .NET 2.0). But the system is too gnarly, still verbose as fuck, and nowhere near as nice as Lisp (as Krishnan freely admits). This just increases the need for sophisticated developer tools and makes things more obscurantist, not less. C# is just another variation on Java, i.e. a way to drag Elvis types 10% closer to Lisp without depriving them of their oh so precious ALGOL syntax. Fuck the priesthood, seriously.
  • dkersten 17y ago
    I never did understand this averseness to anything not algol-derived... I personally like Lisps syntax (fuck off, even though it looks different and uses "s-expressions" and code as data and all the rest - ITS STILL SYNTAX) and I like point free syntax and forth-like syntax and prolog intrigues me and ML has interesting syntax too and ... My point is: ITS JUST SYNTAX! Syntax doesn't define the language, just the look. I do like a nice, clean, concise syntax though.
    • omouse 17y ago
      Syntax does define the language. It's very difficult to write macros for an ALGOL-style language. It's possible but very difficult. Some people are put off by Common Lisp's LOOP macro or the FORMAT function and will try and avoid using the more complex features of them. Those are small examples of how the syntax encourages, or discourages, the use of language features. Hell, I even hate doing any complex shell scripting because I can never remember the difference between [ ] and [[ ]] and ( ) when using conditionals.
  • yummyfajitas 17y ago
    Something I've never gotten around to is building an algolish-lisp -> lisp translator. [a, b, c] -> '(a b c) f(x) -> (f x) These two translations are strictly syntatic modifications to lisp. Some syntactic sugar: { f(x) g(x) } -> (progn (f x) (g x) ) With these three tweaks, we are probably 90% of the way to recruiting the common man (if syntax is really what puts them off).
    • tnovelli 17y ago
      I've done things like this in Scheme - not robustly, but it's worth pursuing IMHO. I can't stand math formulas in SEXP notation. Array/slice/hash lookup notation would be nice too. Lisp gets it right by excluding sugar from the language kernel, but a "batteries-included Lisp" should include it in a standard library.
    • KirinDave 17y ago
      You can do these within PLT scheme quite easily. In fact, PLT Scheme comes with an Algol 60 reader that reads Algol 60 and turns it into scheme forms which are then executed. It's a cute trick. http://docs.plt-scheme.org/algol60/index.html http://docs.plt-scheme.org/algol60/index.html
    • rincewind 17y ago
      I tried this with arc (worked with anarki based in arc2) http://arclanguage.org/item?id=8172 http://arclanguage.org/item?id=8172 The syntax is inspired by McCarthy's in his paper from 1958. It works, but i don't find it useful.
    • jrockway 17y ago
      This looks great for trivial code, but what about more complex code? destructuring-bind([a b &rest c] some-list lambda([x] +(a b x))) or loop(for i from 1 to 10 collect 1+(i)) or with-current-buffer(get-buffer-create("foo") save-excursion( insert(text) buffer-substring-no-properties(point-min() point-max()))) This looks horrible. There is an advantage in using the same syntax for both lists and function application.
• andreyf 17y ago
  And anyone who could write this, can grasp Lisp themselves. Write the memorizer? That's basic functional programming, but what does that have to do with Lisp? You could write it in JavaScript: function memoize(f) { var memory = {}; return function memoized(arg) { return arg in memory ? memory[arg] : (memory[arg] = f(arg)); } } The big thing Lisp has left is reader and compile-time macros, and other systems [1] might be able to do both better pretty soon. Yes, Lisp has a lot to teach people who think that programming languages are passed down immutable from the superior minds of GvR or Stroustrup, but once you realize the enormous variety of decisions made in designing a language, it becomes clear that almost no number of languages will fill the space of possibilities. A lot of ways, languages are like religions - they're part of social structure, and part of people's identity, and they tell you how to pray, when to fast, how to allocate and free memory, how to traverse the call stack, etc. But when you think about it hard enough, it's clear that all of these decisions are better made by individuals, not committees or institutions. 1. http://piumarta.com/software/cola/ http://piumarta.com/software/cola/
• anonjon 17y ago
  Agree completely. Lisp syntax is stupidly simple, if anything it would be easier for a 'Mort' to pick up; In lisp it is pretty easy to hack together something that works. Mort wouldn't use memoize because mort doesn't know what memoize is, and doesn't understand the theoretical basis of it (regardless of language). The learning curve and difficulties in lisp come when you are trying to use the advanced features of the language and write efficient code.(Which isn't any different from any other language, just there are more 'advanced' features available, generally). (Or maybe the learning curve comes when you try to install external libraries, which is my biggest frustration.. at times you struggle longer getting everything setup properly than you would have implementing the library from scratch).