Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #31465 > unrolled thread

Re: Return of the Applets?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 09:46 -0400
    Re: Return of the Applets? Jeff Higgins <jeff@invalid.invalid> - 2015-04-05 13:12 -0400
    Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 15:14 -0400
      Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 16:41 -0400
        Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 16:54 -0400
          Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 17:08 -0400
            Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 17:17 -0400
              Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 17:30 -0400
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 17:42 -0400
                  Re: Return of the Applets? Arne Vajhøj <arne@vajhoej.dk> - 2015-04-05 17:52 -0400
                    Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-05 18:17 -0400
                      Re: Return of the Applets? Luuk <luuk@invalid.lan> - 2015-04-06 11:26 +0200
      Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 13:23 -0500
        Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 15:09 -0400
          Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 17:33 -0500
            Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 17:44 -0400
              Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 19:10 -0500
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 20:03 -0400
                  Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 21:36 -0500
                    Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 09:11 -0400
              Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-06 23:25 +0000
                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-06 19:59 -0400
                  Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 13:29 +0000
                    Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 10:45 -0400
                      Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 15:51 +0000
                        Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 13:16 -0400
                          Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 20:22 +0000
                            Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 17:03 -0400
                      Re: Return of the Applets? Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2015-04-07 11:34 -0500
                        Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 13:18 -0400
                          Re: Return of the Applets? Leif Roar Moldskred <leifm@huldreskog.localdomain> - 2015-04-07 12:40 -0500
                            Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 17:06 -0400
                          Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 20:28 +0000
                            Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 17:11 -0400
                              Re: Return of the Applets? Martin Gregorie <martin@address-in-sig.invalid> - 2015-04-07 23:00 +0000
                                Re: Return of the Applets? Jerry Stuckle <jstucklex@attglobal.net> - 2015-04-07 19:25 -0400
    Re: Return of the Applets? Joshua Cranmer 🐧 <Pidgeot18@verizon.invalid> - 2015-04-06 13:09 -0500

Page 2 of 2 — ← Prev page 1 [2]

#31503

On Mon, 06 Apr 2015 17:44:48 -0400, Jerry Stuckle wrote:

> LOC has been used as a measurement standard for the 47+ years I've been
> programming.  You may not think it's a good measurement, but the experts
> in the field pretty much all agree on it.
>
LOC counting is a useful measurement within a project or within a single-
language shop, but I don't think its at all useful for making 
measurements between languages except in limited cases.

Its probably meaningful for comparing programming productivity between 
block-structured languages because by and large they tend to have similar 
sized statements and the statements have similar capabilities. But, once 
you start comparing radically different languages, it no longer makes 
sense to use LOC counting: the better 4GLs (Sculptor, NCC Filetab, 
Cognos, PowerBuilder, Xbase) can do a huge amount with very little code 
and so can be written very quickly while a COBOL program of less than 
1000 lines would be little more than a warm-up exercise in most of the 
shops I've worked in. Every other language, except maybe assemblers, fit 
somewhere in between these extremes.

Another problem with LOC measurements is that they usually ignore 
comments. Now, that may be OK in COBOL programs provided the local 
standards require meaningful data names and procedure division section 
and paragraph names because its hard to write anything that anywhere near 
as incomprehensible as a C-spell even if you use ALTER statements, but 
other languages (assembler, C, RPG) can easily become impenetrable 
without comments, and some are hard to follow almost by design (APL, 
Forth). I remmeber reading that Ken Iverson once wrote a screen editor in 
26 lines of APL but was unable to amend it himself six months later: no 
comments of course, or it wouldn't have come anywhere close to fitting on 
a screen. 

Bottom line: a good programmer uses clear, well thought out comments 
throughout his code and sensible programming groups require it as part of 
their work packages because they know it will make changes easier. But 
nonetheless comments are ignored by almost all LOC statistics gathering 
tools. IMO this devalues the use of LOC counting for anything except 
estimating new projects and even there its results tend not to be valid 
outside a particular organisation and programming environment.

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#31505

On 4/6/2015 7:25 PM, Martin Gregorie wrote:
> On Mon, 06 Apr 2015 17:44:48 -0400, Jerry Stuckle wrote:
> 
>> LOC has been used as a measurement standard for the 47+ years I've been
>> programming.  You may not think it's a good measurement, but the experts
>> in the field pretty much all agree on it.
>>
> LOC counting is a useful measurement within a project or within a single-
> language shop, but I don't think its at all useful for making 
> measurements between languages except in limited cases.
>

Maybe - but it is still the metric used historically.

> Its probably meaningful for comparing programming productivity between 
> block-structured languages because by and large they tend to have similar 
> sized statements and the statements have similar capabilities. But, once 
> you start comparing radically different languages, it no longer makes 
> sense to use LOC counting: the better 4GLs (Sculptor, NCC Filetab, 
> Cognos, PowerBuilder, Xbase) can do a huge amount with very little code 
> and so can be written very quickly while a COBOL program of less than 
> 1000 lines would be little more than a warm-up exercise in most of the 
> shops I've worked in. Every other language, except maybe assemblers, fit 
> somewhere in between these extremes.
> 

