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

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

Re: Interplatform (interprocess, interlanguage) communication

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: Interplatform (interprocess, interlanguage) communication jebblue <n@n.nnn> - 2012-02-07 12:11 -0600
    Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-07 16:38 -0700
      Re: Interplatform (interprocess, interlanguage) communication Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-07 20:26 -0400
        Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-08 01:41 -0700
          Re: Interplatform (interprocess, interlanguage) communication Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-08 07:19 -0400
            Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-08 12:07 -0700
              Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-08 21:16 -0500
                Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-08 19:50 -0700
                  Re: Interplatform (interprocess, interlanguage) communication Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-09 06:24 -0400
                    Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-09 09:15 -0700
                      Re: Interplatform (interprocess, interlanguage) communication Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-09 18:58 -0400
                        Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-09 16:15 -0700
                        Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-09 18:50 -0500
                          Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-09 21:40 -0700
                            Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 14:47 -0500
                              Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-11 12:06 -0800
                                Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 15:18 -0500
                                  Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-11 23:03 -0700
                                    Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 09:27 -0500
                                      Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-12 13:33 -0700
                                        Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 15:50 -0500
                                          Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-12 14:34 -0700
                      Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-09 18:48 -0500
                        Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-09 21:46 -0700
                          Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-10 08:51 -0800
                            Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-10 10:43 -0700
                              Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-10 13:15 -0800
                                Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-10 14:50 -0700
                                  Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-10 14:32 -0800
                                    Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-10 17:10 -0700
                                      Re: Interplatform (interprocess, interlanguage) communication Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-10 22:08 -0400
                                        Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-11 00:49 -0700
                                          Re: Interplatform (interprocess, interlanguage) communication Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-11 14:04 -0400
                                Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 14:55 -0500
                              Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 14:52 -0500
                                Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-11 20:06 -0700
                                  Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 22:41 -0500
                                    Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-12 00:46 -0700
                                      Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 09:29 -0500
                                      Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 09:31 -0500
                                    Re: Interplatform (interprocess, interlanguage) communication Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-12 16:02 +0000
                                      Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 11:16 -0500
                                        Re: Interplatform (interprocess, interlanguage) communication Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-12 22:46 +0000
                                      Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-12 11:33 -0700
                                  Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-11 20:18 -0800
                                    Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-12 01:36 -0700
                                      Re: Interplatform (interprocess, interlanguage) communication Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-02-12 13:52 -0600
                                        Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-12 14:43 -0700
                          Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 14:49 -0500
                    Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-09 18:46 -0500
                  Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-09 18:45 -0500
          Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-08 14:02 -0800
            Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-08 18:49 -0700
              Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-08 21:14 -0500
                Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-08 20:07 -0800
                  Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-08 23:29 -0700
                    Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-09 09:40 -0800
                      Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-09 17:02 -0700
                Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-08 21:10 -0700
                  Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-09 18:54 -0500
                    Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-10 10:25 -0700
                      Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 14:45 -0500
                        Re: Interplatform (interprocess, interlanguage) communication Lew <lewbloch@gmail.com> - 2012-02-11 12:14 -0800
                          Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-11 15:20 -0500
                            Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-11 22:20 -0700
                              Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-12 09:23 -0500
                                Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-12 12:13 -0700
      Re: Interplatform (interprocess, interlanguage) communication Arne Vajhøj <arne@vajhoej.dk> - 2012-02-07 20:24 -0500
      Re: Interplatform (interprocess, interlanguage) communication Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-08 01:31 +0000
        Re: Interplatform (interprocess, interlanguage) communication BGB <cr88192@hotmail.com> - 2012-02-08 00:55 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#12001

On 2/12/2012 3:33 PM, BGB wrote:
> On 2/12/2012 7:27 AM, Arne Vajhøj wrote:
>> On 2/12/2012 1:03 AM, BGB wrote:
>>> On 2/11/2012 1:18 PM, Arne Vajhøj wrote:
>>>> On 2/11/2012 3:06 PM, Lew wrote:
>>>>> XML is just fine for just about every purpose to which it's put.
>>>>> That's why it's popular now. People who cavil about "bandwidth" and
>>>>> "10 Hz network messages" are tossing us red-herring sashimi. You
>>>>> aren't going to get 10+ Hz message exchanges over the WAN. For
>>>>> realistic message rates, XML suits beautifully. I speak from
>>>>> experience with many, many projects that used every conceivable
>>>>> message format from binary to CSV to custom to XML to protocol buffers
>>>>> to JSON, and XML has distinct advantages. Its purported disadvantages
>>>>> of bulk and bandwidth turn out to be non-issues in practice. Really.
>>>>> That's real.
>>>>
>>>> ????
>>>>
>>>> The industry standard for smartphone apps and AJAX web apps
>>>> are JSON because the bandwidth actually matters.
>>>
>>> yeah.
>>
>> But please note that you do not invent your own JSON parser
>> either - you use something already done. In Java there are json.org,
>> gson etc..
>>
>
> in Java, yes, one may use the libraries.
>
> on the C end, one may choose to throw one together, or use a JavaScript
> VM if one is available, ...

There are plenty of libs for C as well.

30 seconds of googling found:

http://www.digip.org/jansson/
http://live.gnome.org/JsonGlib
http://sourceforge.net/projects/mjson/
http://oss.metaparadigm.com/json-c/

Arne

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

#12005

On 2/12/2012 1:50 PM, Arne Vajhøj wrote:
> On 2/12/2012 3:33 PM, BGB wrote:
>> On 2/12/2012 7:27 AM, Arne Vajhøj wrote:
>>> On 2/12/2012 1:03 AM, BGB wrote:
>>>> On 2/11/2012 1:18 PM, Arne Vajhøj wrote:
>>>>> On 2/11/2012 3:06 PM, Lew wrote:
>>>>>> XML is just fine for just about every purpose to which it's put.
>>>>>> That's why it's popular now. People who cavil about "bandwidth" and
>>>>>> "10 Hz network messages" are tossing us red-herring sashimi. You
>>>>>> aren't going to get 10+ Hz message exchanges over the WAN. For
>>>>>> realistic message rates, XML suits beautifully. I speak from
>>>>>> experience with many, many projects that used every conceivable
>>>>>> message format from binary to CSV to custom to XML to protocol
>>>>>> buffers
>>>>>> to JSON, and XML has distinct advantages. Its purported disadvantages
>>>>>> of bulk and bandwidth turn out to be non-issues in practice. Really.
>>>>>> That's real.
>>>>>
>>>>> ????
>>>>>
>>>>> The industry standard for smartphone apps and AJAX web apps
>>>>> are JSON because the bandwidth actually matters.
>>>>
>>>> yeah.
>>>
>>> But please note that you do not invent your own JSON parser
>>> either - you use something already done. In Java there are json.org,
>>> gson etc..
>>>
>>
>> in Java, yes, one may use the libraries.
>>
>> on the C end, one may choose to throw one together, or use a JavaScript
>> VM if one is available, ...
>
> There are plenty of libs for C as well.
>
> 30 seconds of googling found:
>
> http://www.digip.org/jansson/
> http://live.gnome.org/JsonGlib
> http://sourceforge.net/projects/mjson/
> http://oss.metaparadigm.com/json-c/
>

fair enough.

I might look into it, although personally I don't use JSON for this at 
the moment, and if it were needed in my-case, as-is my script VM can 
parse JSON (given the language used is a superset of JavaScript 
anyways), although this is potentially a less efficient strategy than a 
dedicated parser.

say, in my case, it would be a tradeoff between either: using someone 
else's library, passing the JSON through "eval", or spit out some logic 
to make the VM parse the JSON directly (probably just copy/paste/edit 
some of the existing parser code). then one could wonder secondarily: 
what form would the JSON be parsed into? "there is a library for that" 
is not always necessarily the least-effort option.

