Dylan: the harsh realities of the market

Post by lispm » Wed, Aug 27, 2014, 9:53 AM UTC

lmm wrote: post #108

ohyes wrote: post #101

Earlier quoted context omitted.

So we say the language is terrible because the world around it changed? Using Common Lisp may be inconvenient because the standard is out of date, that doesn't mean the design (or language) was a failure in a historical sense. I just think this whole argument is basically a straw man. Comparing something well specified that hasn't changed is 30 years to an entire class of hand wavy 'better languages' isn't an apples…

I'm less interested in questions like "how much credit do the original designers of CL deserve?" and more interested in "what languages should I consider for my new project?". Is Dylan a viable option? If not, why not? "It's not because it inherits common lisp's non-interoperability" is then an interesting point.

Post by pjmlp » Wed, Aug 27, 2014, 10:27 AM UTC

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.

Post by tetha » Wed, Aug 27, 2014, 4:54 PM UTC

seanmcdirmid wrote: post #103

tetha wrote: post #100

Earlier quoted context omitted.

The important question isn't necessarily: Is it worth it, without the ecosystem? The more interesting questions is: What does this language add? For example, I need to deal with some unix process management tasks. I'm not crazy enough to do them in straight C, so I'm using python for it's strong C bindings, so I can use system calls in C with python level control flow. However, there's a lot to be desired, because de…

My languages tend to be very innovative or even inventive; e.g. I recently posted this to HN: http://research.microsoft.com/en-us/people/smcdirm/managedti... My problem is quite the opposite: when the languages are so different from what already exists, people (and even myself) have trouble thinking about how adoption would even occur, at least in the short term.

Post by lispm » Wed, Aug 27, 2014, 8:58 PM UTC

bainsfather wrote: post #116

lispm wrote: post #112

Earlier quoted context omitted.

Many people who actually write GUI software in Lisp use one of the commercial offerings, typically either LispWorks and Allegro CL. That's one of their advantages: they offer maintained and cross platform GUI libraries. One can for example also use Clozure CL for advanced GUI stuff, but that is best on the Mac. For example http://opusmodus.com is a composition software using Clozure CL. Other composition environments…

Thanks for the info. I just had a quick look at Clozure CL - as you say, the main Gui library is for apple. The other gui library is labelled 'under development' but also 'last modified: 6 years ago' :( I wonder whether the (I'm told) good commercial lisp offerings have hampered lisp adoption, in that people who use lisp a lot, pay for commercial offerings, leaving the free stuff less used and maintained? Then newcom…

Post by loup-vaillant » Thu, Aug 28, 2014, 1:46 PM UTC

AnimalMuppet wrote: post #98

loup-vaillant wrote: post #5

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

> I'd give much to know what went so deeply wrong in our industry that we keep making such basic mistakes. The vast bulk of the industry is much more practical than theoretical. They don't care about your theory about how languages ought to be built. They care about solving the problems that are actually hindering programmers who are trying to write programs. "But", I hear you say, "null pointer exceptions are one of…