Re: Go versus Brand X
a...@pythoncraft.com (Aahz) writes: Comparing Go to another computer language -- do you recognize it? http://www.cowlark.com/2009-11-15-go/ If you skip to the conclusion, you'll be better off. The author has an interesting point. Go (the language) is not really ground-breaking. I don't understand why they're so busy creating their own walled garden... Their own browser, their own programming languages, their own file systems, etc. Weird. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
J Kenneth King wrote: a...@pythoncraft.com (Aahz) writes: Comparing Go to another computer language -- do you recognize it? http://www.cowlark.com/2009-11-15-go/ If you skip to the conclusion, you'll be better off. The author has an interesting point. Go (the language) is not really ground-breaking. I don't understand why they're so busy creating their own walled garden... Their own browser, their own programming languages, their own file systems, etc. because they can, no? Normal business logic doesn't apply to Google. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
Le Mon, 23 Nov 2009 15:30:16 -0600, Robert Kern a écrit : particularly constrained environments like editors that may not be extensible at all. I'm not really an expert on this, but I think most good editors /are/ extensible (through plugins, scripts or other things). You can get away with just that and have something people recognize as syntax highlighting, yes. But if it is possible to highlight local variables, globals, and types differently, that *is* useful. And you will even see some syntax highlighters doing more advanced things like that even for Python (though mostly with heuristics). I suppose it's a matter of taste. I don't expect syntax highlighting to do anything else than make the source code more readable and make some important things stick out (comments, keywords etc.). It's probably the same debate as text editor vs. full IDE. Users of text editors view programming as a literary practice where they manipulate text, while users of IDEs view programming as bringing technologies together through specialized tools. Interestingly, we don't know how easy to parse Go is. We just have to trust their word on that, but perhaps Python is easier to parse (while being less ugly). -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
Aahz wrote: In article 7ms7ctf3k2a7...@mid.individual.net, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: However, Go's designers seem to favour using the absolute minimum number of characters they can get away with. Although if they *really* wanted that, they would have dropped most of the semicolons and used indentation-based block structure instead of curly braces. I would have forgiven them several other sins if they'd done that. :-) That's essentially my issue with Go based on the code samples I've seen: no over-arching design sensibility at the syntax level. It looks like an aggolomeration of semi-random C-like syntax. There's nothing that shouts out, This is a Go program, unlike Python, C, and even Perl. I think there is an overall design sensibility, it's just not a human-facing one. They claim that they designed the syntax to be very easily parsed by very simple tools in order to make things like syntax highlighters very easy and robust. So indentation-based blocks are right out. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
Le Mon, 23 Nov 2009 02:36:33 -0600, Robert Kern a écrit : I think there is an overall design sensibility, it's just not a human-facing one. They claim that they designed the syntax to be very easily parsed by very simple tools in order to make things like syntax highlighters very easy and robust. So indentation-based blocks are right out. But computer languages should be designed to be readable by humans. It's not like you need to write a new parser once a year, but you have to read code everyday. Besides, if you want parsing to be easy, you don't need to make the syntax minimal, you just have to provide the parsing routines as part of the standard library and/or of an external API. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On Nov 23, 2:47 am, Antoine Pitrou solip...@pitrou.net wrote: Le Mon, 23 Nov 2009 02:36:33 -0600, Robert Kern a écrit : I think there is an overall design sensibility, it's just not a human-facing one. They claim that they designed the syntax to be very easily parsed by very simple tools in order to make things like syntax highlighters very easy and robust. So indentation-based blocks are right out. But computer languages should be designed to be readable by humans. It's not like you need to write a new parser once a year, but you have to read code everyday. Besides, if you want parsing to be easy, you don't need to make the syntax minimal, you just have to provide the parsing routines as part of the standard library and/or of an external API. You could argue that by keeping the computer-facing part of the language simple, you make it easier for tools to take care of the human-facing side. But when you leave it up to third-party tools (or diligent programmers) to format code, the language designers have a lot less control over the aesthetics of programs in the wild, and you start having style wars over braces, etc., and no two Go programs will look like they reflect the same sensibility. Human readability and computer readability obviously do not have to be completely orthogonal, as proven by Python. But to the extent that they are orthogonal, I think there's a natural inclination to make a systems programming language focus on the computer-facing issues, with the huge caveat that leaving human-side issues to higher levels on the stack (linters, code formatters, etc.) complicates the overall ecosystem. Since Go is designed for building large programs, any failure of the Go community to prescribe a common aesthetic will probably get magnified to a large degree. Finally, a lot of aesthetics transcend syntax, so you can argue that the most important thing to do to enable programmers to create beautiful programs is to make them be more productive, and a fast compiler is pretty crucial for that, since a lot of human programmers work better in a flow state. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On 2009-11-23 04:47 AM, Antoine Pitrou wrote: Le Mon, 23 Nov 2009 02:36:33 -0600, Robert Kern a écrit : I think there is an overall design sensibility, it's just not a human-facing one. They claim that they designed the syntax to be very easily parsed by very simple tools in order to make things like syntax highlighters very easy and robust. So indentation-based blocks are right out. But computer languages should be designed to be readable by humans. It's not like you need to write a new parser once a year, but you have to read code everyday. You will get no argument from me. My point was only that they had an overall design sensibility, not that it was a good one. Besides, if you want parsing to be easy, you don't need to make the syntax minimal, you just have to provide the parsing routines as part of the standard library and/or of an external API. Not really. The idea was to make the language easily parsed and lexed and analyzed by *other* tools, not written in Go, that may have limited capabilities. Vim isn't written in Go and won't be able to use their API, for example. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
Robert Kern wrote: On 2009-11-23 04:47 AM, Antoine Pitrou wrote: Le Mon, 23 Nov 2009 02:36:33 -0600, Robert Kern a écrit : I think there is an overall design sensibility, it's just not a human-facing one. They claim that they designed the syntax to be very easily parsed by very simple tools in order to make things like syntax highlighters very easy and robust. So indentation-based blocks are right out. But computer languages should be designed to be readable by humans. It's not like you need to write a new parser once a year, but you have to read code everyday. You will get no argument from me. My point was only that they had an overall design sensibility, I think you characterized it fairly, even if it is not one many of us here want to work within. Of course, one way they could show the benefit of Go would be to rewrite CPython in Go and have it be faster, at least for appropriate programs on multicore machines. Or write a Python compiler. Either way, include a foreign function interface that could connect to existing C extensions. Google and the rest of the world certainly have lots of code to test such. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
Le Mon, 23 Nov 2009 11:54:19 -0600, Robert Kern a écrit : Not really. The idea was to make the language easily parsed and lexed and analyzed by *other* tools, not written in Go, that may have limited capabilities. Well, if Go doesn't allow you to write libraries usable from other low- level languages I'm not sure it is a good systems programming language. One point of C is that you can bridge it with everything. Vim isn't written in Go and won't be able to use their API, for example. Syntax highlighting doesn't require a full-blown parser. You probably want to handle three types of events: - comments (and docstrings and the like for languages which have them) - keywords - delimiters of basic syntactical blocks (which most of the time is simply matching pairs of parens / square brackets / curly brackets) That is, you need a very small part of the information a complete parser would give you. In particular, you don't need to know about operator precedence. You don't need to know about what kind of block you are inside (function, method, class...). You don't need to know whether an identifier is a local variable, a global variable, a type, etc. You don't even need to know the different operators. You only need to recognize the basic lexemes and that's all. The reason the Go designers gave for the braindead syntax looks dramatically unserious and makes it look a bit like a joke. (actually, what really made me wonder whether Go was a joke was the iota keyword) -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On 2009-11-23 14:47 PM, Antoine Pitrou wrote: Le Mon, 23 Nov 2009 11:54:19 -0600, Robert Kern a écrit : Not really. The idea was to make the language easily parsed and lexed and analyzed by *other* tools, not written in Go, that may have limited capabilities. Well, if Go doesn't allow you to write libraries usable from other low- level languages I'm not sure it is a good systems programming language. One point of C is that you can bridge it with everything. That doesn't help tools that are already built with their own capabilities. I don't link Python into my editor to get Python syntax highlighting. The easier it is to write *a* parser/analyzer for the language in any other programming language, the more tools you will get for a broader range of runtime environments, particularly constrained environments like editors that may not be extensible at all. Vim isn't written in Go and won't be able to use their API, for example. Syntax highlighting doesn't require a full-blown parser. Most of the time. FORTRAN does require a full-blown parser if you want to be accurate. And the more regular a language is, the more interesting things one can do with just the tools that are usually available for syntax highlighting. FORTRAN and Go represent two opposite sides of that spectrum. You probably want to handle three types of events: - comments (and docstrings and the like for languages which have them) - keywords - delimiters of basic syntactical blocks (which most of the time is simply matching pairs of parens / square brackets / curly brackets) That is, you need a very small part of the information a complete parser would give you. In particular, you don't need to know about operator precedence. You don't need to know about what kind of block you are inside (function, method, class...). You don't need to know whether an identifier is a local variable, a global variable, a type, etc. You don't even need to know the different operators. You only need to recognize the basic lexemes and that's all. You can get away with just that and have something people recognize as syntax highlighting, yes. But if it is possible to highlight local variables, globals, and types differently, that *is* useful. And you will even see some syntax highlighters doing more advanced things like that even for Python (though mostly with heuristics). But note that the more regular the language is, the less you need to rely on a full parser, and the more interesting things you can do with just lexing and other simpler approaches. That's what they are going for. If I were designing a language, that wouldn't be the tradeoff I would make, but they have their own needs. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
Robert Kern wrote: The easier it is to write *a* parser/analyzer for the language in any other programming language, the more tools you will get for a broader range of runtime environments, particularly constrained environments like editors that may not be extensible at all. Seems to me that having a bit more punctuation in the language would make it easier for things like editors that don't have sophisticated parsing abilities to do a better job of syntax highlighting. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
In article 7ms7ctf3k2a7...@mid.individual.net, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: However, Go's designers seem to favour using the absolute minimum number of characters they can get away with. Although if they *really* wanted that, they would have dropped most of the semicolons and used indentation-based block structure instead of curly braces. I would have forgiven them several other sins if they'd done that. :-) That's essentially my issue with Go based on the code samples I've seen: no over-arching design sensibility at the syntax level. It looks like an aggolomeration of semi-random C-like syntax. There's nothing that shouts out, This is a Go program, unlike Python, C, and even Perl. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ The best way to get information on Usenet is not to ask a question, but to post the wrong information. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On Nov 21, 8:40 am, Duncan Booth duncan.bo...@invalid.invalid wrote: a...@pythoncraft.com (Aahz) wrote: Comparing Go to another computer language -- do you recognize it? http://www.cowlark.com/2009-11-15-go/ Yes, spotted it at the first 'fi'. This isn't the first time anyone has criticized Go. The interesting, and somewhat sad, thing is that the entire mess can be explained very easily by looking at the beginning of the language design FAQ on the Go web site. See if you recognize the names of the principle people who designed it. Yep. Go is simply C with most (but not all) of the warts removed and some more modern features added. Brought to you by the same people who brought you C and Unix all those years ago. The use of the Plan 9 toolchain is not a coincidence. John Roth -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On Fri, 20 Nov 2009 17:12:36 -0800, Aahz wrote: Comparing Go to another computer language -- do you recognize it? Here is a language so far ahead of its time that it was not only an improvement on its predecessors but also on nearly all its successors. - C. A. R. Hoare (although he was actually referring to ALGOL-60). -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On Nov 21, 11:20 am, John Roth johnro...@gmail.com wrote: On Nov 21, 8:40 am, Duncan Booth duncan.bo...@invalid.invalid wrote: a...@pythoncraft.com (Aahz) wrote: Comparing Go to another computer language -- do you recognize it? http://www.cowlark.com/2009-11-15-go/ Yes, spotted it at the first 'fi'. This isn't the first time anyone has criticized Go. The interesting, and somewhat sad, thing is that the entire mess can be explained very easily by looking at the beginning of the language design FAQ on the Go web site. See if you recognize the names of the principle people who designed it. Yep. Go is simply C with most (but not all) of the warts removed and some more modern features added. Brought to you by the same people who brought you C and Unix all those years ago. The use of the Plan 9 toolchain is not a coincidence. The assertion that Go is simply C with warts removed and modern features added is not surprising. If you read the Go FAQ, you will see that there is no claim anywhere that they are trying to solve the problem that 40 years of language development since Algol has not produced super-sexy quantum leaps of improvement. Instead, they are trying to solve the problem that in the last ten years, there haven not seen ANY improvement in systems programming languages (No major systems language has emerged in over a decade). The critics of Go probably fall into four categories: 1) Some do not understand the goals of the Go project itself, so they are criticizing Go for not solving problems that were never in Go's bailiwick to begin with. 2) Some believe that Go does not deliver on its goal to modernize systems programming languages. 3) Some do not accept the premise that there has been no progress outside of Go in the last ten years with regards to systems programming languages, and they are wondering why Google invented Go instead of embracing other technologies. 4) Some people do not even believe that the problem is important--do we actually need a modern systems programming language, or do we just need modern programming languages to perform well under all circumstances, or at least be adaptable? My list probably isn't even nearly exhaustive. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On Nov 21, 6:11 pm, Steve Howell showel...@yahoo.com wrote: On Nov 21, 11:20 am, John Roth johnro...@gmail.com wrote: On Nov 21, 8:40 am, Duncan Booth duncan.bo...@invalid.invalid wrote: a...@pythoncraft.com (Aahz) wrote: Comparing Go to another computer language -- do you recognize it? http://www.cowlark.com/2009-11-15-go/ Yes, spotted it at the first 'fi'. This isn't the first time anyone has criticized Go. The interesting, and somewhat sad, thing is that the entire mess can be explained very easily by looking at the beginning of the language design FAQ on the Go web site. See if you recognize the names of the principle people who designed it. Yep. Go is simply C with most (but not all) of the warts removed and some more modern features added. Brought to you by the same people who brought you C and Unix all those years ago. The use of the Plan 9 toolchain is not a coincidence. The assertion that Go is simply C with warts removed and modern features added is not surprising. If you read the Go FAQ, you will see that there is no claim anywhere that they are trying to solve the problem that 40 years of language development since Algol has not produced super-sexy quantum leaps of improvement. Instead, they are trying to solve the problem that in the last ten years, there haven not seen ANY improvement in systems programming languages (No major systems language has emerged in over a decade). The critics of Go probably fall into four categories: 1) Some do not understand the goals of the Go project itself, so they are criticizing Go for not solving problems that were never in Go's bailiwick to begin with. 2) Some believe that Go does not deliver on its goal to modernize systems programming languages. 3) Some do not accept the premise that there has been no progress outside of Go in the last ten years with regards to systems programming languages, and they are wondering why Google invented Go instead of embracing other technologies. 4) Some people do not even believe that the problem is important--do we actually need a modern systems programming language, or do we just need modern programming languages to perform well under all circumstances, or at least be adaptable? My list probably isn't even nearly exhaustive. Like those who think Python programmers would be interedted in Go because it has an import statement. -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On Nov 21, 11:20 am, John Roth johnro...@gmail.com wrote: Go is simply C with most (but not all) of the warts removed and some more modern features added. Syntax-wise, I find myself disappointed that they didn't do as good a job of removing the warts as they could have. For example, there are good reasons for putting types after variable names, but just swapping them around doesn't quite work. C's int x reads well because it mimics similar constructs in English which qualify a noun with another noun, e.g. President Obama. If you say Obama President, it doesn't sound right. You need some extra punctuation to make it meaningful: Obama, President. Similarly, I think just a little bit more punctuation is needed to make name-first declarations readable. For my money, it's hard to beat the Wirth style: func foo(x: int; y: char): float However, Go's designers seem to favour using the absolute minimum number of characters they can get away with. Although if they *really* wanted that, they would have dropped most of the semicolons and used indentation-based block structure instead of curly braces. I would have forgiven them several other sins if they'd done that. :-) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Go versus Brand X
Comparing Go to another computer language -- do you recognize it? http://www.cowlark.com/2009-11-15-go/ -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan -- http://mail.python.org/mailman/listinfo/python-list
Re: Go versus Brand X
On Nov 20, 7:12 pm, a...@pythoncraft.com (Aahz) wrote: Comparing Go to another computer language -- do you recognize it? No, it predates my entry into the computer biz. http://www.cowlark.com/2009-11-15-go/ -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan -- http://mail.python.org/mailman/listinfo/python-list
