Live data from Hacker News

Maybe adding generics to Go is about syntax after all

dave.cheney.net

61–70 of 92 posts

Re: Maybe adding generics to Go is about syntax after all

#61
post #15
post #6

Earlier quoted context omitted.

Why not use lisp syntax, at all? Why do we have to reinvent syntax every single generation? I'm not an old school engineer (I'm in my early 20s and in my first job, freshly outta college) but I can't see why we don't use lisp, prolog or ML syntax for everything . Seems vastly better than C-like synaxes in all ways I can think of, easier to implement, easier to extend, easier to read (imho) etc... When I program even…

I tinkered a bit (as many others have too!) with a lisp syntax for C, just to see what it'd feel like. That is, exact C semantics (so not inventing anything) but sexpressions. What I remember struggling with is that it was surprisingly kind of hard to remember when parens are necessary where. For example you might define an if statement: (if (> x 3) (printf ...)) Looks nice, but what about if you want multiple things…

See the Common Lisp IF* macro:

  (if* (> 3 2) then (foo) (bar) else (baz))
https://franz.com/~jkf/ifstar.txt

Re: Maybe adding generics to Go is about syntax after all

#62

It's been three years since I started writing Go professionally and I think adding generics to Go is one of the worst ideas I've ever encountered. I love Haskell, and I much prefer hindley-milner type systems, type classes, and real sum types. I see the value of generics where appropriate. Golang, however, made the tradeoff to sacrifice anything near that level of abstraction, and it's success might largely be attrib…

I've also been writing a lot of Go professionally for a long time, and I've used every part of the language extensively, and I disagree.

There are many times I remember where I've had to implement some sort of application specific data structure that's not built into the language, and generics would have made it a lot nicer. I made it generic by using interfaces, but then you have the problem of throwing away type safety, so to preserve it, you need wrappers which cast.

It's not a given that adding generics would ruin the ergonomics of the language. I hope that whatever form generics do take in the end, that they remain simple. If I see template meta-programming in Go of the sort that occurs in C++, I think I'll scream, but that meta programming was to work around limitations in C++'s typing system which Go doesn't share.

Re: Maybe adding generics to Go is about syntax after all

#63
post #48

Earlier quoted context omitted.

Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...

I assert most programmers have not been exposed to lisp. I further assert most that complain of it's lack of syntax have not used it in any capacity. I would be interested in studies on this. Most I ever see is posturing and assertions with little to no evidence. Frustrating, because I think both sides have valid points. And I fully believe there is a learning curve both ways. I suspect they both converge on total ab…

I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing.

My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from it.

Of course, the big flaw in my argument is the growth of the industry. A huge number of new people came in. Did they know Lisp, even at a college level? Maybe, maybe not.

My counter-argument to that is that industry knew Lisp, even if the new programmers didn't. If industry wanted them to learn Lisp, it could have made knowing it a job requirement, or trained people.

Re: Maybe adding generics to Go is about syntax after all

#64
post #41

Earlier quoted context omitted.

This is overstating the case for syntax. Without any empirical evidence that syntax is important to anyone other than folks that draft up syntax rules, this is just an assertion. Put another way, do you have evidence that it is important? Has it let people write better programs? How would you prove that? This is akin to saying grammar is important. It is, to an extent; but over adherence to grammar is usually not an…

Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...

Maybe because they don't understand it.

Lisp has syntax. More than any other programming language.

What you think Lisp syntax is, are really simple function calls like

    (+ 1 2)
which are based on the function + various args pattern.

But something like Common Lisp has a few dozen syntactic built-in forms. For example the syntax for LET is in an EBNF (extended backus naur form) form:

     let ({var | (var [init-form])}*) declaration* form*
Then Lisp has macros. Zillions. Each of them implements syntax.

Lisp has a two-stage syntax:

1. stage are s-expressions, a data format: symbols, numbers, lists, strings, ...

2. stage are Lisp forms. They are written as s-expressions. But they have to follow a defined syntax. not every s-expression is a valid Lisp form.

  (let ((a 1) (b 2))
    (declare (integer a b))
    (+ a b))
Above is a valid LET form.

  (let ((a 1) (b 2))
    (+ a b)
    (declare (integer a b)))
Above is not a valid LET form, because the syntax requires that the optional declaration is directly after the binding form.

Without parentheses it might look like:

  let (a 1) (b 2)
    declare integer a b
    a + b
You would think that it has a syntactic structure. Just because Lisp uses s-expressions as a base mechanism, does not mean Lisp has no syntactic structure - but it is on top of s-expressions.

Since Lisp has user-programmable syntax, there is basically an unlimited amount of all kinds of syntactical constructs.

Re: Maybe adding generics to Go is about syntax after all

#65
post #48

Earlier quoted context omitted.

I assert most programmers have not been exposed to lisp. I further assert most that complain of it's lack of syntax have not used it in any capacity. I would be interested in studies on this. Most I ever see is posturing and assertions with little to no evidence. Frustrating, because I think both sides have valid points. And I fully believe there is a learning curve both ways. I suspect they both converge on total ab…

I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing. My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from…

> My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s.

Unlikely, given that TIOBE the company wasn't founded until 2000, and the TIOBE index is based on web search engine results, and there weren't any web search engines, or a web for them to search, in the 1980s.

