How to develop without an IDE?

M

markspace

wrote:

<snip/>

If you read what I wrote, I said that, in some aspects (which, to
me, there are a considerable number), some text editors are better
than IDEs. I did


What you wrote was, with the full context:

They also tend to be inferior in a considerable number of aspects,
particularly when compared with the features provided by some text
editors. Between being forced to stick with an IDE and managing the
build process by hand, the latter option sounds a lot better.


"A considerable number of aspects." Which is greatly different that
"some," according to my grade school English teacher.

Nonetheless, we should understand that there is no such thing as a
"one size fits all" solution. No IDE is the best tool for every
conceivable scenario ever faced by every programmer that ever lived.


Which was going to be my next point. I still use vim, grep, find,
strings, zip/jar as well as any other tool that happens to be the best
for the job at the time. I've got no problem using a different editor
for a job if it happens to provide some cool feature that I need. I'm
happy with my IDE is most respects, but sometimes I do use a different
tool if it does something my current tool won't.

Now, just to point out how a "modern IDE" is inadequate in some
circumstances, I can point you to those cases where a programmer,
for some reason, happens to need to work on some project with one of
those flimsy netbook computers, the ones with tiny monitors and
limited disk space. Running an IDE on one of those systems is an
experience that only a masochist can enjoy, and even then he would
have trouble doing any work. Meanwhile, it isn't hard to find a
bunch of text editors that work perfectly well with those
limitations.


Weak sauce. I do develop on a flimsy notebook with a small screen
exclusively -- a Fujitsu Lifebook. And with a couple of mouse clicks my
IDE will expand to full screen (and back, with a couple of more). If I
bother to use the actual options menu, I can increase the font size to
anything I like. (I just increased it to 14 point, just to check it. I
can read my text from across the room now!)
 
M

markspace

wrote:

<snip/>

If you read what I wrote, I said that, in some aspects (which, to
me, there are a considerable number), some text editors are better
than IDEs. I did


What you wrote was, with the full context:

They also tend to be inferior in a considerable number of aspects,
particularly when compared with the features provided by some text
editors. Between being forced to stick with an IDE and managing the
build process by hand, the latter option sounds a lot better.


"A considerable number of aspects." Which is greatly different that
"some," according to my grade school English teacher.

Nonetheless, we should understand that there is no such thing as a
"one size fits all" solution. No IDE is the best tool for every
conceivable scenario ever faced by every programmer that ever lived.


Which was going to be my next point. I still use vim, grep, find,
strings, zip/jar as well as any other tool that happens to be the best
for the job at the time. I've got no problem using a different editor
for a job if it happens to provide some cool feature that I need. I'm
happy with my IDE is most respects, but sometimes I do use a different
tool if it does something my current tool won't.

Now, just to point out how a "modern IDE" is inadequate in some
circumstances, I can point you to those cases where a programmer,
for some reason, happens to need to work on some project with one of
those flimsy netbook computers, the ones with tiny monitors and
limited disk space. Running an IDE on one of those systems is an
experience that only a masochist can enjoy, and even then he would
have trouble doing any work. Meanwhile, it isn't hard to find a
bunch of text editors that work perfectly well with those
limitations.


Weak sauce. I do develop on a flimsy notebook with a small screen
exclusively -- a Fujitsu Lifebook. And with a couple of mouse clicks my
IDE will expand to full screen (and back, with a couple of more). If I
bother to use the actual options menu, I can increase the font size to
anything I like. (I just increased it to 14 point, just to check it. I
can read my text from across the room now!)
 
G

Gene Wirchenko

On Tue, 24 Apr 2012 11:24:14 -0300, Arved Sandstrom

[snip]
I'll tell you what no Java developer's career depends on: being able to
write a makefile to build a Java project.

Does someone's career depend on being able to use Ant? If it
does, then why can he not simply pick it up when he needs it?

I prefer to learn to use tools that will be of use to me in
preference to those that only might. There is so much software out
there that I have to budget my learning time to items which will give
me a return.

Sincerely,

Gene Wirchenko
 
G

Gene Wirchenko

They also tend to be inferior in a considerable number of aspects,
particularly when compared with the features provided by some text editors.

I am using Dreamweaver for Web development. Its editor forces
tabs into files and does not have a current column indicator. Both
lacks are antipathetic to how I code. When I know enough, I am very
likely to switch to something else.
Between being forced to stick with an IDE and managing the build process by
hand, the latter option sounds a lot better.

I like the idea of an automated build, but I would want the
option of handling it myself. The problem with too much of this
automation is that one has to really dig to find out how to do it
without the IDE.

Sincerely,

Gene Wirchenko
 
G

Gene Wirchenko

[snip]
"A considerable number of aspects." Which is greatly different that
"some," according to my grade school English teacher.

I hope you fired him.

