#1 Garbage collection. a.k.a. automatic memory management. Not very sexy, but by far the single biggest productivity boosting feature of any language. I hate housework. It is just a waste of time.
#2 No pointers, no buffer overruns, no memory corruption. Related to the first point. Memory corruption is just so hard track down. You can keep your pointers, I've already got an OS, I don't need to write my own.:)
After spending years programing asm and C on a platform with no memory protection (Amiga), and then later C++, I think I've paid my dues here.
#3 Stack traces. Not a language feature per se, but it takes a lot of the drudge work out of debugging.
#4 Python's 'for' loop for iterating over the contents of a list or array:
for thing in myarray: mutate(thing)
It is easy to remember, easy to type, much easier to read, and you use it _all_ the time. Compared to the same code in C, C++ or Java, it is a godsend.
#5 Dictionaries, a.k.a. associative arrays. It just makes a lot of problems much much simplier and faster to solve. Sure, most other languages have dictionaries available as a class, but when they are seamlessly built into the language you use them as easily as any other primitive datatype.
Well according to the website "Mono is positioned to become the leading choice for development of Linux applications as well as cross platform applications.". huh?!? sorry, but I can't think of a single major Linux project that is using or planning to use Mono. In fact I would say that most projects are staying away from it due to the uncertainy concerning patents and Microsoft. Which is a shame because it looks like great tech, but who wants to take the risk?
I'll never understand the business model of a newspaper that puts its articles on their website.
The business model here is the same as for the dead tree version ==> Advertising. Tradional newspapers make money from advertising, not from selling newspapers. The money you pay when buying a copy of a newspaper doesn't cover production costs for most papers. The rest is made up by advertising money.
That's exactly right. I mean, if Pac-Man affected us as kids, we'd all be running around in dark rooms, eating magic pills and listening to repetitive electronic music...
I've said it before, and I'll say it again: we're not all UI experts, but we can all improve. IMO that's the main problem with the UI of many packages -- not that developers don't have the UI skill so much as they don't care.
I think that the caring part is changing in the OSS community, and that is good to see. There are still plenty of developers who want to make software with good user interfaces, and mean well but just don't have the skills. Time to get serious, time to Educate thyself. User interface, interaction design or whatever you want to call it isn't "touchy feely", personal preference or "whatever you are used to". There are real design principals and concepts here that are every bit as rational and useful as any in the Software Engineering realm. It is not voodoo. These design principals and concepts can be learnt and successfully applied just like other areas of software development such as network programming, computer security or object oriented programming etc. And just like these areas/fields in software development if want to have a chance of doing them well you will need to do some study, read up on the subject. Hell, you might even find it interesting.:-)
The best book on the subject IMHO is
About Face: The Essentials of Interaction Design. Very practical, insightful while also being quite entertaining to read. This should be the first book that you read.
The SAP Design Guild website has a lot of good articles that explain usability principals and at the same time are very practical (and no advertising to wade through on the site, yay!)
The book "User Interface Design For Programmers" by Joel Spolsky can be read online here. It is quite a good starting point and you can start reading it now.
Now how are they going to force people to give up millions of dollors in investment. Both software and training, let alone the new hardware that may be required (WinTel). For the so far unproven benifits of LongHorn?
Shiny things. IT management loves shiny things.
I'm not sure if that is true these days. I think IT management are looking much closer at what kind of bang per buck they are getting.
The reason the uptake of XP and Server 2003 has been so slow is because they don't really do a hell of a lot more thna Win2k.
And this can work to our advantage.
As far as I can see, the only real benefit of LongHorn to businesses is XAML and its "zero-install over the network" delivery. Businesses are swimming in custom written in-house applications such as billing systems, stock control system, client record systems, etc. I work as a programmer at a web developement business. We specialise in Content Management Systems and basically web based applications. Our clients absolutely love having these applications running centrally on a server while being immediately available (zero install!) on every machine in the office (and out of the office if needed). This is done via a web browser and HTML+Javascript of course. Now, XAML takes this idea and implements it properly and fixes a lot of problems that come with trying to create applications inside a web browser.
What Mozilla needs to do is get their browser out there and on desktops, but more importantly they need to document(!) and further develop XUL. Try to use it for making business applications like I've mentioned above (not chat clients, get serious). Find out where the weak spots and gaps are and fix and fill them in. At the same time they need to get things working happening on the server side. OSS is strong on the server, but we need proper libraries and support for XUL apps on the server written in Java, PHP, etc hell even C# if really want to use a window webserver. For the love of god Mozilla, get in touch with Apache.org, Tomcat and friends. Create a full and complete platform (server + client) for creating and delivery business/database applications. We already have the big pieces.
In 2 years time we want IT management to have to decide between:
a massive rollout of LongHorn, vendor lockin, expensive licenses and windows lock in all round
or just installing Firefox on their desktop systems (2k, XP, Linux, whatever) with minimum impact and cost, and then using their existing servers to serve their applications.
--
Simon
Re:Joe vs. vi vs. GUI based editors
on
JOE Hits 3.0
·
· Score: 2, Insightful
Funny that, replace "text editor" with "operating system" and you've just described the stereotypical Windows zealot.
Perhaps, but I wasn't talking about operating systems. I was talking about text editors. Which I feel is a totally different class of problem/difficulty. Why do I need a manual to do the simplest and most basic things in a text editor? Seriously.
As for that "it's a steep learninig curve, but once you learn it it's powerful" statement people like to bring up, things like Joe are powerful because they do not have a steep learning curve. What exactly is it that vi's steep learning curve gives people apart from a feeling of "eliteness", that can't be found elsewhere in easier to use software? What's the pay-off?
[...] groking vi is valuable as it is ubiquitous
How come that is the only argument I hear from people about why vi is so great? "It's everywhere". So is windows. So what.
--
Simon
Re:Joe vs. vi vs. GUI based editors
on
JOE Hits 3.0
·
· Score: 1
vi has a steep learning curve, no onscreen help, it trapped me too many times for me to give it a chance whe I first started out.
You said it! I find it truly perverse that you need to read a manual, or a tutorial just to use a text editor. This is not rocket science and I've got better things on my mind than how to use the bloody text editor.
Joe was the only one besides pico with on screen help that I could find in my early slackware days. It stuck and I still use it all the time. In the mean while I've still learned enough vi to use it when I have to.
I've learnt enough vi to be able to edit the joe makefile.:-)
The current problems with using DCOP right now for scripting and macros type stuff are:
* There is very little documentation about what DCOP interfaces programs like Kate have, and how they can be used for writing small scripts and macros.
* The existing DCOP interfaces are not designed for the ease of use by scripters/powerusers. They are built directly on top of the C++ implementation.
* The DCOP interfaces are often not complete enough to make it possible to script everything that can be done via the GUI.
and this enables doing things that are simply impossible to batch with a GUI (without writing an app)
What exactly is the difference between 1) using a CLI and then writing "for x in..." or 2) using a GUI and then writing a short script?
How exactly does this show that the CLI is more powerful? I mean, in both cases you have to write a program to solve the problem. (Even a single line program such as your "for x in..." one above).
Except that maybe the GUI user might have the good taste to use something better than horrid shell scripting... bah.
I left Australia a few years ago and one thing that I miss is good radio. Melbourne has excellent radio, especially the non-commercial stations which play an incrediably diverse range styles and types (PBS for example) and JJJ which play a lot of local music (which happens to be excellent too). Actually the difference between the commercial stations and the rest is night and day. They barely overlap w.r.t. what they play. You can really get away from mainstream pop shite altogether in Melbourne.
It is a science fiction (cyperpunkish?) radio play set in a rather bleak future. It covers issues about copyright, corporations etc, and is likely to be a lot more interesting and thought provoking than some show about an unlikey feel-good-shiny-robots-and-flying-cars future.
There is almost no difference between C#/Mono/.NET and Java, but almost no Linux developers write in Java.
...except for the thousands of people developing in-house, business and custom applications in Java and deploying on Linux servers. It is quite possible that the majority of Linux developers are actually developing in Java and as such don't necessarily count themselves in the Linux camp, and certainly don't show up in Linux distributions.
Now, if you don't mind I've got to get back to work with Tomcat.
Except for the fact that 10.0 has heavily patched KDE 3.2.0 packages which are almost 3.2.1. My KDE here is at package version 3.2-70mdk, 70 meaning that it is the *70th* version of this package. i.e. it has been patched and rebuild roughly *70 times.
Try:
rpm -q -changelog libkdebase4 | less
Oh, Mandrake hasn't gone gold either. The boxed version will go gold in May as I understand it.
Mandrake's luck isn't _that_ bad.:) They're even coming out of Chapter 11 too.
Yes it is a proprietary kind of issue. Go take it up with your gfx card manufacturer instead of Mandrake. I mean it, please, put some pressure on ATI let they know that this is important to you.
Don't worry, if I remember correctly the ATO has plenty of machines around that can help people steal your identity. You don't need to hang on to that Windows box.:-)
Wake me up when someone comes up with a realistic strategy for migrating all of our Qt/KDE, GTK/Gnome, Mozilla and OpenOffice.org apps over to their X replacement...
Guys, the reason why we are all still using X is not because windowing systems are so hard to create, it is because we all have so much software invested in X now which would somehow need to be ported over.
No, an X emulation layer is not going to solve it. What is the point in having a new window system if all of my apps get bogged down by an emulation layer? Why bother?
I wish the Y developers the best of luck. But first they must put down their C++ compilers, crack open the source to Qt, GTK etc and have a good look inside and see how these toolkits work and realise that they can't change anything above this software layer. They can only work inside the widget toolkit layer and below. People (developers!) are not going to switch the toolkits their applications use.
It hasn't got much to do with free speech. It would be more like making it illegal to help your neighbour.
Why does all human behaviour having to reduced to the exchange of money? Is not trying to make money for yourself at every turn now morally wrong or something?
"Countries that resort to protectionism end up hampering innovation and crippling their industries, which leads to lower economic growth and ultimately higher unemployment," said the Washington-based Computer Systems Policy Project,
OK, so let me get this straight. To guard against "ultimately higher unemployment" we should be firing the local employees and moving the jobs overseas...:-/
I don't still get it. Well anyway, I'm sure that all the people who just lost thier jobs will sleep much better now that knowing that by being unemployed they are doing thier part to combat unemployment.
Which advertisers want to target a demographic so cheap that they won't buy a computer, and so "behind the times" that they already don't have a computer? Seriously. What are they thinking?
>>> Linux geeks and other developers, who have been conditioned to think like the computer because of the work they do...
Since we are the ones programming them, doesn't that mean that they've been conditioned to think the way that we do? After all, they're running our logic. Kind of like a small section of our minds...
No, because by the time one has learnt how to program, it is too late. We think like them, and then we code. After that point thinking like a "normal person" becomes very difficult.
Slashdot Mirror
#1 Garbage collection. a.k.a. automatic memory management. Not very sexy, but by far the single biggest productivity boosting feature of any language. I hate housework. It is just a waste of time.
:)
#2 No pointers, no buffer overruns, no memory corruption. Related to the first point. Memory corruption is just so hard track down. You can keep your pointers, I've already got an OS, I don't need to write my own.
After spending years programing asm and C on a platform with no memory protection (Amiga), and then later C++, I think I've paid my dues here.
#3 Stack traces. Not a language feature per se, but it takes a lot of the drudge work out of debugging.
#4 Python's 'for' loop for iterating over the contents of a list or array:
for thing in myarray:
mutate(thing)
It is easy to remember, easy to type, much easier to read, and you use it _all_ the time. Compared to the same code in C, C++ or Java, it is a godsend.
#5 Dictionaries, a.k.a. associative arrays. It just makes a lot of problems much much simplier and faster to solve. Sure, most other languages have dictionaries available as a class, but when they are seamlessly built into the language you use them as easily as any other primitive datatype.
--
Simon
--
Simon
The business model here is the same as for the dead tree version ==> Advertising. Tradional newspapers make money from advertising, not from selling newspapers. The money you pay when buying a copy of a newspaper doesn't cover production costs for most papers. The rest is made up by advertising money.
--
Simon
True. I like rave parties too.
--
Simon
The only difference between a "defensive" patent portfolio and an "offensive" patent portfolio is that they haven't used the patents offensively yet.
FAT patents anyone?
--
Simon
I think that the caring part is changing in the OSS community, and that is good to see. There are still plenty of developers who want to make software with good user interfaces, and mean well but just don't have the skills. Time to get serious, time to Educate thyself. User interface, interaction design or whatever you want to call it isn't "touchy feely", personal preference or "whatever you are used to". There are real design principals and concepts here that are every bit as rational and useful as any in the Software Engineering realm. It is not voodoo. These design principals and concepts can be learnt and successfully applied just like other areas of software development such as network programming, computer security or object oriented programming etc. And just like these areas/fields in software development if want to have a chance of doing them well you will need to do some study, read up on the subject. Hell, you might even find it interesting. :-)
--
Simon
Shiny things. IT management loves shiny things.
I'm not sure if that is true these days. I think IT management are looking much closer at what kind of bang per buck they are getting.
The reason the uptake of XP and Server 2003 has been so slow is because they don't really do a hell of a lot more thna Win2k.
And this can work to our advantage.
As far as I can see, the only real benefit of LongHorn to businesses is XAML and its "zero-install over the network" delivery. Businesses are swimming in custom written in-house applications such as billing systems, stock control system, client record systems, etc. I work as a programmer at a web developement business. We specialise in Content Management Systems and basically web based applications. Our clients absolutely love having these applications running centrally on a server while being immediately available (zero install!) on every machine in the office (and out of the office if needed). This is done via a web browser and HTML+Javascript of course. Now, XAML takes this idea and implements it properly and fixes a lot of problems that come with trying to create applications inside a web browser.
What Mozilla needs to do is get their browser out there and on desktops, but more importantly they need to document(!) and further develop XUL. Try to use it for making business applications like I've mentioned above (not chat clients, get serious). Find out where the weak spots and gaps are and fix and fill them in. At the same time they need to get things working happening on the server side. OSS is strong on the server, but we need proper libraries and support for XUL apps on the server written in Java, PHP, etc hell even C# if really want to use a window webserver. For the love of god Mozilla, get in touch with Apache.org, Tomcat and friends. Create a full and complete platform (server + client) for creating and delivery business/database applications. We already have the big pieces.
In 2 years time we want IT management to have to decide between:
--
Simon
Perhaps, but I wasn't talking about operating systems. I was talking about text editors. Which I feel is a totally different class of problem/difficulty. Why do I need a manual to do the simplest and most basic things in a text editor? Seriously.
As for that "it's a steep learninig curve, but once you learn it it's powerful" statement people like to bring up, things like Joe are powerful because they do not have a steep learning curve. What exactly is it that vi's steep learning curve gives people apart from a feeling of "eliteness", that can't be found elsewhere in easier to use software? What's the pay-off?
[...] groking vi is valuable as it is ubiquitous
How come that is the only argument I hear from people about why vi is so great? "It's everywhere". So is windows. So what.
--
Simon
You said it! I find it truly perverse that you need to read a manual, or a tutorial just to use a text editor. This is not rocket science and I've got better things on my mind than how to use the bloody text editor.
Joe was the only one besides pico with on screen help that I could find in my early slackware days. It stuck and I still use it all the time. In the mean while I've still learned enough vi to use it when I have to.
I've learnt enough vi to be able to edit the joe makefile. :-)
--
Simon
The current problems with using DCOP right now for scripting and macros type stuff are:
* There is very little documentation about what DCOP interfaces programs like Kate have, and how they can be used for writing small scripts and macros.
* The existing DCOP interfaces are not designed for the ease of use by scripters/powerusers. They are built directly on top of the C++ implementation.
* The DCOP interfaces are often not complete enough to make it possible to script everything that can be done via the GUI.
--
Simon
What exactly is the difference between 1) using a CLI and then writing "for x in ..." or 2) using a GUI and then writing a short script?
How exactly does this show that the CLI is more powerful? I mean, in both cases you have to write a program to solve the problem. (Even a single line program such as your "for x in..." one above).
Except that maybe the GUI user might have the good taste to use something better than horrid shell scripting... bah.
--
Simon
I left Australia a few years ago and one thing that I miss is good radio. Melbourne has excellent radio, especially the non-commercial stations which play an incrediably diverse range styles and types (PBS for example) and JJJ which play a lot of local music (which happens to be excellent too). Actually the difference between the commercial stations and the rest is night and day. They barely overlap w.r.t. what they play. You can really get away from mainstream pop shite altogether in Melbourne.
--
Simon
It is a science fiction (cyperpunkish?) radio play set in a rather bleak future. It covers issues about copyright, corporations etc, and is likely to be a lot more interesting and thought provoking than some show about an unlikey feel-good-shiny-robots-and-flying-cars future.
--
Simon
Now, if you don't mind I've got to get back to work with Tomcat.
--
Simon
Except for the fact that 10.0 has heavily patched KDE 3.2.0 packages which are almost 3.2.1. My KDE here is at package version 3.2-70mdk, 70 meaning that it is the *70th* version of this package. i.e. it has been patched and rebuild roughly *70 times.
:) They're even coming out of Chapter 11 too.
Try:
rpm -q -changelog libkdebase4 | less
Oh, Mandrake hasn't gone gold either. The boxed version will go gold in May as I understand it.
Mandrake's luck isn't _that_ bad.
--
Simon
--
Simon
--
Simon
Guys, the reason why we are all still using X is not because windowing systems are so hard to create, it is because we all have so much software invested in X now which would somehow need to be ported over.
No, an X emulation layer is not going to solve it. What is the point in having a new window system if all of my apps get bogged down by an emulation layer? Why bother?
I wish the Y developers the best of luck. But first they must put down their C++ compilers, crack open the source to Qt, GTK etc and have a good look inside and see how these toolkits work and realise that they can't change anything above this software layer. They can only work inside the widget toolkit layer and below. People (developers!) are not going to switch the toolkits their applications use.
--
Simon
Why does all human behaviour having to reduced to the exchange of money? Is not trying to make money for yourself at every turn now morally wrong or something?
--
Simon
The Gnome guys/gals don't seem to have a dev-room or much in the way or offical talks. Anyone know what is it going on?
--
Simon
OK, so let me get this straight. To guard against "ultimately higher unemployment" we should be firing the local employees and moving the jobs overseas... :-/
I don't still get it. Well anyway, I'm sure that all the people who just lost thier jobs will sleep much better now that knowing that by being unemployed they are doing thier part to combat unemployment.
--
Simon
In a totalitarian system, you aren't allowed to talk back to the government; in the capitalist system you can't talk back to the sponsor.
--
Simon
ummm... The Power Users group also has too much power to screw the machine up.
Go not unto /. for advice, for you will be told both yea and nay (but have nothing to do with the question)
Or in this case just plain miss the point. We are trying to stop the computer from getting trashed here.
--
Simon
--
Simon
Since we are the ones programming them, doesn't that mean that they've been conditioned to think the way that we do? After all, they're running our logic. Kind of like a small section of our minds...
No, because by the time one has learnt how to program, it is too late. We think like them, and then we code. After that point thinking like a "normal person" becomes very difficult.
--
Simon