/prog/s opinion on Go

You know, the google thing.  Personally I'm a bit excited for a compiled python-like C language.  It's going to take for fucking ever for it to become useful, though, especially with google's slow and steady attitude.  I could see it catching on though kind of like python did.

>>117
Who said Lispers don't read their textbooks? Most of them read more textbooks than the average programmer.

>>121
My theory is that since we have better books than other languages Little Schemer/SICP/AMOP/PAIP it makes us more inclined to read them

factorial n = if n > 0 then n * factorial (n-1) else 1

>>121
Oh, Lispers read textbooks, yeah.
But they're the kinds of people who then write a blog post about how they read the book, whereas for most people finishing a book is not an earth shattering event

>>122
My theory is that since C has better books than other languages K&R/APitUE/Lions' it makes us more inclined to read them.

My theory is that since Perl has better book than other languages Learning Perl/Intermediate Perl/Programming Perl it makes us more inclined to read them.

etc etc etc for every common language in existence.

>>125
etc etc etc for every common language in existence.
You are supposed to do 1 and then leave it for others to continue on. Seriously, the manners of some people

>>124
I don't think that is the case.
1) There's not a lot of Lispers
2) I don't own a blog, and don't plan on having one in the future
3) I've only seen a handful of Lisp blogs. A few were interesting, but they talked about things like what was the latest feature someone added to their compiler or something along those lines. Sometimes, those may be worth reading. From the few Lisp blogs that I've seen, only like 2 of them talked about reading some Lisp book, and it was a newbie's blog, which means most people won't be reading those.
4) I find some books to be insightful(wether about Lisp or in general), but I haven't encountered that many books which lead to an "earth shattering event".
5) The general attitude in the Lisp community is that people should write more code, instead of talking about how great Lisp is. Graham did a bit too much of the latter. There's also some strange people who don't actually know Lisp, but sing praises to it, and view it as some perfect language in which they'll never code in, instead they come to Lisp for "enlightment" - this is the wrong attitude, Lisp may give a programmer new views on certain problems, but that's not going to happen unless you actually learn the language well and use it.

>>125
There's actually a surprising few Lisp books, but the overall quality is fairly high. More popular languages tend to have a lot of books written for them, but only a handful are top quality. It's only natural that there will be more low quality books in a market where the demand is high, while in a market where the demand is low, only those actually interested in will write the books. This ratio isn't very important, as long as the reader knows which books to read.

>>116
No, parametric is slightly different from ad-hoc polymorphism. In terms of System F, the former is expressed as
/\T. \x:T. do something with x
whereas the latter is
/\T. \x:T. if (T can be unified with A) then foo x
      else if (T can be unified with B) then bar x
Yes, you can simulate the parametric variant by simply providing the same code for foo and bar, but that defeats the abstraction.

>>128
No I get it. What I'm saying is that if Go's approach is used correctly, there's little need for parametrics. The problem is there's still a small gap and it's kind of annoying. On the other hand, I would rather see every other problem addressed first.

>>128
Lets see if I've understood this correctly
foo :: a -> [a] would be parametric
bar :: (Baz a) => a -> [a] would be ad hoc

>>107
Type operators are simply abstractions over types as if they were values, and works in tandem with polymorphism to allow the programmer to write generic code. For example, LinkedList in Java is an operator that takes a type and gives another type, and the type inside angle brackets is the argument. LinkedList<Int> returns the type of linked lists specialized to hold integers.

With generalized type operators, it is possible to do all sorts of crazy shit, like defining null-safe lists (cliche pseudo-Haskell here):

data Zero :: *
data Succ n :: *
data List n a where
  cons :: forall n a. a -> List n a -> List (Succ n) a
  nil :: forall a. List Zero a
head :: forall n a. List (Succ n) a -> a
head [x] = x
Note that head is typesafe. If passed an empty list, the compiler will throw a type error. Succ and List are both type operators. The former takes one argument, while the latter takes two.

>>130
Your second snippet would be ad-hoc if bar is defined within a typeclass instantiation. If it is just a vanilla function, then it's still just parametric, except now the type parameter has an extra constraint: that a is an instance of Baz.

>>132
Ah yes, I knew I was missing something. Thanks

>>106,108,111

The only place where null is useful is as a sentinel value for collections. But if you really think about it, any well-chosen user-defined value can fulfill that role. Everywhere else, it's a pain in the ass to deal with. Don't tell me you've never been annoyed with NullPointerExceptions, because that's bullshit.

Having null in the language amounts to admitting the possibility of run-time errors *every time* you use a pointer/reference, but null is obviously only useful *sometimes*. See Scala or OCaml's Option and Haskell's Maybe for alternative ways to solve the null problem when they *are* needed. Note that OCaml is object-oriented, but its variables can never be null. That is because the ML language family actually has type systems that advanced beyond the 70s, unlike C++ and Java, who use glorified structs and are object-oriented in name only.

In short, think of null as the equivalent of Haskell's _|_. Both can be values of any type, but Haskell actually has the courtesy to crap out and allow the programmer to give a helpful text message every time it is encountered, whereas Java, C++ (pointers only, not references), and Go will happily chug along until the problem is encountered so far from its source that hours of frustration ensue.

Remember, kids: When you must fail, fail noisily and as soon as possible.

>>134
I've never been annoyed by null pointer exceptions because I generally don't spend much time in languages that make heavy use of exceptions. Not to mention I check operations that could return null. It's not like it is somehow required to throw over every encountered null value anyway, but people do. Don't hate the player.

