Dylan: the harsh realities of the market • Hacker News Board

Re: Dylan: the harsh realities of the market

#41

Post by calibraxis » Tue, Aug 26, 2014, 4:44 AM UTC

rtpg wrote: post #29

eudox wrote: post #26

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…

> I'm still not sure why there are 80 different ways to loop

Please ignore if you're asking rhetorically. But there are reasons why it was put together in kind of a wild political dash. See: (https://groups.google.com/d/msg/comp.lang.lisp/Llmnxk2SYUk/y...) and (http://www.dreamsongs.com/Files/HOPL2-Uncut.pdf)

An evolving, used platform which was (suddenly?) pressured to freeze.

Re: Dylan: the harsh realities of the market

#42

Post by andrewchambers » Tue, Aug 26, 2014, 4:45 AM UTC

georgegeorges wrote: post #24

If 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…

Clojure is pragmatic in using jvm as its platform.

Re: Dylan: the harsh realities of the market

#43

Post by nostrademons » Tue, Aug 26, 2014, 4:58 AM UTC

Tomte wrote: post #40

rdtsc wrote: post #38

> 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…

> What does Dylan do? 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 pa…

Dylan started out with a prefix syntax; the infix syntax was added on late in its development at Apple, because it was believed the market wasn't willing to adopt a prefix-syntaxed language. Turns out it didn't matter very much.

Dylan also standardized and simplified a lot of the dark, twisty corners of Common Lisp. Generic functions became a core part of the language, rather than something bolted on by ad-hoc macro packages. The collections API was unified to use generic functions (so no more mapc/mapcar/mapcan/mapl/maplist/mapcon mess), and the language syntax's infix operators were all defined in terms of generic functions as well, so you could eg. define a matrix type and have + and * work on it as expected. The superclass linearization was fixed to be monotonic. Macros are hygienic. It's a Lisp-1, and everything in the language is an object bound to a name.

Honestly, I think its lack of success came down to a Worse-is-Better problem. Dylan is a really nice language, designed by a committee with a combined total of over 2 centuries of Common Lisp experience. But it doesn't excel in any one domain. It's a large language, fairly complicated, which tried to mainstream a number of features with complex interactions and limited applicability. To an outsider, who doesn't understand those features or how they might be useful, it's too hard to pick up in a weekend. And so simpler languages like Scheme, Go, Python, or Erlang steal its thunder - they lack the total power of Dylan, but you can point to Scheme and say "Small composable building blocks", or Go and "Fast concurrency with quick, simple deployment", or Python and "Prototype anything, with batteries included", or Erlang and "Reliable message-passing concurrency." If you point to Dylan and try to describe it in one sentence, you get "Generic functions all the way down", which means nothing to the average programmer.

It's much the same problem that Scala faces, except that Scala features JVM interop and so Scala advocates can say "Tomorrow's language features with yesterday's Java code."

Re: Dylan: the harsh realities of the market

#44

Post by nostrademons » Tue, Aug 26, 2014, 5:03 AM UTC

wisty wrote: post #15

nostrademons wrote: post #3

Dylan was my favorite language back in college. I remember following PG's essays to Lisp, and then Lisp to all the newer dialects like Dylan or Goo. Dylan had it all: a metaobject protocol, generic functions, optional static typing, infix macros . I even got started working on an Eclipse plugin for it, which I ended up shelving after like 3 weeks when I lost interest. Unfortunately, there are large network effects to…

I don't really think it's purely tooling that's the issue. If it were so easy to use Dylan, then the tooling would be easy to write. I think it's performance. "Scripting languages" tear compiled languages apart when it comes to iterating. Write a "hello world" web app page in Python and Scala, then see which one takes 30 seconds and about a gig of RAM to actually display in the browser. On the other hand, if you need…

Dylan is compiled. It was done by the same folks who did CMUCL, which was the original optimizing compiler for dynamic languages, built in the 80s, well-before Strongtalk begat Self begat Hotspot begat V8.

Re: Dylan: the harsh realities of the market

#45

Post by yarrel » Tue, Aug 26, 2014, 5:15 AM UTC

I love Dylan. We should all be using it instead of C++ and Java. Particularly C++. Each time I type "friend" in C++ or have to use the STL, I miss Dylan.

Re: Dylan: the harsh realities of the market

#46

