How to develop without an IDE?

G

Gene Wirchenko

On 4/25/2012 12:13 PM, Gene Wirchenko wrote:
[snip]

But it is only 1/3 of the problem that is the actual lack
of Ant skills - the 2/3 of the problem is the attitude.

Yes.

I am highly-resistant to flavour of the<time period>.

Ant has been widely used for over a decade!

I was discussing the general case. I have seen too many cases of
"This is the greatest tool since ..." and when I try it, it fails on
very simple cases of mine.

Well the thread was about build tools.

And the argument were to use ant.

I don't think anyone has claimed a need to learn any tool under
the SUN.

Of course not. Everyone and his dog says to use his tool. The
collective of all that yammering is one should use every tool under
the sun.

[snip]
The point people were trying to make is that you will not look
good at the Java job market if you don't know ant - especially
not with arguments like some of those posted here.

To your first sentence: Yes, I understand that not knowing
certain things can have an effect on getting jobs, but to judge
someone totally or substantially on whether he knows one particular
tool goes way too far.

To your second sentence: Nice smear.

Sincerely,

Gene Wirchenko
 
A

Arne Vajhøj

You keep putting twists in your responses. I did not say "only";
you have just added it.

Yes.

Because I assume that is what you meant.

But let us get it clarified. Do you mean:
A) developers should learn the common tools (ant and maven for Java build)
B) it is fine developers with developer only knowing less used tools
?
Simple negation. If 30% to 50% of all Java developers use
certain tools, then 100%-30% to 100%-50% (= 70% to 50% which
normalises to 50% to 70%) do not.

It is 30-50% each.
1) Overlap. Some use both.

Your 50-70 assumes perfect overlap.

That is certainly not the case.

And the survey in question (Eclipse 2011) was asking about typical
build system, so the overlap must be very small.
2) It was your figure. Perhaps, you got it wrong. This is not
normally a big deal, but when you keep hammering on a point, it would
be nice if you had your facts straight.

What facts are not straight?

Arne
 
A

Arne Vajhøj

On 4/25/2012 12:13 PM, Gene Wirchenko wrote:
[snip]

But it is only 1/3 of the problem that is the actual lack
of Ant skills - the 2/3 of the problem is the attitude.

Yes.

I am highly-resistant to flavour of the<time period>.

Ant has been widely used for over a decade!

I was discussing the general case. I have seen too many cases of
"This is the greatest tool since ..." and when I try it, it fails on
very simple cases of mine.

Well the thread was about build tools.

And the argument were to use ant.

I don't think anyone has claimed a need to learn any tool under
the SUN.

Of course not. Everyone and his dog says to use his tool. The
collective of all that yammering is one should use every tool under
the sun.

Not at all.

As I have tried to explain several times now, then one should
utilize other developers experience. If a huge portion of the
Java developer community is using tool XYZ, then there must be
something good about that tool. If developer NN suggest tool ABC,
but nobody else are using that tool, then it is most likly
not worth spending time on.
To your first sentence: Yes, I understand that not knowing
certain things can have an effect on getting jobs, but to judge
someone totally or substantially on whether he knows one particular
tool goes way too far.

Unless the applicant can demonstrate good knowledge of all
other relevant tool, then not knowing one of the basic
tools like ant will cause the interviewer to assume that
there are many other holes in the applicants toolbox.

Arne
 
A

Arne Vajhøj

this is what they do (or, how they work), but the issue is not what they
do, but what purpose they are used for.

They are always used for the purpose of what they.

The only thing you know that include is for is to include a file.

The includes file can contain prototypes for functions in a library
or it can contain macros or it can contain executable code generated
by another tool or whatever else.
but is most often at the top (except maybe when writing headers or
similar, where near the bottom is also common).

Most often - yes.

But most often does not make it a characteristic of the feature.
yes, but ice-cream is not a keyword in either language.



except in most cases this will not accomplish nearly as much.

"using namespace std;"

by itself, will not give access say, to iostream, hence why people
generally still need to use #include.

You forgot that you can also use using for namespaces defined
in the same file.

Arne
 
D

Daniel Pitts

Most people say "Use ant" or "Use maven", many say "Use ant or maven".
Look at averages and statistics, not every response.
Not at all.

As I have tried to explain several times now, then one should
utilize other developers experience. If a huge portion of the
Java developer community is using tool XYZ, then there must be
something good about that tool. If developer NN suggest tool ABC,
but nobody else are using that tool, then it is most likly
not worth spending time on.

With the exception that ABC may be a new tool that hasn't found adoption
yet, but may in fact be better on average than XYZ. Still, your point
mostly stands.
 
