Re: [dev] lisp
Alexander Sedov writes: > May I get links to your hard works or at least to your papers, or all > you have is some stuff you failed to sell to Yahoo, like that one guy? Wait, I thought he DID sell it, and now farms Chocobos over at Hacker News? I originally had links, but thought it gauche, but if you're gonna call me out: [1] http://www.webcheckout.net/in-use.html [2] https://github.com/strangeloop/clojurewest2013/blob/master/slides/sessions/Brozefsky-SQL_and_core.logic_Killed_My_ORM.pdf [3] http://ccl.northwestern.edu/netlogo One is a resource scheduling/mgmt and inventory control system for university media centers written from scatch in Common Lisp back in ~2000. The second is my current Clojure project, a large-scale malware analysis engine with an expert system built on core.logic. The last is a job I got because of being a lisp hacker, tho it was a Logo variant implemented in Java -- my job application was a module embedding Kawa Scheme, with scheme <-> Logo interop. > You must be really proud about making new tools for solving new > problems, except it's what programmers do, isn't it? Not really, it seems to mostly be text plumbing, and incomplete rediscovering of things that were invented in the 70s. >>> And no libraries. >> >> Trollolololol. > If your "Trolololol" means "you just cannot google", then links > please. People already posted links for CL repos, I would add clojars for Clojure stuff. > If however it does mean "tr00 programmers don't need > libraries", then I shall agree that Lisp is on par with Forth in that > it allows you to rewrite stuff that had already been written in other, > less ideal, languages, VERY elegantly. But some people need to write > something new, too. Never had a problem finding libraries to use, even back in the old days of CMUCL. The ones we ended up writing where the a bit rarer back then, functional SQL composition, ORMs, component based web frameworks, simulated annealing, genetic algos. and java->lisp interop. Standard stuff now, but not then. All the plumbing was already there. You know what DID suck tho, signal handling in CMUCL! Over the long haul I think in the CL world the plethora of half-finished, raw, parts of libraries was the real problem. Dissipated community effort, and NIH fragmented it. I think we didn't have a good model for modularity in CL, so there was a tendency towards heavy, "frameworks" instead of small, composable libraries. I think Clojure gets this much better. I prefer textuality instead of opaque composability. I like the approach Anselm laid out in his presentation about the future of dwm and a shared set of functions for drawing. > Having reread my answer, I apologize if you find it unusually rude, > but you are pronouncing the same empty words that I heard many times. I took it as a fellow cumrudgeonly troll, which is a bit of a tradition here. I always thought programmers needed to know two languages: One to talk to machines, and one to talk to humans (including themselves). C for machines, and a lisp for symbolic computation. I think that dichotomy stands up well, even if the dividing line moves around and is largely determined by the intent of the author and the context of deployment. -- Craig Brozefsky Premature reification is the root of all evil
Re: [dev] lisp
2013/7/2 Craig Brozefsky : > > Good morning, some good-natured trollbait to go with my coffee! > I've spent about half my professional career (15+ yrs) working on Lisp > products -- Common Lisp, and Clojure specifically. In both > cases, accomplishing what we had to do in the time we had would not have > been possible with the tools available in other languages at the time -- > we had to make new tools and take new approaches to solving the > problems. You know, we had to like do programming, motherfucker. [1] > > I would suggest the set of possible programs and programmers is much > larger than you perceive it to be. > > Or, maybe you're just fanning some flames for entertainment. May I get links to your hard works or at least to your papers, or all you have is some stuff you failed to sell to Yahoo, like that one guy? You must be really proud about making new tools for solving new problems, except it's what programmers do, isn't it? Also, the tools have really advanced in all that years, check them out. Nobody is writing in BCML anymore. There is nothing entertaining in the fact that my excitement over Lisp concepts one day met my disappointment that it provides no advantage whatsoever over other modern languages. I do recognize the value of Lisp in the history of programming languages, it served good, but I'm afraid this language family is no more. We should call it "ex-Lisp". > You DO realize that it's been passe to bitch about parens for > years. Also, you complain that lack of syntax in a language with first > class functions and macros and damn near unlimited control over phase(s) > of evaluation like Racket makes your work less 'terse' than you want -- > well, here's a nickle kid, get yourself a real program that writes > programs that writes programs that writes *your* program. 8^) What? I didn't bitch about parens. I bitched about getting an element of vector being a function with a long name, mostly. It's funny how you Lispers like to think that metaprogramming in-language is a feature unique to Lisp and not something adopted by, well, most of languages with level higher than C. Also, it won't save you from lack of terseness. You cannot get away from Kolmogorov length, and when you are doing Lisp, you need to count words instead of characters because (see above). >> And no libraries. > > Trollolololol. If your "Trolololol" means "you just cannot google", then links please. If however it does mean "tr00 programmers don't need libraries", then I shall agree that Lisp is on par with Forth in that it allows you to rewrite stuff that had already been written in other, less ideal, languages, VERY elegantly. But some people need to write something new, too. Having reread my answer, I apologize if you find it unusually rude, but you are pronouncing the same empty words that I heard many times. > [1] http://programming-motherfucker.com/ > > -- > Craig Brozefsky > Premature reification is the root of all evil > Thanks for the link, and nice signature.
Re: [dev] lisp
Good morning, some good-natured trollbait to go with my coffee! Alexander Sedov writes: > I personally consider it irrelevant. People just don't actually write > in Lisp, because it's either painful or results in slowness. Lisp is a > great language for teaching abstract CS concepts and language designs, > but that's it. I've spent about half my professional career (15+ yrs) working on Lisp products -- Common Lisp, and Clojure specifically. In both cases, accomplishing what we had to do in the time we had would not have been possible with the tools available in other languages at the time -- we had to make new tools and take new approaches to solving the problems. You know, we had to like do programming, motherfucker. [1] I would suggest the set of possible programs and programmers is much larger than you perceive it to be. Or, maybe you're just fanning some flames for entertainment. You DO realize that it's been passe to bitch about parens for years. Also, you complain that lack of syntax in a language with first class functions and macros and damn near unlimited control over phase(s) of evaluation like Racket makes your work less 'terse' than you want -- well, here's a nickle kid, get yourself a real program that writes programs that writes programs that writes *your* program. 8^) > And no libraries. Trollolololol. [1] http://programming-motherfucker.com/ -- Craig Brozefsky Premature reification is the root of all evil
Re: [dev] lisp
Andrew Gwozdziewycz dixit: >SBCL and Racket are certainly faster than Python, PHP, Ruby, Perl in most Less portable: http://packages.debian.org/sid/sbcl#pdownload bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Re: [dev] lisp
Hi, > Well, nowadays every toy language out there has CFFI, and it's far > less pleasant to use than native libraries. I have nothing to say True, but have you ever tried to use any of it? I did and I have to say that 99% of them are half baked solutions just to satisfy examples. Even for more popular languages, situation is not better much; the only solid implementations (which could handle even dark corners) I found are ctypes for python and cffi for CL. > about Java library stack because I haven't used it, bu I doubt its > usage is seamless. Correct me if I'm wrong. Really? These days I'm using Selenium for some u.tests; google Selenium examples in java (or ruby/python) and see how much of it you can express with clj-webdriver (Clojure wrapper). Or if I we move to Swing-land, I can talk about it all day long ;) Best.
Re: [dev] lisp
2013/7/2 Andrew Gwozdziewycz : > SBCL and Racket are certainly faster than Python, PHP, Ruby, Perl in most > cases. SBCL, since it is more or less an interactive native code compiler is > faster yet. You'll have to qualify painful. Are you referring to syntax? If > so, no Lisper even sees parentheses. Nah, I like parens, and I understand that they are usually made as pale as possible, and all text editors do everything to make you write less parens by yourself. What I was referring to is -no consistent OS interface, -keywords straight from the land of CREAT, and -funky (personal opinion here) abstractions of Common Lisp. Racket is great, as it is Scheme implementation that is not slow, but the absence of syntax still makes programs a bit less terse than I like them to be. > Yes, the Racket (previously PLT Scheme) has certainly made it even more > viable, but they've also made a practical, quality implementation for real > work. Many other Lisps are similar, certainly many of the Common Lisps. Yet there is apparently nothing non-proof-of-concept-y written in Racket, which is sad. Maybe it's because Racket still provides nothing other than theoretical beauty compared to C, as all other Schemes do? There is just no niche for it. > I urge you to check out Quicklisp (for Common Lisp, > http://www.quicklisp.org/) and reevaluate your statement. While the > Quicklisp + other Common Lisp library repos aren't as exhaustive as CPAN, > they usually contain very high quality code (unlike CPAN, or PyPi, or > whatever the fuck PHP and Ruby use). The fact that "nobody uses Lisp" is a > huge advantage since the people who do are actually smart and very > productive. Or have nothing better to do... Quicklisp is splendid. 700 packages, about a half of which are some network protocol wrappers, and others are numeric utils in experimental state, image handling, and html5 parsing. So, all in all, Common Lisp looks like glue language with all these packages. Do we seriously need another poorly supported glue language with a small amount of libraries? And I don't really care for the quality of library code as long as it works and has tolerable API. > You should not forget Kawa, Clojure and ABCL from where you have > access to all java library stack. And there is CFFI, implemented by almost > all Common Lisp implementation, from where you can access all shared > libraries installed on the system. > > Best. Well, nowadays every toy language out there has CFFI, and it's far less pleasant to use than native libraries. I have nothing to say about Java library stack because I haven't used it, bu I doubt its usage is seamless. Correct me if I'm wrong.
Re: [dev] lisp
>> And no libraries. > > I urge you to check out Quicklisp (for Common Lisp, > http://www.quicklisp.org/) and reevaluate your statement. While the > Quicklisp + other Common Lisp library repos aren't as exhaustive as CPAN, > they usually contain very high quality code (unlike CPAN, or PyPi, or > whatever the fuck PHP and Ruby use). The fact that "nobody uses Lisp" is a > huge advantage since the people who do are actually smart and very > productive. You should not forget Kawa, Clojure and ABCL from where you have access to all java library stack. And there is CFFI, implemented by almost all Common Lisp implementation, from where you can access all shared libraries installed on the system. Best.
Re: [dev] lisp
On Tue, Jul 2, 2013 at 7:11 AM, Alexander Sedov wrote: > 2013/6/29 oneofthem : > > is there any reason why lisp isn't mentioned much in the suckless > > community? > > considered irrelevant, harmful or what? > I personally consider it irrelevant. People just don't actually write > in Lisp, because it's either painful or results in slowness. SBCL and Racket are certainly faster than Python, PHP, Ruby, Perl in most cases. SBCL, since it is more or less an interactive native code compiler is faster yet. You'll have to qualify painful. Are you referring to syntax? If so, no Lisper even sees parentheses. Lisp is a > great language for teaching abstract CS concepts and language designs, > but that's it. > Yes, the Racket (previously PLT Scheme) has certainly made it even more viable, but they've also made a practical, quality implementation for real work. Many other Lisps are similar, certainly many of the Common Lisps. > And no libraries. > I urge you to check out Quicklisp (for Common Lisp, http://www.quicklisp.org/) and reevaluate your statement. While the Quicklisp + other Common Lisp library repos aren't as exhaustive as CPAN, they usually contain very high quality code (unlike CPAN, or PyPi, or whatever the fuck PHP and Ruby use). The fact that "nobody uses Lisp" is a huge advantage since the people who do are actually smart and very productive. -- http://apgwoz.com
Re: [dev] lisp
2013/6/29 oneofthem : > is there any reason why lisp isn't mentioned much in the suckless > community? > considered irrelevant, harmful or what? I personally consider it irrelevant. People just don't actually write in Lisp, because it's either painful or results in slowness. Lisp is a great language for teaching abstract CS concepts and language designs, but that's it. And no libraries.
Re: [dev] lisp
On Mon, Jul 1, 2013 at 4:27 PM, Craig Brozefsky wrote: > Andrew Gwozdziewycz writes: > > >Lisps are loaded with this sort of stuff, and while I love it, and > >enjoy using them thinking about them, reading about them, they just > >aren't practical for mortals who are used to PHP. > > You keep confusing simple and easy. > > http://www.infoq.com/presentations/Simple-Made-Easy > > Many other things which "aren't practical for mortals" such as > logic/functional/declarative programming, immutable data structures, > agents, STM, and async channels are very simple -- even if they are > difficult to grasp and map into previous experiences.\ > You're right, I am conflating the two terms. And you are right in that they are often simple. They are not only simple, they make radically simpler programs. Taken > together, they also enable programs that would be outrageously complex, > and error prone in "easy" languages. > Right. One of the goals of tin is to make it "easy" to utilize these "simple" things--and maybe that even means hiding them away. We'll see. -- http://apgwoz.com
Re: [dev] lisp
Andrew Gwozdziewycz writes: >Lisps are loaded with this sort of stuff, and while I love it, and >enjoy using them thinking about them, reading about them, they just >aren't practical for mortals who are used to PHP. You keep confusing simple and easy. http://www.infoq.com/presentations/Simple-Made-Easy Many other things which "aren't practical for mortals" such as logic/functional/declarative programming, immutable data structures, agents, STM, and async channels are very simple -- even if they are difficult to grasp and map into previous experiences. They are not only simple, they make radically simpler programs. Taken together, they also enable programs that would be outrageously complex, and error prone in "easy" languages. -- Craig Brozefsky Premature reification is the root of all evil
Re: [dev] lisp
On Sat, Jun 29, 2013 at 1:35 PM, Louis-Guillaume Gagnon < louis.guillaume.gag...@gmail.com> wrote: > 2013/6/29 Andrew Gwozdziewycz : > > I don't speak for the suckless community, but despite the fact that I > love > > it, Lisp is complicated and not very simple at all > > It's worth noting that the R5RS scheme standard is only ~50 pages > long: http://www.schemers.org/Documents/Standards/R5RS/ > In comparison, the C99 standard is ~550 pages. I would say that the > scheme dialect is pretty simple. > > 50 pages of spec does not a simple dialect make. Sure, it defines a tiny core, but it demands fully hygienic macros (recommending `syntax-rules`) and continuations. `syntax-rules` macros don't allow you to capture bindings at all, which is impractical enough that R6RS (and many implementations) adopted `syntax-case` (and subsequently implemented `syntax-rules` in terms of it), which is just painful and complex to use. `syntax-rules` macros, while declarative and arguably more maintainable, is actually it's own language, and breaks you out of the "Scheme" flow. Don't even get me started on the "simplicity" of continuations. There's a trove of literature on them which refutes that. -- http://apgwoz.com
Re: [dev] lisp
On Sat, Jun 29, 2013 at 12:12 PM, Craig Brozefsky wrote: > Andrew Gwozdziewycz writes: > > >I don't speak for the suckless community, but despite the fact that I > >love it, Lisp is complicated and not very simple at all, which I'm > >guessing is why you don't hear about it. I'm currently playing around > >with attempting to make a minimal, embeddable, unix friendly, without > >complications dialect, called tin. I have no idea if I'll succeed in > >any of those goals, but it'll be fun regardless. > > Fun project, but I disagree 8^) > > Lisps (and I include scheme varianets in this) are very simple languages > for the most part -- with obvious exceptions like Common Lisp. Minimal > syntax, a few natve data types, programs are code, and functional > composition. > > The runtimes however can vary in complexity depending upon their > implementation goals. Highly performant lisp means an intelligent > compiler. A common lisp design trope is to pay complexity costs in > implementation for maximizing simplicity of use. > I include Scheme as well when I reference Lisp--also Clojure. While I agree that Scheme is relatively simple, this simplicity doesn't really bring much to anyone. Anyone trying to make practical programs in scheme must go past the standard, and seek an implementation the basis to be able to support the practical goals. There's a million and 1 implementations, and they all have various warts and reasons why you might not want to use them. I can't imagine trying to sanely embed Chicken, for instance. I can imagine writing a scheme program that utilizes the FFI to produce an executable directly from Chicken, of course. But, then the entire program is exposed to the "Cheney-on-the-MTA" technique, which certainly has some overhead compared to the finally tuned C, sprinkled with some of the embedded language approach. Racket is just plain huge. It's goals don't align with simplicity at all. Gambit, and the rest of the "compile to C" Schemes just don't have a big enough community to make it possible to *not* have to do everything yourself. And, none of these really play nicely with POSIX, and if they have some layer of compatibility, it's completely awkward to use. Common Lisp suffers from the same sorts of things. It's spec is hundreds of pages, and is that way for portability and practicality--only it doesn't define anything related to the OS, which means again, the implementation must provide it, and every implementation provides it slightly different. This requires packages that exist to conditionally do the right thing across the various warts of each implementation... Not very simple. Clojure--well, just being on the JVM complicates that for practical purposes. If you consider Go, Python, Lua--even Perl, they have relatively few concepts that one needs to learn to utilize before they become really productive languages. You don't have to worry about how to specify filesystem paths as in Common Lisp, because in these other languages you just do it. Maybe they provide you with a library that helps be portable (Python for instance has os.sep, which is either '/' or '\' depending on POSIX vs Windows), but you just don't give a shit most of the time. In Scheme, I can't break out of a loop without understanding continuations, or restructuring loop such that conditions that should break me out of the loop are flagged in a recursive "final step" sort of way. Lisps are loaded with this sort of stuff, and while I love it, and enjoy using them thinking about them, reading about them, they just aren't practical for mortals who are used to PHP. Final thought: Have you ever actually tried to embed Guile? Oh man, is that fun. (And, I LOVE Guile) Tinyscheme is a much better experience when embedding, but it's not exactly a practical implementation... -- http://apgwoz.com
Re: [dev] lisp
Hi, On Sat, Jun 29, 2013 at 10:52 PM, Szabolcs Nagy wrote: > r5rs is much more limited in scope than c99, it has a synthetic > design that provides the bare minimum to express high level > computations, while c99 has an ugly pragmatic design, the result > of long evolution and contradicting constraints > > the scheme spec does not give you enough semantics to reason > about resource usage, latency of operations or to handle > related failures, it cannot control the interaction with the > underlying system without serious language extensions Hm, not quite true: there are enough semantics so you can perform IO, computations (R5RS provides fine model for it) or error/failure handling. However, Scheme abstract those operations to much higher level than C. Also, C isn't much useful without libc and POSIX api either... > this is not a big problem for scheme as it is not a > systems programming language, but a scripting language > > i think the lack of syntax in scheme helps understanding > certain concepts (and makes the spec simpler), but is not > comfortable in practice, a language like lua (with simple > syntax for associative arrays) goes a long way to be more > practical Again, more subjective... We (developers and users) today are more used to think in terms of hardware and hardware approach of computation than mathematical and abstract. > but the fundamental reason why we see more mention of c than > lisp is that all relevant operating systems have a unix like > api for which the only detailed spec is posix, a superset of > c99, while a lisp implementation needs to do a lot to bridge > the gap and its abstractions are leaky and costly 'abstractions are leaky and costly'? How so? If you thing in terms of using POSIX systems from Lisp, it is unnatural, the same as you would try to use Genera (or other Lisp OS) from C. But, if you try another, more abstract approach, things aren't that scary. For example, instead: (define var (fopen "/foo/baz" "r")) (if var ...) you could use: (with-open "/foo/baz" ... ;; or catch errors if you would like (catch ... here goes error handling)) > but there is good news for those who think c is bad: there are > emerging platforms which may give rise to different languages: > jvm on mobile and enterprise systems and the web with js.. Best, Sanel
Re: [dev] lisp
On Sat, 29 Jun 2013 17:11:42 -0400 Jacob Todd wrote: > how is that good news? that's horrible news. (That's the joke.) signature.asc Description: PGP signature
Re: [dev] lisp
On Sat, Jun 29, 2013 at 4:52 PM, Szabolcs Nagy wrote: > but there is good news for those who think c is bad: there are > emerging platforms which may give rise to different languages: > jvm on mobile and enterprise systems and the web with js.. > how is that good news? that's horrible news.
Re: [dev] lisp
* Louis-Guillaume Gagnon [2013-06-29 13:35:58 -0400]: > It's worth noting that the R5RS scheme standard is only ~50 pages > long: http://www.schemers.org/Documents/Standards/R5RS/ > In comparison, the C99 standard is ~550 pages. I would say that the > scheme dialect is pretty simple. r5rs is much more limited in scope than c99, it has a synthetic design that provides the bare minimum to express high level computations, while c99 has an ugly pragmatic design, the result of long evolution and contradicting constraints the scheme spec does not give you enough semantics to reason about resource usage, latency of operations or to handle related failures, it cannot control the interaction with the underlying system without serious language extensions this is not a big problem for scheme as it is not a systems programming language, but a scripting language i think the lack of syntax in scheme helps understanding certain concepts (and makes the spec simpler), but is not comfortable in practice, a language like lua (with simple syntax for associative arrays) goes a long way to be more practical but the fundamental reason why we see more mention of c than lisp is that all relevant operating systems have a unix like api for which the only detailed spec is posix, a superset of c99, while a lisp implementation needs to do a lot to bridge the gap and its abstractions are leaky and costly but there is good news for those who think c is bad: there are emerging platforms which may give rise to different languages: jvm on mobile and enterprise systems and the web with js..
Re: [dev] lisp
2013/6/29 Andrew Gwozdziewycz : > I don't speak for the suckless community, but despite the fact that I love > it, Lisp is complicated and not very simple at all It's worth noting that the R5RS scheme standard is only ~50 pages long: http://www.schemers.org/Documents/Standards/R5RS/ In comparison, the C99 standard is ~550 pages. I would say that the scheme dialect is pretty simple.
Re: [dev] lisp
Andrew Gwozdziewycz writes: >I don't speak for the suckless community, but despite the fact that I >love it, Lisp is complicated and not very simple at all, which I'm >guessing is why you don't hear about it. I'm currently playing around >with attempting to make a minimal, embeddable, unix friendly, without >complications dialect, called tin. I have no idea if I'll succeed in >any of those goals, but it'll be fun regardless. Fun project, but I disagree 8^) Lisps (and I include scheme varianets in this) are very simple languages for the most part -- with obvious exceptions like Common Lisp. Minimal syntax, a few natve data types, programs are code, and functional composition. The runtimes however can vary in complexity depending upon their implementation goals. Highly performant lisp means an intelligent compiler. A common lisp design trope is to pay complexity costs in implementation for maximizing simplicity of use. I think the classic "Worse Is Better" essay by Gabriel is worth checking out. Here is an excerpt: I and just about every designer of Common Lisp and CLOS has had extreme exposure to the MIT/Stanford style of design. The essence of this style can be captured by the phrase ``the right thing.'' To such a designer it is important to get all of the following characteristics right: Simplicity-the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation. Correctness-the design must be correct in all observable aspects. Incorrectness is simply not allowed. Consistency-the design must not be inconsistent. A design is allowed to be slightly less simple and less complete to avoid inconsistency. Consistency is as important as correctness. Completeness-the design must cover as many important situations as is practical. All reasonably expected cases must be covered. Simplicity is not allowed to overly reduce completeness. I believe most people would agree that these are good characteristics. I will call the use of this philosophy of design the ``MIT approach.'' Common Lisp (with CLOS) and Scheme represent the MIT approach to design and implementation. The worse-is-better philosophy is only slightly different: Simplicity-the design must be simple, both in implementation and interface. It is more important for the implementation to be simple than the interface. Simplicity is the most important consideration in a design. Correctness-the design must be correct in all observable aspects. It is slightly better to be simple than correct. Consistency-the design must not be overly inconsistent. Consistency can be sacrificed for simplicity in some cases, but it is better to drop those parts of the design that deal with less common circumstances than to introduce either implementational complexity or inconsistency. Completeness-the design must cover as many important situations as is practical. All reasonably expected cases should be covered. Completeness can be sacrificed in favor of any other quality. In fact, completeness must sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface. Early Unix and C are examples of the use of this school of design, and I will call the use of this design strategy the ``New Jersey approach.'' I have intentionally caricatured the worse-is-better philosophy to convince you that it is obviously a bad philosophy and that the New Jersey approach is a bad approach. However, I believe that worse-is-better, even in its strawman form, has better survival characteristics than the-right-thing, and that the New Jersey approach when used for software is a better approach than the MIT approach. Worse is Better - Richard Gabriel http://www.jwz.org/doc/worse-is-better.html -- Craig Brozefsky Premature reification is the root of all evil
Re: [dev] lisp
I don't speak for the suckless community, but despite the fact that I love it, Lisp is complicated and not very simple at all, which I'm guessing is why you don't hear about it. I'm currently playing around with attempting to make a minimal, embeddable, unix friendly, without complications dialect, called tin. I have no idea if I'll succeed in any of those goals, but it'll be fun regardless. On Sat, Jun 29, 2013 at 7:23 AM, oneofthem wrote: > is there any reason why lisp isn't mentioned much in the suckless > community? > considered irrelevant, harmful or what? > > > -- http://apgwoz.com
[dev] lisp
is there any reason why lisp isn't mentioned much in the suckless community? considered irrelevant, harmful or what?
