Earlier quoted context omitted.
> It's a language designed by committee, and it looks like it. This means nothing. When a design succeeds, we say it was designed by the community; when it fails, by committee. You can produce examples for any language: In Common Lisp the committee that designed it and the community of previous Lisp users that backed it. For Python, the community of users and Guidos' mailing list pals. There is nothing inherently sup…
I think a good reference for what people mean by "designed by committee" is to look at the reference spec for a language. I remember picking up the Common Lisp reference book in my college library. It was one of the thickest books in the entire CS section. Obviously much thicker than any books on Scheme, but even on the same level as "The C++ Programming Language". And the latter spends a lot more time explaining thi…
Dylan: the harsh realities of the market
31–40 of 120 posts
Re: Dylan: the harsh realities of the market
#32I'm the Bruce that he mentioned in the post. For better or worse, I've been pushing Dylan forward heavily over the last few years and am effectively the primary maintainer. Over the last couple of years, we've made a lot of progress. We've completely revived the documentation from 1990s era FrameMaker files and have it published via a pretty modern system. We've converted from SVN to Git and moved to GitHub. We've do…
Re: Dylan: the harsh realities of the market
#33If you're going to rant, you might want to actually have a clear point to make. > college kids on comp.lang.lisp asking for the answers for problem-set 3 on last night's homework Surely not during the Naggum days. CLL was a hostile wasteland. > That is the lesson of perl and python and all these other languages. They're not good for anything. They suck. And they suck in libraries and syntax and semantics and weirdnes…
this. playing with CL inside CL is fun and nice. As soon as you try to interface with the outside world, and actually do almost anything you run into trouble. I mean an FS api that was designed before we solidified on hierarchical filesystems? Lisp does not play nice or well or easily with the outside environment it is running on. (in my experience)
it can be an ugly language, but if it has all the libraries, then you can get so much more done so much quicker with so much work done for you, people will go there.
Again, some little progress has started with things like quicklisp finally starting to provide a better (or first proper) package management system for CL like most newer languages have all had, but still. little and late. But given time and work maybe resuscitateable. We'll see
Re: Dylan: the harsh realities of the market
#34> Algebraic types? Dependent types? You'll never see them. They're too ... research-y. They stink of academe, which is: they stink of uselessness-to-industry. One may think that because closures are finally entering the mainstream (after what, 5 decades?), we have hope for those things to come as well. But then I saw Swift. Built-in support for an Option type, so one can avoid null pointer exceptions. At the same tim…
> But then I saw Swift. Built-in support for an Option type, so one can avoid null pointer exceptions. At the same time, this languages manages to recognize the extreme usefulness of algebraic data types, without using them in their full generality. Like, why bother with a generic feature when we can settle for an ad-hoc one? Swift has the syntax to define arbitrary algebraic datatypes, even if it doesn't yet work in…
Furthermore, Swift doesn't support enough laziness/deferral/coalgebraic formulation to have, say, an infinite stream type without breaking GCD. These will probably be fixed in time, but Swift's ADT support is still pretty experimental to say the least.
Re: Dylan: the harsh realities of the market
#35I'm the Bruce that he mentioned in the post. For better or worse, I've been pushing Dylan forward heavily over the last few years and am effectively the primary maintainer. Over the last couple of years, we've made a lot of progress. We've completely revived the documentation from 1990s era FrameMaker files and have it published via a pretty modern system. We've converted from SVN to Git and moved to GitHub. We've do…
It sounds like you care not only about Dylan but also about advancing programming language construction in general. Have you considered writing, e.g., blog posts about design decisions you make as you work on Dylan? Maybe it would help other people learn from your work.
I don't usually bother to post them on HN as I don't have the time to try to get something on the front page (otherwise, no attention). I do post them on r/lisp though or lobste.rs usually.
I've got a couple of posts in draft stage now that I hope to publish this week or next.
Re: Dylan: the harsh realities of the market
#36Earlier quoted context omitted.
> closures are finally entering the mainstream (after what, 5 decades?) 8 decades, to be precise. They predate electronic computing - Church published his original paper in 1932. It still amazes me that it's only in the past few years that widely-used languages have begun adopting them.
Elements of the idea were in Church's work, but I think it wasn't until the 1960s that anyone thought of closing a lambda by using the lexical environment to bind its free variables. And it wasn't until the 1970s that Sussman and Steele really drove the idea home with Scheme. Before then even LISP didn't have closures. It was based on Church's ideas, and it did need to deal with figuring out how to bind a lambda's va…
Re: Dylan: the harsh realities of the market
#37Earlier quoted context omitted.
> It's a language designed by committee, and it looks like it. This means nothing. When a design succeeds, we say it was designed by the community; when it fails, by committee. You can produce examples for any language: In Common Lisp the committee that designed it and the community of previous Lisp users that backed it. For Python, the community of users and Guidos' mailing list pals. There is nothing inherently sup…
I think a good reference for what people mean by "designed by committee" is to look at the reference spec for a language. I remember picking up the Common Lisp reference book in my college library. It was one of the thickest books in the entire CS section. Obviously much thicker than any books on Scheme, but even on the same level as "The C++ Programming Language". And the latter spends a lot more time explaining thi…
And many of the people involved with that were also involved with the Common Lisp standardization (like David Moon, Scott Fahlman, etc).
Common Lisp is a pretty interesting example, but due to the politics of the various companies involved, the vast amounts of code in each of the various Lisps, and so on, I don't think it is a fair reflection on "designed by committee". It is just what that committee was able to design given the constraints imposed upon them.
In many ways, Dylan was a stripped down and much more minimal Common Lisp, but with aspects of Scheme as well. But Dylan was designed from a green field, while Common Lisp was designed with a number of existing Lisps in mind that each had a stake.
Re: Dylan: the harsh realities of the market
#38Erlang: see 'career wrecker.'
Please. Someone, wreck my career some more.
Unlike Dylan Erlang was created by a company for a purpose with very clear goals and it did and still excels at meeting those goals, and nothing out there gets close to the qualities it has. Not everyone needs those qualities, but sometimes nothing will do. Erlang is at the core of many solid industrial applications -- mobile to internet gateways, message queues, trading systems, large databases, handling millions of concurrent connection and billions of messages per day for WhatsApp.
What does Dylan do? This is the second time I heard about Dylan. I've played with Mercury, Prolog, Nimrod, Curry (Haskell + Logic programming) and other rather obscure languages but haven't heard about Dylan much.
Some languages just don't make it, sometimes it is just luck. However I don't like the disparaging and angry remarks thrown around at other languages and ecosystems. That does nothing to promote Dylan it only pushes people away.
Re: Dylan: the harsh realities of the market
#39If you're going to rant, you might want to actually have a clear point to make. > college kids on comp.lang.lisp asking for the answers for problem-set 3 on last night's homework Surely not during the Naggum days. CLL was a hostile wasteland. > That is the lesson of perl and python and all these other languages. They're not good for anything. They suck. And they suck in libraries and syntax and semantics and weirdnes…
That's a really outdated meme. CPAN is small, pretty much every language you hear about regularly has a larger package space than CPAN. Even Go's package space is bigger than CPAN's. JS and Java each have package spaces roughly 3x CPAN's size.
Re: Dylan: the harsh realities of the market
#40> These languages are defined, right there in the dictionary. Erlang: see 'career wrecker.' Please. Someone, wreck my career some more. Unlike Dylan Erlang was created by a company for a purpose with very clear goals and it did and still excels at meeting those goals, and nothing out there gets close to the qualities it has. Not everyone needs those qualities, but sometimes nothing will do. Erlang is at the core of m…
I'm totally unfair here, because I really don't know much about Dylan, but my view maybe explains a bit why Dylan does not even "win" with people like me, who really like those strange languages like Lisp or ML.
To me, Dylan was never about creating something new and great. It was taking Common Lisp and "fixing" its syntax.
Unfortunately, I can't stand Lisp without prefix notation and lots of parentheses. And people who hate prefix notation and lots of parentheses aren't interested too much in Common Lisp.
The resulting set of people interested in Dylan was... well, I've heard of Bruce. Andreas Bogk was doing some heavy advocacy in Germany, to the point where people just didn't want to listen anymore.
Let's say about ten people in the world cared. And I just don't see how that set could grow by orders of magnitude.