Wed, 26 Sep 2007
Beware of Patro.CZ
We have decided to buy a new electric kettle. Because we drink a lot of green tea, we went for a kettle with thermostatic regulation, so that it can switch itself off at 80 degrees Celsius instead of 100. I have used Patro.CZ e-shop many times, but this time it was a really unpleasant experience.
The kettle arrived, but we have soon realized that its thermostat is way off. Using thermometer we have found that when set to 80°C, the water really had around 63°C, and when set to 90°C, the real temperature was at 75°C. The Czech law allows the consumer to send goods from an Internet order back in 14 days with no questions asked (provided that it is not damaged, etc.). So we have decided to sent it back (so far I have not sent anything back to Patro.CZ). Few days ago it has arrived back with the following explanation: "According to our technician, the kettle shows signs of heavy usage". WTF? We have used it maybe up to 20 times, including the temperature measurement, and initial cleaning of the kettle.
In order to save my nerves, I have decided to fix the kettle myself: I have disassembled it, and after tightening a spring inside the temperature is more accurate (it is off by maybe 5°C, which is acceptable). As an additional bonus, I have learned how the kettle looks like in the inside and how it works.
And in order to not let Patro.CZ get out of this case so easily, I wrote this blog post: if you want to order something from them, beware that they may unlawfuly reject your returned goods.
2 replies for this story:
sil wrote: online shops
You have come over many troubles by internet shopping, haven't you? Since I have started to read your blog I have a strange feeling when I want to buy something online...
Yenya wrote:
Oh, not so much - I only write about unsuccessful events. But I had problems with stone shops as well (such as buying an overly expensive fridge of an mid-upper class brand, and having to replace the whole control unit a month after the warranty expired). Or see this (in Czech): http://www.fi.muni.cz/~kas/satron.html. Stone shops are no better.
Reply to this story:
Tue, 25 Sep 2007
Syntax Error in a ... Comment?
A followup to my yesterday's post about object-oriented code in Java. In fact, I have considered entering this year's FIbot competition. The only drawback is that it is in Java. I have tried to compile their sample code, and here is another blog-post on how Java is bad:
[javac] Tile.java:4: unmappable character for encoding UTF8
[javac] * Created on 6. ?ervenec 2007, 18:14
[javac] ^
So even though Java people reinvent their own XML-happy wheel (ant
instead of make - further reading on replacing make here),
they still cannot XML-encode the information
about the charset of source code
into their Makefile-alike. Or better, into the source code
itself (Perl has been doing this for years, you can even use multiple
charsets in different parts of the source file, just notify the parser with
the appropriate "use encoding" pragma).
Anyway, the first language which barfs with a syntax error inside a comment. Talk about brain damage.
The absurdity of the situation is even bigger when you realize that this comment (saying the file creation date in Czech) is one of those superfluous comments, presumably created by some stupid IDE: it does not add any useful information (such an information would be valuable maybe inside a version control system, but not in the source code itself), and it apparently is a syntax error in some locales.
BTW, anybody interested in forming a FIbot team with me? Preferably someone who can tolerate Java.
9 replies for this story:
Milan Zamazal wrote:
Citing from Java language specification (http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.1): "Programs are written using the Unicode character set." I really, really don't understand why: 1. Unicode is insufficient; 2. character set used in the source code should be declared outside the source code file; 3. the character set should be declared at all when it is already specified in the language definition; 4. the parser should accept invalid input.
Yenya wrote:
"Unicode character set" does not specify which one (UTF-8? UTF-7? UTF-16? UCS-32?). ad 1: allowing different character sets inside (different parts of) the source code file increases flexibility. ad 2: I would accept the charset being declared even in the source code file, but even this was not the case. ad 3: it isn't - see above. ad 4: there definitely are _some_ parsers which accepts this input, the parser which the authors of the code presumably use (which I suspect is the official one - JDK). And also "be conservative in what you send, and be liberal in what you accept".
Milan Zamazal wrote:
As for the character coding, see the link I provided. Ad 1: (i) I repeat: I don't understand why Unicode is insufficient; (ii) actually mixing codings within one file is a completely mad idea (why should one do it?? which editor can handle it?? how does such a mess interact with grep and other tools??); ad 4: I don't understand why one should create invalid source code input and then expect the parser to perform guesswork instead of rejecting it. Bashing Java instead of pointing out its real flaws makes no sense.
Yenya wrote:
The link you mentioned says nothing about the actual encoding of the source code (The section 3.1 mentions UTF-16, but not as an requirement for the source code, it merely describes how UTF-16 works). Ad 1: Unicode is sufficient, but sometimes it is easier to do mix charsets inside one file (think generated source code from mixed sources; yes, it _can_ be recoded, but sometimes it is easier (even though grep and friends do not work then). However, this is not relevant to the blog post. Ad 4: Java definitely _is_ stupid for allowing syntax errors inside comments. Either way, it is fault of the authors of the code, or the authors of the reference implementation (which I suppose the authors use) that allows such a faulty code (if it is faulty) to be compiled.
Milan Zamazal wrote:
This is not a syntax error, it's invalid input (input data can't be decoded).
Yenya wrote:
Invalid input counts as a syntax error as well. NB: I have re-read the whole discussion, and discovered that I have forgotten to add an important piece of information: The javac compiler behaviour depends on the LC_CTYPE locale. When I compile the above code with LC_CTYPE=cs_CZ.ISO-8859-2, it compiles the source code correctly. So is the developer's compiler out of spec for accepting non-UTF8 input, or is my compiler out of spec for not accepting it (or for depending on the system locale)? I have always thought the "source code" means something like "a portable and human-readable way of describing the machine instructions". Apparently, in Java it is not the case.
Yenya wrote: Perl
FWIW, perl accepts invalid characters in comments without problem. Which is how it should be. Comment is something that the compiler should not look at.
thingie wrote:
Compiler has to look at comments too. There is no other way to find where they end :-)
wrote:
Well, end-of-comment characters are ASCII (either a newline or a */ sequence), and since UTF-8 is ASCII-compatible, there is no need for a compiler to parse UTF-8 inside the comment.
Reply to this story:
Mon, 24 Sep 2007
Objects Considered Harmful
From time to time I feel a strong urge to write an article describing how object-oriented programming is bad. Well, this post is not a full analysis, just a simple example. I have tried to read some Java code (maybe I am becoming a masochist :-), and found this:
/**
* Get X position.
* Shortcut for getPosition().getX();
*
* @return X position
*/
public int getX() {
return x;
}
It is nine lines (and nine more for Y) so that they can write something like this:
myobj.getX() + myobj.getY();
instead of the following:
myobj.x + myobj.y;
I wonder why some programming languages tend to attract people who like to write mid-layers. Java is probably the worst one, but also Python with its Zope and Plone mammoths, and Ruby with RoR are similar. Wrapping wrapped wrappers into the wrapper code. I have yet to see something like this in Perl (yet OOP is widely used in Perl). I think accessors and mutators are amongst the worst habits in OOP. Most often they are just like the above code - dummy wrappers for the class member variable. Maybe Java people have some sort of mighty IDE, which generates such a write-only garbage for them.
In a related news (related to the mid-layer problem), see this post about trying to use Ruby on Rails (another midlayer-happy framework).
Comming soon on your favourite flamebait channel: Wrapping SQL Database to Objects Considered Harmful. Stay tuned.
15 replies for this story:
Martiner wrote:
Why is setter/getter better than simple public field? Because when you decide that variable must be e.g. greater than zero, you insert single line into the setter instead of changing every assignment into this variable. Yes, Java IDEs have generators for getters/setters garbage.
Yenya wrote:
It _might_ make sense if the code in question was some public library. But in a closed project in which this particular class has exactly zero subclasses, this simply does not make sense. If you really want type checks or whatever, just declare your own type "postitive_integer", and embed this check to its operator= (or whatever it is named in Java). But this kind of trivial mutators/accessors does not make any sense.
Martiner wrote:
It makes no sense for me to have tons of types like positive_integer, integer_bigger_than_100,... You dont believe in encapsulation, but I dont believe that people who write ugly code in "closed project" will write simple, clean and maintainable public API.
Yenya wrote:
The point is that there is no enapsulation in that project: I would tend to agree that having accessor and mutator functions have _some_ value if the accessor or mutator had at least some chance of being non-trivial. But this is not the case. Also, rather than "positive_integer" in this case the type would be something like "coordinate_t". As for the second part of your comment - "but I dont believe ..." - I fail to understand how it is related to this case: there is no public API in this project.
petr_p wrote:
It's about ambitions of your code. If you believe you are the only user and maintainer of the code, you could afford to keep the code as simple as possible (no intermediate layers, no access protection, no type checking, no comments). But if you think somebody could use your code somehow sometimes, it will be better to build solid interface. And OOP provides straight way how to do it. I agree with you that misusing of OOP bloats your code, eats computer resources etc. But that are pros and cons of every middle ware.
thingie wrote:
When you suddenly decide that variable must be greater than zero (something you didn't say before), it's still change of your API. If someone used it with zero, his code will break and getters/setters won't help him much...
Milan Zamazal wrote:
IMHO classes should have no public slots (AKA attributes or fields) and data should be provided only through methods (I usually do it that way). It doesn't matter whether the code is public or private, one should try to write any not-one-time programs in an elegant way, to save his own work. Providing idiotic examples from idiotic languages is no argument. Java is no way anything close to a modern object oriented language, regardless what Sun's marketing claims. And the primary point of using accessors is not only to allow some checks or so, but to hide implementation details from the class. If you ask a class for data, e.g. a person's name, you shouldn't bother whether it's stored in the class instance directly as a slot or whether it is computed from other data, retrieved from the database, etc. You just call person-name function on the class and get the desired data. Nor you should presume the implementation by naming the method get-person-name or so. Civilized languages provide built-in means for using accessors, e.g. you can declare a slot in the following way: (name :accessor person-name). Other languages allow you at least to implement such things yourself, e.g. then you can write a slot definition by something like Slot('name', writable=True) in Python and the corresponding class attribute and accessors get defined automatically. In really stupid languages like Java you have no better choice than to generate a lot of lines of code which may make the whole thing counterproductive. As for amount of types: Of course it is useful to define a lot of custom types. And I guess you do it in OO all the time: Whenever you define new class, you define new type (unless you use the class just as a name space).
Yenya wrote: re: petr_p
You seem to miss my point. I am not against type control (I sometimes think Perl would be better with at least some compile-time type controls), nor comments, etc. What I object against are _trivial_ accessor/mutator pairs. They bring nothing when compared to the direct access to the member variables. They are slower, more expensive to both write and then understand. And they are even surrounded by heavy comments. Superfluous comments are evil as well: comments should be used for explaining hacks or non-trivial usage, not every method and variable. I think readability and maintainability of the code in question would be _way_ better without those trival accessor/mutator pairs and without those trivial comments. With current IDEs it is even trivial to refactorize - to change a direct member variable access to an accessor or mutator method call, _when_ (but not sooner than) you decide you want to do something nontrivial in the mutator or accessor. Interfaces are rarely set in the stone, and any project (not to mention such a small internal class) should be prepared to refactorize, when the need arises. As for building a "solid interface": it is an impossible task. [Almost] nobody is smart enough to see the future and design a perfect interface. But instead of including everything and a kitchen sink in your class, I think it is better to write _some_ interface, and be prepared to write more when it is needed. Java programmers seem to think that because their code is a class, it would be used as such - as a generic all-purpose object. But for many classes it is simply not true. Many classes have no subclass, and not all of the class interface is ever used in the project. And understanding such a project means scrolling through many and many pages, filled with dummy comments and trivial subroutines.
Vašek Stodůlka wrote:
I have been working with two ERP systems. One was object-oriented code on a traditional SQL database and it has a thick client. It is a very bad concept - you do not have access to code, you can manipulate only with database or through client and nobody gives you guarantee, that your interventions to database will not destroy the entire system and the client is usually stupid (our was :). And even when it was object-oriented code, the selling company cannot make changes to tables, because any user or partner code will not work with changed structures and some programs relied on a client too. So when somebody changed something, nobody knew what to do and whose fail is it. Today I work with another ERP system - it has something like object-oriented database and application server (with a text-based protocol, very well documented) and it has an interpreter with language, which is something between basic and assembler. The situation with database changes is similar to above - when a system producing company changes the database (objects), the programs will stop working. But I have error messages from an application server and with these I can repair my code very quickly. And the conclusion is - it does not matter if you use object-oriented or non-object-oriented language. Instead you have to have a good concept (or at least a layer of application server) and a good API / protocol. But maybe this holds only for ERP.
Yenya wrote: Re: Milan Zamazal
I disagree with two of your points: If I understand the first few sentences of your comment, you tend to write a _complete_ interface, instead of a minimal (or as-needed) one. This is hardly about "saving your own work" (and adds an unnecessary bloat the reader of your program has to walk through, just to discover parts of the code are not really used anywhere). The other point I disagree with is when you talk about the need to hide the implementation details: Unless you write a library for a public use (good luck with that anyway, it is _hard_), this is rarely a valid reason. But a local class inside a local project? No way. Usually you know in advance whether this class would have to hide something, for example to allow a different storage of the data. And even if you don't, it is still easier to access the member variable directly, and refactorize later, as needed. In many editors/IDEs it is trivial.
Yenya wrote: Re: Vašek Stodůlka
Agreed, but the situation is different for (even semi-)public interface of the ERP, and an _internal_ class of a single project.
Milan Zamazal wrote:
I'm not talking about complete interfaces, but about extensible interfaces, this is a very different thing. Hiding implementation is always useful, it's a general principle of building programs from well defined autonomous parts. When I change a function and the change forces me to change code that uses the function (I admit it happens to me often), I know I'm doing useless work caused by a mistake in the extensible design. And I can't see any problem in writing foo.bar() instead of foo.bar all the time, it's more consistent than writing sometimes foo.bar and sometimes foo.baz() anyway. As for comments, it's necessary to distinguish between code comments and documentation strings. Code comments should be rare, good code usually documents itself. Documentation strings should be attached to anything what is exported from a module.
Yenya wrote:
"Hiding implementation is always useful" - nope (unless the implementation is nontrivial, which is not the case here). If it adds a bunch of useless code, it is _not_ useful, especially when this is a purely internal thing and the refactorization using a modern IDE is easy. As for your "documentation strings". From the point of view of the reader of the code, this is _also_ a comment, which should the reader read (or skip). It lowers readability.
Lukas Lalinsky wrote:
I know this wasn't supposed to be about specific languages, but... "... but also Python with its Zope and Plone mammoths, and Ruby with RoR are similar." Seriously, Python is anything but not similar. Any Python programmer would in this case simply use the "x" attribute directly. The point why C++/Java programmers have to use getters/setters is that they can't switch from dumb to smart accessors without breaking the API. In Python you can switch then any time and still have the same API - "myobj.x". But this is a limitation of many languages that are often (incorrectly) presented as reference OO languages, not a problem with OOP itself.
Yenya wrote: Re: Lukas Lalinsky
Thanks for explanation. I was refering to Python in general (esp. Plone and Zope). Fortunately these days there are also Python programmers who focus on getting the job done instead of writing "everything and a kitchen sink" mammoths like the two mentioned.
Reply to this story:
Mon, 17 Sep 2007
Command of the Day
I will probably show my own level of ignorance here, but let me show you an useful utility which can improve the integration of the command line and desktop:
Meet xclip,
a command-line utility for manipulating X11 selections from the command line.
If you wondered how text with tabs (such as diff(1) output)
could be copied and pasted using X11, here it is:
diff -u old.file new.file | xclipThere are more options (such as reading the selection from the command line). Hope this helps (seen in this article at KernelTrap).
2 replies for this story:
Milan Zamazal wrote: xclip is redundant
I've got good news for you, you can be saved from your ignorance: Look for `Emacs' next time. :-) (In case you wonder what Emacs is, it's an acronym: "Emacs Manipulates All Common Selections".)
Yenya wrote: Good one
Thanks for a good joke, I need a good laugh from time to time :-)
Reply to this story:
Fri, 14 Sep 2007
Networking Preview
Our network here at Faculty of Informatics is connected to the outside world by a not-so-small Linux-based router (10 subnets mapped using 802.1q to three gigabit and one 100 Mbit physical interfaces of the router). From time to time I wonder what will we do should this router reach its packet forwarding load limit. Today I have found some hints on how will the networking gear of the future look like:
See DaveM's presentation about the Sun Neptune dual-port 10GbE network card. Fortunately, the future is not in TCP offload engines (useless for a router), but in being successful in exploiting parallelism. I.e. how to use the single device from multiple CPUs or cores, how to distribute IRQs, etc. I hope his work ends up in the mainstream kernel soon. The only remaining problem is to get some 10GbE switches to upgrade our backbone...
0 replies for this story:
Reply to this story:
Mon, 03 Sep 2007
OpenBSD Licensing
So we are in a middle of another licensing flame war. To summarize: Jiří Slabý has posted a patch narrowing the Atheros Linux kernel driver license to GPL (some header files were BSD licensed, and the rest was GPL or BSD dual-licensed before). This caused a big uproar in the OpenBSD community, including Theo de Raadt's accusation of Alan Cox giving advice to break the law.
Narrowing the license (i.e. forking the development) is usually not very polite, and I hope Jiří had good reasons to do so. However, ethics aside, the original author of the Atheros HAL code has already said that he is perfectly OK with taking the code under GPL for the Linux kernel.
But what makes me think "WTF?" are not the licensing details, but the overall attitude of the OpenBSD people (Theo, especially): they appeal to ethics (and, in Theo's case, law), when their license clearly allows taking the software and making it proprietary. And with relicensing to GPL only, it is not even made proprietary, just a bit more restrictive. This is not the only case of Theo de Raadt actually demanding something other than their license says. See his OpenSSH funding request as an example. If they so much care about what people do with their software, and whether they give back their changes, why they did not write it into their license (e.g. use GPL instead)? Is it a "not invented here" syndrome?
2 replies for this story:
Vasek Stodulka wrote:
Interesting. It looks like BSD developers do not understand BSD license...
Jiri Slaby wrote:
Ok, let me enlighten it a little bit. Beside the fact I'm idiot and should check more carefully what am I changing, the only thing I did is I executed Nick Kossifidiss's (the main developer of madwifi project, which I forked and wrote the base mostly on my own) idea of having the whole stuff under GPL to not allow companies to pull the code and close it in their proprietary device OSes (such as routerOS & Mikrotik IIRC). Yes, it will deny bsd devs to get the patches back (anyway the "linuxisation" of the code would raise, and they won't be able to use it anyway), but OK, I've decided to publish my changes under ISC or BSD license -- i.e. mine, not the Nick's changes in the fork he did from bsd people, he still probably wants GPL AFAIR, or at least license statement say so in the latest repo commit. Anyway the whole bunch of messages dropped in lists was about the changes that were legal and that never violated anything (see Adrian Bunk's posts, they seem to be very mature). Possible problematic parts of the patch were not discussed that much and was solved promptly. The flame seems unreasonable in my eyes, and so the Raadt's threats.