Hello World
Spiga

F#与ASP.NET(2):使用F#实现基于事件的异步模式

2010-04-05 20:37 by 老赵, 2951 visits

上一篇文章中,我们的简单讨论了.NET中两种异步模型以及它们在异常处理上的区别,并且简单观察了ASP.NET MVC 2中异步Action的编写方式。从中我们得知,ASP.NET MVC 2的异步Action并非使用了传统基于Begin/End的异步编程模型,而是另一种基于事件的异步模式。此外,ASP.NET MVC 2对于这种异步模式提供了必要的支持,使此方面的程序设计变得相对简单一些。但是,简单的原因主要还是在于已经由其他组件提供了良好的,基于事件的异步模式。那么现在我们就来看看一般我们应该如何来实现这样的功能,以及F#是如何美化我们的生活的吧。

异步数据传输

我们为什么要异步,主要目的之一还是提高I/O操作的伸缩性。I/O操作主要是I/O设备的事情,这些设备在好好工作的时候,是不需要系统花心思进行照看的,它们只要能够在完成指定工作后通知系统就可以了。这也是异步I/O高效的原理,因为它将程序从等待I/O完成的苦闷中解脱出来,这对用户或是系统来说都是一件绝好的事情。

那么说到I/O操作,最典型的场景之一便是数据传输了。比如有两个数据流streamIn和streamOut,我们需要异步地从streamIn中读取数据,并异步地写入到streamOut中。在这个过程中,我们使用一个相对较小的byte数组作为缓存空间,这样程序在进行数据传输时便不会占用太多内存。那么,如果现在需要您编写一个组件完成这样的数据传输工作,并使用标准的基于事件的异步模式释放出来,您会怎么做?

再啰嗦一次,基于事件的异步模式,要求在任务完成时使用事件进行提示。同时在出错的时候将异常对象保存在事件的参数中。现在我已经帮您写好了这样的事件参数:

public class CompletedEventArgs : EventArgs
{
    public CompletedEventArgs(Exception ex)
    {
        this.Error = ex;
    }

    public Exception Error { get; private set; }
}

那么接下来的工作就交给您了,加油!

嗯?那么快就写完啦?再想想?如果真确定了,就展开下面的代码对比一下吧:

展开代码
隐藏代码

public class AsyncTransfer
{
    private Stream m_streamIn;
    private Stream m_streamOut;

    public AsyncTransfer(Stream streamIn, Stream streamOut)
    {
        this.m_streamIn = streamIn;
        this.m_streamOut = streamOut;
    }

    public void StartAsync()
    {
        byte[] buffer = new byte[1024];

        this.m_streamIn.BeginRead(
            buffer, 0, buffer.Length,
            this.EndReadInputStreamCallback, buffer);
    }

    private void EndReadInputStreamCallback(IAsyncResult ar)
    {
        var buffer = (byte[])ar.AsyncState;
        int lengthRead;

        try
        {
            lengthRead = this.m_streamIn.EndRead(ar);
        }
        catch (Exception ex)
        {
            this.OnCompleted(ex);
            return;
        }

        if (lengthRead <= 0)
        {
            this.OnCompleted(null);
        }
        else
        {
            try
            {
                this.m_streamOut.BeginWrite(
                    buffer, 0, lengthRead,
                    this.EndWriteOutputStreamCallback, buffer);
            }
            catch (Exception ex)
            {
                this.OnCompleted(ex);
            }
        }
    }

    private void EndWriteOutputStreamCallback(IAsyncResult ar)
    {
        try
        {
            this.m_streamOut.EndWrite(ar);

            var buffer = (byte[])ar.AsyncState;
            this.m_streamIn.BeginRead(
                buffer, 0, buffer.Length,
                this.EndReadInputStreamCallback, buffer);
        }
        catch (Exception ex)
        {
            this.OnCompleted(ex);
        }
    }

    private void OnCompleted(Exception ex)
    {
        var handler = this.Completed;
        if (handler != null)
        {
            handler(this, new CompletedEventArgs(ex));
        }
    }

    public event EventHandler<CompletedEventArgs> Completed;
}

是不是很复杂的样子?

