3 ms·

I do have a few, and I listed them just a bit earlier above, but, for example: email address validation xml parsing json parsing "other" parsing stripping

I do have a few, and I listed them just a bit earlier above, but, for example: email address validation xml parsing json parsing "other" parsing stripping html email format manipulation binary file manipulation (networking stuff, for example) essentially, any task that takes an input via memory and produces an output via memory, where the speed of doing so is not critical, but the solution correctness is critical. This wouldn't actually replace the need for libraries in other languages, but it would allow languages that are somewhat devoid of libraries to access a large body of methods of accomplishing common tasks that, while slow, may work well, and help give better languages a fighting chance.

beagle3 17y ago
It is my opinion that non of the "memory-to-memory" tasks is holding any better language back; if anything, it's accessing the real world and/or accessing other systems. The tasks you listed are usually available with a new language as part of its standard library, albeit not feature complete or with a standard interface. An implementation such as you suggested may provide a feature complete, standardised solution -- however, it will not be convenient due to "impedance mismatch" (differing object models / storage models / needed conversions back and from, etc). Validating an email address is all good, but without shelling out to /usr/bin/mail or tcp access, you can't actually send it -- and whatever you use for actually sending it probably has a validator already. Parsing, specifically (most of your examples) has relatively good language agnostic support in such things as the GOLD parser --- and yet, it always loses in convenience to a system that lets you embed implementation language constructs, such as yacc / lex / ometa / antlr / lemon and friends. Sorry for being a little non constructive, but I think that without a concrete, specific use case that clearly demonstrates an advantage, this project may be interesting philosophically, but useless in practice. When you work out an example compare: (cost of implementing said feature from scratch in a new language) to (cost of implementing interpreter + conversions from language + conversion of results back to language idioms + ... + in each language + 1/6 feature (amortized over 6 languages)). Take into account unicode and charset handling because you value correctness above all. I think you'll find it hard to justify. What are those languages somewhat devoid of libraries, and what is the large body of methods that can actually fit in this list of yours that you believe are holding language adoption back? I surely lack breadth of knowledge and imagination, but I can't come up with these lists.

beagle3 17y ago

It is my opinion that non of the "memory-to-memory" tasks is holding any better language back; if anything, it's accessing the real world and/or accessing other systems. The tasks you listed are usually available with a new language as part of its standard library, albeit not feature complete or with a standard interface. An implementation such as you suggested may provide a feature complete, standardised solution -- however, it will not be convenient due to "impedance mismatch" (differing object models / storage models / needed conversions back and from, etc). Validating an email address is all good, but without shelling out to /usr/bin/mail or tcp access, you can't actually send it -- and whatever you use for actually sending it probably has a validator already. Parsing, specifically (most of your examples) has relatively good language agnostic support in such things as the GOLD parser --- and yet, it always loses in convenience to a system that lets you embed implementation language constructs, such as yacc / lex / ometa / antlr / lemon and friends. Sorry for being a little non constructive, but I think that without a concrete, specific use case that clearly demonstrates an advantage, this project may be interesting philosophically, but useless in practice. When you work out an example compare: (cost of implementing said feature from scratch in a new language) to (cost of implementing interpreter + conversions from language + conversion of results back to language idioms + ... + in each language + 1/6 feature (amortized over 6 languages)). Take into account unicode and charset handling because you value correctness above all. I think you'll find it hard to justify. What are those languages somewhat devoid of libraries, and what is the large body of methods that can actually fit in this list of yours that you believe are holding language adoption back? I surely lack breadth of knowledge and imagination, but I can't come up with these lists.