From: Arne Vajhøj on
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
From: Arne Vajhøj on
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.

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.

So no - it is not fiction that software engineers think more
than type.

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).

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.

Arne
From: Mike Schilling on
Arne Vajh�j wrote:
> On 05-05-2010 17:53, Jim Janney wrote:
>> "BGB / cr88192"<cr88192(a)hotmail.com> writes:
>>> sadly though, C / C++ and Java are like water and oil...
>>
>> JNI isn't exactly pretty, is it?
>
> It is not easy.
>
> Some consider that an advantage, because it is part of why it is not
> used much!

JNI has to be complex, because it has to expose many of the complicated
features of the JVM (reference counting, exceptions, etc.) without
compromising the safety features of the JVM. Imagine if you could generate
a .h file that represents a class layout and write JNI that is passed object
pointers, allowing you to access the object directly and at the same time
scribble all over memory in the best uncontrolled C fashion. JNI would be a
joy to write, but a nightmare to debug.


From: Mike Schilling on
Arne Vajh�j wrote:
> On 05-05-2010 02:58, Mike Schilling wrote:
>> Arne Vajh�j wrote:
>>> On 04-05-2010 00:57, BGB / cr88192 wrote:
>>>> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message
>>>>> 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...
>>>
>>> The last real Fortran was 77.
>>
>> Fortran 4, you mean.
>
> Nope. I am too young.

Damned whippersnappers. Get off my lawn!


From: Mike Schilling on
Arne Vajh�j wrote:
> On 05-05-2010 05:34, Arved Sandstrom wrote:
>> Mike Schilling wrote:
>>> Arne Vajh�j wrote:
>>>> On 04-05-2010 00:57, BGB / cr88192 wrote:
>>>>> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message
>>>>>> 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...
>>>> 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.
>>
>> 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.
>
> Yes. But no END IF.

no THEN or ELSE either, just the single-line

IF (logical-expr) statement

F77 added

IF (logical-expr) THEN
...
ELSE IF (logical-expr) THEN
...
ELSE
...
END IF