Hacker News new | comments | show | ask | jobs | submit | mikevm's comments login

Is there a reason to learn Perl these days when we have Python?

-----


In my case, I find the Moose ecosystem much preferable to almost any other OO system I've used. Better multidispatch would put Moose over the top.

The last time I looked at Python 3, Perl still had much better Unicode support. In particular, grapheme support in regexes, built-in casefolding, and easy normalization made a 100+ country project much easier.

The stability of the language, core libraries, and CPAN modules across major releases really helps with maintenance. Python's 2/3 break was a bummer for a lot of people for a long time that I'm glad to have (mostly) avoided.

-----


Generally, dealing with data in multiple encodings is far more pleasant in Perl (or at least less unpleasant). I came back to Perl for this very reason when I had to write a script that pulled data from our Active Directory (unicode), our ERP system's database (Latin-1) and a bunch of text files (CP1252), merge it and render it into a HTML file or an Excel sheet (unicode). I tried using Python, but I quickly gave up in frustration.

-----


What's your take on Perl6?

And do you plan to update the book to cover Perl6 some time in the future?

-----


I have no plans to use P6. It's probably years away from having the ecosystem sufficient to support what I personally want.

I have no plans to update the book to cover P6; I think it does what it needs to do as it is now.

-----


I'd bet Perl6 ecosystem will evolve very fast, I don't think you will need to wait several years

-----


Anything that evolves fast also will have stability issues. Part of the draw of CPAN is the stability that comes from mature codebases.

-----


I hope so. It's pretty bare at the moment, but it shouldn't take too much to get it to where, say, Go-lang was when people started to adopt it in earnest.

-----


Won't Perl6 make the book redundant, I mean the whole reason we needed a Modern Perl book was because there was an old and crufty way of writing Perl5...but Perl6 ditched all that baggage so the only way to write Perl6 will be comparable to Perl5's "modern Perl" paradigm?

-----


Modern Perl book was first released a few years before P6, which isn't even released yet. The companies that currently use Perl (at $work, even) are not going to switch to P6 any time soon, but can, and do benefit from the more recent best practices using Perl 5.

-----


So I guess Perl's 5/6 break was also something of a bummer, huh?

-----


I look at it in two ways.

First, Perl is installed on millions of machines by default, with full access to the CPAN--still one of the largest repositories of freely available libraries, with Perl's backwards compatibility and testing offering a lot of stability. If P6 comes out and succeeds, it'll still be quite a while before it can offer anything like that.

Second, I've given away electronic versions of the book for five years. It's not about the money or the job prospects for me. I figure the book's helped more people than I can count, so why not continue?

-----


I figure the book's helped more people than I can count, so why not continue?

It's one of the finest programming books out there, about any language. And your work is very much appreciated. (We've never met, so I hope you don't mind me saying).

-----


Long-time Python dev here, recently started picking up Perl (both 5 and 6).

As with anything, learning another language will give you insight into how things _could_ be done, and you'll pick up a new perspective on programming.

More concretely, I've been liking perl because it's much more expressive than python, especially when writing small unix-y programs or scripts to control the machine.

And of course, sometimes it's just nice to have a variety of tools in your toolbox. We may as well ask whats the reason for learning Python when $LANGUAGE exists. The answer is always going to be some variant on "just because".

-----


I'm not sure I agree that that there is clear winner in expressivity between Perl and Python. In Perl dealing with nested data structures feels really awkward. And Python's list and dictionary comprehensions and generator expression are very handy and highly expressive. Anonymous functions are much more pleasant in Perl than in Python. The added flexibility in placing 'if' and 'while' in Perl is nice sometimes, but I don't think it is a huge advantage.

Going over this (personal) list made me realized I'd probably like Perl 6 better than either Perl 5 or Python...

-----


"more expressive" is often a slippery slope to "I can't read and understand what I wrote 3 months ago"

We read code more than we write it, so optimizing for typing time vs reading time is just losing the war to win the battle IMHO.

-----


I think you misunderstood what "more expressive" meant. It doesn't mean "more concise", though Perl can excel at that too. It means that expressions can be stated in more meaningful ways.

    do_the_thing() if $is_ok;

    warn_the_user() unless $is_ok;