either way, one still might want to save more bytes, say, by running it 
through deflate or similar. if one wants libraries, Java has it built 
in, and in C-land there is zlib.

in my case, I also have a deflate codec which is stored as a single big 
source file, mostly as this makes it a little more convenient (in 
several ways) than using zlib. JPEG was similar, as originally I used 
libjpeg, but reimplemented JPEG as a "single big source file" to be a 
generally more convenient option (copy/paste the source file and go).

I don't claim a person might "always" want to do this, but as I see it, 
it is still a potentially valid option. one could maybe go further, and 
put Deflate, JPEG, PNG, and several other formats, all in a single big 
file, at the drawback of the file becoming overly large.

similarly, the above probably would be fairly pointless in Java, both 
because this stuff exists in the standard library, and also because this 
would also result in a single giant class as well.


the cheapest option for one person may well turn out to be a more 
expensive option for another person, say if they one of the options 
amounts to "implement the functionality from the ground up" rather than 
"copy-paste a few bits from over there and hack something together", or 
even maybe just "add a few lines in a function over here and add a new 
function or method over there which redirects the call to the first 
function".

all of this stuff can be fairly relative, and there are rarely "cut and 
dry" answers to problems.



as for the delay issue, found this article on part of the topic:
http://en.wikipedia.org/wiki/Lag_%28online_gaming%29

also maybe relevant:
http://en.wikipedia.org/wiki/Internet_streaming

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

#11890

On 2/9/2012 11:15 AM, BGB wrote:
> On 2/9/2012 3:24 AM, Arved Sandstrom wrote:
>> On 12-02-08 10:50 PM, BGB wrote:
>>> On 2/8/2012 7:16 PM, Arne Vajhøj wrote:
>>>> On 2/8/2012 2:07 PM, BGB wrote:
>>>>> On 2/8/2012 4:19 AM, Arved Sandstrom wrote:
>>>>>> On 12-02-08 04:41 AM, BGB wrote:
>>>>>>> note: my main way of working with XML is typically via DOM-style
>>>>>>> interfaces (if I am using it, it is typically because I am directly
>>>>>>> working with the data structure, and not as the result of some
>>>>>>> dumb-ass
>>>>>>> "data binding" crud...).
>>>>>>
>>>>>> I haven't been able to completely avoid using the DOM, but I
>>>>>> loathe the
>>>>>> API. If I'm using XML at all, and JAXB suits, I'll use JAXB. More
>>>>>> generally I'll use SAX or StAX.
>>>>>>
>>>>>
>>>>> I have rarely done things for which SAX has made sense...
>>>>> usually in cases where SAX would make sense, I end up using
>>>>> line-oriented text formats instead (because there is often little
>>>>> obvious reason for why XML syntax would make much sense).
>>>>
>>>> Non flat structure and validation comes to mind.
>>>
>>> fair enough.
>>>
>>> often, one can implement non-flat structures with line-oriented formats,
>>> for example:
>>> ...
>>> groupDef {
>>> ...
>>> groupDef {
>>> itemDef {
>>> ...
>>> }
>>> ...
>>> }
>>> ...
>>> }
>> [ SNIP ]
>>
>> No need for the braces, if you're going to use those all you gain over
>> the XML is terseness.
>>
>
> well, if the format is still line-oriented, one can still parse the
> files using a loop, getting and splitting strings, and checking the
> first token of each line.
>
> parsing XML is a little more invovlved, since:
> items may be split across lines, or multiple items may exist on the same
> line;
> one can no longer use whitespace or commas as the primary deliminator;

????

No one in their right mind would parse XML manually.

You can pick between lots of nice XML API's (many of them
shipping with Java) that will handle all that.

Arne

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

#11901

On 2/9/2012 4:48 PM, Arne Vajhøj wrote:
> On 2/9/2012 11:15 AM, BGB wrote:
>> On 2/9/2012 3:24 AM, Arved Sandstrom wrote:
>>> On 12-02-08 10:50 PM, BGB wrote:
>>>> On 2/8/2012 7:16 PM, Arne Vajhøj wrote:
>>>>> On 2/8/2012 2:07 PM, BGB wrote:
>>>>>> On 2/8/2012 4:19 AM, Arved Sandstrom wrote:
>>>>>>> On 12-02-08 04:41 AM, BGB wrote:
>>>>>>>> note: my main way of working with XML is typically via DOM-style
>>>>>>>> interfaces (if I am using it, it is typically because I am directly
>>>>>>>> working with the data structure, and not as the result of some
>>>>>>>> dumb-ass
>>>>>>>> "data binding" crud...).
>>>>>>>
>>>>>>> I haven't been able to completely avoid using the DOM, but I
>>>>>>> loathe the
>>>>>>> API. If I'm using XML at all, and JAXB suits, I'll use JAXB. More
>>>>>>> generally I'll use SAX or StAX.
>>>>>>>
>>>>>>
>>>>>> I have rarely done things for which SAX has made sense...
>>>>>> usually in cases where SAX would make sense, I end up using
>>>>>> line-oriented text formats instead (because there is often little
>>>>>> obvious reason for why XML syntax would make much sense).
>>>>>
>>>>> Non flat structure and validation comes to mind.
>>>>
>>>> fair enough.
>>>>
>>>> often, one can implement non-flat structures with line-oriented
>>>> formats,
>>>> for example:
>>>> ...
>>>> groupDef {
>>>> ...
>>>> groupDef {
>>>> itemDef {
>>>> ...
>>>> }
>>>> ...
>>>> }
>>>> ...
>>>> }
>>> [ SNIP ]
>>>
>>> No need for the braces, if you're going to use those all you gain over
>>> the XML is terseness.
>>>
>>
>> well, if the format is still line-oriented, one can still parse the
>> files using a loop, getting and splitting strings, and checking the
>> first token of each line.
>>
>> parsing XML is a little more invovlved, since:
>> items may be split across lines, or multiple items may exist on the same
>> line;
>> one can no longer use whitespace or commas as the primary deliminator;
>
> ????
>
> No one in their right mind would parse XML manually.
>
> You can pick between lots of nice XML API's (many of them
> shipping with Java) that will handle all that.
>

depends on which language one is using at the time...

if one is using Java, then XML parsing is basically free.
if one is using C, then it is either "write some code to do it", or 
suffer with a 3rd party library dependency (one might validly choose to 
write the code themselves in this case).


I don't expect it is all that uncommon for a person to switch between 
several different languages, and maybe deal with the strengths and 
weaknesses of whichever language they are using at the time.

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

#11905

BGB wrote:
> Arne Vajhøj wrote:
> > ????
> >
> > No one in their right mind would parse XML manually.
> >
> > You can pick between lots of nice XML API's (many of them
> > shipping with Java) that will handle all that.
> >
> 
> depends on which language one is using at the time...
> 
> if one is using Java, then XML parsing is basically free.

This /is/ a Java newsgroup, as you might have noticed.

> if one is using C, then it is either "write some code to do it", or 
> suffer with a 3rd party [sic] library dependency (one might validly choose to 
> write the code themselves in this case).

"Suffer"? The XML parsers for C are well-established, very reliable, and no 
cause for suffering. Using a pejorative is not the same as establishing a 
point.

There is nothing wrong with the third-party libraries, and the choice to 
roll your own for C is rarely valid. You seem to suffer from NIH syndrome.

> I don't expect it is all that uncommon for a person to switch between 
> several different languages, and maybe deal with the strengths and 
> weaknesses of whichever language they are using at the time.

Not usually in the same program. Your expectation lacks relevance here.

-- 
Lew

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

#11912

