5 ms·

In an essay titled "Why Pascal is Not My Favorite Programming Language"[1] Brian W. Kernighan wrote: The size of an array is part of its type If one declar

In an essay titled "Why Pascal is Not My Favorite Programming Language"[1] Brian W. Kernighan wrote: The size of an array is part of its type If one declares var arr10 : array [1..10] of integer; arr20 : array [1..20] of integer; then arr10 and arr20 are arrays of 10 and 20 integers respectively. Suppose we want to write a procedure 'sort' to sort an integer array. Because arr10 and arr20 have different types, it is not possible to write a single procedure that will sort them both. The place where this affects Software Tools particularly, and I think programs in general, is that it makes it difficult indeed to create a library of routines for doing common, general-purpose operations like sorting. People who complain about the lack of generics in Go are making the same argument that Kernighan made against Pascal viz. that it is tedious to write library code in the language. EDIT: Also it is not uncommon for a feature that is deemed essential by some to be thought of as adding too much complexity by others. For example, "I've seen [visual] editors like that, but I don't feel a need for them. I don't want to see the state of the file when I'm editing." said Ken Thompson [2] when comparing line editors like ed to visual editors like vi or emacs. [1]: http://www.lysator.liu.se/c/bwk-on-pascal.html http://www.lysator.liu.se/c/bwk-on-pascal.html [2]: http://web.archive.org/web/20080103071208/http://www.dcs.qmul.ac.uk/~george/history/ http://web.archive.org/web/20080103071208/http://www.dcs.qmu...

gnuvince 12y ago
In a funny twist of history, Kernighan is now writing a book on a language where the length of an array is part of its type: http://play.golang.org/p/jrbSgKFZ_1 http://play.golang.org/p/jrbSgKFZ_1
- nemo1618 12y ago
  Technically true, but the point is that arrays were the only collection type in Pascal, whereas Go also has slices (which, in my experience, outnumber arrays 10-1 in most codebases).
  - gnuvince 12y ago
    When did Pascal gain dynamic arrays?
    - pjmlp 12y ago
      Depends which Pascal you mean. The Extended Pascal ISO standard which does include dynamic arrays is from 1990. Turbo Pascal and other Pascal dialects also had them.
  - pjmlp 12y ago
    Not true, otherwise Wirth would have had an hard time to write "Algorithms and Data Structures".
- manacit 12y ago
  To be fair, slices solve that problem completely: http://play.golang.org/p/56KlgWsxjR http://play.golang.org/p/56KlgWsxjR
bdamm 12y ago
The language has decent interfaces for things like sorting. Why is it a problem? Declare a method for your type and you're off to the races.
- coldtea 12y ago
  The same could save for assembly over any other language. Write your own macro-assembler constructs and you're off to the races!
NateDad 12y ago
http://golang.org/pkg/sort/#Sort http://golang.org/pkg/sort/#Sort So, something like that? Interfaces, man. They're better than you think.
- noelwelsh 12y ago
  And in a wonderfully ironic twist, you've completely missed the parent's general point while addressing the specific issue they used to illustrate it. Data structures are the obvious use for generics. There are also things like monads and so forth, used for example in Rust's result type.
- coldtea 12y ago
  Yeah, fuck this type safety and performance thing...
  - NateDad 12y ago
    It's type safe and there's little performance hit. Please note that the "Interface" there is not "interface{}" ... it is a somewhat unfortunately named interface: http://golang.org/pkg/sort/#Interface http://golang.org/pkg/sort/#Interface The Go authors were following a practice that seemed like a good idea at first, and they've now admitted was probably a mistake... i.e. if your package is mostly about a single interface, name the package something informative, and call the interface type "Interface". This works relatively well from calling code, since it'll be referenced as "sort.Interface", but it makes the documentation for the type potentially confusing.
    - coldtea 12y ago
      OK, thought you meant the interface{} thing people go for, since Go doesn't have generics. This Sort.Interface thing is indeed safe and performant. On the other hand its not a solution to the problem we're discussing (that, to quote the parent, due to lack of generics "it is tedious to write library code in the language"). You still have to implement it all the time for all types despite having identical implementations. So this doesn't show how it's not tedious. It just shows that it can be done in some way, which nobody doubted.

gnuvince 12y ago

In a funny twist of history, Kernighan is now writing a book on a language where the length of an array is part of its type: http://play.golang.org/p/jrbSgKFZ_1 http://play.golang.org/p/jrbSgKFZ_1

nemo1618 12y ago
Technically true, but the point is that arrays were the only collection type in Pascal, whereas Go also has slices (which, in my experience, outnumber arrays 10-1 in most codebases).
- gnuvince 12y ago
  When did Pascal gain dynamic arrays?
  - pjmlp 12y ago
    Depends which Pascal you mean. The Extended Pascal ISO standard which does include dynamic arrays is from 1990. Turbo Pascal and other Pascal dialects also had them.
- pjmlp 12y ago
  Not true, otherwise Wirth would have had an hard time to write "Algorithms and Data Structures".
manacit 12y ago
To be fair, slices solve that problem completely: http://play.golang.org/p/56KlgWsxjR http://play.golang.org/p/56KlgWsxjR

bdamm 12y ago

The language has decent interfaces for things like sorting. Why is it a problem? Declare a method for your type and you're off to the races.

coldtea 12y ago
The same could save for assembly over any other language. Write your own macro-assembler constructs and you're off to the races!

NateDad 12y ago

http://golang.org/pkg/sort/#Sort http://golang.org/pkg/sort/#Sort So, something like that? Interfaces, man. They're better than you think.

noelwelsh 12y ago
And in a wonderfully ironic twist, you've completely missed the parent's general point while addressing the specific issue they used to illustrate it. Data structures are the obvious use for generics. There are also things like monads and so forth, used for example in Rust's result type.
coldtea 12y ago
Yeah, fuck this type safety and performance thing...
- NateDad 12y ago
  It's type safe and there's little performance hit. Please note that the "Interface" there is not "interface{}" ... it is a somewhat unfortunately named interface: http://golang.org/pkg/sort/#Interface http://golang.org/pkg/sort/#Interface The Go authors were following a practice that seemed like a good idea at first, and they've now admitted was probably a mistake... i.e. if your package is mostly about a single interface, name the package something informative, and call the interface type "Interface". This works relatively well from calling code, since it'll be referenced as "sort.Interface", but it makes the documentation for the type potentially confusing.
  - coldtea 12y ago
    OK, thought you meant the interface{} thing people go for, since Go doesn't have generics. This Sort.Interface thing is indeed safe and performant. On the other hand its not a solution to the problem we're discussing (that, to quote the parent, due to lack of generics "it is tedious to write library code in the language"). You still have to implement it all the time for all types despite having identical implementations. So this doesn't show how it's not tedious. It just shows that it can be done in some way, which nobody doubted.