Live data from Hacker News

Dylan: the harsh realities of the market

logicaltypes.blogspot.com

91–100 of 120 posts

Re: Dylan: the harsh realities of the market

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

Since you seem very qualified to critize a PL, could you elaborate on the problems you see with scala ?

I recently had to study the option of starting a real project with this language, but after looking at it, it didn't feel like an elegant and well thought out language. More like a monster language people tried to stuff as many features as they could into.

But that was just a first glance impression. So i'm really wondering what someone like you think of it.

Re: Dylan: the harsh realities of the market

#93
post #21
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 mas…

Unix is another example of a worse reimplementation of an earlier system to fit the hardware constraints of the day.

The thing is though, the security model of multics would be a much better fit for today's security needs, but we don't have it because the hardware that could run it was too expensive 40 years ago, which seems crazy when I think about it. Sometimes it feels like the industry as a whole is no longer ambitious, that building fundamentally better systems is no longer considered important. It's nice that you can run unix on your phone, but i would like to run something better than unix on my desktop. Where are the OS's that are ambitious enough to eventually turn into scarlett johansson in the movie 'Her'?

Re: Dylan: the harsh realities of the market

#94
I really like Dylan, but it has a huge problem that never gets discussed - verbosity. The syntax is entirely too verbose for a modern language. My suggestion would be to first complete the Intellij plugin and then actually change the syntax so it can compete with the scripting languages.

Re: Dylan: the harsh realities of the market

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

Hi eudox, I would love to use CL for my projects - I've read (most of) Norvig's and Graham's books, written small programs etc. I really like most of the language, especially the 'break into debugger on error'. But, when I came to write CL for a project that needed gui, web scraping, using APIs etc (i.e. I wanted to connect it to the outside world) I was stumped. Unlike in e.g. python, there was no nice gui library t…

Regarding CL with some quick googling (searched "common lisp html parser" and "common lisp http client") I found:

Html Parser: http://www.cliki.net/cl-html-parse

Http client: http://weitz.de/drakma/

I'm not sure why you are/were stumped? I could search for qt bindings for you, but I'm sure they exist and are pretty mature.

Re: Dylan: the harsh realities of the market

#96

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. 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 having the great features isn't enough. (In fact, this is a big part of how Java conquered a big chunk of the world. As a language, it's kind of a yawn. But the library is like Barbie - it has everything.)

Re: Dylan: the harsh realities of the market

#97

Earlier quoted context omitted.

Hi eudox, I would love to use CL for my projects - I've read (most of) Norvig's and Graham's books, written small programs etc. I really like most of the language, especially the 'break into debugger on error'. But, when I came to write CL for a project that needed gui, web scraping, using APIs etc (i.e. I wanted to connect it to the outside world) I was stumped. Unlike in e.g. python, there was no nice gui library t…

Regarding CL with some quick googling (searched "common lisp html parser" and "common lisp http client") I found: Html Parser: http://www.cliki.net/cl-html-parse Http client: http://weitz.de/drakma/ I'm not sure why you are/were stumped? I could search for qt bindings for you, but I'm sure they exist and are pretty mature.

Thanks for that. Maybe I will try again some time.

I'm not saying it is impossible, rather that it is hard work compared to e.g. python. I recall looking through a few promising google results and finding e.g. that the library is no longer maintained, has bits missing etc. With python, when I use e.g. beautiful soup, it just works - I lose almost no time getting setup. When doing a project that needs many external libraries, that makes a big difference.

e.g. the first item on http://www.cliki.net/GUI has its last news item from 2007, and the mailing list gives 'not found'. But there is a new(er) github page with the comment "I cleaned up the library just in case I needed GUI in Lisp, but it turned out that I did not. Hence, the primary extent of my testing is running test-gtk:gtk-demo application. Bug reports and/or patches are welcome."

Since the parent was talking about ecosystems etc, I thought my experiences were worth mentioning - "Python novice uses python to get stuff done" but "CL novice gets lost in old/unmaintained libraries, gives up and sticks with c++ & python".

I mean no disrespect to the people who write these libraries etc., I am just describing what I found as a novice in CL.

Re: Dylan: the harsh realities of the market

#98

> 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 those problems!" True. "And algebraic types can fix that!" Also true. But here's the thing: (Almost) Nobody cares. Nobody thinks that algebraic types are a price worth paying to fix null pointers.

Do not automatically assume that you are right, and that everybody else is too stupid to see it. Instead, try to expand your mind far enough to see that they may have a better grasp of the trade-offs that confront them than you do. They think your solution doesn't work in their world. Bemoaning their stupidity is the lazy way out. Instead, try to find out why they think that.

I think the problem is not with the industry. The problem is with your expectations of the industry.

Re: Dylan: the harsh realities of the market

#99
post #82
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…

Your comment is a bit confusing because you're basically explaining how Common Lisp was indeed a language designed by committee containing all sorts of compromises between competing vendors. That's what the OP was getting at.

I wasn't trying to contradict that. I was trying to indicste that failures in it are due to how much the terrain has changed. By and large the standardization process was successful, the failure is that there haven't been any revisions since (and likely won't be).

Re: Dylan: the harsh realities of the market

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

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 dealing with all this concurrency and inherent raciness of the system in a language like python is a royal pain in the rearside.

Similar things with java and performant programming. Some of my major programs at work don't use the java ecosystem outside of log4j, junit, apache commons lang and apache commons collections. They use java, because java is darned fast without being as brittle as C or as nuts as C++. So java adds a lot of really cheap development security.

Designing yet another language that puts the existing features together with just a tiny difference doesn't add anything. I've enjoyed looking at experimental languages, and I've enjoyed tinkering around with ideas myself some time ago. But by now, I've accepted I'm not smart or talented enough to make something worthwile, and it will be some time until an interesting new breakthrough occurs.

Post reply on HN