Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #18647 > unrolled thread

can't throw

Back to article view | Back to comp.lang.java.programmer

Contents

  can't throw bob smith <bob@coolfone.comze.com> - 2012-09-11 13:16 -0700
    Re: can't throw markspace <-@.> - 2012-09-11 13:34 -0700
      Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-11 14:15 -0700
    Re: can't throw Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-11 17:02 -0400
      Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-11 14:17 -0700
        Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-11 21:21 -0400
          Re: can't throw Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-09-11 21:59 -0700
            Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-12 09:18 -0700
              Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-12 19:09 +0200
              Re: can't throw markspace <-@.> - 2012-09-12 10:56 -0700
              Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:36 -0400
                Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-12 18:29 -0700
                  Re: can't throw Patricia Shanahan <pats@acm.org> - 2012-09-12 18:34 -0700
                  Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 21:37 -0400
                    Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 21:54 -0400
            Re: can't throw Jim Janney <jjanney@shell.xmission.com> - 2012-09-12 11:27 -0600
            Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:24 -0400
              Re: can't throw Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-09-13 22:20 -0700
                Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-14 09:49 -0700
                  Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-14 20:50 +0200
                    Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-14 13:02 -0700
                      Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-14 14:06 -0700
                    Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-14 13:16 -0700
                      Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-14 23:07 +0200
                        Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-14 14:28 -0700
                          Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-16 20:04 -0700
          Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:16 -0400
            Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-12 23:15 -0700
          Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-14 17:33 -0500
            Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-16 15:46 +0200
              Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-16 12:17 -0500
                Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-16 22:36 +0200
                  Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-16 20:07 -0700
                    Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-17 07:41 +0200
                      Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-17 09:51 -0700
                        Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-17 21:00 +0200
                          Re: can't throw Gene Wirchenko <genew@ocis.net> - 2012-09-17 13:23 -0700
                      Re: can't throw Joerg Meier <joergmmeier@arcor.de> - 2012-09-17 18:52 +0200
                        Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-17 11:22 -0700
                    Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-17 02:52 -0500
                  Re: can't throw Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-09-17 02:39 -0500
                    Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-17 21:02 +0200
    Re: can't throw markspace <-@.> - 2012-09-11 14:28 -0700
    Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-11 21:14 -0400
      Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:11 -0400
    Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-12 08:31 +0200
      Re: can't throw bob smith <bob@coolfone.comze.com> - 2012-09-12 11:40 -0700
        Re: can't throw Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-09-12 15:50 -0400
        Re: can't throw Lew <lewbloch@gmail.com> - 2012-09-12 12:52 -0700
          Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-12 23:24 +0200
            Re: can't throw Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-09-12 15:10 -0700
              Re: can't throw Robert Klemme <shortcutter@googlemail.com> - 2012-09-13 23:32 +0200
      Re: can't throw Arne Vajhøj <arne@vajhoej.dk> - 2012-09-12 18:06 -0400
    Re: can't throw Roedy Green <see_website@mindprod.com.invalid> - 2012-09-12 20:55 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#18772

Robert Klemme wrote:
> Gene Wirchenko wrote:
>>       It may not be nearly as elegant, but I still prefer BASIC's ON
>> ERROR GOTO handling.  Yes, one had to sort through the error numbers,
>> but that made it easier in some ways.  One could code something to
>> handle the few cases where there was a specific handling and then use
>> a catch-all for the rest.

And you can't do that with Java exceptions?

> Well, you can do _that_ in Java, too.

Ah, I thought so.

So what was that advantage of BASIC's approach again?

> I find the distinction between checked and unchecked exceptions pretty 
> good - although the distribution of exception types across these 
> categories does not always seem to be wisely made in the standard library.

API writing is a Dark Art, or rather a Dark Artish approach to programming generally.

It's arguably the best approach.

But designing the exception API is Darker Art. 

People who complain about checked exceptions always take the client point of 
view, and always blame Java.

(Counterexamples welcome.)

But if they are so bad, why do API writers opt to use them?

I know the answer. Do you?

Regardless, why blame Java for the API writer's choice?

