Live data from Hacker News

How to write Common Lisp in 2017 – an initiation manual

articulate-lisp.com

231–240 of 271 posts

Re: How to write Common Lisp in 2017 – an initiation manual

#231

Earlier quoted context omitted.

I'll take a stab at this glib comment: 1. You've inherited an application written in Common Lisp 2. Common Lisp has features you find desirable that aren't available in another system 3. You like Common Lisp 4. Common Lisp helps you get the thing you're trying to do, done

You can replace "Common Lisp" with any other language and these points still stand (at least in a tautological, nonsensical way).

Those are the kind of answers "glib" questions tend to get in response.

Re: How to write Common Lisp in 2017 – an initiation manual

#232
post #46

Some notes based on my (brief) experience toying with Common Lisp: * Why hasn't anyone made a more eye-frendly version of the Common Lisp Hyper Spec ? Having good, easily-browsable documentation is a core-problem. * The relation between the various native data-types were quite unclear to me. * dealing with the external world was quite a mess. Many project/libraries implementing only half of something and then got aba…

> * The relation between the various native data-types were quite unclear to me. http://sellout.github.io/media/CL-type-hierarchy.png

> http://sellout.github.io/media/CL-type-hierarchy.png

Indeed.

Take for example base-char, which is a type.

base-char derives (derives? the straight solid black line is not represented in the legend) from character, which is a built-in class (according to legend).

So is character a class too? does base-char encapsulate a character or something like it?

Before anyone comment, please keep in mind that this comment doesn't want to start a flame or be critical in any way.

Re: How to write Common Lisp in 2017 – an initiation manual

#233

Earlier quoted context omitted.

Not speaking for hydandata, a few key points of CL as opposed to Clojure (which might be advantages or disadvantages depending on context and preference) include: - Defined by a standard (the text of the standard is available for free online as the Common Lisp HyperSpec [1]), not by a reference implementation led by a BDFL - Multiple mature implementations, both free and proprietary - Wholeheartedly multi-paradigm; h…

> Defined by a standard How does this help, compared to Clojure? > Multiple mature implementations Why wouldn't one free mature implementation be good enough? > Wholeheartedly multi-paradigm Exactly like Clojure. > "Lisp-2" rather than "Lisp-1" I can't remember which one Clojure is :) But I haven't had any problems with namespaces and the like. > Designed for implementation in a wide variety of environments So is Clo…

> > Wholeheartedly multi-paradigm

> Exactly like Clojure.

Clojure is definitively not multi-paradigm. The only blessed by the developers/community paradigm is functional.

Re: How to write Common Lisp in 2017 – an initiation manual

#234
post #232

Earlier quoted context omitted.

> * The relation between the various native data-types were quite unclear to me. http://sellout.github.io/media/CL-type-hierarchy.png

> http://sellout.github.io/media/CL-type-hierarchy.png Indeed. Take for example base-char, which is a type. base-char derives (derives? the straight solid black line is not represented in the legend) from character, which is a built-in class (according to legend). So is character a class too? does base-char encapsulate a character or something like it? Before anyone comment, please keep in mind that this comment does…

https://pbs.twimg.com/media/C56V5kyWMAAi0DD.jpg

Blue are CLOS classes. Brown are structure classes. Red are built-in classes. Black are types without any classes.

This is the hierarchy for types in LispWorks, packages CLOS and CL.

Re: How to write Common Lisp in 2017 – an initiation manual

#235
post #117

I've been working on a CL project for a couple of years. Was my first big stab at using CL for something other than a toy. Sbcl is a nice choice, but far from the only option. It has many tradeoffs. CL is not without its frustrations. Documentation that has not aged well. A community that can be less than welcoming. (in contrast to say the Racket community) Inconsistencies, e.g. first, nth, elt, getf, aref... However…

This talks about GC settings that worked for them in SBCL for production, not sure if you already tried the same kind of stuff but may be an interesting read http://tech.grammarly.com/blog/posts/Running-Lisp-in-Product....

If you can make an easy to run example of the garbage collector not working correctly, the folks in #sbcl on freenode are very responsive and have commit access to fix it.

Re: How to write Common Lisp in 2017 – an initiation manual

#236

I started a big project at work using Common Lisp in 2017 and could not be happier. Sure, most nice features have trickled down to other languages, but they are rarely as nicely integrated. And Lisp still has many advantages that are not found elsewhere: Unmatched stability, on-demand performance, tunable compiler, CLOS, condition system, and Macros to name a few. It has its warts too but which language does not? I f…

Can you elaborate on your use case?

Re: How to write Common Lisp in 2017 – an initiation manual

#237
post #230
post #75

Earlier quoted context omitted.

