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

Pages: 1-

F#uture?

Name: Anonymous 2009-08-12 14:47

Am I wrong in thinking that F# will perhaps be the greatest thing for functional programmers since Lisp was standardized as common lisp?

Its quick, has .NET library access and integration, and has a lot of neat ideas in the language structure. It seems like it will be super popular in the near future.

Name: Anonymous 2009-08-12 14:49

.NET
stopped reading right there

Name: Anonymous 2009-08-12 14:53

It's nice, but it's not like people haven't done O'Caml ports to .NET before. At least since MS is doing it, it means it will be actively maintained.

As for me, I'll probably be sticking with CL for now.

Name: =+=*=F=R=O=Z=E=N==V=O=I=D=*=+= !frozEn/KIg 2009-08-12 16:14

>>1 You been brainwashed by MS. .NET is slow, windows-bound implementation of java.
Also,it manages to be more intrusive and resource hungry than Java itself.


__________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
When everyone thinks the same, nobody is thinking.

Name: Anonymous 2009-08-12 16:38

>>4
You've been brainwashed by GNU.  GNU software is slow, linux-bound ripoffs of useful programs.  Also, it manages to be more buggy and user un-friendly than the original program itself.

Name: =+=*=F=R=O=Z=E=N==V=O=I=D=*=+= !frozEn/KIg 2009-08-12 16:48

>>5 I've not been 'brainwashed' by GNU and i use a wide array of freeware/shareware/proprietary and open-source software. I value quality of programs themself. Not the ideology of their creators.



_____________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
He often argued that human intelligence was more trouble than it was worth. It was more destructive than creative, more confusing than revealing, more discouraging than satisfying, more spiteful than charitable.

Name: Anonymous 2009-08-12 16:53

Clojure > F#

Name: Anonymous 2009-08-12 16:55

>>2
Started agreeing right there.

Name: Anonymous 2009-08-12 16:56

>>7
Needs more TCO.

Name: Anonymous 2009-08-12 16:58

>>4
I've done a few benchmarks myself, and it beats the best Haskell that I can write. I come from ML, OCaml, and Haskell and F# beats all three in speed handily on the toy programs I've written so far. Haskell seems to have better support for threading though, but F#'s model is more simple. I haven't used any of the big library functions in .NET though so I can't speak for their speed, which I hear is pretty bad.

Anyone agree with me on the Syntax? I'm really digging it so far, and I'm comming from Haskell.

Name: =+=*=F=R=O=Z=E=N==V=O=I=D=*=+= !frozEn/KIg 2009-08-12 17:11

>>10 I don't think its syntax is something special. see >>3
Try benchmarking OCaml vs F#.



_____________________________________________
http://xs135.xs.to/xs135/09042/av922.jpg
Velox Et Astrum gamedev forum: http://etastrum.phpbb3now.com
The facts we see depend on where we are placed and the habits of our eyes.

Name: Anonymous 2009-08-12 17:27

>>1
No, but only since CL's standardization didn't mean much of anything for functional programmers. And really, I doubt it was much more than a headache for Lisp programmers either, since it's not like they weren't all working in some perfectly usable existing dialect.

Maybe F# will introduce some Windows programmers to functional programming, so I suppose it's not all useless.

Name: Anonymous 2009-08-12 17:52

>>12
Don't diss CL's standardization, it helped lisp survive, during those times there was a much smaller userbase than today(which is still small), and there were many dialects, some better than others. The standardization unified most of these dialects and ensured lisp's survival (the main reason it was standardized, was that it was a pain to port stuff between different lisps). The resulting standard was pretty complete, but not entirely set in stone, so CL implementors still had some choices. I can only see it as a good thing, try reading the Hyperspec to see how thoroughly thought out the library is.

It may not mean much for purely functional programmers, but CL's functions are first-class: they are objects which can be passed as parameters to functions and returned as needed, and the same applies to closures or lambdas. It allows programming in a fully functional style, but it's a multi-paradigm language which allows you to program in other styles as well, such as imperative, declarative, object-oriented, aspect-oriented, and so on. CL encourages using the most natural style for solving your problem, whatever that style is, maybe that irks some some Haskell programmers that are not used to being allowed such freedoms?

Name: Anonymous 2009-08-12 18:11

U MEAN HASKAL?

Name: Anonymous 2009-08-12 18:47

>>13
It was standardized because DARPA said so. CL is fine, but I don't think it's that significant.

Name: Anonymous 2009-08-12 18:51

>>15
Steele wrote a fairly long paper about the history of Lisp, and he did state that standardization helped the Lisp community survive.

Name: Anonymous 2009-08-12 19:43

