alexhutcheson

Any analysis of Perl’s decline that doesn’t mention PHP is incomplete. Between the height of Perl’s popularity in the 90s and today, web development was the single biggest growth area, and PHP ate Perl’s lunch in that domain.

Why did that happen? In my opinion, PHP had two major advantages over Perl:

1. mod_php for Apache could safely be run in a shared hosting environment, so hosting for PHP was cheap and ubiquitous. mod_perl couldn’t be run in shared hosting, so anyone doing web development in Perl was stuck with either using CGI, or paying for more expensive dedicated hosting.

2. PHP’s approach made it easier to get started for people who were new to web development, or new to programming entirely. This was important in the late 90s and early 2000s as a huge number of people started doing web development for the first time.

By 2000, PHP was already the dominant “scripting language for the web”. If the Perl community had focused on improving web development, then maybe Perl could have caught up, but they focused on Perl 6 instead, and PHP continued its growth without much serious competition from Perl for web development mindshare. MediaWiki was written in PHP in 2002, and both Facebook and Wordpress were written in PHP in 2003.

The article focuses on Python, but during the relevant time period (roughly 1995-2005) Python was a niche and unorthodox choice for web development. Python finally started to gain traction for web dev in 2005 (Django, Pylons, TurboGears, and web.py were all released that year), but by that point Python was mostly competing with PHP, and Perl was already much less relevant.

In summary - the article focuses on how Perl lost the market for scripting, but scripting was always a smaller and less important market than web development, and PHP killed Perl in the web development market. If Perl had stayed relevant for web development, it likely would have stayed relevant in scripting as well, because programmers like to use languages they already know (see: JavaScript). Perl 6 was the nail in the coffin that ensured Perl wouldn’t catch up in the web dev race that it was already losing.

I didn’t count CTAN because Tex isn’t a general-purpose programming language, and so wasn’t competing for the same use-cases.

FastCGI wasn’t available for Apache until ~2004, so having something “akin to FastCGI” was actually a significant advantage until then. mod_perl was strictly more powerful, but that power made it inappropriate for use in a shared hosting environment, which limited Perl’s addressable market.

What would you use to write a quick RPC server or JSON endpoint in Java, if not Spring Boot?

Perl deserves credit for being way ahead of the curve: It was a free, widely available, garbage-collected language with good support for strings, during a time when the server-side alternatives were basically (primitive, early) C++ or expensive commercial toolchains. By 1995 it also had CPAN, which was (I believe) the first comprehensive directory of modules available for a language ecosystem.

The combination of garbage collection, good string support, and a huge set of easy-to-use third-party modules made Perl insanely productive relative to the other options at the time. Remember - Python didn't release a 1.0 until 1994, and Java 1.0 didn't come out until 1996, and the early versions of those languages were missing a lot of features you'd recognize today, and still had plenty of bugs and performance issues to work out. By 1994 Perl had been out for >6 years, and reached version 5.0 that year. In both capabilities and maturity, it was ahead of the other free alternatives, and way ahead of trying to wrestle with string templating in C or C++. Perl enabled a ton of cool things to be built much more quickly than they would have with the other tools available at the time.

At the same time, it's hard to see a viable niche for Perl going forward. The advantages I mentioned above are no longer unique to Perl - they're now table stakes for any mainstream language. Every mainstream language has a package archive now. There are at least 7 mainstream general-purpose languages with a garbage-collecting runtime, with quality ranging from decent to incredible. Every language except C evolved decent support for string manipulation. Perl deserves tremendous credit for leading the way in making these things mainstream, but it has left Perl with very few distinguishing advantages.

Without those advantages, Perl seems destined to gradually fade away. The sheer mass of existing code means it will probably never be gone - there will always be important systems still running on Perl. But very few greenfield projects will use it, and fewer programmers will learn it in the future.

We can quibble about why Perl has gradually faded from relevance. Personally, I think people generally overweight the importance of the Perl 6 announcement, and underweight the impact of Apache's mod_php in shifting usage away from Perl. mod_php enabled hosting providers to safely enable PHP on shared hosting, while mod_perl couldn't be used in that context, because users could affect the Perl environments of other users on the same system. As a result, PHP hosting was cheap and had tons of options, while Perl hosting required a more expensive option like VPS or a dedicated box. This kick-started the PHP ecosystem, and its growth came largely at the expense of the Perl web development ecosystem. One could imagine an alternative world in which PHP never took off, and Facebook, Wikipedia, Wordpress, etc. were all started in Perl, but that's not the world we live in.

Why would a DBMS API need to be built into the runtime?

5. A rewrite in Flutter

DataStax had good results testing the new Shenandoah garbage collector with Cassandra 4.0: https://www.datastax.com/blog/apache-cassandra-benchmarking-...

The lowest trim lines of many cars still have exactly what you’re describing.

Ah didn’t realize that. Thanks for pointing it out.

Creative Commons licenses aren’t recommend for software[1], but you can use the Zero-Clause BSD License[2] to satisfy the same goals as CC0.

[1] https://creativecommons.org/faq/#can-i-apply-a-creative-comm...

[2] https://opensource.org/licenses/0BSD

I wonder what % of users:

1. Have an ultra wide monitor.

2. Regularly use their browser in full width mode on it.

Pretty much everyone I know with an ultra wide snaps their browser to the left or right side - having a single browser window that wide is not very useful, and makes lots of websites look weird.

If you’re the only user, you can avoid almost all the security issues by not exposing any HTTP ports to the internet, and instead accessing any web interfaces through SSH port forwarding. For example:

