Should this list filter companies that are shutdown or have been acquired and no longer have an active product? Many of the links are "our incredible journey" acquihire announcements or just 404. I understand and appreciate the value of having a list of all developer services companies that have gone through YC, but as a developer resource page it's annoying to see a product that might fit my needs but is long shutdown.
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].
I don't think so, although as the sibling says there is hobby activity. Interestingly enough, though, reddit was originally written in arc, but they later rewrote it in python. Make of that what you will.
As sibling said, reddit was CL before it was Python. But more importantly, reddit predates Arc by more than two years. :)
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.
It's easy to roll anything in CL if you know what you're doing, but making it talk wsgi or generate pngs isn't trivial, no matter what language you're writing it in.
I think so? I honestly don't know, I never really worked with the CL codebase, I just used it for reference sometimes. But even if it did, I'm not sure how much velocity is gained by using CL vs. Python, especially when making a web app, where there are so many examples, libraries, and frameworks out there to help in Python.
While I have admittedly limited experience with it, CFFI worked awesome for the couple things I tried to do with it. I don't have any CL code in production yet, but enjoy using it when I'm doing some recreational programming, or looking for something that's easy to embed in a C program (Lua's nice, but it's trivial to take the ECL Common Lisp implementation and hook up emacs-slime to it, even when it's embedded in a C program)
Lisp shines for codegen and creating DSLs and new control structures, but if you're just writing out tedious imperative code, it isn't really better than Python. Its lack of popularity means it can't offer as many libraries waiting to be reused.
Exactly. With good padding and a bit of extra white space and maybe a faint border, it would be possible to notice that the description for Airship (w2018) is missing.
> 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.
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.
Keep in mind the at that Beating the Averages is from 2001 (revised in 2003). This means that it predates Java 1.4 and obviously C++11 (let alone C++14, 17, etc)
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.
If not commercial Lisp, what you think about using Racket for both the IDE and so they can pre-scale by giving HtDP to good developers who want to learn Scheme?
There basically haven't been any big companies build on a lisp-like language unless you consider Scala
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...)
"Almost every valuable company in the past 2 decades was built on a bulb language."
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?
I just noticed that clicking on 'About YC' (top, next to YC logo), results in a 404. Looks like the link contains a '/' too much: https://www.ycombinator.com//about/
> .corp, .home, and .lan are also reserved, just not codified into an RFC yet.
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:
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.)
According to https://get.dev/#benefits:
>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.
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.)
In Chromium, the whole HSTS preload list is expired if it gets too out of date, as domains are both added to and removed from the list. So you're giving up real security by running an out-of-date browser. Not only are HSTS-preloaded TLDs not secured, but even, say, gmail.com or yourbank.com aren't. See: https://chromium.googlesource.com/chromium/src/+/lkgr/compon...
I think it'd be better to use an out-of-date list instead of nothing; I should go push for that again.
HSTS only works if (1) the endpoint properly supports it, (2) the browser supports it, (3) the list is up to date, (4) there is no attacker ever waiting for you to hit the page for the first time or when HSTS expires.
(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.
(4) is solved by HSTS preloading. The request is upgraded to https before any traffic hits the network, even if you've never visited the domain before. The list of HSTS preloaded domains and TLDs is hard-coded into your browser. For more info: https://hstspreload.org/
Clearly it's not solved by preloading, since an old list invalidates the preload, and not every site supports HSTS, and I imagine they would have individual expire times (but perhaps not as a preload)
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.
Well right off the bat, I'm screwed... I hope nobody else on the internet is visiting these sites.
The source code says the data is only valid for 10 weeks. If Google releases a new version of Chrome every 6 weeks, then a user could never skip a single version of Chrome without becoming vulnerable.
That doesn't seem like it's enough time. I would expect one year or at least 6 months.
Can you confirm that it's not rewriting the URL to https://yc.dev first before issuing a request to the network? It's possible that Safari has suffered some kind of regression. This definitely used to work at some point.
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.
Unfortunately I’m not in a situation where I can test that. It’s very possible that that’s the case, but it then leaves the question of why the non-https ycombinator.dev is what we eventually end up on.
Separate from HSTS, they should also be redirecting http to https. Hopefully they'll get around to that soon. The domain is still recent so they're probably not finished with configuration.
I wonder how many of the YC companies use the other YC companies. And which are the most / least used. How much effort do you reckon is put in trying to "align" them and keep them aligned? As in there's a consistency in (e.g.) docs, APIs, etc.
On the one question currently in that section, they have a diversity of viewpoints from the panel. There's no evident echo chamber effect.
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.
I didn't read her article that way. I read it as "Creating a new box to push people into defeats the purpose of opening up the boxes of 'Women' and 'Tech Workers'". She's alright with the labels of "Woman" and "Tech Worker" because they're (relatively) open groups. There's a wide range of people who fit into them. On the other hand, when people are talking about "Women in Tech", there's an image, and expectations surrounding that.
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.
Sure, but overdoing it and confusing labels and abstractions with the things they represent can also keep a human from being more aware of the world and their deeds in it. I gladly reject the label "women in tech", but mostly because I actually do reject the label "tech" (and all stemming from that) to begin with, that's an umbrella so huge as to be meaningless. It's like "business", yeah I know what it is, just like I know what "technology" means, for any sensible use of these words, there's a million occurances where it's just padding at best, a cloak at worst, precisely a tool to not accurately model the real world, but a platonic simplified one that is easier to navigate than the infinitely fuzzy mess reality is.
> Sure, but overdoing it and confusing labels and abstractions with the things they represent can also keep a human from being more aware of the world and their deeds in it.
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.
When someone says "reject labels", I basically hear "don't think primarily in terms of them". I didn't take it as "don't ever speak it", but more "don't put it front, middle and last, 24/7". I can imagine it can be annoying/exhausting, part of feeling welcome is the understanding that it's perfectly normal for one to be there, I think.
> When someone says "reject labels", I basically hear "don't think primarily in terms of them".
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.
Labels, and words in general, while making it possible to communicate concepts to other people, also inherently make gross generalizations of those concepts, which confuses communication. Labels are therefore also used to “label” people, which is considered a bad thing. Therefore, some people really don't like labels.
I know women who feel the same way as the writer you cite. They want to just do their thing without being singled out as different, and don't feel the same need for solidarity that the "women in tech" women do.
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.
This is YC's site, which presents their view, which can be as partisan as they want it to be. There's no need for balance. Your opposing view is fine but they don't have to, and shouldn't, promote it if it's not what they believe.
I find myself somewhere in between the two viewpoints - I think there are a lot of factors that lead women in the United States to pursue careers outside of STEM, and factors that cause women in STEM to leave their tech careers later in life. I don't think it's a coincidence that many of the women in STEM that I know (including myself) are first or second-generation immigrants.
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.
It would be nice if there was an "Ask a Male Engineer" blog section also to get a more diverse viewpoint. It would be interesting to see the differences or similarities in opinions, perspectives and experiences of both genders. Or maybe just an "Ask an Engineer" blog where both genders' views are provided.
Just out of curiosity, do you follow any engineering blogs right now? What percentage of those blogs were written by a male engineer (since you're interested in their viewpoint)?
The viewpoints of male engineers are not particularly interesting, because they are the majority. The viewpoints of minority groups are interesting, but, the very categorization of “Ask a Female Engineer” excludes all women who feel like the article I linked to (and apparently there are more than a few of them). Furthermore, the category “Ask a Female Engineer” does not even acknowledge the existence of this viewpoint – it misleads the reader, who is probably from a majority group, into thinking that this is how all of the minority group members feel. Which is why I thought it might be useful for a reader to know about the existence of this alternate viewpoint, by the inclusion of a simple link, explaining why the very categorization of “Female Engineers” is problematic for some, even those who otherwise would belong to it.
I mean, it looks like 21% of all engineering degrees went to women, which is the easiest way to guesstimate the job data (and is generally how they guess the percentage of women in the workplace, along with questionaires). I get that you're being pedantic, before you start to explain yourself, but still.
EDIT:
Maybe tax forms, but I'm not sure the legality of that... but I think it's still the census.
No, it doesn't. It means "ask an engineer", and every engineer should know that due to lack of specificity the term does not exclude female engineers. Would you also imply that "ask a doctor" means "ask a male doctor"? What about "ask a nurse" or "ask a teacher"?
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?
It's hard to do reproducible experiments measuring productivity, but my personal opinion is it's still relevant. I say that as someone doing mostly JavaScript and TypeScript development day by day. I often miss the clean syntax and macro facilities of Scheme. I used to use Kawa Scheme a lot, which runs on the JVM, so readily available libraries were never a problem.
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.
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.
Does anyone know I can still reach this 'real' website if you're running Valet locally? I get 'Valet - 404 - Not Found' error, since Valet thinks 'yc' is a known Link or Address.