The if/unless pair, along with the ability to put conditionals either before or after the statement to execute, is just one example of Perl's ability to be very readable.

-----


If we're honest with ourselves these discussions are never really about anything more than taste and have almost no technical foundation, but with that said I don't think the trailing conditional is more readable. In the rest of Perl the order in the text of an action normally indicates the sequence of the side effects, but here the first thing to be executed is after the first thing in the text.

-----


Larry Wall is a linguist first, and the design of Perl's syntax reflects that. So I can totally buy taste being more important than technical foundation, in the same way good graphic design is done.

These expressions with the conditionals on the end are supposed to reflect English phrasing. English isn't strict about the order of parts of speech; you can mix them around to change the emphasis. These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent, the way one programmer might explain the logic to another programmer.

-----


> These expressions with the conditionals on the end are supposed to reflect English phrasing.

But nobody's ever explained why that would be a good thing to do. We say things like 'you can read it out loud and it sounds like English', without ever arguing why this is a good thing.

Do most programmers even have English as a first language?

I'm not sure aspiring to be like natural languages actually has any merit. I think we should aspire to precision and clarity. Natural languages rarely have those qualities.

-----


From DougWebb, explaining why this would be a good thing to do.

>> These expressions are the same; they're not meant to strictly indicate order of execution, they're meant to express programmer intent.

We can achieve perfect precision and clarity by naming all of our variables x1, x2, x3, x4, etc. But it's better to give descriptive variable names because it helps us and anyone else reading the code understand what it does. This sort of expression is similar.

-----


I can't see any argument in there. 'meant to express programmer intent'? What does that mean? Basing programming languages on mathematical notation or something else would also of course be 'meant to express programmer intent'.

Why are natural languages a better foundation for programming languages than, for example, maths notation or calculi? Everyone in the Perl community seems to think they just intuitively know it is, but can't explain why.

-----


When you're speaking to another programmer, explaining what a bit of your code is trying to do, do you speak in mathematical notation? I doubt it. I don't think even mathematicians do that.

If you want a well-expressed explaination for why Perl's approach is a good idea, you should read what Larry Wall has written about it. All I can really say is that it worked really well for me and my team for many years. We rarely misunderstood each other's intent, even though our code reviews were mostly just reading commit diffs.

-----


Think of it as a commenting or documentation system that's also interpreted by the language. Comments that can never get out of date.

If you think that human-readable comments and documentation are not useful... then I'm not going to try to convince you that you would benefit from perl's syntactic flexibility. But surely you recognize that there are some people that like documentation, useful comments, and informative variable names.

-----


Everyone already knows what `if x then y` means, why is there a need for `y if x`? They're both as clear

-----


It's actually "if x { y }" in Perl rather than "if x then y". This favours blocks of multiple expressions whereas "y if x" is good for a simple single expression.

A lot of the Perl branching and looping directives provide both methods so you can choose what you prefer.

Having both ways is great for the Perl one-liners :

    cat file | perl -e 'while (<>) {next if /^SKIP /; print if /<fancy regex>/;}'

-----


If all someone wants to express to a reader is literally `if x then y` then `y if x` doesn't really help.

But we typically don't write utterly trivial one-liners with single letter names for conditions and actions.

