Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dylan: the harsh realities of the market

logicaltypes.blogspot.com

Post reply on HN
Print view View original

51–60 of 120 posts

Re: Dylan: the harsh realities of the market

#51

Post by lispm »

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…

> You have to have your head pretty far up your own ass to not see how much Common Lisp sucks. It's a language designed by committee, and it looks like it.

The original design was by four people. Common Lisp does not look worse or better than the Lisp's it was designed to improve on (Maclisp, Lisp Machine Lisp, NIL, ...) and the Lisps it made mostly obsolete (Portable Standard Lisp, Interlisp, ...).

Re: Dylan: the harsh realities of the market

#52

Post by lispm »

mindstab wrote: post #33
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…

> Languages don't matter. Platforms matter. APIs matter. Playing nicely with the rest of the world fucking matters. Common Lisp wouldn't. 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 eas…

Hmm, where is the ISO C++ standard to access the Windows file system?

If you were using say, Allegro CL on Windows, I doubt you had any difficulties accessing the file system.

Re: Dylan: the harsh realities of the market

#53

Post by jahnu »

logicchains wrote: post #27
agentultra wrote: post #9

Earlier quoted context omitted.

> I'd give much to know what went so deeply wrong in our industry that we keep making such basic mistakes. I don't think we can all agree on what counts as progress. Some saw Exceptions as the advance in error handling we need while Go reverts back to error codes. People still think Go is superior for different reasons. I think both suck and prefer conditions and restarts as in Common Lisp. It is rather difficult to…

>Some saw Exceptions as the advance in error handling we need while Go reverts back to error codes. Just a note that Go generally uses strings for error handling, not error codes. This avoids the need to look up the meaning of each error codes in a table somewhere.

How are errors typically localised?

Re: Dylan: the harsh realities of the market

#54

Post by lispm »

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…

Dylan mostly died before practical applications were written in it. I doubt there were more than ten serious applications written in it (besides its own IDE and compilers).

Re: Dylan: the harsh realities of the market

#55

Post by lispm »

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 was not designed for Lisp, Scheme or Smalltalk users. It took ideas from there, but it was developed as a replacement for C, C++ for application development. If Apple had actually used it, stuff like Keynote, Logic, iPhoto, iTunes, Xcode, ... would have been written an Dylan.

Apple used Objective-C for that then.

Re: Dylan: the harsh realities of the market

#56

Post by lispm »

rayiner wrote: post #6

Dylan is also, unfortunately, an example of "worse is better" in action. The extant Dylan implementations were incredibly ambitious. CMU's d2c built on the experience with CMUCL. Harlequin Dylan (AKA OpenDylan) was "Dylan all the way down" with a sophisticated native code compiler and an IDE written in Dylan. Multithreading, generational GC, etc. And what filled the dynamic language niche? Interpreted languages like…

Dylan wasn't really a 'dynamic language' in the classical sense. It was thought to bring the power of dynamic languages to application developers.

Dylan was made obsolete by Objective-C at Apple, not Ruby or Python. Outside Apple Dylan was made obsolete by Java.

Some of the early Dylan users complained that too much time was wasted on the IDEs, while the language implementation and libraries were lacking.

Re: Dylan: the harsh realities of the market

#58

Post by xplothar »

nickbauman wrote: post #8

If you want to gauge a language look at one thing and one thing only. Who are these people using it and what are they using it for? The answer to that question is more important than anything else on the list after that. Amen.

Good one. Used this heuristic to select Erlang and very happy since that time :-)

Re: Dylan: the harsh realities of the market

#59

Post by pjmlp »

Very interesting read.

I have a soft spot for Dylan from magazine articles back in the Newton days.

Here we have a Lisp like language, with a more approachable syntax for the average Joe/Jane developers, AOT compilation and Apple kills it.

I think it is also important to bring out the paper from Erik Meijer about using Visual Basic to hook the typical enterprise developer into FP (via LINQ).

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.118....

Re: Dylan: the harsh realities of the market

#60

Post by klibertp »

BruceM wrote: post #12

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

Thank you for your work and please, please keep working on Dylan.

A couple of years back I wanted to learn Dylan, but it really looked rather old and unfriendly. I read about Dylan module system and object system and thought it's really interesting. My first impression was that it's somewhat similar to Racket units system and to CLOS.

I hoped for Dylan to be modernized enough to make it easier for me to learn it. I forgot about it as I learned a dozen or so new (or old) exciting languages in the meantime, but seeing improvements in Dylan - especially in the docs - makes me interested in it once again.

> there are bite-sized pieces of work that could be done in a couple of hours/week that would lead to significant gains

How to get involved with it? Are there issues on Github, is there a mailing list? Free time is scarce, but if I finally decide to learn Dylan I can help with its development as well.

Again, please don't stop working on Dylan. It's only natural for such a language to have a small user base, it's nothing to be worried about. Just keep working on it and sooner or later it will become (more) popular. That's my experience with various niche languages to date, at least.

Post reply on HN