Post by rtpg » Tue, Aug 26, 2014, 5:33 AM UTC

calibraxis wrote: post #41

rtpg wrote: post #29

Earlier quoted context omitted.

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…

> I'm still not sure why there are 80 different ways to loop Please ignore if you're asking rhetorically. But there are reasons why it was put together in kind of a wild political dash. See: ( https://groups.google.com/d/msg/comp.lang.lisp/Llmnxk2SYUk/y... ) and ( http://www.dreamsongs.com/Files/HOPL2-Uncut.pdf ) An evolving, used platform which was (suddenly?) pressured to freeze.

I am vaguely aware of how CL came to be, but was unaware of this report. I'll give it a read, thanks.

Re: Dylan: the harsh realities of the market

#47

Post by rwallace » Tue, Aug 26, 2014, 5:41 AM UTC

justinpombrio wrote: post #30

rtpg wrote: post #29

Earlier quoted context omitted.

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…

Haskell was designed by committee, and it's exactly the opposite of the stereotype: it's a small language with orthogonal features and a clean syntax. The few "features" the language has, like list comprehensions and do notation, are defined by simple translations into the rest of the language. http://www.haskell.org/onlinereport/

And conversely, Ada was designed by one man, and if you weren't aware of that historical fact and just looked at the language spec, you'd swear it was the classic example of committee design. Fred Brooks' dictum that design should be done by a single mind, or at most two, is a guideline not a rule.

Re: Dylan: the harsh realities of the market

#48

Post by davidw » Tue, Aug 26, 2014, 6:24 AM UTC

There are a lot of things that strike me as being wrong about this essay. Most importantly, to understand the success or failure, you have to think about it, and its economics, like any other product on the market. Granted, programming languages have different characteristics as products than lighthouses or tv shows or telephones, but they do share things with them that we can learn from. This is a somewhat dated attempt of my own to share a bit of that thinking:

http://www.welton.it/articles/programming_language_economics

A few other things:

* Like rdtsc says, Erlang does not fit the mold in a lot of ways. It had a large corporate sponsor from the get-go, which was good for it in some ways (money for developers), and perhaps bad in others: lots of production code early on means it's not possible to change stuff that is less than optimal.

* As per my article, new/small/unpopular languages need a niche, a beachhead if they are to gain traction. You can't create a new language and platform from scratch with an ecosystem as big as Java's (indeed, piggybacking on the JVM is a popular strategy because of this), so you'd better have one thing where you absolutely kick ass. Erlang has this in spades, for instance. Ruby had Rails. Tcl had Tk and a few other "killer apps". PHP was way easier to get started with than mod_perl, back in the day. I don't see this for Dylan, particularly, but then I don't know much about it, so maybe it's there somewhere, and BruceM will figure it out and the language will gain a following.

Re: Dylan: the harsh realities of the market

#49

Post by lispm » Tue, Aug 26, 2014, 7:19 AM UTC

rtpg wrote: post #29

eudox wrote: post #26

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…

Scheme had a very shallow standard. It's written in a dense style and lacked basic stuff like error handling or an object system.

> I'm still not sure why there are 80 different ways to loop

There are many ways to loop, because users found those useful. Lisp by tradition is not telling the developers what they have to use. It's the opposite: it gives the developers various degrees of freedom to shape the language (from macros, read macros, ... to the MOP).

You could have easily removed something like DOLIST from the standard. But why? Software before and after the standard will still use it. How about MAP ? Remove it! But wait, people have used it already and will still use it...

Lisp languages are ball-of-mud languages where users can add their own control structures.

If you look at Scheme, they have added all this and more with SRFIs. Now you get a language, whose implementations support a minimal language and each will implement some subset or superset of SRFIs...

Re: Dylan: the harsh realities of the market

#50

Post by lispm » Tue, Aug 26, 2014, 7:24 AM UTC

BruceM wrote: post #37

rtpg wrote: post #29

Earlier quoted context omitted.

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 was originally designed by committee back in the days when it was designed by people @ Apple, Harlequin and CMU. 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 s…

Common Lisp had different goals from Dylan. Common Lisp was designed as a powerful Lisp dialect, incorporating ideas from 20+ years back plus some new stuff. It was designed to be 'backwarts' compatible with Maclisp and its dialects.

Dylan was designed as a new language (compatible with nothing) for application development and delivery for small machines.