To a certain extent, yes.  But OTOH, a lot of the advantages and
disadvantages of individual languages tend to balance out.

> Another problem with LOC measurements is that they usually ignore 
> comments. Now, that may be OK in COBOL programs provided the local 
> standards require meaningful data names and procedure division section 
> and paragraph names because its hard to write anything that anywhere near 
> as incomprehensible as a C-spell even if you use ALTER statements, but 
> other languages (assembler, C, RPG) can easily become impenetrable 
> without comments, and some are hard to follow almost by design (APL, 
> Forth). I remmeber reading that Ken Iverson once wrote a screen editor in 
> 26 lines of APL but was unable to amend it himself six months later: no 
> comments of course, or it wouldn't have come anywhere close to fitting on 
> a screen. 
> 

Which has nothing to do with LOC measurements.  And while APL has some
advantages in some statements (i.e. mathematical constructs), it has
disadvantages in others (i.e. file operations).

> Bottom line: a good programmer uses clear, well thought out comments 
> throughout his code and sensible programming groups require it as part of 
> their work packages because they know it will make changes easier. But 
> nonetheless comments are ignored by almost all LOC statistics gathering 
> tools. IMO this devalues the use of LOC counting for anything except 
> estimating new projects and even there its results tend not to be valid 
> outside a particular organisation and programming environment.
> 

Which is true for all languages and has nothing to do with which
language is more popular.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31518

On Mon, 06 Apr 2015 19:59:18 -0400, Jerry Stuckle wrote:

> To a certain extent, yes.  But OTOH, a lot of the advantages and
> disadvantages of individual languages tend to balance out.
>
Only if you're comparing similar languages. 

Using a good 4GL I can easily write an accounting type program that 
maintains a detail record file that contains references to three or four 
other files, fully validating all inputs and doing it on a neatly laid 
out screen. That interactive program, together with reporting program to 
show whats in the detail records in a meaningful, neat layout can easily 
be written and tested in a normal working day. The interactive program 
will typically be under 200 lines and the report program will be under 60 
lines, so a total of 260 LOC.

I don't know of any HLL or assembler that can come anywhere near that, 
either in terms of LOC counts or development time. 

IOW using LOC to compare a 4GL with, say, COBOL or Java just doesn't 
work. 

The fact that I can develop and test a program in a day using a 4GL that 
would take a week in Java and longer in COBOL says nothing about the 
skill or productivity of programmers doing similar tasks and doesn't help 
a lot with project estimation either if, as often happens, the project 
sponsor gets to pick the programming language.

Its much better to use something more abstract, such as function point 
analysis simply because the number of function points in a program or 
system depends on the requirements and not on the programming language.  

This way you use function points to estimate specification, design and 
testing effort, all of which are independent of the programming language 
and then apply a language multiplier to the function point total, which 
gives the required programming effort.

> Which has nothing to do with LOC measurements.
>
Agreed, but documentation effort should be factored in if the system 
being developed isn't just a throw-away being built round a one-off event.
LOC counting can't do that.

Function point counting would do better here if you add a documentation 
effort factor for each function point. This would be as equally valid for 
traditional module document writing as it is for a combined approach, 
e.g. via javadocs for Java or cdocs/oxygen for C.

> And while APL has some
> advantages in some statements (i.e. mathematical constructs), it has
> disadvantages in others (i.e. file operations).
>
That applies to pretty much all all languages: try accessing serial ports 
from pretty much anything except C or assembler, TCP/IP networks from 
Fortran or COBOL or anything except the terminal, printer and target DBMS 
from a traditional 4GL.
  
>> Bottom line: a good programmer uses clear, well thought out comments
>> throughout his code and sensible programming groups require it as part
>> of their work packages because they know it will make changes easier.
>> But nonetheless comments are ignored by almost all LOC statistics
>> gathering tools. IMO this devalues the use of LOC counting for anything
>> except estimating new projects and even there its results tend not to
>> be valid outside a particular organisation and programming environment.
>> 
>> 
> Which is true for all languages and has nothing to do with which
> language is more popular.
>
True, but it has a lot to do with using LOC stats for estimating projects 
because documentation effort is invisible to LOC counting and testing 
effort isn't much better served either.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#31519

On 4/7/2015 9:29 AM, Martin Gregorie wrote:
> On Mon, 06 Apr 2015 19:59:18 -0400, Jerry Stuckle wrote:
> 
>> To a certain extent, yes.  But OTOH, a lot of the advantages and
>> disadvantages of individual languages tend to balance out.
>>
> Only if you're comparing similar languages. 
> 
> Using a good 4GL I can easily write an accounting type program that 
> maintains a detail record file that contains references to three or four 
> other files, fully validating all inputs and doing it on a neatly laid 
> out screen. That interactive program, together with reporting program to 
> show whats in the detail records in a meaningful, neat layout can easily 
> be written and tested in a normal working day. The interactive program 
> will typically be under 200 lines and the report program will be under 60 
> lines, so a total of 260 LOC.
> 
> I don't know of any HLL or assembler that can come anywhere near that, 
> either in terms of LOC counts or development time. 
> 
> IOW using LOC to compare a 4GL with, say, COBOL or Java just doesn't 
> work. 
>