编写异步程序,基本则意味着要将原本同步的调用拆成两段:发起及回调,这样便让上下文状态的保存便的困难起来。幸运的是,C#这门语言提供了方便好用的匿名函数语法,这对于编写一个回调函数来说已经非常容易了。但是,如果需要真正写一个稳定、安全的异步程序,需要做的事情还有很多。例如,一次异步操作结束之后会执行一个回调函数,那么如果在这个回调函数中抛出了一个异常那该怎么办?如果不正确处理这个异常,轻则造成资源泄露,重则造成进程退出。因此在每个回调函数中,您会发现try...catch块是必不可少的——甚至还需要两段。

更复杂的可能还是在于逻辑控制上。这样一个数据传输操作很显然需要循环——读一段,写一段。但是由于需要编写成二段式的异步调用,因此程序的逻辑会被拆得七零八落,我们没法使用一个while块包围整段逻辑。

编写一个异步程序本来就是那么复杂。

编写简单的代理

嗯,我们继续。现在我们已经有了一个异步传输数据的组件,就用它来做一些有趣的事情吧。例如,我们可以在ASP.NET应用程序中建立一个简单的代理,即给定一个URL,在服务器端发起这样一个请求,并将这个URL的数据传输到客户端来。简单起见,除了进行数据传输之外,我们只需要简单地输出Content Type头信息即可。

写好了吗?我也写了一个,仅供参考:

展开代码
隐藏代码

public class AsyncWebTransfer
{
    private WebRequest m_request;
    private WebResponse m_response;

    private HttpContextBase m_context;
    private string m_url;

    public AsyncWebTransfer(HttpContextBase context, string url)
    {
        this.m_context = context;
        this.m_url = url;
    }

    public void StartAsync()
    {
        this.m_request = WebRequest.Create(this.m_url);
        this.m_request.BeginGetResponse(this.EndGetResponseCallback, null);
    }

    private void EndGetResponseCallback(IAsyncResult ar)
    {
        try
        {
            this.m_response = this.m_request.EndGetResponse(ar);
            this.m_context.Response.ContentType = this.m_response.ContentType;

            var streamIn = this.m_response.GetResponseStream();
            var streamOut = this.m_context.Response.OutputStream;

            var transfer = new AsyncTransfer(streamIn, streamOut);
            transfer.Completed += (sender, args) => this.OnCompleted(args.Error);
            transfer.StartAsync();
        }
        catch(Exception ex)
        {
            this.OnCompleted(ex);
        }
    }

    private void OnCompleted(Exception ex)
    {
        if (this.m_response != null)
        {
            this.m_response.Close();
            this.m_response = null;
        }

        var handler = this.Completed;
        if (handler != null)
        {
            handler(this, new CompletedEventArgs(ex));
        }
    }

    public event EventHandler<CompletedEventArgs> Completed;
}

如果说之前的AsyncTransfer类是基于“Begin/End异步编程模型”实现的基于事件的异步模式,那么AsyncWebTransfer便是基于“基于事件的异步模式”实现的基于事件的异步模式了。嗯,似乎有点绕口,不过我相信这段代码对您来说还是不难理解的。

使用F#完成异步工作

好吧,我承认,前面的代码我也觉得很复杂,很难写。事实上我已经很久没有写过这样的代码了,咎其原因还是被F#给宠坏了。尝试了C# 2.0之后我便抛弃了Java语言,熟悉了C# 3.0之后我用C# 2.0就快写不了程序了,而使用了F#进行异步编程之后,我就再也没有使用C#写过异步操作了。

那么我们就来看看F#是如何进行异步数据传输的吧:

let rec transferAsync (streamIn: Stream) (streamOut: Stream) buffer = 
    async {
        let! lengthRead = streamIn.AsyncRead(buffer, 0, buffer.Length)
        if lengthRead > 0 then
            do! streamOut.AsyncWrite(buffer, 0, lengthRead)
            do! transferAsync streamIn streamOut buffer
    }

喔喔,上面的代码利用了尾递归进行不断地数据传输,我们也可以使用传统的while循环来实现这个功能(关于ref的作用可参考这篇文章):

let transferImperativelyAsync (streamIn: Stream) (streamOut: Stream) buffer = 
    async {
        let hasData = ref true
        while (hasData.Value) do
            let! lengthRead = streamIn.AsyncRead(buffer, 0, buffer.Length)
            if lengthRead > 0 then
                do! streamOut.AsyncWrite(buffer, 0, lengthRead)
            else
                hasData := false
    }

