On Wed, Jul 27, 2011 at 3:41 AM, BGB <cr88...@gmail.com> wrote:
> a non-turing-complete IL is too limited to do much of anything useful with
> WRT developing "actual" software...
>
You aren't alone in holding this uninformed, reactionary opinion.
Consider: Do we need Turing power for 3D apps? No. Because we want *
real-time* 3D apps, and that means we don't perform arbitrary computations
per frame. There is *no* "actual" software that needs Turing power for
functions.
Anyhow, I did not suggest being rid of Turing power for the whole
application, only moving and controlling access to it externally. ("We
might in the general case need Turing power, at the topmost level of a
service or application... capable of drawing arbitrary images if given
enough resources (time, resolution, et cetera) but the decision on how many
resources to provide is external")
That is, we do need software that can 'run forever' and 'compute arbitrary
functions'. We just don't need that power in the middle. A top-level loop,
based on passage of time, will do the job quite well.
> the usual strategy is to use runtime checks for anything which can't be
> determined at compile time.
>
For a language or IL as finicky as C++, the usual strategy is to sandbox the
whole runtime. This offers better performance on the off-chance things are
written well, though it does force developers to use obtuse means of
communication between extensions and subprograms.
>
> "better" would be to disallow conversions between pointers and integers,
> these are in-fact fairly useful operations.
>
With dependent typing, pointer arithmetic can be safe. Adam Chlipala's
'Bedrock' supports it. To get dependent typing, you first remove unnecessary
power.
>
these idioms are the defined ways of doing things.
>
a language which doesn't support these idioms would be invariably rejected
> by most programmers.
>
Your language will also, invariably, be rejected by most programmers. If
you're going reject ideas that won't be popular, you should give up on
language design and find another hobby.
But I think you're wrong. People will accept new tools and idioms, if:
* they see or are shown how to utilize them to solve today's problems
* they are motivated by a sufficient gain in features or reduction of pain
* there is good support for legacy systems, so they can transition cheaply
* the tools are readily accessible, open source, and easy to use and install
Acceptance won't happen all at once, but it doesn't need to.
> spreadsheets are not programs.
> in the same way, SQL databases, ... are not programs.
>
You are incorrect. I think you would be surprised at how many people will
speak of 'spreadsheet applications' as common-place.
But I agree that spreadsheets and SQL are not sufficiently powerful to
develop many useful domains of services and apps.
>
> however, dataflow-like constraints are a nifty feature, and one of my
> earlier languages had them (they are sort of like values, but their apparent
> value will change whenever one of the input values is modified, ...). IIRC,
> a flush/recalculate model was used.
>
Ah, another of those declarative languages with imperative glue?
For dataflow to really serve as a language of its own, it must be both
bi-directional (effect and observe, push and pull, effective state
management) and contingent (some form of if/then/else internal to the
dataflow) and eliminate need for imperative bindings in the middle. We'll
still need imperative for legacy adapters, but the idea is to slowly creep
and replace the legacy.
> non-algorithmic software is generally not, by definition, software.
> more correctly it can be described as data and file-formats.
>
You have an odd definition of 'software'. I suppose you go around claiming
that BGBScript programs aren't "software", it's just file format containing
data that can be interpreted?
Software is what describes behavior for programmable hardware. "Algorithmic"
software is software that focuses on the internal computation of a function,
as opposed to workflows or control relationships.
> there is nothing really wrong with the current methodology, more just it
> needs more features
>
If there was nothing wrong, then error and buggy code would not be *systemic
* problems, patches and upgrade would not need human intervention, clients
could put useful code on servers to abstract new protocols, and distribution
would be straightforward.
>
> I am thinking more like traditional application software coming down over
> the internet (say, in a manner partly between the Web and something like
> Valve's Steam). or, maybe sort of like Android Market or similar...
>
The idea of rich internet applications appeals to me, too. But I think the
real win will be zero-tier architecture: we write our services and apps
together, and the appropriate amount of the service (i.e. the stuff that
twiddles the video) is downloaded to the client. And other parts move to
resources owned by the client, in the cloud - e.g. storage that is intended
to survive loss of the machine.
One of my interests is market integration. I find Nick Szabo's work on
e-markets quite fascinating.
>
> unnecessary or drastic change may often be seen as evil.
>
> hence, the status quo is king...
>
A despotic king, perhaps.
I do agree with the need for a smooth transition strategy. "Drastic" change
simply doesn't happen, and trying to force the issue causes people to panic
and do stupid things.
>
> the best thing is to keep everything just as it is, so that older
> programs/methodologies/... continue to work until which point they fade away
> on their own (sort of like Fortran and COBOL...).
>
For things to 'fade away', you must be transitioning to something
new. Change requires reaching for something 'different'. Progress requires
reaching for something 'better'. Trying to "keep everything just as it is",
if you were successful (which you won't be), would not result in anything
fading away.
>
> the program would not be running in the browser anyways, but simply
> distributed partly via the browser, and then run primarily on the host
> computer (as standalone applications).
>
I do not believe the future will support a strong distinction between
browser apps and standalone apps. But apps that run offline, I think are
likely.
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