Then what do you suggest as a better measurement?  Experts have tried to
come up with one for over 50 years, and haven't.

> The fact that I can develop and test a program in a day using a 4GL that 
> would take a week in Java and longer in COBOL says nothing about the 
> skill or productivity of programmers doing similar tasks and doesn't help 
> a lot with project estimation either if, as often happens, the project 
> sponsor gets to pick the programming language.
> 
> Its much better to use something more abstract, such as function point 
> analysis simply because the number of function points in a program or 
> system depends on the requirements and not on the programming language.  
> 
> This way you use function points to estimate specification, design and 
> testing effort, all of which are independent of the programming language 
> and then apply a language multiplier to the function point total, which 
> gives the required programming effort.
> 

To do that, you need to define "Function Point Analysis" and how it
applies to each language.  And you need to define how much work is
required for each function point.

And then you will find different languages have different workloads for
each function point.  This then takes you back to LOC to determine workload.

>> Which has nothing to do with LOC measurements.
>>
> Agreed, but documentation effort should be factored in if the system 
> being developed isn't just a throw-away being built round a one-off event.
> LOC counting can't do that.
> 

It really makes no difference whether the system is being built for a
one-off event or not.  The system is being built.

> Function point counting would do better here if you add a documentation 
> effort factor for each function point. This would be as equally valid for 
> traditional module document writing as it is for a combined approach, 
> e.g. via javadocs for Java or cdocs/oxygen for C.
> 

Pretty difficult since not all languages support javadoc or similar.

>> And while APL has some
>> advantages in some statements (i.e. mathematical constructs), it has
>> disadvantages in others (i.e. file operations).
>>
> That applies to pretty much all all languages: try accessing serial ports 
> from pretty much anything except C or assembler, TCP/IP networks from 
> Fortran or COBOL or anything except the terminal, printer and target DBMS 
> from a traditional 4GL.
>   

Which only proves my point.

And BTW - you can access serial ports from many different languages, and
TCP/IP from Fortran or COBOL.  You just need the right libraries.

>>> Bottom line: a good programmer uses clear, well thought out comments
>>> throughout his code and sensible programming groups require it as part
>>> of their work packages because they know it will make changes easier.
>>> But nonetheless comments are ignored by almost all LOC statistics
>>> gathering tools. IMO this devalues the use of LOC counting for anything
>>> except estimating new projects and even there its results tend not to
>>> be valid outside a particular organisation and programming environment.
>>>
>>>
>> Which is true for all languages and has nothing to do with which
>> language is more popular.
>>
> True, but it has a lot to do with using LOC stats for estimating projects 
> because documentation effort is invisible to LOC counting and testing 
> effort isn't much better served either.
> 
> 

Actually, documentation is a part of development, and can be related to
LOC, even though it is not part of the measurement.  I've been doing it
for the last 25 years I've been managing projects.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31520

On Tue, 07 Apr 2015 10:45:54 -0400, Jerry Stuckle wrote:

> On 4/7/2015 9:29 AM, Martin Gregorie wrote:
> Then what do you suggest as a better measurement?  Experts have tried to
> come up with one for over 50 years, and haven't.
>
That depends on what you're measuring.

LOC is OK for measuring programmer productivity and for comparing sizes 
of programs provided that they belong to related groups, e.g. block 
structured languages. 

> To do that, you need to define "Function Point Analysis" and how it
> applies to each language.  And you need to define how much work is
> required for each function point.
>
Sure, but function points are NOT language-specific: think of them as 
atomic system functions that can be deduced from a requirements spec when 
combined with the sort of high level ERD and numbers of display forms and 
reports you'd use when costing a new project. At that point you can 
estimate the number of function points (read a row, paint a screen, 
validate input....) needed to implement each display form, etc. 
 
> And then you will find different languages have different workloads for
> each function point.  This then takes you back to LOC to determine
> workload.
> 
Multiplying the function points by language-specific weightings gives a 
programming cost estimate, but you don't do that until the requirement 
set is specific and the programming language(s) has/have been selected.

> It really makes no difference whether the system is being built for a
> one-off event or not.  The system is being built.
>
Yes it does: if you're writing something to test the practicality and/or 
the performance of a design approach or if you know that program is 
needed for a one-off purpose then you little or no documentation apart 
from the requirement spec. OTOH if the system is expected to be in use 
and maintained for a decade, of its something that is highly configurable 
(such as a commercial banking package) then it needs to be documented 
well enough to make maintenance, modification and configuration changes 
relatively simple and so that supporting it is easy to pick up. I still 
have mental scars from installing/supporting/maintaining systems which 
lacked decent documentation.

>> Function point counting would do better here if you add a documentation
>> effort factor for each function point. This would be as equally valid
>> for traditional module document writing as it is for a combined
>> approach, e.g. via javadocs for Java or cdocs/oxygen for C.
>> 
>> 
> Pretty difficult since not all languages support javadoc or similar.
>
You use the tools for languages that support them and reap the benefits 
of having the module-level documentation in the source and hence more 
likely to be maintained as the code changes.

