Didier Verna wrote:

I'm more worried about the future of programming implementations myself.
Who's going to create the industrial-strength FPL implementations that
we're currently missing?

Jon Harrop wrote:

What, in your opinion, are the characteristics of these implementations?

My list includes:

* Creation of native-format executables requiring no linkables
or libraries unlikely to be found on end-user systems
(user expectation, deliverability)

* Profiling and profile-based optimization tools.

* Code analysis tools integrated with source control
and identity-based package management and keyword
control. ie, when setting up source control, the lead
engineer should be able to specify...

Ray Dillinger sonic.net> writes:

I've seen some papers mentioning termination proofs but the methods
described didn't seem of much use for air traffic control. For
example, David Turner's "Total Functional Programming" describes a
language where all programs terminate, but the running time can be
anything describable in Peano arithmetic, i.e. it could be a tower of
exponentials of arbitrary height. So proofs of termination without
practical complexity bounds seem not so useful.

Ray Dillinger wrote:

You had a list, so let me ask this:
Who's going to create the tools that you said you are missing if it's
not you? You're not waiting for kids/programmers of the future to do it
for you, right?

Ray Dillinger wrote:

I would like a cross-platform open source common language run-time with good
support for functional programming (e.g. tail calls and fast allocation)
and commerce (so I can sell shared run-time DLLs to its users).

That is essentially the .NET CLR but open source and cross platform.

Yes.

Abdulaziz Ghuloum wrote:

Heh. got me in one.

Yes, I have a lisp implementation. No, it's not finished yet.
Yes, I'm planning and doing the stuff on my list with it and was
hoping to see what other people's lists include.

The ideas involved have been evolving for a long time, starting with
some theoretical frustration with the absence of callable objects
that are both first-class (like functions in Lispy languages) and
first-order (like macros in Lispy languages).

Adding to Ray Dillinger and Joh Harrop's post about a ideal functional
lang system, my wishes are:

★ The language will be absolutely high-level, meaning in particular:

☆ The language will not have cons.

☆ The language's documentation, will not need to have mentioning any
of the following words: pointer, reference, memory allocation, stacks,
hash.

☆ The language's variables must not have types. Its values can have
types. And, these types must be mathematics, not computer engineering
inventions. Specifically: The language will not have any concepts or
terms of: float, double, int, long, etc. (it can, however, have
concepts like exact number, n-bit approximate number aka machine-
precision number (See below on optimization declaration).)

☆ The numbers in the language can have the following types: integer,
rational, real, complex number. (and possibly extention from these,
such as algebraic/roots number, etc.)

Ray Dillinger schrieb:

What's source control?
Revision control? In that case: why integrated?

Borderline case: bugfix updates.

What's that?

Joachim Durchholz wrote:

Yes, revision control. Integrated to give additional tools
for code policy enforcement to organizations with policies
and coding standards.

Integrated to prevent projects that are supposed to have
specific coding goals or runtime models from using or depending
on code that does not.

Integrated to prevent people from ignoring a requirement of
code review when using constructs they may or may not understand.
And so on.

Ray Dillinger sonic.net> writes:

I stand against this. First of all, if your people are mostly smart, the solves
most of the problems right there.

Second, I don't think such tools can be practically written. Fiercly
difficult, they would be.

Third, such tools cannot properly understand the reason for any violation, so
in the end it equates to getting a human involved to vet things. And if that's
the case, it is far far simpler and easier to enforce that all commits simply
get reviewed, period.