My thoughts on the article can be surmised in this one statement
foo.x += 1 is so much more readable than foo.setX(foo.getX() + 1)
it's honest and true. so far i've only had to develop a few small
apps in C# (a couple desktop apps and a couple of server side apps),
so I definitely don't have a
On Sun, Aug 9, 2009 at 5:13 AM, John Ament john.d.am...@gmail.com wrote:
My thoughts on the article can be surmised in this one statement
foo.x += 1 is so much more readable than foo.setX(foo.getX() + 1)
Mutable? :(
it's honest and true. so far i've only had to develop a few small
You want a concurrency meme to dictate language readability? Does
foo.getX() guarantee immutability? Does foo.x += 1 exclude it?
/Casper
On 9 Aug., 17:03, Viktor Klang viktor.kl...@gmail.com wrote:
On Sun, Aug 9, 2009 at 5:13 AM, John Ament john.d.am...@gmail.com wrote:
My thoughts on the
On Sun, Aug 9, 2009 at 5:22 PM, Casper Bang casper.b...@gmail.com wrote:
You want a concurrency meme to dictate language readability? Does
foo.getX() guarantee immutability? Does foo.x += 1 exclude it?
If foo.setX(foo.getX() + 1) is symmetrical to foo.x += 1
1) If it's not mutable then
As far as concurrency is concerned you really need an incrementX()
operation -- else you can't assume you've synchronized on the right
thing or invoked the right atomic operation.
Having x += n instead of incrementX(n) really isn't that compelling to me.
Casper Bang wrote:
You want a
Jess Holle wrote:
As far as concurrency is concerned you really need an incrementX()
operation -- else you can't assume you've synchronized on the right
thing or invoked the right atomic operation.
Having x += n instead of incrementX(n) really isn't that compelling
to me.
While I agree
As far as concurrency is concerned you really need an incrementX()
operation -- else you can't assume you've synchronized on the right
thing or invoked the right atomic operation.
Exactly my point, foo.getX()+1 isn't enough, which is why we have i.e.
AtomicLong. .NET is no different, you
Casper Bang wrote:
Yes, evidently even JRE library authors weren't blessed with enough
skills to use exceptions the right way which begs the question, is it
really worth the trouble?
The JRE library authors...
- derived a stack from a vector
- mangled util classes with pretty much all the
For being written in the early 90s I think the std libs are pretty
good. By comparison the C world was still using things like creat
(ENDLESS_CONSTANTS_YOU_CANT_REMEMBER_HERE). The bar on standard libs
has been raised in the last 15+ years *because* the Java runtime was
so good.
A lot of
Well, C# has many great features. However, it is a pitty that C# has
not checked exceptions.
Java platform is usable on lots of mobile phones, personal computers
and servers. You can use C# on:
* possibly some mobile phones, but not as many as with Java
* personal computers with .NET Framework
Well, C# has many great features. However, it is a pitty that C# has
not checked exceptions.
To restate Fabrizio Giudici from earlier, it's funny how one mans
feature is another mans bug. While they can occasionally be useful,
the debate is over. Checked exceptions offers more drawbacks than
Casper Bang wrote:
Well, C# has many great features. However, it is a pitty that C# has
not checked exceptions.
To restate Fabrizio Giudici from earlier, it's funny how one mans
feature is another mans bug. While they can occasionally be useful,
the debate is over. Checked exceptions
I agree that checked exceptions could have better design... But they
are IMHO useful. There is behavior I want:
* I have to define all Exceptions that can happen regardless of good
usage. (checked exceptions)
* I have to define all Exceptions that can happen if I use the class
wrongly. (unchecked
On Aug 4, 11:30 am, Casper Bang casper.b...@gmail.com wrote:
Well, C# has many great features. However, it is a pitty that C# has
not checked exceptions.
To restate Fabrizio Giudici from earlier, it's funny how one mans
feature is another mans bug. While they can occasionally be useful,
I fully agree.
On 4 srp, 18:39, Alexey inline_f...@yahoo.com wrote:
On Aug 4, 11:30 am, Casper Bang casper.b...@gmail.com wrote:
Well, C# has many great features. However, it is a pitty that C# has
not checked exceptions.
To restate Fabrizio Giudici from earlier, it's funny how one
Yes, evidently even JRE library authors weren't blessed with enough
skills to use exceptions the right way which begs the question, is it
really worth the trouble?
If you have a nice public API people are calling, how are you going to
maintain/extend this with a new checked exception type? The
On 4 srp, 19:21, Casper Bang casper.b...@gmail.com wrote:
If you have a nice public API people are calling, how are you going to
maintain/extend this with a new checked exception type? The minute you
touch a method signature, you are breaking each and every existing
callee - and you can't
Exactly, which makes checked exceptions a versionability problem. When
is the last time you wrote something and got it right the first time?
/Casper
On 4 Aug., 19:42, v6ak v...@volny.cz wrote:
On 4 srp, 19:21, Casper Bang casper.b...@gmail.com wrote: If you have a
nice public API people are
Casper Bang wrote:
Exactly, which makes checked exceptions a versionability problem. When
is the last time you wrote something and got it right the first time?
I strongly disagree :-) and agree with people expressing their
appreciation for checked expression, only criticizing the way they
Fabrizio Giudici wrote:
For this reason, I consider checked exceptions one of the good features
of the Java language and a serious missing feature of other languages.
PS COnsider that I'm taking the habit of having my classes never
returning a null; either with the NullPattern thing, or
Is it really a DISadvantage when you get compile error(s) because of
incompatible API?
On 4 srp, 20:01, Casper Bang casper.b...@gmail.com wrote:
Exactly, which makes checked exceptions a versionability problem. When
is the last time you wrote something and got it right the first time?
I strongly disagree :-) and agree with people expressing their
appreciation for checked expression, only criticizing the way they were
implemented.
Isn't that a rather pointless separation though, we have to work with
checked exceptions at a practical level. At a conceptual level I am
already
On 4 Aug., 20:22, v6ak v...@volny.cz wrote:
Is it really a DISadvantage when you get compile error(s) because of
incompatible API?
Let me turn it around instead. Is it a good idea how InputStream.close
() throws a IOException? Can anything be done about it now?
/Casper
Casper Bang wrote:
On 4 Aug., 20:22, v6ak v...@volny.cz wrote:
Is it really a DISadvantage when you get compile error(s) because of
incompatible API?
Let me turn it around instead. Is it a good idea how InputStream.close
() throws a IOException? Can anything be done about it now?
Casper Bang wrote:
On 4 Aug., 20:22, v6ak v...@volny.cz wrote:
Is it really a DISadvantage when you get compile error(s) because of
incompatible API?
Let me turn it around instead. Is it a good idea how InputStream.close
() throws a IOException? Can anything be done about it now?
Correct me if I'm wrong, please: I think that InputStream.close()
never throws an Exception, but it is not guaranteed. However, this
isn't mistake in concept of checked exceptions. It is mistake in
usage.
2009/8/4, Casper Bang casper.b...@gmail.com:
On 4 Aug., 20:22, v6ak v...@volny.cz wrote:
From the Java6 JavaDocs on InputStream
http://java.sun.com/javase/6/docs/api/java/io/InputStream.html
close
public void *close*()
throws IOException
http://java.sun.com/javase/6/docs/api/java/io/IOException.html
Closes this input stream and releases any system resources associated
that only says that InputStream.close() doesnt do anything. Id imagine
that, say, FileInputStream.close would close the underlying file
handler, the InputStream from a socket would close the socket and so
on - witch could possibly throw an IOException
2009/8/4 Ryan Waterer
Maybe you're generaly right. However, I can't find concrete example.
It is convention to wrap socket's InputStream and OutputStream into
one object that implements Closeable. So, closing the input stream
usually cannot cause to close a socket.
2009/8/4, Marcelo Fukushima takesh...@gmail.com:
Chris: Then you're _CLEARLY_ looking in the wrong places for a job.
Nobody likes to tie themselves to the railing of a sinking ship, which
is why the CLR is going to have a permanent problem attracting a
large* following, at least until microsoft completely lets it go**.
That's the price
... Chris: Then you're _CLEARLY_ looking in the wrong places for a
job. ...
I'm looking in 2 major cities and surrounding areas. I'll give at max
3hrs for a daily commute, moving is not something I wish to do. I'm
just looking for work doing development, web, client server, etc, I'm
not overly
Wow, they had all that and Java as a reference implementation, and
still managed to implement and sub standard collections API.
It is also interesting to see the, if ( this == null) in some of the
GUI code, it appears even the inventor had questionable beliefs on the
language.p
I think C# has
Casper Bang wrote:
Nah, Martin Odersky was still dabbling on Pizza (predecessor to Java
with generics) by the time most of the C# stuff was being thought
out. ;) I realize people consider Scala a contender to the next-gen
I wasn't serious :-) this thread seems to have a high degree of
Why hasn't any one written a c# compiler for the jvm yet?
On Aug 1, 2009 8:40 PM, Fabrizio Giudici fabrizio.giud...@tidalwave.it
wrote:
Casper Bang wrote: Nah, Martin Odersky was still dabbling on Pizza
(predecessor to Java with ge...
I wasn't serious :-) this thread seems to have a high
I honestly think project lombok can be the successor, itself. There
are of course a lot more transformations that lombok could work on,
and perhaps at some point I'll figure out how to edit javac's parser
from an annotation processor. If that is indeed possible, the sky is
the limit. You could
Mark Derricutt wrote:
Why hasn't any one written a c# compiler for the jvm yet?
Hasn't MainSoft written one? It goes the other direction as IKVM (MSIL
= Java bytecode). It's been available for a long time. I don't know
of anybody using it.
--
Weiqi Gao
weiqi...@gmail.com
You really want to have a language where everything is preceded by an @
sign?
On Sat, Aug 1, 2009 at 10:50 AM, Reinier Zwitserloot reini...@gmail.comwrote:
I honestly think project lombok can be the successor, itself. There
are of course a lot more transformations that lombok could work on,
We'll when I look in my local area for developer jobs I see loads of
C# and .Net, probably 3x more then Java. I see no Ruby :(
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups The
Java Posse group.
To post to this
On Fri, Jul 31, 2009 at 09:23:56AM -0700, John wrote:
http://brizzled.clapper.org/id/93
I've been working in c# for about 1.5 years after being a hardcode
Java developer since ~1997. I must admit that c# does have a lot of
excellent language features that I wish Java had. Mr. Clapper does
Dominic Mitchell wrote:
On Fri, Jul 31, 2009 at 09:23:56AM -0700, John wrote:
http://brizzled.clapper.org/id/93
I've been working in c# for about 1.5 years after being a hardcode
Java developer since ~1997. I must admit that c# does have a lot of
excellent language features that I wish
Casper Bang wrote:
I came to the same conclusion some years ago, though you are likely to
find a lot who disagrees with the term better and who will raise the
kitchen sink argument. But any new unbiased developer touching both
are likely to come to that conclusion - Indeed that's why Mono was
Also on C# since one year and former Java Developer.
C# is nice but it often feels like a Me too language.
Originally a copy of Java they now copy features from other languages
leaving behind a total mess.
While I am still not certain what language I like more I still think the
Java API
On Fri, Jul 31, 2009 at 08:52:31PM +0200, Alexander Egger wrote:
Also because of one thing: This is the third MS shop I am working for. And
this is the third time I see MS almost killing the company because they
suddenly decide to
change a technology in an incompatible way which leads to a
I think it goes out of its way to be different and require a huge leap
for existing developers.
C - C++ - Java -- each transition was made smooth where possible to
get the market on board. C# seems to be following the same proven approach.
Scala on the other hand, seems to want everyone to
... which is why projectlombok.org is the future!
/shameless self aggrandizing plug
On Aug 1, 12:12 am, Jess Holle je...@ptc.com wrote:
I think it goes out of its way to be different and require a huge leap
for existing developers.
C - C++ - Java -- each transition was made smooth where
45 matches
Mail list logo