Otherwise you have use traditional word processors etc to maintain 
separate module level documentation and accept the almost inevitable 
problems that arise if, as usually happens, the documentation isn't 
updated.

I suspect there are are more third party javadoc-like tools for other 
languages than you may have run across, e.g. there are at least two such 
tools for C that, like javadocs, extract documentation from the source 
files and I've seen systems where the source version control system 
stored the requirements, HLL system design, database schema, forms 
designs and COBOL source and could (a) generate systems documentation and 
(b) feed source to the schema generator, compilers, etc.

> And BTW - you can access serial ports from many different languages, and
> TCP/IP from Fortran or COBOL.  You just need the right libraries.
>
Some of these languages, e.g. Fortran and COBOL, don't have these 
features in their standard libraries (where they even have a standard 
library). Sure, if they can call external functions you can write 
extensions, in assembler if necessary, but that isn't part of the 
language and so shouldn't appear in the language metrics: 

- if you bought a 3rd party library, you shouldn't count much more 
  than the function calls (one statement per call) in the language
  statistics

- if you wrote the extension, the design/implement/test stats for it 
  should count against the stats for that language and again, the 
  calling code inly gets to count the function calls. 
 
> Actually, documentation is a part of development, and can be related to
> LOC, even though it is not part of the measurement.  I've been doing it
> for the last 25 years I've been managing projects.
>
Good! From my past experience I suspect you're one of the few that did.
How did you gather documentation stats? 

In Java you might do something like:

   DLOT = (source_lines - LOC)/F

where DLOT is 'Documentation Lines Of Text', LOC is the statement count 
and F is a fudge factor to reflect that comment lines are easier to write 
and review than source statements are to write and test.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#31523

On 4/7/2015 11:51 AM, Martin Gregorie wrote:
> On Tue, 07 Apr 2015 10:45:54 -0400, Jerry Stuckle wrote:
> 
>> On 4/7/2015 9:29 AM, Martin Gregorie wrote:
>> Then what do you suggest as a better measurement?  Experts have tried to
>> come up with one for over 50 years, and haven't.
>>
> That depends on what you're measuring.
> 
> LOC is OK for measuring programmer productivity and for comparing sizes 
> of programs provided that they belong to related groups, e.g. block 
> structured languages. 
>

Which is the classical method for determining workload.

>> To do that, you need to define "Function Point Analysis" and how it
>> applies to each language.  And you need to define how much work is
>> required for each function point.
>>
> Sure, but function points are NOT language-specific: think of them as 
> atomic system functions that can be deduced from a requirements spec when 
> combined with the sort of high level ERD and numbers of display forms and 
> reports you'd use when costing a new project. At that point you can 
> estimate the number of function points (read a row, paint a screen, 
> validate input....) needed to implement each display form, etc. 
>  

No, function points are not language specific.  However, the amount of
work going into building a function point is quite language specific.

And when determining which language to use, function points is almost
never a consideration.  There are much more important things to consider
- like what you need to do.  For instance, if I need heavy arithmetic
processing, FORTRAN is virtually always the choice.  If I need many
digits of precision, COBOL rules.  And if it needs to be cross-platform,
Java is a great choice.

Another important consideration is the talent you have on board.  Even
if another language may otherwise be the best for a certain project, if
none of your programmers are familiar with the language, it's probably
not a good idea to use that language.

Function points aren't even a consideration.

>> And then you will find different languages have different workloads for
>> each function point.  This then takes you back to LOC to determine
>> workload.
>>
> Multiplying the function points by language-specific weightings gives a 
> programming cost estimate, but you don't do that until the requirement 
> set is specific and the programming language(s) has/have been selected.
>

As I said above - function points are not even a consideration when
picking a language.

>> It really makes no difference whether the system is being built for a
>> one-off event or not.  The system is being built.
>>
> Yes it does: if you're writing something to test the practicality and/or 
> the performance of a design approach or if you know that program is 
> needed for a one-off purpose then you little or no documentation apart 
> from the requirement spec. OTOH if the system is expected to be in use 
> and maintained for a decade, of its something that is highly configurable 
> (such as a commercial banking package) then it needs to be documented 
> well enough to make maintenance, modification and configuration changes 
> relatively simple and so that supporting it is easy to pick up. I still 
> have mental scars from installing/supporting/maintaining systems which 
> lacked decent documentation.
> 

Even a program to test the practicality and/or design approach needs
documentation.  And in the projects I've managed, each is documented
exactly the same way as the final project.  Why?  Because if it works,
chances are it will become part of the final project.  And if it doesn't
work, sometimes another set of eyes can spot weaknesses in the code.

Even test cases are fully documented.

>>> Function point counting would do better here if you add a documentation
>>> effort factor for each function point. This would be as equally valid
>>> for traditional module document writing as it is for a combined
>>> approach, e.g. via javadocs for Java or cdocs/oxygen for C.
>>>
>>>
>> Pretty difficult since not all languages support javadoc or similar.
>>
> You use the tools for languages that support them and reap the benefits 
> of having the module-level documentation in the source and hence more 
> likely to be maintained as the code changes.
> 
> Otherwise you have use traditional word processors etc to maintain 
> separate module level documentation and accept the almost inevitable 
> problems that arise if, as usually happens, the documentation isn't 
> updated.
> 