How many aspects? Say, 32. Is that a considerable number of
aspects? Yes. Does 32 qualify as some? Yes.

"A considerable number of aspects" is a subset of "some". Since
one includes the other, they are not greatly different.

Your statement is like claiming that white dogs and dogs are
greatly different.

[snip]

Sincerely,

Gene Wirchenko
 
G

Gene Wirchenko

Baloney. Love the vague statements, "tend to be inferior" without specifics or statistics. Classic Troll-speak.

Since an IDE is a combination of a number of things (editor,
compiler, debugger, what else) and since preferences vary so greatly,
a given user may well be able to select a better set of things that do
the job. "better" is by his standards. And you could do the same by
yours.

So which losing side are you on? (I think all sides lose when it
gets past editor *discussion*.)

[snip]

Sincerely,

Gene Wirchenko
 
B

BGB

They also tend to be inferior in a considerable number of aspects,
particularly when compared with the features provided by some text editors.
Between being forced to stick with an IDE and managing the build process by
hand, the latter option sounds a lot better.

yeah, there are a few problems IMO with many IDEs:
trying to manage and automate too much of the process;
not being terribly flexible for allowing the developer to do what *they*
want regarding the build.

ultimately, it largely renders an IDE a glorified text editor and
debugging interface, with much more building-related tasks being handled
on the command-line.

sadly, this seems to be a common problem with many sorts of tools.

or such...
 
A

Arved Sandstrom

On Tue, 24 Apr 2012 11:24:14 -0300, Arved Sandstrom

[snip]
I'll tell you what no Java developer's career depends on: being able to
write a makefile to build a Java project.

Does someone's career depend on being able to use Ant? If it
does, then why can he not simply pick it up when he needs it?

I prefer to learn to use tools that will be of use to me in
preference to those that only might. There is so much software out
there that I have to budget my learning time to items which will give
me a return.

Sincerely,

Gene Wirchenko

Does someone's career - let's say current job - *depend* on knowing Ant?
I doubt it, not in and of itself. But if I had someone working for me as
a Java developer, unless they were an absolute newbie I'd look askance
at them not knowing certain things by a certain point in their
professional development.

I have worked with intermediate Java developers - people who have used
basically nothing but Java in their entire career - who don't know Ant,
don't know Maven, don't know Ivy, don't know Hudson/Jenkins or any other
CI system, only know JUnit - sort of - out of all the available test
frameworks, aren't up to speed on any Java API except for the ones that
they've had to use for work. You then come to find out that they barely
know XML: no knowledge (or very deficient knowledge) of XSLT or XPath,
for example. You come to find out that they don't know Powershell on
Windows, bash or sh or ksh on UNIX, or even DOS-type batch files. They
have only superficial knowledge of regular expressions.

The list goes on and on, and I've worked with plenty of intermediate
(and some senior) developers who have a poor grasp of *everything* I
just listed. And more.

So is not knowing Ant a kiss of death for some Java developer's career?
Not by itself, probably not. But it's, in my experience, a strong
indicator that they've probably neglected whole swathes of stuff they
should be conversant with.

I have a great deal of tolerance for someone who has to learn something
unexpected. We all have to do that on occasion. I have considerably less
tolerance for an intermediate or senior developer who is _routinely_
having to "pick up" skills just when they need it. They're doing it on
company time and client time.

AHS
 
A

Arved Sandstrom

I am using Dreamweaver for Web development. Its editor forces
tabs into files and does not have a current column indicator. Both
lacks are antipathetic to how I code. When I know enough, I am very
likely to switch to something else.


I like the idea of an automated build, but I would want the
option of handling it myself. The problem with too much of this
automation is that one has to really dig to find out how to do it
without the IDE.

Sincerely,

Gene Wirchenko

The funny thing is, it's not such a big deal to build, package and
deploy even complicated-looking projects to typical Java EE app servers
on the command line. The information - I find - is readily available.
It's a useful exercise to do this every so often - no Ant, no IDE,
nothing except command line - so that you have a good feel for what your
IDE is doing under the hood. This includes all configuration and
operation of the app server as well.

AHS
 
B

BGB

The funny thing is, it's not such a big deal to build, package and
deploy even complicated-looking projects to typical Java EE app servers
on the command line. The information - I find - is readily available.
It's a useful exercise to do this every so often - no Ant, no IDE,
nothing except command line - so that you have a good feel for what your
IDE is doing under the hood. This includes all configuration and
operation of the app server as well.

personally, I would be more happy with many IDEs (or, at least leaving
them in control of the "project" and "build process"), if the build
process were itself readily available and an editable part of the project.

after all, a person builds the GUI, they get code, and they can edit the
code if they need to.

how much control do they have over, say, which tools are run, or the
command-lines passed to the tools?...

not a whole lot.

