yup. the whole "We're now so user friendly because we've taken all the useful options out of the UI because they scare people" mentality bugs me.
Because it'll always end up with a user saying "I'd like to use this software, but it doesn't do X" To which the response is "Yes, it does!, just open this obscure settings editor and scroll through the hundreds of arcane settings, and manually edit yyy by hand!"
I much prefer the approach that software like KDE takes where the policy is that _any_ instance in which the user has to manually adjust a setting in a configuration file is a bug. (and editing about:config is for all intents and purposes directly editing a configuration file) The difficulty there of course is designing an interface that allows all the settings to be modified, but doesn't clutter the interface.
The trouble is, that you've nicely explained the easiest part of OOP.
Encapsulation, abstract data types, polymorphism and all the other OO buz words are really easy to understand.
The part that's difficult to wrap your head around, are the pratical design issues - shallow vs deep class heirarchies, use of composition and delegation, when to throw an exception, and when to use a return value, whether to use a dependency injection or service locator approach, and so on. It all seemed so much simpler in C.
English allows it fine. People that make up arbitrary rules that have little bearing on how easy a sentence is to construct or understand may not allow it, but that's entirely different.
Most rules like that someone just made up one day. Probably because it worked like that in Latin or Greek and they're 'Proper' languages, so therefore English must be shoehorned into following their rules. Never mind that people had been using the forms that suddenly become 'wrong' for hundreds of years beforehand. - The suprious "Don't split infinitives" rule is one of those.
Personally I don't think there are rules so much as observations. At least not when talking about colloquial speech, which is what 90% of English is. Formal English is another matter, but even there it's not so much hard rules, as a set of guidlines chosen for a specific purpose.
> I'm thinking we need some sort of ISO standard for clock speed I know! We could call it "Hertz" (abbreviated as Hz), as a measurement of frequency where one Hertz means one cycle per second. When used in relation to CPUs it could be prefixed with the SI multipliers G or M for Giga and Mega, and be used to refer to the speed of the internal clock by which the CPU synchronises its instructions. It however will say nothing about how many instructions happen in a cycle, or what those instructions actually do.
So I'm guessing you don't want a standard for clock speed, you want a standard for performance.
But regardless, if you make your entire purchasing decision off the numbers on the box (no matter what they mean) then you deserve whatever you get.
Before you sigh, go and look it up. "spelt", "learnt", "earnt", "burnt" and quite a few others are not only acceptable, but often taught (not teached) as the only way outside of the USA.
Spelled actually looks completely bizarre to me, despite the fact that I know it's technically correct.
however, without a certain amount of due care in regards to spelling and grammar, meaning starts to become obscure at best.
The other thing is that whilst no one should be expected to spend half an hour carefully double checking every slashdot post for errors, they also shouldn't _need_ to. Average spelling and grammar abilities should be high enough that someone can quickly spew something out, and be relatively certain that it makes sense, and is spelt right _without_ the use of spell checkers or anything more than a quick read through.
unless IE runs as LOCAL_SYSTEM, its "integration" is no more a security risk than that of FireFox, Opera, or Notepad.
The "Integration" is that microsoft considers the IE rendering engine to be a part of Windows, and so iexplore.exe just wraps that renderer in a GUI and some networking code. That is very similar to KHTML and KDE - KHTML is used quite widely throughout KDE, not just in Konqueror. There is nothing wrong with doing that, code reuse is a good thing and it even has potential to be _more_ secure than having every application throw together their own half-arsed HTML renderer.
All browsers (and all other native applications) tie "directly into the OS". They all have access to system commands like open(), write(), system(), and all the hideous Win32 APIs. I am not sure I have ever heard of a security flaw in IE that only existed because of its "integration", and that could not have happened on a non "integrated" browser if it had similarly sloppy programming.
Well pretty much the whole point of Debian is to have a distribution that others can take, modify, and re-distribute. So using Debian derived distributions like Ubuntu or Knoppix is still good for Debian, or at least compatible with its goals.
The fact that it's a pretty good distribution in its own right is more or less just a bonus....
> String.getBytes() is deprecated, so your example is invalid. No. No it is not. In fact, it is the suggested alternative to an actual deprecated method (which just happens to be an overloaded version of getBytes - maybe that's what you're thinking of?).
> Not to mention Date.toString produces something really ugly like "java.util.Date{year=2005;month=2;}" and so on. No. No it does not, java.util.Date overrides toString and provides a default date format. The default format is more than sufficient for this purpose, as the ruby example did no special formatting on the date either.
Your comment about the exception is valid - but the goal here was not to create the most robust server possible, it was to provide a Java equivalent of the Ruby example. What happens in the same situation in the Ruby case?
> However, even that's wrong, because technically the Date object itself is deprecated in favor of the hideous GregorianCalendar. No, no it is not. You could have at least attempted to check those facts before making stuff up.
Also, flushing a Writer immediately before closing it is pretty much the definiton of redundancy.
I'll repeat what I said earlier - If you _want_ to make Java verbose, you _can_.
public static void main(String args[]) throws Exception {
ServerSocket server = new ServerSocket(1234);
while(true) {
new TellTime(server.accept()).start();
}
}
}
I have no idea if this is the smallest it could be. I'm not too familiar with thread programming, so I'm not sure if I couldn't have done that part slightly smaller.
So whilst it's not as simple as the Ruby example (nor I expect, the inevitable Perl and Python examples), it's still not bad, and I went from never having done that before, to a completed program that worked first time in 5 minutes.
Of course this example demonstrates what I find to be Java's biggest bugbear - checked exceptions. I'd absolutely love it if exceptions were all unchecked, or at least if the standard libraries made more use of unchecked exceptions than they do, as most of the time there's absolutely nothing you can do except throw the bloody thing - so why shouldn't it just do it automatically without having to include the exceptions thrown in the function signature?
It's particularly ugly when you are forced to create abominations like the nested exception in the finally block. I _hate_ having to do that. But that's the only real issue I have with the language...everything else pretty much suits me fine.
Hmmm...I don't know. I've never tried a TCP server in java before. Or at least, when I have, I've used a 3rd Party library (called SimpleServer). As I was so burned by my experiences with sockets in C (mostly due to inexperience in that particular area) that I wanted someone else to do all the work;)
I was not attempting to start a Python - Java comparison.
The two languages are different and have different goals and suit different people and different jobs. As far as that program goes - realistically if someone asked me to write a program to display the contents of a file to the screen, I would not write it in Java _or_ Python. I would say "why don't you just use cat?" So how well either language tackles that particular problem is pretty much irrelevant.
Personally, I come from a C background, and Java makes infintely more sense to me than Python, or even Perl. But that doesn't make Java better, it just makes it the right language for me. It also means that I don't really care how Java compares to Python. I only care how it compares to C, and it compares very favourably to C.
My main point was that whilst Java is certainly not the most concise language in the world, it is definitely not as verbose as people make it out to be. It also has the advantage of a large number of tools that take away a lot of the verboseness that does exist both in the language, and in the conventions used.
But it's not for everyone, as Python is also not for everyone.
But having said that, I can't resist a passing nitpick. - what happens when no arguments are passed? My code contained checking and a usage message. Although I'm guessing that it'll only be another line - something similar to Perl's "or die(message)" syntax?
why would you have that many uncategorized bookmarks? That's like blaming the designer of a desk that your papers fall off the sides when you overload it.
But you're right, having the menu go off the screen is not good, and it becomes quite a problem to figure out the best way to deal with it. But I'm not a believer in making the normal case hard so that the rare case is easy.
you type File, hit CTRL+Space in Eclipse and then pick it from the list;)
But seriously, knowing the standard libraries is an issue in every language. It's one of the things that often makes it hard to move from one to the other. The syntax is usually easy enough, but knowing what's available in the standard libraries can be the difference between frustration and statisfaction with a language.
Why do it in two steps when you're never going to use the raw reader on it's own? If you _want_ to make Java too much work, you _can_ just like you can in any language.
Also, if I should have checked for exceptions, then you should have checked for error conditions. Also your python code opened a file, but did not actually result in a useful filehandle you could do anything with.
I'm not claiming that Python is _not_ less verbose than Java, just that Java is not as verbose as people make it out to be - even when dealing with the cumbersome Reader / Writer and Stream interfaces.
A complete (Compiled and tested myself) Open a file, read it, print the contents program -
> Will open sourcing Java source code mean that the language will get submitted to a standards organization like ECMA or ISO or something?
It's already under control of a standards organisation - the JCP.
Whilst it's lead by Sun, there are members from all through the Java community, making it arguably a more relevant standards body than ECMA or ISO as far as Java is concerned.
Submitting Java to ECMA or ISO would not achieve anything that cannot be achieved via the JCP, and would possibly even be detrimental to its development.
> Horizontally-expanding menus completely usurp the user's desktop, and that is always a bad interface implementation.
So tell me, what is the user is going to be doing with their desktop whilst they are selecting an item from the menu?
As a user I would prefer to not be able to see my desktop, but be able to see exactly where the item I want to select is, and be able to do it as quickly as possible, rather than still be able to see my desktop, but unable to see the item I want to choose from the menu and then have to waste time scrolling through a list to find what I want.
Scrolling menus are absolutely horrible to deal with, particularly if you are unfortunate enough to want to select an item that is not among the selections available when the menu opens.
scrolling menus are the most horrible invention I've come across. Horizontally expanding ones are faster, and assuming the contents have not changed, the item you want is always in the same place.
Slashdot Mirror
it gave them something to hope for!
yup. the whole "We're now so user friendly because we've taken all the useful options out of the UI because they scare people" mentality bugs me.
Because it'll always end up with a user saying "I'd like to use this software, but it doesn't do X"
To which the response is "Yes, it does!, just open this obscure settings editor and scroll through the hundreds of arcane settings, and manually edit yyy by hand!"
I much prefer the approach that software like KDE takes where the policy is that _any_ instance in which the user has to manually adjust a setting in a configuration file is a bug. (and editing about:config is for all intents and purposes directly editing a configuration file)
The difficulty there of course is designing an interface that allows all the settings to be modified, but doesn't clutter the interface.
The trouble is, that you've nicely explained the easiest part of OOP.
Encapsulation, abstract data types, polymorphism and all the other OO buz words are really easy to understand.
The part that's difficult to wrap your head around, are the pratical design issues - shallow vs deep class heirarchies, use of composition and delegation, when to throw an exception, and when to use a return value, whether to use a dependency injection or service locator approach, and so on.
It all seemed so much simpler in C.
that's why I said 'The suprious "Don't split infinitives" rule is one of those.' :)
English allows it fine.
People that make up arbitrary rules that have little bearing on how easy a sentence is to construct or understand may not allow it, but that's entirely different.
Most rules like that someone just made up one day. Probably because it worked like that in Latin or Greek and they're 'Proper' languages, so therefore English must be shoehorned into following their rules.
Never mind that people had been using the forms that suddenly become 'wrong' for hundreds of years beforehand. - The suprious "Don't split infinitives" rule is one of those.
Personally I don't think there are rules so much as observations. At least not when talking about colloquial speech, which is what 90% of English is.
Formal English is another matter, but even there it's not so much hard rules, as a set of guidlines chosen for a specific purpose.
> I'm thinking we need some sort of ISO standard for clock speed
I know!
We could call it "Hertz" (abbreviated as Hz), as a measurement of frequency where one Hertz means one cycle per second.
When used in relation to CPUs it could be prefixed with the SI multipliers G or M for Giga and Mega, and be used to refer to the speed of the internal clock by which the CPU synchronises its instructions. It however will say nothing about how many instructions happen in a cycle, or what those instructions actually do.
So I'm guessing you don't want a standard for clock speed, you want a standard for performance.
But regardless, if you make your entire purchasing decision off the numbers on the box (no matter what they mean) then you deserve whatever you get.
Konqueror does the same. Maybe it's an inherent KHTML feature?
I knew someone would point that out.
Before you sigh, go and look it up.
"spelt", "learnt", "earnt", "burnt" and quite a few others are not only acceptable, but often taught (not teached) as the only way outside of the USA.
Spelled actually looks completely bizarre to me, despite the fact that I know it's technically correct.
however, without a certain amount of due care in regards to spelling and grammar, meaning starts to become obscure at best.
The other thing is that whilst no one should be expected to spend half an hour carefully double checking every slashdot post for errors, they also shouldn't _need_ to.
Average spelling and grammar abilities should be high enough that someone can quickly spew something out, and be relatively certain that it makes sense, and is spelt right _without_ the use of spell checkers or anything more than a quick read through.
unless IE runs as LOCAL_SYSTEM, its "integration" is no more a security risk than that of FireFox, Opera, or Notepad.
The "Integration" is that microsoft considers the IE rendering engine to be a part of Windows, and so iexplore.exe just wraps that renderer in a GUI and some networking code.
That is very similar to KHTML and KDE - KHTML is used quite widely throughout KDE, not just in Konqueror.
There is nothing wrong with doing that, code reuse is a good thing and it even has potential to be _more_ secure than having every application throw together their own half-arsed HTML renderer.
All browsers (and all other native applications) tie "directly into the OS". They all have access to system commands like open(), write(), system(), and all the hideous Win32 APIs.
I am not sure I have ever heard of a security flaw in IE that only existed because of its "integration", and that could not have happened on a non "integrated" browser if it had similarly sloppy programming.
Well pretty much the whole point of Debian is to have a distribution that others can take, modify, and re-distribute.
So using Debian derived distributions like Ubuntu or Knoppix is still good for Debian, or at least compatible with its goals.
The fact that it's a pretty good distribution in its own right is more or less just a bonus....
> String.getBytes() is deprecated, so your example is invalid.
No. No it is not. In fact, it is the suggested alternative to an actual deprecated method (which just happens to be an overloaded version of getBytes - maybe that's what you're thinking of?).
> Not to mention Date.toString produces something really ugly like "java.util.Date{year=2005;month=2;}" and so on.
No. No it does not, java.util.Date overrides toString and provides a default date format. The default format is more than sufficient for this purpose, as the ruby example did no special formatting on the date either.
Your comment about the exception is valid - but the goal here was not to create the most robust server possible, it was to provide a Java equivalent of the Ruby example. What happens in the same situation in the Ruby case?
> However, even that's wrong, because technically the Date object itself is deprecated in favor of the hideous GregorianCalendar.
No, no it is not.
You could have at least attempted to check those facts before making stuff up.
Also, flushing a Writer immediately before closing it is pretty much the definiton of redundancy.
I'll repeat what I said earlier - If you _want_ to make Java verbose, you _can_.
> Because PHP is rancid pile of festering monkey crap "designed" by people who have the same level of CS knowledge as Homer Simpson.
I think I love you!
I know _what_ it's doing, just not _why_ that syntax makes it do it.
Could you explain the "do |my_session|" bit?
I'm not too familiar with thread programming, so I'm not sure if I couldn't have done that part slightly smaller.
So whilst it's not as simple as the Ruby example (nor I expect, the inevitable Perl and Python examples), it's still not bad, and I went from never having done that before, to a completed program that worked first time in 5 minutes.
Of course this example demonstrates what I find to be Java's biggest bugbear - checked exceptions.
I'd absolutely love it if exceptions were all unchecked, or at least if the standard libraries made more use of unchecked exceptions than they do, as most of the time there's absolutely nothing you can do except throw the bloody thing - so why shouldn't it just do it automatically without having to include the exceptions thrown in the function signature?
It's particularly ugly when you are forced to create abominations like the nested exception in the finally block. I _hate_ having to do that.
But that's the only real issue I have with the language...everything else pretty much suits me fine.
Hmmm...I don't know. ;)
I've never tried a TCP server in java before.
Or at least, when I have, I've used a 3rd Party library (called SimpleServer). As I was so burned by my experiences with sockets in C (mostly due to inexperience in that particular area) that I wanted someone else to do all the work
But I'll give it a go and post the result.
I was not attempting to start a Python - Java comparison.
The two languages are different and have different goals and suit different people and different jobs.
As far as that program goes - realistically if someone asked me to write a program to display the contents of a file to the screen, I would not write it in Java _or_ Python. I would say "why don't you just use cat?"
So how well either language tackles that particular problem is pretty much irrelevant.
Personally, I come from a C background, and Java makes infintely more sense to me than Python, or even Perl. But that doesn't make Java better, it just makes it the right language for me.
It also means that I don't really care how Java compares to Python. I only care how it compares to C, and it compares very favourably to C.
My main point was that whilst Java is certainly not the most concise language in the world, it is definitely not as verbose as people make it out to be.
It also has the advantage of a large number of tools that take away a lot of the verboseness that does exist both in the language, and in the conventions used.
But it's not for everyone, as Python is also not for everyone.
But having said that, I can't resist a passing nitpick. - what happens when no arguments are passed? My code contained checking and a usage message.
Although I'm guessing that it'll only be another line - something similar to Perl's "or die(message)" syntax?
why would you have that many uncategorized bookmarks?
That's like blaming the designer of a desk that your papers fall off the sides when you overload it.
But you're right, having the menu go off the screen is not good, and it becomes quite a problem to figure out the best way to deal with it.
But I'm not a believer in making the normal case hard so that the rare case is easy.
you type File, hit CTRL+Space in Eclipse and then pick it from the list ;)
But seriously, knowing the standard libraries is an issue in every language.
It's one of the things that often makes it hard to move from one to the other. The syntax is usually easy enough, but knowing what's available in the standard libraries can be the difference between frustration and statisfaction with a language.
If you _want_ to make Java too much work, you _can_ just like you can in any language.
Also, if I should have checked for exceptions, then you should have checked for error conditions.
Also your python code opened a file, but did not actually result in a useful filehandle you could do anything with.
I'm not claiming that Python is _not_ less verbose than Java, just that Java is not as verbose as people make it out to be - even when dealing with the cumbersome Reader / Writer and Stream interfaces.
A complete (Compiled and tested myself) Open a file, read it, print the contents program -
> Will open sourcing Java source code mean that the language will get submitted to a standards organization like ECMA or ISO or something?
It's already under control of a standards organisation - the JCP.
Whilst it's lead by Sun, there are members from all through the Java community, making it arguably a more relevant standards body than ECMA or ISO as far as Java is concerned.
Submitting Java to ECMA or ISO would not achieve anything that cannot be achieved via the JCP, and would possibly even be detrimental to its development.
OutputStream out = new FileOutputStream(filename);
next?
(yes, I know it's still more typing than python, and I know you were tying to be funny, but Java really isn't that much work)
> Horizontally-expanding menus completely usurp the user's desktop, and that is always a bad interface implementation.
So tell me, what is the user is going to be doing with their desktop whilst they are selecting an item from the menu?
As a user I would prefer to not be able to see my desktop, but be able to see exactly where the item I want to select is, and be able to do it as quickly as possible, rather than still be able to see my desktop, but unable to see the item I want to choose from the menu and then have to waste time scrolling through a list to find what I want.
Scrolling menus are absolutely horrible to deal with, particularly if you are unfortunate enough to want to select an item that is not among the selections available when the menu opens.
is this a joke?
scrolling menus are the most horrible invention I've come across. Horizontally expanding ones are faster, and assuming the contents have not changed, the item you want is always in the same place.
scrolling menus should die.
actually, we've had benchmark trumpets for years.
;)
It's only when the benchmarks are nothing to trumpet about that we start to get the fiddling