If dynamic typing didn't exist you'd have to invent it :-)
Joe Armstrong
IMHO If dynamic typing didn't exist you'd have to invent it.
Why.
Imagine
foo(A, B) ->
A/B.
I guess I could prove that A and B are integers, but
to avoid division by zero I'd like more - Id like to prove
that B is non-zero.
I'd like a "a non-zero integer" type but this seems to be
beyond the state of the art, at least for real systems.
In such circumstance it seems reasonable to add an assertion to
the code:
foo(A, B) when B > 0 ->
A/B.
The assertion is checked at run-time.
There are all sorts of things that can *easily* be checked at
run-time (absence of dead-lock, prescence of live-lock etc.) that
are totally beyond the ability of *any* static type system to
check.
Type systems can prove things like "If this produces a result"
then it will be of this type - but they can't and never will be
able to prove termination (unless Turing was wrong :-).
Dynamic type systems can test for termination.
Here's a little Erlang function:
within(Func, T) returns {yes, Val} if Func can be computed
within time T otherwise no.
within(F, T) ->
S = self(),
P = spawn(fun() -> compute(F, S) end),
receive
{P, R} ->
{yes, R}
after Time ->
no
end.
compute(F, Parent) ->
Parent ! F().
I can't see how to cast this kind of code into a static type
framework.
In Erlang I can make claims like if "F terminates it will be of
type T" - by running F and *testing* that the return value is of
type T. I can even make stronger claims like "within(F, 1sec)"
will terminate within 1.<somthing> seconds <<provided I believe my
run-time system>>
/Joe
--
Joe Armstrong,
Alteon WebSystems, tel: +46 8-545 550 00
S:t Eriksgatan 44, IV, fax: +46 8-654 70 71
SE-112 32 Stockholm, Sweden info: www.bluetail.com
Christian Brolin
>
> Type systems can prove things like "If this produces a result"
> then it will be of this type - but they can't and never will be
> able to prove termination (unless Turing was wrong :-).
It is possible to statically prove termination of a proper non-empty
subset of all programs.
> Dynamic type systems can test for termination.
>
> Here's a little Erlang function:
>
> within(Func, T) returns {yes, Val} if Func can be computed
> within time T otherwise no.
> within(F, T) ->
> S = self(),
> P = spawn(fun() -> compute(F, S) end),
> receive
> {P, R} ->
> {yes, R}
> after Time ->
> no
> end.
>
> compute(F, Parent) ->
> Parent ! F().
>
This is another (much simpler) problem. It is possible to statically
prove termination, within a limited time, of all programs.
Doesn't your program just prove termination of some invocations of the
program?
> I can't see how to cast this kind of code into a static type
> framework.
QED?
> In Erlang I can make claims like if "F terminates it will be of
> type T" - by running F and *testing* that the return value is of
> type T. I can even make stronger claims like "within(F, 1sec)"
> will terminate within 1.<somthing> seconds <<provided I believe my
> run-time system>>
So you mean that the type of your program depends of the speed of your
computer!?
--
Christian Brolin
Bruce Hoult
<j...@bluetail.com> wrote:
> IMHO If dynamic typing didn't exist you'd have to invent it.
I can't see anything here that is beyond current static type systems.
The fundamental idea of a static type system is that you move errors
from the point of use of a variable to the point of assignment of that
variable. If the compiler complains that there is an error at the point
of assignment then you can change your code there to avoid the problem.
> Imagine
>
> foo(A, B) ->
> A/B.
>
> I guess I could prove that A and B are integers, but
> to avoid division by zero I'd like more - Id like to prove
> that B is non-zero.
>
> I'd like a "a non-zero integer" type but this seems to be
> beyond the state of the art, at least for real systems.
Why?
In Dylan, for example, you have type-unions and limited integer types.
If you declare B to be of type...
define constant <nonzero-integer> = type-union(
limited(<integer>, max: -1),
limited(<integer>, min: 1)
)
... then the division by zero can never happen. At the point of call of
f(), the compiler will give an error if the value of the argument can be
zero -- the actual parameter has to be either of type <nonzero-integer>
or some more restrictive type.
Suppose that you have another function:
define function bar(B :: <integer>)
foo(10, B);
end
The compiler will complain that B is not something that you can pass to
foo(). You have two basic choices:
1) change the type of B to <nonzero-integer> (or +ve integer, or
(10..99), or whatever) and propogate the constraint upwards, or
2) put in an explicit test in bar():
define function bar(B :: <integer>)
if (B == 0)
do-something-appropriate();
else
foo(10, B);
end
end
The compiler's type propogation algorithm then understands that the type
of B within the "then" part is type-union(limited(<integer>, max: -1),
limited(<integer>, min: 1)) and that the type of B within the "else"
part is limited(<integer>, min: 0, max: 0), and all is well.
The same sort of logic applies to things such as array bounds checks,
determining the possible values of an induction variable, etc.
> There are all sorts of things that can *easily* be checked at
> run-time (absence of dead-lock, prescence of live-lock etc.) that
> are totally beyond the ability of *any* static type system to
> check.
True, but there are lots of things that *can* be checked.
> Type systems can prove things like "If this produces a result"
> then it will be of this type - but they can't and never will be
> able to prove termination (unless Turing was wrong :-).
>
> Dynamic type systems can test for termination.
>
> Here's a little Erlang function:
>
> within(Func, T) returns {yes, Val} if Func can be computed
> within time T otherwise no.
>
> within(F, T) ->
> S = self(),
> P = spawn(fun() -> compute(F, S) end),
> receive
> {P, R} ->
> {yes, R}
> after Time ->
> no
> end.
>
> compute(F, Parent) ->
> Parent ! F().
>
>
> I can't see how to cast this kind of code into a static type
> framework.
I don't see any reason why it can't be, given suitable threading
primitives. The return type from the function is simply made to be a
type-union of the expected type of the value and some error code (often
in practise the boolean false value).
It's the threading here that's the problem, not the types.
-- Bruce
Ulf Wiger
-> So you mean that the type of your program depends of the speed of
-> your computer!?
Here's a real-world example:
If a call-handling system is overloaded, you have to start
rejecting call setup requests to avoid further overload. To do this,
you will typically implement a request buffer. The signalling
protocol will time out after a certain time T (e.g. 5 seconds); thus,
any buffered requests older than this can be thrown away, because
the client will not want a reject message anyway.
In addition to this, a typical requirement would be that call-setup
delay must be no greater than, say 100 msecs for 90% of the calls.
Of course, in an existing fault situation, such as failure of
a control processor, it may be acceptable to run with increased
call-handling delays or reduced capacity. It may also be acceptable
to temporarily refuse all new connections.
Not only does the program's behaviour depend on the speed of the
computer: it also depends on available memory, status of required
hardware, and offered network load.
Does this surprise you?
/Uffe
--
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
Christian Brolin
>
> >>>>> "-" == Christian Brolin <Christia...@carmen.se> writes:
>
> -> So you mean that the type of your program depends of the speed of
> -> your computer!?
>
> Here's a real-world example:
>
> If a call-handling system is overloaded, you have to start
> rejecting call setup requests to avoid further overload. To do this,
> you will typically implement a request buffer. The signalling
> protocol will time out after a certain time T (e.g. 5 seconds); thus,
> any buffered requests older than this can be thrown away, because
> the client will not want a reject message anyway.
>
> In addition to this, a typical requirement would be that call-setup
> delay must be no greater than, say 100 msecs for 90% of the calls.
>
> Of course, in an existing fault situation, such as failure of
> a control processor, it may be acceptable to run with increased
> call-handling delays or reduced capacity. It may also be acceptable
> to temporarily refuse all new connections.
>
> Not only does the program's behaviour depend on the speed of the
> computer: it also depends on available memory, status of required
> hardware, and offered network load.
>
> Does this surprise you?
Is 'type' and 'behaviour' the same thing? I thought the type of a
program was the set (or a superset) of all possible scenarios.
--
Christian Brolin
Ulf Wiger
-> Ulf Wiger wrote:
>> >>>>> "-" == Christian Brolin <Christia...@carmen.se>
>> writes:
>>
-> So you mean that the type of your program depends of the speed
-> of your computer!?
>> Here's a real-world example:
<snip>
>> Not only does the program's behaviour depend on the speed of the
>> computer: it also depends on available memory, status of required
>> hardware, and offered network load.
>>
>> Does this surprise you?
-> Is 'type' and 'behaviour' the same thing? I thought the type of a
-> program was the set (or a superset) of all possible scenarios.
I chose the word "behaviour" because I don't consider it a typing
problem. It's a description of how the program must behave. If you
want to define types that describe this behaviour, it also becomes
a typing problem; otherwise, it isn't.
Marcin 'Qrczak' Kowalczyk
> I'd like a "a non-zero integer" type but this seems to be
> beyond the state of the art, at least for real systems.
Indeed not all properties can be conveniently expressed in types.
But many can, and I am glad that I can use languages which allow
to do it.
> Dynamic type systems can test for termination.
It's not a type system which tests for termination in the sense you
describe.
> I can't see how to cast this kind of code into a static type
> framework.
Where is the problem?
------------------------------------------------------------------------
import Concurrent
import Exception
import List
within :: Int -> IO a -> IO (Maybe a)
within us f = do
outcome <- newEmptyMVar
compute <- forkIO $ do
result <- f
putMVar outcome (Just result)
`Exception.catch` \_ -> putMVar outcome Nothing
timeout <- forkIO $ do
threadDelay us
putMVar outcome Nothing
`Exception.catch` \_ -> return ()
out <- takeMVar outcome
killThread compute
killThread timeout
return out
main :: IO ()
main = do
print =<< within 1000000 (return $! sort [1 .. 5])
print =<< within 1000000 (return $! sort [999999, 999998 .. 0])
------------------------------------------------------------------------
This gives the following result on my machine:
Just [1,2,3,4,5]
Nothing
> In Erlang I can make claims like if "F terminates it will be of
> type T" - by running F and *testing* that the return value is of
> type T.
You can also do this in statically typed languages. This can be
checked at compile time.
> I can even make stronger claims like "within(F, 1sec)"
> will terminate within 1.<somthing> seconds <<provided I believe my
> run-time system>>
You can do this too. This must be checked at runtime.
It follows that a language with a static type system provides both
compile time checks and runtime checks, where Erlang provides only
runtime checks. So where is Erlang's advantage in this respect?
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
Fergus Henderson
> I can't see how to cast this kind of code into a static type
> framework.
and then Marcin 'Qrczak' Kowalczyk <qrc...@knm.org.pl> replied
>Where is the problem?
and gave a reasonably straight-forward translation into Concurrent Haskell.
Joe, these kind of arguments really weaken your case.
You and the other Erlang participants here say that you've written
these really complicated large systems, with dynamic code update and
distribution and lots of other nifty features, and that you don't see
how this would be possible in statically typed languages. Since you
have a lot of experience with these kind of systems, your opinions on
this carry a lot of weight. But those of us who are familiar with
(mostly) statically typed languages, and who have not tried to
implement systems that support all of those other nifty features you're
talking about, wonder whether this is because those nifty features are
hard to do with static typing, or whether it is just that you don't
know enough about static typing and how to use it.
Now, it may be that these features _are_ hard to do with static typing.
But the fact that you think that simple examples like the one that
Marcin translated are hard to do with static typing makes it clear
to me that at least _some_ of your worries about static typing are
unfounded, and that casts doubt on the remaining ones.
--
Fergus Henderson <f...@cs.mu.oz.au> | "I have always known that the pursuit
| of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Mike Williams
f...@cs.mu.oz.au (Fergus Henderson) writes:
|> this carry a lot of weight. But those of us who are familiar with
|> (mostly) statically typed languages, and who have not tried to
|> implement systems that support all of those other nifty features you're
|> talking about, wonder whether this is because those nifty features are
|> hard to do with static typing, or whether it is just that you don't
|> know enough about static typing and how to use it.
Please, I don't think any of us think that statically typed languages
are a bad idea. But a lot of us think that static typing isn't as
important as many people like to think. Personally, I don't want to
stop accademic institution working on esoteric type systems, but I do
wish the functional programming community would also work on other
things which are important for the software industry whose job it is
to produce large and complex software systems. For example:
- Concurrency (modelling systems with a lot of explict concurrency)
- Distribution (both to achieve scalability and to model systems which are
inherently distributed)
- SW configuration managment (source code control is only part of this)
- Changing code in running systems
- Reliability and high availability (for example N + M redundancy)
- Man machine interfaces
- Data bases integrated with language implementations
- etc, etc etc
I would be very pleased if they could do research in these areas in
the contex of functional programming languages. The functional
programming accademia just aren't interested. Which means that all
the excellent work being done in Haskell, Oz, Caml, SML, Mercury etc
doesn't get (and won't get) the impact it deserves. This is a great
shame.
/Mike
Mike Williams
'nt missing from title, sorry :-) /Mike
Christian Brolin
>
> >>>>> "-" == Christian Brolin <Christia...@carmen.se> writes:
>
> -> Ulf Wiger wrote:
> >> >>>>> "-" == Christian Brolin <Christia...@carmen.se>
> >> writes:
> >>
> -> So you mean that the type of your program depends of the speed
> -> of your computer!?
> >> Here's a real-world example:
> <snip>
> >> Not only does the program's behaviour depend on the speed of the
> >> computer: it also depends on available memory, status of required
> >> hardware, and offered network load.
> >>
> >> Does this surprise you?
>
> -> Is 'type' and 'behaviour' the same thing? I thought the type of a
> -> program was the set (or a superset) of all possible scenarios.
>
> I chose the word "behaviour" because I don't consider it a typing
> problem. It's a description of how the program must behave. If you
> want to define types that describe this behaviour, it also becomes
> a typing problem; otherwise, it isn't.
Of course, the type of a program should describe the behaviour of the
program. But irrespective of what definition you choose, the type of the
program is not a function of the speed of the computer that runs it.
In your example:
makeCall :: TelephoneNumber -> (Connection Line | WrongNumber |
SystemOverloaded)
One configuration (slow CPU, slow network, little memory) may return the
VALUE 'SystemOverloaded' more often than a more powerfull system, but
the TYPE of the program is still not affected.
--
Christian Brolin
David Chemouil
> For example:
>
> - Concurrency (modelling systems with a lot of explict concurrency)
> - Distribution (both to achieve scalability and to model systems which are
> inherently distributed)
> - SW configuration managment (source code control is only part of this)
> - Changing code in running systems
> - Reliability and high availability (for example N + M redundancy)
> - Man machine interfaces
> - Data bases integrated with language implementations
> - etc, etc etc
>
> I would be very pleased if they could do research in these areas in
> the contex of functional programming languages.
Well, some do. You should for example look at actor languages, based on
Hewitt and Agha's model.
dc
--
David Chemouil [mailto:David.C...@irit.fr]
Institut de recherche en informatique de Toulouse
Ulf Wiger
-> You and the other Erlang participants here say that you've
-> written these really complicated large systems, with dynamic code
-> update and distribution and lots of other nifty features, and
-> that you don't see how this would be possible in statically typed
-> languages.
This has not been my argument. My argument has been "prove it",
i.e. discussing micro examples and extrapolating that to a large
system is useless; so is discussing 1-20 man projects and
extrapolating to 100-man projects. It just doesn't work that way.
From that perspective, I argue that, given what I've seen in this
newsgroup, and given my assessment of the type of programmers we
have at our disposal, the syntax and the kind of reasoning required
to write hundreds of thousand lines of statically typed code in
Haskell, OCaml or other, seem a bit overwhelming.
Maybe it isn't so. Maybe my Erlang preference is coloring my judge-
ment. Some of the things that have been demonstrated really seem
great, but I think that trying to introduce this into a fast-paced
industrial environment with a hundred or so "average programmers"
would be a humbling and extremely useful experience.
Lars Lundgren
>
>
> IMHO If dynamic typing didn't exist you'd have to invent it.
>
> Why.
>
> Imagine
>
> foo(A, B) ->
> A/B.
>
>
> I guess I could prove that A and B are integers, but
> to avoid division by zero I'd like more - Id like to prove
> that B is non-zero.
>
> I'd like a "a non-zero integer" type but this seems to be
> beyond the state of the art, at least for real systems.
>
> In such circumstance it seems reasonable to add an assertion to
> the code:
>
> foo(A, B) when B > 0 ->
> A/B.
>
> The assertion is checked at run-time.
>
> There are all sorts of things that can *easily* be checked at
> run-time (absence of dead-lock, prescence of live-locketc.) that
> are totally beyond the ability of *any* static type system to
> check.
Agreed, but what is the point? Do you somehow imply that static typing
prevents you from making runtime checks? That is just utter nonsense!
> Type systems can prove things like "If this produces a result"
> then it will be of this type - but they can't and never will be
> able to prove termination (unless Turing was wrong :-).
>
> Dynamic type systems can test for termination.
>
Not in general. They can test exactly the cases you can test with
staticly typed systems.
> I can't see how to cast this kind of code into a static type
> framework.
>
How about learning a bit about modern static typing?
> In Erlang I can make claims like if "F terminates it will be of
> type T" - by running F and *testing* that the return value is of
> type T.
You can claim anything you want, but this claim is unwarranted. Testing
can show the existence of bugs, *never* their absence. You only know
"*This* time F terminated and returned a value of type T". That is much
weaker.
In Haskell the typesystem justifies claims like the one you made.
> I can even make stronger claims like "within(F, 1sec)"
> will terminate within 1.<somthing> seconds <<provided I believe my
> run-time system>>
>
Such claims can be made about implementations of within() in most
languages including haskell.
> /Joe
>
> --
> Joe Armstrong,
> Alteon WebSystems, tel: +46 8-545 550 00
> S:t Eriksgatan 44, IV, fax: +46 8-654 70 71
> SE-112 32 Stockholm, Sweden info: www.bluetail.com
>
>
/Lars L
Kellom{ki Pertti
> From that perspective, I argue that, given what I've seen in this
> newsgroup, and given my assessment of the type of programmers we
> have at our disposal, the syntax and the kind of reasoning required
> to write hundreds of thousand lines of statically typed code in
> Haskell, OCaml or other, seem a bit overwhelming.
Syntax and typing discipline are almost orthogonal (not quite, because
obviously one would want a syntax for types), so I do not see syntax
as an issue. I come from a Lisp and Scheme background, so some of the
syntactic details of e.g. Haskell make me shudder. But this is a
surface quality, not something that is intimately tied with being
statically typed.
Also, I have found that static typing actually makes my reasoning
easier than it would be in a dynamically typed language. True, there
is a tendency among functional programmers to apply clever tricks with
higher order functions which require complicated reasoning. But this
is a quality of programmers, not a quality of static typing. Writing
straightforward code should not be any harder with static typing than
with dynamic typing.
The argument I agree with is that distributed systems have important
properties that one cannot (I believe) express using current type
systems. However, this is a not a reason to prefer either dynamic or
static typing. Rather, it is an invitation to invent mechanisms with
which the properties can be expressed and enforced. If static typing
can be extended to do it, all the better.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
Brian Rogoff
> >>>>> "-" == Fergus Henderson <f...@cs.mu.oz.au> writes:
>
> -> You and the other Erlang participants here say that you've
> -> written these really complicated large systems, with dynamic code
> -> update and distribution and lots of other nifty features, and
> -> that you don't see how this would be possible in statically typed
> -> languages.
>
> This has not been my argument. My argument has been "prove it",
> i.e. discussing micro examples and extrapolating that to a large
> system is useless; so is discussing 1-20 man projects and
> extrapolating to 100-man projects. It just doesn't work that way.
What fraction of software is developed by 20-100 person teams? In the
environments I've been in that had >50 people working on the same SW
(in C, Fortran, and C++ BTW) I don't imagine the type system would have
been a hindrance (these were VLSI CAD applications, and weren't non-stop,
code-loading, hot-swapping, ass-kicking Erlang apps :) but performance
issues would have been critical. Also, EDA programmers are a skewed
group, like scientific programmers, and have more math savvy than your
average web programming script kiddy.
> From that perspective, I argue that, given what I've seen in this
> newsgroup, and given my assessment of the type of programmers we
> have at our disposal, the syntax and the kind of reasoning required
> to write hundreds of thousand lines of statically typed code in
> Haskell, OCaml or other, seem a bit overwhelming.
Haskell, maybe, because the state of the art for reasoning about space
in lazy languages is a bit abstruse. Still, imperative programmers master
far trickier stuff. {OCa,S}ML would be fine, there is definitely room for
improvement in error reporting but I find the current OCaml type system
more useful than complex, and other programmers master incredible Perl and
C++ machinations that would make my head spin.
However, you do have a point, and there is a lot of room for more
"human engineering" of type explainers. DrScheme looks promising; both
its type explaining facilities and the units/module language could be
adapted to Erlang.
> Maybe it isn't so. Maybe my Erlang preference is coloring my judge-
> ment. Some of the things that have been demonstrated really seem
> great, but I think that trying to introduce this into a fast-paced
> industrial environment with a hundred or so "average programmers"
> would be a humbling and extremely useful experience.
So, Bluetail was a hundred or so average programmers? :-)
I'd be happy with tools that can effectively double the productivity
of a much smaller group of programmers, and current FPs do this. I'd
say some (large?) part of that is not due to typing but to higher order
functions and pattern matching, but at least for me static typing is a
big win.
-- Brian
Ulf Wiger
-> On 7 Mar 2001, Ulf Wiger wrote:
>> This has not been my argument. My argument has been "prove it",
>> i.e. discussing micro examples and extrapolating that to a large
>> system is useless; so is discussing 1-20 man projects and
>> extrapolating to 100-man projects. It just doesn't work that way.
-> What fraction of software is developed by 20-100 person teams?
Large companies tend to want to know that development tools can scale
to this size. This is not only because they tend to make projects
much larger than they need to be, but because they don't want to
see the projects start falling apart when they start getting
interesting.
(Now, C++ doesn't scale at all well to this size of project. Neither
does Java, in my opinion. But most people go for it anyway.)
-> Still, imperative
-> programmers master far trickier stuff. {OCa,S}ML would be fine,
-> there is definitely room for improvement in error reporting but I
-> find the current OCaml type system more useful than complex, and
-> other programmers master incredible Perl and C++ machinations
-> that would make my head spin.
This is true, but unfortunately beside the point. (:
The fact that people are willing to put up with extraordinary
headaches as long as things are done the way they think they are
supposed to be done, doesn't mean that they will have any patience
with difficulties if you try to teach them something new and
different (i.e. not mainstream or extremely hyped).
That is, if it's hard to get into, and the advantages are not
obvious up-front, most(?) people will not give it a sporting chance.
Making something succeed if it's not mainstream or backed by an
extremely powerful marketing organization means that you have
to show very convincingly that it's still worth the effort and
risk. This means you don't have to be just a little bit better;
not even just that you have to be much better: you also have to
be able to show this convincingly in a non-technical manner.
Building large and important products that sell for many millions
of dollars is one pretty convincing argument, if you can do it
with impressive speed and show consistently good quality and
performance.
>> Maybe it isn't so. Maybe my Erlang preference is coloring my
>> judgement. Some of the things that have been demonstrated
>> really seem great, but I think that trying to introduce this into
>> a fast-paced industrial environment with a hundred or so "average
>> programmers" would be a humbling and extremely useful experience.
-> So, Bluetail was a hundred or so average programmers? :-)
Eh, no. Bluetail started out with a bunch of people who were
expert in Erlang (some even helped invent it). Furthermore, they
started out building products based on a concept that was, to a
large extent already prototyped through the eddie project.
I was not thinking of Bluetail when I wrote "average programmers".
Trying to convince the Bluetail people to start using concurrent
Haskell would probably be humbling for totally different reasons. ;)
Sean Hinde
"Mike Williams" <mi...@erix.ericsson.se> wrote in message
news:984oca$kae$1...@news.du.uab.ericsson.se...
> In article <984l61$f5d$1...@mulga.cs.mu.OZ.AU>,
> f...@cs.mu.oz.au (Fergus Henderson) writes:
>
> - Concurrency (modelling systems with a lot of explict concurrency)
> - Distribution (both to achieve scalability and to model systems which are
> inherently distributed)
> - SW configuration managment (source code control is only part of this)
> - Changing code in running systems
> - Reliability and high availability (for example N + M redundancy)
> - Man machine interfaces
> - Data bases integrated with language implementations
> - etc, etc etc
I'm a bit surprised you missed out "Programming in the large". It is hard to
write a million line program without pretty major support for this
(especially without a static type checker ;) )
<info>Erlang/OTP provides the "application" concept and standard behaviours
(or design patterns) for supervisory processes, generic servers, finite
state machines etc.
http://www.erlang.org/doc/r7b/doc/design_principles/part_frame.html
</info>
Ulf (1M loc, fingers worn to the bone) Wiger has also mentioned before that
AXD relies heavily on these built in behaviours and structures to support
its wide code girth.
In my experience they provide a natural way to break down a problem into
major functionality areas, the OTP environment makes it easy (ish) to
incorporate these structures into large or small programs, and there are
quite a number of tools which understand and rely on the structure.
One question which arises in my mind is what the equivalents of these
"structures for large programs" would be in Haskell or O'Caml. I have seen
this question asked before on c.l.f and the response went along the lines of
"Well first you have to decide on the Type of the whole problem and the
solution just follows from there". I got the impression the questioner went
away shaking his head and muttering to himself..
I'm not at all sure that the OTP solution is perfect in all cases so it
would be interesting to see research into what might be even better..
- Sean
Mike Williams
"Sean Hinde" <sean....@btinternet.com> writes:
|> I'm a bit surprised you missed out "Programming in the large".
Of course you are right. As I manage this sort of thing on a daily
basis, I tend to forget the obvious.
|> I'm not at all sure that the OTP solution is perfect in all cases so it
|> would be interesting to see research into what might be even better..
Thats what I mean. There is a huge area for research. Due to the deathly
silence of the "accademics" in resonse to this thread, I assume that the
my postulate that academia not being interested in the success of FP is
correct. With this sort of attitude we will no doubt see funding for
research in FP dwindling away in the near future.
/Mike
Jerzy Karczmarczuk
[[what features are needed for serious impact of FP, and which
seem to be neglected by teraching/research establishments]]
> > - Concurrency (modelling systems with a lot of explict concurrency)
...
> > - Data bases integrated with language implementations
> > - etc, etc etc
> I'm a bit surprised you missed out "Programming in the large".
> It is hard to write a million line program without pretty major
> support for this (especially without a static type checker ;) )
Typed or not typed...
Could somebody tell me - sincerely - how to organize our work at
Universities in order to treat seriously the problem of writing
programs with millions lines of code? I simply don't know.
Is it a question of interest, or of resources?
This mythic entity called "Academia" needs mainly that. And some
encouragement.
Not only. I must say that I was terribly disappointed in Montreal,
during ICFP when Philip Wadler announced that NOT A SINGLE ONE
application paper has been accepted. I found it shocking, I asked
why, And PW gave me the only answer he could: - papers were simply
not good enough, either trivial or unreadable.
I believe it would be a good idea to organize a PERSISTENT cycle
of workshops, attached to international conferences, or separate,
permiting to present unfinished projects, permitting to distil
the delicate relation between the needs and the possibilities.
The experience is something got only by experience.
On the other hand, even if we (teachers/researchers) cannot
seriously complain that the industrial world is not encouraging
us to teach or work on their problems, I think that people from
out there should sometimes choose their words more carefully.
How many times have we seen even here such rubbish as "if I were
a software manager I would program only in C/C++"?
In some other newsgroups the situation is even worse. The graphics
people, the game programming folk who ask for algorithms and
procedures, refuse to accept anything, but "C". They ask often
quite simple questions, for example how to convert between colour
spaces, demanding a concrete code. So I sent to one of them a piece
of code in Haskell (or in Clean, I don't remember...). And, imagine,
he insulted me in return, saying that he doesn't need stupid
theoretical toys, but a *real program*.
So, when I read Mike Williams again:
> There is a huge area for research. Due to the deathly
> silence of the "accademics" in resonse to this thread, I assume that the
> my postulate that academia not being interested in the success of FP is
> correct. With this sort of attitude we will no doubt see funding for
> research in FP dwindling away in the near future.
I have to say that you are a bit wrong, Mike, and, please, refrain
from issuing useless threats. Try instead to analyse the reasons
of this situation which you seem not to like, but which is much
more painful for the people within this fuzzy "Academia".
Jerzy Karczmarczuk
Caen, France
Ulf Wiger
-> Could somebody tell me - sincerely - how to organize our work at
-> Universities in order to treat seriously the problem of writing
-> programs with millions lines of code? I simply don't know. Is it
-> a question of interest, or of resources?
As I've mentioned, we're trying a model where we work together with
researchers from Uppsala University, Ericsson CSLab and SICS.
We give them access to our source code, and provide a room here at
our development site, and they try to tackle interesting problems
in the context of AXD 301 code. We have more ideas right now than
we have researchers to throw at them, but I think we're off to a
good start.
First projects aim to give us tools to derive visual models from
actual product code (as automated as possible), to formally verify
some components, and to do formal analysis on some really mind-
bending problems.
One of the projects discussed was investigating ways to introduce the
Erlang type checker into our project (also making it ready for prime
time), but we have no one to do this work right now.
My hope is that we will eventually start a tradition, where we pay
some attention to also making our industrial code a good research
platform, and continuously work with academia to find new ways of
improving productivity and quality.
This is by no means the first cooperation with academia. We had a
man from the HIPE project working here and compiling some of our
test benches to native code using the HIPE JIT compiler. Both we
and the HIPE team learned some very interesting lessons: one was that
our code behaved very differently from their micro benchmarks.
As we have design centers in Dallas, TX, Leicester, and soon
Paris as well, we may be able to do this sort of thing on a broader
scale eventually, but first things first.
-> Not only. I must say that I was terribly disappointed in
-> Montreal, during ICFP when Philip Wadler announced that NOT A
-> SINGLE ONE application paper has been accepted. I found it
-> shocking, I asked why, And PW gave me the only answer he could: -
-> papers were simply not good enough, either trivial or unreadable.
This is sad, but speaking for the industrial side, writing papers
that are good enough to be accepted to these conferences is most
often too time consuming for us. Workshops are a totally different
matter.
-> I believe it would be a good idea to organize a PERSISTENT cycle
-> of workshops, attached to international conferences, or separate,
-> permiting to present unfinished projects, permitting to distil
-> the delicate relation between the needs and the possibilities.
-> The experience is something got only by experience.
This sounds like a very good idea.
-> On the other hand, even if we (teachers/researchers) cannot
-> seriously complain that the industrial world is not encouraging
-> us to teach or work on their problems, I think that people from
-> out there should sometimes choose their words more carefully.
I understand your point, but some of us out there really feel that
we have some outstanding research opportunities.
-> So, when I read Mike Williams again:
>> There is a huge area for research. Due to the deathly silence of
>> the "accademics" in resonse to this thread, I assume that the my
>> postulate that academia not being interested in the success of FP
>> is correct. With this sort of attitude we will no doubt see
>> funding for research in FP dwindling away in the near future.
-> I have to say that you are a bit wrong, Mike, and, please,
-> refrain from issuing useless threats.
Unfortunately, I don't think it's a useless threat. Industry
funds research not just for altruistic reasons, but also to get
something back. The assumption is that the research carried out
will benefit industry, even if it's not always obvious how this
happens. The only thing one can really do is to look at a track
record over, say, a decade or two. If useful things have come out
in the past, then funding will probably continue; if not, well...
-> Try instead to analyse the reasons of this situation which you
-> seem not to like, but which is much more painful for the
-> people within this fuzzy "Academia".
I think perhaps that closer cooperation in the form of workshops
and such may help to bridge the gap and help both sides understand
each other better. My suspicion is that cultural differences play
a large part.
Fergus Henderson
>Please, I don't think any of us think that statically typed languages
>are a bad idea. But a lot of us think that static typing isn't as
>important as many people like to think. Personally, I don't want to
>stop accademic institution working on esoteric type systems, but I do
>wish the functional programming community would also work on other
>things which are important for the software industry whose job it is
>to produce large and complex software systems.
[... list of research areas ... ]
>I would be very pleased if they could do research in these areas in
>the contex of functional programming languages. The functional
>programming accademia just aren't interested. Which means that all
>the excellent work being done in Haskell, Oz, Caml, SML, Mercury etc
>doesn't get (and won't get) the impact it deserves. This is a great
>shame.
and then followed up with
>There is a huge area for research. Due to the deathly
>silence of the "accademics" in resonse to this thread, I assume that the
>my postulate that academia not being interested in the success of FP is
>correct. With this sort of attitude we will no doubt see funding for
>research in FP dwindling away in the near future.
With provocative posts like that, you clearly want some replies ;-)
So, I'll do my best to oblige. Forgive me if I plug Mercury more than other
functional languages; it happens to be the one that I am most familiar with.
>For example:
>
>- Concurrency (modelling systems with a lot of explict concurrency)
Most of the modern functional languages support concurrency. Clean,
whose official name is Concurrent Clean, represents one approach to
that, which has been investigated in detail by the Clean group. There
are several different parallel/concurrent variants of Haskell around.
Mercury also has support for concurrency. And I've seen a reasonable
amount of research into formalizing such things (pi-calculus and so
forth).
>- Distribution (both to achieve scalability and to model systems which are
> inherently distributed)
The Oz group have done a lot of work on that.
Mercury has for quite some time now had an interface to CORBA,
implemented by Tyson Dowd and David Jeffery. We've also recently had a
summer student Ina Cheng who has been working on a SOAP interface for
Mercury.
>- SW configuration managment (source code control is only part of this)
Industry seems to be addressing that. And industry probably have a
much better understanding of the problems involved than academia, since
they are the ones who are trying to solve complicated configuration
management problems. So I'm not sure that this area is one for which
there is a big need for academic contributions. If you think there is,
perhaps you could elaborate?
>- Data bases integrated with language implementations
A group at Melbourne University have for a long time been working
on a deductive database called Aditi which has Mercury as its
programming language. The Mercury compiler supports generating
code in Aditi's Relational Language bytecode, and supports
several language extensions specifically for Aditi.
Unfortunately the long-awaited public release of Aditi has
still not yet happened, though I'm am regularly assured
that it will be released Real Soon Now.
Mercury also has an ODBC interface. So do some (many? most?)
other functional languages.
>- Changing code in running systems
We (the Mercury group) have been doing a bit of work on dynamic
linking -- supporting it, working out how to make it type-safe
(with various combinations of static and dynamic type-checking), etc.
That is not the same as changing code in running systems, but it is
something which far more applications need. The Haskell and Ocaml
communities have also been working on support for dynamic linking.
>- Reliability and high availability (for example N + M redundancy)
Researchers working on both Haskell and Mercury have done a bit of work
on reliability, in particular on how to add language support for
exception handling in a way that doesn't compromise the nice
declarative semantics and mathematical properties of our languages.
The Haskell implementors have taken this a bit further to look at
supporting asynchronous interrupts, while the Mercury community has
recently been looking at how to deal with issues that arise when
you combine exception handling with mutable objects expressed
using unique modes.
>- Man machine interfaces
The Oz group have done a bit of work with regard to that, in particular
with regard to constraint solving (I'm thinking about the Oz Explorer,
which shows a graphical color representation of the AND/OR search trees
that the constraint solver searches, allowing you to click on nodes to
expand sub-computations, etc.; Oz also comes with a nice Emacs/Xemacs
interface).
Mercury now comes with three different debuggers:
a traditional procedural one, with a gdb-like interface;
a declarative debugger, that asks the user questions about
the programs behaviour and from that seeks to infer the
An honours student at Monash University has recently started a project
which IIUC is aimed at implementing a graphical debugger for Mercury
and HAL.
The Mercury group has also received funding from Microsoft recently and
we might possibility be planning to spend some of that on work that
might be related to this topic, but I'm not sure whether that is
covered by NDA so I won't go into details on that now.
Another topic that you didn't mention but which has recently gathered
increasing academic attention is language interoperability. I know
that there has been quite a bit of work done on this by both the
Mercury and Haskell communities in the last year or two. I could
go into more detail here, but this post is probably long enough
already, isn't it?
Of course our resources are limited and we can't focus on all of
these issues. For Mercury, our main focus has been on making
logic programming practical and scalable, and we believe that
type systems and other kinds of static checking (e.g. modes,
determinism, unique modes, etc.) are an important part of that.
So we'll continue to work on those.
Andre van Straaten
[...snip...]
> On the other hand, even if we (teachers/researchers) cannot
> seriously complain that the industrial world is not encouraging
> us to teach or work on their problems, I think that people from
> out there should sometimes choose their words more carefully.
> How many times have we seen even here such rubbish as "if I were
> a software manager I would program only in C/C++"?
> In some other newsgroups the situation is even worse. The graphics
> people, the game programming folk who ask for algorithms and
> procedures, refuse to accept anything, but "C". They ask often
> quite simple questions, for example how to convert between colour
> spaces, demanding a concrete code. So I sent to one of them a piece
> of code in Haskell (or in Clean, I don't remember...). And, imagine,
> he insulted me in return, saying that he doesn't need stupid
> theoretical toys, but a *real program*.
[...snip...]
From my experience of 15 years in industrial embedded software
development, I must say that many sofware designers and managers are too
overworked to "sharpen their ax" or just doing their job for a living.
Because always under time pressure, they're looking for easy, ready-to-use
solutions. They have no time to pick up and try out new languages or read
through some CS books.
That is the "average programmer" some people in this thread use as an
argument. Unfortunately, that's a reality. (I could give you plenty of
funny/ridicolous examples including many of mine.)
Only if some companies come up with overwhelming successes, people
probably will ask, why this has been done using a "toy language".
That's the hard way, new inventions and science always had. But now,
science is gaining momentum.
Many people just don't realize that a computer is a mathematical machine.
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
The signs and the omens are everywhere
But too few see them - too few even care
(Lee Clayton - singer/songwriter, 1979)
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
graham
> Sean Hinde adds to the list of Mike Williams:
> [[what features are needed for serious impact of FP, and which
> seem to be neglected by teraching/research establishments]]
>
>>> - Concurrency (modelling systems with a lot of explict concurrency)
> ...
>>> - Data bases integrated with language implementations
>>> - etc, etc etc
>
>> I'm a bit surprised you missed out "Programming in the large".
>> It is hard to write a million line program without pretty major
>> support for this (especially without a static type checker ;) )
>
> Typed or not typed...
>
> Could somebody tell me - sincerely - how to organize our work at
> Universities in order to treat seriously the problem of writing
> programs with millions lines of code? I simply don't know.
> Is it a question of interest, or of resources?
If you want to treat this problem seriously in academia then I think
you need two projects. One is a million line program for doing
whatever. The other is your CS project for handling programming
in the large. The testbad for the CS project is the million line
program. Carefully chosing the million line program to be very
different from your CS interests would also help.
But can you get funding for such an approach?
graham
thomas...@bluetail.com
Ulf Wiger <Ulf....@ericsson.com> writes:
> This is by no means the first cooperation with academia. We had a
> man from the HIPE project working here and compiling some of our
> test benches to native code using the HIPE JIT compiler. Both we
> and the HIPE team learned some very interesting lessons: one was that
> our code behaved very differently from their micro benchmarks.
That man probably was me. The measurements of AXD301-over-HIPE
culminated some months later with the licentiate thesis of Erik
Johansson, after some struggles:
http://www.docs.uu.se/astec/Reports/Reports/9903.ps.gz
ftp://ftp.csd.uu.se/pub/papers/theses/0032.pdf.gz
AXD301 showed some significant differences from smaller benchmarks,
such as an 'inner loop' of a few hundred functions, with a nearly
flatlined profile.
Thomas
--
Thomas Lindgren thoma...@alteon.com
Alteon WebSystems
Hartmann Schaffer
> ...
>Thats what I mean. There is a huge area for research. Due to the deathly
>silence of the "accademics" in resonse to this thread, I assume that the
>my postulate that academia not being interested in the success of FP is
>correct. With this sort of attitude we will no doubt see funding for
>research in FP dwindling away in the near future.
how is "academia" supposed to set up research in this kind of research? they
don't have the funds, and i doubt that anybody in industry will come up soon
with the funds for a research project like this. ericsson seems to have done
something along those lines a while ago (is anybody free to provide some
internal information about the why and how?), but would they really embark
on a similar project that is not in anyway related to erlang?
hs
Zoltan Somogyi
>There is a huge area for research. Due to the deathly
>silence of the "accademics" in resonse to this thread, I assume that the
>my postulate that academia not being interested in the success of FP is
>correct. With this sort of attitude we will no doubt see funding for
>research in FP dwindling away in the near future.
I find that an ironic statement. I can't speak for the other academics on this
newsgroup, but the reason why I have not posted in this thread in the last few
days was that I was busy finalizing a grant application, a research project
in the area of declarative languages that would eventually make them more
useful in industry.
I think a large part of the problem is the funding structure. In many
countries, including Australia, it is very hard to get an industrially oriented
project funded from government sources, because the funding agencies usually
try to make their budgets go further by insisting that such projects be
co-funded by industry; after all, they are the ones who will benefit from it.
If industry insists that they will not fund academics until those academics
have established a track record in industrially oriented projects, then the
academics are caught in a catch-22, and the prediction about the funding of
industrially-relevant projects dwindling away becomes a self-fulfilling
prophecy. The catch-22 becomes worse when people in industry are not willing
to learn about new opportunities for possible projects that could benefit them.
For example, in 1994 Ericsson established a Software Engineering Research
Center at RMIT, about a kilometer from here. The people there do a lot of work
with Erlang. When it was set up, I offered the head of that Center a guided
tour of the Mercury system for him and/or for any of his researchers whenever
they considered it convenient. That offer still stands; it was never taken up.
The other problem with funding structures is that government research grants
are available only for work on novel concepts and techniques. They are not
available for reimplementing well-understood techniques in the novel languages
required for exploring those novel concepts and techniques, or even for
interfacing those novel languages to existing bodies of code. For example,
since integrated development environments are not new, this means that
there is no funding for implementing integrated development environments
for new languages. Unfortunately, industry is usually also uninterested
in funding such work. The resulting gap right in the middle of the technology
transfer process is why progress on the problems that prevent more widespread
use of declarative languages in industry (see e.g. Wadler's paper "Why
no one uses functional languages", SIGPLAN Notices 33(8):23-27, August 1998)
has been so slow. Many academics are interested in solving these problems.
If they appear disinterested, it is because they are tired of butting their
heads against the wall, which is what trying to convince people to fund
projects in this area feels like.
Zoltan Somogyi <z...@cs.mu.OZ.AU> http://www.cs.mu.oz.au/~zs/
Department of Computer Science and Software Engineering, Univ. of Melbourne
Ketil Z Malde
> mi...@erix.ericsson.se (Mike Williams) writes:
>>There is a huge area for research. Due to the deathly
> I think a large part of the problem is the funding structure.
I think another part of the problem is that we should differentiate
between computer science and software engineering - and while most
academic research seems to be comp.sci, the issues solved by Erlang
appears to be of the S.E. type.
While comp.sci prefers the reductionist/positivist approach, with lots
of mathematical background, I suspect programming-in-the-large
efficiency is harder to quantify - and consequently a less appealing
subject to the comp.sci researcher.
I have a feeling Erlang's advocates would get more results if they
turned to e.g. SEI or others involved in S.E, rather than criticize
comp.sci people for not solving S.E. problems.
(Just an opinion to which I'm probably not entitled, with a comp.sci
education doing software engineering work... :-)
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
Mike Williams
h...@paradise.nirvananet (Hartmann Schaffer) writes:
|> how is "academia" supposed to set up research in this kind of research? they
|> don't have the funds, and i doubt that anybody in industry will come up soon
|> with the funds for a research project like this.
If the volume of article in this news group are anything to judge by,
it seems possible to get research funding in research on type systems,
monads, verification, etc etc. But it is always easier to get research
funding if you can show that you are working in an area which is
significant to industry. So why is there so little work being done in
the FP area (I don't say no work) being done in the large scale
programming? I reiterate my original statement, it is because
"academia" aren't (really) interested in functional programming
succeeding.
Setting up co-operative projects with industry is hard, you have to
work with people who are mainly focussed on gettin products out to
customers and getting paid for doing to. It is much easier to
concentrate on doing things "in house" which don't require contact
with industry. I understand why this is so, but this isn't very
helpful in spreading the use of functional programming.
/Mike
Brad Knotwell
> Could somebody tell me - sincerely - how to organize our work at
> Universities in order to treat seriously the problem of writing
> programs with millions lines of code? I simply don't know.
> Is it a question of interest, or of resources?
Sorry. This'll take someone smarter than I am.
> This mythic entity called "Academia" needs mainly that. And some
> encouragement.
>
> Not only. I must say that I was terribly disappointed in Montreal,
> during ICFP when Philip Wadler announced that NOT A SINGLE ONE
> application paper has been accepted. I found it shocking, I asked
> why, And PW gave me the only answer he could: - papers were simply
> not good enough, either trivial or unreadable.
Why is this surprising? In every place I've worked (smaller companies),
people who write papers do them from a fict--marketing slant. In some ways,
I suspect functional programming academics might benefit from watching the
marketing hordes at work (wink). Similarly, industrial developers are
paid to create code while researchers are paid to create research.
Furthermore, I suspect the definition of a trivial and unreadable paper
depends on what side of the fence you're on (wink).
> I believe it would be a good idea to organize a PERSISTENT cycle
> of workshops, attached to international conferences, or separate,
> permiting to present unfinished projects, permitting to distil
> the delicate relation between the needs and the possibilities.
> The experience is something got only by experience.
Based on membership in several mailing lists, I often receive CFPs
for conferences quite far away. In my professional life, I will never
attend one of these conferences. OTOH, I've seen few such conferences
aimed at the industrial developer (Erlang has a user's conference and, in
the future, Ocaml apparently will as well).
I've worked in technology since 1991 (I wish I hadn't done that now. . .it
seems like a long time ;-). In this time, I've only ever personally met
one person who wrote production code in Common Lisp, 3 people who wrote
production code in Smalltalk, and a few other Cobol, RPGIV and Fortran
types. Pathetic as it sounds, functional programming is lonely in
industry. Kent Pitman once wrote about programming languages as a
political party. Until these last two paragraphs, I never really understood
what he meant.
> On the other hand, even if we (teachers/researchers) cannot
> seriously complain that the industrial world is not encouraging
> us to teach or work on their problems, I think that people from
> out there should sometimes choose their words more carefully.
>
>
> How many times have we seen even here such rubbish as "if I were
> a software manager I would program only in C/C++"?
In my current work environment, we deliver a highly-customized networking
stack as well as several user-land daemons and utilities. For the kernel
work (the majority of our added value), I've not seen anything really usable
in the functional arena at this point. With the exception of a few daemons
containing an ORB (I think Erlang and Mercury are the only two functional
languages with orbs), our user-land utilities are pretty simple.
FWIW, our CLI or web-based GUI could be a big win for a functional language,
but I don't think a functional language (typed at compile *or* runtime) would
be necessarily better than any reasonable interpreter.
From my perspective, integrating everything together is what drives us
crazy. Simple changes need to be reflected in too many different
places--the source code, the hard documentation, the soft documentation, the
IDL, the MIBS, and various configuration files. I enjoy functional
programming (I use them pretty much exclusively when I write programs
for personal use), but it's not clear how functional languages (or language
research at all for that matter) helps with this. I suppose, as one of my
favorite comp.lang.lispers would say, we don't write "important enough
programs" to see the benefits of a particular development environment.
> In some other newsgroups the situation is even worse. The graphics
> people, the game programming folk who ask for algorithms and
> procedures, refuse to accept anything, but "C". They ask often
> quite simple questions, for example how to convert between colour
> spaces, demanding a concrete code. So I sent to one of them a piece
> of code in Haskell (or in Clean, I don't remember...). And, imagine,
> he insulted me in return, saying that he doesn't need stupid
> theoretical toys, but a *real program*.
I can understand how you'd find that frustrating. From his perspective,
he now has to: download the language, compile it (maybe), and then figure
out how to build/run an executable (as a C guy, he'll expect it to be
standalone, not much fun in SML/NJ).
Was he an obnoxious jerk?? Of course he was. Was he out of line??
Obviously. Was he incorrect implying functional languages are theoretical
toys??? I dunno.
> Jerzy Karczmarczuk
> Caen, France
Sorry this was so long.
--Brad
Ulf Wiger
-> I think a large part of the problem is the funding structure. In
-> many countries, including Australia, it is very hard to get an
-> industrially oriented project funded from government sources,
-> because the funding agencies usually try to make their budgets go
-> further by insisting that such projects be co-funded by industry;
-> after all, they are the ones who will benefit from it.
I see your point, but their reasoning is flawed to say the least.
One main difference between industry solving its own problems and
industry and research solving them together is that in the latter
case, the results and methods will become publicly available.
Thus, the public benefits.
It's difficult to quantify the value of industrial projects
providing public insight into their problems and process, but to
most companies, this is seen as a significant contribution
(for one thing, published knowledge cannot be patented.)
When we invite researchers to work with us in our project, we
estimate that even if we don't help pay for their time, we still
have to pay for our own time that's spent assisting them. When
doing so, we have to count both direct and alternative costs
(i.e. the value of all the things we could have done if we weren't
busy helping out with research.) This is also sometimes very hard
to quantify.
George Russell
[snip]
> I think another part of the problem is that we should differentiate
> between computer science and software engineering - and while most
> academic research seems to be comp.sci, the issues solved by Erlang
> appears to be of the S.E. type.
I am now going to rant a bit, so don't expect all my statements to be
completely true. Academics aren't paid to write programs; they're paid
to write papers. Journals don't require papers to be based on useful
code; they require only prototypes. The typical prototype is abominably
coded, and usable only by the author. As the author is by this time off
devising another prototype for another paper, the prototype bites the
dust.
If you think I'm foaming at the mouth, look around at the typical programs
people use. Linux and FSF have probably done more for the general public
than 10000 academic papers, yet most of the technology they use was old hat
in the 80's, let alone now. Technology for building multi-level secure
operating systems was devised in the 1970s (see CAP for example), but has
hardly been applied, with the result that I get hoaxes passed to me by
friends who are worried that by opening an e-mail message they will trash
their computers.
The Erlang lot are proving that functional languages really can be used in the
real world. Good on them. I think we also should give a higher status to
programming. In the mathematical world, when someone has proved something in
one paper, it can be used easily in another, because the proof has been
peer-reviewed and there's a good chance it is actually correct. The same should
be true with programs in computer science, but in far too many cases isn't.
I think ideally I would like to see journals which publish papers describing
programming should also publish the programs (electronically), which should
be peer-reviewed. We would then have less published papers, but more useful
code.
Daniel C. Wang
mi...@erix.ericsson.se (Mike Williams) writes:
> In article <slrn9ag7...@paradise.nirvananet>,
> h...@paradise.nirvananet (Hartmann Schaffer) writes:
>
> |> how is "academia" supposed to set up research in this kind of research? they
> |> don't have the funds, and i doubt that anybody in industry will come up soon
> |> with the funds for a research project like this.
>
> If the volume of article in this news group are anything to judge by,
> it seems possible to get research funding in research on type systems,
> monads, verification, etc etc. But it is always easier to get research
> funding if you can show that you are working in an area which is
> significant to industry. So why is there so little work being done in
> the FP area (I don't say no work) being done in the large scale
> programming? I reiterate my original statement, it is because
> "academia" aren't (really) interested in functional programming
> succeeding.
{stuff deleted}
Academics are interested in getting tenure, which means you have to dangle
more than money in front of your average academic to get work done in an
area. There must be something tangible that they can show the tenure review
board so they can proper credit for the effort. This biases academic
research to already established areas where the metric for success is well
established and their are enough "big name" peers who can say "yes
he's/she's smart". Getting an academic community interested in new fields is
a hard thing. Or at least that's the cynics view point. :)
Or to put it another way, establishing a workshop/conference/journal, and
providing funding for research in an area is probably the best way to get
academics interested.
Ulf Wiger
o> But in industry/companies they think in "how much hours have you
o> worked?" and "does it looks like hard work?". I hate that way of
o> thining.
So to I, but I honestly don't see that kind of thinking where I am.
We are, however focused on results, so if you're idea of interesting
projects would be to port our entire system to haskell, we'd tell
go and stuff yourself. ;-)
o> So, when your company/boss awaits from you, to work more and
o> more, you know that this environment is dooming ideas, creativity
o> and humanity.
Good bosses understand the dynamics of creative thinking. There
are good bosses out there. You need to try and find them.
Markus Mottl
> but on the other side (I have worked in academic environment
> a short time) in academia there are no motivating goals, one have
> to achieve. It's boring, when you want to realize great things,
> but your environment is sleeping like "Schneewitchen" (don't
> know, how it's called in english).
Yes, I can to some part identify with this experience. The goal itself
is motivating and not unlikely to be reached successfully. The problem is
only that it costs a terrible amount of work (months or even years) to get
there and you get close to zero feedback in the meanwhile. Sometimes I'd
be happy if somebody told me that what I am doing is complete crap, but
maybe my ideas are so bad that they do not even deserve criticism... ;)
I had always thought of research as being a cooperative task, but (at
least in my experience) it is a rather lonely kind of work. Maybe I
have only been in the wrong places so far, but indeed, motivation is
significantly reduced by the constant lack of feedback.
> But in industry/companies they think in "how much hours
> have you worked?" and "does it looks like hard work?".
> I hate that way of thining.
It's also a physical problem. I have never met anybody (including me)
who could only be half as productive after, say, 8 hours of constant
programming (with little pauses) than during the beginning. In the
commercial sector it seems that people who work overtime are regarded
as especially productive. I think this is a big mistake: if I get
productive after so many hours of work only, then it is almost always
the case that I had just wasted time with irrelevant things before (=
bad time management).
> And that are the reasons, why industry don't get new ideas from
> academia. And the academic environment sleeps and don't get really
> motivating goals, because it doesn't really matter.
It seems that this is often the lack of good leadership qualities among
heads of research groups in academia that makes it difficult to get
(or keep) motivation. To summarize my experience here:
* The head of the research group has hardly any idea of what I am doing
(or trying to do).
* The rest of the research group has absolutely no idea of what I
am doing (or trying to do).
* I have no idea of what the others in the research group are doing.
* I have hardly any idea of what the head of the research group
is doing.
One could say now that the last two points could be addressed by
myself. Reality, however, shows that communication is a fairly difficult
matter. People show little inclination to speak about the internals of
their work and also don't feel too much motivation to take a look at other
people's work. Is this a common problem? Maybe productive communication
really needs moderation by the leader of the research group?
> People who has researched on creativity, say: The most ideas came
> to mind during a walk, or when sitting in the cafe.
> Less ideas came to mind while working.
What concerns me, it's mostly at the toilet or in the subway... ;)
Regards,
Markus Mottl
--
Markus Mottl, mo...@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl
Markus Mottl
> So to I, but I honestly don't see that kind of thinking where I am.
> We are, however focused on results, so if you're idea of interesting
> projects would be to port our entire system to haskell, we'd tell
> go and stuff yourself. ;-)
You see, you are already misunderstanding the motivating factors of
scientists: even if it is an extremely challenging task to port a system
the size of yours from one language to another language, it is not a
scientific activity, "just" (difficult) engineering work.
Even writing such a system from scratch isn't something I'd consider
particularly attractive (though interesting from a technical point of
view). It would be only a new way to do things, but scientists rather
look for new things to do...
> Good bosses understand the dynamics of creative thinking. There
> are good bosses out there. You need to try and find them.
If only we could! ;)
charles loboz
which seem to be important here:
- functionality/niche
- wider understanding of their advantages by _average_ programmers
ad functionality/niche
There is an undercurrent in the industry, very weak at the moment but
nonetheless existing - that the most important characteristic is
reliability. And current languages are not very good in producing a reliable
code. Removal of pointers from C++ (in Java) did help, but the code is not
much less buggy. It seems to me that we are at the edge - where complexity
breeds chaos. Stressing this part of the functionality of functional
languages may help here. We just need more examples and comparison studies.
ad understanding
The best functionality won't help if 'average' programmers will not be able
to grok it. And on _their_ terms, not functional language programmers terms.
I read recently Paul Hudak's book on Haskell. Something along these lines...
not elaborating too much on how nice and why fps are so good - but by coding
simple (and not so simple) programs in Haskell, showing how to do
animations, react to mouse etc. Hudak doesn't compare that code with an
imperative one (and explains why) - but for imperative programmers Hudak's
code speaks for itself. Though I'm not sure that this book is addressed to a
wide enough audience.
How about more comparisons of larger code chunks [doing reasonably realistic
stuff - not just quicksort] with standard imperativer programming and show
LOC [lines of code] counts as well as endless possibilities of introducing
bugs in imperative code - bugs which couldn't even exist in a functional
code? [all these iterators, indexes etc]? Stuff like that is terribly
convincing to managers and testers - even if 'real C++ programmers' may be
less enthusiastic about it.
Platform issue
Popularity among programming population is a real foundation. If you won't
convince programmers it will be difficult to influence managers.
Unfortunately trying to convince even most open-minded real programmers is
very difficult with the existing crop of functional languages. Because their
implementations are terribly substandard [apology for harsh words] in
comparison with the mainstream languages/platforms. I understand that sleek
implemenation is not a publishable paper. I don't have any answers to that.
But without half-decent implemenation it will simply not work.
If you can't connect and use existing COM or Java components, if your only
GUI is Tcl/Tk or some shaky subset of Windows you are a third class citizien
on contemporary platforms - in the industry. .NET architecture opens a way
for having sleek implementations of Haskell - being equal citiziens of that
platform. I hope this will happen. Then there will be more books showing how
to write some code in 100 lines instead of 1000 - and still being able to
use all the underlying platform. And have a development environment which
looks at least as good as Python - or maybe even as good as VisualStudio or
JBuilder.
apologies for verbosity, I just needed to get it off my chest. I am in the
industry and I see some possibilities. But I also see some wasted
opportunities. And not many ways to solve the problem of getting some real
science into mainstream programming. enough for today.
"Brad Knotwell" <knot...@ix.netcom.com> wrote in message
news:864rx38...@localhost.my.domain...
Oliver Bandel
George Russell <g...@tzi.de> wrote:
> Ketil Z Malde wrote:
> [snip]
>> I think another part of the problem is that we should differentiate
>> between computer science and software engineering - and while most
>> academic research seems to be comp.sci, the issues solved by Erlang
>> appears to be of the S.E. type.
> [snip]
> I am now going to rant a bit, so don't expect all my statements to be
> completely true. Academics aren't paid to write programs; they're paid
> to write papers. Journals don't require papers to be based on useful
> code; they require only prototypes. The typical prototype is abominably
> coded, and usable only by the author. As the author is by this time off
> devising another prototype for another paper, the prototype bites the
> dust.
> I think ideally I would like to see journals which publish papers describing
> programming should also publish the programs (electronically), which should
> be peer-reviewed. We would then have less published papers, but more useful
> code.
Where is a difference between program-code and papers?
Both are produced by text's.
What's about literate programming?
It's not a problem of C-programmers for doing no or
nearly no documentation. and comments in the sources
are not the same as literate programming.
(Explain what you are doing, which concepts... don't
explain the syntax of the language...)
Ciao,
Oliver
Oliver Bandel
Andre van Straaten <ne...@vanstraatensoft.com> wrote:
[...]
> From my experience of 15 years in industrial embedded software
> development, I must say that many sofware designers and managers are too
> overworked to "sharpen their ax" or just doing their job for a living.
Yes. That's a problem. In (big) industry (or smaller companies)
you always will be pushed to be faster, but often will be stopped
by communication-/coordination-problems.
When one is really interested in doing a good job, one normally
can't work in such a terrible environment. The academics may have
mor room for the mind. But in academics there is no motivating
goal.
In companies you got a heartattack and in academics you
get bored.
Aren't there any ways to do a god job as an programming-artist?
Workaholism is an addiction and this blocks creative energy,
Julia Cameron said. I see this in many smaller companies.
And when you want to do your best (that implies to do your job
in short time, not do the academic perfectionists meditation
over years), then it is seldom a way, you can go, because your
boss says: "Hey, man. You have to work more hours a week, as
we all do".
If you do that, you stuck.
Creativity isn't perpetuive doing. It needs time and freedom
to think. And that's, what academic environment want to assure.
but on the other side (I have worked in academic environment
a short time) in academia there are no motivating goals, one have
to achieve. It's boring, when you want to realize great things,
but your environment is sleeping like "Schneewitchen" (don't
know, how it's called in english).
You have time to contemplate, but if you get a solution or not,
or get it in one hour, one day or one year, it doesn't matter.
If you think on your work as an artist's artifact (as I do), then
you want to do the best, in shortest time, but you know that
the work must reach a state, where you can leave it into the
public, even if one could do many more optimizations; you can
do it in your next work.
But if you done your job, have created it, then you want to
go home and sleep for a while or sit in a cafe or pub and
watch the people. Then you don't want to sit in the company,
when you really think in projects.
But in industry/companies they think in "how much hours
have you worked?" and "does it looks like hard work?".
I hate that way of thining.
And that are the reasons, why industry don't get new ideas
from academia. And the academic environment sleeps and don't
get really motivating goals, because it doesn't really matter.
If they do their research, it may take decades to achieve,
what others are doing in hours, but not as perfect as the
academia.
So, what I want to say here, is: It's always the same problem,
why companies have problems. The problems are selfmade.
The people has to work more and more hours, because they work
too much. If you work too much, you have no free space for thinking.
You only work like a robot.
But one can't substitute thinking by working.
Any questions, why there aren't enough specialized
people, which are able to solve the it-problems of
the industry?
It's the industry itself, which stops their own
growing.
I call this madness.
> Because always under time pressure, they're looking for easy, ready-to-use
> solutions. They have no time to pick up and try out new languages or read
> through some CS books.
Yes, that is the problem.
And because they don't take the time, they get into trouble and
when this situation evolves, they work more instead of less and
so they don't see enough and the focus gets smaller and they
get deeper and deeper into the muddy waters.
> That is the "average programmer" some people in this thread use as an
> argument. Unfortunately, that's a reality. (I could give you plenty of
> funny/ridicolous examples including many of mine.)
> Only if some companies come up with overwhelming successes, people
> probably will ask, why this has been done using a "toy language".
Small companies often have the same problems: overworking and
underthinking.
People who has researched on creativity, say: The most ideas came
to mind during a walk, or when sitting in the cafe.
Less ideas came to mind while working.
So, when your company/boss awaits from you, to work more and more,
you know that this environment is dooming ideas, creativity and
humanity.
Work is for machines, not for humans!
Ciao,
Oliver
--
Remember, Information is not knowledge; Knowledge is not Wisdom;
Wisdom is not truth; Truth is not beauty; Beauty is not love;
Love is not music; Music is the best.
(Frank Zappa)
Simon Helsen
>I had always thought of research as being a cooperative task, but (at
>least in my experience) it is a rather lonely kind of work. Maybe I
>have only been in the wrong places so far, but indeed, motivation is
>significantly reduced by the constant lack of feedback.
I *absolutely* agree... that's why I love conferences (not because of the
boring talk I'm supposed to give ;-)
>It seems that this is often the lack of good leadership qualities among
>heads of research groups in academia that makes it difficult to get
>(or keep) motivation. To summarize my experience here:
>
> * The head of the research group has hardly any idea of what I am doing
> (or trying to do).
>
> * The rest of the research group has absolutely no idea of what I
> am doing (or trying to do).
>
> * I have no idea of what the others in the research group are doing.
>
> * I have hardly any idea of what the head of the research group
> is doing.
I've pretty much the same experience (not entirely true: my boss knows
very well what I'm doing, but I'm having the impression he's an exception
- besides, his time is limited). However, Marcus, I beleive this is a very
European problem and definitely a German one (or Austrian for that
matter). Your points above are my main motivation for not staying in
academics after my ph.d. And I'm sure I'm not alone in this case...
regards,
Simon
Alwyn Goodloe
There are a few academics like David Parnas and Daniel Jackson who do
work in software engineering. Unfortunately most of what is taught as
SE is really snippits about management. I couldn't concieve of serious
ME or EE doing something like the process model stuff that seemed to consume
much of SE lit. for about a decade. If you look at say a journal on
signals and systems or Control systems, they are working to apply
research done by pure scientists to solve problems. One thing they have
a set of interesting problems that aren't so large it takes years for
multi-person team to produce that never the less reflect the problems
that need to be solved in industry. Also note that they mostly talk about
DESIGN. By design I mean SYSTEMS, not algorithms. I will acknowledge
that the Squigol guys in Holland and the UK did great things in illustrating
how cleaver algorithms can be designed in FP.But algorithms aren't systems.
In fact most systems in industry don't have much in the way of complex
algorithms. If you want to convince industry that this paradigm is the
way to go (and I've said it before here) we need examples of designs.
The sort of things you see in those big fat UML books. I suspect that
a good functional design notation would result in far slicker solutions than
Booch and company could come up with using UML. As to where something like
this would get puplished, SP&E would be a good place. If you are convinced
the notation is mature, I think a book would be in order.
Alwyn Goodloe
agoo...@gradient.cis.upenn.edu
When they do talk about large systems they rarely go beyond design.
Wouldn't it be great if the next ICFP had
Oliver Bandel (oli...@first.in-berlin.de) wrote:
Markus Mottl
> On Sat, 17 Mar 2001, Markus Mottl wrote:
>>I had always thought of research as being a cooperative task, but (at
>>least in my experience) it is a rather lonely kind of work. Maybe I
>>have only been in the wrong places so far, but indeed, motivation is
>>significantly reduced by the constant lack of feedback.
> I *absolutely* agree... that's why I love conferences (not because of the
> boring talk I'm supposed to give ;-)
I am sure I'd love conferences, but I have to bear the costs myself
unless it is directly relevant to the project on which I work (and
even then it is not sure that I get a full refund). This, for instance,
rules out conferences on functional programming. :(
A former colleague of mine once participated in the USENIX conference
in the USA. Even though he gave a talk and though it was about his
topic of research (configuration management), he had to bear about 40%
of the costs himself, and you know how ridiculous an income researchers
get. He has already left academia...
> I've pretty much the same experience (not entirely true: my boss knows
> very well what I'm doing, but I'm having the impression he's an exception
> - besides, his time is limited). However, Marcus, I beleive this is a very
> European problem and definitely a German one (or Austrian for that
> matter). Your points above are my main motivation for not staying in
> academics after my ph.d. And I'm sure I'm not alone in this case...
Yes, I also believe that this is a very common problem in Europe and
maybe a particular problem for Austria (maybe also for Germany, but at
least funding of academic research is significantly better in Germany).
As soon as I complete my PhD, I'll probably have to leave to a foreign
country, irrespective of the choice for the academic or commercial sector.
Oliver Bandel
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
> Ulf Wiger <Ulf....@ericsson-cut-to-reply.com> wrote:
>> So to I, but I honestly don't see that kind of thinking where I am.
>> We are, however focused on results, so if you're idea of interesting
>> projects would be to port our entire system to haskell, we'd tell
>> go and stuff yourself. ;-)
> You see, you are already misunderstanding the motivating factors of
> scientists: even if it is an extremely challenging task to port a system
> the size of yours from one language to another language, it is not a
> scientific activity, "just" (difficult) engineering work.
> Even writing such a system from scratch isn't something I'd consider
> particularly attractive (though interesting from a technical point of
> view). It would be only a new way to do things, but scientists rather
> look for new things to do...
Well, both positions are ok but not matching completely.
It's boring to port a working solution from one language
to another. Why should one do this? If it's written in
ANSI-C, or even assembler, why should one port it to
an FP-language? It runs, one can use it, and thats ok.
Or in other words: if there is a new language:
Why should I learn it, when all things, we want to
realize/program/create are written in two minutes
in ANSI-C or Perl or so?!
And on the other side: If there are new problems to solve
and we hunger to do this in an elegent way and in short time,
we may look for a better solution than things we bring to
success in older projects. We may want to use some of the
old solutions, create new things, going new paths.
Why should we only be satisfied by new (or seemingly new (!!!))
problems to solve?
If we need ("want" doesn't match) ... if we NEED to go
new ways, we *must* go it!
It's both: New problems to solve and new ways, we can
solve it; and when a problem is solved, we can solve
more complex and complicated one next time.
And we go the same or similar or completely other ways,
when we want/need to do it.
But the decision, which way we go, should not be determined
by the sponsors or the boss or any other know-how-less people.
The decision may come from the developper/scientis/artist.
But if we are good in our craft/art, then the decision comes
from the work itself. From the flow, from the structure of
the problem and the path to acchieve a solution.
That's good working, this makes scientists/developers/artists
happy people. And if the bosses/managers would be able to
select the people who really are working in this way and
let them only do their work (and don't constrain them in any way),
but give them attention and acknowledgement (and pay them accurate),
then the work is done at least ten times faster, and unvaluable happier
people (on all sides) will live on this planet.
That's all.
Live could be so easy.
Ciao,
Oliver
Oliver Bandel
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
> Oliver Bandel <oli...@first.in-berlin.de> wrote:
>> but on the other side (I have worked in academic environment
>> a short time) in academia there are no motivating goals, one have
>> to achieve. It's boring, when you want to realize great things,
>> but your environment is sleeping like "Schneewitchen" (don't
>> know, how it's called in english).
> Yes, I can to some part identify with this experience. The goal itself
> is motivating and not unlikely to be reached successfully.
I think it's both: The path and the goal, or in other words,
the process AND the product.
It's often called western-hemisphere-thinking, when one focus
on the prooduct and eastern-hemisphere-thinking, when the
focus is on the process.
But it's both: the product AND the process, what must be "focussed"
on.
We normally have two eyes. So, why shouldn't we learn from the
chameleon? ;-)
> The problem is
> only that it costs a terrible amount of work (months or even years) to get
> there and you get close to zero feedback in the meanwhile. Sometimes I'd
> be happy if somebody told me that what I am doing is complete crap,
Ok, man. You know, that it's true: you always doing only plain,
shitty crap.
(Send me acknowledgements for that not per mail, write it in your
book(s) ;-))
> but
> maybe my ideas are so bad that they do not even deserve criticism... ;)
Oh, well, sorry, that I answer your postings. ;-)
> I had always thought of research as being a cooperative task, but (at
> least in my experience) it is a rather lonely kind of work.
"Regular" work as a developper: same problems. But I never wanted
to do work in a company, because of knowing, that such problems
will occur.
Now, I see that it is reality!
What a sh..... maybe I went to the wrong companies, but
remembering what Dilbert said.... I think it's not only
a personal problem. It's a problem of people (individuals)
and organization.
> Maybe I
> have only been in the wrong places so far, but indeed, motivation is
> significantly reduced by the constant lack of feedback.
Well, that's a problem, what I found too.
Many years ago, when I went to the computer, it was
playing, it was fun in itself. But now... maybe I'm too
old? Or is the reason that I searched for that even years
ago but I'm now at apoint, where impatience overcomes me
more frequently?
What the sense of programming/developping/scientists work?
I think, it's to be an artist.
Why one shouls solve the same problems every day?
When I know, how to declare and define variables in C,
then I want to create solutions.
When i can that in C, i want bigger/moree complex ones.
After that I may try to go further and use other languages.
Perl? O, Perl. Than: Ok, more complex, learning some OO-stuff.
Can do it in perl. Maybe choose ObjectiveC (C++ is crap, from
it'Äs deived jacva too). maybe Smalltalk? Oh, heard about
Lisp many years ago. Try it? Oh, Scheme is easier to learn
(no free minute -> learn Scheme first). Oh, well people say,
learn Lisp (Common Lisp) instead of Scheme, because it
has bigger libraries and is standardizes and more fp-like
than the minimalism Scheme ("What are programs to schemers
is only text for Lispers"). Ok, want to learn Lisp. Now read:
Lisp is shit, because of it's ad-hoc-modularization-crap...
Well. And what to do with this informations?
Does it change the world? Is it really play, like a child
with it's toy-train or puppets or more modern (crappy)
toys?
No, there are no real interesting problems. At work,
you program thousands of times the same shit. When
a new project arises, you have to use same languages
again, declae variables again, create header files instead
of doing your "real" work.
When done this, the next similar problem is there.
if you are good, you need more time at the beginning
and then, when you project-leader comes with new
"challenge", then you change or adds some lines in
your modularized code and acchieve things, your
project leader and "so called programing super-star"
needs weeks for!
And when ready with your work, he say: "oh, well, you
could do this and that better...". => FUCK!
And when your last working day is come, he wants to
see, if it's right documented (he, the project-leader,
unable to create one or two pages on paper).
Showing the documentation, he evry time finds new
holes in the cheese. But why should I quarrel/dispute
on the last day of work?
No, I enjoyed his face, when I - after he annoyed me
with "but this documentation is not enough and where
can i find blahg blah" - showed him the pdf-files
with project documentation, created with LateX/Xfig/PIC/groff
and other tools.
No, he never seen that before. And his tounge dried
because of his open moputh.
Is this a challenge?
When annoying people without any plan or iodea but with a big
mouth give you "challenging" problems to solve?
No, that is no challenge.
It's boring. But they even stress you in your new jobs again:
"faster, man, faster, there is no time to play".
And all people, which are following the instructions will
be acknowledged by getting a heartattack.
That's hell.
And - really - is it really sense, when you always program
little things? Alaways the same?
"I want to see my picture on the web."
"I want the sum of two columns of values."
"I want to save my telephon number into the computer."
and such stuff.
But i don't want to declare "int i" over and over again.
"Please let me write it down in more compact code."
"No, we don't allow you Perl. Use ANSI-C instead."
Or maybe one day, I want to use an FP-Language and they will say:
"no. Use Java, or Perl, Or C++."
And after all this waste: It's more fun to dance on stage than
to do always the same programming shit.
Mother Theresa had more fun than the programer, even if programmers
earn more money.
Yes, it's the feedback. There is no better feedback than
lucky people.
After starting with dancing I realized: That's pure playing.
No computer- and think-flow can be SO full of experience
like a good tap-dance.
So, why should I use languages which are waste, if even programming
itself is only a small part of what life coudl be?
Feedback? Yes, in dancing there is much more feedback.
It's playing, it's life itself.
Programming is cool; but it's not all.
If there is no real challenge (do i every day the same boring
things, only because my bosses/managers are only able to do the
same idealess lowlevel stuff every day of their whole fucking life?!)
or no goal (do I prevent people from hunger, when I choose this
or that language?) than it#s no wonder, that no one want to
do programming/developping, or being a scientist.
Sometimes I meet some people from the time of stuying.
Often the same problems: Our job isn#t as creative, as
we thought of.
Engineers - frustrated people. More interested in doing
explorative work like a scientist, or even at least developping
things, which are understood more deeply by scientists, but
developping as a creative challange...
And the reality is: All are frustrated, because they know
and can more than is needed and that's soooooooooooo boring.
I wonder why there are sooooo less suicides around.....
...maybee this needs creativity and that is what they have
unlearned over the years.
>> But in industry/companies they think in "how much hours
>> have you worked?" and "does it looks like hard work?".
>> I hate that way of thining.
> It's also a physical problem. I have never met anybody (including me)
> who could only be half as productive after, say, 8 hours of constant
> programming (with little pauses) than during the beginning.
I recently read a book on writinbg texts.
The author said: After three ore four ours of creative work,
there is no more energy.
That's what I think too: Let's do each day four hours of creative
work, then have two ours for organizing work. That's six hours a
day.
Then stop working, go home, or shopping, or dancing, in the theatre
or so. There you have fun, get new impressions and may have many
good ideas.
Next day you may explode of ideas... :-)
> In the
> commercial sector it seems that people who work overtime are regarded
> as especially productive.
Dibert says on teleworking, that you can sit at home in your pyjama,
hear music and play with your hand-puppets. If you have a generous
day, and do two hours of work, than it is more, you could acchieve
at the buro. (Because a buro is not organized for productivoity,
it's only organized/designed for working => and that's like
fire and water...).
Dilbert said true things.
I often wonder if the Dilbert-conmics are humor or
only good analyzed reality. I think it's both.
> I think this is a big mistake: if I get
> productive after so many hours of work only, then it is almost always
> the case that I had just wasted time with irrelevant things before (=
> bad time management).
Yes.
last time on work: One of my colleagues: "Oh, don't talk to me *now*!
When all works good, I have ONE productive hour a day. And then
the telephone rings or people annoy me."
Well, that's it.
When I'm at home, I seldom can sit around. I need to structure
time. There I can be productive. No one is there, destroying my thoughts.
At work (a *big* not a small buro), nothing is there for productive
doing.
I think, if I would try to use a language, not known by the
managers/bosses, they may want to conatrain me by using a
less-usable language because "it's better" (reasons: "blah blah").
>> And that are the reasons, why industry don't get new ideas from
>> academia. And the academic environment sleeps and don't get really
>> motivating goals, because it doesn't really matter.
> It seems that this is often the lack of good leadership qualities among
> heads of research groups in academia that makes it difficult to get
> (or keep) motivation. To summarize my experience here:
> * The head of the research group has hardly any idea of what I am doing
> (or trying to do).
> * The rest of the research group has absolutely no idea of what I
> am doing (or trying to do).
> * I have no idea of what the others in the research group are doing.
> * I have hardly any idea of what the head of the research group
> is doing.
That is no problem of academia only. in small and big companies it's
the same problem.
They say: "that's your work. Do it."
If you say: "I could integrate several other projects and problems
within my solution, if I get mor infomrations on the other projects"
(testing, if it is wanted by the deciders, to do that), one
get's only the answers, that this is not your work.
Do less but on demand, not more in independent ways.
Work, don't think!
Yes, work... donm't think... and work six hours, eight hours,
ten hours, twelve hours a day, and come on weekend.
And when you are burned out, we fire you, because you are a looser.
Yes, Workaholism is really an addiction!
I don't want to share my lifetime with junkies!
I want to be productive, have fun and meat people.
> One could say now that the last two points could be addressed by
> myself. Reality, however, shows that communication is a fairly difficult
> matter. People show little inclination to speak about the internals of
> their work and also don't feel too much motivation to take a look at other
> people's work. Is this a common problem?
I think, all people are creative. And all are artists - in their
particlular way.
And which artist lets look at his fingers before the premiere recital?
An artist needs a home, a place to create. An atelier.
When the work is ready for the public, it's time to show it.
No one wants to have big brother staying behind you, showing
over your shoulders. Creating is an act, which needs
intimacy/privacy.
From intimacy to intimate the result: It's more than playing
around with words...
> Maybe productive communication
> really needs moderation by the leader of the research group?
Social systems can't think and psychical systems can't communicate,
Niklas Luhmann said.
>> People who has researched on creativity, say: The most ideas came
>> to mind during a walk, or when sitting in the cafe.
>> Less ideas came to mind while working.
> What concerns me, it's mostly at the toilet or in the subway... ;)
May the drain be with you ;-)
Ciao,
Oliver
Oliver Bandel
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
> Oliver Bandel <oli...@first.in-berlin.de> wrote:
>> but on the other side (I have worked in academic environment
>> a short time) in academia there are no motivating goals, one have
>> to achieve. It's boring, when you want to realize great things,
>> but your environment is sleeping like "Schneewitchen" (don't
>> know, how it's called in english).
> Yes, I can to some part identify with this experience. The goal itself
> is motivating and not unlikely to be reached successfully.
I think it's both: The path and the goal, or in other words,
the process AND the product.
It's often called western-hemisphere-thinking, when one focus
on the prooduct and eastern-hemisphere-thinking, when the
focus is on the process.
But it's both: the product AND the process, what must be "focussed"
on.
We normally have two eyes. So, why shouldn't we learn from the
chameleon? ;-)
> The problem is
> only that it costs a terrible amount of work (months or even years) to get
> there and you get close to zero feedback in the meanwhile. Sometimes I'd
> be happy if somebody told me that what I am doing is complete crap,
Ok, man. You know, that it's true: you always doing only plain,
shitty crap.
(Send me acknowledgements for that not per mail, write it in your
book(s) ;-))
> but
> maybe my ideas are so bad that they do not even deserve criticism... ;)
Oh, well, sorry, that I answer your postings. ;-)
> I had always thought of research as being a cooperative task, but (at
> least in my experience) it is a rather lonely kind of work.
"Regular" work as a developper: same problems. But I never wanted
to do work in a company, because of knowing, that such problems
will occur.
Now, I see that it is reality!
What a sh..... maybe I went to the wrong companies, but
remembering what Dilbert said.... I think it's not only
a personal problem. It's a problem of people (individuals)
and organization.
> Maybe I
> have only been in the wrong places so far, but indeed, motivation is
> significantly reduced by the constant lack of feedback.
"challenge", then you needs fivteen minutes to
That's hell.
and such stuff.
>> But in industry/companies they think in "how much hours
>> have you worked?" and "does it looks like hard work?".
>> I hate that way of thining.
> It's also a physical problem. I have never met anybody (including me)
> who could only be half as productive after, say, 8 hours of constant
> programming (with little pauses) than during the beginning.
I recently read a book on writinbg texts.
The author said: After three ore four ours of creative work,
there is no more energy.
That's what I think too: Let's do each day four hours of creative
work, then have two ours for organizing work. That's six hours a
day.
Then stop working, go home, or shopping, or dancing, in the theatre
or so. There you have fun, get new impressions and may have many
good ideas.
Next day you may explode of ideas... :-)
> In the
> commercial sector it seems that people who work overtime are regarded
> as especially productive.
Dibert says on teleworking, that you can sit at home in your pyjama,
hear music and play with your hand-puppets. If you have a generous
day, and do two hours of work, than it is more, you could acchieve
at the buro. (Because a buro is not organized for productivoity,
it's only organized/designed for working => and that's like
fire and water...).
Dilbert said true things.
I often wonder if the Dilbert-conmics are humor or
only good analyzed reality. I think it's both.
> I think this is a big mistake: if I get
> productive after so many hours of work only, then it is almost always
> the case that I had just wasted time with irrelevant things before (=
> bad time management).
Yes.
last time on work: One of my colleagues: "Oh, don't talk to me *now*!
When all works good, I have ONE productive hour a day. And then
the telephone rings or people annoy me."
Well, that's it.
When I'm at home, I seldom can sit around. I need to structure
time. There I can be productive. No one is there, destroying my thoughts.
At work (a *big* not a small buro), nothing is there for productive
doing.
I think, if I would try to use a language, not known by the
managers/bosses, they may want to conatrain me by using a
less-usable language because "it's better" (reasons: "blah blah").
>> And that are the reasons, why industry don't get new ideas from
>> academia. And the academic environment sleeps and don't get really
>> motivating goals, because it doesn't really matter.
> It seems that this is often the lack of good leadership qualities among
> heads of research groups in academia that makes it difficult to get
> (or keep) motivation. To summarize my experience here:
> * The head of the research group has hardly any idea of what I am doing
> (or trying to do).
> * The rest of the research group has absolutely no idea of what I
> am doing (or trying to do).
> * I have no idea of what the others in the research group are doing.
> * I have hardly any idea of what the head of the research group
> is doing.
That is no problem of academia only. in small and big companies it's
the same problem.
They say: "that's your work. Do it."
If you say: "I could integrate several other projects and problems
within my solution, if I get mor infomrations on the other projects"
(testing, if it is wanted by the deciders, to do that), one
get's only the answers, that this is not your work.
Do less but on demand, not more in independent ways.
Work, don't think!
Yes, work... donm't think... and work six hours, eight hours,
ten hours, twelve hours a day, and come on weekend.
And when you are burned out, we fire you, because you are a looser.
Yes, Workaholism is really an addiction!
I don't want to share my lifetime with junkies!
I want to be productive, have fun and meat people.
> One could say now that the last two points could be addressed by
> myself. Reality, however, shows that communication is a fairly difficult
> matter. People show little inclination to speak about the internals of
> their work and also don't feel too much motivation to take a look at other
> people's work. Is this a common problem?
I think, all people are creative. And all are artists - in their
particlular way.
And which artist lets look at his fingers before the premiere recital?
An artist needs a home, a place to create. An atelier.
When the work is ready for the public, it's time to show it.
No one wants to have big brother staying behind you, showing
over your shoulders. Creating is an act, which needs
intimacy/privacy.
From intimacy to intimate the result: It's more than playing
around with words...
> Maybe productive communication
> really needs moderation by the leader of the research group?
Social systems can't think and psychical systems can't communicate,
Niklas Luhmann said.
>> People who has researched on creativity, say: The most ideas came
>> to mind during a walk, or when sitting in the cafe.
>> Less ideas came to mind while working.
> What concerns me, it's mostly at the toilet or in the subway... ;)
May the drain be with you ;-)
Ciao,
Oliver
Ulf Wiger
-> You see, you are already misunderstanding the motivating factors
-> of scientists: even if it is an extremely challenging task to
-> port a system the size of yours from one language to another
-> language, it is not a scientific activity, "just" (difficult)
-> engineering work.
I think I do understand. This can become a problem as scientists
and industry try to meet and work together. Industry will want a
deliverable that helps them make money -- if there is some
academically interesting part in there: fine, we can get some
scientists to help us; scientists attack the problem (because
the industry guy is paying them), but prefer to do only enough
of the dirty work as is needed to verify the concepts. Now he'll
go back and see if it can be done in a better way. To the
industry guy, this is the famous "90% done, 90% of the work left",
in other words, just another prototype. Useless.
I think part of the prize to pay when working with industry is that
you have to hang in there until your interesting ideas are actually
implemented _all the way_.
Markus Mottl
> I think part of the prize to pay when working with industry is that
> you have to hang in there until your interesting ideas are actually
> implemented _all the way_.
You mean: implement it all alone. That's exactly what I am doing now,
and it sucks. I like programming, but the project is simply too large
for one person. A team of, say, five somewhat competent programmers
(competent in FPLs, preferably OCaml) could do it within a few months.
Can you tell me, where I can find these people? I don't know anybody in
my closer vicinity who uses FPLs at all.
The reason is simple: due to the dark future of research (lack of
funding), most young researchers go the realist way and learn technology
that is demanded by industry (= not FPLs). This makes switching to
industry easier.
So we are in the position that academically biased projects lack man power
to implement interesting ideas. Because things don't get implemented,
industry isn't interested. My experience with the commercial sector
so far was mostly of the kind "Great! Implement it and we will sell it
for you!". A nicer way of saying "You do the work, we make the money.".
If you say "But I'd need a team for that.", they say "First show us that
it works."...
Brian Rogoff
> > I think part of the prize to pay when working with industry is that
> > you have to hang in there until your interesting ideas are actually
> > implemented _all the way_.
>
> You mean: implement it all alone. That's exactly what I am doing now,
> and it sucks. I like programming, but the project is simply too large
> for one person. A team of, say, five somewhat competent programmers
> (competent in FPLs, preferably OCaml) could do it within a few months.
E-mail me your resume when you're through screwing around in academia ;-).
The problem then is that we may not be working on exactly what you want,
but the programming language will be to your liking, and we'll have a
small group of programmers using that language (and loving it, thanks
Caml team!).
> Can you tell me, where I can find these people? I don't know anybody in
> my closer vicinity who uses FPLs at all.
You need to move to a better neighborhood.
> The reason is simple: due to the dark future of research (lack of
> funding), most young researchers go the realist way and learn technology
> that is demanded by industry (= not FPLs). This makes switching to
> industry easier.
I keep reading about "industry" in these threads as if all industry is
monolithic, either working on mega-telephony programs or doing web
scripting or COM programming. I assure you, that is not the case.
However, you're probably right about academia and the general boot-licking
and ass-kissing of popular technology. Just look at all of the SIGPLAN
crap on fixing that utter piece of shit Java language.
> So we are in the position that academically biased projects lack man power
> to implement interesting ideas. Because things don't get implemented,
> industry isn't interested. My experience with the commercial sector
> so far was mostly of the kind "Great! Implement it and we will sell it
> for you!". A nicer way of saying "You do the work, we make the money.".
> If you say "But I'd need a team for that.", they say "First show us that
> it works."...
Don't waste your time with these folks, this is the wrong approach. Notice
that Perl and Python were unknown languages not that long ago, and now
they're widely used. How did that happen? They found niches, exploited
them, dominated, and then grabbed more niches. What are some good niches
for your favorite languages? Are those niches important enough, and
exploitable enough?
Anyways, I shouldn't be posting this in response to Markus, since he
has my vote as the first recipient of the OCaml Advocate Of The Year
award ;-)
-- Brian
Markus Mottl
> E-mail me your resume when you're through screwing around in academia ;-).
Well, I'll hopefully finish my PhD sometime next year - still enough
time to decide what to do next... ;)
> I keep reading about "industry" in these threads as if all industry
> is monolithic, either working on mega-telephony programs or doing web
> scripting or COM programming. I assure you, that is not the case.
Almost the only kind of IT-jobs offered in my vicinity is media or B2B
stuff. Very inspiring... :(
> However, you're probably right about academia and the general
> boot-licking and ass-kissing of popular technology. Just look at all
> of the SIGPLAN crap on fixing that utter piece of shit Java language.
:-)
> Anyways, I shouldn't be posting this in response to Markus, since he
> has my vote as the first recipient of the OCaml Advocate Of The Year
> award ;-)
Thanks for the honours, but there are definitely many people who'd
deserve this much more...
Anyway, my bias for OCaml comes mostly out of pragmatic reasons: IMHO,
it's the most usable FPL-environment around, which doesn't mean that I
consider it to be the "best" or most beautiful language. It's currently
just the toughest boot in the fattest region of mainstream industrial
software engineering... ;)
Brian Rogoff
> Anyway, my bias for OCaml comes mostly out of pragmatic reasons: IMHO,
> it's the most usable FPL-environment around, which doesn't mean that I
> consider it to be the "best" or most beautiful language.
I agree, though I'd qualify that statement with "... for the kinds of
applications I work on", and maybe even with "most usable statically
typed FPL ...", in deference to the Erlang folks. I'd love to be able to
use Clean for non-toy projects since it has the elegance of Haskell and
handles arrays nicely (a must for many applications), but Clean is not
very Unix friendly so even if it were open sourced I'd have to pass.
Maybe in a few years that will change, but I doubt it. So that leaves
Mercury, Haskell, and SML. Of those I think Mercury is the most promising
"other than OCaml" language for me, since SML isn't that different from
OCaml, and the available Haskell compilers don't yet have the right
characteristics IMO.
Anyways, OCaml is also evolving (in good ways IMO) so if in a few years
time it supports generic polymorphism, recursive and first class modules,
and polymorphic recursion, it may well be the best and most beautiful FPL.
Wearing my "industrial" programmer's hat, it isn't so much these language
issues any more that hold us back, but documentation, and the lack of
certain mundane tools. Of all the new features of OCaml 3.01, my manager
was *thrilled* with the ability to get a stack backtrace in the bytecode
compiler. Everything else was just icing on the cake.
-- Brian
Stefan Axelsson
Ulf Wiger <Ulf....@ericsson.com> wrote:
>
>Building large and important products that sell for many millions
>of dollars is one pretty convincing argument, if you can do it
>with impressive speed and show consistently good quality and
>performance.
And even then it's not plain sailing... Since the parallel experiment
is never conducted you still have people who will blame every little
wart on (in this case) Erlang, and lamenting: "If only we were allowed
to do this in 'C' instead.")
It's enough to make you bloody weep.
Stefan,
--
Stefan Axelsson (For mail address see: http://www.ce.chalmers.se/staff/sax)
Ulf Wiger
-> Ulf Wiger <Ulf....@ericsson-cut-to-reply.com> wrote:
>> I think part of the prize to pay when working with industry is
>> that you have to hang in there until your interesting ideas are
>> actually implemented _all the way_.
-> You mean: implement it all alone. That's exactly what I am doing
-> now, and it sucks.
No, I did not mean that, but I can imagine that some industrial
projects have the nerve to suggest that. I wrote "hang in there until
[your ideas] are implemented _all the way_.
For your research to be really effective in an industrial setting,
you have to do it _together with_ people from the industrial project,
and they need to do most of the dirty work.
You, the scientist, need to get your hands somewhat dirty to
understand where they're coming from, and to gain some credibility
in their eyes. There are several dimensions to industrial-academic
cooperation, and one of the most important is education -- on both
sides.
You need to take active part in the process of actually making it
work in an industrial setting, because your intitial, elegant
models may not fit there; then you can either throw in the towel
and say "industry sucks", or change your models to fit.
("you", in this context is not to be read as "you, Markus".)
Ulf Wiger
-> Ulf Wiger <Ulf....@ericsson.com> wrote:
>> Building large and important products that sell for many
>> millions of dollars is one pretty convincing argument, if you can
>> do it with impressive speed and show consistently good quality
>> and performance.
-> And even then it's not plain sailing... Since the parallel
-> experiment is never conducted you still have people who will
-> blame every little wart on (in this case) Erlang, and lamenting:
-> "If only we were allowed to do this in 'C' instead.")
Well, some people just don't want to get it. ;-)
But then again others do...
I know people who have no love for Erlang who take their hats off
to any product that contributes significantly to company profits.
But then, the argumentation has to change a bit. It's no longer
interesting to extoll the virtues of Erlang (or other). What's
interesting is that you have something that works and makes a lot
of money for the company; and the question then is: how do we
protect this investment and gradually make it an attractive
mainstream offering.
(Some people will interpret that as slowly removing all strange
aspects like Erlang, and replacing it with Java, but that's another
discussion.)
Find the people with the money, and make friends with them. Learn
to speak their language. They usually don't want to finance crusades,
but like to finance profitable activities. Make them understand that
you're not the crusader: the others, who want to kill you, are.
Jerzy Karczmarczuk
> Find the people with the money, and make friends with them. Learn
> to speak their language.
...
Oh.
Would you mind publishing a sound, working algorithm on how to do
that (if possible: functionally...)?
I must say that I have heard that already. In Aristophanes or
some other ancient comics.
In Machiavelli as well. Some variants of this theme are worked
upon in the well known books by Dale Carnegie.
And despite all those theories and working examples, the world
is full of people who don't know how to make friends with rich
people (or enterprises). What a calamity.
Fortunately, the Darwinism works, and in a couple of centuries,
all they will perish, and the world will be finally populated
only by rich and their friends, all speaking the same language.
Jerzy Karczmarczuk
Caen, France.
thomas...@bluetail.com
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> Even writing such a system from scratch isn't something I'd consider
> particularly attractive (though interesting from a technical point of
> view). It would be only a new way to do things, but scientists rather
> look for new things to do...
(I'll mainly use the generic 'you' here.)
On the other hand, getting your hands dirty every now and then means
you will understand how your language will be used to a much greater
extent.
A programming language is a tool for using computers, and how do you
know your new hammer is any good if you never use it? How do you know
the fabulous experimental flange on the side actually helps in driving
in the nails? How can you defend your titanium-headed hammer if all
you can offer is opinion? And how do you even start thinking about
devising an ultimate intelligent hammer-replacement, if you're not
thinking deeply and knowledgably about the ultimate use of hammers?
Here's a relevant quote, posted by Christian Stapfer in this group
October last year.
»Where do the good questions, the research problems,
come from? .. One thing is sure: they do not come
from a vague desire to generalize. Almost the
opposite is true: the source of all great mathematics
is the special case, the concrete example.«
...
»A good stock of examples, as large as possible, is
indispensable for a thorough understanding of any
concept, and when I want to learn something new,
I make it my first job to build one.«
- Paul R. Halmos: 'I Want to be a Mathematician'
Well said, IMO.
Thomas
--
Thomas Lindgren thoma...@alteon.com
Alteon WebSystems
thomas...@bluetail.com
agoo...@gradient.cis.upenn.edu (Alwyn Goodloe) writes:
> There are a few academics like David Parnas and Daniel Jackson who do
> work in software engineering. Unfortunately most of what is taught as
> SE is really snippits about management. I couldn't concieve of serious
> ME or EE doing something like the process model stuff that seemed to consume
> much of SE lit. for about a decade.
Good point. This is probably why the issue of programming languages
seems to have been factored out of the SE equation. Or rather, one has
today substituted 'Java' or 'C++' for that variable. :-) This process
is normal for managers, who do not like to take too many independent
factors into account.
> If you look at say a journal on signals and systems or Control
> systems, they are working to apply research done by pure scientists
> to solve problems. One thing they have a set of interesting problems
> that aren't so large it takes years for multi-person team to produce
> that never the less reflect the problems that need to be solved in
> industry.
Again, good point. We do have a problem in that we _do_not_know_ what
problems are representative for industry, nor how they behave. (In the
second stage, it can also be very hard to reduce a big program into a
small one. But we're still at stage one today.)
In fact, I'll be very suspicious of anyone claiming a program to be
representative for 'industry', so stage zero is to segment our
industry into groups of somewhat similar problems.
Jerzy Karczmarczuk
Thomas Lindgren wrote:
> Markus Mottl writes:
>
> > ... but scientists rather
> > look for new things to do...
> On the other hand, getting your hands dirty every now and then means
> you will understand how your language will be used to a much greater
> extent.
>
> A programming language is a tool for using computers, and how do you
> know your new hammer is any good if you never use it? How do you know
> the fabulous experimental flange on the side actually helps in driving
> in the nails?
There is more to it than just producing a "tool for using computers".
Some people make experimental languages to play with non-orthodox
semantics, to exercise parsing algorithms, etc., From the notorious
French perspective: La Haute Couture is far from producing dresses,
gowns, trousers or coats for everyday use, but it became an Art, and
- also - a Science of Style. So, let those theoreticians who play with
languages do the same.
There is no need that *all* people work on the applicative side of
languages. The work may, and should be shared. If a physicist thinks
that "physics is a tool for an engineer", he is not a physicist, but
a slave of technologists. Our faculty (and liberty) to create
abstractions is essential for our progress.
One should not exaggerate, of course.
I'll tell you an anecdote.
One computer scientist whom I know, refused to accept for publication
a paper which elaborated some algorithms. The motivation for refusal
was: the author did not analyze thoroughly the complexity of his
algorithms.
I learnt about it in a casual conversation with this referee, and I
remarked:
"Look, but you, yourself, worked mainly on the complexity of quite
venerable algorithms, Gauss, Euler, etc. The very fact that *you*
worked on them means that the original authors did not analyze
thoroughly that complexity.
Would you refuse to publish their stuff?
Why don't you accept the fact, that people have different aims,
some of them want to deliver working applications, other to split
all the algorithmic hair in four. The creativity is not something
rigid. Who are you, to be the judge of this?"
The result was that paper has been rejected anyway, and as a side
effect I have now one more enemy of mine.
I don't like categoric people who *know* what, and how should
everything be done. This is a totalitarian, doctrinal view of
science.
On both [all] sides.
> Here's a relevant quote, posted by Christian Stapfer in this group
> October last year.
>
> »Where do the good questions, the research problems,
> come from? .. One thing is sure: they do not come
> from a vague desire to generalize. Almost the
> opposite is true: the source of all great mathematics
> is the special case, the concrete example.«
> ... ...
> - Paul R. Halmos: 'I Want to be a Mathematician'
Oh yes? Almost the opposite?
I wonder what would be the opinion of Halmos on works of such
people as Banach, Galois..., on the elaboration and the
development of non-euclidean geometry, and, say, on the theory
of categories.
On more practical mathematics: does somebody seriously suspect
that the General Theory of Relativity or the Gauge Field Theory
are based on concrete, special cases?
The desire to generalize may be *very far* from vagueness.
Jerzy Karczmarczuk
Caen, France
Markus Mottl
> Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
>> Even writing such a system from scratch isn't something I'd consider
>> particularly attractive (though interesting from a technical point of
>> view). It would be only a new way to do things, but scientists rather
>> look for new things to do...
> (I'll mainly use the generic 'you' here.)
So do I... ;)
> On the other hand, getting your hands dirty every now and then means
> you will understand how your language will be used to a much greater
> extent.
What do you mean with "getting your hands dirty"? If you mean "actually
implement something practically applicable", then you are definitely
wrong, because "we" actually spend quite some time with "practically
applicable" things already. No, it's usually not "another web server".
> A programming language is a tool for using computers, and how do you
> know your new hammer is any good if you never use it?
"We" take this as offense: do you really think that "we" spend most
of our time adoring the beauty of theoretically founded FPLs without
actually implementing anything?
> How do you know the fabulous experimental flange on the side actually
> helps in driving in the nails?
Because I use them intensly, and if they don't hold what they promise,
I abandone them. It's usually the case that less theoretically founded
things also fail in practice.
> How can you defend your titanium-headed hammer if all you can offer
> is opinion?
Pardon? This is probably equally offensive as if I said "How can you
defend your opinion that theoretically based languages are practically
useless if you neither understand theory nor use such languages.".
> »Where do the good questions, the research problems,
> come from? .. One thing is sure: they do not come
> from a vague desire to generalize. Almost the
> opposite is true: the source of all great mathematics
> is the special case, the concrete example.«
> ...
> »A good stock of examples, as large as possible, is
> indispensable for a thorough understanding of any
> concept, and when I want to learn something new,
> I make it my first job to build one.«
> - Paul R. Halmos: 'I Want to be a Mathematician'
Citing injustified claims doesn't make them any more valid. "The source
of all great mathematics is the special case." - Ah, really? Do you know
a *proof* for this? Or just a special case?
Andrew Cooke
Ignore it - software development includes people who are often unsure of
themselves, unsure of their skills, wary of change. They'll attack
whatever is new. I'm sure a good (sympathetic) manager could help a lot
with this kind of attitude, but it seems to occur everywhere... Of
course, you've got to make sure you're not ignoreing real problems :-)
Andrew
thomas...@bluetail.com
Jerzy Karczmarczuk <kar...@info.unicaen.fr> writes:
> There is more to it than just producing a "tool for using computers".
> Some people make experimental languages to play with non-orthodox
> semantics, to exercise parsing algorithms, etc.,
Sure, such languages are one form of research: exploring the
characteristics of parsing algorithms or non-orthodox semantics, for
the examples you mention. But are the languages as such a central part in
this?
> From the notorious French perspective: La Haute Couture is far from
> producing dresses, gowns, trousers or coats for everyday use, but it
> became an Art, and - also - a Science of Style. So, let those
> theoreticians who play with languages do the same.
As to your haberdashery metaphor, well, I hate to point it out, but
Haute Couture is also a highly commercial enterprise. Even if it uses
lofty words. (Even above and beyond those rarefied claims of the typical
grant application.)
> There is no need that *all* people work on the applicative side of
> languages. The work may, and should be shared.
Come on in, the water's fine.
> If a physicist thinks that "physics is a tool for an engineer", he
> is not a physicist, but a slave of technologists. Our faculty (and
> liberty) to create abstractions is essential for our progress.
The only way I can read this, given the context of the discussion, is
that you're saying those who work on practical languages, and who
modify the languages to suit the users, are slaves? Say it ain't so.
> /.../
> I don't like categoric people who *know* what, and how should
> everything be done. This is a totalitarian, doctrinal view of
> science.
>
> On both [all] sides.
I've been called a lot of things, but never a totalitarian (until now,
it seems). And all this for suggesting that looking at how a hammer is
used, or even going so far as to using one, can help you make a better
one.
I don't think creativity is _hindered_ by looking at the real world,
or by looking at what users need. Quite the opposite. Doing so
provides inspiration.
thomas...@bluetail.com
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> thomas...@bluetail.com wrote:
> > Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> >> Even writing such a system from scratch isn't something I'd consider
> >> particularly attractive (though interesting from a technical point of
> >> view). It would be only a new way to do things, but scientists rather
> >> look for new things to do...
>
> > (I'll mainly use the generic 'you' here.)
>
> So do I... ;)
>
> > On the other hand, getting your hands dirty every now and then means
> > you will understand how your language will be used to a much greater
> > extent.
>
> What do you mean with "getting your hands dirty"? If you mean "actually
> implement something practically applicable", then you are definitely
> wrong, because "we" actually spend quite some time with "practically
> applicable" things already. No, it's usually not "another web server".
/.../
Note again that I was not talking about you in particular. Sorry if I
was unclear on this point. If your (Markus's) application leads you to
insights into how to make a better programming language, then that's
basically what I was talking about. You needn't do web servers, I
promise.
In my (possibly controversial?) opinion, a programming language should
help the users write their applications as cleanly and painlessly as
possible. In order to attain this goal, the designer should take
actual use into account, which can be learned by working with the
language, by studying usage, or by soliciting opinions, say.
>> [quote of Halmos snipped]
> Citing injustified claims doesn't make them any more valid. "The source
> of all great mathematics is the special case." - Ah, really? Do you know
> a *proof* for this? Or just a special case?
Halmos isn't talking about a _mathematical_theory_ for where the good
questions come from.
Markus Mottl
> In my (possibly controversial?) opinion, a programming language should
> help the users write their applications as cleanly and painlessly as
> possible. In order to attain this goal, the designer should take
> actual use into account, which can be learned by working with the
> language, by studying usage, or by soliciting opinions, say.
And that's why we have C++, Perl, VB, Java, etc.: they help the users
write their applications as cleanly and painlessly as possible, surely
much more so than those useless and complicated academic languages which
were all developed in ivory towers. Really?
What lessons (from a design point of view) do languages like ML, Haskell
or Mercury have to learn from the languages above?
William Lee Irwin III
> And that's why we have C++, Perl, VB, Java, etc.: they help the users
> write their applications as cleanly and painlessly as possible,
> surely much more so than those useless and complicated academic
> languages which were all developed in ivory towers. Really?
Granted, if you're preaching, then I'm the choir, but this one made
me fall out of my chair laughing. Those are precisely what are
considered the dirtiest, nastiest, and ugliest languages in common use
by all of the imperative programmers I know.
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
> What lessons (from a design point of view) do languages like ML,
> Haskell or Mercury have to learn from the languages above?
Plenty: they seem like perfect examples of "what not to do".
Cheers,
Bill
Daniel C. Wang
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
{stuff deleted}
> And that's why we have C++, Perl, VB, Java, etc.: they help the users
> write their applications as cleanly and painlessly as possible, surely
> much more so than those useless and complicated academic languages which
> were all developed in ivory towers. Really?
>
> What lessons (from a design point of view) do languages like ML, Haskell
> or Mercury have to learn from the languages above?
The end user experience is important. A broken langauge with good tools and
loads of documentation and support, is better than a good language without
good tools or good documentation.
i.e. academic languages really can't compete without expending some energy
doing things not related to language design. Would Perl have been so popular
without the good O'Reily books? `
Markus Mottl
> The end user experience is important. A broken langauge with good
> tools and loads of documentation and support, is better than a good
> language without good tools or good documentation.
This was what I was expecting as answer. However, others were not
formulating it like this: we should really not be talking about
the "disadvantages" of academic languages, but about the lack of
(yes!) industrial support for those. Industry cannot expect researchers
and compiler implementors to write support tools and documentation for
even the dullest users.
> i.e. academic languages really can't compete without expending some
> energy doing things not related to language design. Would Perl have
> been so popular without the good O'Reily books? `
Probably not to this extent. I think that Perl really only took off in
this way when the O'Reilly books appeared on the market. One reason more
to exert pressure on O'Reilly to publish books on academic languages...
Daniel C. Wang
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
{suff deleted}
> Probably not to this extent. I think that Perl really only took off in
> this way when the O'Reilly books appeared on the market. One reason more
> to exert pressure on O'Reilly to publish books on academic languages...
Though an O'Reilly OCaml book would probably do wonders for
OCaml...
All of us with enough time to post on usenet, could at the very least try to
explain why all these "ivory tower" academic languages are really useful,
and why traditional approaches don't work.
When I get bored of my thesis, I hack a bit on a few evangelism papers aimed
at joe programmer. This actually helps me think about problems and explain
things to people who don't parse typeing judgements faster than english. :)
If there is a language feature that you think is critically important, it's
worth doing this sort of thing. One can easily write short accessible
articles with title's like
"What is parametric polymoprhims and why subtyping sucks?"
"Laziness: Is it a virtue?"
"Type-inference: Types without the typing."
"Dependent types: Arrays without bounds...."
Anyway you get the idea.... at the very least you could probably submit such
a paper to SIGPLAN Notices which seems to have a dirth of good submissions
these days.... or Doctor Dobb's Journal which still has a good developer
readership, and recently publsihed something by Phil Wadler that actually
explains the Curry Howard Isomorphism!
I'd love to see
"Top 10 langauge features that makes Erlang successful and why!"
"Top 10 langauge features that makes OCaml better than Java!"
"Top 10 design patterns built into every FPL"
Anyway, doing this sort of "marketing type paper" is a useful exercise as it
forces you to focus on the big picture without getting stuck in the
technical details.
My most recent little idea came after the usual prolonged debate about
static typing. It's no where near finished and contains lots of
mistakes.. but if you curious you can get it from
http://www.cs.princeton.edu/~danwang/drafts/wilt.ps
http://www.cs.princeton.edu/~danwang/drafts/wilt.pdf
Academics are expected to educate...
James Hague
news:995p5o$ra$1...@bird.wu-wien.ac.at...
> And that's why we have C++, Perl, VB, Java, etc.: they help the users
> write their applications as cleanly and painlessly as possible, surely
> much more so than those useless and complicated academic languages which
> were all developed in ivory towers. Really?
Now that's an interesting mix. You can make fun of C++ and Java. I've
certainly done my share. I scratch my head at how Java managed to get the
attention of *anyone*. But VB and Perl I can understand. Users don't look
at the language behind VB so much as they see it as a UI building tool for
creating database front ends. It does a better job for that sort of thing
than anything else, except direct competitors like Delphi. Perl is a tool
for ripping through text files quickly. It's ugly, and I don't understand
why Wall and friends want to keep turning it into a full blown C++
competitor (with references and OOP and so on), but it works well for the
type of thing it was originally designed for.
Academic languages can be great as well, if they are designed to actually
solve problems. Haskell is a thing of beauty, but it sure has stumped most
people who try to use it for larger applications. We can debate about typing
and laziness and monads, but in the end it doesn't get used. I think OCaml
is exactly on the right track, except it has to fight the uphill battle of
being a language without a specific niche. That is always tough. But it
doesn't matter too much, because it's useful, is industrial strength, and
can be used right now. That's great, IMO.
James
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Andre van Straaten
> Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> {suff deleted}
>> Probably not to this extent. I think that Perl really only took off in
>> this way when the O'Reilly books appeared on the market. One reason more
>> to exert pressure on O'Reilly to publish books on academic languages...
> Though an O'Reilly OCaml book would probably do wonders for
> OCaml...
You mean an English translation of the O'Reilly OCaml book.
I bought the O'Reilly book in French, and it is easily readable. Every feature comes with a
paragraph containing a short explanation and an example.
It's easier to read than the Perl and Python books, I have from O'Reilly.
It's comparable to the level of the O'Reilly C++ (chipmunk) book if someone knows that.
I learned French only in school and speak it fairly bad, but also the French text is very
technical and there are only a few words to look up in a dictionary.
Have a look under "Books" on http://www.ocaml.org.
It's the "horse book".
[... snip ..]
-- avs
Andre van Straaten
http://www.vanstraatensoft.com
The signs and the omens are everywhere
But too few see them - too few even care
(Lee Clayton - singer/songwriter, 1979)
Timothy Docker
"James Hague" <james...@volition-inc.com> writes:
> Academic languages can be great as well, if they are designed to actually
> solve problems. Haskell is a thing of beauty, but it sure has stumped most
> people who try to use it for larger applications. We can debate about typing
> and laziness and monads, but in the end it doesn't get used.
Is it true that attempts to write larger applications in Haskell have
failed, or is it just that the attempts have not been made? If the
former, what (mis)features have resulted in failure?
I'm not speaking from experience, but I can imagine the following
might cause problems in Haskell in application development
- Managment of time/space requirements due to lazy evaluation
- Lack of hierarchy in the module system
- Immaturity of tool set (eg debugging)
Anyone care to comment?
Tim
Hartmann Schaffer
thomas...@bluetail.com wrote:
> ...
>> If a physicist thinks that "physics is a tool for an engineer", he
>> is not a physicist, but a slave of technologists. Our faculty (and
>> liberty) to create abstractions is essential for our progress.
>
>The only way I can read this, given the context of the discussion, is
>that you're saying those who work on practical languages, and who
>modify the languages to suit the users, are slaves? Say it ain't so.
>
>> /.../
>> I don't like categoric people who *know* what, and how should
>> everything be done. This is a totalitarian, doctrinal view of
>> science.
>>
>> On both [all] sides.
>
>I've been called a lot of things, but never a totalitarian (until now,
>it seems). And all this for suggesting that looking at how a hammer is
>used, or even going so far as to using one, can help you make a better
>one.
>
>I don't think creativity is _hindered_ by looking at the real world,
>or by looking at what users need. Quite the opposite. Doing so
>provides inspiration.
i suspect both your positions are closer to each other's than comes through
in this exchange. ignoring input from "the real world (tm)" completely
tends to make academic research a somewhat sterile exercise, and demanding
that academia concentrate solely on what the industry thinks it needs would
still have us in a world where fortran, cobol, and basic rule
> ...
hs
Hartmann Schaffer
> ...
>formulating it like this: we should really not be talking about
>the "disadvantages" of academic languages, but about the lack of
>(yes!) industrial support for those. Industry cannot expect researchers
>and compiler implementors to write support tools and documentation for
>even the dullest users.
i'm afraid you are wrong there. with very few exceptions the decision
makers look at the cost of developing them, decide it is too much (because
it exists already for ...) and decide to go with the languages where they
don't have to make the investment.
>> i.e. academic languages really can't compete without expending some
>> energy doing things not related to language design. Would Perl have
>> been so popular without the good O'Reily books? `
>
>Probably not to this extent. I think that Perl really only took off in
>this way when the O'Reilly books appeared on the market. One reason more
>to exert pressure on O'Reilly to publish books on academic languages...
the only way you can exert that pressure is buying the books where they are
available from other publishers
hs
Hartmann Schaffer
>Daniel C. Wang <danwan...@cs.princeton.edu> wrote:
>
>> Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
>
>> {suff deleted}
>>> Probably not to this extent. I think that Perl really only took off in
>>> this way when the O'Reilly books appeared on the market. One reason more
>>> to exert pressure on O'Reilly to publish books on academic languages...
>
>> Though an O'Reilly OCaml book would probably do wonders for
>> OCaml...
>
>You mean an English translation of the O'Reilly OCaml book.
wasn't there some talk about a translation effort in english a while ago?
does anybody know what happened to it?
> ...
hs
Isabelle
> Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
>
> ...
> I'd love to see
> "Top 10 langauge features that makes Erlang successful and why!"
> "Top 10 langauge features that makes OCaml better than Java!"
> "Top 10 design patterns built into every FPL"
>
I am working in the industry, and using FPL - Clean to be specific - to build
quickly some reliable pieces of software I would consider a hassle to build
with, say C++/STL. Although there exists a considerable body of software
engineering literature, especially about "design patterns", for such languages
as C++/JAVA, there seems to be nothing of the sort to be found for FPLs -
without even talking about CASE tools and methodologies for large software
development -.
I would be very interested to hear about efforts at establishing a "catalogue"
of FPL design or programming patterns, as they are certainly practiced by
experts Functional Programmers. I suspect, however, that such patterns may be
more difficult to describe and categorize, because of the lack of an appropriate
- graphical ? - notation such as the various flavors of UML, Booch, .. that OO
people are accustomed to.
Does anybody out there know about such an initiative ?
Thanks, Fabien TODESCATO
PS.I remember of the beautiful book of Richard A.O.Keefe "The Craft of Prolog"
that here and there exemplified Prolog programming patterns...
Marcin 'Qrczak' Kowalczyk
> I'm not speaking from experience, but I can imagine the following
> might cause problems in Haskell in application development
>
> - Managment of time/space requirements due to lazy evaluation
> - Lack of hierarchy in the module system
> - Immaturity of tool set (eg debugging)
The lack of hierarchy in the module system is currently being worked on.
There is a mailing list libr...@haskell.org created for this subject
and related subjects (designing a concrete hierarchy for existing modules).
I agree that managment of time/space requirements due to lazy
evaluation can be a problem.
Another problem is that there are not so many libraries (GUI,
databases, Internet protocols, object persistency, efficient data
structures including imperative containers).
--
__("< Marcin Kowalczyk * qrc...@knm.org.pl http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTĘPCZA
QRCZAK
Sven Eric Panitz
Isabelle <isabelle....@libertysurf.fr> writes:
> "Daniel C. Wang" wrote:
>
> > Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> >
> > ...
> > I'd love to see
> > "Top 10 langauge features that makes Erlang successful and why!"
> > "Top 10 langauge features that makes OCaml better than Java!"
> > "Top 10 design patterns built into every FPL"
> >
>
[...]
> development -.
>
> I would be very interested to hear about efforts at establishing a "catalogue"
> of FPL design or programming patterns, as they are certainly practiced by
> experts Functional Programmers. I suspect, however, that such patterns may be
> more difficult to describe and categorize, because of the lack of an appropriate
> - graphical ? - notation such as the various flavors of UML, Booch, .. that OO
> people are accustomed to.
[...]
FP patterns?
map, fold, Monads ...
and were do we find them? In the Prelude.
I suspect a bit that design patterns in the OO world are needed
since OO languages are not powerful enough to provide generic
libraries.
I never felt the need for a graphical language like UML to describe
patterns in FP. FPs are far more expressive and to the point than
such design languages.
I think this is a big advantage of FP: your code is easy to read
and close to the problem description. There is no need to learn a
different formalism to specify things.
On another level some nice cookbooks would be very helpful, which
deal with solutions like:
* how do I write this or that graphical component in Clean
* how is TCP/IP properly done in Haskell/Clean/OCaml...
* how to make data base transactions in Haskell/Clean/OCaml...
sven eric
--
______________________________________________________________
Sven Eric Panitz Uhlandstr. 12
Software AG s...@softwareag.com D-64297 Darmstadt
(+49)6151-92-1426 _________ ... but I say it just to reach you
Jerzy Karczmarczuk
...
> > If a physicist thinks that "physics is a tool for an engineer", he
> > is not a physicist, but a slave of technologists. Our faculty (and
> > liberty) to create abstractions is essential for our progress.
>
> The only way I can read this, given the context of the discussion, is
> that you're saying those who work on practical languages, and who
> modify the languages to suit the users, are slaves? Say it ain't so.
Would you mind trying to *understand* my words? I never said that.
I work on applicative side of functional programming myself. I just
disagree with categorical statements of some (especially quite young)
people whose reductionist attitude is pushed <<ad absurdum>>, who
negate the usefulness of abstract analysis, of "pure", not applied
comp. science.
I said, and I repeated that there is place for everybody, for those
who create abstractions, for the implementors, for the analysts. The
same is valid wrt. physics. Please read carefully the cited fragment
before you write "the only way I can read this...". Your implication
is very far from any rationale.
About the Haute Couture you say:
> As to your haberdashery metaphor, well, I hate to point it out, but
> Haute Couture is also a highly commercial enterprise. Even if it uses
> lofty words. (Even above and beyond those rarefied claims of the typical
> grant application.)
Now, I hate to point it out, but I am sorry for all these poor people
who see money and money everything, and who are unable to admire
some creations just for pleasure. Haberdashery, la Haute Cuisine,
music, mathematics, etc.
Finally I said:
> > I don't like categoric people who *know* what, and how should
> > everything be done. This is a totalitarian, doctrinal view of
> > science.
> >
> > On both [all] sides.
> I've been called a lot of things, but never a totalitarian (until now,
> it seems). And all this for suggesting that looking at how a hammer is
> used, or even going so far as to using one, can help you make a better
> one.
I am not calling *you* totalitarian. In particular not because you see
some usefulness in testing hammers (although I see a little too much
hammering in your style of expression). I am criticizing such viewpoints
as that about programming languages who are just tools to make
computers run. That the end user (especially somebody financially
interested) should be the main criterion of choosing the research
directions. This is important, but whenever the freedom to create
was enslaved in the name of "applicability", the creation stopped.
You say:
> I don't think creativity is _hindered_ by looking at the real world,
> or by looking at what users need. Quite the opposite. Doing so
> provides inspiration.
Nobody ever negated that, and if you knew me better you would know
that I expressed publicly the same feeling. But I would never dare
to say that people who prefer to close their eyes and to liberate
their abstract imagination are wrong. It is from them that we may
learn what the word "freedom" means. The inspiration doesn't
necessarily come from bottom-up. Do you think that applied physics
works in such a way: a rich fellow says -
"Hey, folks, I WANT TO INSPIRE YOU, I have some money, and I think
that it would be nice if you invented something called laser, which
we badly need".
And, as far as the computer science is concerned, and the programming
languages in general, I am still waiting for ANY industrial organism
to say anything inspiring. ///Apart from trivialities, such as: we
need efficiency, good documentation, good interfacing, and plenty of
cheap, but very good code for our immediate use///.
Jerzy Karczmarczuk
Caen, France
Kellom{ki Pertti
> I never felt the need for a graphical language like UML to describe
> patterns in FP. FPs are far more expressive and to the point than
> such design languages.
It should not be very surprising that UML not very useful for
describing FP programs, because UML is about describing objects with
local mutable state. However, ...
> I think this is a big advantage of FP: your code is easy to read
> and close to the problem description. There is no need to learn a
> different formalism to specify things.
... I would be very disapppointed if FP's are really the ultimate
level of abstraction that we can reach. FP code may be able to
describe an implementation more concisely, but it is still at the
implementation level.
What I am referring to here is e.g. that in a distributed system you
may want to specify operations that involve spatially separate objects
in which parts of the operations happen at different times. Describing
such operations may involve variables that do not exist in an
implementation at all.
If one can use a FP language as a wide spectrum language all the way
from requirements specification to actual implementation, all the
better. Somehow I doubt that, though.
--
Pertti Kellom\"aki, Tampere Univ. of Technology, Software Systems Lab
Robert Virding
Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
>This was what I was expecting as answer. However, others were not
>formulating it like this: we should really not be talking about
>the "disadvantages" of academic languages, but about the lack of
>(yes!) industrial support for those. Industry cannot expect researchers
>and compiler implementors to write support tools and documentation for
>even the dullest users.
This is where you most definitely are wrong! If researchers have any
interest in the fruits of there research being used, which in the long
run they must, then they must take the time and effort to produce
quality systems and to work at spreading them. Unless you/they are
prepared to do this then most industry will deem that work to be
uninteresting and ignore it.
The only exception seems to be where you already have converts in
industry who can take on the work. But then, why should they do your
work and plug your stuff instead of their own things?
This is rather painful fact of life actually took us a while to grasp
when we were trying to spread Erlang, and other stuff, in Ericsson.
It is hard enough to get people to use new technology as it is, but
first expecting them to spend a few years developing tools,
documentation and training first is completely unrealistic. The end
descision makers are seldom interested in the really cool theory
underlying your language/whatever but rather in the tangible gains
they can get by using it. And that is up to you to SHOW them!
The only reasons for Erlang being used today in products is that it
has been shown in other products and *realistic* prototypes to be good
at solving *real* problems, and that there is a production quality
system with full support and extras available.
If you are serious in getting Haskell or ML or CamL or MottLang or
... seriously used in industry then you must be prepared to do the
work. that is all there is too it!
>> i.e. academic languages really can't compete without expending some
>> energy doing things not related to language design. Would Perl have
>> been so popular without the good O'Reily books? `
>
>Probably not to this extent. I think that Perl really only took off in
>this way when the O'Reilly books appeared on the market. One reason more
>to exert pressure on O'Reilly to publish books on academic languages...
O'Reilly, or any other publisher, will only publish a book which they
are reasonably cerain will sell and which they will make a profit on.
They are not a charity organisation. You have to interest them.
Unfortunately academic institutions today are not really organised
today to extend effort in spreading their technology. No researcher
gets credit for time spent in technology transfer. Perhaps more
industry money should be spent more here than in basic research?
Robert
--
Robert Virding Tel: +46 (0)8 545 55 017
Alteon Web Systems Email: r...@bluetail.com
S:t Eriksgatan 44 WWW: http://www.bluetail.com/~rv
SE-112 34 Stockholm, SWEDEN
"Folk säger att jag inte bryr mig om någonting, men det skiter jag i".
Markus Mottl
> * how is TCP/IP properly done in Haskell/Clean/OCaml...
What concerns OCaml, it implements all Unix-system calls and can
even emulate those on all platforms that use different calling
conventions. This means that you only need to get good books on TCP/IP
(e.g. by Richard Stevens - probably *the* standard) and can apply the
examples in a straightforward manner.
OCaml also implements some more abstract functions that simplify common
TCP/IP tasks, e.g. to write servers. For example, here is a forking
echo server (on port 9000):
open Unix
let echo ic oc =
try while true do Printf.fprintf oc "%s\n" (input_line ic); flush oc done
with End_of_file -> ()
let _ = establish_server echo (ADDR_INET (inet_addr_any, 9000))
Jerzy Karczmarczuk
> Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
> >... we should really not be talking about
> >the "disadvantages" of academic languages, but about the lack of
> >(yes!) industrial support for those. Industry cannot expect researchers
> >and compiler implementors to write support tools and documentation for
> >even the dullest users.
> This is where you most definitely are wrong! If researchers have any
> interest in the fruits of there research being used, which in the long
> run they must, then they must take the time and effort to produce
> quality systems and to work at spreading them.
...
> O'Reilly, or any other publisher, will only publish a book which they
> are reasonably cerain will sell and which they will make a profit on.
> They are not a charity organisation. You have to interest them.
>
> Unfortunately academic institutions today are not really organised
> today to extend effort in spreading their technology. ...
Academic institutions are not charity organisations whose aim is
to promote industrials who think only about their own profit.
Researchers/teachers are not prophets whose dream is to provide
more money for profit-oriented organisms by "spreading the Word".
This is *your* business to interest academic institutions,
government educational agencies, etc. This is important for us,
but - I believe - we do everything we can. We even teach such
monstrosities as Perl, just for your pleasure.
Always when we look for enterprises who could take our graduates
for a 1- 4 month stage, very badly paid (if at all), I feel like
a beggar. "They" do us favour by exploiting our young birds!
And, too often, the first thing they do is to tell them:
"Now, you will learn a bit of REAL STUFF. All that you have learnt
at the university is academic rubbish. Don't even try to convince
anybody here to use your exquisit languages. Adapt yourself to
us, otherwise...!"
==
You say something a bit hilarious:
"they must take the time and effort to produce quality systems ..."
??????
Could you please devote a bit of your preciou$$$ time to see what
are the mechanisms which rule academic institutions? And then, try
to address your remarks not to us, but to institutions responsible
for our funding. Institutions who decide how many positions are
there, how many hours of teaching per week we have to ensure, etc.
I think I will filter out this thread, I am wasting my time and effort,
I could spend on producing a quality system worth spreading.
Jerzy Karczmarczuk
Caen, France
Markus Mottl
> This is where you most definitely are wrong! If researchers have
> any interest in the fruits of there research being used, which in the
> long run they must, then they must take the time and effort to produce
> quality systems and to work at spreading them. Unless you/they are
> prepared to do this then most industry will deem that work to be
> uninteresting and ignore it.
If you give us the funding to do this, you could get it. But where is
funding? At our institute diploma engineers (MSc-level) can expect a
net-income of not even $9 per hour: we just cannot afford more! It's
ridiculous to demand from us to write GUIs, books on "Language X for
dummies" or whatever if we do not have the resources. A competent engineer
can expect several times this income in industry. No wonder that they
are not interested in working in academic research environments.
If we did what you expect, we wouldn't have enough time to do academic
work (e.g. publish articles; do teaching; stupid administrative things
that the ministry wants us to do; etc.). In this case government would
even cut the miserable funding we already have.
What you are essentially saying is that researchers shouldn't do the
"interesting" work only but also the "dirty" work (= *all* work) and do
this as cheaply as currently. Sorry, but what you need is obviously not
researchers but slaves!
> The only exception seems to be where you already have converts in
> industry who can take on the work. But then, why should they do your
> work and plug your stuff instead of their own things?
Our work? Our work is research, I don't know what your's is.
> This is rather painful fact of life actually took us a while to grasp
> when we were trying to spread Erlang, and other stuff, in Ericsson.
And now imagine how tough it is if you do not even get a fraction of
the funding.
> It is hard enough to get people to use new technology as it is,
> but first expecting them to spend a few years developing tools,
> documentation and training first is completely unrealistic.
Give us funding to employ engineering staff.
INRIA is currently trying to build up a consortium with industry partners
to get funding for less research oriented things. Although I am in doubt
whether it will work out this way, there it is: it's up to you now to
show your interest in advanced technology.
As we use to say: "No money, no music".
> The end descision makers are seldom interested in the really cool
> theory underlying your language/whatever but rather in the tangible
> gains they can get by using it. And that is up to you to SHOW them!
The compiler technology of many modern FPLs is significantly better than
anything I have ever seen from industry. But it is obviously not good
compilers that industry needs but nice applications to make colorful
GUIs and books that are simple enough so that even managers can read them
(sorry for my sarcasm).
> The only reasons for Erlang being used today in products is that it has
> been shown in other products and *realistic* prototypes to be good at
> solving *real* problems, and that there is a production quality system
> with full support and extras available.
The only reason why Erlang is used today is because you have had
sufficient funding.
> O'Reilly, or any other publisher, will only publish a book which they
> are reasonably cerain will sell and which they will make a profit on.
> They are not a charity organisation. You have to interest them.
That's the common problem of highly competitive markets: companies are so
risk-averse that they only start investing when you can make immediate
profit. In other terms: they don't have enough incentive to invest into
the future.
> Unfortunately academic institutions today are not really organised
> today to extend effort in spreading their technology. No researcher
> gets credit for time spent in technology transfer. Perhaps more
> industry money should be spent more here than in basic research?
More money should be spend on both basic *and* applied research and
especially the former! E.g. in Austria, funding for basic research is
not even half as high as for applied research. There is not much money
that you can shift here. For example, the FWF (the largest public fund
for academic research in Austria) has a volume of about $600 million.
Large corporations probably spend more money on postal stamps...
And kick government out of university administration to solve the
"organisation problem" (it's luckily withdrawing slowly but steadily now).
Andre van Straaten
> ...
> ==
> ??????
> Jerzy Karczmarczuk
> Caen, France
That's absolutely right.
There are so many different kinds of companies and academic
institutions, overall in different countries with different
policies, and therefore so many different viewpoints.
The interaction between industry and research, or science and
money, might not only be interesting, but also important for
many people in this newsgroup, but it has really the stuff for
an endless thread.
Mark Carroll
Marcin 'Qrczak' Kowalczyk <qrc...@knm.org.pl> wrote:
(snip)
>Another problem is that there are not so many libraries (GUI,
>databases, Internet protocols, object persistency, efficient data
>structures including imperative containers).
Absolutely. One of the things that would probably be a big factor in
encouraging us to use a "non-mainstream" language commercially is the
availability of such libraries. Of course, there's probably something
of a chicken-and-egg situation here...
-- Mark
Ulf Wiger
-> Robert Virding <r...@bluetail.com> wrote:
>> This is where you most definitely are wrong! If researchers
>> have any interest in the fruits of there research being used,
>> which in the long run they must, then they must take the time and
>> effort to produce quality systems and to work at spreading them.
>> Unless you/they are prepared to do this then most industry will
>> deem that work to be uninteresting and ignore it.
-> If you give us the funding to do this, you could get it. But
-> where is funding?
Forgive me Markus, but you're probably asking the wrong guy. (:
I'd be surprised if Robert decided to fund technology transfer of
yet another functional language.
I recommend that you read Bjarne Däcker's thesis:
"Concurrent Functional Programming for Telecommunications:
A Case Study of Technology Introduction"
http://www.ericsson.se/cslab/publications/bjarnelic.ps
In it, chapter 4.2: "Steps towards a product", you will find the
following passages:
"The Erlang design team consisting of Joe Armstrong, Mike Williams
and Robert Virding started experimenting" ... "Joe wrote the compiler,
Mike the emulator and Robert the design libraries."
In other words, Robert is basically describing what he and his
colleagues did once with Erlang.
-> What you are essentially saying is that researchers shouldn't do
-> the "interesting" work only but also the "dirty" work (= *all*
-> work) and do this as cheaply as currently. Sorry, but what you
-> need is obviously not researchers but slaves!
That is not nearly *all* work. That's the beginning. Then, someone
will have to build products on the foundation that you provide.
That's expensive and risky.
Technology transfer is a very tricky thing. I think lots more could
be done to make it work better. There seems to be tremendous
resistance on both sides, for various reasons. Both industry and
academia must work together in a much more flexible and creative
way than what's usually the case.
/Uffe
--
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
Ulf Wiger
Sven> I never felt the need for a graphical language like UML to
Sven> describe patterns in FP. FPs are far more expressive and to
Sven> the point than such design languages. I think this is a big
Sven> advantage of FP: your code is easy to read and close to the
Sven> problem description. There is no need to learn a different
Sven> formalism to specify things.
There *is* a need to describe things with graphical models, or
rather a well established notation.
While I agree that functional languages raise the level of
the source code, "the source code is the documentation" really
only works for the developers of a particular language.
Personally, I feel that way about Erlang programs, but I'm not that
great at browsing Haskell or OCaml code, since I don't program in
those languages.
I sit next to some absolutely first-rate system architectures who
don't share my enthusiasm about reading the Erlang code in order
to figure out what's going on. I don't blame them for that.
Ulf Wiger
-> This is *your* business to interest academic institutions,
-> government educational agencies, etc. This is important for us,
-> but - I believe - we do everything we can. We even teach such
-> monstrosities as Perl, just for your pleasure.
-> Could you please devote a bit of your preciou$$$ time to see what
-> are the mechanisms which rule academic institutions?
A former fighter pilot once told me this:
You need to build a thousand bridges to be called a bridge
builder, but you only need to suck one **** to be called a
**********.
(fighter pilot lingo censored.)
Just for the record (it's been posted on this newsgroup before.)
The Bluetail guys are not Perl hackers without a clue about what
it takes to introduce functional programs in industry.
When people from Bluetail post here, you don't have to agree with
them, but many of them have spent over a decade trying to get
Erlang accepted in industry. If they don't volunteer to spread
*your* language, you may want to forgive them for that.
Having written that, I will let them fend for themselves. (:
Ulf Wiger
>> I sit next to some absolutely first-rate system architectures who
Forgive me, I meant "first-rate architects".
There's nothing first-rate about the architecture in the industrial
area where I sit.
James Hague
>
> This is where you most definitely are wrong! If researchers have any
> interest in the fruits of there research being used, which in the long
> run they must, then they must take the time and effort to produce
> quality systems and to work at spreading them.
This is true even to the point where a poorer language with a reliable and
comfortable implementation is much, much preferred to a better language with
a flakey environment. I even think this is a a big part in language
popularity, Java excepted. Languages that have harder times are those that
require Emacs, don't have proper Windows versions because of personal issues
on the part of the developers, are pains to install, only run in
non-resizable console windows without any any command line editing
facilities, and come in monstrous tar files that seem out of line with what
a language does for you. Some examples:
Good, in this respect:
1. Python - Hugely portable, simple to use, comfortable interpreter.
2. Perl - Ditto. Perl is ugly, but it is reliable and simple to fire up.
3. OCaml for Linux - Excellent suite of tools and just about bullet-proof.
4. Erlang for Windows & Linux - Well thought-out shell interface, impossible
to crash. Windows version has a nice front-end plus it doesn't require any
external tools like Perl or Cygwin to run. Nice HTML documentation.
5. Hugs for Windows - Really simple and easy to use.
Bad:
1. Any of the Haskell compilers for Windows - Ugh. Can anyone get any of
these to work? Need a zillion extra tools.
2. OCaml for Windows - Awful GUI shell, plus you need MASM and Visual C++.
3. Mercury for Windows - Gigantic download, needs Cygwin, needs gcc.
4. Mozart/Oz for Windows - Emacs-centric..
5. Clean for Windows - No interactive mode, clunky GUI.
James
Markus Mottl
> Forgive me Markus, but you're probably asking the wrong guy. (:
> I'd be surprised if Robert decided to fund technology transfer of
> yet another functional language.
This is probably a question on which you may not be allowed to give
an answer, but anyway: how much money did it cost (personnel and other
resources) to make Erlang accepted within Ericsson alone?
> "The Erlang design team consisting of Joe Armstrong, Mike Williams
> and Robert Virding started experimenting" ... "Joe wrote the compiler,
> Mike the emulator and Robert the design libraries."
That's only the initial phase. I don't think that things would have
worked out so well if you hadn't managed to draw other Ericsson staff
(= resources) into your project.
> That is not nearly *all* work. That's the beginning. Then, someone
> will have to build products on the foundation that you provide.
> That's expensive and risky.
Right. And how comes that researchers should bear both the expenses and
the risk? Even more so considering their lack of funding?
> Technology transfer is a very tricky thing. I think lots more could
> be done to make it work better. There seems to be tremendous
> resistance on both sides, for various reasons. Both industry and
> academia must work together in a much more flexible and creative
> way than what's usually the case.
The only kind of resistance on my side is that I don't see why researchers
should do all the work so that industry can make the money afterwards. If
it is industry who benefits from technology transfer, it is only natural
to ask them to bear the expenses and risk. This is the minimum one can
demand as return for the service.
Maybe one of the reasons why funding for academic projects is so low is
that industry (or even privat people) cannot easily speculate on returns
from such projects. Whether you donate something or not will probably not
make a big difference if you are the only one that does so. Therefore,
it is actually not really rational (though it would be moral) to donate
for such projects.
I had once proposed that industry could trade some kind of voting shares
of academic projects on virtual markets: these shares give them the right
to vote in yearly meetings for what to develop next. If the project is
likely to succeed, this will make other companies want to steer this
development, too, so as to influence it in their favour. This again
would raise the price for these shares, and the project could distribute
further shares, thus raising further money.
This might allow "pure" speculators (people not directly benefiting from
the product as such) to "donate" (rather: invest) money, which increases
the number of potential investors significantly. Because the shares are
tradable, one could always make profit in the meantime by speculation,
even if the project finally fails.
I don't know whether this has already been tried in some form or the
other. It would be interesting to see such an experiment.
Markus Mottl
> Bad:
> 2. OCaml for Windows - Awful GUI shell, plus you need MASM and Visual C++.
That's not fair: you do not need MASM and Visual C if you want to compile
byte code only or use the toplevel interpreter. Most other language
environments you mentioned cannot even compile to native code. It's
not OCaml's fault if Windows doesn't come with assemblers and linkers
by default.
Furthermore, if you have Cygwin you can make full use of the native code
compiler under Windows. Even the whole Unix-library is portable then! So
your argument lacks the point.
What concerns the GUI shell: if you don't like it, why do you use it? I
haven't tried them under Windows, but are Perl or Python really any
better in this respect?
Brian Rogoff
> "Daniel C. Wang" wrote:
> > I'd love to see
> > "Top 10 langauge features that makes Erlang successful and why!"
> > "Top 10 langauge features that makes OCaml better than Java!"
> > "Top 10 design patterns built into every FPL"
>
> I am working in the industry, and using FPL - Clean to be specific - to build
> quickly some reliable pieces of software I would consider a hassle to build
> with, say C++/STL. Although there exists a considerable body of software
> engineering literature, especially about "design patterns", for such languages
> as C++/JAVA, there seems to be nothing of the sort to be found for FPLs -
> without even talking about CASE tools and methodologies for large software
> development -.
>
> I would be very interested to hear about efforts at establishing a "catalogue"
> of FPL design or programming patterns, as they are certainly practiced by
> experts Functional Programmers.
That's a great idea! It might even be helpful to start posting such
"design patterns" here on this newsgroup, instead of posting long rants
whining about industry and academia. A while ago I posted some simple
ML code on comp.lang.ml in response to a Python programmer who wanted to
know what's great about ML (really, FP) and the *examples* were more
convincing than arguments.
I suspect those FPers who disparage design patterns as being an OO only
thing, useless to FP, don't know what they're talking about. Obviously the
FP patterns will be different from OO ones, but the idea of a design
pattern is a bit more general than OO or FP. Anyone who has played chess
knows various tactical (forks, pins, x-ray attacks) and strategic patterns
that help their game. The patterns will differ in the different languages,
for instance Clean and Haskell don't need to implement lazy evaluation
with a pattern, but that's part of the fun.
One interesting pattern to consider is CPS. It's usually shown on trivial
problems, but it is applicable to things like combinatorial search. It is
interesting to write such programs in say ML and then write an equivalent
one in a good imperative language like Ada (or an awful one like Java or
C++ ;-). I've done this and it is quite educational.
Monads are another related interesting "pattern". There is a neat paper
by Norman Ramsey applying monadic style error combinators in SML. Sven
Panitz mentions folds and kin. There is the "list of successes" technique
for simulating non-determinism. I could go on, but I'll stop and go
extract some code...
> I suspect, however, that such patterns may be more difficult to
> describe and categorize, because of the lack of an appropriate
> - graphical ? - notation such as the various flavors of UML, Booch,
> .. that OO people are accustomed to.
I don't know of such a graphical notation, but I haven't felt the need
yet.
> Does anybody out there know about such an initiative ?
How abot hashing something out here?
> Thanks, Fabien TODESCATO
>
> PS.I remember of the beautiful book of Richard A.O.Keefe "The Craft of Prolog"
> that here and there exemplified Prolog programming patterns...
Robert Harper's online SML book is similar. Anyways, I think this is a
good idea. What have you come up with for Clean? It would be good to see
more Clean code in this newsgroup!
-- Brian
Mattias Waldau
> Markus Mottl <mo...@miss.wu-wien.ac.at> writes:
>
> {suff deleted}
> > Probably not to this extent. I think that Perl really only took off in
> > this way when the O'Reilly books appeared on the market. One reason more
> > to exert pressure on O'Reilly to publish books on academic languages...
>
> Though an O'Reilly OCaml book would probably do wonders for
> OCaml...
>
Books are important. Information about features in FP-languages are also
very important, for example before I saw Ocaml I assumed incorrectly that
all FP-languages didn't have allow any side-effects (Ocaml allows mutable)
and didn't support OO (which Ocaml allows, however OO assumes side-effects).
Without these features, you can't use a FP as an all-purpose language.
I believe in all-purpose languages, since even if the language is easy
to learn, the libraries are much harder.
(I would really like a standard library. :-)
So I think the following is important
0. A good language, not a pure language.
1. One language should be able to solve almost all your problems
2. Good documentation of language and of language patterns
3. A good library (Why not implement the Java-library in other languages,
it will shorten the learning curve dramatically!)
/mattias
P.s I found Ocaml the following way:
Prolog -> Typed Prolog (Typical 0.6) -> Mercury -> ICFP-competition -> OCaml.
Mark Carroll
Markus Mottl <mo...@miss.wu-wien.ac.at> wrote:
(snip)
>Furthermore, if you have Cygwin you can make full use of the native code
>compiler under Windows. Even the whole Unix-library is portable then! So
You may want to update http://www.ocaml.org/ocaml/portability.html,
then, given the "A Microsoft Windows ... port ... is
distributed. ... the native-code compiler needs the Microsoft MASM
assembler and Visual C++ compiler."
This is one of the reasons I hadn't gone with OCaml to date. Some
Haskell and ML things seem quite close to where they have to be before
I'll think about using them commercially; I just wish I could choose
the best from each different compiler and union these things
together. (-:
-- Mark
Markus Mottl
> [...] and the *examples* were more convincing than arguments.
As usual - but even examples are not guaranteed to convince the most
ferocious discussion opponents...
> I suspect those FPers who disparage design patterns as being an OO only
> thing, useless to FP, don't know what they're talking about.
When mentioning "design patterns", most people (that I have seen mention
them) really mean those as described by Gamma et al., though he has
surely not intended to reduce this term to the OO-only use.
> I don't know of such a graphical notation, but I haven't felt the
> need yet.
The only thing where I find graphical notation useful is to show
dependencies among large sets of modules to get a quick idea of how a
system is structured.
Joachim Durchholz
>
> The only kind of resistance on my side is that I don't see why
> researchers should do all the work so that industry can make
> the money afterwards. If it is industry who benefits from
> technology transfer, it is only natural to ask them to bear
> the expenses and risk. This is the minimum one can demand as
> return for the service.
Well, industry won't pay for it unless you can make a reasonable claim
that the results will be worth the expense.
And here's the crux: you can make as many claims on the issue as you
wish, you cannot prove it. Oh, you may be able to prove the advantages
of a new programming language is you use it, but that won't help the
industry decision-maker when he tries to guess how his under-educated
programmers will cope with the new language.
Besides, you're essentially asking him to throw most of the acquired
knowledge away and starting from scratch, turning experiences
programmers in (relative) newbies and reducing the productivity of the
IT department by a considerable amount, for a considerable time. Or can
you *guarantee* him that the department will be productive within half a
year, at least to the level at which it was before? Would you bet your
personal income on that? Under the very real threat that the change may
be shot down because the programmers revolt against the change? (This is
what most managers do with such a decision, in one or the other form.)
Of course, if the person you're talking to has influence over enough
resources that he can set aside an entire team and let them experiment
for a year, then the change is feasible. The team may succeed or fail,
but that doesn't matter if the IT department is several hundred people.
(Aside note: This is why large companies are the first to adopt new
technology. Small companies simply can't afford failure, or even the
risk of failure.)
The problem with the large-department approach is that you must be very
lucky to find an IT department head who knows enough about programming
so that you can convince him with technical arguments. (Marketing
arguments won't be heard. Leave the hype to those who can spend millions
on it.)
Another aside note: While I see many interesting things in functional
programming, I'm still not convinced that everything should be done
functionally.
> Maybe one of the reasons why funding for academic projects is
> so low is that industry (or even privat people) cannot easily
> speculate on returns from such projects. Whether you donate
> something or not will probably not make a big difference if you
> are the only one that does so. Therefore, it is actually not
> really rational (though it would be moral) to donate for such
> projects.
This sounds very similar to one of the main arguments of the Open Source
movement: that software development should be a public activity, driven
by donations (and, consequently, the results being available to the
public).
> I had once proposed that industry could trade some kind of
> voting shares of academic projects on virtual markets: these
> shares give them the right to vote in yearly meetings for what
> to develop next. If the project is likely to succeed, this will
> make other companies want to steer this development, too, so as
> to influence it in their favour. This again would raise the price
> for these shares, and the project could distribute further shares,
> thus raising further money.
Nice idea... but you'll have problems keeping those out who want to
destroy a project because it's endangering one of their product.
Besides, markets aren't very good at predicting the success of a new
endeavour. Even historically, funding has been a huge problem: Columbus
searched for investors for years. Gutenberg had his press confiscated to
pay debts. The much-hyped New Economy has just broken down.
> This might allow "pure" speculators (people not directly
> benefiting from the product as such) to "donate" (rather:
> invest) money, which increases the number of potential
> investors significantly. Because the shares are tradable,
> one could always make profit in the meantime by speculation,
> even if the project finally fails.
That's exactly the logic that drove the New Market. Unfortunately, too
many investors jumped the wagon without knowing enough about the risks,
starting a speculative bubble which just recently collapsed.
> I don't know whether this has already been tried in some
> form or the other. It would be interesting to see such an
> experiment.
As I said. See the Internet Economy. I don't expect that scientific
research would fare much better - you're asking people with financial
knowledge to understand and evaluate complex technical issues. This
isn't going to work.
Besides, the outcome is often unpredictable. In the 18th century, when
the steam engine was invented, there was no indication that steam-driven
railroads could make you filthy rich while steam-driven automobiles were
a dead end. This kind of foresight simply isn't available to humans or
markets.
(And then there's the usual argument: if it were that easy, it would
have been done decades or centuries ago.)
Regards,
Joachim
--
This is not an official statement from my employer.
Joachim Durchholz
>
> This is true even to the point where a poorer language with a reliable
and
> comfortable implementation is much, much preferred to a better
language with
> a flakey environment. I even think this is a a big part in language
> popularity, Java excepted.
Huh? I always though Java is the example par excellence for this rule,
with broad library support? What I have seen of Java libraries wasn't
all that bad either - not that I have seen much of it, so I'd be
interested to hear some informed opinions on that.
> Good, in this respect:
>
> [...]
> 5. Hugs for Windows - Really simple and easy to use.
Hugs is bad at least on Win 95. Sluggish as hell, and you can't even
cut&paste source code into the console.
One of the last announcements said that Hugs doesn't take up all CPU
cycles anymore (I forgot whether that's just for Win 95 or for Windows
in general). Guys, you're claiming Haskell is one of the best languages
around: how does it come that the previous shell had a Stone Age
construct in it, a Busy Wait? If that was the simplest construct for a
quick implementation (and why else should it have been part of the
system): will I make similar mistakes when I want to use Haskell for my
own projects?
Note that I'm not talking about the real qualities that Haskell may or
may not have, I'm talking about those signs and omens that I'm forced to
rely on - I simply can't spend a year of my life programming in Haskell
just to find out whether it's for me or not. I've got other demands on
my free time, such as a certain amount of active social life (does this
make me a geek in a programming newsgroup? <grin>)
James Hague
> That's not fair: you do not need MASM and Visual C if you want to compile
> byte code only or use the toplevel interpreter. Most other language
> environments you mentioned cannot even compile to native code. It's
> not OCaml's fault if Windows doesn't come with assemblers and linkers
> by default.
You can say what you like here, but that doesn't change the fact that having
to own Visual C++ to make full use of OCaml is a pain.
> Furthermore, if you have Cygwin you can make full use of the native code
> compiler under Windows. Even the whole Unix-library is portable then! So
> your argument lacks the point.
I know lots of people who won't touch Windows don't realize this, but Cygwin
is disgusting. It's not something you want to force people to install.Why
limit your audience? It's like telling Linux people "To use this, all you
have to do is install WINE!"
> What concerns the GUI shell: if you don't like it, why do you use it? I
> haven't tried them under Windows, but are Perl or Python really any
> better in this respect?
I have downloaded REBOL, which has a plain little window with a scroll bar,
command history, command completion, etc. Nothing fancy; it probably took a
week at most to write, but it sure feels nice compared to a DOS window
without any command line editing other than backspace. I have used Erlang,
which has similar facilities. Corman Lisp? Same. Perl and Python are funny
cases. Perl isn't interactive, so it doesn't matter. Python has an
interactive mode, but it isn't really for writing programs; it's just a way
to play around. I have used OCaml's GUI for the Mac, BTW, and it is
excellent. Again, it is just a simple thing, not some awful IDE, but it is
pleasant to use.
My point here is not to criticize particular language implementations, just
to point out that little things like:
1. Not relying on lots of external tools.
2. Having a comfortable shell.
3. Running under Windows in a clean manner.
are what make tools feel good to use. These things are often not given
priority among language implementors, and can unfortunately keep more people
from looking at their languages.
Daniel C. Wang
Sven Eric Panitz <s...@softwareag.com> writes:
{stuff deleted}
> FP patterns?
> map, fold, Monads ...
> and were do we find them? In the Prelude.
>
> I suspect a bit that design patterns in the OO world are needed
> since OO languages are not powerful enough to provide generic
> libraries.
>
> I never felt the need for a graphical language like UML to describe
> patterns in FP. FPs are far more expressive and to the point than
> such design languages.
{stuff deleted}
This is the kind of statement is that needs to be written out for Joe/Jane
programmer. Many FPL folks will probably read the sentence and say
".. probably right" but unless you can explain it to Joe/Jane programmer
they never are going to get past "gee what's FPL good for".
If you've got time to post to Usenet, you can surely hack up a web page that
elaborates this point in more detail! :)
Joachim Durchholz
>
> That's not fair: you do not need MASM and Visual C if you want to
compile
> byte code only or use the toplevel interpreter. Most other language
> environments you mentioned cannot even compile to native code. It's
> not OCaml's fault if Windows doesn't come with assemblers and linkers
> by default.
No, but somehow many other languages do without.
> Furthermore, if you have Cygwin you can make full use of the native
code
> compiler under Windows. Even the whole Unix-library is portable then!
So
> your argument lacks the point.
Installing Cygwin is still a challenge. It's just alien concepts that
will leave a Windows user (even a Windows power-user) baffled. (Just as
I'm struggling with Unix right now. How do I get POP3 mail into my local
mail directory? Under Windows, there's no such thing as a mail
directory... and I don't even know how this type of program is called so
I don't know what to look for in the usual download servers. Such are
the stumbling blocks that make the transition from Unix to Windows or
vice versa a real challenge.)
Ulf Wiger
-> Ulf Wiger <Ulf....@ericsson.com> wrote:
>> Forgive me Markus, but you're probably asking the wrong guy. (:
>> I'd be surprised if Robert decided to fund technology transfer of
>> yet another functional language.
-> This is probably a question on which you may not be allowed to
-> give an answer, but anyway: how much money did it cost (personnel
-> and other resources) to make Erlang accepted within Ericsson
-> alone?
I don't know if I'm allowed or not, but I don't have that number,
and I wouldn't venture a guess. As technologies go, however, I'd
say Erlang came at a bargain prize.
Again, if you read Bjarne's thesis, you will get a feeling for
how much was invested in Erlang.
>> "The Erlang design team consisting of Joe Armstrong, Mike
>> Williams and Robert Virding started experimenting" ... "Joe wrote
>> the compiler, Mike the emulator and Robert the design libraries."
-> That's only the initial phase. I don't think that things would
-> have worked out so well if you hadn't managed to draw other
-> Ericsson staff (= resources) into your project.
Of course not, but you have to differentiate between the projects
that were willing to bet on Erlang, and the researchers who
invented it and saw it through.
>> That is not nearly *all* work. That's the beginning. Then,
>> someone will have to build products on the foundation that you
>> provide. That's expensive and risky.
-> Right. And how comes that researchers should bear both the
-> expenses and the risk? Even more so considering their lack of
-> funding?
My point was the opposite. The companies bear the whole financial
risk for their production projects, and many (even the majority)
fail. They have to finance all failed attempts with profits from
their successful ones.
I'm not suggesting you do all the work -- just that you stay
_involved_ until the work is done. Big difference.
I understand from your posts that you have very bad personal
experience from working with industry. I've been part of a few
attempts at evangelising new technology. Erlang is the only
successful one so far, and that one certainly didn't come easy.