Re: Maybe adding generics to Go is about syntax after all

#66

It's been three years since I started writing Go professionally and I think adding generics to Go is one of the worst ideas I've ever encountered. I love Haskell, and I much prefer hindley-milner type systems, type classes, and real sum types. I see the value of generics where appropriate. Golang, however, made the tradeoff to sacrifice anything near that level of abstraction, and it's success might largely be attrib…

I've also been writing a lot of Go professionally for a long time, and I've used every part of the language extensively, and I disagree. There are many times I remember where I've had to implement some sort of application specific data structure that's not built into the language, and generics would have made it a lot nicer. I made it generic by using interfaces, but then you have the problem of throwing away type sa…

What do you mean by nicer? I would imagine that something that is application specific would not require generics.

Interfaces do not throw away type safety if they are used correctly. They are also better suited for the consumer of the type rather than the definer. One of your problems might be that you are prematurely abstracting your interfaces for your callers.

Re: Maybe adding generics to Go is about syntax after all

#67
post #48

Earlier quoted context omitted.

I assert most programmers have not been exposed to lisp. I further assert most that complain of it's lack of syntax have not used it in any capacity. I would be interested in studies on this. Most I ever see is posturing and assertions with little to no evidence. Frustrating, because I think both sides have valid points. And I fully believe there is a learning curve both ways. I suspect they both converge on total ab…

I think it's going to be really hard to do the study in a rigorous way. Solid data would be nice, though. Then we could stop guessing. My best try at a data point is that Lisp was #4 on the TIOBE index back in the 1980s. Now it's on the fringe. I assert that people had been exposed to Lisp, it was widely used. It became less and less popular. It's not that industry didn't know Lisp; they knew it and turned away from…

Agreed it would be really hard. I do want to underscore I'm interested in the question. And I don't know which way I expect it to go.

My personal hunch is that lisp was just too expensive when most industry took off. In near every way. C compilers being basically free is a ridiculous advantage. Yes, there are free lisp implementations today. However, early mover advantage is working against them, now.

Re: Maybe adding generics to Go is about syntax after all

#68
post #64

Earlier quoted context omitted.

Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...

Maybe because they don't understand it. Lisp has syntax. More than any other programming language. What you think Lisp syntax is, are really simple function calls like (+ 1 2) which are based on the function + various args pattern. But something like Common Lisp has a few dozen syntactic built-in forms. For example the syntax for LET is in an EBNF (extended backus naur form) form: let ({var | (var [init-form])}*) dec…

I really should adopt this view in my future posts.

I think the difference is most people, myself included, are looking at basically the syntax as where the capital letter and the sentence ending punctuation go. Which is really the only mostly constant thing in most sentences. You raise a vital point that that is a small part of the syntactic makeup of a sentence.

Which is funny, because so many people are convinced you get no static help in lisp. Which is demonstrably wrong.

Re: Maybe adding generics to Go is about syntax after all

#69

Earlier quoted context omitted.

I've also been writing a lot of Go professionally for a long time, and I've used every part of the language extensively, and I disagree. There are many times I remember where I've had to implement some sort of application specific data structure that's not built into the language, and generics would have made it a lot nicer. I made it generic by using interfaces, but then you have the problem of throwing away type sa…

What do you mean by nicer? I would imagine that something that is application specific would not require generics. Interfaces do not throw away type safety if they are used correctly. They are also better suited for the consumer of the type rather than the definer. One of your problems might be that you are prematurely abstracting your interfaces for your callers.

interface {} definitely does throw away type safety, however, and is reasonably necessary for some library use cases. Is it possible that you're coming at this from an angle of building applications for specific purposes, while oppositelock is building more libraries?

My experience (admittedly limited) is that application writing in Go is nice, but as soon as I try to build a library for use in several similar (but not quite identical) cases, maintaining type safety can quickly become a hassle.

Re: Maybe adding generics to Go is about syntax after all

#70
post #64

Earlier quoted context omitted.

Well, empirically, syntax is important to a large number of programmers who complain about Lisp's (lack of) syntax. That's not a rigorous empirical study, but it's the best I can do at the moment...

Maybe because they don't understand it. Lisp has syntax. More than any other programming language. What you think Lisp syntax is, are really simple function calls like (+ 1 2) which are based on the function + various args pattern. But something like Common Lisp has a few dozen syntactic built-in forms. For example the syntax for LET is in an EBNF (extended backus naur form) form: let ({var | (var [init-form])}*) dec…

Another helpful comparison is Lisp syntax versus Forth syntax. If you actually want a simple, terse, unstructured language, Forth is the way to do it: Words will consume and return any number of inputs or outputs to the stack, and you get entire classes of error when it's unbalanced that would surface as syntax errors anywhere else.

Just adding s-expressions is actually a huge jump up in syntactic complexity and structure, since now you can define a whole hierarchy statically, "on the page", instead of having to use a series of stack operations to manipulate memory from afar. And then as you lucidly put it, going from s-expressions to a practical Lisp dialect adds another level of context on top of that.

(And yeah, it's possible to bolt structure onto a Forth dialect, too, but the "Chuck Moore way" is that you do that custom every time you need it, instead of trying to generalize. Generalizing a concatenative structure leads to something like Factor.)

Post reply on HN