As for comparing to other languages that don't have checked exceptions, 
that's utter bullshit. Bullshit, I say.

You can't compare the API writer's choices when they don't have the same 
options.

So writers of code in those other, lesser languages that don't have checked 
exceptions resort to some other idiom, simply because the checked 
exception idiom doesn't exist.

So of course it works, because they use the mechanisms that their 
languages *do* provide. Duh, and double-duh.

Drawing the conclusion that checked exceptions aren't necessary, 
given some other mechanism to accomplish equivalent goals, 
is hardly insightful. Drawing the conclusion from that evidence that 
checked exceptions are somehow inferior to those other mechanisms 
is fallacious.

What is valid is to compare decisions to use or not use checked 
exceptions in environments where they are available. 

Interesting then, that in such environments that good programmers 
find checked exceptions useful.

If you don't like their insistence that you honor the exception contract 
they designed, don't use their libraries. Just like if you don't like their 
insistence that you honor the argument contract they designed, don't 
use their libraries.

Just don't blame Java for providing the API writer the tools to force you 
to deal with something they thought important enough to force you to 
deal with. Thank God and the Java Founders that checked exceptions 
were available to that API writer to enforce that contract on you, otherwise 
a) they couldn't ensure you honor certain robustness requirements, and 
b) you couldn't be sure of exactly what exceptional situations they really 
insist you handle.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#18775

On Fri, 14 Sep 2012 13:02:05 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

>Robert Klemme wrote:
>> Gene Wirchenko wrote:
>>>       It may not be nearly as elegant, but I still prefer BASIC's ON
>>> ERROR GOTO handling.  Yes, one had to sort through the error numbers,
>>> but that made it easier in some ways.  One could code something to
>>> handle the few cases where there was a specific handling and then use
>>> a catch-all for the rest.
>
>And you can't do that with Java exceptions?
>
>> Well, you can do _that_ in Java, too.
>
>Ah, I thought so.
>
>So what was that advantage of BASIC's approach again?

     It is obvious that you can do it that way.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#18773

On Fri, 14 Sep 2012 20:50:38 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

>On 14.09.2012 18:49, Gene Wirchenko wrote:
>
>>       It may not be nearly as elegant, but I still prefer BASIC's ON
>> ERROR GOTO handling.  Yes, one had to sort through the error numbers,
>> but that made it easier in some ways.  One could code something to
>> handle the few cases where there was a specific handling and then use
>> a catch-all for the rest.
>
>Well, you can do _that_ in Java, too.

     I am not surprised.  Unfortunately, I never learned that.
Beginning Java texts that I have seen do not cover it.  With BASIC,
handling errors was with only one error handler so it was forced to do
it that way (and sometimes, it was covered).

>I find the distinction between checked and unchecked exceptions pretty 
>good - although the distribution of exception types across these 
>categories does not always seem to be wisely made in the standard library.

     Java has too many distinctions that are not easily (or
often-enough) made and that can catch Java newbies.

     Maybe, it was too much of trying to be everything to everybody?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#18776

On 14.09.2012 22:16, Gene Wirchenko wrote:
> On Fri, 14 Sep 2012 20:50:38 +0200, Robert Klemme
> <shortcutter@googlemail.com> wrote:
>
>> On 14.09.2012 18:49, Gene Wirchenko wrote:
>>
>>>        It may not be nearly as elegant, but I still prefer BASIC's ON
>>> ERROR GOTO handling.  Yes, one had to sort through the error numbers,
>>> but that made it easier in some ways.  One could code something to
>>> handle the few cases where there was a specific handling and then use
>>> a catch-all for the rest.
>>
>> Well, you can do _that_ in Java, too.
>
>       I am not surprised.  Unfortunately, I never learned that.
> Beginning Java texts that I have seen do not cover it.  With BASIC,
> handling errors was with only one error handler so it was forced to do
> it that way (and sometimes, it was covered).

I wasn't aware that this seems to be such a mystery.  The basic (!) 
mechanism is pretty simple: exception handler order matters: the first 
matching handler is used.  So you can place handlers for classes down 
the exception inheritance hierarchy at the front and place handlers for 
classes further up later.  In an extreme case use a catch block with 
RuntimeException, Exception or Throwable as last one.