1. Run Gitea on your server, but make it only available on localhost.

2. Connect to your server via SSH, and use the -L flag to forward the port that Gitea is using e.g.

    ssh -L 8888:localhost:8888 me@myserver.com

3. Access Gitea by opening http://localhost:8888 (or whatever port you’re using) in your browser.

However, this doesn’t work if you’d like to collaborate with anyone who you don’t trust enough to give SSH access to your machine.

It would also be annoying or impossible to open the web interfaces on mobile devices.

No, it’s just switching from a pessimistic locking approach to an optimistic one: https://en.wikipedia.org/wiki/Optimistic_concurrency_control

Are you familiar with gRPC-web?

https://github.com/grpc/grpc-web

Here’s the relevant Wikipedia article, which has a decent explanation: https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_op...

Yeah, and I was (sincerely) curious why they’d be disappointed if that happened.

What advantages does NetBSD have that distinguish it from other BSDs and other existing OS options?

Naive tree traversal on a GPU actually has pretty bad performance, due to execution divergence. It takes a lot of application-specific reframing of the problem to making working with BVH trees efficient: https://developer.nvidia.com/blog/thinking-parallel-part-ii-...

Not sure what GPU algorithms you’re trying to implement, but linked lists (and generally anything with pointer-chasing) are almost maximally terrible on GPUs - they are really not designed for that.

> There's also benefits to middle-operations, such as text editing (although text files are so small that inefficient operations aren't a big deal anymore).

Applications operating on text would normally use a rope (aka cord) or gap buffer. A linked list would have horrible performance because random access within the text is important for most applications.

> (I'm building up GBs of data: so saving redundant chunks like this really wins)

You’re likely spending a huge amount of memory to store pointers between elements within the unshared chunks (8 or 16 extra bytes per element adds up in a hurry) so it may be worth investigating some “chunking” so that you only have to use pointers to link between chunks, which can be stored continuously.

Alternatively, consider whether the index representation used by suffix arrays will work for your use-case: https://en.wikipedia.org/wiki/Suffix_array

What environment are you working in where this is a problem in practice?

In tiny embedded devices with very limited memory, you do all your allocation at startup and avoid malloc during runtime, so you’d never run into this.

On server, desktop, or even smartphone applications, I’ve never run into cases where “the allocator was unable to get a chunk of memory to complete a vector resize()” is a significant problem. If my vector is going to be a significant fraction of the memory available on the system, I generally know that up-front, and would just call reserve() with a conservative estimate of the upper-found size. That’s pretty rare though - not many problems call for vectors that are 1+ GB in size. For anything that’s not a significant fraction of the system’s available memory, the allocator can generally find you a chunk.

Sorted linked lists are also especially-not-useful, because you can’t binary search them, which is often the main benefit to having something sorted.

The only thing a sorted linked list is really good for is being able to cheaply peek/pop the lowest- or highest-valued item, and a heap is almost always better for that use-case in practice.

An acquisition doesn’t really score as a win for the seed investors in most cases, although it’s often a win for the team.

This is called arena allocation, and there are many implementations of the concept.

For example, the C++ Protocol Buffers library has an Arena class, which is documented here: https://developers.google.com/protocol-buffers/docs/referenc...

The EA STL has fixed_allocator, which implements a similar concept while exposing more low-level details in the API: https://github.com/electronicarts/EASTL/blob/master/include/...

But then your objects are scattered all over the address space, which means that objects you’re accessing in sequence are unlikely to be in the same cache line, so you pay a cache miss on every single access.

Having (maybe?) more efficient malloc/free in exchange for dramatically increasing the cost of accessing your data is not a good trade-off for most access patterns.

See Chandler Carruth’s talk from CppCon 2014: https://youtu.be/fHNmRkzxHWs?t=2085

YC and other seed investors are betting more on people than on the specific business plan. If a founding team seems really smart, skilled, and driven, but is working on an idea that doesn’t seem to make immediate business sense, then it can still be worth betting on that team, because one of two things is reasonably likely to happen:

1. The team realizes that the business plan isn’t viable, and they pivot to something else, which might be.

2. The team was actually perceiving an opportunity you didn’t understand, and the idea ends up being a big success.

This doesn’t have to work out all the time, or even most of the time - if you fund even one team that ends up pivoting into a runaway success, it pays for all the “bad” (in hindsight) bets that didn’t pay off.

Maybe one of SF’s tech companies can invent a technology that would allow housing to be stacked vertically.

> I don’t want a terminal in my browser because that would be ridiculous.

Secure Shell[1] is actually my go-to terminal for daily use, and supports some features that are important to me (e.g. OSC 52 codes) that GNOME Terminal doesn’t.

[1] https://chrome.google.com/webstore/detail/secure-shell/iodih...

This is pretty cool. The title would be a bit more descriptive if it were “Fast Rolling Quantile Filters for Python”, since the high-pass/low-pass filter functionality seems to be the focus.

The README mentions it uses binary heaps - if you’re willing to accept some (bounded) approximation, then it should be possible to reduce memory usage and somewhat reduce runtime by using a sketching data structure like Dunning’s t-digest: https://github.com/tdunning/t-digest/blob/main/docs/t-digest....

There is an open source Python implementation, although I haven’t used it and can’t vouch for its quality: https://github.com/CamDavidsonPilon/tdigest

There are multiple implementations, but the contents of the .git directory are essentially the API, which tightly constrains how it can be implemented.