Hacker News new | past | comments | ask | show | jobs | submit login

If you want to reply about Arc, do so here.



> once the next implementation of Arc is ready

A nice example of how using the wrong programming language for your project impedes your progress/feature delivery.


Oh you guys. More an example of how using the perfect programming language for your project allows it to succeed, thrive, and eventually meet the challenges of growth :)

HN wouldn't exist without Arc, so it's pointless to argue about this. But I love talking about it so I'm going to anyway.

The feedback loops between the language, the HN software, and the living system of the community go very deep. I could write a lot about that. It's one of the most interesting things about the project, though unfortunately not visible. The software just works its Lispy magic behind the scenes, remaining small and malleable. It's still only 15k lines of code, including the language implementation, and that code does a lot.

On performance, it's pretty cool that Arc has managed to run HN through 12+ years of growth without much optimization. It's a good sign, not a bad one, that we're only doing major rework for performance reasons now. HN is far from Reddit-scale, but still: the application runs on a single core. (Though we do cache pages for logged-out users and serve those from an Nginx front end.)

As long as we're on the topic, consider this: the software for both HN and YC was just a single Arc program (and not a large one) for the first 9 years of their existence, during which they went from nothing to massively successful to industry-changing. Written by one person, programming part-time. That is a staggering achievement. The power of using the right language for your project goes far further than most people dream. Our imagination about this is crippled by path dependence, social proof, and the conditioning that comes from only ever doing things the same few ways, like those fish in experiments (which may be urban legends?) who stick to their corner of the aquarium even after a glass barrier has been removed. The solution space of software and programming is so much larger than most of us want to imagine that it is. Sad.

I'm not saying that everyone should use Arc—language/programmer fit is a key part of language/project fit. But when all three variables align, incredible things become possible. Not only HN, but YC would not exist without Arc. Another case that came up recently was Cloudflare; very different language, project, and programmer, but a similar story (https://news.ycombinator.com/item?id=22883548).


I appreciate you taking the time to reply to this, but come on, “YC would not exist without Arc” is a definite exaggeration. YC’s impact as a platform is immeasurable, but the software is quite simple that could be coded in any other programming language just as well (I’d argue better since users wouldn’t be waiting now for new features to land if it weren’t for the language update).


You can write any program in any Turing-complete language, so that's obviously not my point.

Rather, it's that there's a deep interdependency between the three variables of language, programmer, and problem that give rise to a system like HN+YC (which was a single program until 2014). If you changed any one of those variables you'd either have gotten something radically different or nothing at all. So my statement is a bit like saying that YC would not exist without PG; and your objection is a bit like saying: that's an exaggeration, any person who did the same steps at the same time could have arrived at the same place (and perhaps better since that person might have been a better manager as well).

(Not only PG built YC, of course! But PG wrote the software and that was a critical piece.)

I'm not saying that all programs have this property about programming languages—rather, that some do, and they tend to be particularly interesting and creative. For another example, one might say that Unix would not exist without C.

There would be more interesting and creative systems in the world if we were more open as a community to these unexplored spaces. We exclude them in order to have the feeling that we know what we're doing, and we reinforce this by ridiculing and dismissing deviants. The social dynamics that exclude new creative possibilities are incredibly strong, which is one reason why when systems like this do end up succeeding, they tend to be the work of loners, weirdos, or people who have some strange mutation to withstand social pressure. (This by the way is the origin of the "$weird-language is only good for solo programmers" meme, ironically confusing cause and effect.) No doubt other fields work the same way; software is just the one I know well enough for the mechanisms to be obvious to me.

An analogy just occurred to me, which I want to note so I don't forget it. The relationship between a program and the language it's written in is like the relationship between a piece of music and the instrument it was composed for. To say "this system could have been built in some other language" is like saying "this music could have been composed for some other instrument". That may technically be true; music gets transcribed for other instruments all the time, just as programs get ported to other languages. But it misses the most important thing: the creative process by which the music or program got written in the first place.

There are intimate feedback loops between the mind of the composer, the developing music, and the design of the instrument—which possibilities it makes natural/easy vs. which it discourages/excludes. Every instrument and every programming language has a different set of these. They may not differ in what can theoretically be played on them, but they differ immensely in how they organize the space of possibilities—which ones are near at hand vs. out of reach. You can play the same scales on the piano, the cello, and the guitar, but where the mind goes next as it composes a new sequence of notes—not a scale, but a sequence that has never existed before—is deeply conditioned by the instrument it's working with, which is the medium it's growing in. Some next-notes are far more likely than others, and which next-notes those are differs greatly between instruments. In the same way, a program grows by accruing constructs (expressions, statements, forms, types), and the ones that are most likely to get added next are the ones that are most natural and nearest-to-mind, given the program so far. Which next-constructs those are differs greatly between languages.