A

Arne Vajhøj

Most people say "Use ant" or "Use maven", many say "Use ant or maven".
Look at averages and statistics, not every response.

With the exception that ABC may be a new tool that hasn't found adoption
yet, but may in fact be better on average than XYZ. Still, your point
mostly stands.

Occasionally new good stuff show up.

But rarely out of thin air (someone completely unknown
creates a project on SF and people just find it and start
using it).

More often it is created by somebody that already have a good
reputation and that reputation is sufficient to get somebody to
try it and then their positive feedback cause even more to try it.

Arne
 
G

Gene Wirchenko

[snip]
You keep putting twists in your responses. I did not say "only";
you have just added it.

Yes.

Because I assume that is what you meant.

How about checking instead of putting curves in?
But let us get it clarified. Do you mean:
A) developers should learn the common tools (ant and maven for Java build)

No.

It is likely that a developer will need such, but if he does not,
then passing on them is acceptable.

You can argue probabilities if you want. I will not bother. I
am thinking of the individual developer who might have no need at all
for the tools, or might well absolutely have to know them, but it is
the individual case that I am concerned with.
B) it is fine developers with developer only knowing less used tools
?

It could be. If that is all that a developer needs and will not
use the other tools, that is fine.

If it turns out that a developer needs to learn another tool --
whether ant, maven, or anything else -- then yes, he ought to. I just
do not see the point of learning a tool that one is not going to use.
Know about, yes; know, maybe. I have sometimes only used a tool once
and never needed it after that. Several versions later, what do I
really know about it? Not much anymore.
It is 30-50% each.

Fine. If no overlap, then 0% to 40% use something else.
Your 50-70 assumes perfect overlap.

That is certainly not the case.

I thought you were referring to the both of them since you only
gave one figure.
And the survey in question (Eclipse 2011) was asking about typical
build system, so the overlap must be very small.


What facts are not straight?

Percentages.

Sincerely,

Gene Wirchenko
 
G

Gene Wirchenko

[snip]
Of course not. Everyone and his dog says to use his tool. The
collective of all that yammering is one should use every tool under
the sun.

Not at all.

I have encountered many who each insist that the tools that each
uses is what I should be using. Typically, they do not bother to find
out my needs before prescribing. How good is such a suggestion? Not
very.
As I have tried to explain several times now, then one should
utilize other developers experience. If a huge portion of the
Java developer community is using tool XYZ, then there must be
something good about that tool. If developer NN suggest tool ABC,

Sometimes, it seems that the good is only a marketing department.
I have used some tools that are so awkward, I have wondered how they
ever got released.
but nobody else are using that tool, then it is most likly
not worth spending time on.

Or it is cutting edge.

I will consider tools. I will not drink the kool-aid.
Unless the applicant can demonstrate good knowledge of all
other relevant tool, then not knowing one of the basic
tools like ant will cause the interviewer to assume that
there are many other holes in the applicants toolbox.

Then, the interviewer is falling down on the job. He should be
asking.

Sincerely,

Gene Wirchenko
 
L

Lew

BGB said:
this is what they do (or, how they work), but the issue is not what they
do, but what purpose they are used for.

Clearly you are joking here.
but is most often at the top (except maybe when writing headers or
similar, where near the bottom is also common).

"Most often" is stylistic; the discussion here is how the constructs are dissimilar, and Java 'import' must be at the top, just as Arne said, and thatis a difference. Your so-called counterargument is irrelevant as it does not countervail the difference.
yes, but ice-cream is not a keyword in either language.

And "include" is not a keyword in Java. The comparison is both inaccurate and blazingly irrelevant. I know you are just jerking us around, but it's causing people to answer you seriously, BGB, so please stop.
 
B

BGB

Clearly you are joking here.


"Most often" is stylistic; the discussion here is how the constructs are dissimilar, and Java 'import' must be at the top, just as Arne said, and that is a difference. Your so-called counterargument is irrelevant as it does not countervail the difference.


And "include" is not a keyword in Java. The comparison is both inaccurate and blazingly irrelevant. I know you are just jerking us around, but it's causing people to answer you seriously, BGB, so please stop.

I was not joking here...

this was mostly a matter of "how pedantic or technically accurate a
statement should be".

in this case, a technically inaccurate statement was used to make a
point, but the technical inaccuracy would be "excusable" under the basis
that many people wouldn't really care that they are different in these
regards, seeing them as "similar".

so, the assertion is that strict technical accuracy is not always
necessary, or for that matter, beneficial.


do people make a big fuss over "the sun rises and the sun sets" when
in-fact it is the Earth that is moving?

