Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

/prog/s opinion on Go

Name: Anonymous 2009-11-28 22:04

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.

Name: Anonymous 2009-12-03 0:05

>>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.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List