Do you suggest me using IDE when I'm learning JAVA
in [Java Programming]
|
Prev: call jni function dynamically without getting a JNIEnv handleas an argument.
Next: Telnetting to diff IP with same port number
From: Graham on 6 May 2010 02:23 Clarence Blumstein <blumstein.clarence(a)gmail.com> wrote: > Do you suggest me using IDE when I'm learning JAVA? because I'm about > to using Eclipse when I'm learning JAVA? Did you using IDE while/when > are a beginner? > I haven't read the whole thread but when I started tinkering with Java on Unix all I had was Vi. I never liked Forte, end up using Eclipse, tried JBuilder but found it less reliable than Eclipse, never spent the time learning NetBeans when I should have given it a fair shot. Now you don't say what your experience is. If you are a total beginner (or near enough) give BlueJay a shot. It isn't an IDE but a graphical learning tool that you can write Java and execute bits of your code. Graham
From: Arved Sandstrom on 6 May 2010 05:42 Arne Vajh�j wrote: > On 04-05-2010 05:17, Arved Sandstrom wrote: >> Arne Vajh�j wrote: >>> On 03-05-2010 07:08, Arved Sandstrom wrote: >>>> I think it would depend on the role of the developer and the particular >>>> methodology in use - 50%+ time spent in the IDE might not be indicative >>>> of a low state of software process, or it might be. >>>> >>>> And after all, IDE does mean _Integrated_ Development _Environment_. In >>>> theory a developer could be knocking out everything from requirements >>>> analysis through design and coding to running/analyzing tests in one of >>>> those puppies. >>> >>> Sure - but no matter if he is creating UML, Java LOC's or running JUnit >>> tests, then I would expect thinking to dominate over typing. And >>> thinking is a process that unfortunatetly does not benefit from better >>> tools. >> >> If (taken from Wikipedia) thought/thinking is "an intellectual exertion >> aimed at finding an answer to a question or the solution of a practical >> problem", which is a good definition for our purposes, then how could >> something which is designed to help us create and organize and present >> information _not_ contribute to better thought/thinking? > > The problem is that IDE's are very good at helping with the > trivial stuff (like generating getters and setters, finding syntax > errors etc.) and does not provide much for all the difficult > stuff (designing API's, designing data structures, picking > algorithm etc.). > > Arne You're quite correct...if your process for doing the "difficult" stuff doesn't involve using an IDE. However, in real-life most APIs, data structures etc get designed through an iterative coding process in an IDE. There's nothing wrong with this approach per se. Clients of an API only see it when they get it, and if your design process leading up to API release happened to include lots of refactoring in an IDE, as opposed to UML diagramming and so forth, so what? Let's look at this another way: why is it somehow superior to do lots of editing and thinking while using UML and pencil & paper, and it's somehow inferior to do the same editing and thinking with code? If I'm thinking up method signatures for my new interface, it's totally immaterial as to whether I draw a pretty UML diagram or code them up in a Java interface right away. I may as well - the Java interface is as meaningful to me or any other programmer as staring at a UML diagram, and at that stage it's very much a legitimate design artifact. And my personal belief is that you're more likely, 90 percent of the time, to get an equally good result faster by involving an IDE at an early stage, and starting to refine your API or data structure through use in tests. Your tests are expressing your planned usage...and *testing* the actual implementation as you refine it. Let's be real - if you did a whack of design first you'd still end up doing all that coding and _refactoring_ and testing anyway, 90 percent of the time...and overall needed more time to attain the same result. The important thing in software production is that we have good requirements analysis, good analysis & design, good implementation, good testing and so forth. But IMHO it's still very much a traditional waterfall mentality that the design, for example, cannot involve writing code. A lot of the coding in newer methodologies isn't really implementation - it's design. And this process - design refinement in code - is assisted by IDEs. AHS
From: Tom Anderson on 6 May 2010 09:23 On Wed, 5 May 2010, Arne Vajh?j wrote: > On 04-05-2010 19:40, Tom Anderson wrote: >> On Mon, 3 May 2010, Arne Vajh?j wrote: >> >>> On 03-05-2010 07:08, Arved Sandstrom wrote: >>>> Arne Vajh?j wrote: >>>>> But please don't use the term software ENGINEERING about a >>>>> process that spends 50-75% of the time in the IDE. >>>> >>>> I think it would depend on the role of the developer and the particular >>>> methodology in use - 50%+ time spent in the IDE might not be indicative >>>> of a low state of software process, or it might be. >>>> >>>> And after all, IDE does mean _Integrated_ Development _Environment_. In >>>> theory a developer could be knocking out everything from requirements >>>> analysis through design and coding to running/analyzing tests in one of >>>> those puppies. >>> >>> Sure - but no matter if he is creating UML, Java LOC's or running >>> JUnit tests, then I would expect thinking to dominate over typing. And >>> thinking is a process that unfortunatetly does not benefit from better >>> tools. >> >> No, this is rubbish. Programmers don't spend ages sitting there >> thinking, and then do a bit of typing. This is pure fiction. We think as >> we type - we think *by* typing, by putting our ideas down, working >> through the details, trying things out, seeing what works and what >> doesn't. Masses of thinking goes on, but it's not like some caricature >> of a mathematician, staring at a ceiling for days on end and then >> jotting down a complete theorem at the end of it. To do the thinking, >> you have to work through it - and better tools let you work through it >> faster. If by the use of autocomplete and type inference and whatnot i >> can flesh out a for-loop over the entries of a map in which i filter the >> keys with such-and-such a test and transform the corresponding values >> with this-or-that function in thirty seconds rather than three minutes, >> then that's two minutes and thirty seconds less that's taken me to learn >> if my idea for the loop works or not. That's the kind of thing i spend >> my time doing when i program, and an IDE does help me to do that faster. > > But that is not how good software gets created. > > Any software of real world size will be unmaintainable. Real complex > software created that way will never even work. > > You analyze requirements, come up with an architecture and a > design. Producing the actual code is a minor part of the work. Have you just fallen through a timewarp from the 1970s or something? That's called 'waterfall', and it doesn't work. > The before mentioned paper has some statistics for productivity. It > varies with code complexity and project size. But all are in the range > of 1-25 man months per KLOC. That is 1/4-6 lines per hour. Either they > are extremely slow typists or they actually do some heavy thinking > between the typing. Or producing one finished line of code involves typing more than one line of code. > The most extreme form I have ever heard about were a project for some > traffic control system - the engineers spend all their time writing a > formal specification of requirements and functionality - and then they > got somebody else to do the trivial work of typing in the Ada code > (which could then be verified against the specs). Cases like that have been recorded (the guy on the MULTICS project someone posted about earlier). They get recorded because they're so exceptional - the great majority of software is not built that way. I would be very interested to know in detail how that project was done, though; i'd make a small wager on the ground truth being rather divergent from that description. tom -- File under 'directionless space novelty ultimately ruined by poor self-editing'
From: cr88192 on 6 May 2010 15:06 "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4be21ea7$0$277$14726298(a)news.sunsite.dk... > On 04-05-2010 22:33, BGB / cr88192 wrote: >> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message >> news:4bdf807c$0$285$14726298(a)news.sunsite.dk... >>> On 03-05-2010 08:46, Tom Anderson wrote: >>>> On Mon, 3 May 2010, Arved Sandstrom wrote: >>>>> I think it would depend on the role of the developer and the >>>>> particular methodology in use - 50%+ time spent in the IDE might not >>>>> be indicative of a low state of software process, or it might be. >>>> >>>> I find what i assume to be Arne's point shocking. The ideal software >>>> process would spend *100%* of its time writing code, because it would >>>> have optimised all the supporting activities to the point where all >>>> working time could be put into the one activity that actually produces >>>> the output. >>> >>> You think it is shocking that software engineers should spend more time >>> thinking about the problems instead of typing full speed in their IDE? >>> >>> I think the definition of engineering is to think more than type. >> >> I think I think more than type, but practically this is a massive >> time-waster relative to actually getting code written... >> >> it is like spending time speculating about the future: >> this is wasting time, since the future is has not happened yet. > > The difference between good code and bad code can be rather > significant in cost. > > It may cost more to produce good code, but over the life cycle > of a typical application bad code will turn out to be a lot more > expensive. > this doesn't mean one has to forsake good conventions, such as using regular naming conventions, or modularizing things, ... also effective I have found is to find things which are similar, and use them as design templates. in this case, bad design decisions which didn't work, and so were dropped, will generally have already been caught by the prior implementation. or, someone can cross-reference between different designs for similar things, and see if they can find a good set of tradeoffs... only that one need not sit around trying to plan out everything in advance (into some distant future-time...). since almost inevitably, this wastes lots of time thinking (say, a person spends 5 hours planning what only takes them 1 hour to write), when they could have easily gotten much more done. similarly, if one tries to address the future, almost inevitably the thing ends up over-complicated and over-engineered in ways which don't ideally match the project at hand, or don't exactly match how the project will go in the future. over-complexity and over-engineering is something to be avoided... what then typically matters is making the code work right then, and any problems can be fixed up as one goes along. (and in the long run, this often ends up with the better solution...). if it aint broke, don't fix it (unless there is some clearly better solution...). take for example, Microsoft: much of their technology is built upon decades of kludgery and relatively short-term hacks to address all manner of problems. take for example .NET binary images (which are essentially a hacked over version of PE/COFF, which is a hacked-over version of COFF and DOS-style EXE's...). but, it all works fairly solidly none-the-less... they get Windows sold, and they provide a platform with many niceties and conviniences. if it were really that bad, they would either get stuck in their own mess (unable to add more features, ...), or consumers would be unwilling to buy their products, or something...
From: cr88192 on 6 May 2010 15:49
"Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4be222a6$0$279$14726298(a)news.sunsite.dk... > On 04-05-2010 19:40, Tom Anderson wrote: >> On Mon, 3 May 2010, Arne Vajh?j wrote: >> <snip> >> >> No, this is rubbish. Programmers don't spend ages sitting there >> thinking, and then do a bit of typing. This is pure fiction. We think as >> we type - we think *by* typing, by putting our ideas down, working >> through the details, trying things out, seeing what works and what >> doesn't. Masses of thinking goes on, but it's not like some caricature >> of a mathematician, staring at a ceiling for days on end and then >> jotting down a complete theorem at the end of it. To do the thinking, >> you have to work through it - and better tools let you work through it >> faster. If by the use of autocomplete and type inference and whatnot i >> can flesh out a for-loop over the entries of a map in which i filter the >> keys with such-and-such a test and transform the corresponding values >> with this-or-that function in thirty seconds rather than three minutes, >> then that's two minutes and thirty seconds less that's taken me to learn >> if my idea for the loop works or not. That's the kind of thing i spend >> my time doing when i program, and an IDE does help me to do that faster. > > But that is not how good software gets created. > it depends on who is defining "good"... > Any software of real world size will be unmaintainable. Real complex > software created that way will never even work. > I have an approx 300 kloc compiler/VM framework (it was closer to 500 kloc, but I shaved it down some mostly by a great dead-code cleanup...). and, very little planning was done up front... (although, admitted, I often write a short spec describing what feature I am considering and maybe do a mock-up of the API, so it is maybe more design than simply beating it together and beating it into working...). in fact, most of the time I have little idea where it is I am going (in the long term), so in large part the overall design magically appears out of nowhereland... most of the time is spent instead adding features and fixing problems... > You analyze requirements, come up with an architecture and a > design. Producing the actual code is a minor part of the work. > I say, this doesn't scale... much above about a 25-50 kloc component, this doesn't seem like a reasonable strategy... my strategy is more like biology, where code may be duplicated and refined, and components may be split when they become too large or complex, and dead or useless code and features are shaved off. > The before mentioned paper has some statistics for productivity. > It varies with code complexity and project size. But all are > in the range of 1-25 man months per KLOC. That is 1/4-6 lines > per hour. Either they are extremely slow typists or they actually > do some heavy thinking between the typing. > yeah, that is slow... my output volume tends to be a bit higher, even though I still spend most of my time doing other stuff (unrelated to coding or design...). > So no - it is not fiction that software engineers think more > than type. > dunno... maybe most of them are just lazy... nothing broke that day == free day to watch stuff and play games... maybe they can use a KVM switch and a VGA-box to hide the XBox360 hidden under their desk if their boss just happens to wander by... can't miss the next episode of Shippuden or One Piece... oh wow, the Spoony One has released another review and Nostalgia Critic has reviewed another movie, can't miss this... and at the slightest hint of hearing steps in the background, a quick double-scroll-lock or alt-tab and they are back in Visual Studio or Eclipse, starting intently at whatever is the current problem, busy away at the task at hand, or at least until the boss has left again... > The most extreme form I have ever heard about were a project > for some traffic control system - the engineers spend all > their time writing a formal specification of requirements > and functionality - and then they got somebody else to > do the trivial work of typing in the Ada code (which could then > be verified against the specs). > now what is the cost of a bug in a traffic-control system: well, apart from obvious problems, like 2 green lights and traffic colliding head-on, or a green light at the same time as the cross-walk, probably not a whole lot to go wrong... if they really want to know, they could beat together some tests or a traffic simulation to look for bugs or performance bottlenecks... > No - I don't think that approach is cost efficient for most > apps where it is only about money. But it illustrates how > pure engineering software development can be. Let us call > it the other extreme from your 100% typing and thinking as > you type approach. > I don't think it is effective for most apps... I also don't think it is likely to result in good software either. there is far more that a person is likely to see when testing or using an application than when pondering about it... someone with paper: wow, this design is so elegant, ... person using the app: wow, this sucks, who the hell thought it was a good idea to put this over here?... they run it through the profiler, and find that some unanticipated design issue has caused performance to be horrible, ... problems like horrible UI's, terrible performance, or unusable bugs, are fairly likely to show up in use, but are trivial to overlook if one is trying to design something on paper... at least with solid prototypes, one can know the thing works, and it is simply a matter of beating out most of the bugs prior to the final release... or such... |