Why Racket? Why Lisp? • Hacker News Board

Re: Why Racket? Why Lisp?

#291

Post by pvaldes » Sat, Aug 23, 2014, 2:04 PM UTC

cturner wrote: post #136

calibraxis wrote: post #97

Earlier quoted context omitted.

Yes, that is very important. When I watch experienced programmers learn Lisp, they write a couple functions, then go through the pain of debugging that. They should unlearn that. And put tiny fragments in the REPL. (Or whatever interactive tool you have.) Playing with it.

Since lisp is homoiconic (refreshed on this, see downvotes below) it would be nice if you could type things into a repl and then run a function like this: (persist function-i-just-wrote). And then it would save to a text file. Then you wouldn't need to stuff around with the mouse copying from one buffer to another and the like. (I expect something similar is possible in emacs, but emacs is not my thing.) Hmm. I suppo…

this is easy: you only need to wrap your function in the body of a 'with-output-to-file' macro. You can send the output also to a stream, to a string, or use the * as stream name to grab the stdout also if i'm remembering correctly

Is possible.

Re: Why Racket? Why Lisp?

#292

Post by innguest » Sun, Aug 24, 2014, 4:59 AM UTC

theseoafs wrote: post #285

innguest wrote: post #279

Earlier quoted context omitted.

No. It's a very meaningful distinction, actually. Compare: Ruby: will_print = puts "hello world" # it already print to the screen! and will_print does not have any meaningful value -- indeed it's nil Haskell (demonstrated on the repl, which runs inside the IO monad): let willPrint = putStrLn "hello world" -- nothing gets printed! willPrint -- now the string gets printed ( only because the repl is inside the IO monad…

I know how IO works in Haskell, I don't need you to explain it to me. I still maintain the distinction you're making is meaningless -- Haskell code very clearly has side effects (mutating state, downloading files, sending data over a network, displaying pictures), and like any other programming language in existence, nothing actually happens until runtime.

Now you're just ignoring what I said. It's not about things actually happening at runtime, it's about having to consider the program as running in a changed environment after each line of code. I'm sure I've made my point to more mature people that never say things like "I don't need you to explain it to me".

Re: Why Racket? Why Lisp?

#293

Post by GFK_of_xmaspast » Mon, Aug 25, 2014, 5:36 PM UTC

It's kind of interesting that the author's examples of 'woah! look at all these cool packages' include plotting, unit testing, and a gui. Those standards feel a little low to me.

Re: Why Racket? Why Lisp?

#294

Post by raiph » Mon, Aug 25, 2014, 7:15 PM UTC

einhverfr wrote: post #268

I am learning Perl's FP features and really liking it, and teaching myself common lisp. I enjoyed the article quite a lot actually. I find it is very hard to define functional programming for many people but this is what I have come to explain to people: Functional programming means thinking in terms of mathematical functions in the f(x) sense. Once you get that basic promise, that for any given input you have a sing…

What about spending a few minutes exploring P6 and providing feedback about it to Larry Wall et al on #perl6?

One easy way follows (for you or anyone else reading this who is curious about P6). Preferably between about noon and midnight GMT (so you're more likely to catch Larry Wall, nick TimToady) visit the freenode IRC channel #perl6 (eg go to https://kiwiirc.com/client/irc.freenode.net/perl6 and enter a nick) and enter 'hi'. There are on channel evalbots and folk who will be happy to show you a well designed and continuously improving Perly blend of FP, OO, etc.

Yesterday's log is at http://irclog.perlgeek.de/perl6/yesterday. Hope to see you in the log. :)

Re: Why Racket? Why Lisp?

#295

Post by tome » Tue, Aug 26, 2014, 1:34 PM UTC

LesZedCB wrote: post #76

eru wrote: post #72

Earlier quoted context omitted.

> Actually, I think even Haskell still qualifies as imperative. How so?

Technically, if a language can produce side effects, it's considered imperative. However, nobody really is going to say that Haskell is imperative.

Haskell doesn't have side effects. It has effects. Side effects are effects that implicitly occur as a result of evaluation. That's why they're called side effects.