"What works for Google (or the DOD, or IBM) doesn't work for most other companies, projects, or programmers, because they operate under a completely different set of constraints." - that is VERY true.
I agree that C++ is too complex. The problem is, alternatives are even worse for other reasons. Ruby is HORRIBLE from maintainability and performance points of view. To write maintainable Ruby, one has to use TDD, which is deeply incompatible with how many people think. (See the debates between David Heinemeyer Hanson and Kent beck: http://martinfowler.com/articl...) And I have used Ruby a-lot, so I am not guessing. And Go is really awful because it throws out enormously useful features like virtual methods and exception handling, and Go also has lots of "gotchas" - my favorite is comparing a reference with nil and getting false, then type asserting it, comparing the asserted value with nil, and then getting true. Things like that will result in lots of bugs, and there are many gotchas like that. So I have turned back to C++ because, if used well (i.e., conservatively), one can write very efficient and maintainable programs - IF used well. Efficiency matters at Internet scale because if a Ruby program requires 10,000 VMs but a C++ program requires only 100, that is a very large cost saving.
"not designed for large messages...": Hmmm - isn't there a way to attach a file - i.e., a MIME "part"? Since PB uses HTTP2, it would be hard for me to imagine that they left that out. But if you are right, I agree it would be a terrible problem. Perhaps attaching files is part of gRPC but not PB?
Not sure I understand your comment about non-copy memory transfers, since PB/gRPC are remote (out-of-process) communication tools.
Yes, you are right, that message passing (e.g., UDP) is more scalable when one has a single server. But if you can massively scale the servers, the limitations of RPC-like communication go away.
Another thought: I don't want to dismiss what you said above about Internet scale: it is actually quite insightful: "The 'Internet scale' we are talking about here is millions of different clients and servers..." It is true that for for query applications, the REST model is logically a good one. However, the REST protocol (i.e., HTTP with character data) is horribly inefficient. If one compresses it, that helps a-lot, but that is really a workaround. gRPC uses (by default) Protocol Buffers, which is reportedly ten times more efficient/responsive in terms of bandwidth and latency. Also, for applications in which the user performs updates to data, an RPC model makes more sense. Once can use gRPC with a REST-like paradigm: it all depends how one defines one's responses. It is kind of moot though because programmers use toolkits like React and Angular, and a component-oriented approach has become popular today (we are back to a popularity contest) - driven largely by the frameworks that embed a "react" pattern - i.e., the MVC is gone, and each component performs transactions against a back end microservice. For this pattern, gRPC and microservices in containers is a perfect combination - and Internet-scalable.
Stodgy? Some of the languages that I have used extensively over the years (more or less chronologically): Basic, Fortran, Algol, PL/I, Pacal, Ada, C, Module2, C++, VHDL (I helped to develop this language, and wrote compilers for it), Java, Ruby, Go. Other languages that I have used here and there: Lisp, Prolog, Python, AspectJ, Scala, Groovy. Which are the most productive for an organization (not an individual) over the long term? Without a doubt, Java. Reason: It is by far the most maintainable and refactorable as teams turn over. Second choice: C++. Some of the worst for maintainability: all the dynamic languages, and Go. I think that Google knows what it is doing, and the fact that it defies many of today's trendy tools tells me that just maybe those tools are popular because they are popular - not because they are good. As Alan Kay has said, "Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture..."
It seems to me that REST tries to solve a problem that does not exist. Programmers want RPC. The notion of REST is too abstract for most programmers. Also, Google's internal systems are Internet-scale - they are the ones providing that scale! Of late, Google has turn away from several current cherished paradigms, including REST and dynamic languages, returning to older concepts that have stood the test of time.
Yes, and before SunRPC, I remember that Apollo Computer had an RPC toolkit. Actually, CORBA did work - quite well. I used it a-lot back then. XML based messaging came along - way before Internet scale was a concern - because it went over HTTP, thus "tunneling" through firewalls. CORBA required you to open ports, and sysadmins would not do that. From there, the nightmare of WSDL emerged, and then REST replaced WSDL, and programmers signed with relief because it was so much simpler. By that time, the OMG had updated CORBA so that it could to through firewalls, but it was too late: since IT is fad-driven, CORBA was "out of style". Then "internet scale" started to become an issue. And Google has found that REST cannot meet the needs of Internet scale, so they have developed gRPC, which is just like CORBA, and is (like CORBA) much, much faster and uses much, much less bandwidth than REST. Google's clearly stated reason for developing gRPC is that REST is too slow and uses too much bandwidth.
"The first "web browser" was actually a WYSIWYG editor"
Which one was that? Are you referring to Mosaic? If so, I did not know that it had editing capability.
As I recall, REST came along as a response to SOAP, which was overly complex for what people were using it for. The most common feature of SOAP was SOAP-RPC, so it was natural for people to want to use REST for that.
I 100% agree that HTTP is being misused - and REST as ell. What we need is a protocol other than HTTP for remote procedure calls. Unfortunately, everyone assumes that every new application over the Web must use HTTP. Do you recall IIOP (CORBA)? Sysadmins would not let it through their firewalls, so people turned to HTTP in order to be able to do remote procedure calls over the Internet.
People need and want RPC for a myriad of applications. REST and HTTP are terrible for that. IIOP exists, but no one uses it. Now we have gRPC which pushes RPC over HTTP (without REST), but it is still using HTTP. This sidesteps the issue but it might be the best we can hope for.
Well I must misunderstand REST then! Although every single REST project I have been on has treated REST as an API syntax. But is this splitting hairs? I know that the concept is that one transfers state from one place to another. But in practice the paradigm is driven by the UI framework (e.g., Angular, etc.), and given the component-oriented react oriented patterns of today, one is not transferring state: one is making API calls. That is what apps need, and they are using REST because of AJAX, and it has produced a mess. JSON is a maintainability nightmare, for example, with people specifying data structure syntax by showing examples, instead of using something complete and normative like BNF (or JSON schema now that there finally is such a thing).
Yes, that has been the argument. But it has proven to be a red herring. Systems are semantically coupled if they interoperate. The syntax of that coupling can either help to maintain consistency, or not. REST does not help: it is entirely up to the programmer to check everything and make sure though tons of testing that everything still works. In contract, a compiler based approach helps enormously. Real real way to decouple systems is to _logically_ decouple them, so that, e.g., backward compatibility is intentionally retained, and API methods are designed to be general purpose instead of special purpose - and those issues are independent of the syntax.
Swagger is nice but it is a workaround for what is really a mess: REST. HTTP was not intended to be used an an application level API, nor were XML or JSON. These are all bastard approaches. Compare these with the elegance of remote procedure call approaches such as CORBA and gRPC, where one specifies a method interface just like in a normal computer language, and the marshalling and unmarshalling code is generated by a compiler. The compiler is then the subject of rigorous validation based on the language spec, which leads to a much more robust toolset - a far better situation than someone's hack (i.e., tools like swagger). Also, an API specified in gRPC or CORBA's IDL that is one page will generally be 50 pages if specified as REST - even using Swagger - and the REST spec will have more ambiguity and complexity.
Yeah, I guess each online community is going to migrate toward a standard that is preferred by that community. One thing I won't do though is "pile on" or add to the nastiness.
Interesting. Yes, I am in the US and US folks ("Americans") are pretty sensitive I think. I have noticed that I often get offended when chatting with a fellow who I know who lives in the Netherlands - I have been told that they are more like your culture. Oriental cultures are even more sensitive than US culture. Good point.
Of course, it also depends on the situation. When I was in grad school, my friends and I would greet each other such as "Joe you XXXhole", etc., and we would all laugh. But we knew each other well, so it was different;-)
It seems that you hear "you're an idiot" differently than I do. If someone says to me, "You're an idiot", I hear a nasty insult. I pretty much stop listing to the content at that point, and conclude that the other person is nasty and that I can't have an intelligent discussion with them. It sounds like when you say, "You're an idiot", you don't mean it that way. But given that many people are like me and will hear it as an insult, why say that? And it adds nothing: it is too non-specific to address anything useful in the discussion. It is far more useful to just say what you disagree with, which guarantees that no one will hear it as an attack. That is not being politically correct: it does not prevent you from disagreeing with any of the points being discussed. Remember that in an online forum, you don't know the other people personally, and you don't know how they will react, so it just makes common sense to be polite - not to be PC, but to merely be polite.
I loved that movie too. To the point, being considerate does not equate to being conformist. In fact, being considerate and civil fosters diversity of ideas.
Yes. Exactly. I think that if those who don't like rude behavior speak up and call it out, things actually get better. The people who are rude should not get away with it - if they get away with it, they don't change; but if they sense that others won't tolerate it, they will restrain themselves. And you are right that a-lot of it has to do with not being face-to-face - people can more easily be dehumanized ("he's an idiot so I don't need to treat him like a human").
Yes, true. They can be as nasty - they are just more civilized about it. But being civilized is still important - without that, one can't even have a discussion that allows fringe points of view, and without fringe points of view, nothing ever changes.
You are right, that it can't be completely enforced - someone who gets banned can always create a new account. But if the community expects better, it gets better. Most people don't want to get banned, and most people don't want to be seen as rude. Are you familiar with the "broken windows theory"? It tells us that if things are in a state of chaos, they become even more chaotic. By setting a higher standard, we get better behavior.
I think that you have not experienced more intellectual and civilized forums. There are many on the Internet. When you are in a forum where most people have PhDs or are very accomplished, they don't behave this way. Not all parts of the Internet are the same.
It is not about changing human nature - you are right, we can't do that. But it is possible to establish norms of behavior. The right norms of behavior _can_ make things more functional and more fair. Norms of behavior do not have to emphasize political correctness - they can instead emphasize civility. Civility promotes intelligent discourse, where all ideas are given a chance, even if an idea is not popular. Sometimes unpopular ideas are the best ones - the game changers; but rudeness can silence those who have unpopular ideas.
Don't you think that making it personal derails a discussion? Why not say something like, "I think that your response seems very irrational, because it ignores all of these obvious things..." - instead of calling the _person_ an idiot. If you call someone an idiot, you most likely start a personal back and forth of attacks that no one else wants to read, and it clutters and destroys the discussion. IMO it would be much better if people simply ignored posts that appear to be irrational. It is also possible that someone posts something that seems idiotic, but is _not_ an idiot - perhaps they don't understand something. Calling them an idiot is then callous and again, disrupts the discussion.
The fact that something has problems does not mean that we should either accept those problems or stay away. Change begins with realizing that there is a problem.
I can relate to his experience - not in wikipedia, but other forums, including slashdot and LinkedIn. I have found that most people are nice, but there are certain people who become nasty very quickly. Those individuals can easily destroy a discussion. IMO we need to expect civility in online forums - otherwise, why have a forum? People should not make personal attacks - comments should be issue focused. I see a-lot of posts on slashdot that get personal, like "you are an idiot", etc. That is not appropriate - it is childish. IMO, a comment that embeds a personal attack should result in the commenter being banned for awhile at least.
Today the IT world is such a mess because of "coding" - aka "hacking". It used to be that systems were designed well. I am not talking about big design up front - I am talking about prototyping and refinement, but with a design centric focus. Today's programmers jump right to code, and that is why systems are so insecure, and the IOT is not even possible as a result - because it will be all hackable. So teach kids to "code"? No way. Instead, teach them about systems thinking. Teach them about artificial intelligence. Teach them about electronics. Teach them about mathematics. The focus on coding is misguided.
Slashdot Mirror
"What works for Google (or the DOD, or IBM) doesn't work for most other companies, projects, or programmers, because they operate under a completely different set of constraints." - that is VERY true.
I agree that C++ is too complex. The problem is, alternatives are even worse for other reasons. Ruby is HORRIBLE from maintainability and performance points of view. To write maintainable Ruby, one has to use TDD, which is deeply incompatible with how many people think. (See the debates between David Heinemeyer Hanson and Kent beck: http://martinfowler.com/articl...) And I have used Ruby a-lot, so I am not guessing. And Go is really awful because it throws out enormously useful features like virtual methods and exception handling, and Go also has lots of "gotchas" - my favorite is comparing a reference with nil and getting false, then type asserting it, comparing the asserted value with nil, and then getting true. Things like that will result in lots of bugs, and there are many gotchas like that. So I have turned back to C++ because, if used well (i.e., conservatively), one can write very efficient and maintainable programs - IF used well. Efficiency matters at Internet scale because if a Ruby program requires 10,000 VMs but a C++ program requires only 100, that is a very large cost saving.
"not designed for large messages...": Hmmm - isn't there a way to attach a file - i.e., a MIME "part"? Since PB uses HTTP2, it would be hard for me to imagine that they left that out. But if you are right, I agree it would be a terrible problem. Perhaps attaching files is part of gRPC but not PB?
Not sure I understand your comment about non-copy memory transfers, since PB/gRPC are remote (out-of-process) communication tools.
Yes, you are right, that message passing (e.g., UDP) is more scalable when one has a single server. But if you can massively scale the servers, the limitations of RPC-like communication go away.
Another thought: I don't want to dismiss what you said above about Internet scale: it is actually quite insightful: "The 'Internet scale' we are talking about here is millions of different clients and servers..." It is true that for for query applications, the REST model is logically a good one. However, the REST protocol (i.e., HTTP with character data) is horribly inefficient. If one compresses it, that helps a-lot, but that is really a workaround. gRPC uses (by default) Protocol Buffers, which is reportedly ten times more efficient/responsive in terms of bandwidth and latency. Also, for applications in which the user performs updates to data, an RPC model makes more sense. Once can use gRPC with a REST-like paradigm: it all depends how one defines one's responses. It is kind of moot though because programmers use toolkits like React and Angular, and a component-oriented approach has become popular today (we are back to a popularity contest) - driven largely by the frameworks that embed a "react" pattern - i.e., the MVC is gone, and each component performs transactions against a back end microservice. For this pattern, gRPC and microservices in containers is a perfect combination - and Internet-scalable.
Stodgy? Some of the languages that I have used extensively over the years (more or less chronologically): Basic, Fortran, Algol, PL/I, Pacal, Ada, C, Module2, C++, VHDL (I helped to develop this language, and wrote compilers for it), Java, Ruby, Go. Other languages that I have used here and there: Lisp, Prolog, Python, AspectJ, Scala, Groovy. Which are the most productive for an organization (not an individual) over the long term? Without a doubt, Java. Reason: It is by far the most maintainable and refactorable as teams turn over. Second choice: C++. Some of the worst for maintainability: all the dynamic languages, and Go. I think that Google knows what it is doing, and the fact that it defies many of today's trendy tools tells me that just maybe those tools are popular because they are popular - not because they are good. As Alan Kay has said, "Computing spread out much, much faster than educating unsophisticated people can happen. In the last 25 years or so, we actually got something like a pop culture..."
It seems to me that REST tries to solve a problem that does not exist. Programmers want RPC. The notion of REST is too abstract for most programmers. Also, Google's internal systems are Internet-scale - they are the ones providing that scale! Of late, Google has turn away from several current cherished paradigms, including REST and dynamic languages, returning to older concepts that have stood the test of time.
Yes, and before SunRPC, I remember that Apollo Computer had an RPC toolkit. Actually, CORBA did work - quite well. I used it a-lot back then. XML based messaging came along - way before Internet scale was a concern - because it went over HTTP, thus "tunneling" through firewalls. CORBA required you to open ports, and sysadmins would not do that. From there, the nightmare of WSDL emerged, and then REST replaced WSDL, and programmers signed with relief because it was so much simpler. By that time, the OMG had updated CORBA so that it could to through firewalls, but it was too late: since IT is fad-driven, CORBA was "out of style". Then "internet scale" started to become an issue. And Google has found that REST cannot meet the needs of Internet scale, so they have developed gRPC, which is just like CORBA, and is (like CORBA) much, much faster and uses much, much less bandwidth than REST. Google's clearly stated reason for developing gRPC is that REST is too slow and uses too much bandwidth.
"The first "web browser" was actually a WYSIWYG editor" Which one was that? Are you referring to Mosaic? If so, I did not know that it had editing capability. As I recall, REST came along as a response to SOAP, which was overly complex for what people were using it for. The most common feature of SOAP was SOAP-RPC, so it was natural for people to want to use REST for that. I 100% agree that HTTP is being misused - and REST as ell. What we need is a protocol other than HTTP for remote procedure calls. Unfortunately, everyone assumes that every new application over the Web must use HTTP. Do you recall IIOP (CORBA)? Sysadmins would not let it through their firewalls, so people turned to HTTP in order to be able to do remote procedure calls over the Internet. People need and want RPC for a myriad of applications. REST and HTTP are terrible for that. IIOP exists, but no one uses it. Now we have gRPC which pushes RPC over HTTP (without REST), but it is still using HTTP. This sidesteps the issue but it might be the best we can hope for.
Well I must misunderstand REST then! Although every single REST project I have been on has treated REST as an API syntax. But is this splitting hairs? I know that the concept is that one transfers state from one place to another. But in practice the paradigm is driven by the UI framework (e.g., Angular, etc.), and given the component-oriented react oriented patterns of today, one is not transferring state: one is making API calls. That is what apps need, and they are using REST because of AJAX, and it has produced a mess. JSON is a maintainability nightmare, for example, with people specifying data structure syntax by showing examples, instead of using something complete and normative like BNF (or JSON schema now that there finally is such a thing).
Yes, that has been the argument. But it has proven to be a red herring. Systems are semantically coupled if they interoperate. The syntax of that coupling can either help to maintain consistency, or not. REST does not help: it is entirely up to the programmer to check everything and make sure though tons of testing that everything still works. In contract, a compiler based approach helps enormously. Real real way to decouple systems is to _logically_ decouple them, so that, e.g., backward compatibility is intentionally retained, and API methods are designed to be general purpose instead of special purpose - and those issues are independent of the syntax.
Swagger is nice but it is a workaround for what is really a mess: REST. HTTP was not intended to be used an an application level API, nor were XML or JSON. These are all bastard approaches. Compare these with the elegance of remote procedure call approaches such as CORBA and gRPC, where one specifies a method interface just like in a normal computer language, and the marshalling and unmarshalling code is generated by a compiler. The compiler is then the subject of rigorous validation based on the language spec, which leads to a much more robust toolset - a far better situation than someone's hack (i.e., tools like swagger). Also, an API specified in gRPC or CORBA's IDL that is one page will generally be 50 pages if specified as REST - even using Swagger - and the REST spec will have more ambiguity and complexity.
Yeah, I guess each online community is going to migrate toward a standard that is preferred by that community. One thing I won't do though is "pile on" or add to the nastiness.
Interesting. Yes, I am in the US and US folks ("Americans") are pretty sensitive I think. I have noticed that I often get offended when chatting with a fellow who I know who lives in the Netherlands - I have been told that they are more like your culture. Oriental cultures are even more sensitive than US culture. Good point. Of course, it also depends on the situation. When I was in grad school, my friends and I would greet each other such as "Joe you XXXhole", etc., and we would all laugh. But we knew each other well, so it was different ;-)
It seems that you hear "you're an idiot" differently than I do. If someone says to me, "You're an idiot", I hear a nasty insult. I pretty much stop listing to the content at that point, and conclude that the other person is nasty and that I can't have an intelligent discussion with them. It sounds like when you say, "You're an idiot", you don't mean it that way. But given that many people are like me and will hear it as an insult, why say that? And it adds nothing: it is too non-specific to address anything useful in the discussion. It is far more useful to just say what you disagree with, which guarantees that no one will hear it as an attack. That is not being politically correct: it does not prevent you from disagreeing with any of the points being discussed. Remember that in an online forum, you don't know the other people personally, and you don't know how they will react, so it just makes common sense to be polite - not to be PC, but to merely be polite.
You are right, that civility is not a sufficient condition for fair discourse: it is only a necessary condition.
I loved that movie too. To the point, being considerate does not equate to being conformist. In fact, being considerate and civil fosters diversity of ideas.
Yes. Exactly. I think that if those who don't like rude behavior speak up and call it out, things actually get better. The people who are rude should not get away with it - if they get away with it, they don't change; but if they sense that others won't tolerate it, they will restrain themselves. And you are right that a-lot of it has to do with not being face-to-face - people can more easily be dehumanized ("he's an idiot so I don't need to treat him like a human").
Yes, true. They can be as nasty - they are just more civilized about it. But being civilized is still important - without that, one can't even have a discussion that allows fringe points of view, and without fringe points of view, nothing ever changes.
You are right, that it can't be completely enforced - someone who gets banned can always create a new account. But if the community expects better, it gets better. Most people don't want to get banned, and most people don't want to be seen as rude. Are you familiar with the "broken windows theory"? It tells us that if things are in a state of chaos, they become even more chaotic. By setting a higher standard, we get better behavior.
I think that you have not experienced more intellectual and civilized forums. There are many on the Internet. When you are in a forum where most people have PhDs or are very accomplished, they don't behave this way. Not all parts of the Internet are the same.
It is not about changing human nature - you are right, we can't do that. But it is possible to establish norms of behavior. The right norms of behavior _can_ make things more functional and more fair. Norms of behavior do not have to emphasize political correctness - they can instead emphasize civility. Civility promotes intelligent discourse, where all ideas are given a chance, even if an idea is not popular. Sometimes unpopular ideas are the best ones - the game changers; but rudeness can silence those who have unpopular ideas.
If one were in a tribe in neolithic times, one could use that argument to persuade everyone that there should be no improvements to existing norms.
Don't you think that making it personal derails a discussion? Why not say something like, "I think that your response seems very irrational, because it ignores all of these obvious things..." - instead of calling the _person_ an idiot. If you call someone an idiot, you most likely start a personal back and forth of attacks that no one else wants to read, and it clutters and destroys the discussion. IMO it would be much better if people simply ignored posts that appear to be irrational. It is also possible that someone posts something that seems idiotic, but is _not_ an idiot - perhaps they don't understand something. Calling them an idiot is then callous and again, disrupts the discussion.
The fact that something has problems does not mean that we should either accept those problems or stay away. Change begins with realizing that there is a problem.
I can relate to his experience - not in wikipedia, but other forums, including slashdot and LinkedIn. I have found that most people are nice, but there are certain people who become nasty very quickly. Those individuals can easily destroy a discussion. IMO we need to expect civility in online forums - otherwise, why have a forum? People should not make personal attacks - comments should be issue focused. I see a-lot of posts on slashdot that get personal, like "you are an idiot", etc. That is not appropriate - it is childish. IMO, a comment that embeds a personal attack should result in the commenter being banned for awhile at least.
Today the IT world is such a mess because of "coding" - aka "hacking". It used to be that systems were designed well. I am not talking about big design up front - I am talking about prototyping and refinement, but with a design centric focus. Today's programmers jump right to code, and that is why systems are so insecure, and the IOT is not even possible as a result - because it will be all hackable. So teach kids to "code"? No way. Instead, teach them about systems thinking. Teach them about artificial intelligence. Teach them about electronics. Teach them about mathematics. The focus on coding is misguided.