if one is lucky, it is partly available in some arcane-looking set of
dialog boxes off in a menu somewhere, and in others, it is nowhere to be
found.


meanwhile, if manually building a project, it is fairly easy to add
custom tools or build-targets to the process (assuming the person knows
and understands the process), ...


now, why is it this way?...

OTOH, some fancier text editors, end up sort of resembling an IDE, but
generally without project-management features or integrated debugger or
profiler support (kind of a loss).


or such...
 
M

Martin Gregorie

It isn't supposed to be ant's problem. Yet, it doesn't make it an
acceptable alternative for every conceivable scenario, let alone the
ideal solution. And that's precisely the point.
Sure, but there scenarios where not knowing it is very definitely your
problem. Here's a fairly common one: you join a project team where the
project standards are enforced and they say Ant is the project build
tool, but you don't know it. You may be cut some slack while you get up
to speed on Ant but you may well find yourself out on your ear if you
insist on using something else, e.g. make. As AJS says, if the project is
about to hit a deadline your need to learn on the job will not make you
popular with the PM or other team members if your reduced productivity
while learning the tool causes a milestone to be missed.
 
L

Lew

Rui said:
It was a hyperbole.

And we were supposed to know that how...?

I see no exaggeration in your comment at all.
And surely you are aware that a considerable number of people who spend a
portion of their time writing Java code don't exactly make that their
profession.

Are you claiming that non-professionals should deliberately flout best practices, simply because they don't make a living at it?

The main point here, which you're ducking, is that no one can be a Java programmer, professional or otherwise, without having heard of Ant or being more than superficially aware of it. Your statement about being "unaware thattool B even existed" is utterly irrelevant to this issue.
It isn't. But wasting time checking each and every alternative that some
bloke on the internet said was the winning strategy is also not a winning
strategy.

This isn't a case of that, so why mention it?
It isn't expected to. That's the job for the compiler, which is called by
the automated build tool.

If I'm not mistaken, this is also what ant does. Someone correct me if I'm
wrong.
http://ant.apache.org/manual/Tasks/javac.html

Ant does all sorts of things superficially similar to make, but better whenit comes to Java.
As you can imagine due to the fact that I've started this thread, I never
managed to do this nor know how to pull this off. The reason I said that
maybe built-in rules aren't needed to build java programs with the make tool
is the fact that it is quite possible to build software written in a number
of programming languagea without relying on built-in rules.

Nevertheless, after a quick google, I stumbled on a tutorial on how to
"write and use makefiles to build java applications". It doesn't rely on
static pattern rules, and instead uses suffix rules. I don't know how well
this works, but you are free to give it a try and see if it doesn't work.

On a side note, I don't believe that the point is to prove that the make
tool can be made to work better than alternatives such as ant, but only that
it actually works.

It would have to be better to justify its use, since Ant is the standard. As it happens, make is worse for Java projects than make, so that's a huge strike against it.

Unwillingness to learn the standard tool (which really only takes about an hour or two to learn, BTW) is a pitiful and non-engineering reason to avoidusing Ant.
 
M

markspace

personally, I would be more happy with many IDEs (or, at least leaving
them in control of the "project" and "build process"), if the build
process were itself readily available and an editable part of the project.


Just FYI: NetBeans actually generates an ant build file and uses it
exclusively to build projects. Anytime you want to change the internals
of how NetBeans builds, just edit the build.xml file.

I'd recommend checking the project's Properties first, but if you don't
find what you need there, a little work with the build script will fix
things right up.
 
L

Lew

markspace said:
Just FYI: NetBeans actually generates an ant build file and uses it
exclusively to build projects. Anytime you want to change the internals
of how NetBeans builds, just edit the build.xml file.

Uh-huh. Have you tried this yourself?

In the first place, you don't edit the build.xml but the ancillary build file that build.xml incorporates.

In the second place, the generated build script is a tour de force, but verbose and heavy. It is likely more than you'd hand-craft. I usually eschew the NetBeans build.xml as too IDE-specific, and create one from first principles. I recommend that practice.
I'd recommend checking the project's Properties first, but if you don't
find what you need there, a little work with the build script will fix
things right up.

A "little" work indeed - seriously, have you tried this?
 
B

BGB

Just FYI: NetBeans actually generates an ant build file and uses it
exclusively to build projects. Anytime you want to change the internals
of how NetBeans builds, just edit the build.xml file.

I'd recommend checking the project's Properties first, but if you don't
find what you need there, a little work with the build script will fix
things right up.

can't really claim to have used NetBeans.

mostly, I was writing from experience with Visual Studio and Eclipse,
which are not exactly all that friendly IME to a user-customizable build
process...

yes, there are some workarounds, but still...
 
M

markspace

In the first place, you don't edit the build.xml but the ancillary
build file that build.xml incorporates.
A "little" work indeed - seriously, have you tried this?

