Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #11934
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: Interplatform (interprocess, interlanguage) communication |
| References | (16 earlier) <jh43hj$oa8$1@news.albasani.net> <31853844.362.1328913143289.JavaMail.geo-discussion-forums@pbne9> <jh4bn6$89h$1@news.albasani.net> <J4kZq.4545$xH4.1983@newsfe19.iad> <jh56jr$c38$1@news.albasani.net> |
| Message-ID | <L4yZq.13248$EF2.3703@newsfe18.iad> (permalink) |
| Organization | Public Usenet Newsgroup Access |
| Date | 2012-02-11 14:04 -0400 |
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
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web