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

101–110 of 120 posts

Re: Dylan: the harsh realities of the market

#101

Post by ohyes »

lmm wrote: post #84
ohyes wrote: post #68

Earlier quoted context omitted.

> 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. Erh, no. You don't seem to have any historical insight into how common lisp came to be. (Or maybe you do have historical insight and are just being willfully ignorant). It is a language designed by a set of companies and institutions compromising 25 years ago. Com…

Sure, 25 years ago there were good reasons for the design compromises of Common Lisp. But that doesn't mean they make sense today, where "Windows or Unix" is pretty much the world, and there are any number of consistent, elegant languages that work on both. > All this said, Common Lisp (and Scheme, and it's implementations) have features that the general programming community is still rediscovering 30 years later. A…

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 to apples comparison, and is, frankly, a dumb waste of time.

Re: Dylan: the harsh realities of the market

#102

Post by Diederich »

lmm wrote: post #83
Diederich wrote: post #80

Earlier quoted context omitted.

https://metacpan.org/recent There are a couple of CPAN module installers, and every one of them, by default, will not install the target module if there are any test failures. Honest question: are there any other languages that do that? I last looked a few years ago, and it didn't seem to be the case.

Maven will not, by default, allow you to perform a release if there are any test failures. That seems like a better model, at least for a VM language - if something works on the release machine and not on the user's machine, you have bigger problems.

That's great to hear!

I'm not too strong on Java; does what you're saying imply that some/all/most of the freely available Java 'modules' or 'packages' that are built with Maven will end up running and passing associated test suites in most all of the organizations that end up using the code in question?

Re: Dylan: the harsh realities of the market

#103

Post by seanmcdirmid »

tetha wrote: post #100
seanmcdirmid wrote: post #23

Earlier quoted context omitted.

Its even worse for the PL designer inventing something new without even a small ecosystem in place; I ask myself everyday "is it worth it?"

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.

Re: Dylan: the harsh realities of the market

#104

Post by wtetzner »

Diederich wrote: post #102
lmm wrote: post #83

Earlier quoted context omitted.

Maven will not, by default, allow you to perform a release if there are any test failures. That seems like a better model, at least for a VM language - if something works on the release machine and not on the user's machine, you have bigger problems.

That's great to hear! I'm not too strong on Java; does what you're saying imply that some/all/most of the freely available Java 'modules' or 'packages' that are built with Maven will end up running and passing associated test suites in most all of the organizations that end up using the code in question?

No, the tests are run as part of the deploy. So before deploying a library, if the tests don't pass, the deploy fails.

However, the artifact that actually gets deployed is a .jar file containing .class files. Users of libraries don't rebuild the libraries.

Re: Dylan: the harsh realities of the market

#105

Post by [deleted] »

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…

[deleted]

Re: Dylan: the harsh realities of the market

#106

Post by nunb »

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…

the libraries abstract over most fs warts see Practical Common Lisp for an example

Re: Dylan: the harsh realities of the market

#107

Post by klibertp »

AnimalMuppet wrote: post #96
klibertp wrote: post #61

Earlier quoted context omitted.

> Languages don't matter. Bullshit. Languages DO matter. Language features matter, too. Even syntax matters, although not that much. It's easy to get trapped in "languages don't matter" attitude if you know a couple languages. The perspective changes drastically with mastery - being able to use a language to its fullest, as opposed to just using it - and with dozens more of learned languages. A language is your basel…

I think you're missing George's point. Languages don't matter in isolation . It's the language plus the libraries plus the rest of the ecosystem, which he's calling the "platform". If you have this language with these great features, but it has lousy libraries and therefore you have to write a bunch more stuff yourself, you need to weigh that against the great features when deciding whether to use that language. Just…

I completely agree. As I wrote, libraries and other features of a platform do matter and of course you need to take those into account when deciding which language to use. It's always very specific to a given situation though, for example lack of "batteries included" libraries may not be a concern when choosing language to embed in your app (like Lua). But in general great language features and great platform features (for example working package manager) are both very important factors that you need to take into account when deciding on language(s) for your project.

Re: Dylan: the harsh realities of the market

#108

Post by lmm »

ohyes wrote: post #101
lmm wrote: post #84

Earlier quoted context omitted.

Sure, 25 years ago there were good reasons for the design compromises of Common Lisp. But that doesn't mean they make sense today, where "Windows or Unix" is pretty much the world, and there are any number of consistent, elegant languages that work on both. > All this said, Common Lisp (and Scheme, and it's implementations) have features that the general programming community is still rediscovering 30 years later. A…

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.

Re: Dylan: the harsh realities of the market

#109

Post by lmm »

wtetzner wrote: post #104
Diederich wrote: post #102

Earlier quoted context omitted.

That's great to hear! I'm not too strong on Java; does what you're saying imply that some/all/most of the freely available Java 'modules' or 'packages' that are built with Maven will end up running and passing associated test suites in most all of the organizations that end up using the code in question?

No, the tests are run as part of the deploy. So before deploying a library, if the tests don't pass, the deploy fails. However, the artifact that actually gets deployed is a .jar file containing .class files. Users of libraries don't rebuild the libraries.

Just to clarify, "deploy" in this sense means "upload to your organization's maven repository (or maven central)".

Re: Dylan: the harsh realities of the market

#110

Post by lispm »

lmm wrote: post #84
ohyes wrote: post #68

Earlier quoted context omitted.

> 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. Erh, no. You don't seem to have any historical insight into how common lisp came to be. (Or maybe you do have historical insight and are just being willfully ignorant). It is a language designed by a set of companies and institutions compromising 25 years ago. Com…

Sure, 25 years ago there were good reasons for the design compromises of Common Lisp. But that doesn't mean they make sense today, where "Windows or Unix" is pretty much the world, and there are any number of consistent, elegant languages that work on both. > All this said, Common Lisp (and Scheme, and it's implementations) have features that the general programming community is still rediscovering 30 years later. A…

> between CL and the rest of the world is undeniably poor

Because CL is a language and not an implementation.

Many CL implementations have excellent interoperability capabilities.

Post reply on HN