Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisp: More is less

jameso.be

Post reply on HN
Print view View original

71–80 of 125 posts

Re: Lisp: More is less

#71

Post by innguest »

147 wrote: post #70
innguest wrote: post #51

Earlier quoted context omitted.

We're a team of 6 programmers, 3 of which code Typed Racket. We all started here as Rails devs and got tired of it. I'm always pushing to invest time in research for better solutions and our team seems to be open to that (after weeks of discussion, though - we're no heaven). Typed Racket is the solution we found after surveying the field. Our management has recently told us they believe we're now a good-sized team gi…

How are you liking Racket instead of Rails? I'm assuming you're using it for web development. I was a Rails dev that moved to Clojure and I don't know much about Racket at all, but how is the library situation? Of course in Clojure if I ever need something I can count on being able to find it in Java and interop with it.

To be fair and not to mischaracterize the situation, I have been programming in lisp for at least 5 years in personal projects, so it's not like I had to learn it now and I also did not convert from Ruby to lisp.

I never liked Rails. I don't like anything that focuses on files, because in my mind the fact that code needs to be saved in the filesystem is simply incidental, so no code should rely on that fact; but Rails builds on top of that, telling you where to put your code (folder structure), taking control from you over what code sees what code (MVC), giving you command-line tools to use when it could simply provide functions at a REPL (gems, migrations, tests), etc. It simply doesn't get it at all.

In my opinion, a framework (loosely speaking) that solves only the easy problems (how to organize code) is pointless. But something like an FRP library that allows me to do GUI by focusing on how I want to transform data, and liberating me from thinking about events and callbacks - THAT to me is something that solves a hard problem.

So to answer your first question, I'm happy not to need to touch Rails again - right now I only need to look at it, rewrite it in Racket, and delete it.

Racket is a much nicer system than Clojure, it has immensely intelligent people behind it, the documentation is stellar (unbelievably so, in my opinion), there are libraries for everything you can imagine and more (like an FRP library). It also does native GUI everywhere, effortlessly. For things it lacks, it is easy to write an FFI.

I would never touch Java nor trust any library written in Java. The more I code the more I distrust code that relies on mutability. I haven't reached 100% pure code yet but I work towards that goal, not away from it.

EDIT: Yes, I am using Racket for a webapp that connects to a database and perform general CRUD operations.

Re: Lisp: More is less

#73

Post by gruseom »

brandonbloom wrote: post #69
vorg wrote: post #68

Earlier quoted context omitted.

> > just restrict the use of macros > Precisely. Enabling macros is the sole justification for the homoiconic syntax, which is often cited as the most offputting feature of lisps for uptake by large programmer teams. If you're going to have two "editions" of Clojure, one with the full feature set for language designers, and the other a more restricted sans-defmacro one for more general programmer use, then why not gi…

1) I genuinely prefer variadic prefix notation, even in the absence of homoiconicity. 2) Restricted does not mean "banned". It means that they need to be justified and subject to expert scrutiny. 3) Even if you never write a macro of your own, you're a beneficiary of the syntactic sugar and can leverage macroexpand to demystify otherwise opaque language constructs.

Pet peeve, sorry, but it irritates me that Clojure people act like this guilty-until-proven-innocent policy about macros is somehow original. It has been standard advice for decades. Chapter 8 of On Lisp (1994) is called "When to Use Macros" and its first section is "When Nothing Else Will Do":

By default we should use functions: it is inelegant to use a macro where a function would do. We should use macros only when they bring us some specific advantage.

I understand from a language marketing point of view why someone might say, "Oh, those other Lisps made wild and crazy use of macros. It was really bad! But we are enlightened and have restricted them." But it's a bogus way of playing to a bogus criticism. It would be better to just say that there's a tradition of how to use macros correctly.

Re: Lisp: More is less

#74

Post by [deleted] »

coldtea wrote: post #33
gruseom wrote: post #3

