James Watson
Posts: 2024
Nickname: watson
Registered: Sep, 2005
|
|
Re: Five Things Java (and Ruby) Developers Need to Know about Scala
|
Posted: Jan 10, 2007 6:13 AM
|
|
> "Speed doesn't count? Do mean development speed or
> execution speed. Execution speed does matter in a lot of
> shops (but admittedly more than it should in many of
> those.)"
>
> Like you say, speed is relative. It certainly counts, but
> the algorithms, the use of external database engines, the
> reuse of existing fast libraries, and such, all contribute
> to the final speed that the user might presence. Often
> said as "glue languages", the scripting languages aren't
> known for heavy lifting anyway, but they get used all the
> time for many things, nonetheless. :-)
I don't argue with you here but I don't see Scala as a scripting language. You can use it in an interpreter mode IIRC but I think generally people compile it to bytecodes.
> "I don't get your point here. The vast number of libraries
> written for Java is a big bonus to me. I use Jython (maybe
> not for long) and I often turn to the Java libraries for
> certain things over the Python versions. Not to mention,
> Java is supported on the platform I am using and Python
> isn't (I'm pretty sure.)"
>
> My short experience with JRuby gave me a clue:
> interoperability. For example, you may want to implement
> an interface, an abstract class, and sometimes you might
> need it to be accessible from Java itself. To be able to
> override methods and provide more of the native Java
> functionality from another language does not seem to be
> that easy to get going. Also, I can read a file in Ruby
> with "IO.read(file_path)". In JRuby it's possible to do
> the same thing. But can you do it like that in BeanShell?
> Or in Jython? There are difference, sometimes large,
> because the Java libraries are not known for providing
> easy to consume APIs.
Jython is just a version of Python with some extra features. You can read a file by calling open(). What I generally do is make helper modules to simplify access to the Java functionality.
> For instance, when I added some support for the Simple Web
> Framework (Java) to a JRuby prototype, I noticed that it
> had some helper classes in its source code. I think many
> Java applications and libraries recreate their own "helper
> classes" all the time, maybe because they want a small
> footprint and don't want to create a dependency on large
> Apache Jakarta libraries, but I am not sure. But the point
> is that the wheel reinvention is fulled by the uncaring
> core Java APIs. And a scripting language might suffer from
> the wheel reinvention as well, because easy to reuse APIs
> might not come "free". :-)
I'm not really talking about reinventing the wheel. There are a lot of libraries in Java all over the place. Not all of them are open source. Many shops have millions of lines of critical applications written in Java. If they've written them well, they may be able to use them from a language like Jython or Scala. They can then avoid the huge risks of the 'big rewrite'.
> "I don't get this XML thing with languages. Why is
> everyone in such a race to make their language more like
> COBOL. We need good XML-Object libraries, not native
> support. I dread the day I start seeing stinking XML
> hard-coded all over the place. "
>
> I have been using JSON for streaming data as of late
> (converted to it from YAML a few days ago). In Ruby, YAML
> is largely used for configuration files. I think that with
> the JSON popularity increasing, it will become the most
> popular alternative to XML.
>
> When I am developing, I might not know yet the design of
> the configuration files. Sometimes you might want to store
> the information in the database. You could use JSON for
> that as well. Also, in Ruby, a separated Ruby file can be
> used for configuration. For example, I use one for each
> Web Application, I use one for each Web server. And I even
> use one for a Web Dispatcher I created recently.
>
> The alternatives to XML are accumulating. With a scripting
> language, you might have more options at your hands. The
> problem is that scripting languages allow for faster
> development and lots of "wheel reinventions" in short
> periods of time (the increased productivity allows for
> that), and XML use becomes awkward at best.
I've heard or JSON but I need to look into it more. I was really thinking something else here. I don't see why we need to make serialization formats part of general programming language. We need better approaches for serializing Object graphs into different formats. For example lets say JSON does become the dominate format, then we'll still be stuck with XML because it's all through the code. From a more general standpoint, we shouldn't be hardcoding serialization structures. Making this part of the language is just going to encourage people to do this and I can't see how that's good.
I was just in a meeting yesterday where we have to write a file to the government and they have changed the file structure every year for the last five years. The program is written in RPG and the file structure is hardcoded and compiled into the program. Every year someone has to go in and modify the program and recompile it instead of just adding or modifying a configuration that defines how the data is output to the file. Sure you might need to modify the program anyway but not for every little change. This makes me want to scream because it's as if no one else sees this as a problem and we are headed full-steam into this same situation with XML.
|
|
Previous Topic
