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

61–70 of 120 posts

Re: Dylan: the harsh realities of the market

#61

Post by klibertp »

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.

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 baseline, a starting point for building things. How you build API, how you interact with outside world, how you accomplish common tasks depends on a language and language features. And it gets even more important as you climb the abstraction ladder. For example, at language level Scheme offers call/cc. You may say it doesn't matter, as it's just a language feature. But take a look at Racket continuation-based web server - it's an impressive piece of work which solves a certain problem really well and is almost impossible to implement in some other languages (you don't need continuations specifically to implement this, there are other features which would enable it). At a language level Lua offers coroutines, which in itself is not very impressive. But take a look at OpenResty: you can write code which looks perfectly normal and synchronous (no callback etc.) while still fitting inside of async by nature Nginx.

Anyway, thing you mention, like APIs, do matter too, but language features are equally important. Don't dismiss them because you superficially know a few languages; rather learn some of them in depth and build real world things with them and I'm 97% sure you'll see how language features matter.

Re: Dylan: the harsh realities of the market

#62

Post by leoc »

nostrademons wrote: post #44
wisty wrote: post #15

Earlier quoted context omitted.

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…

Dylan is compiled. It was done by the same folks who did CMUCL, which was the original optimizing compiler for dynamic languages, built in the 80s, well-before Strongtalk begat Self begat Hotspot begat V8.

Typo: Self begat Strongtalk.

Re: Dylan: the harsh realities of the market

#63

Post by jacobparker »

lispm wrote: post #52
mindstab wrote: post #33

Earlier quoted context omitted.

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

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n394...

Not finalized yet, but soon: https://isocpp.org/std/status

(It is basically a standardization of boost::filesystem)

Here are the MSDN docs: http://msdn.microsoft.com/en-CA/library/hh874694.aspx

Re: Dylan: the harsh realities of the market

#64

Post by Dolimiter »

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

Nice, I like that.

Reminds me of the Discourse peeps, who rejected eg PHP, and wrote it in their pet language, ignoring that no-one cares about language, and finding the problem that their platform is so difficult to install and use, that no-one uses their software.

Re: Dylan: the harsh realities of the market

#65

Post by Jgrubb »

Dolimiter wrote: post #64
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." Nice, I like that. Reminds me of the Discourse peeps, who rejected eg PHP, and wrote it in their pet language, ignoring that no-one cares about language, and finding the problem that their platform is so difficult to install and use, that no-one uses their software.

> the Discourse peeps, who rejected eg PHP, and wrote it in their pet language, ignoring that no-one cares about language

Are you talking about Ruby/Rails?

Re: Dylan: the harsh realities of the market

#66

Post by lispm »

jacobparker wrote: post #63
lispm wrote: post #52

Earlier quoted context omitted.

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.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n394... Not finalized yet, but soon: https://isocpp.org/std/status (It is basically a standardization of boost::filesystem) Here are the MSDN docs: http://msdn.microsoft.com/en-CA/library/hh874694.aspx

That's great. But it's POSIX, not native Windows.

Re: Dylan: the harsh realities of the market

#67

Post by vijucat »

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…

Bruce, not sure if you are interested in commercial success, but assuming you are, one suggestion is : whatever you may feel about Scala, I believe that Martin Odersky had the right strategy when he noted that Object Oriented Programming did well despite it's flaws because people could build real, working things with OO languages. This probably holds true even more for PHP.

So my suggestion is to do the same for your language : build a cool, new mp3 player that reminds folks of the days when WinAmp was so awesome. Or build a scalable server-side framework that makes WhatsApp-scale chat easy as pie. Make it easy for folks to achieve commercial success, and your language will thrive, too.

Re: Dylan: the harsh realities of the market

#68

Post by ohyes »

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.

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. Companies and institutions that had radically different operating systems and hardware, it wasn't a matter of writing software for a machine that ran either 'Windows or Unix.' You had to support the lisp machine vendors and a variety of mainframes/minicomputers. Emphasis on 'Common.' The theoretical possibility was that you could write a program on a MacIvory and then run it on your Symbolics Machine, ThinkingMachines machine, Unix Machine, Windows machine, PDP-11, Dandelion, DEC Alpha etc...

Go write a C (or Python for that matter) program that lets you access the file-system port-ably on a huge variety of operating systems using only the C standard. I suspect it will be difficult.

Anyway, you couldn't be any more wrong. You've limited the 'entire world' to essentially two similar platforms, one of which (Windows) isn't really that well supported.

The whole point is that it tried really, really hard to satisfy the entire lisp world, which included a number the larger players who were put out of business by Moore's law and cheap generic hardware rapidly outpacing expensive special purpose hardware.

All this said, Common Lisp (and Scheme, and it's implementations) have features that the general programming community is still rediscovering 30 years later. Dismissing it as something that sucks because the people involved didn't try hard enough is incredibly myopic.

tl;dr: Nu-uh.

Re: Dylan: the harsh realities of the market

#69

Post by alanctgardner3 »

chrismonsanto wrote: post #39
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…

> What? How have you not heard of CPAN? There is not a single language in the world that can touch Perl's libraries. That's a really outdated meme. CPAN is small, pretty much every language you hear about regularly has a larger package space than CPAN. Even Go's package space is bigger than CPAN's. JS and Java each have package spaces roughly 3x CPAN's size. http://www.modulecounts.com/

CPAN is much higher quality, though. For every Perl package that works and has unit tests and documentation, there are 10 node packages someone tried for a month to write, then gave up and left at 0.01 with no docs. Perl isn't sexy, but Perl diehards have written and published modules to do everything you can imagine.

Re: Dylan: the harsh realities of the market

#70

Post by tempodox »

tel wrote: post #34
cwzwarich wrote: post #7

Earlier quoted context omitted.

> But then I saw Swift. Built-in support for an Option type, so one can avoid null pointer exceptions. At the same time, this languages manages to recognize the extreme usefulness of algebraic data types, without using them in their full generality. Like, why bother with a generic feature when we can settle for an ad-hoc one? Swift has the syntax to define arbitrary algebraic datatypes, even if it doesn't yet work in…

It seems to be likely that 1.0 will hit before this really holds true. In Beta 6 I'm told you can easily crash the compiler with recursive generic ADTs and most have to travel "through" some heap type to compile at all. Furthermore, Swift doesn't support enough laziness/deferral/coalgebraic formulation to have, say, an infinite stream type without breaking GCD. These will probably be fixed in time, but Swift's ADT su…

Wow, where did you get Beta 6? I only have 5.
Post reply on HN