>>16
I think it would have survived anyway.

Name: Anonymous 2009-08-12 19:57

>>17
Somehow I don't see many(if any) active implementations of ZetaLisp, InterLisp, MacLisp, Lisp Machine Lisp. It may be argued that Common Lisp killed them, but do you think they would have survived nowadays if CL wouldn't have been standardized?

Name: Anonymous 2009-08-12 19:59

>>17
The 17 highest ranking wizards in the world sacrificed their own lives to send us back here to alter the timeline, and this is the kind of thanks we get.

Name: Anonymous 2009-08-12 20:10

>>18
Hell if I know. I see no reason we wouldn't have had Emacs Lisp and Scheme, and perhaps some of those dialects or their descendants. We might be using EuLisp.

Name: Anonymous 2009-08-12 20:13

>>1
I'm excited for it, though the code completion is still a bit off in the last VS2010 beta I tried, but it's getting better all the time.

Name: Anonymous 2009-08-12 20:31

>>20
Sure, Emacs Lisp and Scheme would have survived, but they're quite different languages than CL, or its predecessors. As a fundamental difference between CL, Elisp and Scheme:
Emacs Lisp's scope is dynamic, this poses many issues and is unclean for general purpose programming, also the language itself is mostly meant for scripting Emacs, and not to be a general purpose language.
Scheme's scope is lexical/static, which is very nice and encourages good programming style. Scheme doesn't have real macros(it does have syntax-case), but that is fine, as they're not hygienic, and we wouldn't want that in a language which was designed to be theoretically beautiful.

CL's scope is lexical by default, but dynamic scope can and is used when needed by the user. This solves many tricky practical problems. CL has real macros. CL has a large library and many supported types.

The goals of Elisp and Scheme differ from CL's goal:
Emacs Lisp's goal is to be a scripting language for Emacs.
Scheme's goal is to be be a good teaching language and to be theoretically beautiful ( this does not include the large body of libraries written by contributors and community standards ).
Common Lisp's goal is to be a practical multi-paradigm general purpose language. The initial goal was to unify various Lisp dialects so they could achieve better portability.

Name: Anonymous 2009-08-12 23:07

>>22
Scheme's scope is lexical/static, which is very nice and encourages good programming style. Scheme doesn't have real macros(it does have syntax-case), but that is fine, as they're not hygienic, and we wouldn't want that in a language which was designed to be theoretically beautiful.
http://www.ibm.com/developerworks/linux/library/l-metaprog2.html

Name: Anonymous 2009-08-12 23:26

>>23
define-syntax/syntax-case are macro systems, but they're not the same as what people consider to be ``real macros''. Real macros are those macros where you take user input as quoted/unevaluated, and then using the full power of your language process those parameter and generate a new piece of code. Scheme does not have such kinds of macros due to hygiene reasons, such as variable capture issues. Such macros have existed even in the earliest lisps as FEXPRs, and later on as DEFMACRO's. They are trivial to implement, so a lot of Scheme implementations do provide them, however they are not accepted as part of the language. It's also trivial to define a metacircular evaluator which implmenets real macros : if the car of the expression evaluates to a macro function, call it with the parameters given (quoted/unevaluated), and then evaluate the resulting expression.

Name: Anonymous 2009-08-13 0:01

datum->syntax

Name: Anonymous 2009-08-13 0:03

>>25
Your argument is invalid because you know Scheme.

Name: Anonymous 2009-08-13 1:43

>>26
Your comment is invalid because his food gave me the shits

Name: Anonymous 2009-08-13 2:24

>>22
Maybe you don't like them, but they certainly exist and are fine Lisps. And I don't think you're making the argument that without CL, all other Lisps but those two would have vanished, so that's beside the point to begin with.

Name: Anonymous 2009-08-13 2:40

When did this Ephsharp thread turn into a Lisp thread?

Name: Anonymous 2009-08-13 2:42

>>28
I never said I don't like them, I think they're fine Lisps indeed, but I also think they're quite different Lisps than CL, and that it would have been a shame if CL wouldn't exist today. Maybe if CL wouldn't have been standardized, we'd be seeing people program in ZetaLisp and the like, or maybe they would have died... History could have taken many different courses. Prior to CL, there were some efforts to make a common subset of portable Lisp, but they were much tinier than CL.

Name: Anonymous 2009-08-13 8:35

>>12
Maybe F# will introduce some Windows programmers to programming
Fixed that for you, buddy!!

Name: Anonymous 2009-08-13 11:49

>>32
UTERUS GET

Name: Anonymous 2010-12-22 5:40

Name: Anonymous 2012-03-06 15:37

Ovaries
Novaries

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