>> I find the distinction between checked and unchecked exceptions pretty
>> good - although the distribution of exception types across these
>> categories does not always seem to be wisely made in the standard library.
>
>       Java has too many distinctions that are not easily (or
> often-enough) made and that can catch Java newbies.
>
>       Maybe, it was too much of trying to be everything to everybody?

I believe what you describe is rather an effect of the massive success 
the language has had.  That success a) led to a prolonged life and b) 
steered more resources into the development of the language, libraries 
and frameworks.  For another language people might not have bothered to 
write another IO library.  Now there are is more than one around to 
maintain compatibility and that makes the language look inconsistent - 
even though it's just history showing.  Same story with Vector and 
ArrayList or synchronized vs. java.util.concurrent.locks (where one is 
really a language feature and the other a library) or Date vs. Calendar. 
  As Lew said, you need darn good library designers to get it right the 
first time.  But at least you can see that newer parts of the library 
are better than older parts.  I find that good even though it increases 
the volume of library API to learn.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#18779

 Robert Klemme wrote:
>  Gene Wirchenko wrote:
>>>>        It may not be nearly as elegant, but I still prefer BASIC's ON
>>>> ERROR GOTO handling.  Yes, one had to sort through the error numbers,
>>>> but that made it easier in some ways.  One could code something to
>>>> handle the few cases where there was a specific handling and then use
>>>> a catch-all for the rest.
> 
> >       I am not surprised.  Unfortunately, I never learned that.
> 
> > Beginning Java texts that I have seen do not cover it.  With BASIC,

Here you go, the cure for your ignorance of how to use Java exceptions:
http://docs.oracle.com/javase/tutorial/essential/exceptions/index.html

>> handling errors was with only one error handler so it was forced to do
>> it that way (and sometimes, it was covered).
> 
> I wasn't aware that this seems to be such a mystery.  The basic (!) 

It isn't if you read the tutorial.

The place where everyone is recommended to begin learning Java.

> mechanism is pretty simple: exception handler order matters: the first 
> matching handler is used.  So you can place handlers for classes down 

From the tutorial: " The runtime system invokes the exception handler 
"when the handler is the first one in the call stack whose ExceptionType 
matches the type of the exception thrown." 

> the exception inheritance hierarchy at the front and place handlers for 
> classes further up later.  In an extreme case use a catch block with 
> RuntimeException, Exception or Throwable as last one.

As illustrated in the tutorial: "By catching any IOException that's not caught 
by the first handler, . . . "

>>> I find the distinction between checked and unchecked exceptions pretty
>>> good - although the distribution of exception types across these

"The first kind of exception is the checked exception. These are exceptional 
conditions that a well-written application should anticipate and recover from."
  
>>> categories does not always seem to be wisely made in the standard library.
> 
>>       Java has too many distinctions that are not easily (or
> > often-enough) made and that can catch Java newbies.

Unless they read the tutorials.

>>       Maybe, it was too much of trying to be everything to everybody?

Maybe it was a case of not RTFM?

Blaming the language for one's failure to study is an unworthy act.

> I believe what you describe is rather an effect of the massive success 

This doesn't apply to exceptions, most of whose functionality has been 
the same in Java for a long time.

> the language has had.  That success a) led to a prolonged life and b) 
> steered more resources into the development of the language, libraries 
> and frameworks.  For another language people might not have bothered to 
> write another IO library.  Now there are is more than one around to 
> maintain compatibility and that makes the language look inconsistent - 
> even though it's just history showing.  Same story with Vector and 
> ArrayList or synchronized vs. java.util.concurrent.locks (where one is 
> really a language feature and the other a library) or Date vs. Calendar. 
> 
>   As Lew said, you need darn good library designers to get it right the 
> first time.  But at least you can see that newer parts of the library 
> are better than older parts.  I find that good even though it increases 
> the volume of library API to learn.

