|
Hi.
F# is a new language or Microsoft just wanted develop it ?
|
|
|
|
|
here is everything you need to know about F#[^]
Yusuf
Oh didn't you notice, analogous to square roots, they recently introduced rectangular, circular, and diamond roots to determine the size of the corresponding shapes when given the area. Luc Pattyn[^]
|
|
|
|
|
I scanned it. But I couldn't find when F# has been made ?
I want the year of F# birth !
|
|
|
|
|
It was created within the last 4 years, but borrowed heavily from OCaml and Haskell.
Religiously blogging on the intarwebs since the early 21st century: Kineti L'Tziyon
Judah Himango
|
|
|
|
|
I think you should start taking it more seriously if and when an F# forum appears on CodeProject 
IMO it looks like Microsoft are trying to replace the C# language with the VB language (which is clearly for people with no logical sense who want to be programmers - which shouldnt happen)
Again, this is my opinion and not fact!
Life goes very fast. Tomorrow, today is already yesterday.
|
|
|
|
|
musefan wrote: IMO it looks like Microsoft are trying to replace the C# language with the VB language (which is clearly for people with no logical sense who want to be programmers - which shouldnt happen)
What make you say so terrible things? I'd like to believe it's a joke, but today isn't 1st of April  .
|
|
|
|
|
If you look at the new C# 4.0 language specifications, including the dynamic keyword (Variant) and optional parameters
|
|
|
|
|
Well, dynamics are part of DLR (or rather, will be), I actually look up for possiblity to interop with dynamic languages easy way.
Optional parameters are actually part of C++, plus they make COM easier in some situations. So I rather hope that all those feature will just make c# more convienent, and not more "VB style". Anyway, we are making offtopic here, but this discussion would be / is interesting .
|
|
|
|
|
I'm trying to think of where to post a new topic now, but the problem with dynamic (and Variant) is that it doesn't just defer compiler type-checking, it removes it. Method names are bound at runtime, and this encourages bad programming practices. Optional parameters is (are?) a little odd because we have function overloading for this reason. However, I see why its good to support them for COM interop purposes
|
|
|
|
|
Computafreak wrote: Optional parameters is (are?) a little odd because we have function overloading for this reason.
Well, I think Optional parameters is very easier than function overloading !
Isn't it ?
|
|
|
|
|
It's less code, but difficult in the long run. Example:
void ExampleMethod(int parOne, double parTwo = 3)
{
}
void ExampleMethod(int parOne)
{
}
Which method gets called?
|
|
|
|
|
I think dynamic is like var. You should not use it everywhere in your code, just because you can. Having dynamic types is great, when they allow you to access dynamic languages, this means you can easily interop with python as a script/macro language for you apps. Other then that, I'm going to use "casual", static types. I just hope that C# developers will give us new features, but won't force us to you them by removing some "old" ones.
|
|
|
|
|
I agree; it has the potential to be very useful. Incidentally, dynamic types are determined at runtime. var types are determined at compile time. However, you can see matter from the point of view of the original comment - C# and VB appear to be merging (VB# ?)
|
|
|
|
|
Of course you are right that dynamic and var are totally different things, but both are introduced in c# to handle some things (for var it would be anonymous types and useful inferring when using LINQ), and when I see code full of var x = 5; var y = FooFunc(); etc, I'm lost, just like if someone would put dynamic y = FooFunc(); everywhere (which btw would be much slower then using var ). I hope that, if there is some merging going on behinf our back, C# will remain C-like language, especially that I still have to use c++/c often.
|
|
|
|
|
I agree. It's difficult to read, and unsafe. However, it has its uses. I'm with you on the C-like language though. From a certain viewpoint (i.e. mine), it is beyond just machine code and becomes a work of beautiful art
|
|
|
|
|
Computafreak wrote: From a certain viewpoint (i.e. mine), it is beyond just machine code and becomes a work of beautiful art
True, True...
|
|
|
|
|
Well, the primary intent is to enable interfacing with dynamic languages like Python and Ruby, along with COM interop (IDispatch).
The CLR itself stays type safe, so for .NET types atleast, I'd imagine that runtime type checking would still happen.
|
|
|
|
|
1) How can we apply cosine transformation on color images using vb.net or c#
2) How to apply diffie hellman key exchange algorithm on images for encrypting it with a text message
|
|
|
|
|
For example by coding it yourself. Or by saving image as JPEG, which relies on Cosine transformation, but that's not what you have in mind propably .
|
|
|
|
|
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
So, as we all know, trying to access a control on any thread other than the one that created it is very bad. This tends to lead to applications which have just one GUI thread with background threads doing 'work' and 'Invoking' their changes back to the main thread.
Not content with this, I'm playing around trying to get two forms to display each running seperate gui threads. Easy enough it seems, just put the Application.Run() for each in seperate threads. Now, should the GUI thread in one form lock up the other can continue running freely. This works and I'm happy and its virtue in a system which is full of windows all over the shop is easy to see.
The next stage would be to do this in an MDI type set up so that the child windows each have their own thread. Anyone see any issue with this? I'm concerned by the fact that each child form belongs to the parent 'mainframe' window as we used to call them, but in principle can't see any fault with it.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: Anyone see any issue with this?
Yep. Each form is told WHEN to render by the MdiClient control, running on the "GUI Thread" in the MdiParent. So how is the MdiClient going to jump the thread boundry without ever leaving the GUI thread??
|
|
|
|
|
That's a good question. It can't be done it seems, I think all the MDI child windows share the same message pump. Oh well, there we go. Thanks for the reply.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: I think all the MDI child windows share the same message pump.
Yes, they do.
|
|
|
|
|
Hi,
I'm just about to start on a new project and while I've written stuff that uses web services, I'm thinking I should probably use a different approach.
Can anyone point me in the direction of when to use web services and when not to?
Also, if I don't want to use a web service (I need high perforamance), what do I do? Should I write a load of DLLs or Windows services? Does .NET offer me a component-based system I could use instead?
My application will have a SQL database which will contain my own entities. The system must be able to create, read, update and delete the entities via a published interface that other applications can use.
Should I present the interface via web service, a DLL or a Windows Service?
All opinions welcome and thanks for looking
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
