[Scala] looks like ECMAScript (commonly known as Javascript), except worse. If you mean Scala is concise like ECMAScript, well, yes. But where ECMAScript is very dynamically typed, Scala has a strong static typing system. Type inference makes Scala strong type system less of a burden on the programmer than the (weaker) type system of Java.
The key to Java's success is that it got out of the syntactic sugar rat race and pushed all the functionality into the API. Need new features? Write them as APIs. Java has some deficencies here: it is extremely difficult to extend somebody else's library in Java. So, as you say, everybody writes another. Wouldn't it be nicer if the existing libraries were extensible?
Scala would be a very poor language for large projects Stong typing + concise + existing libraries + extensibility = excellent language for large projects.
It fails the KISS test Programing isn't hamburgers; higher metalevels can be a good thing.
[Scala] doesn't appeal to most of the people who want a better Java. It's a language that takes a totally different direction, which is a good thing, but it's not even approximately the same thing as Java with a cleaned-up class library. Scala can be written much like Java. It does have cleaned up versions of some basic Java libraries such as collections. Also it makes using existing java libraries less ugly; for example
jdbc like:
val insertPerson = conn prepareStatement "insert into person(type, name) values(?, ?)"; for (val name <- names) insertPerson<<rnd.nextInt(10)<<name<<!;
I can't speak for most people, but it's the better Java I was looking for.
Person 1 buys a $50000 house. Person 2 buys 2 $500,000 houses.
Person 1 will have about $2500 in interest--- this is significantly less than the standard family deduction. So while in theory the interest is deducable in practice it is not.
Person 2 will have about $50,000 in deductable interest and will itemize (subject to the amt).
It is not that person 1 was stupid, it's that the tax code is sturctured to help the well-to-do buy houses at the expense of the less well to do.
temporary, since laws required the companies to at least minimally restore the areas effected
That's a nice theory, the practice is often different. The (Federal) law requires the contours to be more or less restored--- this falls to the state EPA to enforce; in WV the EPA chooses to enforce rather laxly. Typically, the hills are forested pre minining and not forested after reclaimation. The happiest example of reclamation I know of is the Wilds, a large zoo in Ohio. A good use of the reclaimed land, making its difference from the surronding forests a feature.
In WV these changes are especially unfortuante as the other two large industries in the state--- logging and tourism--- both are happier with forested mountains than grassy hills.
Java is two distinct things: 1) a language and 2) a runtime.
The Java language is ok, but not great.
The Java runtime is somewhat better: the JVM is faster than most and the libraries are extensive.
The Scala (or Groovy or Beanshell) compiler is a.jar (a Java application in sense 2) that reads.scala files and creates.class files. Those class files are Java applications (again in sense 2).
All these languages can also be interpreted. Other languages-- notably variants of ruby, python, scheme and common lisp--- also use the java runtime.
The Java libraries are large and useful. The JVM is widely deployed, reasonably fast, cross platform and garbage collected. These traits make the JVM a good platform.
Java, the language, succedes as is a better C++ (for most purposes); but it still has large downsides. It's not duck typed and it doesn't have a class inference system. It's verbose; so people write tools to write Java, but the language makes that harder than it should be. Still, you end up with a lot of code generated (by the IDE or whatnot)--- Foo foo; getFoo() & setFoo are standard(!) and that is just the beginning. This generated code is inconvenient and adds no value. Its possible to do higher order programing in Java, but not natural.
Other languages are more powerful...but the lack of good library support has left them at best as niche tools or academic toys. Implementing in the JVM (or CLR) solves that problem. Also, lots of existing code is in these environments, and the JVM based languages typically interact well with these programs.
Groovy is one of these; kind of a Ruby in the JVM. Scala is even better, I think: Ruby meets Haskell in the JVM.
As to what happened to the high point of Arabic culture, thats easy, we destroyed it in The Crusades.
I assume you are not counting the crusades in Palestine. These crusades were a mere pinprick in Arab power. They were largely ignored in Arab writtings at the time-- because they didn't much matter. Consider this map of Mongol Empire. At the time of this map there is a Crusader state at Jerusalem-- just west of the battle at Ain Julat. But a small country of semibarbarians--- with trade goods--- is no big deal. Real barbarians overrunning half of Islam is a big deal.
If you mean just the Reconquista, yes there were tradgedies there. But at the same time Islam was conquering Bzyantium; Constantinople had been the most important Christian city for a thousand years.
Do you realize it is illegal in most states for an ordinary citizen to read try to help another citizen by answering questions about what a law even means - for attempting to understand on our own the laws the govern our lives?
Yup, fewer people is why technology progressed so much faster in the old days. Not.
Our main shortage now (as always) is of cluons. More people can mean more cluons--- given a reasonable infrastructure; fortunately the infrastructure is reasonable for a higher percentage of people than has ever been the case before. (ie less hunger, better education, better learning and communication infrastructure)
I did a 48 day for several weeks some years back. I'd wake up in the evening very well rested and go to work. I found it easy to get into a coding zone and have a nice long hack. In the morning I'd consult with my coworkers and then take 12h off-- this was a nice long block of time, pratically a day off. Then sleep for 16h.
It was a very productive time coding for me; but somewhat inconvenient for my wife and coworkers--- I was writting a lot of code and wasn't around much to talk about it. Also, things that happen once a week were awkward. Eventually, I finished the project and switched to normal days to integrate it with the rest of the code(rs).
These tests aren't entirely safe either. A 40 yr old woman has a 1% chance of the baby having down's syndrome; the chance of amniocentesis inducing miscarrage is (something like) 0.5%.
1 in 200 sounds very high to me for a procedure that can not help the child.
The battery they will use is also probably LIthium which makes it lighter and more resistent to charge fade. Did I mention it is also much smaller?
Um, I couldn't disagree more. Rechargeable AAs also use Lithium. Plus you can charge them separately from the device, replace them with better batteries when the better batteries come along next year, and, in a emergency, use alkalines from any convenience store in the world.
Standard size batteries win unless the device form factor is very strange, which is not the case here.
BTW: energy is what's conserved here; Joules or milliwatt hours are the right metric.
I can't remember the last time I had issues with code because I changed platform, OS, or even JVM version. It's to the point where I don't think about it anymore.
Lucky you. jdk1.4 bit our back end app in two ways I remember. First, the "assert" keyword broke our build. No big deal, but a pain. Second and much worse, classes in the default classpath became unusable. This made a third party piece unusable. Granted, the third party's code was in poor taste, but it 1) was just like Sun's examples 2) worked and 3) was (arguably) compliant with the spec.
Sun broke their working code. We lost functionallity because of this.
Nevermind the times the JDBC guys break their interfaces. They have even changed return types! You can't write code that implements the interface in both versions. Thanks guys, you should win an award for most fsck'ed.
Different OSs, no problem. Different versions of the JDK, watch out.
Slashdot Mirror
That's great! Thanks.
Uh, these laptops have a plain old 12VDC connector, no hand cranking required.
Haven't you heard? Java 2.0 is out. It broke source but not binary compatability. It's called Scala.
Person 1 buys a $50000 house. Person 2 buys 2 $500,000 houses. Person 1 will have about $2500 in interest--- this is significantly less than the standard family deduction. So while in theory the interest is deducable in practice it is not. Person 2 will have about $50,000 in deductable interest and will itemize (subject to the amt). It is not that person 1 was stupid, it's that the tax code is sturctured to help the well-to-do buy houses at the expense of the less well to do.
Fortunately, Spinal Tap and music have very little to do with each other.
temporary, since laws required the companies to at least minimally restore the areas effected
That's a nice theory, the practice is often different. The (Federal) law requires the contours to be more or less restored--- this falls to the state EPA to enforce; in WV the EPA chooses to enforce rather laxly. Typically, the hills are forested pre minining and not forested after reclaimation. The happiest example of reclamation I know of is the Wilds, a large zoo in Ohio. A good use of the reclaimed land, making its difference from the surronding forests a feature.
In WV these changes are especially unfortuante as the other two large industries in the state--- logging and tourism--- both are happier with forested mountains than grassy hills.
The Java language is ok, but not great.
The Java runtime is somewhat better: the JVM is faster than most and the libraries are extensive.
The Scala (or Groovy or Beanshell) compiler is a .jar (a Java application in sense 2) that reads .scala files and creates .class files. Those class files are Java applications (again in sense 2).
All these languages can also be interpreted. Other languages-- notably variants of ruby, python, scheme and common lisp--- also use the java runtime.
Java, the language, succedes as is a better C++ (for most purposes); but it still has large downsides. It's not duck typed and it doesn't have a class inference system. It's verbose; so people write tools to write Java, but the language makes that harder than it should be. Still, you end up with a lot of code generated (by the IDE or whatnot)--- Foo foo; getFoo() & setFoo are standard(!) and that is just the beginning. This generated code is inconvenient and adds no value. Its possible to do higher order programing in Java, but not natural.
Other languages are more powerful...but the lack of good library support has left them at best as niche tools or academic toys. Implementing in the JVM (or CLR) solves that problem. Also, lots of existing code is in these environments, and the JVM based languages typically interact well with these programs.
Groovy is one of these; kind of a Ruby in the JVM. Scala is even better, I think: Ruby meets Haskell in the JVM.
I assume you are not counting the crusades in Palestine. These crusades were a mere pinprick in Arab power. They were largely ignored in Arab writtings at the time-- because they didn't much matter. Consider this map of Mongol Empire. At the time of this map there is a Crusader state at Jerusalem-- just west of the battle at Ain Julat. But a small country of semibarbarians--- with trade goods--- is no big deal. Real barbarians overrunning half of Islam is a big deal.
If you mean just the Reconquista, yes there were tradgedies there. But at the same time Islam was conquering Bzyantium; Constantinople had been the most important Christian city for a thousand years.
Hey, you can't say that!
Yup, fewer people is why technology progressed so much faster in the old days. Not.
Our main shortage now (as always) is of cluons. More people can mean more cluons--- given a reasonable infrastructure; fortunately the infrastructure is reasonable for a higher percentage of people than has ever been the case before. (ie less hunger, better education, better learning and communication infrastructure)
It was a very productive time coding for me; but somewhat inconvenient for my wife and coworkers--- I was writting a lot of code and wasn't around much to talk about it. Also, things that happen once a week were awkward. Eventually, I finished the project and switched to normal days to integrate it with the rest of the code(rs).
To pick a nit, the church they were escaping was the Anglican church.
If you aren't a person who would be more productive in an office, get a cube.
sqlplus is annoying. One free substitute that works much better (at least on unix) is Henplus.
Oracle does use a full table lock for modifications to table structure.
1 in 200 sounds very high to me for a procedure that can not help the child.
Um, I couldn't disagree more. Rechargeable AAs also use Lithium. Plus you can charge them separately from the device, replace them with better batteries when the better batteries come along next year, and, in a emergency, use alkalines from any convenience store in the world.
Standard size batteries win unless the device form factor is very strange, which is not the case here.
BTW: energy is what's conserved here; Joules or milliwatt hours are the right metric.
I thought interlock protocols could be used to foil the man-in-the-middle attack. Am I out of date?
Lucky you. jdk1.4 bit our back end app in two ways I remember. First, the "assert" keyword broke our build. No big deal, but a pain. Second and much worse, classes in the default classpath became unusable. This made a third party piece unusable. Granted, the third party's code was in poor taste, but it 1) was just like Sun's examples 2) worked and 3) was (arguably) compliant with the spec.
Sun broke their working code. We lost functionallity because of this.
Nevermind the times the JDBC guys break their interfaces. They have even changed return types! You can't write code that implements the interface in both versions. Thanks guys, you should win an award for most fsck'ed.
Different OSs, no problem. Different versions of the JDK, watch out.