3 ms·
Contrary to some of the other comments appearing, for me this kind of thing is excellent. The biggest mental hurdle I find myself facing when learning new langu
by kolektiv 16y ago
Contrary to some of the other comments appearing, for me this kind of thing is excellent. The biggest mental hurdle I find myself facing when learning new languages and having got beyond the "hello world" stage is "how do I go from here to structuring an app?" An opinionated prescriptive guide is what I need then. When I know more later I can choose to go against the grain if I feel I understand the risks, but structuring projects varies a lot, and being helped to find the idiomatic way is great. It's a whole class of problem I now can ignore and concentrate on the design of my code.
It was a while before I understood how Erlang project structure worked. But I knew where to look. Ditto when I try things like Scala and Clojure (as I'm no longer familiar with Java, really). This is a good and useful step.
- cabalamat 16y ago> An opinionated prescriptive guide is what I need then. Indeed; it gives the default values for lots of things in the program / build environment / revision control, etc. One might of course later decide to change some of these settings, but one can be sure that none of the default settings are outright insane or likely to lead you up the garden path. I suspect one of the reasons Lisp hasn't broken out of being a niche language is that there is no default value to the question: Which Lisp shall I learn/use?
- ionfish 16y agoThat assumes that Lisp is a (singular) language. Lisp, to my mind, is a family of languages of a certain type, much like the statically-typed functional languages are a family. Choosing one Lisp over another is not like choosing which C compiler to use, it's more like choosing whether to use Python or Ruby.
- cabalamat 16y agoOK, let's say I decide to use Common Lisp. Then I have to decide what implementation to use. There isn't a default one like there is with Python or Ruby. Whichever one I choose, how can I know (and remember at this point I don't actually know CL) what libraries it has, what quality they are, whether there are libraries that work on other CLs but not this one, what debugging tools are available and what quaslity, whether it will work on the OS I use, whether it will work on the OS I will use in 5 years time (and I don't know what that will be), whether there are any other pitfalls with my choice, etc. For me to be sure I've made the right choice, I'd have to do weeks or months of research, including trying out the major varients. Fuck that. If I do learn a Lisp it'll be Clojure, because there's only one implementation.
- pjscott 16y agoIn case anybody is wondering, here's some information about Common Lisp that should make it easier to get started. Use SBCL; it's the most common and well-supported implementation. It works fine on most OSes (and has done so for years, and will continue to do so for the foreseeable future), though it's a bit dodgy on Windows. If you're using a Unix (including OS X), you'll be fine: http://www.sbcl.org/platform-table.html http://www.sbcl.org/platform-table.html The place to look for libraries is CLiki.net, and if you'd like to get started with minimum effort, then Quicklisp is exactly the library collection you're looking for: http://www.quicklisp.org/beta/ http://www.quicklisp.org/beta/ Quicklisp has all the common libraries, with easy installation and dependency management. For editing and debugging, it's hard to beat slime-mode in emacs. It's very slick and pleasant to work with. (Incidentally, this is also the most common way of editing Clojure, but it works more smoothly with Common Lisp. Much better stack traces, for example.) I'm enjoying using Clojure right now, but please don't be scared away from Common Lisp. It's got a lot going for it.
- Homunculiheaded 16y agoThis is exactly my feeling. I'm always surprised that it seems like no books or tutorials ever cover this area, the only way to find out is to dive into github and look through actual projects. Especially when I was newer to software I would have really appreciated a chapter in most books saying "oh and here's how we lay all this stuff out in the real world", I still really appreciate this since each language has many of it's own idioms. I'd been hoping to make Haskell a more 'real world' language for me and this will be a great place to start