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

21–30 of 120 posts

Re: Dylan: the harsh realities of the market

#21

Post by djur »

Fice wrote: post #17

You could think of it as putting a low-pass filter on some of the good ideas from the ’60s and ’70s, as computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture ... So I think the lack of a real computer science today, and the lack of real software engineering today, is partly due to this pop culture. A Conversati…

The history of mass computing involves numerous 'bottleneck' events where an increase in usage was bought with a curtailment of hardware and software quality. You had the first blast of cheap minis available outside military and academic environments. Then you had cheap home computers with limited BASIC implementations. That was followed by web apps scripted with half-assed '90s JavaScript and served from cramped mass hosting servers. Then you had smartphones -- iOS using a somewhat spruced-up but constrained version of the decades-old NeXTSTEP, and Android using an outdated and pared-down version of Java.

This is pretty much what "Worse Is Better" is about. Cheap, readily-available software that runs on cheap, readily-available hardware is always going to have a huge head start.

Re: Dylan: the harsh realities of the market

#22

Post by joshvm »

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…

The combo of C(++) and Python is very strong. A friend of mine works in a research HPC lab (think around 16000 cores); they use Python for the IO and interface glue and C for the heavily parallel science code. It's the best of both worlds.

Re: Dylan: the harsh realities of the market

#23

Post by seanmcdirmid »

eudox wrote: post #2

The article hits rather close to home, as someone who, for better or worse, is committed to improving Common Lisp's ecosystem. I often feel this existential dread of "Is it worth it? Whose lives will it change? Will I spend years labouring in obscurity for nothing?". And while the answer to all those questions is probably not what I'd like to hear, I still do it. This is why ecosystems are, for most people, more valu…

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?"

Re: Dylan: the harsh realities of the market

#24

Post by georgegeorges »

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 weirdness-factor and everything.

What? How have you not heard of CPAN? There is not a single language in the world that can touch Perl's libraries. I'm not sure why you feel the need to toss either Perl or Python under the bus to make some petty point about Dylan's lack of popularity. Python replaced Scheme at MIT. It's time to move on. I know I have.

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.

I've used Erlang too. For everything Erlang does well, there are countless areas that make you want to bang your head against the desk.

Languages don't matter. Platforms matter. APIs matter. Playing nicely with the rest of the world fucking matters. Common Lisp wouldn't.

Re: Dylan: the harsh realities of the market

#25

Post by freyrs3 »

seanmcdirmid wrote: post #23
eudox wrote: post #2

The article hits rather close to home, as someone who, for better or worse, is committed to improving Common Lisp's ecosystem. I often feel this existential dread of "Is it worth it? Whose lives will it change? Will I spend years labouring in obscurity for nothing?". And while the answer to all those questions is probably not what I'd like to hear, I still do it. This is why ecosystems are, for most people, more valu…

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?"

Have to figure it takes 10-20 years to grow an industrial strength language. It takes a lot of faith in an idea or stubbornness ( probably both ) to go through that struggle. I admire people with that kind of dedication and I wish exploring the language design space wasn't such an enormous investment.

Re: Dylan: the harsh realities of the market

#26

Post by eudox »

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…

> 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 superior or inferior about design by community or committee, respectively.

Re: Dylan: the harsh realities of the market

#27

Post by logicchains »

agentultra wrote: post #9
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. 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.

Re: Dylan: the harsh realities of the market

#28

Post by bunderbunder »

peterkelly wrote: post #19
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…

> 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 variables in order to evaluate it. But it was a dynamically scoped language, so capturing free variables from an anonymous function's lexical scope (which is what a closure does) didn't really make sense for it. Instead it just used the execution context to bind variables.

Re: Dylan: the harsh realities of the market

#29

Post by rtpg »

eudox wrote: post #26
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…

> 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 things than the Lisp book did.

CL is a huge and complex language, and I'm still not sure why there are 80 different ways to loop. It's a confusing language, with not nearly as much orthogonality as it could have.

Re: Dylan: the harsh realities of the market

#30

Post by justinpombrio »

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…

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/

Post reply on HN