I'd put that one under type safety, and it definitely seems bizarre to me to make a new language that claims to have strong, static typing and allow arbitrary types, or pointers to arbitrary types to be null.

Go's nil is statically-typed. The nil keyword is polymorphic (as numbers in the source code are) but individual nils that occur at runtime in Go are actually typed. You can actually put methods on them and they execute just fine: type S struct{} func (s *S) Test() { if s == nil { fmt.Println("Nil pointer") } else { fmt.Println("Not nil pointer") } } func main () { var p *S p.Test() } That will print "Nil pointer", no…

The type of s/p there can't be guaranteed to be (S not nil) at compile time, which is a bizarre decision in an otherwise-statically-typed language where the type system is designed to provide runtime type safety. You still have to do a null check at runtime if you want to be safe here

While it's nicer that you can perform the check inside Test() instead of before the call, I don't understand why the type system doesn't just prohibit this and make you use a union type if you want (S or nil) given that a lot more situations call for (S not nil) than (S or nil).

Re: How to write Common Lisp in 2017 – an initiation manual

#238

Wondering if anyone has any experience using lisp for machine learning? I'm aware of mgl[0], but it seems to be abandoned. The lack any wrappers for tensor flow or caffe is also a bit surprising to me. The cliki page [1] is also unhelpful and out of date. Is machine learning on lisp dead or are there projects out there that I'm just not aware of? [0] https://github.com/melisgl/mgl [1] http://www.cliki.net/machine%20l…

Not directly, but have been following various projects over the years..

My take on this is that the people using CL for machine learning have been doing this for some time, and so have their own toolsets; tensor flow is relatively new in that regard, and w/r/t lisp interfacing would entail low-level binary interfacing (and therefore mostly non-portable between implementations) to hook CL code with tensorflow kernels (definately not an expert here on either however).

also, what is popularly referred to as 'machine learning' is in my opinion mostly only one aspect of the field - e.g. classification neural networks - while lisp can definitely do this, lisp AI programming (in my amateur opinion) shines more in the realm of machine reasoning/inference due to the symbolic / dynamic nature of the environment - e.g. constructing a set of reasoning primitives (e.g. functions and facts and decision trees) and a meta-interpreter to reason/infer about external data and walk around a problem space.. also, owing to the dynamic and rapid development nature of the language, likely many people are working with their own prototype/core frameworks, possibly cobbled together from various small bits and pieces of 3rd party code. Also, neural networks have been around for quite a while - what these new frameworks bring to the table is not so much new core algorithms, but the ability to quickly cobble them together in a more popular/user friendly way, and also take advantage of fast hardware (e.g. GPUs)

as for projects - in the general sense, lisp has been a latecomer to the 'languages with cpan-style trove of public addon modules' crowd, owing in my opinion to the need to support multiple implementations in order for such a project to take hold - so older but yet still quite functional libraries might be around in various hodge-podge repositories which are not standardised but old timers have already included in their own local systems, etc. (see also CMU AI repository)

In the last few years, much has been done in the module space - I would definately consider 'quicklisp' to be roughly the defacto definitive list of current modules, especially those under active development, since the active community is basically converging on this as a module/distribution platform and so many (most?) active community projects are available as quicklisp modules and included here - and so would probably be the one of the first places to start in checking into for available libraries for any topic.

Also, the best way to 'explore' quicklisp is to install it, and then install various packages and then muck around/explore with the source code that they download into your environment - the documentation tends to be much less 'external' (e.g. websites) and much more 'internal' (e.g. READMEs, in-tree code examples or unit tests).

https://www.quicklisp.org/beta/releases.html

Re: How to write Common Lisp in 2017 – an initiation manual

#239

Earlier quoted context omitted.

Honestly I don't think Emacs is an obstacle to people who use Vim. It's an obstacle to people who use IDEs

I use(d) vim and see EMacs as annoying.

I use vi and emacs and see vim as some odd vi that is trying to be emacs but ends up being neither.

Re: How to write Common Lisp in 2017 – an initiation manual

#240

Earlier quoted context omitted.

R is pretty pointless though. Unless you want to rewrite everything between prototyping in R and real deployment with a real language, you are better off writing in Python.

That right there is what I am talking about. I make a point and people have to attack that that the language is pointless when it is the number one language in that domain, which just happened the last two years. Why would you ever have to rewrite the code? Python isn't faster and has less function then R and if you want you can just drop a few lines of Python in a cell of a Notebook. I like Python and its a good cho…

R is useful only more in pure analysis - interfacing to other systems and dealing with application/control logic is not it's strong point, so unless you are embedding R into a larger project (e.g. R batch scheduler), if you need these features, you'll likely need to rewrite.
Post reply on HN