But learning about Exceptions isn't an API exercise, at this level, but 
a language-comprehension issue and whether one bothers to read the 
elementary introductions to the language.

Or then whines that the language is too hard because they didn't bother 
to learn the most elementary aspects of it in the first place.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#18795

On Fri, 14 Sep 2012 14:28:29 -0700 (PDT), Lew <lewbloch@gmail.com>
wrote:

[snip]

>Or then whines that the language is too hard because they didn't bother 
>to learn the most elementary aspects of it in the first place.

     Just try finding the most elementary aspects in all that bloat.

     The problem is not so much reading the docs; it is finding the
correct ones.  When one is just starting, it is difficult to sort the
wheat from the chaff.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#18709

On 9/11/2012 9:21 PM, Arne Vajhøj wrote:
> On 9/11/2012 5:17 PM, Lew wrote:
>> Eric Sosman wrote:
>>>       Some people, deeper thinkers than I, consider the whole
>>> business of checked exceptions a nuisance or a misfeature.  The
>>
>> Those people are mistaken.
>>
>>> need for a dodge like the above can be seen as evidence for
>>> that viewpoint, but I don't find it overwhelmingly convincing.
>>
>> Not even suggestive, much less convincing.
>>
>>> In any event, that's Java As It Is And Is Likely To Remain, so
>>
>> and for good reason.
>
> I must admit that personally I like the checked exception
> context.

It makes a lot of sense if you are API centric.

A contract "I will either return a value of type X or throw
one of the exceptions E1,...,En" seems a lot more strict than
"I will either return a value of type X or throw an exception
but I will not tell you which".

Arne

[toc] | [prev] | [next] | [standalone]

#18727

Arne Vajhøj wrote:
> Arne Vajhøj wrote:
>> Lew wrote:
>>> Eric Sosman wrote:
>>>>       Some people, deeper thinkers than I, consider the whole
>>>> business of checked exceptions a nuisance or a misfeature.  The
> 
>>> Those people are mistaken.
> 
>>>> need for a dodge like the above can be seen as evidence for
>>>> that viewpoint, but I don't find it overwhelmingly convincing.
> 
>>> Not even suggestive, much less convincing.
> 
>>>> In any event, that's Java As It Is And Is Likely To Remain, so
> 
>>> and for good reason.
> 
>> I must admit that personally I like the checked exception
>> context.
> 
> It makes a lot of sense if you are API centric.
> 
> A contract "I will either return a value of type X or throw
> one of the exceptions E1,...,En" seems a lot more strict than
> "I will either return a value of type X or throw an exception
> but I will not tell you which".

Agreed, although some chafe at the restriction, and point out 
that other code works just fine without such things.

In some cases that's because the platform implicitly supports 
some exception-handling mechanism that wraps more than what 
Java's does, or the language uses some assertion-like mechanism 
to render exceptions moot.

Java's checked exceptions serve a real but optional need, not 
only to be strict, but to warn API users (yes, this is an 
API-centric or API-ontologic view) of expected exceptions.

Otherwise all exceptions are RuntimeExceptions or worse, and 
by definition come as a surprise.

By convention and just the way it works out, RuntimeExceptions 
are for program(mer) errors. The infamous NPE is an example. 
Most use cases are better served by explicit null guards than 
exception tosses.

Not to say that RuntimeExceptions aren't useful; they are. 
The suggestions here to wrap checked exceptions in them
are an example. That's because an exception visible to one 
thread from another are a surprise, and most likely a 
program(mer) error. *Especially* because checked exceptions 
are by definition expected and should usually not propagate 
outside their thread.

Into logs, yes. As exceptions, not.

Throwing 'Exception' itself is a Dark Art. You can play 
with poison - there are valid reasons to do so.

'Error' and raw 'Throwable' - whatever the interpretation here, 
it's a bad-ass event.

Like all programming idioms, when you write exceptions 
you should have a good flair for their purpose. Arne makes 
sense - balances a case for their utility with a recognition 
of both their limits and that people do without them.

