3 ms·
I'd say the onus is on Perl to be the best language for a niche, rather than on me to provide a list of niches with languages better than Perl. Besides that, l
by fusiongyro 13y ago
I'd say the onus is on Perl to be the best language for a niche, rather than on me to provide a list of niches with languages better than Perl.
Besides that, language appropriateness is necessarily subjective. I love Prolog and Haskell and use them all the time. My passion for them makes their thorns seem small and easily avoided, but the reality is that those thorns are sufficient to keep out a lot of curious people. I didn't really figure out how to write a Prolog program that handled command line arguments until a month ago. Prior to that, I would just run Prolog, consult my script and run my function. Simple enough barrier, but one that would have kept most of my friends away.
I think you took my "real X, Y, Z" list as a literal insult, which isn't what I meant. I don't know Perl. I was just referencing the presentation, not trying to sling arrows at Moose or whatever.
I do think that providing multiple options where most languages have one option built-in is unnecessary cognitive load. One doesn't "choose" an "object system" for Python--what benefit would one hope to gain? That the options are compatible is nice, but it's indisputably more work for everyone than just having one.
Having what are essentially language built-ins elsewhere available instead on CPAN is worth complaining about, because if you're going to do things differently from others, the difference should be motivated by something. That something in Perl is backwards compatibility and the desire to provide lots of options. The former is an explanation, not a rationale, and the latter implies, again, a cognitive cost. When you spend my attention and brain power, I had better get something in return. "Options" are only worth something if the alternatives are worth choosing between. In the case of OO, complete intercompatibility between them suggests the differences are minor; in that case, why have them?
- berntb 13y ago>>I do think that providing multiple options where most languages have one option built-in is unnecessary cognitive load. (I'll assume you're not a troll despite acknowledging that you talk about a subject you don't know.) You are seriously arguing against flexibility and configurability of your programming environment? I guess you don't like Lisp either? To answer your specific point, re OO system: Today the de-facto Perl OO system (Moose with relatives) is better than the alternatives among other scripting languages. Without language extensibility, that wouldn't have happened. Exactly where the optimum is for sizes of std libs can and should be discussed. IMHO, after a few work years, a week or two extra to learn an environment is worth it when you get things like Moose. YMMV, but since you acknowledge that you don't know the environment, well...
- fusiongyro 13y agoI'm arguing that flexibility has a cost, and unless you can show me a tangible benefit, it's unnecessary cost. That you can build an OO system comparable to what other languages have built-in is a compelling demonstration of the extent of the flexibility, but it isn't a compelling demonstration of the need for the flexibility. Surely you have better examples of the extensibility of the language than stealing well-understood ideas from other languages. The best time to bring those out would be when wooing new users. In other words, your Prolog-style unification engine, your LINQ, your dependent-typing system, etc. would be better demonstrations of the vitality and power of your language's flexibility and extensibility than things I get for free by typing "python" at my shell prompt.
- Mithaldu 13y ago> comparable Not comparable. Better. > your LINQ DBIx::Class. I don't want to go to the effort of going into massive detail here, but in short: It allows you to write SQL access code under which you can use ANY database (SQLite, MySQL, MSSQL, Postgres, what have you), without changing a single line of your code. It will not only deploy your schema onto the database server, but also optimize your queries, so that for anything of slight complexity, it will likely be faster than your hand-written queries.
- berntb 13y ago>>That you can build an OO system comparable to what other languages have built-in My explicit point was that it is better [edit: which was an answer to your question about value from flexibility, compared to the cognitive cost], don't do straw man attacks please. (Are you trolling?) Edit: Thanks for the downvote. :-) Edit 2: As answer to the next long, long comment with parts going all over: Of course complexity has costs. if you really just want a good reference on Moose to see exactly what it is, ask Mithaldu. He probably has better sources than me. This is what I give people (it is getting old): http://rjbs.manxome.org/talks/moose/Moose.pdf http://rjbs.manxome.org/talks/moose/Moose.pdf Edit 3: And to avoid being called a "troll" -- don't write shit like "In 2013 nearly every problem has a language more appropriate than Perl." while you acknowledge you don't know the subject...
- Mithaldu 13y agoThe onus on one making broad statements and presenting them as fact is on the one making them. Note, i'm not really asking you to prove your statement. Just that you refrain from making such statements when you don't already carry the proof and provide it along with the statement. Also, no, i did not take it as an insult, just as a false statement from someone with little knowledge of the subject matter. > I do think that providing multiple options where most languages have one option built-in is unnecessary cognitive load. One doesn't "choose" an "object system" for Python--what benefit would one hope to gain? That question is actually understandable and easily answered. Two benefits: 1. More expressive power for example. Perl has Roles that function in a way unmatched by most other languages (i say most because i don't know all languages, i honestly don't know one that has roles as good as perl). They make it possible to share methods among classes without needing to resort to base classes and diamond inheritance issues, while still retaining full introspection capabilities. Another system implements most of the sugar, but leaves out some really complicated features in order to make it much faster. Yet another provides the most speed by implementing the core in C. This makes it a bit harder to debug, and less portable, but if you need massive speed, there you go. 2. The ability to try out different things and work out in real life situations which features are needed and which ones are dead ends. This ability is amplified by the ability to simply extend your object system by writing more Perl. In comparison, Ruby has an ubiquitous one, but when they desire to change it, they cannot easily test the changes large-scale in real situations, and even if a change is undoubtably positive, they still have to convince Matz first, and then implement it in C. > indisputably more work for everyone than just having one. Actually that is disputable. In the past it was the case, yes. But nowadays they have converged on the same syntax and present themselves identically to consumers. That means porting between different systems is trivial, and people using a class don't even notice changes. And that is not just fluff. The perl community has been doing this actively, for example here: https://github.com/rjbs/Email-Sender/compare/52fcbbb9b6a1c4a0b54a031f9eb211c77c6ba8dc...0708a1582dfea1677741134d5ac9939032d04a06 https://github.com/rjbs/Email-Sender/compare/52fcbbb9b6a1c4a... I'm not going to comment on your last paragraph because you wrote it while having decided that what you wrote before is actual fact and it is thus very flawed. Please stop doing that and use more question marks.
- fusiongyro 13y ago