On 2/10/2012 9:51 AM, Lew wrote:
> BGB wrote:
>> Arne Vajhøj wrote:
>>> ????
>>>
>>> No one in their right mind would parse XML manually.
>>>
>>> You can pick between lots of nice XML API's (many of them
>>> shipping with Java) that will handle all that.
>>>
>>
>> depends on which language one is using at the time...
>>
>> if one is using Java, then XML parsing is basically free.
>
> This /is/ a Java newsgroup, as you might have noticed.
>

yes, but this thread is also about cross-language message passing, one 
may have to face the issue that, at least one end, will not be using Java.

this means, of course, that both ends will need to be able to deal with 
both sending and receiving the data.


>> if one is using C, then it is either "write some code to do it", or
>> suffer with a 3rd party [sic] library dependency (one might validly choose to
>> write the code themselves in this case).
>
> "Suffer"? The XML parsers for C are well-established, very reliable, and no
> cause for suffering. Using a pejorative is not the same as establishing a
> point.
>
> There is nothing wrong with the third-party libraries, and the choice to
> roll your own for C is rarely valid. You seem to suffer from NIH syndrome.
>

they introduce porting hassles:
does one bundle "libxml" with their app on Windows;
do they use MSXML and then deal with having to switch over to "libxml" 
when building on Linux?
...

often, writing ones' own code to do something may be the fastest and 
easiest option.


writing code to do something can also be a fun and entertaining 
experience (giving oneself stuff to do, and then doing it, ...), and 
also give ideas/experience which could be useful for other things.

granted, there is also the goal of getting things done in a timely 
manner, so it is a tradeoff.

but, anyways, it is like asking a person never to write their own JPEG 
loader/saver, or their own scripting-language compiler. yes, maybe a 
person doesn't technically need to, but they may forsake potentially 
valuable learning experiences (or the claim to having the skills to do so).


>> I don't expect it is all that uncommon for a person to switch between
>> several different languages, and maybe deal with the strengths and
>> weaknesses of whichever language they are using at the time.
>
> Not usually in the same program. Your expectation lacks relevance here.
>

so, then, a program written in a mix of 5 programming languages is 
probably rare then?...


but, anyways, whether or not it is within the same program was not the 
issue:
it could be in multiple cooperating programs which share data, or in 
different components (which merely share APIs or similar).

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

#11919

BGB wrote:
> yes, but this thread is also about cross-language message passing, one 
> may have to face the issue that, at least one end, will not be using Java.
> 
> this means, of course, that both ends will need to be able to deal with 
> both sending and receiving the data.

This is the use case for which XML with schema excels. It is very nearly ideal 
for the purpose. XML is semantically void with respect to the problem domain, 
schemas provide a reliable contract for interpretation of the messages, they 
provide a convenient human-readable format to ensure agreement by all 
stakeholders, the drive the easy-to-use tools for XML-based message passing, 
and such easy-to-use tools are abundantly available for every major platform 
and computer language.

Your comments about different libraries' availability makes an asset sound like 
a problem. It's a *good* thing that there are so many libraries available. XML 
itself provides the compatibility.

-- 
Lew

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

#11920

On 2/10/2012 2:15 PM, Lew wrote:
> BGB wrote:
>> yes, but this thread is also about cross-language message passing, one
>> may have to face the issue that, at least one end, will not be using Java.
>>
>> this means, of course, that both ends will need to be able to deal with
>> both sending and receiving the data.
>
> This is the use case for which XML with schema excels. It is very nearly ideal
> for the purpose. XML is semantically void with respect to the problem domain,
> schemas provide a reliable contract for interpretation of the messages, they
> provide a convenient human-readable format to ensure agreement by all
> stakeholders, the drive the easy-to-use tools for XML-based message passing,
> and such easy-to-use tools are abundantly available for every major platform
> and computer language.
>

yes, but it is the agreement on particular formats (say, that both 
parties will use XML and have the contents laid out a particular way), 
rather than the use of either schemas or validation, which allows for 
said compatibility.

it is like claiming that people need to depend on standardized 
dictionaries (and some sort of automatic word-use and grammar checker) 
to be able to carry on a conversation, rather than, say, the 
dictionaries existing as a means of recording agreed-upon word-use patterns.


or, like those people who go and claim that "math is reality" rather 
than "math is a formalized system which can be used to describe 
reality", and so on.


> Your comments about different libraries' availability makes an asset sound like
> a problem. It's a *good* thing that there are so many libraries available. XML
> itself provides the compatibility.
>

yep.


it is likewise for many common file-formats:
large numbers of people use them, write code to read and write them, ... 
so, people go and write down how the file format works, such that others 
can write things which can read and write the files.

luckily for everyone, most people can agree to use PNG and JPEG and so 
on as well...

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

#11923

On Friday, February 10, 2012 1:50:43 PM UTC-8, BGB wrote:
> On 2/10/2012 2:15 PM, Lew wrote:
> > BGB wrote:
> >> yes, but this thread is also about cross-language message passing, one
> >> may have to face the issue that, at least one end, will not be using Java.
> >>
> >> this means, of course, that both ends will need to be able to deal with
> >> both sending and receiving the data.
> >
> > This is the use case for which XML with schema excels. It is very nearly ideal
> > for the purpose. XML is semantically void with respect to the problem domain,
> > schemas provide a reliable contract for interpretation of the messages, they
> > provide a convenient human-readable format to ensure agreement by all
> > stakeholders, the drive the easy-to-use tools for XML-based message passing,
> > and such easy-to-use tools are abundantly available for every major platform
> > and computer language.
> >
> 
> yes, but it is the agreement on particular formats (say, that both 
> parties will use XML and have the contents laid out a particular way), 
> rather than the use of either schemas or validation, which allows for 
> said compatibility.

Sure, and schemas give a simple, readable, clear and unambiguous means to 
communicate the proposal and reach an agreement.

You might as well say that it's the intent of the carpenter that makes the 
furniture, not the saw. This does not make the saw any less useful or valuable.

> it is like claiming that people need to depend on standardized 
> dictionaries (and some sort of automatic word-use and grammar checker) 
> to be able to carry on a conversation, rather than, say, the 
> dictionaries existing as a means of recording agreed-upon word-use patterns.

No, it's nothing like that.

It is like having a dictionary to record the agreement. Following your logic, 
we'd claim that a dictionary isn't useful because all it does is record an 
agreement in a structured, easily-followed and standard manner.

> or, like those people who go and claim that "math is reality" rather 
> than "math is a formalized system which can be used to describe 
> reality", and so on.

Huh? To make a math joke, you really are off on a tangent with that one.

What have you got against math people? Oh, and by the way, math is reality.

> > Your comments about different libraries' availability makes an asset sound like
> > a problem. It's a *good* thing that there are so many libraries available. XML
> > itself provides the compatibility.
> >
> 
> yep.
> 
> 
> it is likewise for many common file-formats:
> large numbers of people use them, write code to read and write them, ... 
> so, people go and write down how the file format works, such that others 
> can write things which can read and write the files.
> 
> luckily for everyone, most people can agree to use PNG and JPEG and so 
> on as well...

But by your logic, PNG and JPEG are not useful because all we have to do is 
invent our own format and agree to use it and re-invent all the nifty (and 
often free) useful tools that only work on standard formats like PNG and JPEG,
thus throwing away all the human-centuries of engineering and wisdom that went 
into those standards simply because we believe we're more clever than anyone 
else and can exist in a vacuum and don't need all those steenkeen' free, useful
tools.

-- 
Lew

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

#11925