Besides which, I rarely find libraries that will return null when it should be meaningless. In other words, testing on null in practice ought only be necessary when some kind of test is necessary anyway. Your null pointer exception stems from the fact that exceptions are being misused, presumably in order to prevent the problem of having to try { everything }, which is also frustrating. The exceptional case should be truly exceptional; "degenerate state" not "operation failed." (Ignoring the latter is cause #1 of the former. Throwing on the latter promotes it to the former.)

>>107
Thanks for helping the rest of us idiots (this is not sarcasm, I actually was wondering the same things but was afraid to ask a bunch of stupid questions).

I'll ask a few more:

Full type inference;
These were rejected as problematic. Part of the goal is unambiguous code.

Why is full type inference problematic? Is it that it did not play nice with their (quite cool) system of inferring implemented interfaces?

I've never used a language that has it, but as I'm reading about it, full type inference seems pretty awesome to me. It's like everything is a template. Why is this not in the language?

Does type inference cause problems with break/continue, return, goto, etc? I've heard that in many languages (especially functional languages), if/else blocks return values, which is great except that because of type inference and static typing, Haskell has the additional restriction that both blocks must return the same type. Is this true? Is this a huge pain in the ass, especially when the language doesn't have null?

null

I've never used a language that doesn't have some sort of null, but I've heard people talk about why this is great also. Personally, I know that in C I like the ability to take several parameters, and just ignore them if they are null (for example a function that outputs to a pointer and returns length; if the pointer is null, nothing is written, and you get the length you need to allocate).

Are you forced to write separate functions that call eachother in this scenario? Is this somewhat mitigated by function overloading?

An example that springs to mind where this might be problematic is a function that takes a 'logger' argument, and if it's non-null, it prints to it at several points throughout the function. How does this work if the logger can't be null? Surely you can't duplicate that code. Do you make a 'dummy' logger that ignores calls to print into it? This seems inefficient; you're probably doing lots of string formatting, and you'd like that code skipped. Do you make a sentinel value for 'no logger', and the function checks against it before trying to print? Seems like a hack to implement a (typesafe) null manually. How do you solve this problem?

Side note, nice to see a decent programming thread here once in a while. Thanks for not being dicks.

>>136
whoa whoa take it easy buddy, one question at a time, one question at a time! oxygen, I need oxygen here. you're smothering me

how does one pronounce "haskell"?

>>95
it doesn't offer anything remarkable in any form whatsoever.
Of course, neither does Go.

>>138
LISP

Frozen Void is right.

The only interesting things with Go are
- the no inheritance motto, only interfaces
- goroutines

The rest of the language is pure distillated fail.

>>141
3/10

>>136
Type inference is not an implementation issue, not that I know of anyway. The idea I keep getting is that being forced to write out a conversion is better for code clarity.

Also, in Go you only ever return a specified type. If you think this is a problem, the type can be interface{} which every type satisfies, but putting an int in there won't make the LHS an int, it will just be interface{}. (You can still use it like an int, but you basically have to cast it.)

For non-nullable types, people mostly want to see them included in the language so return values and required parameters can never be nil. This would be awkward because there are no exceptions at the moment, so potentially recoverable situations would be promoted to irrecoverable ones. (The bigger part of the idea is to remove the need for defensive programming. I really don't buy that though.)

>>141
Frozen Void
Stopped reading right there.

>>144
You should have stopped posting right there. Announcing that you're ignoring something is pretty lame dude.

>>145
Ignoring FV should be mandatory. Because it isn't, we must exert peer pressure in order to preserve social order and have sensibility dominate /prog/. As you are unaware of this, I will also say, welcome to GTFO.

>>146
You should try actually ignoring him rather than making a stink and drawing yet more attention.

>>146
Although it is flattering to "dominate /prog/", in fact, it is a very bad idea. Unlike most of human society, science and engineering are based on the idea that each of us is capable of evaluating evidence and thinking on our own. Each of us can do experiments, work out the reasoning, and determine the truth for ourselves. There is no room in science or engineering for "sage" representing group disapproval over individual thought.

>>148
Did you mean, "Acceptance and rejection of theories in technical disciplines involve group approval or disapproval over individual thought"?

>>149
I see he's gotten to you already.

Damn it, MDickie, you're a programmer.  You know that science and engineering can't be taken away with the wave of a magic paintbrush.  They're the things we carry with us, the things that make us who we are.  If we lose them, we lose ourselves.  I don't want my science taken away!  I need my science!

And then >>150 was replaced by an artist.

>>107
An effects system is an extension to the language, usually in the type system, that statically infers the source and scope of side effects. In a systems programming language like Go, such a feature is ridiculously useful, because not only does it require no runtime overhead, it drastically reduces the number of errors usually attributed to "invisible" changes to state.

>>141
distillated
（　≖‿≖）

package main
import "fmt"
 
func main() {
    fmt.Printf("Hello World !!! \n")
}

>>154
package main

func main() { println("EHLO 世界") }

>>152
type inference
no runtime overhead
（　°‿‿°）

>>156
Do you somehow doubt this?

>>157
（　°‿‿°）

（　≖o≖）

(　≖‿≖)　　D
( ≖‿≖ ) 　　I
(≖‿≖　)　　C
(‿≖   ) 　　K
(≖　　　) 　　
(　 　　 ) 　　T
(　 　　 ) 　　O
(　　　≖) 　　W
( 　≖‿) 　　E
(　≖‿≖)　　R

I'm pretty sure that he'll enjoy being stuffed into anuses of clueless toddlers. (　≖‿≖)

(　≖‿≖)　　R
( 　≖‿) 　　E
(　　　≖) 　　W
(　 　　 ) 　　O
(　 　　 ) 　　T
(≖　　　) 　　
(‿≖   ) 　　K
(≖‿≖　)　　C
( ≖‿≖ ) 　　I
(　≖‿≖)　　D