As he says overthread, "One needs to think about the issue anyway."
Exceptions provide one way to express the decisions you make on 
how to handle it.

A key for me is an idea that some code path is exceptional, 
and another is a "happy" path. Another key is that I pair 
(not) throwing an exception with an assertion.

Example:

  public void foo(Bar param)
  {
    if (param == null || param.getBaz() != State.READY)
    {
      throw new IllegalStateException("Bad param "+param);
    }
    assert param != null && param.getBaz() == State.READY;
 . . .
  }

-- 
Lew
All rules of thumb are useful as far as they go. But no farther.
As a rule.

[toc] | [prev] | [next] | [standalone]

#18781

Arne Vajhøj <arne@vajhoej.dk> wrote:
> 
> So the benefits are not that obvious to everyone.
> 

Personally, I think it was a design flaw to tie the checked /
unchecked to the class hierarchy. An exception's class corresponds to
a particular error type, but the severity of a particular type of
error, and wheter we can expect the client to be able to recover from
it or not, depends on the context.

The choice of checked / unchecked should be made statically _at the
point of the throw statement_,

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#18790

On 09/15/2012 12:33 AM, Leif Roar Moldskred wrote:

> Personally, I think it was a design flaw to tie the checked /
> unchecked to the class hierarchy. An exception's class corresponds to
> a particular error type, but the severity of a particular type of
> error, and wheter we can expect the client to be able to recover from
> it or not, depends on the context.
>
> The choice of checked / unchecked should be made statically _at the
> point of the throw statement_,

Let's see what the consequences of this would be:

1. we need new syntax (e.g. a new keyword), in order to make that 
distinction.  So it's either
throw checked new IllegalStateException("You can't do that right now.")
throw_checked new IllegalStateException("You can't do that right now.")

2. The complier needs to enforce all exceptions thrown with "throw 
checked" are declared in the throws clause.

OK so far, no issues there.

3. Now, assume we have a section of code which throws the same exception 
type checked and unchecked.  That section is embedded in a try block. 
Now we have a catch clause for this exception type attached to the try 
block.  This prompts the question: which of the thrown exceptions does 
the catch block handle - only the checked throws or also unchecked throws?

3a. It handles both.  This leads to the unsatisfactory situation where 
the same catch block needs to handle programmer errors (now 
RuntimeException and subclasses) and other errors which are actually 
expected.  That's not good since programmer errors (and catastrophic 
situations like OOM are usually handled quite close to Thread.run, i.e. 
further up the call stack.

3b. The programmer can decide, so we need a new syntax again:

catch checked ( IllegalStateException e )

This will only catch checked exceptions.  Do we now need an additional 
syntax for "unchecked", e.g.

catch unchecked ( IllegalStateException e )

And what do we do if we want to cover both cases (e.g. because we just 
want to print the error)?  Do we then do this?

catch checked, unchecked ( IllegalStateException e )

Or do we use the current form to mean "catch both"?

catch ( IllegalStateException e )

In which way we resolve these questions it's obvious that one can easily 
forget a keyword or make a different error so one ends handling other 
exceptions than intended.

Given the fact that the type of exception also describes the type of 
error and that in turn is related to the classification "programmer 
error" / "no programmer error" I am not so sure whether the additional 
complication your distinction at call site introduces is actually 
worthwhile.

Kind regards

	robert

[toc] | [prev] | [next] | [standalone]

#18792

Robert Klemme <shortcutter@googlemail.com> wrote:
> 
> 3b. The programmer can decide, so we need a new syntax again:
> 
> catch checked ( IllegalStateException e )
> 
> This will only catch checked exceptions.  Do we now need an additional 
> syntax for "unchecked", e.g.
> 
> catch unchecked ( IllegalStateException e )
> 
> And what do we do if we want to cover both cases (e.g. because we just 
> want to print the error)?  Do we then do this?
> 
> catch checked, unchecked ( IllegalStateException e )
> 
> Or do we use the current form to mean "catch both"?