In actual programming there are times when it's more like a series of lines, each of which is something akin to `if some-expression-that's-so-much-longer-than-a-single-letter-that-you-start-to-consider-factoring-it-out-in-to-another-variable-or-function then some-function-or-flow-control`.

And when that happens there are times where by far the most important thing a writer wants to first bring to the attention of a reader (eg themselves, later) is some-function-or-flow-control.

Sticking with made-up examples for a moment, there's:

  if long-complex-conditional----that-you-might-start-to-read-thru-in-an-attempt-to-understand-the-code-you're-reading---is-true then blow-rocket-up
vs

  blow-rocket-up if long-complex-conditional----that-you-don't-need-to-read-and-understand-to-understand-that-the-rocket-will-blow-up-if-it's-true----is-true
Or it takes me I estimate less than a second to know the gist of the overall control flow of this fragment from a recent Advent of Code entry[1]:

  next unless (() = /[aeiou]/g) >= 3;
  next unless /(.)\1/;
  next if /ab|cd|pq|xy/;

  $count++;
I can immediately see that it increments `$count` unless it bails out of the containing loop (`next`s) due to any of several (complicated looking) conditions.

In contrast, it might well take me more than a second to figure that out if they'd written:

  unless (() = /[aeiou]/g) >= 3 { next } ;
  unless /(.)\1/ { next };
  if /ab|cd|pq|xy/ { next};

  $count++;
While these examples are pretty weak, I have hope that they might at least give you pause for thought. If you don't see anything going on here worth even thinking about, or more importantly seriously reflecting on, well, at least I tried. And if you're a trained linguist and/or able to quote science to refute what other scientists are finding in recent studies[2], please quote away. :)

[1] https://www.reddit.com/r/adventofcode/comments/3viazx/day_5_...

[2] http://www.infosun.fim.uni-passau.de/cl/publications/docs/SK...

-----


While I agree with you that they are not more readable, there are some other notable cases like that in the language, for example:

map { row => $_ } $db->get_rows

-----


This is harder to parse in my mind than:

  if is_ok:
    do_the_thing()
  else:
    warn_the_user()
In that you can see more or less visually what the intent is rather than having to mentally parse the text. But perhaps that's just personal taste.

IMHO, expressiveness and conciseness are largely the same idea because when you talk about the former, you mean being able to bang out an idea in fewer lines of code yielding the latter.

Having a complex grammar and a myriad of ways to do the same thing seems very neat, but in the end the productivity gained in the writing, you waste several times in the reading, so it ends up being a net loss.

But Perl lost the dynamic language wars a long time ago -- I think perhaps some of the flavor got picked up in Ruby?

And having a language read like English is IMO, a bad idea -- English is very ambiguous in many cases -- mimicking this in your programming language would be a bad idea indeed.

-----


It's precisely a slippery slope argument[1], which is generally much debatable.

Perl somewhat indulged the nix culture tendency to write extremely concise and cryptic one-liners, but* this does not mean that verbosity is good and expressiveness is bad.

[1] https://en.wikipedia.org/wiki/Slippery_slope

-----


Yes.

I use Python usually but Perl is simply faster at processing large amounts of text.

And while Python has made great strides in regex readability since the 90s, Perl's regexes are still more cleanly and flexibly incorporated into the language.

-----


I started as a Perl dev, and I must say that some of the principles I learned there that I still feel are underutilized in other languages even though the syntax could support them.

I think the very nature of Perl meant that I had to learn additional tricks to make the code make more sense when I returned 6 months later...tricks that I wish other languages embraced. Having your code not be obscure is the minimum, not the maximum you should be shooting for.

Also - I'd still write short scripts (basically glorified one-liners) in Perl vs Python. JS is getting up there, but still isn't as expressive as Perl.

Edit: And I say this with full respect for other languages, particularly Python that has done a lot for many areas of development

-----


What are some of these principles that you've learned?

-----


Hmm...hard to put into words.

But here are some examples:

Perl often gets flak for "There's more than one way to do it", and sometimes that's justified: It's confusing to do things a billion different ways. BUT, sometimes you can use those different ways to be meaningful. So:

foo() unless (condition) vs if(!condition){ foo() }

They are FUNCTIONALLY the same, but COMMUNICATE differently. If you don't pay attention to the latter, then TIMTOWTDI will be an enemy. If you do, then it can really help.

Also: "not", "and", "or" - I wish more languages had these. && and || might seem to be the same thing, but there's no reason to cling to foreign symbols where native (for english speakers) symbols do the same. ! is particularly bad, since it's so small, can easily blend in to an adjacent paren, and yet REVERSES the meaning. Don't get me started on the terrible switch/case syntax that is perpetuated for no reason other than C did it.

Moving away from syntax, hashes/dictionaries/associative arrays/Js objects, these guys all have the same basic addressing style. If you're using them in a context where the key will almost always be present, why not use that?

instead of addresses[currentAddress] use address_of[current] (or addressOf[current]

Instead of building variable names that are 4-5 camelCase words, use the hierarchy of your structures to communicate more clearly.

variables are WORDS. Too few words doesn't communicate clearly, but too many is just as obtuse.

There are a great many "clean" bits of code out there - nicely structured, nothing wrong, but I'll still have to read the whole to understand a part of it. Similar to the semicolon argument: The reason I object to dropping semicolons is not that the statement needs it - but that I need to read the next statement to retroactively know if the statement needs it.

If you can write code so that a reader understands what is happening as they read, rather than understanding the whole and then viewing the parts in that context, your code becomes that much more maintainable.

-----


Personally, I use Perl for small-ish programs (roughly less than a thousand lines, counting comments and long text constants such as SQL queries) dealing mostly with text, and in that area it is fairly hard to beat.

Also, while Python's library ecosystem has grown a lot over the years, in Perl you can find so many modules on CPAN, ranging from very common tasks (like talking to a database / ldap directory / network service) through fairly exotic (at least in my perception: e.g. formatting datetime values in just the right way to feed them to MS SQL Server, figuring out if a given day is a holiday in a given federal state of Germany) to downright silly (but in a clever way: CPAN's ACME::* branch). You think of it, CPAN probably has it.

One thing I have grown to appreciate about Perl is its mentality of helping you getting the job done no matter what. Python is a - relatively - clean and simple language, where Perl is not ashamed to be messy, but it's oh-so-useful I just cannot stay mad at it. ;-)

Last but not least, the Perl community is awesome, there are so many friendly and helpful people around willing to share insights, code, and words of encouragement. (That is not to say other languages have bad communities, not at all!)

-----


> One thing I have grown to appreciate about Perl is its mentality of helping you getting the job done no matter what.

It is incredibly effective at helping prototyping rapidly small ideas.

> the Perl community is awesome, there are so many friendly and helpful people around willing to share insights, code, and words of encouragement.

And CPAN helps a lot too! It can be considered as an important part of what makes this community so special, it is a very serious repository of modules, I mean not only code: it is incredibly usable, with lots of documentation and a crazy test infrastructure (http://www.cpantesters.org/) that helps to build quality distributions.

The good thing with the Modern Perl book is that, before explaining the language itself, it explains the Perl philosophy. And then it explains about the community and the CPAN. Being modern is also about not writing code and re-using long-tested modules from CPAN with cleans APIs: it helps to compose quality code and make maintenance easier.

-----


Not really. As in, I wouldn't start from zero and try to learn enough to get a day job at it, at this stage.

There are still so many negative tradeoffs in Perl 5 -- especially, and most crucially, for new adopters -- that I don't think it will ever make up the ground it has steadily lost to Python/Ruby/PHP over the last 15 years. P6 has addressed many of P5's most notorious faults, while perpetuating others, and quite likely introducing a whole family of newer, far subtler traps and pitfalls. All while being not particularly fast, poorly document (last I checked -- about a year ago), and like Perl 5, just plain.... zany.

That said, there are a lot of incredibly bold -- we might even say, "ahead-of-their-time" ideas in Perl 6 (just as there were in Perl 5, in its time), and I sincerely hope many of these will be carefully studied -- and I won't be surprised if some of them are incorporated to whatever "lingua franca" that ultimately emerges and ends up burying Python, hopefully not too long from now.

-----


> incorporated to whatever "lingua franca" that ends up burying Python, hopefully not too long from now.

Sincerely, at this point (Dec 2015) I feel like python is well too far along to be buried. As you state, if something better comes along I too would welcome it, but, and correct me if I'm wrong, python has been around for 20+ years, I don't see it being buried anytime soon.

-----


Yeah, I meant "not long" as in 20-30 years from now. It's definitely got a lot of momentum. But ultimately, we can do better.

-----


Statically typed scripting languages? Please let it be statically typed scripting languages.

-----


At the very least, the fact that we have Python does not make Perl irrelevant.

-----


No, but the multiyear period where Perl 5 development stalled waiting on Perl 6 and much of the community moved on might.

-----


Yeah, fortunately nothing like that is going on with Python.

P.S. That was intended as VERY light-hearted ribbing, not as a snide remark.

-----


> Is there a reason to learn Perl these days when we have Python?

Yes, the GIL - global interpreter lock (in python) is a reason if you are doing multithreaded stuff in a scripting language (which i think is a bad idea by definition because suddenly you are debugging problems in your program as well as the interpreter/runtime)

Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.

-----


Let's not pretend perl threads solve concurrency issues in dynamic languages.

The third item in the threads perldoc, after the table of contents and the version, is a big, fat warning about how you shouldn't use them [1]:

> The "interpreter-based threads" provided by Perl are not the fast, lightweight system for multitasking that one might expect or hope for. Threads are implemented in a way that make them easy to misuse. Few people know how to use them correctly or will be able to provide help.

>The use of interpreter-based threads in perl is officially discouraged.

> Perl 5 has an interpreter instance per thread, so it doesn't have a global interpreter lock. It will have other problems with threads though - you can easily run into deadlocks for example.

Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes. Also most of the librarys that use perlxs modules aren't thread-safe.

[1] http://perldoc.perl.org/threads.html

-----


> Let's not pretend perl threads solve concurrency issues in dynamic languages

i didn't 'pretend' that - that's a misstatement; still a big fat lock in the interpreter isn't a concurrency solution at all, instead of running concurrently your threads will be mainly blocked on the lock.

Interpreter threads is an approach that does without a global lock, but as i said it is still a pain to debug the result - as you are effectively debugging both your program and the runtime.

> Which makes threads more expensive than processes on *nix because you don't get the advantages of copy-on-write processes.

threads are not copy on write processes; that is not unique to perl threads. The advantage of threads is that it makes easier to share data - with processes you will need to do a shared memory segment for that. Also it is less costly to create a thread rather than a process.

-----


> The advantage of threads is that it makes easier to share data

Sharing of data is of marginal benefit when you have to pay the cost of duplicating all of your data to begin with. Perl also has modules that make forks just as easy to use as threads.[1] This is doubly so when most libraries have little to no regard for thread safety because perl's threading support it so bad.

> Also it is less costly to create a thread rather than a process.

Not unix because of copy on write processes [2][3]. Perl threads copy not just the interpreter but all local variables. [4] The only place threads are useful is on windows where the cost of a fork is higher than a thread.

[1] https://news.ycombinator.com/reply?id=10708168&goto=item%3Fi... [2] http://stackoverflow.com/a/16658623/2863146 [3] http://www.perlmonks.org/?node_id=306089 [4] http://perldoc.perl.org/perlthrtut.html#Performance-consider...

-----


> most libraries have little to no regard for thread safety because perl's threading support it so bad.

Fwiw Perl 6's concurrency and parallelism is very much one of its strengths, not one of its weaknesses.

(It's pretty obvious to me that you are writing about Perl 5, not Perl 6, but it might not be obvious to others. Indeed some folk will even claim Perl 6 isn't a Perl, but Perl's original creator Larry Wall thinks Perl 6 is a Perl, and I think he has a point.)

-----


Oh, but that refers to perl 5, for which threads were always something of a bummer.

As far as I can tell, concurrency and parallelism in perl6 are a quite different and really powerful tool.

-----


Perl 6 is extremely cool.

-----


Indeed. But the book is about Perl5. Perl6 is such a different language that someone moving from Perl5->Perl6 will likely be mostly/completely a rewrite.

... unless, I suppose, they are following the practices in Modern Perl ala Moose and some other things. I guess maaayybbeee they could translate across. But it would be touching ever single line, in a transformation that would be on par with switching to Ruby (or Python I suppose).

-----


It seems disingenuous to imply that moving to Perl 6 from Perl 5 is akin to switching to Ruby or Python (much less "touching every single line"). Perl 6 supports Perl 5 syntax with Inline::Perl5. So, in theory, one could move Perl 5 code directly into a Perl 6 project without changing much at all.

Edited: an earlier version of this comment that referred to an outdated FAQ (mentioning a perl 5 to 6 translator).

-----


That page looks almost six years out of date. I believe the project to which it refers has bitrotted.

-----


Yes, I updated my comment, but my point still stands: Perl 6 supports Perl 5 syntax and migrating is nowhere near as hard as was implied. Sorry for confusion.

-----


Your comment is still blatant disinformation. By the same measure Perl6 is also Python and Java and JavaScript, because somebody could make an Inline:: for any of those.

You could say that a number of hooks exist to make it easier to write various Inline:: variants, and you would be correct. But claiming that there is a special soft spot for the Perl5 interpreter is factually wrong.

-----


What disinformation? Perl 5 is supported when using Perl 6. The comment I replied to states:

"Perl6 is such a different language that someone moving from Perl5->Perl6 will likely be mostly/completely a rewrite."

Rewriting is not always necessary due to Perl5 support.

The comment further states:

"I guess maaayybbeee they could translate across. But it would be touching ever single line, in a transformation that would be on par with switching to Ruby (or Python I suppose)."

Touching every single line is technically not necessary due to Perl 5 support.

To your comment:

"But claiming that there is a special soft spot for the Perl5 interpreter is factually wrong."

Nowhere in my comments did I make any such claim. I was simply refuting the statement that people with Perl 5 code will have such a difficult time with Perl 6 that it would be just as painful as dropping all their Perl code and switching languages.

-----


Although to switch to ruby or python you'd likely end up either typing out a lot of things Moo(se) give you or trying to port them (see also the MooseX gem and Elk)

-----


This book is for Perl 5

-----


I believe that "Git for Windows" has been EOL'd in favor of https://github.com/git-for-windows/sdk (which hasn't seen a first official release yet).

-----


>This is an Inno Setup based wrapper around MinGW's mingw-get which installs a development environment for building Git for Windows using GCC.

This installs the dependencies and environment needed for building Git from source. I think that's overkill for most users.

-----


SMS is unreliable. It may arrive in an hour, the next day, or not at all.

-----


In practice, it seems about as reliable as email, and faster to get to me.

-----


Here's a short clip of him giving the answer on what he learned from Steve Jobs: https://www.youtube.com/watch?v=2oksetv3i90

-----


I too was surprised by the high civilian casualties given Israel's attempts at warning the population before they strike. I wondered why would people stay in that area if they knew the Israelis were going to strike? And then I got the answer: http://www.gatestoneinstitute.org/4706/gazan-hamas-war-crime...

    "Hamas imposed a curfew: anyone walking out in the street was shot. 
    That way people had to stay in their homes, even if they were about to get bombed. 
    Hamas held the whole Gazan population as a human shield." — K., graduate student
Regarding the civilian-to-fighter ratio: http://www.bbc.com/news/world-middle-east-28688179

Another interesting thing to note is that according to the CIA World Factbook (https://www.cia.gov/library/publications/the-world-factbook/...) Gaza's age structure is:

   0-14 years: 43.2% (male 402,848/female 381,155)
   15-24 years: 20.6% (male 191,710/female 182,405)
   25-54 years: 30.1% (male 280,551/female 266,756)

-----


Fulltext (paywalled): http://www.sciencemag.org/content/345/6202/1326.abstract?sid...

-----


This approach reminds me of a course I took on Coursera a while ago called "A Brief History of Humankind": https://www.coursera.org/course/humankind

It is the best enrichment course I had ever taken. I wonder if the lecturer (Yuval Harrari) was influenced by this "Big History", or he arrived at this teaching method independently.

-----


Paper here (paywalled): http://www.sciencedirect.com/science/article/pii/S0042698914...

-----


If you're looking for a textbook, this one is pretty good: http://www.amazon.com/Introduction-Modern-Cryptography-Princ...

-----


Not only for women...

http://www.nature.com/nm/journal/v14/n11/full/nm1108-1170a.h...

http://www.nytimes.com/2012/08/23/health/fathers-age-is-link...

http://www.nytimes.com/2014/02/27/health/mental-illness-risk...

-----


But for children of older fathers, there are well documented advantages as well:

http://www.cbc.ca/news/canada/older-fathers-may-pass-health-...

http://www.mommyish.com/2012/06/12/older-fathers-benefits-65...

-----


Huh, I never figured.

I guess that's a reason to spermbank. Though really, people should just have kids young in the first place. :/

-----


I disagree - I would have made a terrible father if I had kids in my 20s.

I mean, I might still make a terrible father, but I'm trying to imagine 23 year old me raising a child and it's terrifying.

-----


Don’t worry too much about being a bad father - as long as you are there at least some of the time and don’t beat them and their mother then they will almost certainly turn out OK.

My experience with my own children is the effect you can have on them is very limited - this is both liberating and depressing.

-----


You are largely correct: http://www.amazon.com/The-Nurture-Assumption-Children-Revise...

-----

More

Applications are open for YC Summer 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: