The claims may be bold, but I wouldn't say they are lies.
Suppose you had a problem to solve. Approach A is to describe a solution to it in plain English that any layman can understand. Approach B is to describe a solution in pure machine-language code at the CPU instruction level.
At the end of the exercise, the CPU instructions probably occupy less bytes. But that does not mean that the machine-language solution was a more productive path. The productivity gain here has to do with the fact that it's very difficult for humans to think in pure machine code -- that's one major reason why we have programming languages in the first place.
Sure it's an intellectual accomplishment to conceive of the pure machine-code solution. It probably requires more skill than the layman version. It could execute orders of magnitude faster. But at the end of the day, is it more "productive?" No, not if the difficulty and specialized expertise to create it put that solution out of consideration.
I think we have to ask ourselves why programming is becoming more and more of an "ivory tower" profession. When computers were first introduced, everyone focused on learning BASIC in order to create software. Now we have people steering apps like Excel (at best), very few "programmers." Programming has all but disappeared from K-12 curriculums, and struggling in higher education. There have been many articles about this.
I think it's a good thing to have a language closer to English, that can appeal to a broader range of people.
The claim is "10x more productive" and the fact one isn't forced to struggle constructing and debugging a regex expression (which Rev actually supports as well) is part of the productivity boost. I find your one-liner examples to be time-consuming to compose, difficult to read, and undesireable to debug.
I guess what you're missing is that a lot of people consider things like
r.readLine match { case null => s; case word => makeSet(r, s + word) }
to be impenetrable gobbledygook. The fact they have no interest in learning that kind of syntax is in no way connected to their ability to break large problems down into component parts, think logically, or come up with effective algorithms.
Interestingly, revTalk does also use "return" to return a value from a function, as shown at the end of the sortWord handler. But we have different meanings for words in English, too. I think it's nifty that he compiler knows how to evaluate these terms "in context."
FYI, one can use "cr" or "crlf" or "numtochar(13)" as synonyms for "return" in the context of strings, but I like "return." The idea of synonyms in code probably makes it that much messier and aggravating for some!:)
I'd like to see the 50 lines of BASIC code. (Which would be about twice as long.)
At least you agreed that with zero previous knowledge of the language, you could "already see what the code is trying to do." I think that would be true for even non-programmers, and is a testament to the self-documenting strength of revTalk.
The main idea here is that revTalk appeals to people who are not keen on traditional programming languages. It can therefore enable them to accomplish things they wouldn't normally consider trying, either because of the expense or time involved.
Aren't you making the point? Your examples of one-liners are not something I would consider "human-readable." It probably took a lot more effort to construct them, too.
Why should a decent programming language require such byzantine constructions in order to be considered "real?"
1) It enables people who are not full-time programmers to undertake projects they normally wouldn't consider doing otherwise. It's possibly true that someone who knows a more traditional language could write something that executes faster or more efficiently, but if you reduce a five-hour process down to 10 minutes, you're still getting a significant boost in productivity, even if "real" programmer could write code that did the process in 3 minutes.
2) It is definitely more readable, and often shorter. As an example, there was a "readbility challenge" for coding a while back. The task was to write a routine that would determine all possible two-word anagrams given a starting word and a word list. See http://selfexplanatorycode.blogspot.com/
I can't post the code of the winning entry; Slashdot reports "Filter error: Please use fewer 'junk' characters. But you can find it here: http://www.reddit.com/r/sdcc1/comments/6wru4/leonardo/
-------- And here is the code in revTalk:
constant alphabet = "abcdefghijklmnopqrstuvwxyz" on mouseUp put "documenting" into sourceWord put url "http://someserver.com/wordlist.txt" into wordList repeat for each character c in alphabet if c is not in sourceWord then filter wordList without ("*" & c & "*") end repeat put sortWord(sourceWord) into sourceWord repeat for each line firstWord in wordList repeat for each line secondWord in wordList put firstWord & secondWord into testWord if the length of testWord is the length of sourceWord then if sortWord(testWord) is sourceWord then put firstWord && secondWord & return after anagramList end if end if end repeat end repeat put anagramList end mouseUp
function sortWord theWord repeat for each character c in theWord put c & return after theSortedWord end repeat sort theSortedWord replace return with empty in theSortedWord return theSortedWord end sortWord
It is shorter and (in my opinion) much more readable.
Obviously a lot of posts here about various email providers and strategies. You have some interesting requirements for your email which raise questions for me:
- What's wrong with user@gmail.com? A ton of people I know list Google as their personal email address. As a brand, it beats yahoo, hotmail, and aol for professionalism. There are other services, but do you want to risk things on a fly-by-night? Just pick GMail and stick with it:)
- Why not add IMAP to your company's email facility? Is it that the company is too big and you couldn't possibly influence this decision? Or too small, and you can't figure out how to do it?
- Do you really want to conduct work-related business on an outside server? Look at the trouble Gov. Palin's getting for that.
Having said all that then your main option is to just get a domain and pick a cheap plan from a decent-sized hosting business.
The correct response to that question is, "why WOULD you design it without MySQL or some other database engines?" Of course, it's very effective if your company is all about doing funky implementations just for the hell of it, but most organizations are concerned about time-to-market and the ability for someone else to come in and pick up where you left off. Anyway, after all this posturing about programming skills and philosophy, no one has come forward with concrete reasons WHY this feature was allegedly a continuing pain for the NetFlix development team. My position remains that it should not have been so. Frankly my experience has been that software engineers report "difficulty" with a feature in inverse proportion to what they happen to find interesting at the moment, regardless of the actual technical challenge present in the task.
I AM a database programmer. There's thousands of examples of systems that have subaccounts and profiles; it's fairly trivial to process and present them, provided you don't make really glaring mistakes up-front. Even when those mistakes have been made, it's usually a straightforward process to script a migration to a proper schema. Databases are designed to be flexible that way, that's why we store data in them.
And it can't be that broken because the feature works in every way it can be perceived to work. My family member's profile receives the proper recommendations. They get the correct DVDs in the right order. And so on.
I almost buy the idea that someone at NetFlix thought a "simpler" web page might be better for users. I can imagine someone saying that only a small fraction of customers actually use the feature. But pain? From the folks who have put together an incredibly sophisticated database system already? From people who have implemented a recommendations system that is, so far, safe from the 10% improvement challenge? Hard to imagine Profiles were just tacked on in an amateur way.
So, cough it up. What was the "pain" associated with this feature? Real-world IT people are dying to know.
Slashdot Mirror
The claims may be bold, but I wouldn't say they are lies.
Suppose you had a problem to solve. Approach A is to describe a solution to it in plain English that any layman can understand. Approach B is to describe a solution in pure machine-language code at the CPU instruction level.
At the end of the exercise, the CPU instructions probably occupy less bytes. But that does not mean that the machine-language solution was a more productive path. The productivity gain here has to do with the fact that it's very difficult for humans to think in pure machine code -- that's one major reason why we have programming languages in the first place.
Sure it's an intellectual accomplishment to conceive of the pure machine-code solution. It probably requires more skill than the layman version. It could execute orders of magnitude faster. But at the end of the day, is it more "productive?" No, not if the difficulty and specialized expertise to create it put that solution out of consideration.
I think we have to ask ourselves why programming is becoming more and more of an "ivory tower" profession. When computers were first introduced, everyone focused on learning BASIC in order to create software. Now we have people steering apps like Excel (at best), very few "programmers." Programming has all but disappeared from K-12 curriculums, and struggling in higher education. There have been many articles about this.
I think it's a good thing to have a language closer to English, that can appeal to a broader range of people.
Rev includes an XML library, standard.
The claim is "10x more productive" and the fact one isn't forced to struggle constructing and debugging a regex expression (which Rev actually supports as well) is part of the productivity boost. I find your one-liner examples to be time-consuming to compose, difficult to read, and undesireable to debug.
I guess what you're missing is that a lot of people consider things like
r.readLine match { case null => s; case word => makeSet(r, s + word) }
to be impenetrable gobbledygook. The fact they have no interest in learning that kind of syntax is in no way connected to their ability to break large problems down into component parts, think logically, or come up with effective algorithms.
The company is based in Scotland. In British English, "per cent" is the preferred spelling.
http://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style_(spelling)
Interestingly, revTalk does also use "return" to return a value from a function, as shown at the end of the sortWord handler. But we have different meanings for words in English, too. I think it's nifty that he compiler knows how to evaluate these terms "in context."
FYI, one can use "cr" or "crlf" or "numtochar(13)" as synonyms for "return" in the context of strings, but I like "return." The idea of synonyms in code probably makes it that much messier and aggravating for some! :)
I'd like to see the 50 lines of BASIC code. (Which would be about twice as long.)
At least you agreed that with zero previous knowledge of the language, you could "already see what the code is trying to do." I think that would be true for even non-programmers, and is a testament to the self-documenting strength of revTalk.
The main idea here is that revTalk appeals to people who are not keen on traditional programming languages. It can therefore enable them to accomplish things they wouldn't normally consider trying, either because of the expense or time involved.
Aren't you making the point? Your examples of one-liners are not something I would consider "human-readable." It probably took a lot more effort to construct them, too. Why should a decent programming language require such byzantine constructions in order to be considered "real?"
I think there are two key advantages to revTalk.
1) It enables people who are not full-time programmers to undertake projects they normally wouldn't consider doing otherwise. It's possibly true that someone who knows a more traditional language could write something that executes faster or more efficiently, but if you reduce a five-hour process down to 10 minutes, you're still getting a significant boost in productivity, even if "real" programmer could write code that did the process in 3 minutes.
2) It is definitely more readable, and often shorter. As an example, there was a "readbility challenge" for coding a while back. The task was to write a routine that would determine all possible two-word anagrams given a starting word and a word list. See http://selfexplanatorycode.blogspot.com/
I can't post the code of the winning entry; Slashdot reports "Filter error: Please use fewer 'junk' characters. But you can find it here: http://www.reddit.com/r/sdcc1/comments/6wru4/leonardo/
--------
And here is the code in revTalk:
constant alphabet = "abcdefghijklmnopqrstuvwxyz"
on mouseUp
put "documenting" into sourceWord
put url "http://someserver.com/wordlist.txt" into wordList
repeat for each character c in alphabet
if c is not in sourceWord then filter wordList without ("*" & c & "*")
end repeat
put sortWord(sourceWord) into sourceWord
repeat for each line firstWord in wordList
repeat for each line secondWord in wordList
put firstWord & secondWord into testWord
if the length of testWord is the length of sourceWord then
if sortWord(testWord) is sourceWord then
put firstWord && secondWord & return after anagramList
end if
end if
end repeat
end repeat
put anagramList
end mouseUp
function sortWord theWord
repeat for each character c in theWord
put c & return after theSortedWord
end repeat
sort theSortedWord
replace return with empty in theSortedWord
return theSortedWord
end sortWord
It is shorter and (in my opinion) much more readable.
Western Union, I found out recently, requires IE7 to send a wire online. Firefox is not supported, no joke.
Obviously a lot of posts here about various email providers and strategies. You have some interesting requirements for your email which raise questions for me: - What's wrong with user@gmail.com? A ton of people I know list Google as their personal email address. As a brand, it beats yahoo, hotmail, and aol for professionalism. There are other services, but do you want to risk things on a fly-by-night? Just pick GMail and stick with it :)
- Why not add IMAP to your company's email facility? Is it that the company is too big and you couldn't possibly influence this decision? Or too small, and you can't figure out how to do it?
- Do you really want to conduct work-related business on an outside server? Look at the trouble Gov. Palin's getting for that.
Having said all that then your main option is to just get a domain and pick a cheap plan from a decent-sized hosting business.
The correct response to that question is, "why WOULD you design it without MySQL or some other database engines?" Of course, it's very effective if your company is all about doing funky implementations just for the hell of it, but most organizations are concerned about time-to-market and the ability for someone else to come in and pick up where you left off. Anyway, after all this posturing about programming skills and philosophy, no one has come forward with concrete reasons WHY this feature was allegedly a continuing pain for the NetFlix development team. My position remains that it should not have been so. Frankly my experience has been that software engineers report "difficulty" with a feature in inverse proportion to what they happen to find interesting at the moment, regardless of the actual technical challenge present in the task.
I AM a database programmer. There's thousands of examples of systems that have subaccounts and profiles; it's fairly trivial to process and present them, provided you don't make really glaring mistakes up-front. Even when those mistakes have been made, it's usually a straightforward process to script a migration to a proper schema. Databases are designed to be flexible that way, that's why we store data in them. And it can't be that broken because the feature works in every way it can be perceived to work. My family member's profile receives the proper recommendations. They get the correct DVDs in the right order. And so on. I almost buy the idea that someone at NetFlix thought a "simpler" web page might be better for users. I can imagine someone saying that only a small fraction of customers actually use the feature. But pain? From the folks who have put together an incredibly sophisticated database system already? From people who have implemented a recommendations system that is, so far, safe from the 10% improvement challenge? Hard to imagine Profiles were just tacked on in an amateur way. So, cough it up. What was the "pain" associated with this feature? Real-world IT people are dying to know.
I'd like to understand why Profiles should cause any pain. It's all a database, right? How hard could it be?