Why Racket? Why Lisp?
251–260 of 295 posts
Re: Why Racket? Why Lisp?
#252Earlier quoted context omitted.
> It is a pain to align a whole Haskell project according to new requirements to make the whole system work again. I'll quote a recent tweet by Chris Done: "I feel like 80% of Haskell advocacy should involve screencasts of people refactoring large codebases." In my experience, refactoring is easier with a strongly typed compiler, not harder. It may take more time and work to get your program to "run" again, but the e…
If it takes longer to refactor the program, that can kill the initiative to do so. When you do get the program to run, but it turns out that the refactoring is not wanted for whatever external reason, then you just wasted more time than was necessary. Without the bondage of static typing, you can just refactor a small enough fraction of the program, which can run now in some limited way. You can use that to motivate…
If it takes short to refactor the program but, because of the lack of safety checks, what seemed to be working "in some limited way" turns out to be a big ball of bug-ridden mud in the end, and maybe the whole approach wasn't sound, wouldn't that also kill motivation for future refactors? And what if keeping the motivation high for the more impulsive programmers leads to worse software?
Doesn't this look like something analogous to the old carpenter's motto: measure twice and cut once? "But I don't want to measure, I want to cut it now, it'll be faster! Measuring kills my motivation!" :)
Re: Why Racket? Why Lisp?
#253Earlier quoted context omitted.
> It is a pain to align a whole Haskell project according to new requirements to make the whole system work again. I'll quote a recent tweet by Chris Done: "I feel like 80% of Haskell advocacy should involve screencasts of people refactoring large codebases." In my experience, refactoring is easier with a strongly typed compiler, not harder. It may take more time and work to get your program to "run" again, but the e…
There are other ways of making refactoring easy. I'm not trying to dismiss a powerful type system - which is a great help indeed - but pervasive unit tests and contracts work as well. Linters are a nice addition, and even gradual typing like in Erlang with Dialyzer is much better than nothing. The point being: problems solved by type systems are being solved with other tools, too. I don't want to argue about how well…
Re: Why Racket? Why Lisp?
#254Earlier quoted context omitted.
If you write Lisp every day why not remap the ( and ) to a non-shifted position? I use the [ and ] keys but I use Common Lisp, not Clojure.
I find it odd that people use their pinky to type parens. When my fingers are on the home row, '(' is above my middle finger, and ')' is above my ring finger. Typing them with my pinky would require me to contort my hand.
Many people seem to type it the way you have just suggested (middle/ring) - myself included. I'm currently re-training myself to do that properly.. it feels weird at first, but I'm starting to get the feeling it will actually be faster.
Your touch typing can always be better, right?
Re: Why Racket? Why Lisp?
#255Earlier 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…
The editor is hooked directly up to a running image.. a keypress (or two) causes an expression to be executed in the running image... you can flip to the REPL and goof around directly and/or at the same time work from one or more editor buffers and selectively execute code as you desire. You can bust into the debugger whenever you feel like it, etc etc.
Someone else described it better above I think - but this image-based interaction is one of the most attractive things for many - it goes well beyond just having a REPL where you can evaluate code... lisp was basically designed around the idea of interactive development.
If you think this through to a large, complex project - you can have a giant running application, working in production, and still attach to it with an editor/environment and debug it live... that's hard to do with anything else.
Re: Why Racket? Why Lisp?
#256Agree with some of the earlier comments: the diamond-shaped thingies inserted are really a nuisance and breaks the reading flow.
Maybe only because it's unfamiliar. After all, other punctuation doesn't break your flow. And trying to figure out whether something is a link or not also breaks flow.
Re: Why Racket? Why Lisp?
#257I dislike this notion that Lisp (or Haskell or OCaml or ...) owe it to everyone else to explain and enunciate why it can be more productive to use Lisp. """ That’s asking too much. If Lisp languages are so great, then it should be possible to summarize their benefits in concise, practical terms. If Lisp advocates refuse to do this, then we shouldn’t be surprised when these languages remain stuck near…
It benefits both groups to to enlighten G. Since G is so much larger, that's how we would increase the library count from 2727 to 27280.
Re: Why Racket? Why Lisp?
#258Earlier quoted context omitted.
> I don't see any Lisp in the Go space (native compilation, great networking features) What?!? Proper Lisps compile to native code, both JIT and AOT. Plus there are quite a few code commercial compilers with networking libraries. http://franz.com/products/allegrocl/ Don't judge Lisps by the open source alternatives.
Sorry, instead of "native compilation" I actually should have said "compiles to a single static binary".
Re: Why Racket? Why Lisp?
#259Earlier quoted context omitted.
> I don't see any Lisp in the Go space (native compilation, great networking features) What?!? Proper Lisps compile to native code, both JIT and AOT. Plus there are quite a few code commercial compilers with networking libraries. http://franz.com/products/allegrocl/ Don't judge Lisps by the open source alternatives.
Sorry, instead of "native compilation" I actually should have said "compiles to a single static binary".
Re: Why Racket? Why Lisp?
#260Earlier quoted context omitted.
I program in Python for a living and I curse significant whitespace every single work day. Especially when I try to copy paste some code into the shell. It's one of the worst misfeatures of the language, and it wouldn't even be necessary if there was an "end" keyword.
Use IPython and %cpaste magic. Works well.