There still seems to be interest in the project. The forum gets new topics posted every few days [1] and Anarki, a community ran fork of Arc, shows recent commits [2].
They were converting from Arc to Racket, but I don't know how much ended up being done (https://github.com/hubski/hubski/wiki/Converting-Arc-functio...).
And the main reason reddit was rewritten was library support. Doing simple things in CL was hard because you had to write it from scratch, but doing those things in Python was a simple library install.
A little white space would be helpful.
I would have done something like this: https://i.imgur.com/Ck96siZ.jpg
> A classic article on using powerful programming languages as a secret weapon
I'm surprised this is included given that it's been more or less been proven to be false. Almost every valuable company in the past 2 decades was built on a blub language. Facebook even used PHP! Java and C++ are at the core of most Amazon and Google services. There basically haven't been any big companies build on a lisp-like language unless you consider Scala, but even the most companies adopted that later.
edit: blub
It should be developers.ycombinator.com
You should be using .test or .localhost for any development domains: https://tools.ietf.org/html/rfc2606#section-2
What browser are you using that you are not redirected to https://yc.dev?
>Most major browsers (Chrome, Firefox, Opera, Safari, IE 11 and Edge) also have HSTS preload lists based on the Chrome list. (See the HSTS compatibility matrix.)
The "About" link at the top links to HTTPS, but it's a 404, because it points to //about instead of /about
I see it pretty high up on the site, and I thought the consensus is that nowadays most languages have enough lispy and functional features to give similar productivity.
Is there any benefit from hyperflexible languages high enough to outweigh the benefits of readily available libraries?
Libraries, documentation and community are reasons to use non-Lisp languages for certain projects, but if you don't have some kind of Lisp in your toolbox, you're still missing out in 2019, in my opinion.
If you go to http://yc.dev, you get an HTTP 307 (Internal redirect) to https://yc.dev.
https://get.dev/#benefits says: >The .dev top-level domain is included on the HSTS preload list, making HTTPS required on all connections to .dev websites and pages without needing individual HSTS registration or configuration.
Somewhat shocking to see a brand new 2019 website that isn't responsive, especially when it's not super difficult.
:(
it seems a little bit outdated
I have my eye on some short .dev domains too, but I'm hoping to get one for $350.
Hopefully someone who knows the details could chime in on that.
Not really. It's true that few big winners have used Lisp, but that would only disprove the thesis if there were also companies who tried using Lisp and failed. AFAICT, no one is even doing the experiment.
I actually know of two notable counterexamples: Barefoot Networks has an internal design tool written in Common Lisp that is a significant source of competitive advantage for them. Also Orbitz.
Most languages have the features of CL that made it so useful. Even Java has first class functions, lambdas, partial application, async IO, etc. Java even has a repl now. The only things left afaict are macros (non-hygenic in CLtL2) and code-as-data/eval (a security hole).
Aside from pulling from functional languages, Java also learned Python's 'with' using try-with-resources. Meanwhile the tooling of Java went from strength to strength and it's a serious blub factor for people who haven't used Java.
Beating the Averages was fairly spot on at the time it was written, but since then it's lost it's power as features of blub languages was merged into existing languages.
According to Alan Kay, Smalltalk was an explicit attempt at making something as dynamic as Lisp, but where one wasn't "coding in your data representation." There was very high representation in the Fortune 500, and some very big business applications. Much of the natural gas in North America was scheduled on a Smalltalk application. JP Morgan used Smalltalk to manage very large portfolios at one point. I could go on about the applications I know about personally for hours, actually.
The line blurs, however, as Java was very much inspired/influenced by Smalltalk, as was the CLR and C#. Ruby and Python were also highly influenced by Smalltalk. Javascript was influened by Self, which was effectively the "Son of Smalltalk." Smalltalk, at one point, was also cited as being a "blub" language. (No templates, no macros, no explicit multiple inheritance...)
But did they succeed because or despite those languages?
Would they have been even more successful and would their code have been more maintainable, more easily exapandable, had more power or more flexibility had they used Lisp?
Had to look that up — do you mean a blub language?
Anyhow, it would be rejecting the argument of the blog post to link to it there, and the blog post itself is a bit of an increase incoherent mess (the author proudly identifies as female, adopting one label, and seems to equally proudly adopt the tech worker label, yet rejects the woman in tech label with the argument that rejecting all labels is essential to inclusivity. This is both incoherent on a surface level, and deeply problematic in that labels are the interface the human mind uses to deal with the world; rejecting all labels is rejecting all ability to model and interact with the world.
Embracing her identity as a woman gives her a place to build her character from. Being a "Woman in Tech", the way she's using the term, pigeonholes her into acting or looking a certain way, for fear of the dissonance it might create for someone else.
That's a valid viewpoint. But I don't see the "echo chamber effect" you're talking about. I think most people seeking out the "Ask a Female Engineer" series are aware of other viewpoints that exist.
The main thing I wish they would do under that heading is link to the category, not just one of the blog posts. https://blog.ycombinator.com/category/ask-a-female-engineer/
Sure, but it would still be cool if it wasn't.
This is teddyh's comment, he can say what he wishes.
At the same time, I'm skeptical of attempts to increase the number of women in STEM fields, especially those sponsored by major tech companies or venture capitalists. They seem like thinly-veiled attempts to increase the pool of potential workers and decrease wages - the same way that these tech companies lobby to increase the number of H1B visas. I think the best way to work towards ending discrimination towards women in the industry, and also discrimination towards immigrants (without decreasing wages) is organizing tech workers collectively.
Edit: I was just guessing at the ratio of male to female engineers, so maybe I overestimated the imbalance, but I think the point stands.
EDIT: Maybe tax forms, but I'm not sure the legality of that... but I think it's still the census.
They aren't reserved as the term is usually used for domains. Reservations don't exist in outside of those codified in RFCs; the IANA is the party that reserves domains and the full current list of reserved special use domains is here:
https://www.iana.org/assignments/special-use-domain-names/sp...
More general info on reserved domains is here:
https://www.iana.org/domains/reserved
Note that of those domains you falsely describe as reserved, .home was suggested as a special use domain in RFC 7788, but that was updated by RFC 8375 to the reserved domain .home.arpa.
.home, .corp, and .mail (but not .lan, AFAICT) are subject to a ICANN policy decision against granting delegations as TLDs, though, which means they won't become real TLDs while that policy is in effect (it doesn't mean they won't get reserved for a use which might conflict with what you might adopt them for, the way .local has for some uses, though.)
Sure, abstractions are not the underlying reality, the map is not the territory, and the Tao that can be told is not the true Tao. That doesn't mean that it is necessary to “reject all labels” as a fundamental requirement for inclusiveness, or even that rejecting all labels is useful or even possible given the way human minds work. It certainly means we need to understand that all labels obscure as well as explain, and understand where each is useful and where each is counterproductive.
But that's not what the blog post in question is arguing, or if it is intended to be it is not argued well.
I've yet to see a reason to believe that complex thought or communication is practical among humans, other than through manipulation of labels for abstractions over the underlying subject matter, so that doesn't change my objection to the argument one bit. You can recognize the limitations of the models underlying labels and be careful in choosing models (and thereby, relevant labels) that you have reason to believe are useful for the specific purpose and recognize that you're still subject to imperfect results in the best case, but labels are, ultimately, universally essential.
And that certainly doesn't mean you can't reject the utility of particular labels and their underlying model, either in general or for particular uses, but that doesn't get you to “reject all labels” much less that you must do so as a prerequisite for inclusiveness.
I think it'd be better to use an out-of-date list instead of nothing; I should go push for that again.
(2) is not really a concern any more, (3) occasionally becomes a concern, (1) is a concern for most of the web, and (4) is a concern for literally every use of HSTS.
The whole point of HSTS is to ward off man-in-the-middle. If all a man in the middle has to do is wait, and is eventually guaranteed a shot at exploiting you, they will. So all HSTS gives you is the small hedge that if an attacker is present, but not persistent, and not targeting you specifically, you're slightly more secure.
Basically, it only protects you if a random hacker is sitting in a coffee shop you don't normally go to, and only if your browser is up to date, and only if every site you want to visit uses HSTS, and only if you've visited them before. It's so incredibly specific that it's almost pointless.
A better solution would be either (A) an extention to the specification to actually support a "secure://" URI prefix, or (B) a proxy or browser mode that only allows valid HTTPS connections. These are user interface fixes, because the entire point of HSTS is to prevent users (and really bad apps, I guess) from accidentally using HTTP.
That doesn't seem like it's enough time. I would expect one year or at least 6 months.
I can confirm here in Chrome and Firefox that the URL is rewritten internally to https://yc.dev (which then redirects to https://ycombinator.dev), so no unencrypted traffic is ever sent over the network.
For a very short period they will be a status symbol for internet companies.
That might be what the buyer is hoping for, but the reality is they're probably mistaken.
Also, does that site even work?
Status: google.com is not preloaded.
Status: microsoft.com is not preloaded.
Status: duckduckgo.com is not preloaded.
Status: news.ycombinator.com is not preloaded.
Status: aws.amazon.com is not preloaded.
Status: bankofamerica.com is not preloaded.
Status: capitalone.com is not preloaded.
Would I like a .dev domain? Yep. Can I afford it? Nope. Therefore ... status symbol.