@Sven Groot: Right, in that case one would need something like Option<T> because C# wasn't designed from the outset with nullability as an orthogonal concept.
*cough* topic *cough*
What do you guys think about the proposal to declare local variables as part of expressions?
int.TryParse("123", out int x);
I find this excruciatingly ugly - but understand the desire for compactness. But then why not solve this at the API-level with nullable primitive types?
var x = int.ParseNullable("123"); // x : int?
var x = int.ParseNullable("123") ?? 0; // x : int
I guess if you have to interact with lots of methods that use "multiple return values" through out parameters rather than tuples or other structures then this saves you pain.
Most of this stuff appears to be minor syntactic sugar - nothing major like async/await. I think Lucian once spoke about async methods returning multiple values. Perhaps something a la this:
Agreed (except they don't need to be).
@Jason818: Text is more concise, usually, than visual languages because they are symbolic of some mental concept and if you have to draw a rectangle or something to define boundaries,that ends up being extra noise with no syntactical or semantic meaning, and instead, some label on that shape is what is actually important.
Intentional Software has an DSL editor where one can switch between textual and visual presentations and forms of interaction. Some notations are also more suited for some domains and are semi-visual.
Mathematica also comes to mind.
If you have to care much about "drawing" or "defining boundaries" then the implementation is not smart enough. You should only have to care about three things: instantiation (via e.g. drag and drop), connecting (via e.g. drag and drop) and perhaps commenting (via e.g. typing or talking). Graph layout perhaps guided by a logic engine with some domain understanding could help with automatically arranging objects in a pleasing and sensible way. [Easier written than implemented, of course.]
However visual programming is perhaps best used at a coarse-grained level in the form of workflows. Workflows are programs and they are presented in diagram form. They have sequences, branches, repetitions, events, etc.
So many programmers already use "visual programming".
Now all you need is to convince the people taking the snapshots to take the video of the path you'd like to travel (and all other people would like to travel). That should be easy!
This looks similar to F# constructor syntax
Wasn't this null-safe operator part of Cω? It looks very useful indeed. In F# it's less of an issue because types have to be declared as nullable - except for all other "foreign" types that are also nullable.
Really exceptions/etc. are all just a type of syntax for the more fundamental maybe construct explicitly found in some purely functional languages. Using something derived from maybe is the only way I can see to implement something like IEnumerable without introducing the side effects in question.
Nitpick: Maybe has nothing to do with purely functional languages per se. C# has the Nullable type (albeit limited to value types; because reference types are unfortunately always nullable in C#) whereas F#, SML and others have a more generalized option type (which has a nice synergy with default non-nullable reference types in F#).
Also, I wouldn't say Maybe/option is a good way to model exceptions. Because either you get a value or you don't - but then you don't know why you didn't get one! No, in general discriminated unions could be used instead - but that's another story.