有了transferAsync函数,编写一个资源请求的代理也是几分钟的事情:

let webTransferAsync (context: HttpContextBase) (url: string) =
    async {
        let request = WebRequest.Create(url)
        use! response = request.GetResponseAsync()
        context.Response.ContentType <- response.ContentType
        
        let streamIn = response.GetResponseStream()
        let streamOut = context.Response.OutputStream
        let buffer = Array.zeroCreate 1024
        do! transferAsync streamIn streamOut buffer
    }

没错,就是这么简单,这就是F#中编写异步任务方式(关于这方面的更多细节,您可以阅读F#的主要设计者Don Syme所撰写的一系列文章)。在执行这两个函数时(当然确切地说,是执行这两个函数所生成的异步工作流),便会在出现“感叹号”的操作之处自动分成二段式的异步调用,但是在程序的写法上和同步代码可谓毫无二致。

使用F#实现基于事件的异步模式

当然,光有上面的代码还不够,因为这样的代码无法交给C#代码来使用,我们还需要将它们封装成基于事件的异步模式。不过这也非常简单,使用一个通用的抽象基类即可:

[<AbstractClass>]
type AsyncWorker(asyncWork: Async) = 
    
    let completed = new Event()

    [<CLIEvent>]
    member e.Completed = completed.Publish

    member e.StartAsync() = 
        Async.StartWithContinuations
            (asyncWork,
             (fun _ -> completed.Trigger(new CompletedEventArgs(null))),
             (fun ex -> completed.Trigger(new CompletedEventArgs(ex))),
             (fun ex -> ex |> ignore))

在使用F#进行面向对象开发时,由于不需要C#的架子代码,它实现相同的结构一般都会显得紧凑不少(不过在我看来,C#在进行一般的命令式编程时还是比F#来的方便一些)。在StartAsync方法中,我们使用Async.StartWithContinuations发起一个异步工作流,而这个异步工作流便是从构造函数中传入的具体任务。StartWithContinuations方法的后三个参数分别是成功时的回调,失败后的回调,以及任务取消后的回调(我们并不需要这个回调,随意提供一个即可)。

您可能会说,难道F#中不需要异常处理,不需要资源释放吗?当然需要。只不过:1) 异常处理已经由StartWithContinuations统一完成了,我们只要按照“同步式”代码的写法编写逻辑,也就是说,从语义上说您可以看作存在一个巨大的try...catch围绕着整段代码。2) 而对于资源释放来说,您可以发现在webTransferAsync方法中有一个use!指令,这便是告诉F#的异步框架,在整个异步工作流结束之后需要调用这个资源的Dispose方法——没错,您可以把它看作是一种能在异步环境下工作的C# using关键字。

有了AsyncWorker类之后,AsyncTransfer和WebAsyncTransfer类也可轻易实现了:

type AsyncTransfer(streamIn: Stream, streamOut: Stream) = 
    inherit AsyncWorker(
        Transfer.transferAsync streamIn streamOut (Array.zeroCreate 1024))

type AsyncWebTransfer(context: HttpContextBase, url: string) =
    inherit AsyncWorker(Transfer.webTransferAsync context url)

最后,只要在ASP.NET MVC中使用即可:

public void LoadFsAsync(string url)
{
    AsyncManager.OutstandingOperations.Increment();
    var transfer = new FSharpAsync.AsyncWebTransfer(HttpContext, url);

    transfer.Completed += (sender, args) =>
        AsyncManager.OutstandingOperations.Decrement();

    transfer.StartAsync();
}

public ActionResult LoadFsCompleted()
{
    return new EmptyResult();
}

事实上,在ImageController中我还提供了一个LoadAsync及对应的LoadCompleted方法,它们使用的是利用C#实现的AsyncWebTransfer类。猜猜看这样的代码长成什么样?其实只是将上面的AsyncWebTransfer的命名空间改成CSharpAsync而已——F#与其它.NET代码是真正做到无缝集成的。

总结

这便是F#的伟大之处。时常有朋友会问我为什么对F#有那么大的兴趣,我想,如果借助F#可以用十分之一的时间,十分之一的代码行数,写出执行效果相同,但可维护性高出好几倍的程序来——我为什么会不感兴趣呢?

您可以在这里访问到本文的示例代码,其中我在WebApp项目中实现了简单的入口页面,您访问“/image”便会出现两个文本框,您填入一个URL(例如某幅图片)并提交,它会将URL提交至“/image/load”或“/image/loadfs”中,它们分别使用了C#和F#实现的AsyncWebTransfer类,从效果上说两者完全相同。

相关文章

Creative Commons License

本文基于署名 2.5 中国大陆许可协议发布,欢迎转载,演绎或用于商业目的,但是必须保留本文的署名赵劼(包含链接),具体操作方式可参考此处。如您有任何疑问或者授权方面的协商,请给我留言

Add your comment

18 条回复

  1. 李永京
    65.49.2.*
    链接

    李永京 2010-04-05 21:43:45

    老赵不容易啊,同步打理两博客~~下载看下实例......

  2. 老赵
    admin
    链接

    老赵 2010-04-05 22:01:18

    @李永京: 老赵不容易啊,同步打理两博客~~下载看下实例......

    不打理,随便贴一下,不回复不更新的。

    话说博客园访问量是这里的十倍,真是没意思啊。

  3. 克伟
    114.113.50.*
    链接

    克伟 2010-04-05 23:45:40

    呵呵,确实不容易

  4. 克伟
    114.113.50.*
    链接

    克伟 2010-04-05 23:48:07

    老赵你留言里面的照片年轻好多哈

  5. akeng
    220.169.105.*
    链接

    akeng 2010-04-05 23:56:40

    老赵,你这博客需要备案么?我也想开个博客。

  6. 老赵
    admin
    链接

    老赵 2010-04-06 01:30:58

    @akeng: 老赵,你这博客需要备案么?我也想开个博客。

    主机在国外,没法备案。

  7. 那啥
    111.193.11.*
    链接

    那啥 2010-04-09 01:04:51

    你的这个事例是完完全全的语法糖应用,甚至问题的产生也不过是因为你选用的异步API就是设计成这么使用的。而且这个语法糖是在其它语言中是可以用库和框架代替的。

    即便是同样的API,我可以用Waiter把异步Read伪装成阻塞的模式,然后仍旧用一个while搞定。(Write可以异步也可以不异步)

    我说的这个惯用法(其整体或者细节部分)很容易就可以封装起来重用,所以你说的1/10时间/代码/精力,并不成立。事实上F#最差劲的地方就是晦涩的语法糖太多。(相对于Java的该有的语法糖太少)。

    另外就是,异步任务的实质如果就是二段式的,那么实际上这一实质应该被充分的表现,而不是隐藏。所以所谓的“七零八落”并不一定是坏事。

    另外,我个人认为,把这个博客作为主力(对你本人而言)不是一个很好选择,这会使得除了比较关注你的那些人外的其它阅读者徒增一个麻烦,逐渐就和你减少了交流。

  8. 那啥
    111.193.11.*
    链接

    那啥 2010-04-09 03:07:01

    另外对于大并发需求,语言所带库及其运行时下实现(或者直接自带的)Waiter还不够轻量级,比如会真正阻塞当前线程(这是一种资源占用),那么还可以做一个“执行序列管理器”:

    manager.while(
        () => 条件,
        () => { step1 },
        () => { step2 }, ....)
    

    var x = manager.seq(
        () => { step1 },
        () => { step2; if ... then x(); }
    );
    x();
    

    当然,C#的那种异步读写要被重新包装成能配合manager的工作的。反观F#的版本却无需如此。但若规定F#必须使用BeginXXX(callback)的接口,针对异步的语法糖也就发挥不了什么作用了;从这一点可以看出,即便异步编程的自身特点相对突出,在这里语法糖并不是提升工作效率的关键。

    通用语言的目标是能对各种有特点的任务提供良好的支持,如果针对需求一种一种的扩展下去,最终这个语言就会不堪重负了。考虑到F#的目标并不是作为多语言编程时特别擅长于某一类任务的半领域语言,它已经拥有了太多的糖。

    与其如此,不如在更根本性的设计上着手,比如提供更加丰富的元编程支持,让更多的语言元素作为一个一个的单位可以被静态的和动态的处理和使用,就能让使用者记忆和学习更少的东西,却在不同特点的任务中都能找到合适且相对自然的表示方法。

  9. 老赵
    admin
    链接

    老赵 2010-04-09 09:21:54

    @那啥

    谢谢回复,我补充一点我的看法。

    这个“语法糖”可以用什么框架、库代替呢?不要举LISP或Haskell作为例子,就说C#,Java,Ruby等等吧。大并发下的异步I/O是必须的,例如你用C#实现一个AsyncManager,构造一个While它的确可以实现(真可以吗?事实上我还没有想到可以怎么写,真的),但是如果还有其他需求呢,比如if,for,以及异步模块间的组合呢?代码就会变得臃肿丑陋。而在F#里的做法是最流畅的写法,然后由编译器生成可能和C#类库较为接近的,容易表示的语法。事实上在F#里的async { ... }的确就是CSP的语法糖,但是说到底什么语言都是汇编的语法糖,不是吗?关键其实就是看最终能否带来开发方式上的改变。F#的确做到了。

    为什么要逼F#使用Begin/End的语法呢?在F#里Begin/End语法可以被很方便的组合成一个async { ... }异步模块(使用Async.FromBeginEnd就可以了),事实上如WebRequest的GetResponseAsync便不是自带的,而是我扩展的。

    其实在所谓“根本性”方面下手,让使用者记忆和学习的更少也是需要权衡的。比如LISP,“根本性”方面做的很好,连数据结构也只有“表”和“院子”,其他的通通靠组合而来。但是它省去了记忆和学习的成本吗?它让开发变得容易了吗?没有。因为很多特性在编译器角度很容易通过直接提供一个primitive来实现的东西,如果交给类库或者需要组合的语法特性,它使用也是不易了。

    “抽象”的误区之一便是“过度抽象”,目前我觉得F#做的不错。

  10. 那啥
    111.193.11.*
    链接

    那啥 2010-04-09 21:04:01

    这个跟抽象其实关系不大,而是语言设计时非常具体的取向问题。

    Lisp也好,Java也好,他们之所以在不同程度上让人不爽,关键在于他们没有做好对通用设施的支持。这造成比如Lisp难于阅读,Java废话太多。

    而类似于async这样的语法糖,却是针对特殊任务的。所以这两者没有可比性。不赞成在通用语言中增加这类语法糖,并不代表赞成Lisp或者Java的语言设计选择。

    具体到这个例子,我的意思是说,如果C#带有这样一个manager和一整套配合这个manager完成各种任务的库(包括异步读写),那么在表达方式上的差距并未大到不可接受的地步。(F#的说到底也是有人实现的,而且无论在哪个语言里,相同行为、相似水平的库也仅需实现一次)

    就这个语法糖本身来说并没有太大问题;关键是从通用语言这一目的来看,F#的针对不同的特殊任务的语法糖就有点多了。C++也是因为提供的东西太多而遭人诟病的,但相对而言,C++的每次增容都很好的遵循了仅关注通用设施的原则。(刨除特定编译器的扩展)

    当然,这只是我个人的看法。不同背景的人被不同的需求驱使,每个人都会有所偏好。其实有一个路子可以调和这种矛盾:一个语言的通用版本去除对特定任务的支持,但是可以发展出不同偏好的子分支,类似于Stackless Python这样。

    作为通用语言,其实C是一个很好的例子,虽然它年代久远,但它令人惊异的设计成了,“恰恰刚好不够”,这是它为什么能历久不衰的原因;而不是因为“底层需要”。

  11. 老赵
    admin
    链接

    老赵 2010-04-09 23:51:05

    @那啥

    F#中的async可不是语法糖,它是利用了F#中叫做Workflow Builder特性而开发出的一套类库,您可以认为是利用了Monad。事实上您在F#中可以还可以看到seq {...}等等,其实它和async {...}都是利用了相同语言功能的类库而已。我们也可以再实现一个xyz {...}或是其他什么的功能。

    至于你说C#的Manager,说实话,我十分了解C#,也用它的特性设计过很多API,但是我真的不知道该如何设计出F#的这类能力,它和F#的表达能力的确“大到不可接受的程度”,这也就是很典型的类库与语言原语的差距。如果您感兴趣的话,我们不妨可以更继续探讨一下这方面,例如您如果觉得C#也可以做到的话,要不给一系列接口定义和使用简介吧(不需要具体实现内部),这样究竟能否做到也就一目了然了。

    至于你说的C语言,在我看来它并非是说明现在这问题的好例子,从语言角度来说它并非是个多么优秀的语言。C语言的成功,完全是由于,我们永远需要一种语言,它可以和冯诺依曼机的概念尽可能的对应,这样才能得到最好的性能。抽象能力一高,势必无法确保在任何时候满足性能需求。

    因此,例如Objective-C这样基于C语言发展的语言,由于它的目标定位已经是应用开发,因此在我看来它也已经是一门很平庸的语言了,不比Java强到哪儿去──即便它的语言能力是C的超集。由于最近遇到的果粉比较多,所以我也正打算关注Objective-C方面的问题,呵呵。

  12. 那啥
    111.193.11.*
    链接

    那啥 2010-04-10 03:12:15

    这么说F#现在的版本这个类别的关键字是可定制可扩展的? 那这个事情的意义就有些不同了 ^^ 不过若按有些人所言,高阶函数和对象也仅仅是糖豆,那么这种扩展又何尝不是呢?当然,采取这个视角,不同的高级语言往往也就成了不同的糖豆的集合。那么好不好吃、值不值得一吃仍旧是最重要的问题。

    不过C#也好其它语言也好,肯定可以在不扩展语法的情况下实现形式相似的使用方式(在这个例子中,是只使用很少的代码且能够把逻辑写在一起);尤其是配合元数据支持,这种工作会相对容易很多。不过我确实没有时间做一个清晰明了的设计,这得费咱好几袋烟的功夫。

    如果说简单讨论一下的话:Manager的对象以function为单位(对应于一个一个的代码片段)保存要干什么,这些代码片段和其它类型的对象共同提供如何干的信息。它提供的最基本的能力是根据所提供的信息执行这些以function为单位的代码段。(共用变量则使用语言自带的闭包就足够)

    比如异步读写的这个例子是如何运作的。用户必须使用新类型的对象,这里就好比F#中的类相比C#的中的类是经过重新设计的一样,我们要求这个新类型的对象必须知道、并使用manager对象。

    一个方法是实例化任何这类对象时(比如一个和Manager配合工作的Stream对象),传入manager实例;在这个新版Stream对象的实现中,假设我们是包装原来的C#接口,我们会在Callback中告诉manager执行序列中下一个function(代码片段)。

    同时,用户提供的function集合决定了Manager返回值所代表的粒度,用户也可以通过直接调用提供关于什么时候执行哪一个子集的信息。不过循环等逻辑在很多情况下是需要由Manager直接提供支持的,除非Manager具有动态分析IL的能力(虽然这也是可以实现的)。

    那么这种配合Manager的类,是必须手工包装或者重新设计的吗? 这个问题我倒是没有好好想。但是我相信若Begin/End这种惯用法的接口具有一定的共同性,我们完全可以做一个Manager.FromBeginEnd()的方法出来。尤其是像C#这样有着丰富元数据支持的语言,大不了就是反射/Emit的工作了。

    使用相同的形式,我想等价于任何xyz {...}这种扩展方式的非原生支持版本,也都是可以实现的。

    我的信心完全来自于所有.NET平台上的语言都是和IL对应的;然后,F#所做的工作,无外乎运行时/编译时两种。运行时的工作基本可以原样照搬,而编译时的工作可以转移到运行时(如果我们不喜欢编译时多一道预处理工序的话)。

    这样,真正的不同就仅仅在于这些东西是被语法所触发(F#),还是被一定规则的对象使用/方法调用所触发(库和框架)。

    当然你绝对可以设计出一个例子,在F#里很优雅,但是使用这个方案却会需要很多废话;所以问题在于这样的例子是不是很多。另外一个就是我们似乎还没有一个这样的方案的实做,自己来的话,恐怕要花费很大精力。

    关于C的判断,你的看法很传统。但是我可以反问你一句:难道“可以和冯诺依曼机的概念尽可能的对应”这个需求下,我们就做不出和C不一样的设计了吗?至少我自己寻得答案是否定的。比如D语言,或者有了move语义的C++(尤其是那些降低效率设施完全可以不用)。但事实是,相对多的人并没有强烈的感受到需要新的表达方式。

    C实际上可以大面积的覆盖面向对象、函数式等范式中所有最关键的概念。比如我们有函数指针,那么我们就有了委托,是不是匿名则相对不重要;我们也可以用各种方法,而不仅仅是被语言限制为虚表一种,来实现面向接口编程;等等。

    当然,C缺乏很多糖,比如跟匿名委托所需形式一块消失的闭包也挺让人难受的(我们总得在不必要的地方同时关注委托将要作用的变量),所以它是不够的,但是它的不够对于C的主要应用场合影响不大,所以是一种“刚好不够”。我并不是说干脆拿C做Web得了(虽然这一点也不难):当我们确实不需要关注内存管理之类的问题的时候,就如我前面所说,这一针对特殊任务的支持就应该被无情的砍掉;即便有时候用起来还挺方便的。

    我不是在给谁翻案,或者拒绝语言革新,而是表达这样一种观点:如无必要,勿增实体。在这里,实体就是你所说的更好的抽象手段,而在我个人的观点上,他们到底只是一些用得着的Features。那么必要性是不是已经跨过了一个限度,这个如何判定?我的看法是,对于一个通用语言来说,扩展的速度宁可慢,不要快;尤其是扩展仅针对某类特殊任务的情况下。

  13. 那啥
    111.193.11.*
    链接

    那啥 2010-04-10 03:26:40

    我知道了,你说的是这个东西:

    http://blogs.msdn.com/dsyme/archive/2007/09/22/some-details-on-f-computation-expressions-aka-monadic-or-workflow-syntax.aspx

    确实我对F#的认识仅仅是很久以前浅尝辄止,已经给忘了这是怎么回事了。

    感觉这个和我的思路有相似之处(只不准我自己的思路也是来自于类似的东西),不过通过语法给与了一个直接的支持,暂时不评价了,需要重新仔细的了解,惭愧。

  14. 老赵
    admin
    链接

    老赵 2010-04-10 12:00:52

    @那啥

    的确我们可以用C++和那些非高级特性来实现C的高效,但是这和C就没有太大差距的说。在我看来,人们的确很难在保证C的高效时再添加更多高级特性。GO可能算是一个尝试吧,它的基础功能在C的上加了些语法糖,开发时的确可以略微方便一点,编译器可以将其编译成最高效的代码。人们在权衡了效率,历史因素(如已有代码行数),开发效率的提高等方面后,还是觉得C也已经是个不错的选择了。

    您的看法也给了我不少启发,我很喜欢这样有质量的,包含每个人独特见解的评论,欢迎常来。:)

  15. 自由王者
    119.85.151.*
    链接

    自由王者 2010-04-12 21:04:18

    老赵,您好!您能不能一步一步地介绍F#啊,您写的文章太有深度了,实在看不懂!o(∩_∩)o

  16. rocky
    218.59.162.*
    链接

    rocky 2010-04-20 14:14:46

    同感,不过我还停留在c# 3.0

    好吧,我承认,前面的代码我也觉得很复杂,很难写。事实上我已经很久没有写过这样的代码了,咎其原因还是被F#给宠坏了。尝试了C# 2.0之后我便抛弃了Java语言,熟悉了C# 3.0之后我用C# 2.0就快写不了程序了,而使用了F#进行异步编程之后,我就再也没有使用C#写过异步操作了。

  17. 老赵
    admin
    链接

    老赵 2010-04-20 14:24:11

    @rocky

    F#对异步操作的支持的确令人惊艳。

  18. Alex
    182.149.70.*
    链接

    Alex 2012-02-08 11:01:10

    我一直停留在C#上。。。。。F#就小试了几下。还有待提高啊

发表回复

登录 / 登录并记住我 ,登陆后便可删除或修改已发表的评论 (请注意保留评论内容)

昵称:(必填)

邮箱:(必填,仅用于Gavatar

主页:(可选)

评论内容(大于5个字符):

  1. Your Name yyyy-MM-dd HH:mm:ss

使用Live Messenger联系我