On 2/10/2012 3:32 PM, Lew wrote:
> On Friday, February 10, 2012 1:50:43 PM UTC-8, BGB wrote:
>> On 2/10/2012 2:15 PM, Lew wrote:
>>> BGB wrote:
>>>> yes, but this thread is also about cross-language message passing, one
>>>> may have to face the issue that, at least one end, will not be using Java.
>>>>
>>>> this means, of course, that both ends will need to be able to deal with
>>>> both sending and receiving the data.
>>>
>>> This is the use case for which XML with schema excels. It is very nearly ideal
>>> for the purpose. XML is semantically void with respect to the problem domain,
>>> schemas provide a reliable contract for interpretation of the messages, they
>>> provide a convenient human-readable format to ensure agreement by all
>>> stakeholders, the drive the easy-to-use tools for XML-based message passing,
>>> and such easy-to-use tools are abundantly available for every major platform
>>> and computer language.
>>>
>>
>> yes, but it is the agreement on particular formats (say, that both
>> parties will use XML and have the contents laid out a particular way),
>> rather than the use of either schemas or validation, which allows for
>> said compatibility.
>
> Sure, and schemas give a simple, readable, clear and unambiguous means to
> communicate the proposal and reach an agreement.
>
> You might as well say that it's the intent of the carpenter that makes the
> furniture, not the saw. This does not make the saw any less useful or valuable.
>

a saw is actually physically needed for the work to be done.


a more accurate example would likely be:
does the carpenter need a CNC milling machine?

the carpenter could just saw at the wood, and make something.
and he could draw up a diagram or make a blueprint or similar if he wanted.

but, demanding that a schema be used is about like asking that he write 
the CNC program, and have the machine do it.


>> it is like claiming that people need to depend on standardized
>> dictionaries (and some sort of automatic word-use and grammar checker)
>> to be able to carry on a conversation, rather than, say, the
>> dictionaries existing as a means of recording agreed-upon word-use patterns.
>
> No, it's nothing like that.
>
> It is like having a dictionary to record the agreement. Following your logic,
> we'd claim that a dictionary isn't useful because all it does is record an
> agreement in a structured, easily-followed and standard manner.
>

I was not saying dictionaries are not useful, only that one can carry on 
a conversation without invoking one at every instant to validate what 
one is saying.

a written specification for a file format will serve a similar purpose.
an XML schema could be considered as a narrower machine-readable subset 
of a file-format specification. although there are cases where it could 
be useful to validate against the schema, this is not likely the case in 
every case.


>> or, like those people who go and claim that "math is reality" rather
>> than "math is a formalized system which can be used to describe
>> reality", and so on.
>
> Huh? To make a math joke, you really are off on a tangent with that one.
>
> What have you got against math people? Oh, and by the way, math is reality.
>

grr, those people annoy me, especially for their whole "the theory is 
too pure to be used for anything actually useful" thing (of believing 
that physical reality is somehow inferior to "mathematical perfection" 
or whatever...).

at least software does something, and has slightly less occurrence of 
people going on endlessly about "perfection" and whatever else (or 
getting all condescending and nit-picky about something being "not 
sufficiently perfect enough", bleh...).


also, my reality happens to be made mostly out of matter, and "stuff".

matter is obvious enough: one can see it, one can eat it, ... 
secondarily: software is "real enough", because one can run it, and one 
can copy it around via drives or over the internet, ...

but, where is the "math": it is seemingly nowhere to be found, and seems 
mostly just to boil down to people messing around with symbolic 
notations and describing the behavior of systems otherwise made out of 
matter.

IMO, it makes about as much sense as those people who believe reality is 
made out of emotions, or perceptions, or morals, or is actually a huge 
pile of laws and words, or whatever else.

(decided against writing a bunch of arguments for how each apparently 
fails as a good basis for observable reality).

rather each is by some means built on top of reality:
emotions and perception being a byproduct of the brain (itself made out 
of matter...);
morals being (probably) a byproduct of large-scale cost/benefit 
tradeoffs (bad behavior -> bad results, and is a place where emotions 
and economics seem to converge, ...);
and laws and words are a byproduct of language use and peoples' attempts 
to organize things.

likewise, math would seem to be a byproduct of the analysis and 
description of physical and mechanical systems.


not that all this stuff doesn't matter, just reality is (probably) not 
made out of it.

also note: it is possible to believe in a reality made out of matter, 
and also believe in religious stuff and similar as well (because, as I 
see it, the belief that they necessarily conflict is probably also flawed).

( could go into the matter of "matter + religion + morals + rational 
self-interest + free market + ...", but, I have probably been going off 
on enough of a tangent already... )


>>> Your comments about different libraries' availability makes an asset sound like
>>> a problem. It's a *good* thing that there are so many libraries available. XML
>>> itself provides the compatibility.
>>>
>>
>> yep.
>>
>>
>> it is likewise for many common file-formats:
>> large numbers of people use them, write code to read and write them, ...
>> so, people go and write down how the file format works, such that others
>> can write things which can read and write the files.
>>
>> luckily for everyone, most people can agree to use PNG and JPEG and so
>> on as well...
>
> But by your logic, PNG and JPEG are not useful because all we have to do is
> invent our own format and agree to use it and re-invent all the nifty (and
> often free) useful tools that only work on standard formats like PNG and JPEG,
> thus throwing away all the human-centuries of engineering and wisdom that went
> into those standards simply because we believe we're more clever than anyone
> else and can exist in a vacuum and don't need all those steenkeen' free, useful
> tools.
>

this is missing the point. to write ones' own code is not the same as to 
forsake using an existing standardized file format.


I do use a lot of standardized formats, just I often feel little need to 
use others' implementations of those formats.

for example, I have my own implementations of PNG, JPEG, Deflate, ... 
granted, I didn't really "need" to do so, but often to use a library 
means either creating an annoying external dependency issue, or needing 
to drag around the library, when often one can get by just writing a 
much smaller and more narrowly focused piece of code to deal with it.

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

#11928

On 12-02-10 08:10 PM, BGB wrote:
[ SNIP ]
> 
> this is missing the point. to write ones' own code is not the same as to
> forsake using an existing standardized file format.
> 
> I do use a lot of standardized formats, just I often feel little need to
> use others' implementations of those formats.
> 
> for example, I have my own implementations of PNG, JPEG, Deflate, ...
> granted, I didn't really "need" to do so, but often to use a library
> means either creating an annoying external dependency issue, or needing
> to drag around the library, when often one can get by just writing a
> much smaller and more narrowly focused piece of code to deal with it.
> 
Apart from a situation where you are genuinely resource-constrained and
need to slim down the library in question [1], I don't see those factors
as justifying the effort. "External dependency"? You've already got one
- you depend on the file format specification. So would you rather spend
the (usually substantial) time understanding the spec and implementing
the format, or have other folks do it for you?

And "drag around the library"? Who are you kidding? Look at the size of
libtiff libraries on a typical Linux or Unix system, and then look at
the supported API: you think the library is bloated? You think the
effort is justified to understand the TIFF spec well enough to pick out
just the bits you need, so you can build your own library? Or look at
the Javadoc API for iText 5.1.3: http://api.itextpdf.com/itext/. You
think the 1.6 MB size of the core iText JAR is so indefensible that it's
worth your time to understand the PDF spec well enough to write your own
library for just the bits you need?

It's possible a few times in your career to adopt a new file format so
early that nobody else has a decent library for it. Or the only decent
ones are commercial, as another possibility. This is quite rare, though.

AHS

1. Possible, I suppose, if someone is asking you to do miracles with a
dinky low-end microcontroller.
-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

#11932

On 2/10/2012 7:08 PM, Arved Sandstrom wrote:
> On 12-02-10 08:10 PM, BGB wrote:
> [ SNIP ]
>>
>> this is missing the point. to write ones' own code is not the same as to
>> forsake using an existing standardized file format.
>>
>> I do use a lot of standardized formats, just I often feel little need to
>> use others' implementations of those formats.
>>
>> for example, I have my own implementations of PNG, JPEG, Deflate, ...
>> granted, I didn't really "need" to do so, but often to use a library
>> means either creating an annoying external dependency issue, or needing
>> to drag around the library, when often one can get by just writing a
>> much smaller and more narrowly focused piece of code to deal with it.
>>
> Apart from a situation where you are genuinely resource-constrained and
> need to slim down the library in question [1], I don't see those factors
> as justifying the effort. "External dependency"? You've already got one
> - you depend on the file format specification. So would you rather spend
> the (usually substantial) time understanding the spec and implementing
> the format, or have other folks do it for you?
>

it depends some...

but, anyways, depending on the format is not a dependency, since the 
code doesn't care about the format spec. maybe the programmer does when 
they implement it, but this doesn't matter for the program.


what is a dependency is whether or not the library exists on the user's 
system. if one needs a library, and it is not there already, well then, 
the app isn't going to work (hence why one would end up having to bundle 
such libraries with the app, ...).


