Well, the F# base syntax is still pretty light. Many constructs are written in F# itself. There's nothing about F# that demands "|>" be "fun x f -> f x" -- you can define it or redefine it as you see fit. Many other constructs are, at some level, just syntactic sugar (if-then/while, etc.).

Your point about "integer" is easily rectified:

1
2
3
4
5
6

 

type integer = int

let a : integer = 1

As far as wanting to have a slightly different syntax on the front end: the full source code is provided :). The reasons I can think of for not offering the option is not only that it adds complexity to the language, but now that F# is commercial, I imagine we'll need a lot better than "why not" as justification. There's documentation, Visual Studio editing, compatibility (someone might be using "recursive" as an identifier, for example), and on and on. That would have to be offset by some real solid evidence that providing long keywords provides enough value to justify the costs.

I'm not convinced that changing "rec" to "recursive", "val" to "value", "sig" to "signature", "fun" to "lambdafunction" ("function" is already used for "fun x -> match x with ..."), and so one are really going to increase the overall readability. Any sizable amount of code will probably use F# idioms like |>, >>, << and so on anyways that you're going to have to "get in the flow" again regardless of a handful of keyword names. (BTW, this is the same reasoning I have against using 'T, 'U versus 'a 'b -- the slight benefit of .NET consistency is overwhelmed by the huge differences in the languages anyways.)

Hi Brian - here's a kindred spirit, commenting on google's "go" language, over in slashdot...

I don't like how this language uses "func" instead of "function",

therefore this language is terrible and everyone who uses it or thinks

about it in any way except for about it sucking is also terrible.

:)

Hi Michael,

When in school, COBOL was one of about 1/2 dozen programming languages in our (Systems Analyst/Programmer), curriculum. I actually enjoyed the English-like nature of COBOL (except for colliding with the reserved words list).

We wrote code - literally - (in pencil, character by character), on pre-printed forms; which were given to data entry personnel, who would type them into punch cards, which were passed along to the main-frame computer operators to run as over-night batch files. So, more room for source code, just meant cutting down a few more trees.

Each error (typo or logical), cost us a day, plus the time it took to find it in a hex dump - ambiguity had a definite price. On the positive side, we only worked in one language (except for the added JCL), at a time. Once you were "into" coding that language, you didn't have to deal with mental switch-backs. [Wonder which coding style, those that made a career of maintaining COBOL written by others, preferred to see?]

The 'precious" memory referred to early microprocessor based systems. The first computer I bought for myself came with 2K RAM, and source code was either typed in directly or "read" off an audio cassette.

Never worked in JAVA (though the concept of its promised universality was appealing). I'll take your word for its short-comings.

Anyway, I should get back to learning F#, with the syntax it has - even if the style makes it harder for at least some of us.

BRN..

A key dimension in this how often you use the language.

Another is how many other languages you use.

I don't know what the spectrum of F# users is, but I find that I need to use an annoyingly wide range of languages to do what I do. Readability after a break is a big issue.

If I can pick up quickly after a fairly big "cognitive break" then a language stands more chance of getting used. If it takes too long to get back into it I might simply drop it.

(I can think of at least one language that I really like, but takes so much time to get back into that I haven't used it for a long time.)

I've not been using F# a lot recently (after I bought the early books I found syntax changing too much, I'm not one who wants to rewrite operational code...).

I have a feeling that F# is well designed in this respect, the significant white space is a good idea (though I like an option of tabs).

(I presume somebody, somewhere has researched this.)