I've added small changes to a NetBeans build file. I've never attempted
large or wholesale changes.

I just double checked, and it's the other way around: The main
build.xml file is the one you edit. It's empty, except for the project
header and an include of the generated targets (one line), and a really
long comment explaining the targets that NetBeans uses to build your
program.

The trick is to get the right dependency on the right target. I've
found that the -pre and -post targets should be ignored. Those never
seem to do anything useful. Just base your own stuff on the real
targets, and it all builds normally.

If you're doing large changes, I can see that it might be unworkable.
You're probably better off using the "free form" NetBeans project type,
and just managing the build file entirely yourself. But if you're
adding small bits to the existing paths or other configuration, or
you're adding small build targets, it's easy.
 
A

Arne Vajhøj

It can only make no sense if you believe that any statement regarding how a
particular text editor compares to the text editor made available by a
specific IDE is something which can be expressed objectively in absolute
terms. It isn't. Taste and personal preferences are, well, personal.
These are subjective opinions, which each of us holds, that reflect nothing
more than our personal tastes, preferences and even habits.

????

There is certainly a strong element in personal preferences for
specific tools.

But that has absolutely no relevance.

You were not talking about specific tools but about IDE's and
text editors.

And you were talking about features provided not whether
you liked them or not.
So, unless we believe it is a good idea to waste time discussing how a
particular text editor is better or worse than any other text editor,
mentioning specific text editors, and how someone uses them, is perfectly
irrelevant, and we would only focus on that irrelevant detail if we had
missed the point.

Well - you brought up the discussion about features provide by IDE's
and editors.

And we pointed out that you were wrong because editor+tools does
not have less features than editor.

And the rest is just your hopeless pathetic attempts to avoid
admitting your fault.

Arne
 
A

Arne Vajhøj

I am using Dreamweaver for Web development. Its editor forces
tabs into files and does not have a current column indicator. Both
lacks are antipathetic to how I code. When I know enough, I am very
likely to switch to something else.

I would be tempted to consider Dreamweaver a design tool and not an IDE.
I like the idea of an automated build, but I would want the
option of handling it myself. The problem with too much of this
automation is that one has to really dig to find out how to do it
without the IDE.

I can not think of one widely used IDE that does not work
with command line build tools (typical ant for Java IDE's).

Arne
 
A

Arne Vajhøj

You are assuming that everyone's career depends on how well they are able to
manually set up an ant build script to build a Java project. That's a bad
assumption. I would bet that a significant number of people who write Java
code for a living never bothered to manually tweak an ant build script, let
alone took the time to learn that tool.

Almost no good Java developers.

Good Java developers like good developers in any language like
to learn and broaden their skills.

The "I don't want to do build scripts - I will leave that to the
integration engineers" developers will be considered second class
developers.

Arne
 
R

Rui Maciel

Lew said:
And we were supposed to know that how...?

I see no exaggeration in your comment at all.

You already shown that you have a bit of a problem in basing your arguments
and criticism on unfounded assumptions. In this case, you even choosed to
ignore that the example I gave was between "tool A" and "tool B", not make
and ant, which certainly no one else had any trouble understanding that it
was purely figurative.

Are you claiming that non-professionals should deliberately flout best
practices, simply because they don't make a living at it?

I made no such claim. I would appreciate it if you stopped trying to pin on
me these wild claims you are making up as you go along.

The main point here, which you're ducking, is that no one can be a Java
programmer, professional or otherwise, without having heard of Ant or
being more than superficially aware of it. Your statement about being
"unaware that tool B even existed" is utterly irrelevant to this issue.

This is not nor it ever was the main point. Nor a side note, even. You
knack for making wild assumptions led you to make this stuff up. If you
have any doubt then simply point out exactly where anyone besides yourself
ever mentioned anything remotely similar to that.

This isn't a case of that, so why mention it?

Frankly, that's what every single one of those blokes on the internet says.

As a warning, I should inform you that this was also a hyperbole.

It would have to be better to justify its use, since Ant is the standard.

By your reasoning, you should be using make as it is actually the standard
in the real sense of the word. ISO standard and all. Instead, it appears
you are hell-bent on criticising make.

As it happens, make is worse for Java projects than make, so that's a huge
strike against it.

Unwillingness to learn the standard tool (which really only takes about an
hour or two to learn, BTW) is a pitiful and non-engineering reason to
avoid using Ant.

Again with your unfounded assumptions and baseless accusations. Can you
point out exactly where anyone stated that they refused to learn how to use
ant or even maven? You can't, because no one, besides you with your wild
imagination, ever said it.

So, you either are a functional illiterate or a troll. Either way, you are
not helpful. So, if you don't have anything helpful to add then go waste
your time and your wild imagination elsewhere.

Rui Maciel
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,439
Members
44,829
Latest member
PIXThurman

Latest Threads

Top