the main issue is also copy/pasting around a bunch of extra source-code, 
and dealing with making sure it all builds, some of which may have 
annoying legal terms if used this way: worse if it is GPL (though GPL is 
generally annoying all around in these regards). some other libraries 
have requirements that one mention the library and its authors in the 
credits, ...


in the case of JPEG, it was more effort probably to skim through the 
spec than write the code to load/save the format (mostly because the 
JPEG spec is overly long-winded, and most of its relevant contents could 
be probably boiled down to a few pages).

the only real difficult part of PNG is Deflate (yes, also handled by 
zlib or similar, if one wants to worry about it).

it might be a little easier to "sell" someone on using all of these 
libraries if they were all aggregated into a single library (much like 
"libavcodec" in the case of audio/video codecs).


> And "drag around the library"? Who are you kidding? Look at the size of
> libtiff libraries on a typical Linux or Unix system, and then look at
> the supported API: you think the library is bloated? You think the
> effort is justified to understand the TIFF spec well enough to pick out
> just the bits you need, so you can build your own library? Or look at
> the Javadoc API for iText 5.1.3: http://api.itextpdf.com/itext/. You
> think the 1.6 MB size of the core iText JAR is so indefensible that it's
> worth your time to understand the PDF spec well enough to write your own
> library for just the bits you need?
>

TIFF: not sure why someone would want TIFF support in the first place, 
so no really comment here. apparently it is mostly for people who want 
48 bit color depth or something.

I have not considered PDF loading or saving (not terribly relevant in my 
case).

an LWO loader might be nice, given I haven't gotten around to writing 
one yet (but, the observant may notice: even if a 3rd party LWO loader 
was used, it wouldn't probably load into the mesh-format my engine uses 
already, making it essentially pointless). not that it really matters: 
if I really cared much about LWO, I probably would have had a loader for 
it already.


> It's possible a few times in your career to adopt a new file format so
> early that nobody else has a decent library for it. Or the only decent
> ones are commercial, as another possibility. This is quite rare, though.
>

or, one might develop their own file-formats as well, without being 
chained to the cult of "does a library already exist for that?..."


another power of writing ones' own code is that there is control over 
what is done and why. with a 3rd party library, one may be stuck with 
whatever way *they* chose to do something, impeding ones' own freedom to 
do it differently and to try out alternate possibilities.


more so, writing code is fairly cheap.

but, anyways, most of the stuff where people are worrying about writing 
code oneself, is typically in regards to trivia.

what is there to really to gain from doing all of the hard parts of app 
development, by actually writing the app, but then spending inordinate 
time worrying about not re-implementing functionality which exists in 
libraries.


probably, if a typical programmer can go read a spec for a file format, 
throw something together, and have everything working ok in maybe a few 
hours or so, what really is the problem? it could very well end up being 
more time and effort working out differences between the library's API 
and however the app does things internally.

it may even be the case that using the library would end up with one 
writing more code than just doing it oneself more directly...


but, whatever, people can try to micro-optimize their productivity or 
whatever if they want (ultimately, so long as one does stuff and gets 
stuff done, it is probably good enough regardless of whether or not it 
is the "most efficient" regarding programmer-time or whatever...).

doesn't hurt programmers too much, given it gives something to do, 
especially if one is being paid by the hour, or by the kloc (arguably, 
it is a win-win situation, either way the employer gets code, and the 
employee gets money).

then one is all on the job, "keeping it real" and "doing their thing" 
and similar.


> AHS
>
> 1. Possible, I suppose, if someone is asking you to do miracles with a
> dinky low-end microcontroller.

mostly it is about writing 3D engines for desktop PCs which work on both 
Windows and Linux (though Windows is the much higher priority).

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

#11934

On 12-02-11 03:49 AM, BGB wrote:
> On 2/10/2012 7:08 PM, Arved Sandstrom wrote:
>> On 12-02-10 08:10 PM, BGB wrote:
>> [ SNIP ]
>>>
>>> this is missing the point. to write ones' own code is not the same as to
>>> forsake using an existing standardized file format.
>>>
>>> I do use a lot of standardized formats, just I often feel little need to
>>> use others' implementations of those formats.
>>>
>>> for example, I have my own implementations of PNG, JPEG, Deflate, ...
>>> granted, I didn't really "need" to do so, but often to use a library
>>> means either creating an annoying external dependency issue, or needing
>>> to drag around the library, when often one can get by just writing a
>>> much smaller and more narrowly focused piece of code to deal with it.
>>>
>> Apart from a situation where you are genuinely resource-constrained and
>> need to slim down the library in question [1], I don't see those factors
>> as justifying the effort. "External dependency"? You've already got one
>> - you depend on the file format specification. So would you rather spend
>> the (usually substantial) time understanding the spec and implementing
>> the format, or have other folks do it for you?
> 
> it depends some...
> 
> but, anyways, depending on the format is not a dependency, since the
> code doesn't care about the format spec. maybe the programmer does when
> they implement it, but this doesn't matter for the program.

There are different types of dependencies. Which ones matter more? If
you are contractually bound to implement a given specification, I
guarantee you that except for the most trivial specs that you will spend
more time understanding the requirements than you will coding them up.
I'd call that a real dependency.

But I get that you mean only compile/link implementation dependencies. OK.

> what is a dependency is whether or not the library exists on the user's
> system. if one needs a library, and it is not there already, well then,
> the app isn't going to work (hence why one would end up having to bundle
> such libraries with the app, ...).

Sure. Or at a higher level if it's a managed or interpreted program,
does the user have the runtime or interpreter at all, let alone a
correct version. Your most elegant and compact program might be a Python
or Ruby or Windows Powershell script, but if the target user can't run
it, what's the point?

This is universal though. Like in the examples above, does the target
user have the right interpreters? If running C# or Java, do they have a
sufficiently recent runtime? Are the right versions of framework
libraries present? For C or C++ similar: what libraries exist? Do you
provide them yourself, or link them in? Do you go the GNU build route
and support only configure scripts and building from source? For Java or
C#, if using 3rd party libraries, how do you handle that? For
build/install mechanisms that support downloading of dependencies, like
Perl CPAN or Maven/Ivy or whatever, you have to configure all that.
Maybe you spend quality time configuring up a NSIS installer for
Windows, or a Mac OS X .pkg for use by Installer.