This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. (If the OP contains any, I missed it.) But they're the sort of things that sound plausible and have more gravitas than "Here are my current preferences", so they get repeated, and no do…

> This post repeats two memes that float around the programming language space. One is: "it's so powerful that it's bad". Also known as "less is more", which is a well established point in programming, and with a lot of historical examples to showcase it. > The other is: "it's ok, but not for large projects". I don't think I've ever seen any evidence attached to either. Well, were are the sucesfull large projects wri…

[deleted]

Re: Lisp: More is less

#76

Post by jeorgun »

innguest wrote: post #60
rtpg wrote: post #56

Earlier quoted context omitted.

didn't even know that. BTW the people on #haskell are quite active, and nice :) (maybe a pointless counter-example, I once went onto #ruby, and asked about an easy way to make a function name refer to a function( to be able to do things like list map f easily, without the superflous do |x| f x end ), and I got yelled at because I was trying to write "non-ruby code".

The Ruby community is very close-minded. I've been a victim of that behavior in #ruby as well. If you asked an equivalent question on #ror (the Rails channel) you'd get more than yelled at - no one would take you seriously from that point on. To answer your question, because methods aren't first-class in Ruby, you can't pass them around the way you want to. I've decided I don't want my languages telling me what I can…

You can pass Ruby methods around; the syntax is just ugly, and it isn't really used:

    def call_on_two fn
      fn.call 2
    end

    call_on_two 1.method(:+)      #=> 3
The problem with [1, 2, 3].map(:function_name) is just that map requires a block, and not a method or proc.

A method like that could be easily enough created, though it'd be kind of ugly:

    module Enumerable
      def map_fn fn
        map { |i| method(fn).call i }
      end
    end

    def foo num
      num + 2
    end

    [1, 2, 3].map_fn :foo #=> [3, 4, 5]
I don't know why there isn't an easy way to freely convert between methods, procs, and blocks; it's definitely something the language is missing.

Re: Lisp: More is less

#78

Post by stuhood »

I wasn't excited about scala's macros initially [a], but Eugene's Burmako's recent talk [b] on the constraints the developers worked with to keep macros consistent and interoperable was illuminating, and has changed my mind to a large degree [c].

In the end, they only directly added support for 1) type-safe macros, aka "black-box" macros 2) ...invoked transparently as methods, aka "def macros"

They identified "white-box" (non-type safe) macros and quasiquoting as distinct from black-box macros, because the type signature of a black-box macro tells you approximately what it will do, meaning that you can treat it as a "black box". But additionally, in order to write a meaningful type signature, the input to a black-box macro must _already_ be valid scala code! This means that the addition of macros cannot actually result in new scala syntax [d].

[a] https://news.ycombinator.com/item?id=3709193

[b] http://www.infoq.com/presentations/scala-macros

[c] still hoping the existence of scala macros leads to the deprecation of a bunch of other features though

[d] see the explanation starting around 33m30s in [b]

Re: Lisp: More is less

#80

Post by dandrews »

gruseom wrote: post #73
brandonbloom wrote: post #69

Earlier quoted context omitted.

1) I genuinely prefer variadic prefix notation, even in the absence of homoiconicity. 2) Restricted does not mean "banned". It means that they need to be justified and subject to expert scrutiny. 3) Even if you never write a macro of your own, you're a beneficiary of the syntactic sugar and can leverage macroexpand to demystify otherwise opaque language constructs.

Pet peeve, sorry, but it irritates me that Clojure people act like this guilty-until-proven-innocent policy about macros is somehow original. It has been standard advice for decades. Chapter 8 of On Lisp (1994) is called "When to Use Macros" and its first section is "When Nothing Else Will Do": By default we should use functions: it is inelegant to use a macro where a function would do. We should use macros only when…

Please name a language you use so that whenever you and I disagree I'll be able to cite the "Blub people".
Post reply on HN