Creator of Cirru here. Cirru is confusing since it's a syntax of data, not a standalone language. Calcit(<https://calcit-lang.org/>) is the language I built. However Calcit does not store source code in files called `blabla.calcit` or something. Instead, Calcit stores code in data, which is called "Cirru EDN" since it's a variant of Clojure EDN. And it uses Cirru as a data format so stored in files called `compact.cirru` or `calcit.cirru`, which might confuse you PLDB data.
I think the back button is fine, it's the keyboard shortcut for Go Back, `alt-left`, that's broken. The `scrollKeyboardNav` element's "press left/right to go to the prev/next language" keydown handler is triggering even when alt is being held is preempting the Go Back shortcut.
Workaround is to swipe back furiously, presumably before the page is able to add additional locations to browser history.
Without actually pulling this code or doing any debugging, I believe the issue is this line here, at some point during the initial page load you are setting `location.hash` (watching the actual URL I can see that it happens) which adds a navigation event to your history and interferes with the back button.
It also doesn't happen in Chrome in Android. I do not know why one browser would trigger that code path while another would not, perhaps they all trigger the code but most of them discard JS induced navigation events that fire during a page load.
You could probably go ahead and start using `location.replace` with a minor refactor. The difference in behavior there would be when someone updates their query, a new entry is not added to history. Whether that's a regression or an improvement is probably user dependent. IMO, it's better not to have a bunch of history items for playing with one table.
I was viewing this page in the Harmonic app and had to quit since the Android back button was unable to exit the webview.
Allowing developers to mess with the back button was a mistake, I've never used a website where that functionality didn't present a problem rather than solving one.
Looking at the code, the issue is most likely a modification of window.location or its child properties. Any modification of these things will cause the browser to navigate to the new page, adding a new browser history entry.
Then, whenever a user tries to go back, it will rerun the code that causes the browser to nagivate to the new page, so you end up on the same page you started on. It feels like the back button was hijacked.
To fix this, usually the two ways to change the URL without changing the browser history are either using window.location.replace() which will navigate there as well, or using window.history.replaceState() which will only change the URL without naviating there.
They are cramped in a tiny table where you can barely see them.
The PDF button did work for me, but only the second time: the first time, for some reason, the blob:// scheme was transformed into blob.com, a scammy SEO parking website.
Add to that the hijacking of the back button, and boy what a terrible experience...
Obviously this is the opposite of what I'm trying to create.
I actually design the site for it to work 100% offline. You can download it to your computer. Some pages, such as this advanced explorer, are designed really with desktop in mind, and mobile is an afterthought. I gave my smart phone up 2 years ago, and that made my life a lot better, and I won't be going back. However, I do test on a low powered burner phone, and try to make sure the site works, but this explorer page is more advanced, and is literally doing clientside search and transforms on the entire database with no server calls. So it's just something better used on a computer.
Unfortunately time and resources are limited (the site has no business model yet, but perhaps if the WWS catches on we'll have funds to bring on more people...or maybe someone has a great idea for grants we could win or other business models?) .
If anyone wants to volunteer time to make this run better on mobile phones, I'd love to help unblock you! Source code is:
Why does this site list CUDA as a programming language? I also don't see why we need to include versioning tools or APIs and many other things. I suppose this evolved beyond the PLDB naming. The interface is nice and simple though.
> Why does this site list CUDA as a programming language?
Our original taxonomy was pretty weak due to tooling. Much better now (switched away from "type" to "tags"), but still work to be cleaning up the old categorizations.
It is my understanding that CUDA extends the c/c++ langs though, right? It's not simply a library? My own knowledge of CUDA is a little weak (so pull requests welcome!)
> I suppose this evolved beyond the PLDB naming.
Yup! It turned out to be quite hard to tell the story of programming languages without including other concepts from the ecosytem. But the focus is on languages. The schema and language underneath (ScrollSets) evolved so it's simple for us to extend beyond the core and include things 1 degree of separation out. This Explorer is new and the first step toward making it easier for people to include/exclude the set of things they are interested in.
Cuda is a programming language. It's a dialect of C++ which leaks compiler implementation quirks into the application layer. A best effort approximation to the Nvidia one is available in clang by passing -x cu or naming a file something.cu.
For me it's a labor of love and I was doing it anyway to try and make my own languages good.
But yes, a lot of work still ahead.
If anyone wants to give us grants/donations, we can make a dollar go far, and there are some people that have been helping for years who I would love to be able to support to work on the site adding data.
I'm also all ears to any business model ideas (of course nothing that would involve paywalls or non-public domain).
That being said, LLMs have changed the game and made a lot of things tremendously easier, so we should see a lot of useful data added this year regardless (all human reviewed, of course!).
Creator of Cirru here. Cirru is confusing since it's a syntax of data, not a standalone language. Calcit(<https://calcit-lang.org/>) is the language I built. However Calcit does not store source code in files called `blabla.calcit` or something. Instead, Calcit stores code in data, which is called "Cirru EDN" since it's a variant of Clojure EDN. And it uses Cirru as a data format so stored in files called `compact.cirru` or `calcit.cirru`, which might confuse you PLDB data.
Okay updated! Thank you for that extra info. Calcit looks awesome!
I did a screencast of the fix: https://www.youtube.com/watch?v=LAPvG5M1-vQ&feature=youtu.be
If there are any other mistakes or data to add, pull requests are very much appreciated :).
The way this website was made makes the back button useless.
Sorry!
This page is new. The source is below:
https://github.com/breck7/pldb/blob/main/code/browser/explor...
Can you explain what you are doing and what you expect? I can get a fix out.
I think the back button is fine, it's the keyboard shortcut for Go Back, `alt-left`, that's broken. The `scrollKeyboardNav` element's "press left/right to go to the prev/next language" keydown handler is triggering even when alt is being held is preempting the Go Back shortcut.
Ah, got it! Yeah the keyboard nav should not be on that page. Just removed it (should be live in a minute or two).
Thank you!
https://github.com/breck7/pldb/commit/111b2c061df080d042297f...
You break mobile apps that use a webview, as my history trail never ends
Can you please provide repro steps? Whatever is happening I am happy to fix.
Also, the source code is 100% open source and pull requests are encouraged: https://github.com/breck7/pldb
For me, repro steps are:
1. Vist the page on Firefox Nightly for Android
2. Attempt to use the back gesture to go back
3. Observe you cannot go back
Workaround is to swipe back furiously, presumably before the page is able to add additional locations to browser history.
Without actually pulling this code or doing any debugging, I believe the issue is this line here, at some point during the initial page load you are setting `location.hash` (watching the actual URL I can see that it happens) which adds a navigation event to your history and interferes with the back button.
https://github.com/breck7/pldb/blob/ae07a2e4dfcc15bf8c16c4ca...
Awesome repro steps. Appreciate the effort.
Any idea why this only happens in Android on Firefox? I can't repro in Firefox on MacOS, or Chrome, or Safari.
Might it be a bug in Android on Firefox?
It also doesn't happen in Chrome in Android. I do not know why one browser would trigger that code path while another would not, perhaps they all trigger the code but most of them discard JS induced navigation events that fire during a page load.
Ok. At some point I need to clean up that code and add some unit tests. I'm sure at that point will get this fixed.
This is v0.1.0 of the Explorer.
Really appreciate the help!
You could probably go ahead and start using `location.replace` with a minor refactor. The difference in behavior there would be when someone updates their query, a new entry is not added to history. Whether that's a regression or an improvement is probably user dependent. IMO, it's better not to have a bunch of history items for playing with one table.
You are probably right. My todo list is a mile long though so won't get to this for a while. Open to pull requests.
If it was only this one.
You can long-press it.
Yes, but it messes with the convenience of swiping back on your trackpad or phone.
I was viewing this page in the Harmonic app and had to quit since the Android back button was unable to exit the webview.
Allowing developers to mess with the back button was a mistake, I've never used a website where that functionality didn't present a problem rather than solving one.
This site hijacks the back button and I really hate that.
Shouldn't there be some way for the browser to prevent that?
Can you explain what you mean? It's definitely not intentional, and should be easy to fix.
The source code is 100% open source and pull requests are encouraged: https://github.com/breck7/pldb
Looking at the code, the issue is most likely a modification of window.location or its child properties. Any modification of these things will cause the browser to navigate to the new page, adding a new browser history entry. Then, whenever a user tries to go back, it will rerun the code that causes the browser to nagivate to the new page, so you end up on the same page you started on. It feels like the back button was hijacked.
To fix this, usually the two ways to change the URL without changing the browser history are either using window.location.replace() which will navigate there as well, or using window.history.replaceState() which will only change the URL without naviating there.
Can't see any results in Firefox for Android
They are cramped in a tiny table where you can barely see them.
The PDF button did work for me, but only the second time: the first time, for some reason, the blob:// scheme was transformed into blob.com, a scammy SEO parking website.
Add to that the hijacking of the back button, and boy what a terrible experience...
> and boy what a terrible experience...
Obviously this is the opposite of what I'm trying to create.
I actually design the site for it to work 100% offline. You can download it to your computer. Some pages, such as this advanced explorer, are designed really with desktop in mind, and mobile is an afterthought. I gave my smart phone up 2 years ago, and that made my life a lot better, and I won't be going back. However, I do test on a low powered burner phone, and try to make sure the site works, but this explorer page is more advanced, and is literally doing clientside search and transforms on the entire database with no server calls. So it's just something better used on a computer.
Unfortunately time and resources are limited (the site has no business model yet, but perhaps if the WWS catches on we'll have funds to bring on more people...or maybe someone has a great idea for grants we could win or other business models?) .
If anyone wants to volunteer time to make this run better on mobile phones, I'd love to help unblock you! Source code is:
https://github.com/breck7/pldb
Why does this site list CUDA as a programming language? I also don't see why we need to include versioning tools or APIs and many other things. I suppose this evolved beyond the PLDB naming. The interface is nice and simple though.
> Why does this site list CUDA as a programming language?
Our original taxonomy was pretty weak due to tooling. Much better now (switched away from "type" to "tags"), but still work to be cleaning up the old categorizations.
Here is the source code for our CUDA page: https://github.com/breck7/pldb/blob/main/concepts/cuda.scrol...
It is my understanding that CUDA extends the c/c++ langs though, right? It's not simply a library? My own knowledge of CUDA is a little weak (so pull requests welcome!)
> I suppose this evolved beyond the PLDB naming.
Yup! It turned out to be quite hard to tell the story of programming languages without including other concepts from the ecosytem. But the focus is on languages. The schema and language underneath (ScrollSets) evolved so it's simple for us to extend beyond the core and include things 1 degree of separation out. This Explorer is new and the first step toward making it easier for people to include/exclude the set of things they are interested in.
Cuda is a programming language. It's a dialect of C++ which leaks compiler implementation quirks into the application layer. A best effort approximation to the Nvidia one is available in clang by passing -x cu or naming a file something.cu.
If you set the minimum year to -5000 you'll find the abacus as the first entry (not in the "pl" category though).
The data on the page seems a bit... iffy. Apparently only 3 languages have "Ifs", and 7 languages have for loops.
> Apparently only 3 languages have "Ifs", and 7 languages have for loops.
The "coverage" for all 388 columns is listed on the CSV page.
For example, you can see the coverage for "forLoops" is 0%: https://pldb.io/csv.html#q=forLoops&order=2.asc
Resources and time is limited.
I would LOVE any grants/donations to prioritize coverage on any column that people are interested in.
Otherwise, data get added by volunteers.
ha, interesting, if you extend to 2023, you get to see https://observablehq.com/framework/ made by d3 guys.
Somehow not works for me… iOs mobile. Still - trending is RUST imo.
looks like a lot of work to fill in all the data.
For me it's a labor of love and I was doing it anyway to try and make my own languages good.
But yes, a lot of work still ahead.
If anyone wants to give us grants/donations, we can make a dollar go far, and there are some people that have been helping for years who I would love to be able to support to work on the site adding data.
I'm also all ears to any business model ideas (of course nothing that would involve paywalls or non-public domain).
That being said, LLMs have changed the game and made a lot of things tremendously easier, so we should see a lot of useful data added this year regardless (all human reviewed, of course!).
Thank you for creating this.
How are the rankings arrived at?
It's a team effort! Thanks to all of these people: https://pldb.io/pages/acknowledgements.html
> How are the rankings arrived at?
https://pldb.io/pages/the-rankings-algorithm.html
Txt version: https://pldb.io/pages/the-rankings-algorithm.txt
The interface of absolutely beautiful.
The good parts provided by: https://datatables.net/
The interface is a train wreck when seen on Firefox for Android. Almost unusable.
> Almost unusuable!
Almost?! Wow! I'll take that as a compliment. I just assumed it was completely unusable on an untested platform like that ;).
I do have deep affection for Mozilla, and do test on Firefox on MacOSx.
Again, very sorry for the experience, and if you'd like to get involved helping make it work great on Android for Firefox, source code is:
https://github.com/breck7/pldb
Or we'd gladly accept any grants to prioritize that kind of work!
I like getlang.
[dead]