Part of any properly defined change process includes updating the
documentation - and code is not released until the documentation is updated.

> I suspect there are are more third party javadoc-like tools for other 
> languages than you may have run across, e.g. there are at least two such 
> tools for C that, like javadocs, extract documentation from the source 
> files and I've seen systems where the source version control system 
> stored the requirements, HLL system design, database schema, forms 
> designs and COBOL source and could (a) generate systems documentation and 
> (b) feed source to the schema generator, compilers, etc.
> 

Sure.  But the documentation should be much more than what javadocs and
similar tools generate.  Most programmers (especially Java programmers)
are quite skimpy on the doc they generate.

Full doc includes not only the method name, parameters and return type,
but any constraints on each of those parameters and the return value. It
also contains a description of the processing it does, other methods
this one calls, and other methods which call this one.

Very little of this shows up in java documentation.

>> And BTW - you can access serial ports from many different languages, and
>> TCP/IP from Fortran or COBOL.  You just need the right libraries.
>>
> Some of these languages, e.g. Fortran and COBOL, don't have these 
> features in their standard libraries (where they even have a standard 
> library). Sure, if they can call external functions you can write 
> extensions, in assembler if necessary, but that isn't part of the 
> language and so shouldn't appear in the language metrics: 
> 

Java can't call TCP/IP either, without native-OS libraries.  The only
difference is these libraries are supplied with the JVM.

> - if you bought a 3rd party library, you shouldn't count much more 
>   than the function calls (one statement per call) in the language
>   statistics
> 
> - if you wrote the extension, the design/implement/test stats for it 
>   should count against the stats for that language and again, the 
>   calling code inly gets to count the function calls. 
>

Which is the same with any language.

>> Actually, documentation is a part of development, and can be related to
>> LOC, even though it is not part of the measurement.  I've been doing it
>> for the last 25 years I've been managing projects.
>>
> Good! From my past experience I suspect you're one of the few that did.
> How did you gather documentation stats? 
> 
> In Java you might do something like:
> 
>    DLOT = (source_lines - LOC)/F
> 
> where DLOT is 'Documentation Lines Of Text', LOC is the statement count 
> and F is a fudge factor to reflect that comment lines are easier to write 
> and review than source statements are to write and test.
> 
> 

It's pretty simple.  As part of the documentation, programmers indicate
the number of LOC in the function/method.  We've always kept a running
total, and used that against our design metrics to see how close we are
to the estimated workload.

Source_lines is not a good metric; it isn't unusual to have a long
source line span multiple lines in the file.  And occasionally you'll
have more than one statement on the same line.  For instance:

if (i == 3) return 5;
else return 6;

Depending on how you write it, this could be two, three or four LOC.
How do you count it?  You can't do it with a simple line counter; you'd
need to parse the entire file with a language-sensitive parser to make a
determination.

BTW - I usually count it as 3 lines (the "else" is not required), but
that needs to be determined as part of the project documentation so
everyone is on the same page.  But that doc may say to include the
"else", even though it is not strictly required at this time, for
consistency.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31527

On Tue, 07 Apr 2015 13:16:20 -0400, Jerry Stuckle wrote:

> Sure.  But the documentation should be much more than what javadocs and
> similar tools generate.  Most programmers (especially Java programmers)
> are quite skimpy on the doc they generate.
>
Agreed - both points.
 
> Full doc includes not only the method name, parameters and return type,
> but any constraints on each of those parameters and the return value. It
> also contains a description of the processing it does, other methods
> this one calls, and other methods which call this one.
> 
Indeed. In Java I think the standard class library documentation sets a 
reasonable standard that everybody should aim for. As a personal foible, 
I tend to regard the package, class, and method level comments as 
'documentation' and think these should be written to include the stuff 
that I, as a programmer, want to see if I'm going to use them. This means 
that comments inside a class or method are not tagged for javadocs use, 
principally because when I tried that, the result wasn't terribly 
readable.

Same goes for C, where the manpages set a reasonable standard and some of 
the tools allow a similar approach to Java - a comment at the top of a 
source file is effectively a class-level comment while comments in front 
of function declarations have the same content as a Java method level 
comment. If a C documentation tool is any good it can use the prototype 
or the actual function declaration to generate the API description  just 
as javadocs does: asking the programmer to do this just wastes his time 
and invites errors.
 
> Very little of this shows up in java documentation.
> 
If it doesn't then IMO the programmer and the code reviewers both did a 
bad job.

>>> And BTW - you can access serial ports from many different languages,
>>> and TCP/IP from Fortran or COBOL.  You just need the right libraries.
>>>
>> Some of these languages, e.g. Fortran and COBOL, don't have these
>> features in their standard libraries (where they even have a standard
>> library). Sure, if they can call external functions you can write
>> extensions, in assembler if necessary, but that isn't part of the
>> language and so shouldn't appear in the language metrics:
>> 
>> 
> Java can't call TCP/IP either, without native-OS libraries.  The only
> difference is these libraries are supplied with the JVM.
>
Of course, but like C, this stuff is in the standard libraries and well 
documented. The O'Reilly 'Lion' book may be old, but its still a 
worthwhile part of every *NIX programmers toolkit.

