Do you suggest me using IDE when I'm learning JAVA

[BGB / cr88192]

Most people who deal with this regularly have command line, and hence
scriptable, tools to deal with it, e.g. unix2dos and dos2unix in the UNIX
world or you can always use tr, which has been ported to about as many
OSen as grep has.

yes, this is one option for file conversion...

just, I guess the mystery is why they never bothered with it in Notepad,
given:
they did deal with it in both WordPad and MS Edit;
it is unlikely to be a major issue to add;
they did go and add Unicode and UTF-8 support, which is presumably a much
bigger issue to implement;
....

but, granted, it doesn't really matter that much...

 

[BGB / cr88192]

Yup.

Since I've never seen "OSX" used to refer to OS9 and its ancestors I took
the above to mean that early OS X versions used CR before changing to LF
in midstream.

nope, I see OSX as part of the same continuity (MacOS), and thus coming
after OS9.

given OS9 used CR and OSX used LF, by this reasoning OSX switched to LF.


it would be the same as if, by some chance, MS abandoned PE/COFF for, say,
"Windows 8" (say, in favor of... ELF), one would say "Windows 8" switched to
ELF. (admitted this is an unlikely example...).

 

[BGB / cr88192]

I think that is more about eating ones own dog food paradigm.

The technical problems of doing IDE for language A in language B
are solvable.

the technical differences between languages should be relatively trivial WRT
writing an IDE.
pretty much any sufficiently capable language should be able to write an IDE
for pretty much any other sufficiently capable language.

for example, for a Java IDE, one doesn't actually need access to the Java
runtime or reflection mechanisms, but could instead only have access to the
classes and class-libraries (as data), or even only info about the classes
and libraries, and still get by fairly well.

Some languages may not even be that suited for writing IDE's. I am
not sure that writing a Fortran IDE in Fortran would be optimal.

depends on the variety of Fortran, but admittedly I would not likely do
this...


if I were to pick a language for the task of writing an IDE, personally I
would likely pick either a mix of C and C++ (my typical major-use
languages).

the big downside of C and C++ is that there is no really good and portable
ways to do GUIs, leading to issues here no matter which route is chosen.
typically I have done GUIs via OpenGL, but admitted there are a few
drawbacks here as well...


maybe C#, the big downside here being portability, the main upsides here
being easy access to C land (via C++/CLR, ...) and ability to use Windows
Forms...

I might consider Java, but I am not certain that the language design is that
optimal for this sort of tool (and integration between C and Java code is
typically not, exactly, pleasant...). not that it is difficult to integrate
them, mostly it is just unpleasant.

admitted, the integration issue is not likely to be as bad for a pure-Java
project, so this remains an open possibility as well...

 

[Arved Sandstrom]

On 03-05-2010 07:08, Arved Sandstrom wrote:

[ SNIP ]

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.

Arne

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?

AHS

 

[Jim Janney]

the technical differences between languages should be relatively trivial WRT
writing an IDE.
pretty much any sufficiently capable language should be able to write an IDE
for pretty much any other sufficiently capable language.

for example, for a Java IDE, one doesn't actually need access to the Java
runtime or reflection mechanisms, but could instead only have access to the
classes and class-libraries (as data), or even only info about the classes
and libraries, and still get by fairly well.

This is where the bit about "for reasonably dynamic languages" comes
into play. A Lisp program can easily modify itself at runtime, using
the mechanisms of the language in a very natural way; this makes it an
obvious choice for writing a Lisp IDE. I'm not sure, now that I think
about it, whether Java fits into this category or not. You can load
new classes at runtime; you can even assemble byte code in memory and
then load it as a class, but it's not what I'd consider a natural part
of the language. And languages like C and Fortran don't even have a
foot in the door.

 

[cr88192]

This is where the bit about "for reasonably dynamic languages" comes
into play. A Lisp program can easily modify itself at runtime, using
the mechanisms of the language in a very natural way; this makes it an
obvious choice for writing a Lisp IDE. I'm not sure, now that I think
about it, whether Java fits into this category or not. You can load
new classes at runtime; you can even assemble byte code in memory and
then load it as a class, but it's not what I'd consider a natural part
of the language. And languages like C and Fortran don't even have a
foot in the door.

yeah.

this would more matter for a debugger though I think, whereas for an IDE (in
general) one can work based on the static/lexical visibility of types and
declarations.