In the big scheme of things you've got enough effort devoted to all this
that I don't myself see how making use of a good 3rd party library
should be questioned...*for the reasons you are thinking of*. I can
certainly think of good reasons why a team would, and should, want to
debate the selection of a _given_ 3rd party library, but not because you
think it'll overly complicate your deployments.

> the main issue is also copy/pasting around a bunch of extra source-code,
> and dealing with making sure it all builds, some of which may have
> annoying legal terms if used this way: worse if it is GPL (though GPL is
> generally annoying all around in these regards). some other libraries
> have requirements that one mention the library and its authors in the
> credits, ...

Copying/pasting? !!! Annoying legal terms? !!! Mentioning folks in
credits? !!!

To borrow from Monday Night Football, "C'mon Man!" OK, granted, legal
requirements attached to candidate 3rd party libraries can be a blocker
(or a difficulty) when dealing with commercial software, but overall
this is quibbling. These are reasons you manufacture when you want to
roll your own code and won't be dissuaded.

> in the case of JPEG, it was more effort probably to skim through the
> spec than write the code to load/save the format (mostly because the
> JPEG spec is overly long-winded, and most of its relevant contents could
> be probably boiled down to a few pages).

Who cares about the quality of the spec? They are what they are. You
have to deal with them as is. Most of the W3C specs are way more turgid
and confusing than the image file format specs. Point being, you had to
read some of the spec - at *some point* - in order to load/save a legal
version of a JPEG file. That's my point: *someone* has to read and
understand as much of a spec as is needed to accomplish Task X, and why
would you want to do that if someone else did it for you?

I just glanced at the JPEG/JFIF and JPEG/EXIF file format specs, and I
gotta tell you, if you think that either of those are overly long-winded
then you haven't read very many specs. And "relevant contents...boiled
down to a few pages"??? Relevant to whom? You? There are other people
who use these file formats, and they may be interested in supporting
most or all of the spec. It sounds like to me that you know that *your*
JPEGs are a consistent small slice of the spec, and you want to write
code that only supports the BGB JPEG subset.

Good luck to the maintainers of your code after you leave.

[ SNIP ]

>> And "drag around the library"? Who are you kidding? Look at the size of
>> libtiff libraries on a typical Linux or Unix system, and then look at
>> the supported API: you think the library is bloated? You think the
>> effort is justified to understand the TIFF spec well enough to pick out
>> just the bits you need, so you can build your own library? Or look at
>> the Javadoc API for iText 5.1.3: http://api.itextpdf.com/itext/. You
>> think the 1.6 MB size of the core iText JAR is so indefensible that it's
>> worth your time to understand the PDF spec well enough to write your own
>> library for just the bits you need?
> 
> TIFF: not sure why someone would want TIFF support in the first place,
> so no really comment here. apparently it is mostly for people who want
> 48 bit color depth or something.

Bit parochial, aren't we? TIFF usage is quite huge actually, in scads of
domains...but maybe not in your little niche. And it's got nothing to do
with 48 bit colour depth.

I happen to encounter TIFF a great deal, and it's almost always B/W or
grayscale when *I* do. But certain advantages of TIFF also carry over to
colour.

> I have not considered PDF loading or saving (not terribly relevant in my
> case).

Maybe it's not. JPEG support isn't particularly relevant to me. Point
being, if you did have to support programmatic creation or editing or
reading/display of PDFs, would you roll your own code? In 2012? That
would be insane.

[ SNIP ]

>> It's possible a few times in your career to adopt a new file format so
>> early that nobody else has a decent library for it. Or the only decent
>> ones are commercial, as another possibility. This is quite rare, though.
> 
> or, one might develop their own file-formats as well, without being
> chained to the cult of "does a library already exist for that?..."

I have no intrinsic problem with that first bit. I like well-designed
file formats, and I've concocted a few of my own. A custom file format
can be the best thing to do as part of a solution.

I don't quite see how the first statement leads to the second, the one
about cults. I fully agree that if someone picked an unsuitable file
format simply because it had a library to accompany it, that that would
be questionable. But you're advancing a stronger argument, that even
when you've selected a suitable file format that does have a suitable
library, that you'd often prefer to dispense with the library, and write
your own code.

> another power of writing ones' own code is that there is control over
> what is done and why. with a 3rd party library, one may be stuck with
> whatever way *they* chose to do something, impeding ones' own freedom to
> do it differently and to try out alternate possibilities.

Is that a problem with libjpeg, say? You are free to use what source you
like from that codebase, make whatever changes you like, and
redistribute commercially without paying royalties. All you have to do
is assume blame and credit the original authors. Big deal.

Unless you think that their codebase is utter garbage then why not just
modify it?

> more so, writing code is fairly cheap.

It is? How much do you get paid? You work for a company? What's their
overhead for keeping you on the books? Are you involved in services
work? What's the cost to the client of spending unnecessary extra time
in coding? Or do you produce product? What's the cost to the end user of
unnecessary extra coding time?

Do you subject the code to testing? Do you write developer and end user
documentation for it? Does *someone*?

It's new code, a brand new burden for maintenance programmers. Do you
factor in the cost of their time, down the road?

Coding ain't cheap. Not even relatively.

> but, anyways, most of the stuff where people are worrying about writing
> code oneself, is typically in regards to trivia.

??? I don't get that.

> what is there to really to gain from doing all of the hard parts of app
> development, by actually writing the app, but then spending inordinate
> time worrying about not re-implementing functionality which exists in
> libraries.
> 
> probably, if a typical programmer can go read a spec for a file format,
> throw something together, and have everything working ok in maybe a few
> hours or so, what really is the problem? it could very well end up being
> more time and effort working out differences between the library's API
> and however the app does things internally.

What kind of file format are we talking about here? It's got to be
pretty twinky if someone can read the spec for it, *and* "throw
something together", *and* having it working "OK", all in a few hours.

What's "OK", anyways? You certainly didn't allow for a whole bunch of
time there to write comprehensive unit tests for the "something".

> it may even be the case that using the library would end up with one
> writing more code than just doing it oneself more directly...

Let's be real, one can always identify trivial cases where that's true,
but it's not a solid argument for the general case.

> but, whatever, people can try to micro-optimize their productivity or
> whatever if they want (ultimately, so long as one does stuff and gets
> stuff done, it is probably good enough regardless of whether or not it
> is the "most efficient" regarding programmer-time or whatever...).

You've mentioned "good enough" a few times in your posting history. It's
a venerable engineering concept, and can be carried over (_has been_
carried over) to software development.

Let's be clear: "good enough" in software development means [1] that the
product has sufficient benefits, has *no* critical problems, the
benefits sufficiently outweigh the problems, and further improvement is
more harmful than helpful.

In other words, "good enough" means that anything you consider doing has
an inadequate return on investment of time and money.

This is a pretty high bar, actually. It doesn't mean what most
developers seem to think it means. And I'm not convinced that your
development philosophy falls in line with "good enough".

> doesn't hurt programmers too much, given it gives something to do,
> especially if one is being paid by the hour, or by the kloc (arguably,
> it is a win-win situation, either way the employer gets code, and the
> employee gets money).

Doesn't help the client/consumer much, does it? We're all professional
developers here, aren't we? Don't they still matter?

> then one is all on the job, "keeping it real" and "doing their thing"
> and similar.
> 
>> AHS
>>
>> 1. Possible, I suppose, if someone is asking you to do miracles with a
>> dinky low-end microcontroller.
> 
> mostly it is about writing 3D engines for desktop PCs which work on both
> Windows and Linux (though Windows is the much higher priority).

Desktop PCs: d'you think you're hurting for resources on a typical
desktop PC these days?

AHS

1. See http://www.satisfice.com/articles/good_enough_quality.pdf

-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

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

#11940