Plain catch statements, "catch ( SomeException ex )", only catches
checked exceptions and it's illegal to have a plain catch statement
for an exception that can not be thrown (checked) in the try
block. 

"Catch unchecked" catches both checked and unchecked versions of the
exception. Having only an unchecked catch for a given exception that
can be thrown checked in the try block is legal, but causes a compiler
warning: the preferred is to have two separate catch statements for
checked and unchecked versions of that exception.

It's not foolproof (fools are just so darned clever at times), but it
strikes me as safe enough to be practical.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#18793

On 16.09.2012 19:17, Leif Roar Moldskred wrote:

> Plain catch statements, "catch ( SomeException ex )", only catches
> checked exceptions and it's illegal to have a plain catch statement
> for an exception that can not be thrown (checked) in the try
> block.
>
> "Catch unchecked" catches both checked and unchecked versions of the
> exception. Having only an unchecked catch for a given exception that
> can be thrown checked in the try block is legal, but causes a compiler
> warning: the preferred is to have two separate catch statements for
> checked and unchecked versions of that exception.
>
> It's not foolproof (fools are just so darned clever at times), but it
> strikes me as safe enough to be practical.

My point was not that it can't be made "safe".  I rather questioned 
whether the additional complexity introduced in the language would be 
beneficial (even if we let compatibility issues aside for the moment).

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#18796

On Sun, 16 Sep 2012 22:36:00 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

[snip]

>My point was not that it can't be made "safe".  I rather questioned 
>whether the additional complexity introduced in the language would be 
>beneficial (even if we let compatibility issues aside for the moment).

     The architecture astronauts got Java long ago.

     While C has many trade-offs that I disagree with, one thing that
they got right is that it is a small language.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#18797

On 17.09.2012 05:07, Gene Wirchenko wrote:
> On Sun, 16 Sep 2012 22:36:00 +0200, Robert Klemme
> <shortcutter@googlemail.com> wrote:
>
> [snip]
>
>> My point was not that it can't be made "safe".  I rather questioned
>> whether the additional complexity introduced in the language would be
>> beneficial (even if we let compatibility issues aside for the moment).
>
>       The architecture astronauts got Java long ago.
>
>       While C has many trade-offs that I disagree with, one thing that
> they got right is that it is a small language.

But "small" is not a value in itself.  Programming languages are tools 
and a small language might have less complexity than necessary to solve 
today's problems.  If you can learn it fast (because it is small) but 
then you need to go through hoops every day to write the code that you 
need to write, what have you gained?

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#18804

On Mon, 17 Sep 2012 07:41:11 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

>On 17.09.2012 05:07, Gene Wirchenko wrote:
>> On Sun, 16 Sep 2012 22:36:00 +0200, Robert Klemme
>> <shortcutter@googlemail.com> wrote:
>>
>> [snip]
>>
>>> My point was not that it can't be made "safe".  I rather questioned
>>> whether the additional complexity introduced in the language would be
>>> beneficial (even if we let compatibility issues aside for the moment).
>>
>>       The architecture astronauts got Java long ago.
>>
>>       While C has many trade-offs that I disagree with, one thing that
>> they got right is that it is a small language.
>
>But "small" is not a value in itself.  Programming languages are tools 
>and a small language might have less complexity than necessary to solve 
>today's problems.  If you can learn it fast (because it is small) but 
>then you need to go through hoops every day to write the code that you 
>need to write, what have you gained?

     If.

     One can drown in huge languages.  Features can interact in
"interesting" ways.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#18810

On 17.09.2012 18:51, Gene Wirchenko wrote:
> On Mon, 17 Sep 2012 07:41:11 +0200, Robert Klemme
> <shortcutter@googlemail.com> wrote:
>
>> On 17.09.2012 05:07, Gene Wirchenko wrote:
>>> On Sun, 16 Sep 2012 22:36:00 +0200, Robert Klemme
>>> <shortcutter@googlemail.com> wrote:
>>>
>>> [snip]
>>>
>>>> My point was not that it can't be made "safe".  I rather questioned
>>>> whether the additional complexity introduced in the language would be
>>>> beneficial (even if we let compatibility issues aside for the moment).
>>>
>>>        The architecture astronauts got Java long ago.
>>>
>>>        While C has many trade-offs that I disagree with, one thing that
>>> they got right is that it is a small language.
>>
>> But "small" is not a value in itself.  Programming languages are tools
>> and a small language might have less complexity than necessary to solve
>> today's problems.  If you can learn it fast (because it is small) but
>> then you need to go through hoops every day to write the code that you
>> need to write, what have you gained?
>
>       If.
>
>       One can drown in huge languages.  Features can interact in
> "interesting" ways.

