[Cryptography] Languages, languages (was Re: Swift and cryptography)

Phillip Hallam-Baker phill at hallambaker.com
Wed Jun 11 15:47:24 EDT 2014


On Wed, Jun 11, 2014 at 11:09 AM, Perry E. Metzger <perry at piermont.com>
wrote:
> On Wed, 11 Jun 2014 08:23:06 -0400 Phillip Hallam-Baker
> <phill at hallambaker.com> wrote:
>> This is of course what the functional language advocates claim they
>> do but I don't see that they succeed. All they have is a different
>> model of computing that is closer to one particular set of problems.
>
> I'm not sure that's particularly true. There are disadvantages to
> functional programming -- it is generally "further from the machine"
> and doesn't give you much control over memory management, and thus
> more difficult to do things like producing truly efficient OS kernels
> and such, but for most uses it is no more or less a reasonable way of
> thinking about problems than most other programming paradigms. If
> efficiency isn't an issue, functional usually wins, and often even if
> it is an issue.

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:

 Protocol Goedel.HTTP HTTP

Structure Common
String Content_Type
Integer Content_Length
DateTime Date

Structure Request
Struct RequestLine Line
Inherits Common
Struct QTag Accept
Multiple
String Authorization
Multiple
String Cache_Control
String Connection
Struct HostSpecification Host
String Referer
String TE
String User_Agent

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.

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.


> It is commonly believed that array bounds checks are the only or
> "main" issue with C. They aren't. C has hundreds of ways for a
> programmer to hang themselves.

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.

I am currently unwinding some code that was written expecting long == Int64
which would be the logical thing to do.

Rather more oddly, on a 64 bit machine size_t is defined as unsigned int!


> Consider, for example, what happens
> when you accidentally capture the address of a local variable past
> function exit, or what happens when you pass the wrong type to a
> varargs function, or when you invoke signed overflow and the compiler
> (quite rightfully) optimizes it out, or when a programmer depends
> accidentally on the order of invocation of parameters to a function
> call and the optimizer changes its mind one day.

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.




> If the language manual doesn't tell you all you need to know about how
> a program will behave, a programmer's life gets "interesting", and it
> is surprisingly easy even for the most skilled programmers to get into
> trouble with C.
>
>> Unfortunately what it does not do is to provide a drop in
>> replacement for C.
>
> That's what my own research work has been on for some time now. You
> need an unusual design for that, one that one would normally not
> select if you were designing afresh. Unfortunately I'm working alone
> and have no particular expectation of producing a usable product for
> non-academic purposes any time soon.

But will it be C with added bits or C with stupidity stripped out?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140611/317787bd/attachment.html>


More information about the cryptography mailing list