|
You should also check out the recently updated
ideas, which are often (but not always) a bit more fully elaborated. Here
are the latest random thoughts.
07.06 Partial evaluation ala POJQ could be very useful for web-based
programming, where you have some code to execute on the client
and some to execute on the server. Ideally we can infer whether
each variable depends on client-side values or server-side
values and divide the computation automatically, while the
programmer doesn't even have to be aware of the difference.
31.03 Here's a crazy sci-fi idea: in the future a computer programmer's job is simply
to receive requirements and think about them while their neuron activation
patterns are recorded; then the recording is used to construct and/or train a
stupid neural network to implement the solution. The point is that we will
always need specially-trained humans to interface other humans with computers,
but there may be a point where the "programmer" is simply using their ability
to think mostly-logically while still being mostly human as a wetware interface
layer. In other words, programming with mental symbols and constructs instead
of text. Imagine how it would be to "load" someone else's program to edit; very
disorienting.
09.03 Ulf Wiger on comp.lang.functional Message-ID <xczacbzzo4g.fsf@CUT-ericsson.com>:
Joe argues (not very visibly here) that message-passing interfaces are much
more succinct than functional APIs. His example is the X11 protocol, which
consists of 154 protocol messages. XLib, the programming interface, has about
800 interface functions. The reason, according to Joe, that programmers don't
use the protocol level directly, is that they get the concurrency wrong. So, in
order to hide the natural concurrency of the problem, one devises APIs that
quickly grow enormous.
28.11 The possibility of a semi-transparent wearable LCD give all new meaning to the
old classic fairy tale. Imagine buying a designer dress and experiencing a
power failure!
-- /. 550448
30.09 The reason Lisp's syntax is good for macros & syntax extensions
isn't just because it makes them easier to express -- you can
always express macros on the underlying tree as in Mathematica.
Instead, it's mainly a way of reducing expressiveness to gain
consistency (much like Python's equally-controversial
whitespace-dependence). Writing syntactic extensions is hard --
writing them when you're allowed to use any surface syntax you feel
like is apparently practically impossible to do well (witness
Perl). So this is one case where it's better if your fellow
programmers don't get to indulge.
12.09 Rob Thorpe on comp.lang.lisp today suggested that a Lisp compiler segregate
objects into atomic versus non-atomic types, so that it can use separate heaps
and different gc algorithms for each. For example, you know atomic types won't
contain pointers to other types so they shouldn't need marking. Sounds great!
more...
|