in this case, the distinction is itself largely irrelevant.
 
L

Lew

I was not joking here...

Oh, my goodness. I am shocked.
this was mostly a matter of "how pedantic or technically accurate a
statement should be".

Your statements went far past pedantry deep into the territory of utter uselessness.

The similarity that you propose of both beginning with the letter "i", for example, is so stupid as to be insulting, unless meant as a joke. It's alsowrong, since the C directive begins with "#", not "i".

Try to stay with the program here. People are having a serious discussion.
in this case, a technically inaccurate statement was used to make a
point, but the technical inaccuracy would be "excusable" under the basis
that many people wouldn't really care that they are different in these
regards, seeing them as "similar".

It was not excusable, not even with quotation marks. C's '#include" and Java's "import" are far too dissimilar to allow anyone to muddle them. This isa computer programming forum, and accuracy in this area is not mere pedantry.

You say "technically inaccurate" as if that somehow is different from "wrong".
so, the assertion is that strict technical accuracy is not always
necessary, or for that matter, beneficial.

That has nothing to do with the topic of the similarities and differences between C's '#include' and Java's 'import'. Here, not being wrong is both necessary and beneficial.
do people make a big fuss over "the sun rises and the sun sets" when
in-fact it is the Earth that is moving?

WTF does that have to do with the price of tea in Beijing?
in this case, the distinction is itself largely irrelevant.

What distinction? Are you saying the distinction between C's '#include' andJava's 'import' is irrelevant to this discussion, because it's not.

Wrong ideas about programming are not beneficial to programmers, and "technically inaccurate" is wrong.
 
B

BGB

On 5/2/2012 12:21 PM, BGB wrote:
...

There are exceptions, and special cases, where the differences really
matter. I've written a C program that included the same file a dozen
times.

yes, granted.

I was not claiming here that they work similarly, or that they even
really do the same thing. so, it isn't too hard to observe that, yes,
import and #include are in-fact very different mechanisms.

but, sometimes, the actual mechanism doesn't really matter all that much.

However, they very frequently take the same place in the formalities for
using library software, the same place in the life of a programmer. Each
of them is the answer to "What do you usually add near the start of a
compilation unit when using external software?" for its language.

yep, this pretty much the main point of the argument.

both serve similar roles, and kind of look vaguely similar, even if what
they do is very different.
 
A

Arne Vajhøj

I was not joking here...

this was mostly a matter of "how pedantic or technically accurate a
statement should be".

in this case, a technically inaccurate statement was used to make a
point, but the technical inaccuracy would be "excusable" under the basis
that many people wouldn't really care that they are different in these
regards, seeing them as "similar".

so, the assertion is that strict technical accuracy is not always
necessary, or for that matter, beneficial.

do people make a big fuss over "the sun rises and the sun sets" when
in-fact it is the Earth that is moving?

If it is a group for physics/astronomy I would assume so.

Here nobody cares.

If you consider Java import and C include similar in
alt.chocolatecake.baking, then I don't think anyone
will object.

But we will here as this happens to be a programming
group where a certain level of technical accuracy in
relation to programming languages is expected.

Arne
 
A

Arne Vajhøj

[snip]
Who would hire somebody that only know about a very specific and highly
unusual environment?

You keep putting twists in your responses. I did not say "only";
you have just added it.

Yes.

Because I assume that is what you meant.

How about checking instead of putting curves in?

Fair enough.
No.

It is likely that a developer will need such, but if he does not,
then passing on them is acceptable.

You can argue probabilities if you want. I will not bother. I
am thinking of the individual developer who might have no need at all
for the tools, or might well absolutely have to know them, but it is
the individual case that I am concerned with.


It could be. If that is all that a developer needs and will not
use the other tools, that is fine.

If it turns out that a developer needs to learn another tool --
whether ant, maven, or anything else -- then yes, he ought to. I just
do not see the point of learning a tool that one is not going to use.
Know about, yes; know, maybe. I have sometimes only used a tool once
and never needed it after that. Several versions later, what do I
really know about it? Not much anymore.

So you really mean B.

And my assumption and argumentation was correct.
Fine. If no overlap, then 0% to 40% use something else.


I thought you were referring to the both of them since you only
gave one figure.

So you think I was recommending to learn N tools based
on their combined usage?

That was a weird assumption. Because it could be used to
mean any tool since ant+maven+X would be big for any X.
Percentages.

They are pretty straight.

The mentioned survey put them at 30.8% and 48.2% - I don't
see any problems calling them tools with 30-50% usage.

Arne
 
A

Arne Vajhøj

