3 ms·

i.thumbnail([220, 133], Image.BICUBIC) Having everyone rewrite those 100 lines is really inexcusable. Throwing in a few convenience functions to make the commo

by paul 19y ago

i.thumbnail([220, 133], Image.BICUBIC) Having everyone rewrite those 100 lines is really inexcusable. Throwing in a few convenience functions to make the common case simple would not detract from the "flexibility" one bit. It shows that they gave zero thought to what people will actually do with the library. BTW, want to take a stab at writing the "save at different quality level" code? (since you don't mind writing lots of code) You can post your solution here.

aston 19y ago
I didn't mean to detract from your original point. I think you're right, it's good to have good libraries. I was just pointing out that there are some advantages to the way Java normally works. Anyway, as Java's such a popular language, you can get away with copying other people's 100 lines if you really need to. A quick Google search turned up an image scaler outright. By the way, I think it's kind of unfair for you to link to the interface definitions rather than some implementation for Java. java.awt.Image is probably just as inscrutable, but at least it does something. edit: While I'm at it, one point that I didn't quite make clear, but should be noted is that Image in Java is used all over the place, so its interface is going to be pretty much targeted at not missing any possible use case. If you're interested in a narrow-scoped pixel image application, why not use some Java image processing library? Sun's got one: http://java.sun.com/javase/technologies/desktop/media/jai/ http://java.sun.com/javase/technologies/desktop/media/jai/
- bootload 19y ago
  '... you can get away with copying other people's 100 lines if you really need to ...' Owch! that will come back to bite you. Wouldn't it be better to re-write, re-factor to reduce complexity and get cleaner code? '... think it's kind of unfair for you to link to the interface definitions rather than some implementation ...' because it's the interface that we are stuck with & have to work with '... If you're interested in a narrow-scoped pixel image application, why not use some Java image processing library? ...' because it's not COSHER & I do not want to be locked into using non-free software ~ http://wearcam.org/cosher.htm http://wearcam.org/cosher.htm
  - aston 19y ago
    "because it's the interface that we are stuck with & have to work with" is blatantly wrong. You can use anything you want to manipulate images; don't feel bound to using the standard Java Image class. To my knowledge, there's no standard python image class, so there's not even a comparison here. As to your other points, I'm not sure why you assume copying code leads to that code being bloated or unclean. Bad assumption. Personal preference on the latter point, though it's pretty easy to find open sourced libraries.
    - bootload 19y ago
      "... I'm not sure why you assume copying code leads to that code being bloated or unclean ..." DEFECTS if you cut+paste code from place to place and find a single defect in the block you have to go and find all the other instances you have pasted the code. BLOAT If you cut+paste code it increases the number of lines of code within the codebase so the LOC increases. Software development within a startup context is about creating code that is "reliable, smaller, cleaner & faster". Reusing code is good but not at the expense of modularity, bloat and defects. Not using cut & paste as a development practice isn't personal preference, its DEV 101 ~ http://en.wikipedia.org/wiki/Copy_and_paste_programming http://en.wikipedia.org/wiki/Copy_and_paste_programming
- ralph 19y ago
  Anyway, as Java's such a popular language, you can get away with copying other people's 100 lines if you really need to. A quick Google search turned up an image scaler outright. You'd be copying its bugs too. And you wouldn't pick up any future bug fixes automatically. Copying lines of source like this is cut-and-paste programming, rife in MS-shops everywhere.
  - aston 19y ago
    That's a pretty pessimistic view of code copying. I don't know why there'd inherently be bugs in a decently simple chunk of code. And we're not talking about a huge system, so whether you catch bug fixes is irrelevant. Code copying is pretty much a standard thing. I don't know why everyone's hating on it so much. The Ruby on Rails community has pretty much built itself on code copying...
    - ralph 19y ago
      That's a pretty pessimistic view of code copying. There's real-world experience for you. I don't know why there'd inherently be bugs in a decently simple chunk of code. There's often bugs, especially if the language or API is unwieldy and getting in the way of expressing the aim. Look at how easy it is to write an incorrect binary search of an array. Then there's common "off by one" or "fence post" errors. And people copy one line to a line below but only change one of the two things that need changing. And we're not talking about a huge system, so whether you catch bug fixes is irrelevant. Paul's estimating 100 lines. You don't want to have to be detecting bugs, let alone fixing them, in someone elses code of that size if the well-tested, not grabbed off the Internet, library provides a routine to do it for you. If there's a bug in PIL then everyone will get the fix on the next release, not so for a copy-and-paste code. Code copying is pretty much a standard thing. Yes, there's much wrong with coding practices today. I don't know why everyone's hating on it so much. We've seen the outcome. We've maintained systems where people were doing this twenty years ago and the problems it caused then are still being created today. The Ruby on Rails community has pretty much built itself on code copying... Yes. 8-D

by paul 19y ago

aston 19y ago

I didn't mean to detract from your original point. I think you're right, it's good to have good libraries. I was just pointing out that there are some advantages to the way Java normally works. Anyway, as Java's such a popular language, you can get away with copying other people's 100 lines if you really need to. A quick Google search turned up an image scaler outright. By the way, I think it's kind of unfair for you to link to the interface definitions rather than some implementation for Java. java.awt.Image is probably just as inscrutable, but at least it does something. edit: While I'm at it, one point that I didn't quite make clear, but should be noted is that Image in Java is used all over the place, so its interface is going to be pretty much targeted at not missing any possible use case. If you're interested in a narrow-scoped pixel image application, why not use some Java image processing library? Sun's got one: http://java.sun.com/javase/technologies/desktop/media/jai/ http://java.sun.com/javase/technologies/desktop/media/jai/

bootload 19y ago
'... you can get away with copying other people's 100 lines if you really need to ...' Owch! that will come back to bite you. Wouldn't it be better to re-write, re-factor to reduce complexity and get cleaner code? '... think it's kind of unfair for you to link to the interface definitions rather than some implementation ...' because it's the interface that we are stuck with & have to work with '... If you're interested in a narrow-scoped pixel image application, why not use some Java image processing library? ...' because it's not COSHER & I do not want to be locked into using non-free software ~ http://wearcam.org/cosher.htm http://wearcam.org/cosher.htm
- aston 19y ago
  "because it's the interface that we are stuck with & have to work with" is blatantly wrong. You can use anything you want to manipulate images; don't feel bound to using the standard Java Image class. To my knowledge, there's no standard python image class, so there's not even a comparison here. As to your other points, I'm not sure why you assume copying code leads to that code being bloated or unclean. Bad assumption. Personal preference on the latter point, though it's pretty easy to find open sourced libraries.
  - bootload 19y ago
    "... I'm not sure why you assume copying code leads to that code being bloated or unclean ..." DEFECTS if you cut+paste code from place to place and find a single defect in the block you have to go and find all the other instances you have pasted the code. BLOAT If you cut+paste code it increases the number of lines of code within the codebase so the LOC increases. Software development within a startup context is about creating code that is "reliable, smaller, cleaner & faster". Reusing code is good but not at the expense of modularity, bloat and defects. Not using cut & paste as a development practice isn't personal preference, its DEV 101 ~ http://en.wikipedia.org/wiki/Copy_and_paste_programming http://en.wikipedia.org/wiki/Copy_and_paste_programming
ralph 19y ago
Anyway, as Java's such a popular language, you can get away with copying other people's 100 lines if you really need to. A quick Google search turned up an image scaler outright. You'd be copying its bugs too. And you wouldn't pick up any future bug fixes automatically. Copying lines of source like this is cut-and-paste programming, rife in MS-shops everywhere.
- aston 19y ago
  That's a pretty pessimistic view of code copying. I don't know why there'd inherently be bugs in a decently simple chunk of code. And we're not talking about a huge system, so whether you catch bug fixes is irrelevant. Code copying is pretty much a standard thing. I don't know why everyone's hating on it so much. The Ruby on Rails community has pretty much built itself on code copying...
  - ralph 19y ago
    That's a pretty pessimistic view of code copying. There's real-world experience for you. I don't know why there'd inherently be bugs in a decently simple chunk of code. There's often bugs, especially if the language or API is unwieldy and getting in the way of expressing the aim. Look at how easy it is to write an incorrect binary search of an array. Then there's common "off by one" or "fence post" errors. And people copy one line to a line below but only change one of the two things that need changing. And we're not talking about a huge system, so whether you catch bug fixes is irrelevant. Paul's estimating 100 lines. You don't want to have to be detecting bugs, let alone fixing them, in someone elses code of that size if the well-tested, not grabbed off the Internet, library provides a routine to do it for you. If there's a bug in PIL then everyone will get the fix on the next release, not so for a copy-and-paste code. Code copying is pretty much a standard thing. Yes, there's much wrong with coding practices today. I don't know why everyone's hating on it so much. We've seen the outcome. We've maintained systems where people were doing this twenty years ago and the problems it caused then are still being created today. The Ruby on Rails community has pretty much built itself on code copying... Yes. 8-D