Would he? There seems to be a tradition of illuminations of the Quran (see e.g. https://www.islamicity.org/77800/illumination-of-the-quran/, first result of an internet search). The style is quite different, since Islam forbids making representations of animated beings, but that didn't prevent the development of a rather exquisite craftmanship.
But there’s something beautiful in the way that a Taylor expansion or a trigonometric identity emerge from the function definition. Also, it teaches an interesting concept in lazy evaluation.
I mean, why not write straight up assembler? That would be even more efficient…
t-string are lazy, which is the point (escaping HTML, translating strings when you get preferred language headers, preparing SQL statements...).
Does Ruby strings already allow lazy processing ?
I'm not talking about wrapping them in a block and passing the block (all languages can do that with a lambdas) but a having literally that eventually resolves to something when you use it.
That's seems like the wrong pattern, maybe I'm missing something.
Ruby has lazy evaluation with a generic lazy enumeration facility, whether to produce string or any kind of object.
That is, I don't know what is the actual behavior of the default string interpolation in Ruby, but if profiling a codebase some string generation would gain lazy evaluation, there is a path to do so. But in the general case, does it really matter? Chances are good that a string construction is not a big bottleneck.
Does Python miss such a feature of generic lazy enumeration, or is it so painful to use that some syntactic sugar felt like a must have? Genuine question here, I don't have any strong opinion on this t-string feature.
- string construction is a hot path, you don't want them to always be lazy, especially since any access is slow in python.
- having it using a string syntax is just very clean and easy to read. It's explicit and can be supported by good editor highlighting.
- it's easy to grep, analyse for, substitute, etc.
- you get one single unified API instead of thousands of variations. Translations API, log API and escaping API can all look the same, arguments are in the same shapes.
I understand that string generation can be a hotpath, though I wouldn't take it as a general certain fact.
From what I understand here the benefit in term of performance is mainly due to partial application automatically handled by the interpreter. It's hard to me to jauge actual pro/con compared to Ruby which can also leverage on freezed string, lambda, miscellaneous lazy evaluation facilities for example. I'm not aware of anything close in PHP, to stay in the realm of popular interpreted languages. I didn't make any Lua for a long time, so no idea how it evolved on that matter.
They learned from this and now just have periodic arbitrary layoffs to depress salaries and keep the workers scared and in line in a deniable way instead of in an explicit way.
It does not work. You have to declare the real source of the merchandise. Or it has to go through "substantial transformation" so that is called "Made in France".
Country of origin is taxed and not country of shippment.
And nobody ever lied on those Chinese envelopes with the value declaration. ;)
Also, I can tell you that the country of origin field has one of the lowest entry qualities of all fields. People just don't bother, and customs don't have the capacity. Also, depending on your warehousing, there is a good chance you simply don't know. If something in your item bucket came from either China, Vietnam, Malaysia or the Philippines, what are you gonna write?
I've seen a few headlines in our local news here in Australia about how nobody knows what amount of Chinese ingredients will result in the final product being hit with Chinese tariffs, even though the products are assembled here.
Religious scriptures for sale feels really weird on HN either way.
reply