Yes, of course.  But the "if" applies the other way round.  As I said: 
small or large in itself are no values.

Cheers

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#18813

On Mon, 17 Sep 2012 21:00:12 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

>On 17.09.2012 18:51, Gene Wirchenko wrote:
>> On Mon, 17 Sep 2012 07:41:11 +0200, Robert Klemme
>> <shortcutter@googlemail.com> wrote:

[snip]

>>       If.
>>
>>       One can drown in huge languages.  Features can interact in
>> "interesting" ways.
>
>Yes, of course.  But the "if" applies the other way round.  As I said: 
>small or large in itself are no values.

     Actually, they are.  "elegant" refers to simplicity of form
accomplishing something.  This is a case of "Small is beautiful."  And
"bloat" is the term we use for the opposite.

     Given the choice between a large programming language and a small
one, all other things equal, I will go for the smaller one.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#18805

On Mon, 17 Sep 2012 07:41:11 +0200, Robert Klemme wrote:

> On 17.09.2012 05:07, Gene Wirchenko wrote:
>> On Sun, 16 Sep 2012 22:36:00 +0200, Robert Klemme
>> <shortcutter@googlemail.com> wrote:

>> [snip]

>>> My point was not that it can't be made "safe".  I rather questioned
>>> whether the additional complexity introduced in the language would be
>>> beneficial (even if we let compatibility issues aside for the moment).
>>       The architecture astronauts got Java long ago.

>>       While C has many trade-offs that I disagree with, one thing that
>> they got right is that it is a small language.
> But "small" is not a value in itself.  Programming languages are tools 
> and a small language might have less complexity than necessary to solve 
> today's problems.  If you can learn it fast (because it is small) but 
> then you need to go through hoops every day to write the code that you 
> need to write, what have you gained?

I would even question whether a small language is actually less complex or
easier to learn. If I need to write five pages of code to read a text file,
because the language is so small it doesn't have existing mechanisms for
common tasks, then that incurs a high cost in learning and complexity to
apply the small language.

Just because you learn a languages syntax and keywords doesn't mean you
really learned the language. Languages are there to solve problems, so you
really only 'learned' a language when you can solve problems with it.

Liebe Gruesse,
		Joerg

-- 
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[toc] | [prev] | [next] | [standalone]

#18808

Joerg Meier wrote:
> I would even question whether a small language is actually less complex or
> easier to learn. If I need to write five pages of code to read a text file,
> because the language is so small it doesn't have existing mechanisms for
> common tasks, then that incurs a high cost in learning and complexity to
> apply the small language.

The point is true in general but doesn't apply to Java specifically.

> Just because you learn a languages syntax and keywords doesn't mean you
> really learned the language. Languages are there to solve problems, so you
> really only 'learned' a language when you can solve problems with it.

And any sufficiently powerful language will require continuous learning and 
relearning.

Learning a programming language and learning to program are a continuum of 
mastery, similar to any craft. You might learn Java, for example, well enough to 
solve certain single-user, desktop application scenarios and be quite helpless in 
the face of a Tomcat app and installation.

I acknowledge that I never learn what I'm doing 100%.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#18799

Gene Wirchenko <genew@ocis.net> wrote:
> 
>     The architecture astronauts got Java long ago.
> 
>     While C has many trade-offs that I disagree with, one thing that
> they got right is that it is a small language.

Is it really? I wonder. 

The C11 language standard is comparable in size to the Java 7 language
specification.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web