Not sure if humor, but this is meant to make a distinction with a non-human readable compilation target, many of which aren't, even when using high level languages.
I love Wikipedia and think it's one of the greatest resources on the Internet, but there's absolutely a lot of bias in Wikipedia. Even within the same language, I think a lot of it has to do with how many people have or are contributing to a page, whether there's a recent event affecting it, how polarizing or political the subject, etc. But it's not hard to find examples of straight up opinions or very incomplete narratives.
I've also noticed huge differences between two different language versions of the same articles. (English/Spanish specifically). Sometimes they even feel independently written.
Of course, we should all do our part to improve these things when we spot them, if we're able.
This is fun. Is it not checking for previously submitted URLs though? I can seemingly re-submit the exact same URL and get a new link every time. I would expect this to fill the database unnecessarily but I have no idea how the backend works.
Am I missing something, or would these essentially be implemented via DNS records? It's not clear to me that keeping the links in a database would be necessary at all (unless the DNS records are what you mean by "database")
The top comment in the article mentions it, but chawan[1] is really quite neat. Many sites are still have their quirks (or may be broken), but I think it's the closest I've seen a text browser approximate a "real" browser. The support for CSS, JS, and images (depends on your terminal) is already quite impressive even if imperfect. To my knowledge it's an actual browser implementation rather than "cheating" by using an existing browser like browsh (which is still quite cool).
Yep, that's me. :) It's cool when blogs incorporate ActivityPub comments to them.
I liked chawan from the first time it was shown here on HN, https://news.ycombinator.com/item?id=44293260. It made me add support for CSS Grid API in my sites targeting text browsers.
Image support has been present in numerous terminal-mode browsers for many years if not decades, generally implemented through the framebuffer, though in some cases the browser will spawn an external image viewer (presuming a graphical environment, e.g., Xorg / Wayland).
I love CHICKEN Scheme! Nice to see it mentioned. Though I think it's worth pointing out it compiles to something pretty far from handwritten C, to my understanding. I think this is true of both performance and semantics; for example you can return a pointer to a stack allocated struct from a foreign lambda (this is because chicken's generated C code here doesn't really "return", I think. Not an expert).
Of course you can always drop to manually written C yourself and it's still a fantastic language to interop with C. And CHICKEN 6 (still pre-release) improves upon that! E.g structs and Unions can be returned/passed directly by/to foreign functions, and the new CRUNCH extension/subset is supposed to compile to something quite a bit closer to handwritten C; there are even people experimenting with it on embedded devices.
Chicken indeed interoperates with C quite easily and productively. You're right that the generated C code is mostly incomprehensible to humans, but compiles without difficulty.
The Chicken C API has functions/macros that return values and those that don't return. The former include the fabulous embedded API (crunch is an altogether different beast) which I've used in "mixed language" programming to good effect. In such cases Scheme is rather like the essential "glue" that enables the parts written in other languages to work as a whole.
Of course becoming proficient in Scheme programming takes time and effort. I believe it's true that some brains have an affinity for Lispy languages while others don't. Fortunately, there are many ways to write programs to accomplish a given task.
Seriously. I do think people should spend enough time with bash or posix sh to be comfortable with it, but I'd recommend everyone at least just try fish. It's a lovely interactive experience out of the box with colors, completions, a great prompt, etc. Plus, the scripting language is quite comfy. Like, somewhere between bash and Python (if you find Python comfy, I guess). At least to me it makes more intuitive sense, once I got over the fact that "it's not bash/zsh."
It's written in Rust, if you care about that sort of thing (I switched before that was a thing). And for simple one-liners, compatibility actually has improved at least a bit (like you can do && now, which wasn't a thing before).
Write your shell-specific helper scripts or personal scripts in fish, write your portable scripts in Python or Bash. Look, I love standards. Sometimes non-standard things make sense though. Sometimes they even make more sense in the right context.
Or maybe you'll hate it. That's fine. People won't know until they try though.
For something newer and even more different, check out nushell. I don't have much experience with it, but a lot of its ideas are enticing.
I think I mostly agree with the thesis here, but I actually liked the point in the title at face value, too. We need both, I think. I guess I'll be another annoying Lisp guy, but:
> At this point, the right question to ask would be, well can you write a static-typing library for Scheme that then automatically checks your code for type errors? And the current answer, for now and for the foreseeable future, is no. No mainstream language today allows you to write a library to extend its type system.
The author seems to provide a counter example themselves(?):
> Racket and Shen provide mechanisms for extending their type systems...
I wonder if this is as clear-cut as the author is making it out to be. Coalton, which is effectively a library (and language) for Common Lisp, seems like it basically does this. Maybe that's not exactly what the author is referring to, because it is essentially a new language on top of Lisp using its meta-programming facilities, as opposed to merely extending the type system. Still, it can be used as a library right alongside Lisp code, so I think it's in the same spirit of of the first question of writing a "static-typing library that automatically checks your code" in a dynamic language.
Standard scheme may or may not be able to do this, but most Scheme implementations have unhygienic macros like CL's too, so I'd assume something similar would be possible. The fact that that these tend to be extensions from implementation designers might align with the article's point though. Also somewhat to the author's point, Coalton does rely strongly on CL's underlying type system, for which there's no real equivalent in Scheme. It also relies on implementation-specific optimizations alongside that.
For what it's worth you can (and indeed people have) written object systems in Scheme, despite the language not having one, though they tend not to be performant, which is likely another point towards using/writing a different language. CL also tends to allow fairly deep extension of its object system through the Meta-object Protocol.
I guess my point is that in my (probably biased) opinion, Lisps, or other languages with very strong meta-programming facilities, are pretty close to the language longed for in "Perhaps one day we'll have such a language." They aren't a silver bullet, of course. CL has no easy way to write performant coroutines/continuations, for example, even given all its extensibility. Scheme has no real type system, etc. etc.
I don't think any of this invalidates the articles points, I'm just not sure I agree with the absolutes.
It's quite common in UK English (and maybe others, I don't know), to refer to "singular" or collective non-people entities (such as companies, I know Gmail itself isn't one) using the plural form of verbs.
This isn't in my natural speech, but I quite like it; it seems to kind of imply "the people behind [company]" rather than anthropomorphizing the company itself. ...generally though I think it's just colloquial convention and not that deep.
There's something funny about someone trying to be smart and pointing out a typo or some other minor irrelevant error only to be proven completely wrong.
Gmail is a product, but the comment wasn't saying "Gmail the product deserves to be shamed... ", more like "the Gmail team/devs/company deserves to be shamed...", which is why the plural still made sense to me (given the omission of an explicit "team"). The singular makes sense to me too.
In any case, I wasn't really interested in correcting or proving anyone right or wrong, just pointing out an interesting linguistic detail and where the grammar may have come from.
Can you "shame" a product, though? Obviously not. So you're shaming the people who built Gmail, the organization - hence the plural form is acceptable.
I think you're not wrong, but it's not necessarily a problem? I might argue that's actually part of the main point the article is making. The software is already written in C, well understood and optimized in that language, and quite stable, so they'd need very compelling reasons for a rewrite.
I think the "lingua franca" argument for C and the points at the end about what they'd need from Rust to switch do go beyond merely justifying a decision that's already been made, though.
reply