Since each next-note or next-construct is deeply conditioned by the sequence it's adding to, this effect compounds as the system grows. It follows that, at least for the most interesting and creative systems, a program is literally unthinkable apart from the language it grows in. So much for "languages don't matter"—yet how often that untrue truism is repeated! The reason for this fallacy is that we take a program as if it existed prior to being written, which is impossible.

So when I say HN/YC would not exist without Arc (or Lisp really), I mean it in the sense that https://www.youtube.com/watch?v=rGgG-0lOJjk#t=14 would not exist without the cello even though https://www.youtube.com/watch?v=mhfxM5FOzjQ#t=3 is a thing, https://www.youtube.com/watch?v=x6GZ6xeGnJQ#t=15m would not exist without the piano even though https://www.youtube.com/watch?v=XXGCfW-cGoE#t=91 is a thing, and https://www.youtube.com/watch?v=skdE0KAFCEA would not exist without the electric guitar even though https://www.youtube.com/watch?v=kNFpOh2seqo is a thing.


Seems to me, he's an insider who is in the know and he's made an effort to explain why he sees it that way:

As long as we're on the topic, consider this: the software for both HN and YC was just a single Arc program (and not a large one) for the first 9 years of their existence, during which they went from nothing to massively successful to industry-changing.

I mean, you don't have to agree, but his opinion is probably more informed on the topic than yours is.


Maybe. And maybe it's just a simple, single category message board :)


Or maybe, because you need a handle here to apply for YC to begin with (or did the last time I looked), it's part of their funnel and business model.

And maybe, because they launch YC companies here and let them advertise job openings here, it's part of their business model.


I'm trying to write this in a way that does not come across as sarcastic or ungracious, but does it strike anyone else as odd that this change blocks on the next version of the underlying programming language?


Given that both the language and the forum are developed in tandem, and are linked to the degree that they ship together, it wouldn't be surprising that changes in Arc would be made specifically with the forum in mind.


Given that this is, to the best of my understanding, one of if not the only things Arc is doing.

No.

It probably could be done in the current version, just not done well.


Are there some relevant limitations in the current implementation of Arc? Also, numbered pages would be quite useful as well.


Just performance limitations. The two implementations should be identical otherwise.

What would numbered pages look like?


> What would numbered pages look like?

e.g. "1 2 3 4 ... 10" links or something like that instead of a single "More".


Also when we save a page the number is in the title.


That's interesting, mind elaborating on this? How is the next version of Arc going to help with pagination? Is this a memory limit thing?


It's a speed thing, but related to memory pressure because if we use too much memory then the GC uses too much CPU.


Is Arc open source?


The language, yes[0], but AFAIK the maintainers don't take pull requests.

Arc has a public fork called Anarki[1], which is built on Racket[2]. The Anarki version of the forum differs from the Arc forum, which differs from HN's own custom instance, which is closed because of various YCombinator business reasons.

[0]http://arclanguage.org/

[1]https://github.com/arclanguage/anarki

[2]https://racket-lang.org/


And to be a little more specific (because I really like Arc), the releases are very rare, and minor at this point. I would be surprised if the Arc that was running HN was the latest released version of Arc, the news library notwithstanding.

For example, the latest release, Arc3.2, came out in 2018, and was relatively minor (http://arclanguage.org/item?id=20772). Arc 3.1 was released in 2009 (http://arclanguage.org/item?id=10254).


next implementation of Arc

Are there any details about this anywhere? What's it written in?



Will the next implementation of Arc also include the ability to delete posts and comments?

Surely there might be some portion of the 1,200 people who posted today that may want to delete their submission in the future.

Allowing them to do so would be civil don’t you think?

(There may also be those who figured out there is a risk here and just avoid sharing anything anymore, but that’s another story).


Your many posts and emails about this are beginning to resemble harassment. We've given you many lengthy explanations and I've deleted dozens of posts at your request. I've spent hours engaging with you about this, answering questions and objections and explaining HN's approach in deep detail.

As I've explained many times in these conversations, we're happy to delete specific posts and to redact identifying information. What we don't allow is wholesale deletion of account history. You disagree with that—you've said so dozens of times—and this has now become repetitive and your behavior has become abusive. Actually, it became abusive months ago, including with surprisingly vicious comments in email. We try give people the benefit of the doubt and cut them slack for as long as we can, but I don't see what else to do at this point but ban your account and ask you to stop.


So the person with all the power, the one who speaks in plural about what he allows is suddenly some how the victim?

Please just delete all my comments. Including this one.


It's time to stop.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: