<div dir="ltr"><br><br>On Wed, Jun 11, 2014 at 11:09 AM, Perry E. Metzger <<a href="mailto:perry@piermont.com">perry@piermont.com</a>> wrote:<br>> On Wed, 11 Jun 2014 08:23:06 -0400 Phillip Hallam-Baker<br>> <<a href="mailto:phill@hallambaker.com">phill@hallambaker.com</a>> wrote:<br>
>> This is of course what the functional language advocates claim they<br>>> do but I don't see that they succeed. All they have is a different<br>>> model of computing that is closer to one particular set of problems.<br>
><br>> I'm not sure that's particularly true. There are disadvantages to<br>> functional programming -- it is generally "further from the machine"<br>> and doesn't give you much control over memory management, and thus<br>
> more difficult to do things like producing truly efficient OS kernels<br>> and such, but for most uses it is no more or less a reasonable way of<br>> thinking about problems than most other programming paradigms. If<br>
> efficiency isn't an issue, functional usually wins, and often even if<br>> it is an issue.<br><br>By close to the problem I mean something like this code I wrote when my end to end email scheme needed a http client I can trust:<div>
<br></div><div> Protocol Goedel.HTTP HTTP</div><div><br></div><div><span class="" style="white-space:pre"> </span>Structure Common</div><div><span class="" style="white-space:pre"> </span>String<span class="" style="white-space:pre"> </span>Content_Type</div>
<div><span class="" style="white-space:pre"> </span>Integer<span class="" style="white-space:pre"> </span>Content_Length</div><div><span class="" style="white-space:pre"> </span>DateTime<span class="" style="white-space:pre"> </span>Date</div>
<div><br></div><div><span class="" style="white-space:pre"> </span>Structure Request</div><div><span class="" style="white-space:pre"> </span>Struct RequestLine<span class="" style="white-space:pre"> </span>Line</div><div>
<span class="" style="white-space:pre"> </span>Inherits<span class="" style="white-space:pre"> </span>Common</div><div><span class="" style="white-space:pre"> </span>Struct QTag<span class="" style="white-space:pre"> </span>Accept</div>
<div><span class="" style="white-space:pre"> </span>Multiple</div><div><span class="" style="white-space:pre"> </span>String<span class="" style="white-space:pre"> </span>Authorization</div><div><span class="" style="white-space:pre"> </span>Multiple</div>
<div><span class="" style="white-space:pre"> </span>String<span class="" style="white-space:pre"> </span>Cache_Control</div><div><span class="" style="white-space:pre"> </span>String<span class="" style="white-space:pre"> </span>Connection</div>
<div><span class="" style="white-space:pre"> </span>Struct<span class="" style="white-space:pre"> </span>HostSpecification<span class="" style="white-space:pre"> </span>Host</div><div><span class="" style="white-space:pre"> </span>String<span class="" style="white-space:pre"> </span>Referer</div>
<div><span class="" style="white-space:pre"> </span>String<span class="" style="white-space:pre"> </span>TE</div><div><span class="" style="white-space:pre"> </span>String<span class="" style="white-space:pre"> </span>User_Agent</div>
<div><br>That code does depend on some additional FSR code that does the RFC822 funky parse stuff. But if they add a header line to the spec and it does not introduce yet more wierdness, just declare it there and the handler code can access the variable.</div>
<div><br></div><div>The way I write user interface code is essentially the same: write out the abstract code and let the UI compiler generate code for X-Windows or command line or whatever.</div><div><br><br>> It is commonly believed that array bounds checks are the only or<br>
> "main" issue with C. They aren't. C has hundreds of ways for a<br>> programmer to hang themselves. </div><div><br></div><div>C provides you with more ways to shoot yourself in the foot than anyone could ever want or need. You have everything from pointy sticks to RPGs.</div>
<div><br></div><div>I am currently unwinding some code that was written expecting long == Int64 which would be the logical thing to do.</div><div><br></div><div>Rather more oddly, on a 64 bit machine size_t is defined as unsigned int!</div>
<div><br></div><div><br></div><div>> Consider, for example, what happens<br>> when you accidentally capture the address of a local variable past<br>> function exit, or what happens when you pass the wrong type to a<br>
> varargs function, or when you invoke signed overflow and the compiler<br>> (quite rightfully) optimizes it out, or when a programmer depends<br>> accidentally on the order of invocation of parameters to a function<br>
> call and the optimizer changes its mind one day.<br><br>I find that I can code art roughly the same speed in C or C#. Except that is when I am spending a week adding features to C that I need like memory management or the like or trying to resist doing the job properly and working round C's lossage.<br>
<br><br><br><br>> If the language manual doesn't tell you all you need to know about how<br>> a program will behave, a programmer's life gets "interesting", and it<br>> is surprisingly easy even for the most skilled programmers to get into<br>
> trouble with C.<br>><br>>> Unfortunately what it does not do is to provide a drop in<br>>> replacement for C.<br>><br>> That's what my own research work has been on for some time now. You<br>
> need an unusual design for that, one that one would normally not<br>> select if you were designing afresh. Unfortunately I'm working alone<br>> and have no particular expectation of producing a usable product for<br>
> non-academic purposes any time soon.<br><br>But will it be C with added bits or C with stupidity stripped out?</div><div><br></div><div>What I want is a language I can use to write code modules that don't require a custom runtime and can run native on any platform. <br>
<br></div></div>