Response to eiffel thread 
Author Message
 Response to eiffel thread

On Wed May 12 16:45:37 EDT 1993, some guy named Philip said the following:

Quote:
> Yes, this may be true. But rumour has it that Nicolaus arrived at this
> speed by, among others, stripping every single comment out of the
> source code of the compiler. If this is true, it makes one wonder
> about professors in Computer Science ... B-(

So what is your point?  So what if the test was done w/o comments.
As long as the tests are equivalent, it does not matter if they are
full of comments, devoid of comments or conducted under hypnosis.

Then, Konrad Hinsen had to put in his own two cents:

After reading the article about Oberon in the last issue of Byte, I
downloaded the DEC version and played around with it a bit.  It is
impressive in many respects, but I wonder whether it can be used for
"real" applications (as opposed to training purposes).

Quote:
> Apart from some problems I see in the current implementation (like
> lack of debugging support and interfaces to other languages), there
> are also two conceptual problems with the Oberon system:
> 1) There is only a global name space for modules
> 2) No multitasking
> Lack of multitasking seems to be a deliberate design decision, but
> one I don't understand. While it is true that users normally interact
> only with one program at a time, there are always operations that
> need no user interaction, but much time, and should therefore be run
> as background processes.  A common example would be background
> printing, another one the execution of lengthy numerical
> computations.

Geesh.  Here we go again.  Another NG that takes a look at Oberon
and decides taht it is not perfect, and here is how to fix it.  This,
after only a short period of use.  Sigh.  I wish these people would
think before they would open their keyboard.

Oh, Konrad.  If there is a problem, tell us your proposals to
introduce seamless multitasking into the Oberon system as it stands
now.  It is a single user workstation operating system that has a
global name space.

If you introduce multitasking, do you propose multiple instances of a
module?  Or thunks?  What should the system do when a module re-load
is requested?  How do you resolve multiple data segments?  What about
the possibility of multiple data segments for the Oberon core
(remember, they Oberon core is just simply Oberon.  Nothing special
here; you can't introduce special circumstances for them...)

I don't think you really have thought about the problem, or
understood the tenets of Oberon.  Please read the books on Oberon.
References to them can be found in the FAQ.

Taylor "You are getting sleepy" Hutt
Championing good beer!



Fri, 03 Nov 1995 11:16:30 GMT  
 Response to eiffel thread

says:

Quote:

>Then, Konrad Hinsen had to put in his own two cents:

No, I didn't have to. It was my own free decision.

Quote:
>Geesh.  Here we go again.  Another NG that takes a look at Oberon
>and decides taht it is not perfect, and here is how to fix it.  This,
>after only a short period of use.  Sigh.  I wish these people would
>think before they would open their keyboard.

Whether you believe it or not, some of them do.

Quote:
>Oh, Konrad.  If there is a problem, tell us your proposals to
>introduce seamless multitasking into the Oberon system as it stands
>now.  It is a single user workstation operating system that has a
>global name space.

First of all, the fact that it is difficult doesn't mean that
it is not necessary. And second, I didn't ask for "seamless
multitasking", but only for some provision for running long
non-interactive jobs in the background. They may be independent
of everything else, so they may use a different name space.
I just don't want to be forced to switch to a different language
whenever a calculation takes more than a minute.

Quote:
>I don't think you really have thought about the problem, or
>understood the tenets of Oberon.  Please read the books on Oberon.
>References to them can be found in the FAQ.

I think I do understand the problem; after all, Oberon is not
the first language and/or work environment I use.
But I didn't know that Oberon has reached the status of a holy
cow. Like many others, I look at it as a new option to solve
my everyday computing needs. In my case, they happen to include
long numerical calculations. If Oberon as it is now is not
able to handle these (and no one disagreed about that), I feel
entitled to criticize it. This was intended to be a contructive
type of criticism, but it seems that some people didn't realize
that.




Fri, 03 Nov 1995 18:48:18 GMT  
 Response to eiffel thread

Quote:

> On Wed May 12 16:45:37 EDT 1993, some guy named Philip said the following:

> ...
>> Apart from some problems I see in the current implementation (like
>> lack of debugging support and interfaces to other languages), there
>> are also two conceptual problems with the Oberon system:

>> 1) There is only a global name space for modules
>> 2) No multitasking

>> Lack of multitasking seems to be a deliberate design decision, but
>> one I don't understand. While it is true that users normally interact
>> only with one program at a time, there are always operations that
>> need no user interaction, but much time, and should therefore be run
>> as background processes.  A common example would be background
>> printing, another one the execution of lengthy numerical
>> computations.

> Geesh.  Here we go again.  Another NG that takes a look at Oberon
> and decides taht it is not perfect, and here is how to fix it.  This,
> after only a short period of use.  Sigh.  I wish these people would
> think before they would open their keyboard.

> Oh, Konrad.  If there is a problem, tell us your proposals to
> introduce seamless multitasking into the Oberon system as it stands
> now.  It is a single user workstation operating system that has a
> global name space.

Konrad perceives a problem.  Possession of a solution
is not a prerequisite for stating a problem.

Anybody who's written compute-intensive GUI applications recognizes the value
of language/environment support for multi-tasking.  Some languages (Modula-3)
and operating systems (Solaris) provide support for multi-threaded
execution, and this is exceptionally useful in GUI applications as it allows
compute tasks to update the UI as they generate results.  Never mind that it's
difficult to implement in a safe way.

I'm not really advocating that languages provide direct multi-threading
support.  I'd prefer that the operating system offer the capability (in spite
of the loss of portability).  If it doesn't, odds are good that all of your
threads will stop the first time one of them makes a system call.
Witness for example VAX Ada under VMS 4.x.

I've no comment on the global name space problem, except to say
that Oberon is by no means the only language afflicted.

Quote:
> I don't think you really have thought about the problem, or
> understood the tenets of Oberon.

That may well be, but -- Oh! You were talking to Konrad :)

Quote:
> Taylor "You are getting sleepy" Hutt
> Championing good beer!

Beer:  it's not just for breakfast anymore.




Sun, 05 Nov 1995 17:11:14 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. ISE Eiffel and Pricing Response

2. Function return values revisted (response to response)

3. Python 2.1.1 ASP/Response object does not HONOR Response.End()

4. httplib: response.read() vs response.read(size)

5. Slightly Off Topic : restrictions on the response part in a SOAP-response

6. Is, Eiffel multi-threaded yet ?

7. Does Eiffel get along threads?

8. Threads Eiffel Studio / SmallEiffel and VxWorks

9. the state of threading in eiffel

10. ISE Eiffel 3.3, GUI and Multi-Threads

11. Interresting thread in comp.lang.eiffel

12. Interresting thread in comp.lang.eiffel

 

 
Powered by phpBB® Forum Software