any self-modification then can be assumed to be a non-issue (as in, outside
the effective scope of an IDE, but within the scope of a debugger...).


now for something like Lisp (or Scheme, JavaScript, ...) this would be a
much bigger issue, since the exact visibility and types can't be reliably
statically determined (type-inference is possible, but is of less utility
given that the code is not required to have statically-known types).


now, as for self-modification and self-extension:
it IS possible in C (I have done this).

however, if one were to ask if it were clean or simple, I would have to
fairly solidly answer: NO.
technically, it can't actually be done within the confines of the C
standard, but actually requires side-stepping the language and compiler, and
going fairly solidly into the lands of the low-level instruction set, ASM,
ABI's, and code-generation / compiler writing, ...

the key to making it all workable though is function pointers:
without function pointers, very possibly it would not actually be possible.

in Java, classes and interfaces can serve a similar role (as noted, in
combination with the class-loader).


with other hackery, one can add dynamic typing to both languages, although
Java is much closer to providing native dynamic typing, but poses the
problem that it would likely be a lot more difficult to do so as efficiently
(the JVM isn't really designed to allow the needed facilities).

however, some people at Sun have been working to address some of these
issues in the JVM.
at least going by the ECMA standard, the .NET CLR would likely have some
similar issues WRT efficient dynamic typing, although these could be
addressed by either:
using unsafe code to implement the type facilities;
possibly implementation-specific extensions.

C has it a little easier as the language is "unsafe" by default, and so the
main issue is more just doing everything in a way which is agreeable with
the underlying system...

or such...

 

[Tom Anderson]

On 05/03/2010 08:46 AM,

I find what i [sic] assume to be Arne's point shocking. The ideal software
process would spend *100%* of its time writing code, because it would

That's ridiculous.
Nope.

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.

So you completely discount planning,

Yep. It's a good idea, but the less time you can spend doing it, the
better.

designing,

Part of programming, done in the IDE.

testing,

Part of programming, done in the IDE.

filling out time cards,
Yep.

taking a whiz, coffee, conversations with team mates and management,

Essential, but not part of the denominator of that 100%.

meetings,

SUPER YEP.

training,

I've yet to come across any training worth anything that wasn't done by
sitting at a machine and actually doing something.

and all the other ancillary activities that make up a work day. All of
which contribute to the output.
Nope.

What utter irredeemable nonsense.
Nope.

You think like the worst kind of software-development manager.

Nope. I think you'll find that the worst managers are the ones who want
everyone to spend *less* time programming, because they want them to spend
*more* time in meetings, preparing documents, etc.

Our goal is to build things out of software. Time we spend not building
things out of software is, from a professional point of view, wasted. We
should minimise waste.

tom

 

[Tom Anderson]

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.

tom

 

[Tom Anderson]

This is where the bit about "for reasonably dynamic languages" comes
into play. A Lisp program can easily modify itself at runtime, using
the mechanisms of the language in a very natural way; this makes it an
obvious choice for writing a Lisp IDE.

The word you're looking for is 'homoiconic' - meaning that running
programs are represented by the same means as the data manipulated by
those programs.

I'm not sure, now that I think about it, whether Java fits into this
category or not.

It doesn't.

You can load new classes at runtime; you can even assemble byte code in
memory and then load it as a class, but it's not what I'd consider a
natural part of the language. And languages like C and Fortran don't
even have a foot in the door.

C doesn't? You never heard of void*?

tom

 

[Arne Vajhøj]

depends on the variety of Fortran, but admittedly I would not likely do
this...

The last real Fortran was 77.

if I were to pick a language for the task of writing an IDE, personally I
would likely pick either a mix of C and C++ (my typical major-use
languages).

Java or C# seems more obvious to me.

the big downside of C and C++ is that there is no really good and portable
ways to do GUIs, leading to issues here no matter which route is chosen.
typically I have done GUIs via OpenGL, but admitted there are a few
drawbacks here as well...

An IDE does not need the OpenGL capabilities.

maybe C#, the big downside here being portability, the main upsides here
being easy access to C land (via C++/CLR, ...) and ability to use Windows
Forms...

C# with Mono for *nix and GTK# instead of WinForms could work fine.

And you do not even need to use mixed mode C++ to access
C code - p/invoke will do fine for that.

I might consider Java, but I am not certain that the language design is that
optimal for this sort of tool (and integration between C and Java code is
typically not, exactly, pleasant...). not that it is difficult to integrate
them, mostly it is just unpleasant.

Java should do fine for IDE. There are lot sof IDE's written in Java.

JNI is a bit cumbersome, but I don't think an IDE need JNI at all.

Arne

 

[BGB / cr88192]

The last real Fortran was 77.

yeah.

some newer Fortran varieties add OO, function pointers, and a lot of the
stuff from C and C++...

Java or C# seems more obvious to me.

well, in my case, a lot has to do with familiarity...

C# raises the issue of differences between MS's implementation and Mono, and
the lack of good alternatives...

Java leaves one in a world of primarily Java-only...

An IDE does not need the OpenGL capabilities.

true, but in my case, OpenGL is the most convinient way (in C and C++) to
pull off portable GUI code (the main other alternative being to maintain
local bitmaps and draw into these...). but, I like OpenGL because it can do
nearly anything I need (from simple GUI's and consoles to more elaborate 3D
scenes), without having to really modify or port much code (usually just a
few kloc is needed to manage OS-specific matters).

also, my main widget toolkit is based on OpenGL.


interfacing with platform GUI facilities tends to be much more painful to
make work well (since damn near every OS has its own local GUI API, and
often it is not particularly a 1:1 mapping between them).

however, in the past I had done some basic GUI's using some design ideas
from HTML forms as a means of abstraction.

granted, portable GUI is much easier in Java, since Java includes AWT and
Swing, which work regardless of the target OS.

C# with Mono for *nix and GTK# instead of WinForms could work fine.

but, the issue with GTK# is that AFAIK it is not available for MS's .NET
implementation...

providing redundant GUI between WinForms and GTK#, or demanding use of Mono
on Windows, would also be lame...

possibly it would leave one needing to find some way to gloss over the
differences.

And you do not even need to use mixed mode C++ to access
C code - p/invoke will do fine for that.

granted.
however, there is some merrit in being able to write mixed-mode code, since
it can serve as an essentially bidirectional interface with both languages,
and thus avoid much of the "harsh edge" effect from using P/Invoke.

granted, I have not used it much in any large scale, but I would imagine it
to be a nicer experience...

and as well before I essentially used it to more-or-less coerce a bunch of
plain C code to run on .NET...

Java should do fine for IDE. There are lot sof IDE's written in Java.

JNI is a bit cumbersome, but I don't think an IDE need JNI at all.

but, this is only if one is willing to write the whole thing in Java, which
granted, seems like a little bit of a strain for someone far more used to
(the relative anarchy of) C and C++...

similar, there is also the uncertainty of one having to quite possibly
abandon much of their legacy codebase, essentially "starting over" as far as
programming goes...

 

[BGB / cr88192]

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.

one could instead use their time doing stuff, and the future will happen
when it happens (well, except when some dismal concern is staring one in the
face, at which point, then they are free to think about the future, and try
to find some way to work around this dismal turn of events...).

"oh crap, all my money is gone..." => "come up with some way to summon up
the needed funds..."
=> "yay... all is good now... back to whatever I was doing...".

but, then again, I guess things don't typically turn out this way, since
usually I guess I end up spending far too much time sitting around and
thinking about stuff, and procrastinating (so, more often it is like "oh
crap, I have this big pile of crap I need to get done in the next few
hours...").

and maybe some of "grr... I am supposed to do some random paperwork... I
have no idea how to fill this crap out...".

and being intellectual and so on, or more like, I am left thinking I am
being intellectual, being like "oh wow, this random theoretical crap is
working really well in making my stuff work"... followed by classes and a
whole lot of "ok, how the hell is all this supposed to be useful in any sane
reality?...".

but, it is sometimes surprising how all these little pieces of random stuff
can turn out being useful to the greater good: making stuff work... even as
such, classes still suck and are a terribly boring and unpleasant
experience, one being doomed to failure either because the subject doesn't
make sense or someone has procrastinated away all the assignments or some
combination thereof...


so, yeah, not everything is perfect sometimes...

 

[Mike Schilling]

The last real Fortran was 77.

Fortran 4, you mean. Non-arithmetic IF statements are for sissies, and God
intended character processing to be done by stuffing bytes into parallel
arrays of INTEGERs.

 

[Arved Sandstrom]

Fortran 4, you mean. Non-arithmetic IF statements are for sissies, and God
intended character processing to be done by stuffing bytes into parallel
arrays of INTEGERs.

All humour aside, the significant FORTRAN for many of us must have been
either FORTRAN 66 or FORTRAN 77. My start to programming was actually
FORTRAN 66...now that I look carefully at what FORTRAN 77 added, it
appears that I was also able to get away with not having a CHARACTER
data type.

As near as I can tell FORTRAN IV did have a logical IF.

AHS

 

[Lars Enderin]

All humour aside, the significant FORTRAN for many of us must have been
either FORTRAN 66 or FORTRAN 77. My start to programming was actually
FORTRAN 66...now that I look carefully at what FORTRAN 77 added, it
appears that I was also able to get away with not having a CHARACTER
data type.

As near as I can tell FORTRAN IV did have a logical IF.

It had. It was one of its improvements over FORTRAN II. There was no
FORTRAN III, at least not widely available.
I started real programming with Algol 60 in 1962, just one project, then
began programming in FORTRAN II in 1963. FORTRAN IV was a great
improvement, but it was the last FORTRAN I used.

 

[Jim Janney]

Lisp sort of does, but doesn't, so your point doesn't really hold. I
don't think there is an editor written in lisp (is there?). Stallman
had to create Elisp (Emacs Lisp) which supports GUI features to allow an
editor to take advantage of a lisp virtual machine's power, which is
what Emacs does. Allowing you to modify its behaviour by interacting
with the Elisp VM.

There are lots and lots and lots of editors written in Lisp. It's a
very common pattern, and most serious Lisp implementations, for
example LispWorks, include a complete programming environment written
in Lisp. Stallman wrote GNU Emacs not for technical reasons but for
legal ones: he wanted something he could place under the GPL. And the
larger part of GNU Emacs is written in Emacs Lisp.

Truly, your main point just isn't really valid. I certainly wouldn't
want to try and write an IDE for shell code using a shell language.

I'm not claiming that every language should have an IDE written in
that language. I'm speculating that there exists a class of languages
for which this holds, and trying to identify the properties of that
class.

Java's big boon is the idea of a virtual machine combined with
reflection. I believe that reflection came about for the exact reason of
adoption of the language. The IDE's available allow a huge level of
adoption for java, and I'm pretty sure this wasn't just a coincidence.
The reflection calls allowed tons of IDEs to come to life. I would bet
java wouldn't have close to the level of adoption without the IDEs being
available.

I agree with all of this.

 

[Jim Janney]

The word you're looking for is 'homoiconic' - meaning that running
programs are represented by the same means as the data manipulated by
those programs.

Um, OK.

It doesn't.


C doesn't? You never heard of void*?

That's more like a finger in the door...

 

[Mike Schilling]

All humour aside, the significant FORTRAN for many of us must have
been either FORTRAN 66 or FORTRAN 77. My start to programming was
actually FORTRAN 66...now that I look carefully at what FORTRAN 77
added, it appears that I was also able to get away with not having a
CHARACTER data type.

As near as I can tell FORTRAN IV did have a logical IF.

Full FORTRAN IV did, but there was a subset of it called "Standard Basic
FORTRAN", which is I used both in college and at my first job (IBM 1130 and
1800 respectively), that did not. The 1130/1800 dialect also had a strict
ordering of declaration statements:

Type (INTEGER, REAL)
EXTERNAL
DIMENSION
COMMON
EQUIVALENCE
DATA

which I still remember with the aid of of the menmonic "places getting
further away from California" (TEXas, Washington DC, EcuaDor.)

 

[BGB / cr88192]

Um, OK.


That's more like a finger in the door...

be careful not to underestimate the sheer hackery power made available by
these seemingly trivial pointers...

plain pointers allow the likes of custom memory management, garbage
collection, and the implementation of dynamic typing.

function pointers make possible the creation of self-modifying programs
(among other things), as well as custom code-loading, JIT compilers, and
adding "eval" and other features to C, ...


this is part of what makes C hard to learn, but also what makes it difficult
for C and C++ programmers to commit to using only Java...

sadly though, C / C++ and Java are like water and oil...

 

[Stefan Ram]

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

But then, we also think by deleting, which might result in a
negative LOC number, while still indicating an advancement
toward project goals.

See also:

http://www.developerdotstar.com/mag/articles/reeves_design_main.html