I worked with functional languages and while I like the concept, I don't care much for the attitudes of the the people proclaiming it's the best thing ever.
It's really not that different from any other language. Sure, there's delayed evaluation, which is extremely cool, but in the the it's just a shorthand notation, just like classes is a useful shorthand notation for writing object oriented code.
I guess I've been tained by the fact that my real language of choice is Lisp, a language which allows me to do imperative, functional and object oriented programming in the same program. It also teaches you that none of these tehniques are any special. Useful, yes, but they are not the magic "do what i mean" feature functional advocates make it out to be.
Ever coupld of months some know-it-all, usually with a few degrees in CS come out saying that "programming sycks", "we haven't eveolved in 20 years", "we need better tools that can automate things" and usually finishes off with "this can't go on! We're working on a tool that will transform programming!".
Then you usually don't hear from them again. Want to know why? Because they're wrong.
The fact is that regardless of what methodologys used when developing software, in the end you are simply giving instructions to the computer what to do. No matter how many layers of tools you try to add on top of this, in the end you want to giveinstructions to the computer how it should solve the problem at hand. What it all boils down to is that the more complex the problem is, the more detailed must your instructions to the computer be.
Allow me to give an example: If you have some calculations to perform you can do that in a spreadsheet app, but when your formulas grows more complex you start scripting the spreadsheet. After a while even that isn't enough and you write a separate VB (or other scripting language) app to do this for you. Again, the problem might grow to the level that even your scripting language can't handle it and you sit there with a full app implemented in Java or C++ which solves your original problem. If you happen to be a CS professor, you will start thinking: "why did I have to write this app so solve this simple problem? Programming sucks! We haven't evolved in 20 years! I'm going to write an app that takes the complexity out of programming!", you will publish an article on this, and then you'll spend the next couple of years trying to solve a problem that doesn't exist.
Are you old enough to remember the craze about 4GL? The reasoning behind that is exactly the same as what Charles Simonyi says:
Giving the former group tools to shape software will transform the landscape, according to Simonyi. Otherwise, you're stuck in the unsatisfactory present, where the people who know the most about what the software is supposed to accomplish can't directly shape the software itself: All they can do is "make a humble request to the programmer." Simonyi left Microsoft in 2002 to start a new company, Intentional Software, aimed at turning this vision into something concrete.
Right. Brining programming to non-programmers. Think about it. Does it make sense? As soon as you start programming, you ARE a programmer. Why, then, do you want to limit yourself to a limiting point-and-click tool? This is where 4GL failed. While making it very easy to connect a few database tables together, the real business logic was hard or even impossible to create, and the resulting apps were extremely difficult to understand and impossible maintain.
One of the best tools that helps programming in recent years is, in my opinion, IDEA. It's a Java IDE that doesn't assume that the programmer is stupid and doesn't understand programming, but rather automatically creates the boilerplate code for you while you write the code. You still work with the code, you just don't have to write all of it.
There's an enormous difference between IDEA and the "4GL mindset". While IDEA acknoledges that the best way of writing code is by typing in the instructions that will actually run, the 4GL mindset assumes that people are incapable of learning this and need fancy icons instead. Allow me to clarify:"icons is not a good way of representing computer code.
It feels to me that the people who claim these things have realised that they are not the worlds bet programmers. They realised that programming can be hard, but instead of acknowledging this and try to be better, they decide that it's the "state of programming today" that is at fault. That if they don't know how to write good code it's got be the tools fault. It couldn't possible be that some non-academics can be better programmers than them, now could it?
Except you're forgetting that the guy is from the US. Although non-americans (like myself) often spell rather poorly, the types of errors he made (u = you, cann't = can't) is typical of poorly educated native english speakers.
Non-native english speakers mistakes are usually grammatical in nature. The spelling is usually correct.
His post history kind of hints that he's Indian, but my guess is that he's a US troll. I've never seen indians (or any non-US-person in fact) spell like that.
Sorry for posing AC, but this might be seen as a troll by some. Actually it isn't, it's called "showing off".:-)
Here in sweden, getting good upload speeds is quite common. I am getting my 2 mbit upload/download upgraded soon, and I will then be on par with all my friends who has 10 mbit upload and download. There are some lucky people who has more than that.
Now for the good part. The price for this is around 40 USD per month.:-)
Well, first of all you obviously wasn't part of the early presentations by Bill Joy. You're describing the situation 5 years later.
The presentations went something like this: "look! now we can have our devices discover all the services they need! the digital camera can find the file storage to save the pictures on!". A pity they had no interest in actually defining or even suggesting how the file storage should be accessed. The people over at jini.org were "working on it" but nothing had happened over a year later.
If I had designed a file storage, do you seriously think the digial camera manufacturers would comply with it?
If it works better now, fine. I'm happy for you. Personally I lost all interest in Jini, and Obje seems to be exactly the same thing. You very elegantly avoided the core issue, explaining why Obje would succeed where Jini failed.
I have that book in my bookshelf. I did read it when it came out. It was after I had read the book I concluded that Jini wouldn't work.
Apparently it's better now, but in the 1.0 version you had to write (or copy&paste) a hundred or so lines of boilerplate code, and the deployment model was an extreme pain. The description on how to create the Hello World service is 24 pages! And that is after 120 or so pages of theoretical discussion. Why the designers of Jini (or at the very least, the authour of the book) didn't provide some helpers to do this is beyond me.
I just wanted you to know about what it's like to read his work. Now, it's not just his fault, it's the Jini designers fault too, but he certainly was an advocate for the technology in the book.
I remember being in the middle of all the Jini buzz a few years ago. I remember talking to some of the Jini designers, asking them for the API's I should use when talking to a distributed file storage service. I was under the impression (still am, actually) that such a service would be one of the first to be defined. It's easy enough, should just be a few interfaces. Could be designed in an hour.
Now, what was the reply? Something in the lines of: "it is not our job to define the standard API's. That's up to the community". Well, at that time I concluded that Jini would never succeed. And, it seems, Obje is falling into the same trap.
Protocols are needed. Regardless of wether they are defined in terms of binary data, XML schemas, or Java interfaces. You need them to be able to know what you are saying to the other party, and what it is trying to tell you.
I had some really neat ideas actually. I wanted to use stuff like distributed file storage. But there was no way I'd be writing my own interfaces that no one else would use. So, in the end, I didn't care much for Jini and apparently it was the right choice.
As far as I can tell, there is no difference between Obje and Jini, the designers are going to fall into the exact same trap. I would love it if someone showed me why Obje would succeed where Jini did not.
By the way, there were a lot of other things that sucked about Jini, but that had more to do with the crappy implementation than the actual concept.
Yes, that is true. One of the solutions, coaxial rotors, are used in what is possibly the best combat helicopters today: The Ka-50 and the Ka-52 attack helicopters.
These are the standardised (ISO-standard mostly) languages I can think of right now:
C and C++ - One billion libraries, very poor compatibility between platforms, naming conventions differs wildly between teams and my favourite point: not even the character sets are the same.
Lisp - Nice language, very flexible, very much like Java in many ways. However, few users, no standard libraries for stuff like XML processing or graphics. Even basic stuff like networking is not entirely compatible between implementations.
ADA - Exactly how do you go about adding new stuff to that language? Anything even remotely like the JCP? (yes, that was a rhetoric question)
ECMAScript - To be fair to the standardisation process, let's just conclude that it sucked as much before it got standardised as after.
SQL - If standardisation is so great, why can't I ever move SQL code from one database to another? I can in Java, and it's not even standardised!
You've obviously not very familiar with software patents. Chances are, when you sit down to write something more complex than "Hello world", you'll infringe on somebody's patent somewhere. Sun don't have the ability to state that you are free to implement Java, because even if they don't hold any patents (and you can never be sure of that), it doesn't mean that nobody does. Sun aren't omniescent.
And this is different to any other language exactly how?
The point I'm trying to make is that you should not compared with C# if you want examples pointing at how bad Sun is in this respect.
You have to understand that standardising the syntax of the language means nothing. This is true for both Java and C#. The core syntax of the language is such a small part of the entire platform. You implied that Microsoft is somehow "better" than Sun because they standardised the syntax of the language.
MS is actuallly worse than Sun because they are sneaky. You aren't even allowed to re-implement the MS libraries. Well, they have said that it's mostly OK, but they can pull out various patent lawsuits (patent infrigement?) at a moments notice if a free implementation becomes too good.
Java, on the other hand, is safe to re-implement. Of course, you'll have to play catchup with Sun for every new version, but you can always join the JCP and get a say in what is added to the language. Exactly how do you do that with.net?
Java isn't a standard. It's a specification with multiple implementations. That's the whole point. C# has been submitted to ECMA for standardization, the same way C and C++ have been standardized.
While youre words may be accurate, the meaning is very cunningly incorrect. Yes, C# the language has been submittedto ECMA. However, implementing the language is the easy bit. The hard part is implementing all these libraries that run on top of Java. The libraries is what make Java great and without them there would be no reason to use Java.
Last I looked Microsoft hadn't submitted the class libraries to ECMA, so stop claiming they are for open standards. The whole C# submitted to ECMA thing was a huge publicity stunt, and apparently it worked.
It seems to me that the Linux/Open Source community has already chosen.net, it's sad really... There are much more complaints about Sun and Java than against.net and Microsoft on this site. I just can't figure it out.
Umm... You don't even have to RTFA to see that the article is about GNOME. And GNOME is doing exactly what you were asing for: standardising the L&F of the apps.
99% of my apps are GNOME compliant. With the exception fo XChat, they are also HIG compliant. That's better that the Windows desktop I used at work (before switching to Linux there as well).
After seeing the lists of files SCO has published, it's now clear why they have requested every single source release of AIX and Dynix.
If you look at the list, you'll notice that most of the files are header files. These header files are probably available in the off-the-shelf releases of these OS'es. They have then probably does some compare and came up with the resulting list.
If they get all sources from IBM, they probably will perform the exact same comparison, but on all the new files they got.
However, we shouldn't be so worried about this. According to one post on groklaw, the contents of these files are mostly #include's anyway.
Slashdot Mirror
It's really not that different from any other language. Sure, there's delayed evaluation, which is extremely cool, but in the the it's just a shorthand notation, just like classes is a useful shorthand notation for writing object oriented code.
I guess I've been tained by the fact that my real language of choice is Lisp, a language which allows me to do imperative, functional and object oriented programming in the same program. It also teaches you that none of these tehniques are any special. Useful, yes, but they are not the magic "do what i mean" feature functional advocates make it out to be.
Then you usually don't hear from them again. Want to know why? Because they're wrong.
The fact is that regardless of what methodologys used when developing software, in the end you are simply giving instructions to the computer what to do. No matter how many layers of tools you try to add on top of this, in the end you want to giveinstructions to the computer how it should solve the problem at hand. What it all boils down to is that the more complex the problem is, the more detailed must your instructions to the computer be.
Allow me to give an example: If you have some calculations to perform you can do that in a spreadsheet app, but when your formulas grows more complex you start scripting the spreadsheet. After a while even that isn't enough and you write a separate VB (or other scripting language) app to do this for you. Again, the problem might grow to the level that even your scripting language can't handle it and you sit there with a full app implemented in Java or C++ which solves your original problem. If you happen to be a CS professor, you will start thinking: "why did I have to write this app so solve this simple problem? Programming sucks! We haven't evolved in 20 years! I'm going to write an app that takes the complexity out of programming!", you will publish an article on this, and then you'll spend the next couple of years trying to solve a problem that doesn't exist.
Are you old enough to remember the craze about 4GL? The reasoning behind that is exactly the same as what Charles Simonyi says:
Right. Brining programming to non-programmers. Think about it. Does it make sense? As soon as you start programming, you ARE a programmer. Why, then, do you want to limit yourself to a limiting point-and-click tool? This is where 4GL failed. While making it very easy to connect a few database tables together, the real business logic was hard or even impossible to create, and the resulting apps were extremely difficult to understand and impossible maintain.
One of the best tools that helps programming in recent years is, in my opinion, IDEA. It's a Java IDE that doesn't assume that the programmer is stupid and doesn't understand programming, but rather automatically creates the boilerplate code for you while you write the code. You still work with the code, you just don't have to write all of it.
There's an enormous difference between IDEA and the "4GL mindset". While IDEA acknoledges that the best way of writing code is by typing in the instructions that will actually run, the 4GL mindset assumes that people are incapable of learning this and need fancy icons instead. Allow me to clarify:"icons is not a good way of representing computer code.
It feels to me that the people who claim these things have realised that they are not the worlds bet programmers. They realised that programming can be hard, but instead of acknowledging this and try to be better, they decide that it's the "state of programming today" that is at fault. That if they don't know how to write good code it's got be the tools fault. It couldn't possible be that some non-academics can be better programmers than them, now could it?
So
Non-native english speakers mistakes are usually grammatical in nature. The spelling is usually correct.
His post history kind of hints that he's Indian, but my guess is that he's a US troll. I've never seen indians (or any non-US-person in fact) spell like that.
I think they'd run out of beer commercials with naked chicks pretty quickly if they tried to do that.
You get what you deserve, I guess.
Oh, and the things I said are true.
Here in sweden, getting good upload speeds is quite common. I am getting my 2 mbit upload/download upgraded soon, and I will then be on par with all my friends who has 10 mbit upload and download. There are some lucky people who has more than that.
Now for the good part. The price for this is around 40 USD per month. :-)
The presentations went something like this: "look! now we can have our devices discover all the services they need! the digital camera can find the file storage to save the pictures on!". A pity they had no interest in actually defining or even suggesting how the file storage should be accessed. The people over at jini.org were "working on it" but nothing had happened over a year later.
If I had designed a file storage, do you seriously think the digial camera manufacturers would comply with it?
If it works better now, fine. I'm happy for you. Personally I lost all interest in Jini, and Obje seems to be exactly the same thing. You very elegantly avoided the core issue, explaining why Obje would succeed where Jini failed.
Apparently it's better now, but in the 1.0 version you had to write (or copy&paste) a hundred or so lines of boilerplate code, and the deployment model was an extreme pain. The description on how to create the Hello World service is 24 pages! And that is after 120 or so pages of theoretical discussion. Why the designers of Jini (or at the very least, the authour of the book) didn't provide some helpers to do this is beyond me.
I just wanted you to know about what it's like to read his work. Now, it's not just his fault, it's the Jini designers fault too, but he certainly was an advocate for the technology in the book.
Now, what was the reply? Something in the lines of: "it is not our job to define the standard API's. That's up to the community". Well, at that time I concluded that Jini would never succeed. And, it seems, Obje is falling into the same trap.
Protocols are needed. Regardless of wether they are defined in terms of binary data, XML schemas, or Java interfaces. You need them to be able to know what you are saying to the other party, and what it is trying to tell you.
I had some really neat ideas actually. I wanted to use stuff like distributed file storage. But there was no way I'd be writing my own interfaces that no one else would use. So, in the end, I didn't care much for Jini and apparently it was the right choice.
As far as I can tell, there is no difference between Obje and Jini, the designers are going to fall into the exact same trap. I would love it if someone showed me why Obje would succeed where Jini did not.
By the way, there were a lot of other things that sucked about Jini, but that had more to do with the crappy implementation than the actual concept.
Oh, and if you don't get the tounge-in-cheek part of the above, don't spend the mod points.
Yes, that is true. One of the solutions, coaxial rotors, are used in what is possibly the best combat helicopters today: The Ka-50 and the Ka-52 attack helicopters.
These are the standardised (ISO-standard mostly) languages I can think of right now:
C and C++ - One billion libraries, very poor compatibility between platforms, naming conventions differs wildly between teams and my favourite point: not even the character sets are the same.
Lisp - Nice language, very flexible, very much like Java in many ways. However, few users, no standard libraries for stuff like XML processing or graphics. Even basic stuff like networking is not entirely compatible between implementations.
ADA - Exactly how do you go about adding new stuff to that language? Anything even remotely like the JCP? (yes, that was a rhetoric question)
ECMAScript - To be fair to the standardisation process, let's just conclude that it sucked as much before it got standardised as after. SQL - If standardisation is so great, why can't I ever move SQL code from one database to another? I can in Java, and it's not even standardised!
You have to understand that standardising the syntax of the language means nothing. This is true for both Java and C#. The core syntax of the language is such a small part of the entire platform. You implied that Microsoft is somehow "better" than Sun because they standardised the syntax of the language.
MS is actuallly worse than Sun because they are sneaky. You aren't even allowed to re-implement the MS libraries. Well, they have said that it's mostly OK, but they can pull out various patent lawsuits (patent infrigement?) at a moments notice if a free implementation becomes too good.
Java, on the other hand, is safe to re-implement. Of course, you'll have to play catchup with Sun for every new version, but you can always join the JCP and get a say in what is added to the language. Exactly how do you do that with .net?
Last I looked Microsoft hadn't submitted the class libraries to ECMA, so stop claiming they are for open standards. The whole C# submitted to ECMA thing was a huge publicity stunt, and apparently it worked.
It seems to me that the Linux/Open Source community has already chosen .net, it's sad really... There are much more complaints about Sun and Java than against .net and Microsoft on this site. I just can't figure it out.
To SCO: Look yourself in the mirror, dude.
Poor choice of words. What is Windows anyway? Operating system? Desktop environment?
99% of my apps are GNOME compliant. With the exception fo XChat, they are also HIG compliant. That's better that the Windows desktop I used at work (before switching to Linux there as well).
No humans ever lived in partial gravity either.
"this is slashdot" is the slashdot version of godwins law.
Yeah, but SCO's way is the most innovative. Don't you think?
If you look at the list, you'll notice that most of the files are header files. These header files are probably available in the off-the-shelf releases of these OS'es. They have then probably does some compare and came up with the resulting list.
If they get all sources from IBM, they probably will perform the exact same comparison, but on all the new files they got.
However, we shouldn't be so worried about this. According to one post on groklaw, the contents of these files are mostly #include's anyway.