For this discussion I think its fair to make a distinction between a 
language's standard library and any locally written or 3rd party 
libraries: the standard library counts as part of the language because it 
and its documentation are there and available once the compiler is 
installed while locally written/third parties don't count as part of the 
language because they require extra time/effort/money to acquire, learn 
and use.
 
> It's pretty simple.  As part of the documentation, programmers indicate
> the number of LOC in the function/method.  We've always kept a running
> total, and used that against our design metrics to see how close we are
> to the estimated workload.
>
OK
 
> Source_lines is not a good metric; it isn't unusual to have a long
> source line span multiple lines in the file.  And occasionally you'll
> have more than one statement on the same line.  For instance:
>
Indeed: thats why I suggested that:
 
  commentlines = sourcelines - statements  

> if (i == 3) return 5;
> else return 6;
> 
> Depending on how you write it, this could be two, three or four LOC.
> How do you count it?  You can't do it with a simple line counter;
>
Sure, but for languages that use semicolons, counting them or, better, 
counting lines that contain semicolons gives fairly reasonable results: 
"good enough for government work" as an ex-army helicopter flying 
instructor used to say.

> BTW - I usually count it as 3 lines (the "else" is not required), but
> that needs to be determined as part of the project documentation so
> everyone is on the same page.  But that doc may say to include the
> "else", even though it is not strictly required at this time, for
> consistency.
>
... and don't lets get into the problems of counting

   if (cond) {
      statement;

versus
   if (cond)
   {
      statement;
   }

As I said, semicolon counting isn't all bad: in these cases it gives the 
same answer even if it opens up additional cans of worms with 'for' 
statements.

Similarly, though I've never tried it, counting full-stops at the end of 
lines would probably work for COBOL. this method wouldn't be confused by 
fullstops in data item pictures or decimal points in numeric literals, 
and would correctly say that an indexed READ or a SEARCH statement was a 
single statement even if it was spread over several lines as is commonly 
done. Comments are fairly straight forward too: just count NOTE 
statements and all following lines that don't end with a full stop as 
well as lines with an asterisk as the first non-numeric, non-whitespace
character.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#31529

On 4/7/2015 4:22 PM, Martin Gregorie wrote:
> On Tue, 07 Apr 2015 13:16:20 -0400, Jerry Stuckle wrote:
<snip>
>> Java can't call TCP/IP either, without native-OS libraries.  The only
>> difference is these libraries are supplied with the JVM.
>>
> Of course, but like C, this stuff is in the standard libraries and well 
> documented. The O'Reilly 'Lion' book may be old, but its still a 
> worthwhile part of every *NIX programmers toolkit.
> 
> For this discussion I think its fair to make a distinction between a 
> language's standard library and any locally written or 3rd party 
> libraries: the standard library counts as part of the language because it 
> and its documentation are there and available once the compiler is 
> installed while locally written/third parties don't count as part of the 
> language because they require extra time/effort/money to acquire, learn 
> and use.
>

I don't see any difference between a library which is supplied with the
compiler and an external library which has become a defacto standard,
For instance, in C++, STL at one time was an external library (actually
set of templates).  But it became a defacto standard, then finally a
standard.

Acquiring these libraries is generally pretty easy, and learning to use
them no more or less difficult and time consuming than if they were a
part of the compiler-supplied library.

>> It's pretty simple.  As part of the documentation, programmers indicate
>> the number of LOC in the function/method.  We've always kept a running
>> total, and used that against our design metrics to see how close we are
>> to the estimated workload.
>>
> OK
>  
>> Source_lines is not a good metric; it isn't unusual to have a long
>> source line span multiple lines in the file.  And occasionally you'll
>> have more than one statement on the same line.  For instance:
>>
> Indeed: thats why I suggested that:
>  
>   commentlines = sourcelines - statements  
> 
>> if (i == 3) return 5;
>> else return 6;
>>
>> Depending on how you write it, this could be two, three or four LOC.
>> How do you count it?  You can't do it with a simple line counter;
>>
> Sure, but for languages that use semicolons, counting them or, better, 
> counting lines that contain semicolons gives fairly reasonable results: 
> "good enough for government work" as an ex-army helicopter flying 
> instructor used to say.
> 

Not really.  Statements is not the same as LOC.  This would be two
statements - but in most cases it would be written on three or four
lines, counting as that many lines of code.

Depending on the program, the difference may be significant.


>> BTW - I usually count it as 3 lines (the "else" is not required), but
>> that needs to be determined as part of the project documentation so
>> everyone is on the same page.  But that doc may say to include the
>> "else", even though it is not strictly required at this time, for
>> consistency.
>>
> ... and don't lets get into the problems of counting
> 
>    if (cond) {
>       statement;
> 
> versus
>    if (cond)
>    {
>       statement;
>    }
> 
> As I said, semicolon counting isn't all bad: in these cases it gives the 
> same answer even if it opens up additional cans of worms with 'for' 
> statements.
> 

I don't know anyone who would consider a single brace to be a LOC.  But
this also brings up the point that you can't just count non-blank lines
and subtract lines with comments.

> Similarly, though I've never tried it, counting full-stops at the end of 
> lines would probably work for COBOL. this method wouldn't be confused by 
> fullstops in data item pictures or decimal points in numeric literals, 
> and would correctly say that an indexed READ or a SEARCH statement was a 
> single statement even if it was spread over several lines as is commonly 
> done. Comments are fairly straight forward too: just count NOTE 
> statements and all following lines that don't end with a full stop as 
> well as lines with an asterisk as the first non-numeric, non-whitespace
> character.
> 
> 

Which can take a significant amount of parsing to handle correctly.  Not
easy to do.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31521

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
> Then what do you suggest as a better measurement?  Experts have tried to
> come up with one for over 50 years, and haven't.
> 

For the purpose of measuring which language is used the most? Man-hours of
developer effort per year seems the most obvious metric, although one could
make an argument for dollars spent on development per year as well.

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#31524

On 4/7/2015 12:34 PM, Leif Roar Moldskred wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>
>> Then what do you suggest as a better measurement?  Experts have tried to
>> come up with one for over 50 years, and haven't.
>>
> 
> For the purpose of measuring which language is used the most? Man-hours of
> developer effort per year seems the most obvious metric, although one could
> make an argument for dollars spent on development per year as well.
> 

Which is directly related to LOC per year.  LOC per programmer for
experienced programmers varies little with the language.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31525

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> 
> Which is directly related to LOC per year.  LOC per programmer for
> experienced programmers varies little with the language.
> 

For the same type of activity, perhaps, but in my experience LOC
per programmer-hour can vary a lot between initial system 
implementation, system maintenance and system reworking, and it
can also vary a great deal with different frameworks and 
technologies within the same language. 

-- 
Leif Roar Moldskred

[toc] | [prev] | [next] | [standalone]

#31530

On 4/7/2015 1:40 PM, Leif Roar Moldskred wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>
>> Which is directly related to LOC per year.  LOC per programmer for
>> experienced programmers varies little with the language.
>>
> 
> For the same type of activity, perhaps, but in my experience LOC
> per programmer-hour can vary a lot between initial system 
> implementation, system maintenance and system reworking, and it
> can also vary a great deal with different frameworks and 
> technologies within the same language. 
> 

It all depends on how well designed the system is.  A good design speeds
up programming.

But even though the LOC per programmer-hour varies, it can still be
estimated from a good design with experience and knowledge of programmer
abilities.

Some frameworks will help, but if the system is designed properly, the
most help would be to prevent (or catch early) syntactical errors
(especially unbalanced braces - which can be a bugger to find).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31528

On Tue, 07 Apr 2015 13:18:00 -0400, Jerry Stuckle wrote:

> On 4/7/2015 12:34 PM, Leif Roar Moldskred wrote:
>> For the purpose of measuring which language is used the most? Man-hours
>> of developer effort per year seems the most obvious metric, although
>> one could make an argument for dollars spent on development per year as
>> well.
>> 
>> 
> Which is directly related to LOC per year.  LOC per programmer for
> experienced programmers varies little with the language.
>
Yes, agreed. There's a fair amount of research been done on this and the 
number of lines of written, clean compiled *and unit tested* code 
produces by an individual programmer is remarkably constant regardless of 
the language being used. This is the main reason productivity rises as 
you progress along the sequence:

	assembler -> C/COBOL/Java etc -> 4GL


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#31531

On 4/7/2015 4:28 PM, Martin Gregorie wrote:
> On Tue, 07 Apr 2015 13:18:00 -0400, Jerry Stuckle wrote:
> 
>> On 4/7/2015 12:34 PM, Leif Roar Moldskred wrote:
>>> For the purpose of measuring which language is used the most? Man-hours
>>> of developer effort per year seems the most obvious metric, although
>>> one could make an argument for dollars spent on development per year as
>>> well.
>>>
>>>
>> Which is directly related to LOC per year.  LOC per programmer for
>> experienced programmers varies little with the language.
>>
> Yes, agreed. There's a fair amount of research been done on this and the 
> number of lines of written, clean compiled *and unit tested* code 
> produces by an individual programmer is remarkably constant regardless of 
> the language being used. This is the main reason productivity rises as 
> you progress along the sequence:
> 
> 	assembler -> C/COBOL/Java etc -> 4GL
> 
> 

Oh, definitely.  I did a fair amount of IBM Assembler (mainframe) back
in the 70's and 80's.  It's fun to get down to the bits and bytes for a
while - but quickly becomes tedious in the length of time it takes to
code something pretty simple.  And keeping all those registers
straight... Yuk! :)

Internally, IBM had a language called PL/S which was a subset of PL/1
with an embedded assembler.  The compiler would convert the PL/S
statements to assembler statements, then assemble the program.  It sped
up development quite a bit, while still keeping the efficiency of
assembler where needed (even back then mainframe OS's had to be coded in
assembler for efficiency).

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31532

On Tue, 07 Apr 2015 17:11:48 -0400, Jerry Stuckle wrote:

> Internally, IBM had a language called PL/S which was a subset of PL/1
> with an embedded assembler.  The compiler would convert the PL/S
> statements to assembler statements, then assemble the program.  It sped
> up development quite a bit, while still keeping the efficiency of
> assembler where needed (even back then mainframe OS's had to be coded in
> assembler for efficiency).
>
Interesting.

In the late 70s/early 80s the same thing showed up on 8/16 bit chips. I 
did a fair amount of programming in both assembler and PL/9 (a clone of 
the lowish-level PL/M for Intel chips but for the MC6809). A nice feature 
of PL/9 was that it could generate out assembler source rather than 
binary if you asked nicely and it was equally easy to drop chunks of 
assembler back into a PL/9 . Consequently, it was dead easy to optimise 
code that way. PL/9 was a good code generator (it was almost impossible 
to improve in the code it generated for each statement) but a poor code 
optimiser (it made no attempt to rationalise adjacent code where one 
statement ended and the next began), so it was interesting that some 
chunks of code could be improved a lot by recoding in assembler, but most 
of the compiler's output could be improved only marginally. 

I've written a bit of PL/1 in the past - all on AS/400 or IBM System/88 
(rebadged Stratus fault-tolerant boxes) though, never on a mainframe.

So, I'm curious: did PL/S show the same characteristic I discovered in 
PL/9?  


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#31533

On 4/7/2015 7:00 PM, Martin Gregorie wrote:
> On Tue, 07 Apr 2015 17:11:48 -0400, Jerry Stuckle wrote:
> 
>> Internally, IBM had a language called PL/S which was a subset of PL/1
>> with an embedded assembler.  The compiler would convert the PL/S
>> statements to assembler statements, then assemble the program.  It sped
>> up development quite a bit, while still keeping the efficiency of
>> assembler where needed (even back then mainframe OS's had to be coded in
>> assembler for efficiency).
>>
> Interesting.
> 
> In the late 70s/early 80s the same thing showed up on 8/16 bit chips. I 
> did a fair amount of programming in both assembler and PL/9 (a clone of 
> the lowish-level PL/M for Intel chips but for the MC6809). A nice feature 
> of PL/9 was that it could generate out assembler source rather than 
> binary if you asked nicely and it was equally easy to drop chunks of 
> assembler back into a PL/9 . Consequently, it was dead easy to optimise 
> code that way. PL/9 was a good code generator (it was almost impossible 
> to improve in the code it generated for each statement) but a poor code 
> optimiser (it made no attempt to rationalise adjacent code where one 
> statement ended and the next began), so it was interesting that some 
> chunks of code could be improved a lot by recoding in assembler, but most 
> of the compiler's output could be improved only marginally. 
> 
> I've written a bit of PL/1 in the past - all on AS/400 or IBM System/88 
> (rebadged Stratus fault-tolerant boxes) though, never on a mainframe.
> 
> So, I'm curious: did PL/S show the same characteristic I discovered in 
> PL/9?  
> 
> 

Yup, it was basically just a generator; no optimization involved.  An
"if" statement always generated the same code (other than the condition
itself, anyway).  But like PL/9, it was expert assembler programmers who
coded the compiler, and they new every shortcut in the book, so it was
pretty much impossible to optimize any single statement.  And the
language itself was very slimmed down, with only the more common
statements such as if/then/else, loops and similar "easy" statements.

But even without optimization, the generated code was generally so good
it didn't require much, if any, rework.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#31496

On 4/5/2015 12:31 PM, Stefan Ram wrote:
>    But since you insist, let me give you some factual information.
>
>        - Both are trademarks of Oracle.

Which is why the language is now officially called "ECMAScript."

>        - JavaScript was designed by Brendan Eich who wrote:
>
>            »The diktat from upper engineering management
>            was that the language must "look like Java".«

Who hates that decision.

>        - of course the syntax and semantics of both
>          languages have a lot in common (I am giving courses
>          in both languages and my course notes for both Java
>          and JavaScript can be read in the web, albeit in
>          German language).

False, false, false, false, false. Yes, the core syntax of 
semicolon-terminated statements, curly-brace block definitions, and 
infix arithmetic notation is vaguely the same, but the fundamental 
object semantics are wildly different. JavaScript is a dynamically-typed 
language (all attempts to add static typing have failed), which is a 
radical departure from Java. Actually, JS has only five types: number, 
undefined, string, function, and object (although ES6 does appear to add 
symbol to that list). The object-oriented nature of JS is fully a 
duck-typed system, and it's based on a prototype model of inheritance in 
contrast to Java's strict static subtyping relationships.

JavaScript owes far more of its core semantic model to LISP or Scheme 
than it does Java.

>        - when running in the browser, the LiveConnect
>          technology allows Java and JavaScript code
>          to communicate with each other.

No longer present in any major browser, as of several years ago.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.java.programmer

csiph-web