[snip]
I don't think anyone has claimed a need to learn any tool under
the SUN.

Of course not. Everyone and his dog says to use his tool. The
collective of all that yammering is one should use every tool under
the sun.

Not at all.

I have encountered many who each insist that the tools that each
uses is what I should be using. Typically, they do not bother to find
out my needs before prescribing. How good is such a suggestion? Not
very.

Suggesting tools that are used by millions of Java devlopers
is a pretty good suggestion.
Sometimes, it seems that the good is only a marketing department.
I have used some tools that are so awkward, I have wondered how they
ever got released.

Do you consider "Java developer community" and "marketing department"
to be similar concepts?

Otherwise I can not see the relevancy!
Then, the interviewer is falling down on the job. He should be
asking.

You mean go through all relevant tools?

That will be one very long interview!

Arne
 
M

Martin Gregorie

On 5/1/2012 10:21 PM, Gene Wirchenko wrote:

Do you consider "Java developer community" and "marketing department"
to be similar concepts?
There's a sort of connection, in that there are definitely two disjoint
sets of tools out there.

One set was written because the developer(s) needed them and as a result
polished and tweezed them until they did the target job efficiently and
were easy and elegant to use. Examples include Awk, the PostgreSQL SQL
client, the Embarcadero DBA tools and the XFCE window manager

The other set have rough edges and seem so awkward to use that you start
to wonder if their author's have even tried to use them for the tasks
they were meant to do. Examples of this group include RPG III, the IBM
mainframe DB2 client, the ERWIN DBA tools and the Gnome 3 window manager.
 
M

Martin Gregorie

On 5/1/2012 10:21 PM, Gene Wirchenko wrote:

Do you consider "Java developer community" and "marketing department"
to be similar concepts?
There's a sort of connection, in that there are definitely two disjoint
sets of tools out there.

One set was written because the developer(s) needed them and as a result
polished and tweezed them until they did the target job efficiently and
were easy and elegant to use. Examples include Awk, the PostgreSQL SQL
client, the Embarcadero DBA tools and the XFCE window manager

The other set have rough edges and seem so awkward to use that you start
to wonder if their author's have even tried to use them for the tasks
they were meant to do. Examples of this group include RPG III, the IBM
mainframe DB2 client, the ERWIN DBA tools and the Gnome 3 window manager.
 
M

Martin Gregorie

On 5/1/2012 10:21 PM, Gene Wirchenko wrote:

Do you consider "Java developer community" and "marketing department"
to be similar concepts?
There's a sort of connection, in that there are definitely two disjoint
sets of tools out there.

One set was written because the developer(s) needed them and as a result
polished and tweezed them until they did the target job efficiently and
were easy and elegant to use. Examples include Awk, the PostgreSQL SQL
client, the Embarcadero DBA tools and the XFCE window manager

The other set have rough edges and seem so awkward to use that you start
to wonder if their author's have even tried to use them for the tasks
they were meant to do. Examples of this group include RPG III, the IBM
mainframe DB2 client, the ERWIN DBA tools and the Gnome 3 window manager.
 
M

Martin Gregorie

On 5/1/2012 10:21 PM, Gene Wirchenko wrote:

Do you consider "Java developer community" and "marketing department"
to be similar concepts?
There's a sort of connection, in that there are definitely two disjoint
sets of tools out there.

One set was written because the developer(s) needed them and as a result
polished and tweezed them until they did the target job efficiently and
were easy and elegant to use. Examples include Awk, the PostgreSQL SQL
client, the Embarcadero DBA tools and the XFCE window manager

The other set have rough edges and seem so awkward to use that you start
to wonder if their author's have even tried to use them for the tasks
they were meant to do. Examples of this group include RPG III, the IBM
mainframe DB2 client, the ERWIN DBA tools and the Gnome 3 window manager.
 
A

Arne Vajhøj

There's a sort of connection, in that there are definitely two disjoint
sets of tools out there.

One set was written because the developer(s) needed them and as a result
polished and tweezed them until they did the target job efficiently and
were easy and elegant to use. Examples include Awk, the PostgreSQL SQL
client, the Embarcadero DBA tools and the XFCE window manager

The other set have rough edges and seem so awkward to use that you start
to wonder if their author's have even tried to use them for the tasks
they were meant to do. Examples of this group include RPG III, the IBM
mainframe DB2 client, the ERWIN DBA tools and the Gnome 3 window manager.

That is somewhat true.

"designed by committee" is not always a success.

But I do still not quite understand why Gene bring op marketing when
I suggest he use tools recommended by the developer community.

Arne
 

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