On 2/10/2012 4:15 PM, Lew wrote:
> BGB wrote:
>> yes, but this thread is also about cross-language message passing, one
>> may have to face the issue that, at least one end, will not be using Java.
>>
>> this means, of course, that both ends will need to be able to deal with
>> both sending and receiving the data.
>
> This is the use case for which XML with schema excels. It is very nearly ideal
> for the purpose. XML is semantically void with respect to the problem domain,
> schemas provide a reliable contract for interpretation of the messages, they
> provide a convenient human-readable format to ensure agreement by all
> stakeholders, the drive the easy-to-use tools for XML-based message passing,
> and such easy-to-use tools are abundantly available for every major platform
> and computer language.
>
> Your comments about different libraries' availability makes an asset sound like
> a problem. It's a *good* thing that there are so many libraries available. XML
> itself provides the compatibility.

Multiple libraries for same language each available on all platforms is
a good thing.

But he was talking about multiple libraries for same language
one for each platform, which is bad.

The good thing is that the particular example mentioned in
a previous posts does not apply as LIBXML2 is available for
both platforms.

Arne

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

#11939

On 2/10/2012 12:43 PM, BGB wrote:
> On 2/10/2012 9:51 AM, Lew wrote:
>> BGB wrote:
>>> if one is using C, then it is either "write some code to do it", or
>>> suffer with a 3rd party [sic] library dependency (one might validly
>>> choose to
>>> write the code themselves in this case).
>>
>> "Suffer"? The XML parsers for C are well-established, very reliable,
>> and no
>> cause for suffering. Using a pejorative is not the same as establishing a
>> point.
>>
>> There is nothing wrong with the third-party libraries, and the choice to
>> roll your own for C is rarely valid. You seem to suffer from NIH
>> syndrome.
>>
>
> they introduce porting hassles:
> does one bundle "libxml" with their app on Windows;
> do they use MSXML and then deal with having to switch over to "libxml"
> when building on Linux?

LIBXML2 works fine on Windows, so you can use it on both platforms.

> but, anyways, it is like asking a person never to write their own JPEG
> loader/saver, or their own scripting-language compiler. yes, maybe a
> person doesn't technically need to, but they may forsake potentially
> valuable learning experiences (or the claim to having the skills to do so).

I think you should very clearly distinguish between when you talk about
learning and programming production code.

The goals are just so different.

Arne

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

#11957

On 2/11/2012 12:52 PM, Arne Vajhøj wrote:
> On 2/10/2012 12:43 PM, BGB wrote:
>> On 2/10/2012 9:51 AM, Lew wrote:
>>> BGB wrote:
>>>> if one is using C, then it is either "write some code to do it", or
>>>> suffer with a 3rd party [sic] library dependency (one might validly
>>>> choose to
>>>> write the code themselves in this case).
>>>
>>> "Suffer"? The XML parsers for C are well-established, very reliable,
>>> and no
>>> cause for suffering. Using a pejorative is not the same as
>>> establishing a
>>> point.
>>>
>>> There is nothing wrong with the third-party libraries, and the choice to
>>> roll your own for C is rarely valid. You seem to suffer from NIH
>>> syndrome.
>>>
>>
>> they introduce porting hassles:
>> does one bundle "libxml" with their app on Windows;
>> do they use MSXML and then deal with having to switch over to "libxml"
>> when building on Linux?
>
> LIBXML2 works fine on Windows, so you can use it on both platforms.
>

yeah, it is an option.
however, it is not a standard library on Windows (in certain cases, one 
may need to provide for it, or expect anyone who wants to build from 
source to provide for it, ...).


>> but, anyways, it is like asking a person never to write their own JPEG
>> loader/saver, or their own scripting-language compiler. yes, maybe a
>> person doesn't technically need to, but they may forsake potentially
>> valuable learning experiences (or the claim to having the skills to do
>> so).
>
> I think you should very clearly distinguish between when you talk about
> learning and programming production code.
>
> The goals are just so different.
>

in my case, both often end up being the same code.

one may end up doing something initially as a learning activity, but if 
one does so, and the code works fairly well, why write the same code 
again?...

granted, being a programmer working for a corporation or something, vs 
being an independent game developer, could also be a factor.

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

#11958

On 2/11/2012 10:06 PM, BGB wrote:
> On 2/11/2012 12:52 PM, Arne Vajhøj wrote:
>> On 2/10/2012 12:43 PM, BGB wrote:
>>> On 2/10/2012 9:51 AM, Lew wrote:
>>>> BGB wrote:
>>>>> if one is using C, then it is either "write some code to do it", or
>>>>> suffer with a 3rd party [sic] library dependency (one might validly
>>>>> choose to
>>>>> write the code themselves in this case).
>>>>
>>>> "Suffer"? The XML parsers for C are well-established, very reliable,
>>>> and no
>>>> cause for suffering. Using a pejorative is not the same as
>>>> establishing a
>>>> point.
>>>>
>>>> There is nothing wrong with the third-party libraries, and the
>>>> choice to
>>>> roll your own for C is rarely valid. You seem to suffer from NIH
>>>> syndrome.
>>>>
>>>
>>> they introduce porting hassles:
>>> does one bundle "libxml" with their app on Windows;
>>> do they use MSXML and then deal with having to switch over to "libxml"
>>> when building on Linux?
>>
>> LIBXML2 works fine on Windows, so you can use it on both platforms.
>>
>
> yeah, it is an option.
> however, it is not a standard library on Windows (in certain cases, one
> may need to provide for it, or expect anyone who wants to build from
> source to provide for it, ...).

C is not standard on Windows either.

You need to get some things.

>>> but, anyways, it is like asking a person never to write their own JPEG
>>> loader/saver, or their own scripting-language compiler. yes, maybe a
>>> person doesn't technically need to, but they may forsake potentially
>>> valuable learning experiences (or the claim to having the skills to do
>>> so).
>>
>> I think you should very clearly distinguish between when you talk about
>> learning and programming production code.
>>
>> The goals are just so different.
>>
>
> in my case, both often end up being the same code.
>
> one may end up doing something initially as a learning activity, but if
> one does so, and the code works fairly well, why write the same code
> again?...

Because what you learn the most from and what is most cost efficient for
the company may very well be two different things.

Arne

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

#11968

On 2/11/2012 8:41 PM, Arne Vajhøj wrote:
> On 2/11/2012 10:06 PM, BGB wrote:
>> On 2/11/2012 12:52 PM, Arne Vajhøj wrote:
>>> On 2/10/2012 12:43 PM, BGB wrote:
>>>> On 2/10/2012 9:51 AM, Lew wrote:
>>>>> BGB wrote:
>>>>>> if one is using C, then it is either "write some code to do it", or
>>>>>> suffer with a 3rd party [sic] library dependency (one might validly
>>>>>> choose to
>>>>>> write the code themselves in this case).
>>>>>
>>>>> "Suffer"? The XML parsers for C are well-established, very reliable,
>>>>> and no
>>>>> cause for suffering. Using a pejorative is not the same as
>>>>> establishing a
>>>>> point.
>>>>>
>>>>> There is nothing wrong with the third-party libraries, and the
>>>>> choice to
>>>>> roll your own for C is rarely valid. You seem to suffer from NIH
>>>>> syndrome.
>>>>>
>>>>
>>>> they introduce porting hassles:
>>>> does one bundle "libxml" with their app on Windows;
>>>> do they use MSXML and then deal with having to switch over to "libxml"
>>>> when building on Linux?
>>>
>>> LIBXML2 works fine on Windows, so you can use it on both platforms.
>>>
>>
>> yeah, it is an option.
>> however, it is not a standard library on Windows (in certain cases, one
>> may need to provide for it, or expect anyone who wants to build from
>> source to provide for it, ...).
>
> C is not standard on Windows either.
>
> You need to get some things.
>

