Todays languages don't differ much. There are basic syntactical differences, but in principal they are all the same (except LISP and Prolog, which are really different approaches).
Java, C++, Python... who cares?
A somewhat really different "language" are for example GUI-Builders. Why bother with a textual language, when you can do this with your mouse.
Or perhaps programming in 100 Years will mean training neural nets (which will have nothing to do with writing programs, but providing examplary inputs). Still you could call this a language.
This guy is talking about todays problems. And even today I do not care if a string is implemented using a list or an array of chars. This has nothing to do with the language itself.
[Classloading] > Accepted this is a problem. Classloaders are a little difficult to understand, but they are not a problem!
Classes loaded by different classloaders may never have the same type, because they might be completly different, implement different interfaces and have nothing at all to do with each other.
Also you could load a class java.lang.String from a different Classloader and pass it to other classes. The class is declared final, but who cares, if you can just load a different class in a different classlaoder? This would cause huge security problems.
Classloaders are implemented the right way. So don't change this (The exception messages could be improved though).
Working 70h might work for some time, but when the "great programmer" doing this leaves the company, nobody will be able to maintain the code... great !
> Also, you can do full inheritance, etc. AMONG THE DIFFERENT.net languages.
> Write a form in C#, inherit it in VB, modify it, inherit the interface back into C#.
Have you ever looked at Borland Delphi and C++ builder !?! They ave been doing this for ages...
Actually there is a COM implementation for Linux : http://www.softwareag.com/entirex/download/free_do wnload.htm... but I don't think using COM with Linux could do any good...
This is madness... imagine what happens if you have two 10 GB files, which are exactly the same. Open one of them, read one byte, write the same byte back again and close the file....
What happens ?
When opening the file a new copy has to be created. Then you can work on this copy. After closing the file the checksum is calculated (requires reading the whole file). The checksum is the same, because you just read and wrote the same byte. But now you have to compare the two files bytewise. A checksum makes it only very impropable, that these files are really different files, but to be sure you have compare them.
After that the second copy can be deleted. wow... what kind of performance do you expect !?
Another problem is, that you might run out of diskspace, just by opening a file and writing one byte... GREAT. I WANT TO HAVE IT ! NOW !
Slashdot Mirror
Todays languages don't differ much. There are basic syntactical differences, but in principal they are all the same (except LISP and Prolog, which are really different approaches).
... who cares?
Java, C++, Python
A somewhat really different "language" are for example GUI-Builders. Why bother with a textual language, when you can do this with your mouse.
Or perhaps programming in 100 Years will mean training neural nets (which will have nothing to do with writing programs, but providing examplary inputs). Still you could call this a language.
This guy is talking about todays problems. And even today I do not care if a string is implemented using a list or an array of chars.
This has nothing to do with the language itself.
[Classloading]
> Accepted this is a problem.
Classloaders are a little difficult to understand, but they are not a problem!
Classes loaded by different classloaders may never have the same type, because they might be completly different, implement different interfaces and have nothing at all to do with each other.
Also you could load a class java.lang.String from a different Classloader and pass it to other classes. The class is declared final, but who cares, if you can just load a different class in a different classlaoder? This would cause huge security problems.
Classloaders are implemented the right way. So don't change this (The exception messages could be improved though).
... sounds a lot better to me ;)
... great !
http://slashdot.org/books/99/12/ 21/ 097256.shtml
Working 70h might work for some time, but when the "great programmer" doing this leaves the company, nobody will be able to maintain the code
> Also, you can do full inheritance, etc. AMONG THE DIFFERENT .net languages.
> Write a form in C#, inherit it in VB, modify it, inherit the interface back into C#.
Have you ever looked at Borland Delphi and C++ builder !?! They ave been doing this for ages ...
Actually there is a COM implementation for Linux : http://www.softwareag.com/entirex/download/free_do wnload.htm ... but I don't think using COM with Linux could do any good ...
What happens ?
When opening the file a new copy has to be created. Then you can work on this copy. After closing the file the checksum is calculated (requires reading the whole file). The checksum is the same, because you just read and wrote the same byte. But now you have to compare the two files bytewise. A checksum makes it only very impropable, that these files are really different files, but to be sure you have compare them.
After that the second copy can be deleted. wow ... what kind of performance do you expect !?
Another problem is, that you might run out of diskspace, just by opening a file and writing one byte ... GREAT. I WANT TO HAVE IT ! NOW !