Perhaps the viability rate of the offspring of cross-breeds is low. "Viability" is not necessarily a Boolean value. As two groups drift apart genetically, the success rate of mating gradually goes down. I'm not sure the definition requires 0.00000...% viability. But, most biologists don't get pedantic of over such and accept fuzzy boundaries of many concepts (until somebody sues over paternity or something).
Who is to say some of the Neanderthal genes that have been found in humans are not "helpful"? How are they measuring "helpful adaptation"? Perhaps they mean the high-altitude features are clearly helpful, while the benefits of others are not known yet. (Maybe some of the top football players are the top because of Neanderthal genes.)
There are trade-off's to different comparing techniques. My preference would be a symbol for explicitness in intent. Example:
$a #> $b;// # for numeric compares (greater than) $a @> $b;// @ for date compares
If the variables couldn't be interpreted as the indicated type, then an error would be triggered. (Perhaps fancier compare functions could allow more contingency handling for such.)
So future language designers out there, THAT'S the way you do dynamic compares.
As far as Python's versioning techniques, PHP could adopt that practice also for new versions, but probably chose not to for a reason. Per module versioning could get confusing. I'm still hesitant to call that a "flaw" in PHP, but rather a personal preference instead.
You would think the modern age of cameras in everyone's phones would produce evidence-a-plenty
One "UFO enthusiast" answered such this way: The craft know if and who is using a camera in the area through advanced scanning. Like any other bureaucracy, they are pressured to do as much as possible with as few resources as possible. Occasionally they'll let low resolution photography slip through rather than chase the photographer down. They know to stay at the "edge" of detectability. Being too careful slows down their work, and not being careful enough allows high-quality images to slip through. They try to find a middle ground.
Plus, in the age of Photoshop, it's relatively easy to flood the Internet with look-alikes that discredit the original. Our improved image capture abilities has come with advanced fudging capabilities. It was harder to fake analog photography.
1. Re "comparing...loose types": that's the nature of dynamic languages. What's an example of a (default) dynamic language doing comparing right? Explicit comparing operators seem just about the only way (I've proposed symbols in my pet drafts), other than explicit conversion of the operands, which is redundant.
3. Re: "inconsistent naming": Any sufficiently large library that has grown incrementally is going to have naming and parameter convention oddities. Choices appropriate to a small name-space may not be appropriate to a large one. The only way to get that right is to design the big library up front, which is not something many languages get a shot at. What's an example of an existing language with decently named library parts?
5: Re: "server operator changes": That's a flexibility trade-off. I'm not sure I'd classify that as summarily "bad". Arguments could be made for either.
6: "Versions change semantics": That's another trade-off in improving the language versus backward compatibility. I'm not sure I'd classify that as summarily "bad".
I consider those "kinds" of programming, not "programming" versus "not programming". I think I understand what point you are trying to make, but I'm not sure English has the right words to say it well and concisely.
1A: But they don't work for JS as it runs in other browsers. We can't control what browser a user is using. True, that's more of an implementation issue than a language issue. But such still damages JS's reputation, risking legacy status earlier, which the author was concerned with.
2A: "Just remember goofy rules" is not a good enough justification in my opinion. JS doesn't need those things: chop the fuckers out. (Paraphrased)
3A and 6B: What's wrong with using an ordered tree for everything? It can even represent tables (although not practical for large tables, but that's not the job of an app language). I don't need heavy-ass app speed for most of what I do: dump the volume processing onto the database if you have to chomp on large collections. Note I agree that many other languages do collections worse than JS. I guess we can agree that JS is at least average there.
6A: Trim is one of the most common string functions I need.
Oh, and JS lacks optional named parameters, something I really miss. Once you get used to them, they are hard to give up.
1B: Objects, with method defining or overriding, is good enough for the same thing, better understood among programmer population, and often more flexible in my opinion. Heavy use of HOF's usually indicates bad coding or bad API design in my opinion.
4B: Explicit number types are not very common in dynamic languages anyhow. That's more of an issue of comparing dynamic langs to static ones.
7B: Certain bad coding idioms seem to be fads for a while, and then people realize they over-did it and go back to judicious use.
Thanks for your feedback. Even though I may not agree on everything, I enjoy counter views.
Most developers only use JavaScript because it's their only realistic option on the client side for web-based applications. It's kind of like the QWERTY standard: you have to use it because avoiding it is made difficult by entrenchment.
I don't know if better tools (IDE's, interpreters, lint-er's, etc.) could make it more tolerable, but most of us have had a crappy experience with JavaScript in browsers, and this has damaged its reputation such that unless something comes along that repairs its reputation on a wide scale, server-side JavaScript is a tough sell. You can't just make it good, you have to show the world it's good and that their shitty browser experience was the browser's fault and not JavaScript.
The browser only seems to give one of two unhelpful errors: "object not found" or "is not an object'.
As far as the language, I don't like its non-WYSIWYG typing model. It has too many nulls, nils, NaN's, Nuns, or whatnot that drive one crazy. I prefer a typing model where every value is or is treated like a string and is readily displayable. No damned hidden types/modes. (Some say Null is needed for RDBMS compatibility, but I've almost never needed such, and the API can use the string "[null]" or the like if null detection is really needed by an app.)
And it has too many "kinds" of data structures; these may be delimited or enclosed with square brackets, curly braces, parenthesis, and whatnot. Too many similar kinds of collections. Just make everything a dynamic ordered tree rather than have similar but not quite the same species of structures. Lisp at least got that part right.
And don't overload "+" to mean both addition and concatenation. Slap the bastard who put that "cute" feature in.
Oh, and literals starting with "0" are interpreted as octal. Cute Marie, real cute. That feature almost got me fired from a contract once because the customer didn't believe such a design flaw could exist in a common language, thinking it was my fault. There's probably only 7 JavaScript programmers who use lots of octal literals; why the hell did you ignore the other 99.999%? Were you targeting cephalopod coders?
And JS lacks typical string- and date-handling functions. Lots of octal-friendly shit and no fucking strings; must be cephalopods.
If someone was able to predict the future that well, they'd be buying out Warren Buffett instead of answering questions on slashdot.
Perl does seem to be on a downward popularity spiral. Whether it merits that or not would turn into a heated debate, so I'm only stating that from the perspective of having enough usage momentum to provide sufficient shop staffing options and support in the future.
PHP would be my rough best guess, if you want a dynamic language in the same general family as Perl. PHP is a bit clunky, but has huge current usage and has not shown any signs of slowing down. IF it started dying tomorrow due to some newfangled language or gizmo, it would take decades to fully kill.
Python and Ruby have failed to fully catch on mainstream, and the "white space" issue still haunts their growth. It just agitates enough developers to keep them down. (I'm not putting a value judgement on the white-space thing here, only looking at perceptions.) Plus, their communities seem to overdue "clever abstraction" coding, at least in terms of what the market prefers. They suffer part of what Lisp does, in terms of market perceptions and reactions to high coding abstraction. The market likes mid-brow languages, not high-brow.
C# is still too tied to Microsoft's fortune, despite having OSS clones. If MS sinks, it may take the clones with it out of industry support/momentum fear (not necessarily language merit).
And Java is currently haunted by Oracle's Big Lawyer ways.
Slashdot Mirror
That's redundant because one has to apply the same function/method to both sides. I still prefer the symbols.
http://2.bp.blogspot.com/_VG-L...
Perhaps the viability rate of the offspring of cross-breeds is low. "Viability" is not necessarily a Boolean value. As two groups drift apart genetically, the success rate of mating gradually goes down. I'm not sure the definition requires 0.00000...% viability. But, most biologists don't get pedantic of over such and accept fuzzy boundaries of many concepts (until somebody sues over paternity or something).
Who is to say some of the Neanderthal genes that have been found in humans are not "helpful"? How are they measuring "helpful adaptation"? Perhaps they mean the high-altitude features are clearly helpful, while the benefits of others are not known yet. (Maybe some of the top football players are the top because of Neanderthal genes.)
If they bred with humans, technically they didn't go extinct: their genes live on, at least some of them. "Extinct" is perhaps not a Boolean value.
There are trade-off's to different comparing techniques. My preference would be a symbol for explicitness in intent. Example:
If the variables couldn't be interpreted as the indicated type, then an error would be triggered. (Perhaps fancier compare functions could allow more contingency handling for such.)
So future language designers out there, THAT'S the way you do dynamic compares.
As far as Python's versioning techniques, PHP could adopt that practice also for new versions, but probably chose not to for a reason. Per module versioning could get confusing. I'm still hesitant to call that a "flaw" in PHP, but rather a personal preference instead.
One "UFO enthusiast" answered such this way: The craft know if and who is using a camera in the area through advanced scanning. Like any other bureaucracy, they are pressured to do as much as possible with as few resources as possible. Occasionally they'll let low resolution photography slip through rather than chase the photographer down. They know to stay at the "edge" of detectability. Being too careful slows down their work, and not being careful enough allows high-quality images to slip through. They try to find a middle ground.
Plus, in the age of Photoshop, it's relatively easy to flood the Internet with look-alikes that discredit the original. Our improved image capture abilities has come with advanced fudging capabilities. It was harder to fake analog photography.
Horses, dogs, and bears; oh my!
1. Re "comparing...loose types": that's the nature of dynamic languages. What's an example of a (default) dynamic language doing comparing right? Explicit comparing operators seem just about the only way (I've proposed symbols in my pet drafts), other than explicit conversion of the operands, which is redundant.
3. Re: "inconsistent naming": Any sufficiently large library that has grown incrementally is going to have naming and parameter convention oddities. Choices appropriate to a small name-space may not be appropriate to a large one. The only way to get that right is to design the big library up front, which is not something many languages get a shot at. What's an example of an existing language with decently named library parts?
5: Re: "server operator changes": That's a flexibility trade-off. I'm not sure I'd classify that as summarily "bad". Arguments could be made for either.
6: "Versions change semantics": That's another trade-off in improving the language versus backward compatibility. I'm not sure I'd classify that as summarily "bad".
I consider those "kinds" of programming, not "programming" versus "not programming". I think I understand what point you are trying to make, but I'm not sure English has the right words to say it well and concisely.
Vimacs; compromise, people.
What is it called then? Markupping?
I suspect the first fully mutating and evolving virus will be written in Perl. Resistance is futile.
(A=top list, B=bottom list)
1A: But they don't work for JS as it runs in other browsers. We can't control what browser a user is using. True, that's more of an implementation issue than a language issue. But such still damages JS's reputation, risking legacy status earlier, which the author was concerned with.
2A: "Just remember goofy rules" is not a good enough justification in my opinion. JS doesn't need those things: chop the fuckers out. (Paraphrased)
3A and 6B: What's wrong with using an ordered tree for everything? It can even represent tables (although not practical for large tables, but that's not the job of an app language). I don't need heavy-ass app speed for most of what I do: dump the volume processing onto the database if you have to chomp on large collections. Note I agree that many other languages do collections worse than JS. I guess we can agree that JS is at least average there.
6A: Trim is one of the most common string functions I need.
Oh, and JS lacks optional named parameters, something I really miss. Once you get used to them, they are hard to give up.
1B: Objects, with method defining or overriding, is good enough for the same thing, better understood among programmer population, and often more flexible in my opinion. Heavy use of HOF's usually indicates bad coding or bad API design in my opinion.
4B: Explicit number types are not very common in dynamic languages anyhow. That's more of an issue of comparing dynamic langs to static ones.
7B: Certain bad coding idioms seem to be fads for a while, and then people realize they over-did it and go back to judicious use.
Thanks for your feedback. Even though I may not agree on everything, I enjoy counter views.
Most developers only use JavaScript because it's their only realistic option on the client side for web-based applications. It's kind of like the QWERTY standard: you have to use it because avoiding it is made difficult by entrenchment.
I don't know if better tools (IDE's, interpreters, lint-er's, etc.) could make it more tolerable, but most of us have had a crappy experience with JavaScript in browsers, and this has damaged its reputation such that unless something comes along that repairs its reputation on a wide scale, server-side JavaScript is a tough sell. You can't just make it good, you have to show the world it's good and that their shitty browser experience was the browser's fault and not JavaScript.
The browser only seems to give one of two unhelpful errors: "object not found" or "is not an object'.
As far as the language, I don't like its non-WYSIWYG typing model. It has too many nulls, nils, NaN's, Nuns, or whatnot that drive one crazy. I prefer a typing model where every value is or is treated like a string and is readily displayable. No damned hidden types/modes. (Some say Null is needed for RDBMS compatibility, but I've almost never needed such, and the API can use the string "[null]" or the like if null detection is really needed by an app.)
And it has too many "kinds" of data structures; these may be delimited or enclosed with square brackets, curly braces, parenthesis, and whatnot. Too many similar kinds of collections. Just make everything a dynamic ordered tree rather than have similar but not quite the same species of structures. Lisp at least got that part right.
And don't overload "+" to mean both addition and concatenation. Slap the bastard who put that "cute" feature in.
Oh, and literals starting with "0" are interpreted as octal. Cute Marie, real cute. That feature almost got me fired from a contract once because the customer didn't believe such a design flaw could exist in a common language, thinking it was my fault. There's probably only 7 JavaScript programmers who use lots of octal literals; why the hell did you ignore the other 99.999%? Were you targeting cephalopod coders?
And JS lacks typical string- and date-handling functions. Lots of octal-friendly shit and no fucking strings; must be cephalopods.
Yeah, who the hell needs more than that?
If someone was able to predict the future that well, they'd be buying out Warren Buffett instead of answering questions on slashdot.
Perl does seem to be on a downward popularity spiral. Whether it merits that or not would turn into a heated debate, so I'm only stating that from the perspective of having enough usage momentum to provide sufficient shop staffing options and support in the future.
PHP would be my rough best guess, if you want a dynamic language in the same general family as Perl. PHP is a bit clunky, but has huge current usage and has not shown any signs of slowing down. IF it started dying tomorrow due to some newfangled language or gizmo, it would take decades to fully kill.
Python and Ruby have failed to fully catch on mainstream, and the "white space" issue still haunts their growth. It just agitates enough developers to keep them down. (I'm not putting a value judgement on the white-space thing here, only looking at perceptions.) Plus, their communities seem to overdue "clever abstraction" coding, at least in terms of what the market prefers. They suffer part of what Lisp does, in terms of market perceptions and reactions to high coding abstraction. The market likes mid-brow languages, not high-brow.
C# is still too tied to Microsoft's fortune, despite having OSS clones. If MS sinks, it may take the clones with it out of industry support/momentum fear (not necessarily language merit).
And Java is currently haunted by Oracle's Big Lawyer ways.
We'll, after I got a hold of their disks, they did become flying saucers.
They just don't make Horta like they used to
Somebody stole it and made it into jillions of AOL disks
And here's to you Mrs. Robinson...
Better get non-geeks to test it. Otherwise they'll turn grey trying to figure out why it's always zero.
Now we have cat whisker problems instead of tin whiskers.
That's how Godzilla was born, I hope you know.