probably, but it is a question of how many things have to be worried 
about as a part of getting it built (for someone wanting to rebuild from 
source). if a program depends on a big pile of 3rd party libraries, it 
may be harder to get rebuilt than if it doesn't.

it is arguably bad enough requiring that a particular C compiler be 
installed (such as MSVC / Windows SDK), and that the program has to be 
built in a certain way.

expecting the person to go download a bunch of libraries, get them 
built, and put them all in the library and include paths, well, this is 
adding a bit more to the cost.

this particular cost is a bit lower on Linux though, since 3rd party 
libraries are more commonly available and are handled more gracefully 
(nearly everything gets installed to "/usr/lib" and "/usr/include" and 
similar).


alternatively, one could be like:
this app needs to be built in Cygwin.

the tradeoff though is that Cygwin has its own annoyances (needing to 
have their DLL with compiled binaries, and the tendency for it to always 
have a console window pop up for the app if it wasn't launched from a 
console).

MinGW is a little nicer than Cygwin regarding the above, however it 
doesn't come by default with a large pile of 3rd party libraries (so, it 
has the same basic issue here as MSVC).


it is not that I haven't used any 3rd party libraries though, as a few 
have been used, but essentially copied into the project. a few past 
libraries were used, but later dropped since I had re-implemented their 
functionality in smaller forms.


this avoids needing them as external dependencies, since then they are 
built along with the application (then they are internal dependencies).

yeah, even within the same program, the matter of "what is allowed to 
use and depend on what" can become its own issue (if one doesn't pay 
attention to these internal dependencies, they may come around and bite).



>>>> but, anyways, it is like asking a person never to write their own JPEG
>>>> loader/saver, or their own scripting-language compiler. yes, maybe a
>>>> person doesn't technically need to, but they may forsake potentially
>>>> valuable learning experiences (or the claim to having the skills to do
>>>> so).
>>>
>>> I think you should very clearly distinguish between when you talk about
>>> learning and programming production code.
>>>
>>> The goals are just so different.
>>>
>>
>> in my case, both often end up being the same code.
>>
>> one may end up doing something initially as a learning activity, but if
>> one does so, and the code works fairly well, why write the same code
>> again?...
>
> Because what you learn the most from and what is most cost efficient for
> the company may very well be two different things.
>

well, it is possible.


often it ends up with a cycle where something is implemented once (or 
maybe a few times), and very often if something similar is needed later, 
code is reused via "copy/paste/edit" magic.

in my case though, admittedly I am not actually employed as a 
programmer, but am more of a college student + independent game 
developer (mostly working on a 3D FPS style game). like, one has to 
"face the impossible" and so on (and, with luck, getting something on 
the market and getting enough money to live on, and trying to make newer 
and better stuff, ...).


admittedly, a person who was notable influence for me was John Carmack, 
who was the lead programmer for id Software, and was well known for the 
Doom and Quake series games. I learned a fair amount from his code 
(since he tends to release it all under the GPL).

others influences include Linus Torvalds (who created Linux) and Notch 
(Marcus Persson, most well known for creating Minecraft). the Linux 
kernel was a notable influence on me regarding things like program 
architecture and similar.


in my case this also means dealing with with the all art, sound, music, 
... as well, so one tries to gain skills both as a programmer and as an 
artist. I consider myself to be much more of a programmer than an artist 
though (I started out programming, and the art can't do much without the 
code).

there is still a lot of areas for learning and experimentation though.


or such...

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

#11976

On 2/12/2012 2:46 AM, BGB wrote:
> On 2/11/2012 8:41 PM, Arne Vajhøj wrote:
>> On 2/11/2012 10:06 PM, BGB wrote:
>>> On 2/11/2012 12:52 PM, Arne Vajhøj wrote:
>>>> On 2/10/2012 12:43 PM, BGB wrote:
>>>>> On 2/10/2012 9:51 AM, Lew wrote:
>>>>>> BGB wrote:
>>>>>>> if one is using C, then it is either "write some code to do it", or
>>>>>>> suffer with a 3rd party [sic] library dependency (one might validly
>>>>>>> choose to
>>>>>>> write the code themselves in this case).
>>>>>>
>>>>>> "Suffer"? The XML parsers for C are well-established, very reliable,
>>>>>> and no
>>>>>> cause for suffering. Using a pejorative is not the same as
>>>>>> establishing a
>>>>>> point.
>>>>>>
>>>>>> There is nothing wrong with the third-party libraries, and the
>>>>>> choice to
>>>>>> roll your own for C is rarely valid. You seem to suffer from NIH
>>>>>> syndrome.
>>>>>>
>>>>>
>>>>> they introduce porting hassles:
>>>>> does one bundle "libxml" with their app on Windows;
>>>>> do they use MSXML and then deal with having to switch over to "libxml"
>>>>> when building on Linux?
>>>>
>>>> LIBXML2 works fine on Windows, so you can use it on both platforms.
>>>>
>>>
>>> yeah, it is an option.
>>> however, it is not a standard library on Windows (in certain cases, one
>>> may need to provide for it, or expect anyone who wants to build from
>>> source to provide for it, ...).
>>
>> C is not standard on Windows either.
>>
>> You need to get some things.
>
> probably, but it is a question of how many things have to be worried
> about as a part of getting it built (for someone wanting to rebuild from
> source). if a program depends on a big pile of 3rd party libraries, it
> may be harder to get rebuilt than if it doesn't.
>
> it is arguably bad enough requiring that a particular C compiler be
> installed (such as MSVC / Windows SDK), and that the program has to be
> built in a certain way.
>
> expecting the person to go download a bunch of libraries, get them
> built, and put them all in the library and include paths, well, this is
> adding a bit more to the cost.

You could (and probably should) checkin the libs used with
your source code!

No problems getting anything.

Arne

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

#11977

On 2/12/2012 2:46 AM, BGB wrote:
> On 2/11/2012 8:41 PM, Arne Vajhøj wrote:
>> On 2/11/2012 10:06 PM, BGB wrote:
>>> On 2/11/2012 12:52 PM, Arne Vajhøj wrote:
>>>> On 2/10/2012 12:43 PM, BGB wrote:
>>>>> but, anyways, it is like asking a person never to write their own JPEG
>>>>> loader/saver, or their own scripting-language compiler. yes, maybe a
>>>>> person doesn't technically need to, but they may forsake potentially
>>>>> valuable learning experiences (or the claim to having the skills to do
>>>>> so).
>>>>
>>>> I think you should very clearly distinguish between when you talk about
>>>> learning and programming production code.
>>>>
>>>> The goals are just so different.
>>>>
>>>
>>> in my case, both often end up being the same code.
>>>
>>> one may end up doing something initially as a learning activity, but if
>>> one does so, and the code works fairly well, why write the same code
>>> again?...
>>
>> Because what you learn the most from and what is most cost efficient for
>> the company may very well be two different things.
>>
>
> well, it is possible.
>
> often it ends up with a cycle where something is implemented once (or
> maybe a few times), and very often if something similar is needed later,
> code is reused via "copy/paste/edit" magic.
>
> in my case though, admittedly I am not actually employed as a
> programmer, but am more of a college student + independent game
> developer (mostly working on a 3D FPS style game). like, one has to
> "face the impossible" and so on (and, with luck, getting something on
> the market and getting enough money to live on, and trying to make newer
> and better stuff, ...).

That is all fine.

But many of your conclusions does not fit with a more traditional
developer job.

Arne

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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

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

csiph-web