> If I wanted to write a similar Java program, I'd need to > create a scanner class to read the file, a transformer > class to take the string from the scanner and massage the > data, and then I'd cry because I'd need to write JDBC > code. I suspect it would take fifty lines of code to do > that, and fifteen of those lines would be needless > infrastructure (class declarations, opening and closing > braces).
I don't know why you would have to write a Scanner class. I've never used it. Having said that, it's more painful than it need to be to read in a file line by line but not horribly so:
BufferedReader reader = new BufferedReader(FileReader("myfilename.txt");
for (String line = null; (line = reader.readLine()) != null;) {
// do something with line
}
JDBC is a pretty arcane library. I've written a thin wrapper around it that makes it a lot easier to use for my own work. The great thing about JDBC is that you can talk to almost any database around with it. A guy I worked with at my last job had written a rudimentary tool for looking at database tables in grid form with Java. I could use it to connect to pretty much any database that provides a Java driver (I don't know of a DBMS that doesn't). At my current job we paid tons of money for a tool that can't do that. As far as I can tell it was a monumental effort to add support for a second DBMS. This kind of thing makes the pain of JDBC less severe, especially when you have multiple DBMS vendors. We have 4 or 5 here I think. ODBC works but it's really slow in my experience. It takes just as long to select all the columns from a table as it does to select one or at least it used to for certain drivers.
> The problem I was solving was an imperative, or at the > least declarative problem. And Java lets me write > imperative and declarative solutions, so long as I filter > them through OOP first.
But you don't have to. You can just write code. There's nothing about Java that forces you to use good OO design. Some people might argue that that is a problem.
> Of course, Perl lets me write OOP code when I want to; but > doesn't force me to write that code when I don't want to.
Perl's a great scripting language (if unreadable) but a pretty marginal OO language.
> Anyhow, writing fifty lines of code to do a ten-line job > is a pain point similar to water torture. You slowly burn > out typing the same thing over and over.
And I agree that Java shouldn't be used for these kinds of things. Use a scripting language like Perl or Python.
> /* Classes aren't Objects and static methods in Java have > basically nothing to do with OO. > */ > > That detour was my attempt to understand what you meant by > "you don't need to create Objects." I misunderstod you, > and so we can disregard that. > > Although. > > I want to transform data from my scanner before putting it > in the database. I don't think those methods "belong" in > the scanner class because the scanner's job is to read in > data, not process it. So I create a class, and give it > some forgetable name. I then realize that I don't need to > create objects of type "transformer," so I make every > method static. I don't see why this is better than simply > having free functions like every other language has. Java > programmers I know can never figure out why I would want > methods not attached to classes: "the almighty Gosling > says that this is the One True Way and Any Other Way would > Confuse Programmers."
I think you are just not buying into (Simula-style) OO. I think it has a lot of value but I would say that a lot of people who think that they are writing OO code in Java are not and don't really understand what value it provides. I don't really want to get into a long discussion about OO vs. say, functional programming because I think OO is good and so is functional and that they mix surprisingly well.
> Yes, water tortue style verbosity. No, it's not OO per > se. But it's the "Java is an OOP language *only*" > problem. Want to write something in another style? Tough > luck. you can only do that if you can convert it to OOP.
If you are talking about functional style programming, I agree you have to convert it and although that conversion is straightforward, it is verbose. This is precisely why Java needs function pointers. If you are saying you can't write procedural code in Java, I disagree because I see it all the time. Sometimes I think there's more procedural code written in Java than OO.
> /* [me] I don't want pointer arithmetic so much as I want > access to raw pointers or references. I don't want to > have to remember the details about when the implementation > will pass things by value and when it will pass things by > reference. Instead I want to be able to control that. > > [Response] There's not much to remember. Everything is > passed by value. I can't think of how it could be any > less complex than that. > */ > > My mistake. I run into issues trying to remember if Java > does deep copy of objects and shallow copy of primitives > or vice versa (that is, when can I say x = y, and when do > I have to say x.member = y.member; x.otherMember = > y.otherMember; ...). The rules seem to be based on the > implementation. That is, Java 1.0 did it this way because > of how Java 1.0 was implemented, therefore all versions of > Java shall forever do it this way.
I don't think this has changed. There are three rules you have to remember.
1. The value of an Object-type variable is a pointer. 2. The value of a primitive is it's data value. 3. All method arguments are passed by value.
What this means is that if you 'pass an Object' to a method, it's actually copying the value of that variable, which is a pointer to the actual Object. This is a really important thing that no one ever seems to teach in introductory Java classes. Often they tell people the wrong thing: that Objects are passed by reference and primitives by value. That commonly held misconception is one of the biggest problems in Java. It's almost correct but causes much confusion partly because it is almost correct.
> It doesn't lead to bugs, per se, but compile time errors. > And then the programmer comes to me saying "I'm writing > g this static method, and I want to call this non-static > method, and the compiler won't let me." Then I've got to > explain things. It's a pain point to me to have to teach > other programmers to distinguish between two different > thing that look identical (called through the dot > operator).
I really don't think those programmers are going to be better off programming in C++. Even if there was a different operator, people still need to understand the difference. I have a hard time with telling people rules of thumb instead of getting them to really understand.
> And since finalizers don't do the job for you, yes, > another pain point is remembering to write the needed try > { ... } finally { ... } blocks.
Watch out! I'm going flip-flop. If there was a way to capture when certain things fell out of scope and send an event to a monitor (something like ReferenceQueue perhaps) it would be a big improvement in Java. I think this is something that is needed in rare circumstances but when it is needed it's really needed. A special Reference type could be created to do this. Whether this is technically feasible in the current Java architecture is not something I can address.
> So it's not a technical reason, simply a "I think it's > best to do it this way, therefore Everyone Must Do It This > Way." I don't usually want to name a file 1.java (unless > it's in a directory, of say, tests; where I then need to > name it test1.java), but I don't see why Gosling should > *force* me to name my files according to his rules.
I believe the idea is that Java was meant to improve consistency in development. I like that people can't name things in stupid ways because no matter who wrote the code and how stupid they were, I can find their code in a reliable way. If it's just me maintaining my own code, then I'd say it probably doesn't matter. But if I need to look at code written by Clown-Town Consulting 5 years ago, I want things to be absolutely consistent. I don't want to hunt around for their source. For this same reason I love that Python forces indentation rules for code. I thought it was stupid at first but it's really a great thing.
It's kind of like operator overloading. I love writing overloaded operators myself. But when we bring in a bunch of 'genius' contractors I don't want them to create overloaded operators. Ever. So until there's a way that only I can create overloaded operators, then I don't want them in Java even though I personally would like them for writing code.
> As for finding methods in C++; cscope was developed for > that, but I've always found grep to do the job. > Additionally, in code that I write, I simply don't > t scatter things around because that's annoying (any more > than I overload operators with nonsensical uses). I > gather things together in ways that make sense logically, > regardless of the class hierarchy. In fact, my complaint > is that Java's rules make it just a little harder to > gather things together in one file. Java's rules > encourage organizing your source according to your class > hierarchy regardless of whether that makes sense for any > particular project.
I don't understand why you wouldn't want to organize your source according to your class hierarchy. Can you elaborate?
> > but I don't see why Gosling should > > *force* me to name my files according to his rules. > > I believe the idea is that Java was meant to improve > consistency in development. I like that people can't name > things in stupid ways because no matter who wrote the code
I definitely agree with this in spirit. It's much faster to search for a file name than to grep code searching for a particular class name, especially if there are thousands of classes.
Whenever we use (any) language, we have to stick to the rules the designer thought of, and most of those design decisions were surely made with good intentions. I'd say that this particular decision has its merits, seeing how it simplifies something that could be needlessly complicated.
In hindsight though, after seeing the partial classes feature in C#, I'm not so sure anymore whether it was wise to couple the class name to the physical file name.
/* I don't know why you would have to write a Scanner class. I've never used it. */
Fair enough. I'm not as conversant in Java as I am in other languages.
/* [Me] The problem I was solving was an imperative, or at the least declarative problem. And Java lets me write imperative and declarative solutions, so long as I filter them through OOP first.
[Response] But you don't have to. You can just write code. There's nothing about Java that forces you to use good OO design. ...
If you are talking about functional style programming, I agree you have to convert it and although that conversion is straightforward, it is verbose. */
I don't think any language can force somebody to use good design of any kind. But you do seem to understand my point (all styles must be filtered through Java's style, although it's trivial, tedius, mechanical conversion).
/* [Me] Of course, Perl lets me write OOP code when I want to; but doesn't force me to write that code when I don't want to.
[Response] Perl's a great scripting language (if unreadable) but a pretty marginal OO language. */
Either way, Perl allows me to write my functional code in a functional style, without filtering it through Larry Wall's One Approved Style. Perl also allows me to write my OOP, imperative, and declarative code in their respective styles.
I use Perl for small jobs and C++ for large ones. Java's not all that great for "scripting jobs"; we've established that. And Java was originally sold as a neutered version of C++ that wouldn't bite you. So it's not all that useful (to me) for large jobs, when I've got this more powerful language on my harddrive. I do write in Java, but only if somebody else already put in the effort to bang out a lot of code. I never start a Java program if I can help it.
/* I don't really want to get into a long discussion about OO vs. say, functional programming because I think OO is good and so is functional and that they mix surprisingly well. */
I agree, which is why I don't like the OOP-centricness of Java's design. And, yes, even that design hasn't been able to make everyone a good OOP programmer.
/* There are three rules you have to remember.
1. The value of an Object-type variable is a pointer. 2. The value of a primitive is it's data value. 3. All method arguments are passed by value.
What this means is that if you 'pass an Object' to a method, it's actually copying the value of that variable, which is a pointer to the actual Object. This is a really important thing that no one ever seems to teach in introductory Java classes. */
Thank you. That was what I was grasping for: this is an implementation detail that was allowed to become a rule that's not intuitive to the new programmers I know. And the fact that I only dabble in Java makes me remember there's a gotcha here, but I can never remember what.
/* I really don't think those programmers are going to be better off programming in C++. */
Neither do I, but then again, C++ was never sold as Java's successor.
/* Watch out! I'm going flip-flop. If there was a way to capture when certain things fell out of scope and send an event to a monitor (something like ReferenceQueue perhaps) it would be a big improvement in Java. I think this is something that is needed in rare circumstances but when it is needed it's really needed. A special Reference type could be created to do this. */
This is why I would like to access raw pointers or raw references. I'm always a little miffed when Perl libraries have to muck around inside the interpreter instead of being implemented in the language.
> > gather things together in one file. Java's rules > > encourage organizing your source according to your > class > > hierarchy regardless of whether that makes sense for > any > > particular project. > > I don't understand why you wouldn't want to organize your > source according to your class hierarchy. Can you > elaborate?
Indeed - this is one of the things I took away from Java and use in other languages (where it is not enforced). You might get away with putting stuff all over the place in your own code but as soon as you need to start working with others then: *put the code where it can be found!* - there is nothing worse than looking at someones source and having to load _every_ _single_ _file_ to find out where things are and what does what.
I completely believe this is a success in Java- it is designed for easy team coordination. In a way it is a form of convention over configuration.
Imagine if you could deploy an xml descriptor that would describe how your project was laid out for the compiler, instead of just having it be organized one way for everyone.
> /* [Me] Of course, Perl lets me write OOP code when I want > to; but doesn't force me to write that code when I don't > want to. > > [Response] Perl's a great scripting language (if > unreadable) but a pretty marginal OO language. > */ > > Either way, Perl allows me to write my functional code in > a functional style, without filtering it through Larry > Wall's One Approved Style. Perl also allows me to write > my OOP, imperative, and declarative code in their > respective styles.
But this is also the downside of Perl. It's the most unreadable language I've ever worked with. There's no telling what someone's Perl code looks like. I liken it to traffic laws. Often I would prefer to not have to stop at a red-light or yield to other vehicles. Sometimes it would be convenient to drive the wrong way down a one-way street. When I am in a hurry, it would be nice to be able to drive 80 miles an hour through a residential or commercial area.
If I was the only person on the road, this would be just fine. But this is a untenable situation in reality because these chaotic situations would inevitably lead to accidents.
So even though I would like to be able to drive however I want but I'm not lobbying to eliminate traffic laws.
Now I'm not saying you have to like the 'Java way'. But I disagree that the flexibility allowed by Perl and C++ is a good thing for large teams. It's a problem that must be solved and when the language enforces certain rules, it means I don't have to.
> I use Perl for small jobs and C++ for large ones. Java's > not all that great for "scripting jobs"; we've established > that. And Java was originally sold as a neutered version > of C++ that wouldn't bite you. So it's not all that > useful (to me) for large jobs, when I've got this more > powerful language on my harddrive. I do write in Java, > but only if somebody else already put in the effort to > bang out a lot of code. I never start a Java program if I > can help it.
This is fine if you can find and afford great C++ developers. But I have a hard enough time getting people to cope with Java. There's a cost that comes with powerful languages and sometimes it's very high.
> Thank you. That was what I was grasping for: this is an > implementation detail that was allowed to become a rule > that's not intuitive to the new programmers I know. And > the fact that I only dabble in Java makes me remember > there's a gotcha here, but I can never remember what.
It's an implementation detail, it's part of the language specification that was consciously and specifically chosen.
> /* I really don't think those programmers are going to be > better off programming in C++. > */ > > Neither do I, but then again, C++ was never sold as Java's > successor.
But how are you going to deal with all the questions they have when they look at C++? You are saying you use C++ over Java but then you are saying that Java is too confusing. C++ is way more confusing. The amount of knowledge required to use C++ effectively is orders of magnitude greater than with Java.
> /* Watch out! I'm going flip-flop. If there was a way to > capture when certain things fell out of scope and send an > event to a monitor (something like ReferenceQueue perhaps) > it would be a big improvement in Java. I think > this is something that is needed in rare circumstances but > when it is needed it's really needed. A special Reference > type could be created to do this. > */ > > This is why I would like to access raw pointers or raw > references. I'm always a little miffed when Perl > libraries have to muck around inside the interpreter > instead of being implemented in the language.
I don't quite see how accessing raw pointers solves this issue. Can you explain?
Since I haven't already responded to the "why would you want to name your file something other than That Which Gosling Decreed You Must Name Your File?" crowd, let me try once more.
I want to name my files whatever I feel like. Sure, this means I can abuse the privilege and name all my files XXy1, XyQ2, etc. but it also means I can name my files according to something other than their class hierarchy. After all, if I cared about the class hierarchy, I would open up javadoc. Sometimes the hierarchy says "I thought this class implemented the Liskov Substitution Principle for this base class," but sometimes it means "I used this class as an implementation detail for this other class." I may want to encode different information in the file name than just the class name. I don't think a programming language has any business telling me what to name my files.
If you think the rules work for you, great. If you think the compiler's job is to be your nanny, I'm willing to write a compiler for you that will tell you to "eat your vegetables, brush your teeth, drink eight glasses of water per day, get plenty of sleep" or whatever else you want to read.
It's not the compiler's job to determine file naming conventions. And when the compiler does, it causes a small cascade of inconveniences -- from dealing with the rules for, say, CVS (which makes removing files and directories a little annoying after you decided to merge two classes together), to naming files "test1.java" even though you know it's a test because it's in a directory called "tests."
***
Now:
/* [Me] Either way, Perl allows me to write my functional code in a functional style, without filtering it through Larry Wall's One Approved Style. Perl also allows me to write my OOP, imperative, and declarative code in their respective styles.
[Response] But this is also the downside of Perl. It's the most unreadable language I've ever worked with. There's no telling what someone's Perl code looks like. I liken it to traffic laws. Often I would prefer to not have to stop at a red-light or yield to other vehicles. Sometimes it would be convenient to drive the wrong way down a one-way street. When I am in a hurry, it would be nice to be able to drive 80 miles an hour through a residential or commercial area.
If I was the only person on the road, this would be just fine. But this is a untenable situation in reality because these chaotic situations would inevitably lead to accidents. */
I've heard this argument before, and I doubt I will convince you. I consider the flexibility in styles offered by Perl and C++ to be more like having different speed limits for different roads based on the conditions of those roads.
Java decided everything must be written in Simula-style "OOP." The Almighty Gosling Decreed it is the One True Way. It's like saying "the speed limit is 35 mph on every street because 35 mph is the One True Speed Limit."
I'm not saying I want to drive 80 mph on streets where it doesn't make sense. If it's a residential street, I may even be willing to drive slower. If OOP is the right style to solve a problem, I'm for it. But if it's not the right style, don't pee on my shoe and tell me it's raining.
Yes, this means I took much longer to get good writing C++ and Perl code. And, yes, it means I thought I was good very early on, and discovered otherwise when fundamental concepts gelled. But it also means I have more tools in my toolbox to attack problems.
/* [Original] If there was a way to capture when certain things fell out of scope and send an event to a monitor (something like ReferenceQueue perhaps) it would be a big improvement in Java. I think this is something that is needed in rare circumstances but when it is needed it's really needed. A special Reference type could be created to do this.
[Me] This is why I would like to access raw pointers or raw references. I'm always a little miffed when Perl libraries have to muck around inside the interpreter instead of being implemented in the language.
[Response] I don't quite see how accessing raw pointers solves this issue. Can you explain? */
My initial response wasn't thought out well enough. Lemme try again:
The system you've described solves one problem. But it does not solve any related problems. I would rather have a general framework that allows me to implement a solution to the original problem than have a particular solution to the particular problem.
That's where the Perl libraries part comes in. "We discovered something the language won't let us do, so we've left the language to do it" means that I also can't do something inside the language.
However, after closer thought, you are right that access to pointers (whether raw pointers like Gosling hates, or "safe pointers" that can never point to unitialized memory) does not solve this problem. So it's not a general framework.
/* If OOP is the right style to solve a problem, I'm for it. But if it's not the right style, don't pee on my shoe and tell me it's raining.
*/
to: If OOP is my hammer, and I need to drive nails, then great. But if I need to cut wood, paint the walls, or dig a ditch, don't hand me a bigger hammer. Don't even hand me a saw, paintbrush, or shovel with a hammer attachment.
And: /* That's where the Perl libraries part comes in. "We discovered something the language won't let us do, so we've left the language to do it" */
to: "We discovered something that the language won't let us do, so we've gone outside the language to do it."
My point being the language has no way of signaling something's fallen out of scope. So the proposed fix would have to be implemented outside the language and inside the interpreter. I would prefer it be fixed inside the language (or rather that the language be fixed) so that I have access to that framework to solve similar problems that may come up in the future.
Current good practice is to code to interfaces. Interfaces can't define constructors. Therefore, we get lots of godawful getFoo() / setFoo(). Which, IMO, is terrible OOP, but that's another topic.
It is a pain point for verbosity.
This causes two forms of verbosity: first, writing all the accessor methods (though an IDE can help). But, then when using the code, you have
If interfaces could define constructors (or static factory-like methods), which typically take multiple arguments, you wouldn't need to define all the setAs, you could pass the args in a constructor. Then maybe your object could be immutable, could be reasonably threadsafe, have good invariants, etc... If the interface also let you define public final variables, e.g.
public final int a; ... public final String z;
You don't need to code / define all the getters either.
Alternatively, using existing Java, instead of 26 sets we could define 1 monster method, setAtoZ(a,b,c,d...). This is an extreme case, probably don't want to do that, but for a more typical class you could define a few sets that deal with related information. This does not seem to be current preactice, which IMO is incorrect. Might be a case where varargs could come into play...
Another issue I see a lot is where one programmer has a MyFoo and because he is smarter than the guy who wrote Foo he refuses to use Foo. I am sick and tired of pages and pages of code going
especially when it is buggy and forgets that we recently added a field AA to the class.
With existing Java, I guess you could use reflection, find any property with the same name/type and copy it. But would be much cleaner if built into the language.
> I may want to encode different information in the > file name than just the class name.
In the example you cited, the information is about 200 characters long. Not suitable for a filename (nor a classname). Could you please give some examples of what would belong in a filename but not in the classname?
> to naming files "test1.java" even > though you know it's a test because it's in a directory > called "tests."
I believe this is a JUnit convention, not a Java convention.
> Java decided everything must be written in Simula-style > "OOP."
Unfortunatly, it didn't enforce this, it just tried to encourage this. Not sure how this is enforceable. Programmers can write FORTRAN in any language. (BTW, no ding on FORTRAN, I wrote lots of it and it's a fine language for many things)
> It's not the compiler's job to determine file naming > conventions. And when the compiler does, it causes a > small cascade of inconveniences -- from dealing with the > rules for, say, CVS (which makes removing files and > directories a little annoying after you decided to merge > two classes together), to naming files "test1.java" even > though you know it's a test because it's in a directory > called "tests."
Honestly, I think it's big waste of time to worry about this. I've got bigger fish to fry. If I have to name my class A instead of 1, I really don't care. It's completely inconsequential as far as I am concerned. There are a lot of things about every language I ever used that I didn't care for. Perl has the most, C++ comes in second. What difference does it make? If C++ is the right tool for the job, I'll use it. It's just not been the right tool since I graduated college. I probably won't use Perl because it's an abomination but that's another discussion.
> If I was the only person on the road, this would be just > fine. But this is a untenable situation in reality because > these chaotic situations would inevitably lead to > accidents. > */ > > I've heard this argument before, and I doubt I will > convince you. I consider the flexibility in styles > offered by Perl and C++ to be more like having different > speed limits for different roads based on the conditions > of those roads.
No, it's not like that because there are no limits. We don't have time to teach every contractor that comes through our 500 page style-guide. Java works and forces a pretty good level of consistency. You can clearly enforce your own rules and create large sets of rules about when to use this and when to use that but this is costly. With Java, a developer can sit down understand the code and find what he or she needs from day 1. Don't you see that there's an advantage to that?
> Java decided everything must be written in Simula-style > "OOP." The Almighty Gosling Decreed it is the One True > Way. It's like saying "the speed limit is 35 mph on every > street because 35 mph is the One True Speed Limit." > > I'm not saying I want to drive 80 mph on streets where it > doesn't make sense. If it's a residential street, I may > even be willing to drive slower. If OOP is the right > style to solve a problem, I'm for it. But if it's not the > right style, don't pee on my shoe and tell me it's > raining.
You keep saying 'me'. This seems to miss the point. The value of the rules is not on individual projects. It's value manifests itself projects with many developers.
> Yes, this means I took much longer to get good writing C++ > and Perl code. And, yes, it means I thought I was good > very early on, and discovered otherwise when fundamental > concepts gelled. But it also means I have more tools in > my toolbox to attack problems.
Perhaps. Perhaps you've not learned some other tools because you've had language features to do things for you. I'm confident that some of the limitations in Java have made me more skilled, not less.
> However, after closer thought, you are right that access > to pointers (whether raw pointers like Gosling hates, or > "safe pointers" that can never point to unitialized > memory) does not solve this problem. So it's not a > general framework.
What I'm still not getting is what having access to raw pointers buys you. Why do you need this?
> If interfaces could define constructors (or static > factory-like methods), which typically take multiple > arguments, you wouldn't need to define all the setAs, you > could pass the args in a constructor.
Unless classes are also Objects, this doesn't really solve anything because until you construct the Object, there's nothing to provide to someone else.
You can always define a second interface where the instances are factories for the first interface type. But this is verbose and a pain in the butt.
It's also what languages where classes are objects give you 'out of the box' which is why users of those languages are always bitching about Java.
> Unless classes are also Objects, this doesn't really solve
class MyClass implements static ClassInterface { }
then methods specified in ClassInterface are implemented in MyClass as static methods, and MyClass.class is an instance of ClassInterface. Perhaps in addition any method in ClassInterface with the name "newInstance" would be mapped to the constructor with the same parameter signature.
It seems simple enough to do but I'm not a language designer.
> > to naming files "test1.java" even > > though you know it's a test because it's in a directory > > called "tests." > > I believe this is a JUnit convention, not a Java > convention.
The number 1 (or rather, the character 1) is not a valid class name. Since the file is named after the class, I can't name the file 1.java. Instead, I have to make it a valid class name, say test1.java. Even though the file is in a directory called tests, and I already know it's a test.
End of the world? Nope; but it's a case of the compiler enforcing a rule that's not related to the compiler. It might as well refuse to run after 10:00 PM local time because that's Just Too Late to be programming.
Flat View: This topic has 264 replies
on 18 pages
[
«
|
34567891011
|
»
]
Previous Topic
