Would I do it? Yes. Have I? Yes - I've switched banks once because of it, but I guess I've been lucky enough not to have encountered anything else that absolutely requires IE that I absolutely cannot change.
Still, it's what you get from running Windows - people can always tell you to "just fire up IE". I can't run IE - it is not available for the operating systems I have available to me, hence I have a much bigger stick to hit them with when they tell me I must use that browser.
You're not forced to use IE by those people - you choose to. In doing so, you are rewarding them for being crap.
What you should be doing is refusing to use them. Switch bank, don't use the service, or whatever - but make sure you write them an email or letter explaining why.
Fair enough, but given most people here are Linux or Windows kids, you're still better off asking the lists - even if you get a "read the archives!" response you'll know more than you'll get here. >:)
So you're saying the way they were implemented clutter the editor up? Or the extra commands do? I assume you don't mean the windowing clutters the UI...
Yeah, good question. I dunno - maybe everyone was standing around asking "when is someone going to do this?" and using FTP(S) in the mean time. I might have been.;)
Look, I can't be bothered arguing about 80 cols or HTML in email. It's been done to death and you are arguing it is bad because for reasons of personal taste - which, when it comes to, you can never convince someone that their personal taste is wrong. I should point out however that you are wrong about most of it, ask Google if you can be bothered learning something.
Now, about those char and byte streams - you never want to directly instantiate a file stream then start using it - you're making the assumption that the bytes live on disk, which is not the case in unit tests or when, say running a web app from a WAR, i.e. breaking encapsulation. So you pointed out your own strawman yourself. Good!
There are only two times you need to use a BufferedReader (only one for BufferedInputStreams): When you need to call BufferedReader.readLine() or really, really need the performance. 99% of the time you need neither.
So we're agreed that Hungarian has no place in modern programming (languages)? Good! But I have to take offence at your strawman remark. Your assumption that there will be similarly named variables scattered around the code is as bogus as my cherry picking.
Yes, I would have trotted out the "100 lines max" rule of thumb because, surprise, it actually does make the code more readable. If you were taught that sort of thing in second year CS, then hurray for CS departments teaching people something useful. _Of course_ there are times when you have to go over it but you know what, but this should be the exception, not the rule.
But I don't know about the IDE argument. The point of Hungarian was that you don't need to hunt for the declaration, you could tell from a few lines of code in isolation what the value of a variable should be. A modern language won't tell you that either, but at least it will throw a fit at compile time or run time rather than segfaulting five source files and hundreds of lines away from the original bug.
irks me, but you might see how redundant it is. _Of course_ choosing variable names is important, but Hungarian is a very specific notation, the examples above (including yours) are not Hungarian.
You need to find a balance between too terse and too verbose. Using Hungarian today can fall down in both ways. Done correctly it is too terse ("rwCur" anyone?) and if not done correctly, is redundant (see examples above) and hence too verbose.
Sure, if rowCurrent was a pointer to an unsigned int, then it would be a useful variable name, but if not there is little point. Welcome to the 21st century.
WRT my PPS, there a lot of good reasons to have 80 cols max. It means your code is emailable (or do you use HTML mail?/me lols). It keeps function/method complexity down by limiting nested blocks. It means you can fix stuff reasonably well on a serial console. It keeps code readable (c.f. newspaper column widths). I bet you also have your web browser windows maximised, all the time. Tisk, tisk.
If you're a Java developer, you may be interested to know that Sun's Java code conventions specify 80 cols max - so it's not just 'sez me'.
/Mike
PS: You java streams are a good example of poorly encapsulated code. Separate your concerns and the 80 col "problem" goes away.
PPS: Even excluding the encapsulation problem, why wouldn't you just do "new BufferedReader(new FileReader(file));"? Or not bother with the BufferedReader at all given that 99% of the time is is needlessly used?
If you've got to use an IDE to find the definition of a variable in your codebase, you have a much bigger problem.
Still, how is "rwPosition" any better than "rowPosition"? (from the Wikipedia article) Sure, "i" is kinda ambiguous, but use a modern for-loop instead and get rid of it altogether. Again citing Wikipedia, some of Simonyi's suggested prefixes added semantic information, but not all.
I'll say it again: Hungarian is pointless in a modern language.
All design patterns are workarounds for missing language features. See GTK's use of an object oriented pattern in C, for example. Hungarian is a design pattern (well, naming convention, but same thing) for the same weakly typed language: C.
Modern languages are strongly typed and hence will tell the programmer when they've screwed up, at compile time or later. So there's no need for Hungarian in these languages, much like C# or Java and maybe even C++ now has built in support for object oriented programming.
So again, Joel spins something that was useful historically as being something that is still essential, even though it is now completely redundant. This man is a living, breathing excuse for poor practices based on historical, obsolete artifice.
Now, to get to your point - it is moot that some programmers are using some bastardised version of Hungarian, because even if done correctly it is now a waste of time when using a modern programming language. It only contributes by making a program harder to read, hence increasing complexity and reducing maintainability rather than providing any actual benefit.
Ack, no. They always appear to be really nifty on the surface, but they always go wrong on the details.
Take this article, for instance - sure, he's right that trying to implement support for these specs is futile. It's the same reason why Office's OOXML "standard" is a joke. But he didn't really need to spend 6 pages saying so. And sure, the workarounds are fine if you're a Windows shop, but workarounds #2 and #3 are not simple "half day of work" if you have no experience with Microsoft technologies - it's weeks at least. You're much better off using an existing free or proprietary library to do the work in whatever environment you are familiar with.
And 2 days work to allow for an adjustable epoch? To add a constant to a parsed number? I lol'ed! For someone who believes in metrics based software development, he sure seems to be pulling a lot of numbers out of his arse.
I like his stuff when I first came across it, but there's too much cool-aid, not enough reality.
Ditto. Include the fact that the unused memory gets paged to disk anyway (hello? we have had virtual memory since, I don't know, the 70's) so it doesn't really affect the performance of your system anyway and I really don't know what the problem is.
I think it's mostly trolls, people with some sort of system-performance-tools related OCD, (tinfoil hat on) Microsoft employees and those two other people that complain. Probably best to just ignore them.
Sort of. It still has to be tuned per platform - see Edit > Preferences vs Tools > Options, for example. Also, it and the XPCOM toolkit that FF uses is slowly getting forked per platform: Linux is only getting native file open/save and print dialogs, for example. Full emulation of the look of GTK controls is only just landing. Like with wxWidgets, GTK is a second class citizen.
So again, unless there is a platform specific front end, some poor bastards lose out. Usually the Linux users.
Forget cross platform widget sets. There is no way to get a 100% native look/and/ feel using them. C.f. GTK, AWT, Swing, XUL, Windows.Forms, etc. One or more platforms will always get the nasty end of the stick (usually, in order, Linux then MacOSX) and you will annoy those users, and sometimes lose them to competitors/alternatives.
If you want to write non-trivial cross platform apps that conform well to the UI guidelines for the target platforms, you need to commit to using the default native widget set for that platform. Yes, this means a separate front end for each platform. If you write your app's backend well, this won't mean too much duplicate effort.
That's always been the case however - Epiphany does not implement this itself. Granted, the code to do this was scattered over the place - gnome-vfs for the non-local file access and libgnomeui(?) for activation - i.e. actually opening the apps, but it is definitely all there.
You're right, gio/gvfs will make this nicer/easier/available to non-GNOME apps, but it's not something new.
Check your facts, it has been doing this for years.
I click on a PDF link in Epiphany and it downloads the PDF and opens it in Evince (or whatever is registered as the primary PDF handler). If the website annoyingly opens a new window to show the PDF in (as if you have the plugin installed), Epy even helpfully closes the empty window for you.
This works for all registered content types, not just PDFs. If on some occasions it does not work, it is because the server is misconfigured and is sending the wrong MIME content type./Mike
Slashdot Mirror
Still, it's what you get from running Windows - people can always tell you to "just fire up IE". I can't run IE - it is not available for the operating systems I have available to me, hence I have a much bigger stick to hit them with when they tell me I must use that browser.
/Mike
What you should be doing is refusing to use them. Switch bank, don't use the service, or whatever - but make sure you write them an email or letter explaining why.
/mike
Of course, the devil will be in the details - let's see how how well they implement the new support.
/mike
/Mike
/mike
/Mike
/me lols
Genius!
/Mike
/mike
Yep, that's precisely why my ears perked up upon hearing this, for hosting providers that want to provide secure remote file access, this is awesome!
/Mike
Now, about those char and byte streams - you never want to directly instantiate a file stream then start using it - you're making the assumption that the bytes live on disk, which is not the case in unit tests or when, say running a web app from a WAR, i.e. breaking encapsulation. So you pointed out your own strawman yourself. Good!
There are only two times you need to use a BufferedReader (only one for BufferedInputStreams): When you need to call BufferedReader.readLine() or really, really need the performance. 99% of the time you need neither.
/Mike
Yes, I would have trotted out the "100 lines max" rule of thumb because, surprise, it actually does make the code more readable. If you were taught that sort of thing in second year CS, then hurray for CS departments teaching people something useful. _Of course_ there are times when you have to go over it but you know what, but this should be the exception, not the rule.
But I don't know about the IDE argument. The point of Hungarian was that you don't need to hunt for the declaration, you could tell from a few lines of code in isolation what the value of a variable should be. A modern language won't tell you that either, but at least it will throw a fit at compile time or run time rather than segfaulting five source files and hundreds of lines away from the original bug.
/Mike
Row rowCurrent = getCurrentRow();
irks me, but you might see how redundant it is. _Of course_ choosing variable names is important, but Hungarian is a very specific notation, the examples above (including yours) are not Hungarian.
You need to find a balance between too terse and too verbose. Using Hungarian today can fall down in both ways. Done correctly it is too terse ("rwCur" anyone?) and if not done correctly, is redundant (see examples above) and hence too verbose.
Sure, if rowCurrent was a pointer to an unsigned int, then it would be a useful variable name, but if not there is little point. Welcome to the 21st century.
WRT my PPS, there a lot of good reasons to have 80 cols max. It means your code is emailable (or do you use HTML mail?
If you're a Java developer, you may be interested to know that Sun's Java code conventions specify 80 cols max - so it's not just 'sez me'.
/Mike
PS: You java streams are a good example of poorly encapsulated code. Separate your concerns and the 80 col "problem" goes away.
PPS: Even excluding the encapsulation problem, why wouldn't you just do "new BufferedReader(new FileReader(file));"? Or not bother with the BufferedReader at all given that 99% of the time is is needlessly used?
/mike
PS: 80 col display terminals were around long before DOS - VT100's ran in either 80 or 132 col mode in the 70's.
PPS: If your code today needs more than 80 cols (or arguably 132 cols), you have bigger problems.
Still, how is "rwPosition" any better than "rowPosition"? (from the Wikipedia article) Sure, "i" is kinda ambiguous, but use a modern for-loop instead and get rid of it altogether. Again citing Wikipedia, some of Simonyi's suggested prefixes added semantic information, but not all.
I'll say it again: Hungarian is pointless in a modern language.
/Mike
Modern languages are strongly typed and hence will tell the programmer when they've screwed up, at compile time or later. So there's no need for Hungarian in these languages, much like C# or Java and maybe even C++ now has built in support for object oriented programming.
So again, Joel spins something that was useful historically as being something that is still essential, even though it is now completely redundant. This man is a living, breathing excuse for poor practices based on historical, obsolete artifice.
Now, to get to your point - it is moot that some programmers are using some bastardised version of Hungarian, because even if done correctly it is now a waste of time when using a modern programming language. It only contributes by making a program harder to read, hence increasing complexity and reducing maintainability rather than providing any actual benefit.
/Mike
Take this article, for instance - sure, he's right that trying to implement support for these specs is futile. It's the same reason why Office's OOXML "standard" is a joke. But he didn't really need to spend 6 pages saying so. And sure, the workarounds are fine if you're a Windows shop, but workarounds #2 and #3 are not simple "half day of work" if you have no experience with Microsoft technologies - it's weeks at least. You're much better off using an existing free or proprietary library to do the work in whatever environment you are familiar with.
And 2 days work to allow for an adjustable epoch? To add a constant to a parsed number? I lol'ed! For someone who believes in metrics based software development, he sure seems to be pulling a lot of numbers out of his arse.
I like his stuff when I first came across it, but there's too much cool-aid, not enough reality.
/Mike
Huh, that never happens to me. Oh well, guess I'm lucky.
/Mike
I think it's mostly trolls, people with some sort of system-performance-tools related OCD, (tinfoil hat on) Microsoft employees and those two other people that complain. Probably best to just ignore them.
/mike
So again, unless there is a platform specific front end, some poor bastards lose out. Usually the Linux users.
/Mike
Forget cross platform widget sets. There is no way to get a 100% native look
If you want to write non-trivial cross platform apps that conform well to the UI guidelines for the target platforms, you need to commit to using the default native widget set for that platform. Yes, this means a separate front end for each platform. If you write your app's backend well, this won't mean too much duplicate effort.
Friends don't let friends use wx.
/Mike
Nokia drives Qt proprietary? Fork it.
GNOME includes support for OOXML? Ignore it.
Want to write an GUI app? Use what ever desktop suits you and your users most.
Thinking of posting to ask
/Mike
You're right, gio/gvfs will make this nicer/easier/available to non-GNOME apps, but it's not something new.
/Mike
Check your facts, it has been doing this for years.
/Mike
I click on a PDF link in Epiphany and it downloads the PDF and opens it in Evince (or whatever is registered as the primary PDF handler). If the website annoyingly opens a new window to show the PDF in (as if you have the plugin installed), Epy even helpfully closes the empty window for you.
This works for all registered content types, not just PDFs. If on some occasions it does not work, it is because the server is misconfigured and is sending the wrong MIME content type.
Well, the original BSD licence did - the one with the advertising clause, but that's why it's called "obnoxious". /Mike