Slashdot Mirror

The "nmap" project really is just a "placeholder". The FRS part is completely empty. If Fyodor doesn't want to put the current release there because of staleness concerns, fine, but it would be polite to at least put a "README.txt" there with a link to the real distribution-site and an explanation of why he chooses not to host the files on SourceForge.

And I'm not happy about all the recent changes (dropping OpenID authentication, for example), but other changes in the last year or so have been positive, SF is still a reasonable place to host a project, and it's good to not have all eggs in the one basket of GitHub. The field of core-technology-agnostic open-source hosting is shrinking, note last week's termination of CodeHaus and the in-process termination of Google Code (which offers a migrate-to-GitHub service, but also provides a link to SF's migrate-from-Google-Code service).

You might like Groovy. http://groovy.codehaus.org/

Foo foo; - which creates a private variable and Groovy auto-generates getters & setters (which you can write yourself if you wish)

accessing the member variable bar.foo actually calls the getter.

Groovy also has an implicit null check

foo?.bar()

And many other syntactical niceties and enhancements over Java.

Java is moving into archaic irrelevance faster than ever. That is, the language itself.

The JVM, however, is now more useful and relevant than it ever was. It used to be naught but an implementation detail. Now, rather, it's central to an entire ecosystem of languages that will inevitably send Java the way of C: used only when the greatest speed is necessary.

Scala is basically a next-generation Java. Java with functional programming, or really, vice versa. JRuby make Ruby actually scalable, given the presence of native threads and interoperability with existing enterprise libraries that commonly only ship in the form of Java or C# libraries. Clojure enables LISPers of yore and Schemers of new import explore functional programming as it used to be, without having to drop the wealth of Java libraries available. Ceylon, Groovy, Jython, and dozen of others are paving a way to give the JVM much more to do after Java becomes obsolete.

Java will never die - it'll just become like COBOL, Fortran, and C before it: used in enterprise software, operating systems, and outdated educational assessments.

Both Ant and Maven can compile C/C++ code, either through native support or via plugins.

Ant: http://codemesh.com/products/junction/doc/ant_cpp.html
Maven: http://mojo.codehaus.org/maven-native/native-maven-plugin/ and http://blog.bigpixel.ro/2012/07/building-cc-applications-with-maven/

Mind you, we have so many build tools available, why not just pick one that suites you and your target environment? (eg make for C/C++, groovy/ivy/maven for Java, etc).
eg cmake and scons all are popular as well...

Do it with MySQL and a programming language of your choice and output to spreadsheet. Put your code in version control (git). Profit.
Or if you really need to be using Excel, try something like this: http://groovy.codehaus.org/COM+Scripting

That is a bit of a pain, but if you're willing to take a small hit on performance you could always try groovy on the jvm: Operator Overloading

I happened to be grabbing a fresh copy of Jetty and noticed that Codehaus's logo has the same keyhole.

There a similar maven recipe for deploying a hadoop cluster

no, not now, but if you need it, you could easily fork http://mojo.codehaus.org/wagon-maven-plugin so that it could be used like that:mvn install deploy:deploy deploy:execute-on-remote.

Hadoop is easy -- having the analytical skills to express a problem as mapreduce in the first place is the hard part.

Agreed, math is more useful, my halfexpertise enables me to assert that the right way to express a problem for hadoop is it to formulate it into associative (a+b==b+a) and distributive (a*(b+c)==a*b+a*c) operators. But I only have two day of self-education on the subject, if someone more experienced would like to enlighten us, I would appreciate.

Boo is designed to be like Python, but with static typing. It's not easy for alternative languages to gain traction, though.

1. is an agile and dynamic language for the Java Virtual Machine
2. builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
3. makes modern programming features available to Java developers with almost-zero learning curve
4. supports Domain-Specific Languages and other compact syntax so your code becomes easy to read and maintain
5. makes writing shell and build scripts easy with its powerful processing primitives, OO abilities and an Ant DSL
6. increases developer productivity by reducing scaffolding code when developing web, GUI, database or console applications
7. simplifies testing by supporting unit testing and mocking out-of-the-box
8. seamlessly integrates with all existing Java classes and libraries
9. compiles straight to Java bytecode so you can use it anywhere you can use Java

Try out boo... http://boo.codehaus.org/

if you are using PHP and want purity with the ease of scripting language, you seriously need to jump ship.

If someone is using PHP and is open to jumping ship, they're going to jump to another server-side web programming language. But they're idiots, so odds are it will be another steaming pile, probably ASP.net and VB.

And there's nothing "pure" about anything related to Java; only managers think all that enterprisey crap is "pure." Java is fundamentally object-oriented, and that means it has no foundation in mathematics. Groovy just takes Java's original terrible idea and doubles down on it.

And let's not even talk about the "ease of a scripting language," because that just sounds like a steaming pile of weakness.

A pure solution to web development would be Yesod which guarantees type safety throughout your entire system using Haskell's extended Hindley-Milner type system.

if you are using PHP and want purity with the ease of scripting language, you seriously need to jump ship.

Whenever there is a discussion about op.ov. always comes an example with a vector, matrix, complex number, etc., i.e. with something math. I get the impression the only thing people write in C++ are some yet another math. library.

You know how other languages solve complex expressions? With Builders. Instead of abusing op. like that: xml << tag << text xml << tag << text Or whatever you can write:root { tag { text }, tag { text } }

Only because C++ don't have such features, it doesn't mean op.ov. is such a great idea.

You have to do that for named functions too. What's the difference between calling a function "+" and calling it "plus"?

Because it's not a plus. If there was no op.ov. I could tell you that it is a plus. But in C++ it's not a plus, it can be append, save, write, or something completely different. So why confuse the user more and instead just call the method what the method is doing?

Practically speaking, the name of complex operator+(complex const & rhs) is "+" to the same degree that the name of complex plus(complex const & rhs) is "plus". I feel quite strongly about this.

In C++ the name is not "plus" but the symbol "+". This symbol "+" can stand for anything you want, like append, save, concat, plus, add, etc. ppp. If you set a normal name for the operation like "append" or even "add" for complex numbers, the user of your library does not need to look up what the method is doing because it tells him in the name. It's all about a fluent API The Wikipedia is about method chaining but I rever here more to the designing a "API in a way that aims to provide for more readable code.".

So you don't think "+" is a good name for a function that adds two complex numbers, or that "[4]" is a good name for a function that returns the 5th element of an STL vector?

It is a good name for those particular examples. But why it is not in the C++ standard like in Java is "+" for Strings a concatenation? Operator Ov. is a good thing if it's in the language. Because this operators are well defined and they are a part of the language itself. It's like operators make a lot of sense in mathematic expressions, because operators are a part of mathematics. In mathematics nobody will wonder what 1+1 means, because it's well defined.

Operator should be part of a language and they should not just change the meaning. The same goes for keywords, are you going to argue that keywords overloading is a good idea?

Also, MS produces a much better integrated and more functional development environment that anything available in the FOSS world.

They're nowhere near the level of depth in the HPC world that linux has, but if they can do for parallel programming what VB did for programming generally (make is accesible to non-programmer domain experts) then it could be a compelling alternative.

If you want that, then you're probably looking for either X10 or Chapel which offer a huge leap forward in making massive scale parallel programming simpler and easier. Of course X10 is from IBM and has Eclipse and plugins as the dev environment, and the closest they offer to a Windows version of the compiler is one compiled against cygwin. Chapel is from Cray, and has practically no Windows support, save for a claim that you can get it working with cygwin. Both languages are excellently supported on Linux (which is, of course, what Cray and IBM supercomputers run these days). So it woudl seem the future of parallel programming is firmly in the linux camp.

I know I'm late to this story, but thought I'd try this.

I'm the original developer behind Perf4J: http://perf4j.codehaus.org/ . Perf4J is a library for performance tracking code in Java that uses the appender frameworks of popular Java logging frameworks to handle timing statements. The library has been pretty successful, but right now I don't really have the time to be the sole "despot" for this project. I'm looking for someone to essentially take this library over from me, or at the very least add some cool new features (#1 on my list is a port to logback).

This could be a great project for a college student wanting to get into open source. The library itself is not too big, I think it's easy to understand the design, and there are a ready list of features that users have requested. Plus, if you do a good job on it, while I can't 100% guarantee my company will hire you, I can 100% guarantee will give you an interview, and there is no better thing on your resume than showing that you can actually CODE a real project.

sure I do, it's a framework that allows quick generation of web-service servers/clients.

I really think interpolation is the right way for a programmer to express intent, and the compiler should be smart enough to extract it

There are already languages that do this rather well. It is one of my favorite parts about how Groovy handles SQL. The developer simply writes:

db.execute("select foo from bar where id = $id")

and the language is smart enough to extract that out and bind it correctly to the local "id" variable, with correct escaping, etc. Groovy makes it significantly harder to inject data into a string unsafely than safely.

I can't give opinions on all of these (and some are still in development at this time anyway), but here's a list of some languages with paralellism designed in:

• Erlang -- Very popular message passing/actor model based language.
• Scala -- A functional language with actor model concurrency for the JVM.
• Oz -- An exceptionally multiparadigm language.
• Occam-pi -- The modern version of the old occam for transputers; CSP style concurrency (I believe).
• Chapel -- Cray's parallel programming language for supercompters. Cray's entry into DARPA's HPCS programming language competition.
• X10
• Fortress -- Sun's language for serious scientific computing. It was Sun's entry into DARPA's HPCS programming language competition, but lost and is now open sourced.
• Eiffel SCOOP -- An effort to take a CSP model and make it elegantly compatible with object oriented programming

If you also know Java well, Groovy can also be an excellent tool, and is also useful in production environments.

http://groovy.codehaus.org/

Friends of mine have open-sourced savana, http://savana.codehaus.org/ a thin layer on top of Subversion that makes it easy to do all work in private branches before promoting to the trunk. A common workflow is:

sav createuserbranch mybranch --calls svn copy under the covers to create user branch named mybranch ... normal checkins using svn commit go to YOUR private branch ... when you are ready to promote your changes back to the trunk:
sav sync -- pulls in any changes made to trunk since your private branch was created so you can test locally
sav promote -- merges your changes back into the trunk

The thing I like about this thin "workspace managing" layer on top of Subversion is that for the most part you can take advantage of existing tool support for subversion (like integrated IntelliJ Idea and Eclipse support), as all of the savana commands just call svn commands under the covers.

not rto be forgotten in the language department:Scala and Groovy

Enter Scala: Scala achieves a brevity of syntax you see in Groovy and Ruby without sacrificing the static type system (it uses type inference).

While, certainly, Scala code is less verbose than Java, it is noticeably more verbose, in most cases, than Python, Ruby, or Groovy.

Marginally so, and mostly where type inference breaks down (e.g. public api's, but that's a Good Thing). If you code in Scala against standard Java libraries you will get verbose code same as you will with Groovy and Ruby. To properly judge Scala, look at samples coded against 'native' Scala libraries. And don't forget all the code you won't be writing for runtime type checking with Ruby or Python.

A very trivial comparison between Groovy and Scala can be seen here. A comparison of BDD-style tests between Scala, Java, and Ruby can be seen here.

Since Groovy and Ruby are dynamically typed, they are inherently slower than Scala.

Groovy, as I understand, supports but does not require static typing.

Not quite. From my understanding, if you declare an identifier to be of a certain type in Groovy and then go ahead and treat as something else, a type error would still only occur at runtime -- no type-related compilation errors! That's called strong typing, not dynamic typing. Please someone correct me if I'm wrong about Groovy on this. Also, using strongly typed variables in Groovy seems to be slower (as per the previous link, may have changed since).

The nieche Scala fits into is actually a testament that developers want the power and benefits of Ruby's syntax,

Scala's syntax, which is almost completely unlike Ruby's.

Agreed, but Scala and Ruby are both very malleable and share some very attractive features. To clarify my point: Java developers want some features popularized by Ruby (closures!), which Scala delivers.

A JVM language occupying a similar nieche is Fan, with a growing community and tool support coming right up.

Fan seems to fit much better into Groovy's niche (the almost-Ruby-but-intimately-tied-to-the-JVM niche, such as it is) than Scala's. Scala's real niche, it seems to me, is closer to Java's own niche.

Agreed about Scala's nieche being closer to Java's. I think we can fit Fan somewhere between Scala and Groovy: Fan's type system actually does support both static&dynamic (unlike Groovy, which is dynamic with support for strong&weak typing).

Enter Scala: Scala achieves a brevity of syntax you see in Groovy and Ruby without sacrificing the static type system (it uses type inference).

While, certainly, Scala code is less verbose than Java, it is noticeably more verbose, in most cases, than Python, Ruby, or Groovy.

Marginally so, and mostly where type inference breaks down (e.g. public api's, but that's a Good Thing). If you code in Scala against standard Java libraries you will get verbose code same as you will with Groovy and Ruby. To properly judge Scala, look at samples coded against 'native' Scala libraries. And don't forget all the code you won't be writing for runtime type checking with Ruby or Python.

A very trivial comparison between Groovy and Scala can be seen here. A comparison of BDD-style tests between Scala, Java, and Ruby can be seen here.

Since Groovy and Ruby are dynamically typed, they are inherently slower than Scala.

Groovy, as I understand, supports but does not require static typing.

Not quite. From my understanding, if you declare an identifier to be of a certain type in Groovy and then go ahead and treat as something else, a type error would still only occur at runtime -- no type-related compilation errors! That's called strong typing, not dynamic typing. Please someone correct me if I'm wrong about Groovy on this. Also, using strongly typed variables in Groovy seems to be slower (as per the previous link, may have changed since).

The nieche Scala fits into is actually a testament that developers want the power and benefits of Ruby's syntax,

Scala's syntax, which is almost completely unlike Ruby's.

Agreed, but Scala and Ruby are both very malleable and share some very attractive features. To clarify my point: Java developers want some features popularized by Ruby (closures!), which Scala delivers.

A JVM language occupying a similar nieche is Fan, with a growing community and tool support coming right up.

Fan seems to fit much better into Groovy's niche (the almost-Ruby-but-intimately-tied-to-the-JVM niche, such as it is) than Scala's. Scala's real niche, it seems to me, is closer to Java's own niche.

Agreed about Scala's nieche being closer to Java's. I think we can fit Fan somewhere between Scala and Groovy: Fan's type system actually does support both static&dynamic (unlike Groovy, which is dynamic with support for strong&weak typing).

And since 1.6, with annotations and generics, I'm not sure that the complaint about inflexibility is really there.

Annotations and generics have been there since 1.5. However, yes, this is still quite inflexible - what about lambdas, for example (which Python has)?

I don't know much about these things but supposedly that's why Groovy Closures are a big deal.

from the link ...

Since Groovy doesn't provide a way to define a closed lambda function and a block of code might not be a closed lambda function at all (because it has free variables), we refer to both as closure - even as syntactic concept.

... which gives Java programmers the ability to use Lambdas or at least lambda like things conceptually ... albeit not in the same ways.

Yes, it is used less right now. But it has support from Apple and Sun. I still prefer Python, but it is a fun language and now seems to be a long-term player.

Who mentioned programming Java? Only your fouled-mouthed troll.

Cyberax was talking about running languages such as Python, Ruby or Lisp on the Java Virtual Machine. In turns out that many of the runtime techniques within HotSpot to speed Java can also be used to optimise the performance of others. Where not the case, special mechanisms are being added to bytecode to create a truly language independant VM.

Thanks to Red Hat, there's also an LLVM based backend for HotSpot in development, Shark.

Perl, Python, Ruby? Sure, all will work, but have fun rewriting the interpreters themselves in Java!

This has been done for Python and Ruby. I believe there was an abortive attempt to do the same for Perl a few years back.

Too busy to just google for 2 sec before spouting off?
Here is jRuby using java VM , Maglev using Smalltalk VM , IronRuby using MS .Net , or pure Ruby Rubinius>Rubinius all aimed at among other execution speed.

Seems that grails isn't "tons" faster than rails--see http://docs.codehaus.org/display/GRAILS/Grails+vs+Rails+Benchmark etc. -=R

In which case, we may as well use Java or Silverlight -- plenty of dynamic languages target these. My personal favorite would probably be JRuby in an applet.

Seriously? Applets? again? Have fun.

And I think he was talking about Groovy embedded inside of Java.

The article is similar to just about anything you read written by anyone : An alternating points of insight and clueless, but generally well meaning.

Try groovy

$ groovy -e 'println "Hello, World!"'
$ Hello, World!

You can script with it, import and use any existing java classes, compile groovy code into java classes that can be used by other 'pure' java classes. It's a really cool dynamically typed language, and I highly suggest checking it out.

I was surprised that Groovy didn't appear anywhere in the article.

RTFA: page 2, paragraph 5

I'de give you a link, but the spam filter won't let me post it.

I was surprised that Groovy didn't appear anywhere in the article. If there's a dynamic language poised to convert the enterprise crowd, its Groovy. Able to compile into Java bytecode, compile Java code, and directly exploit the huge base of Java, but without the cumbersome Java syntax. I wouldn't be surprised to see Python and Ruby supplanted by Groovy in a couple of years.

It's not a scripting language like Perl, however, so if your world looks like Perl, you may not notice Java that much.

For a scripting language that runs on the java platform, check out groovy

Wicket is pretty cool.

If you haven't already, check out Groovy and Grails. They will change your life :)

I agree that Java is showing its age. C# has the advantage that is was designed several years after Java and learnt from its mistakes. Also, Java had a philosophy (for quite a while although it seems to be changing) that language changes should be made quite conservatively. However, there are some languages that run on a JVM that integrate perfectly with the Java API but have all the C# features you mention (and many more). I highly recommend looking both at JRuby and Scala.

Though Java-centric in nature, the JVM provides a secure sandboxed environment to host numerous languages including Ruby, Python, Lisp and even JavaScript. Throw in Groovy and Scala for home-grown alternatives.

Thanks to the efforts of IcedTea (principally funded by RedHat) and others, Java 6 will be fully GPL by the end of the year.

I just started at a new job at the beginning of this year after quitting from my last job where I barely got to do any programming. The place where I work now is a Java shop. I was getting back to Java programming after a hiatus of a few years. For the last few years I mostly doing Perl with a smattering of C (PHP and Javascript on occasion). My experience with Java was mainly from college and a few odd projects I did here and there. The language had changed quite a bit over the last few years and to be honest, I surprised myself by being happy to get back to it (I had some sort of vague dislike for it for a period of time).

The company sponsored a trip to JavaOne at San Francisco earlier this month, for the Dev Team. I also got to go. This was my first time at JavaOne. It was amazing, exciting, and I learnt a LOT of new stuff. The main thing I got from there was that Java, far from being a programming language, is also a platform. There are a lot of new things being built on TOP of Java. For example, Groovy, and JavaFX. Java now has excellent support and frameworks to roll your OWN domain-specific languages.

Python and Ruby are not going to push Java out of the way. For example, you have mergers of Java with these languages (Jython and JRuby). Essentially you have Python and Ruby using Java resources and libraries. I think instead of "dying", Java is just going to evolve into a stable platform that lets you build stuff on top of it.

Quick addendum - I would be remiss if I forgot to mention that my personal favorite language is implemented using ANTLR, so it isn't all bad.

What is your complaint about Groovy?

Lets you write code very similar to Ruby if you want, but its just java on the back-end, running on the JVM.

He used Ada, not Groovy

Depends on what you're doing, of course -- but for a good chunk of what I do, I find that the Python toolchain is fastest. Some tools (like Paramiko) simply have no Freely-available equivalents in the .NET world -- I looked at writing my last project (which included a custom SFTP server) with Boo, but just couldn't find the libraries I needed. For web services, several of the Pythonic frameworks -- TurboGears in particular comes to mind -- also seem hard to beat for terseness, readability or (to address your point directly) dev cycle time.

Even working with JSON (with the JSON.Net library which seems by some folks to be treated as a godsend) is much, much more difficult in .net-based languages than in Python unless one is able to use LINQ; as part of C# 3.x, this isn't available to folks who want to retain compatibility with Mono. I'll grant, on the other hand, that Python's support for SOAP is downright ghastly -- that's a place where both C# and Java have far better solutions.

As for the "integrated development platform" thing, I tend to buy the argument (which I've seen eloquently argued, but no link comes immediately to hand) that Python and its kin (of which Boo is arguably one) tend to make push functionality into the language which moots many of the whiz-bang features of modern IDEs. I've used Eclipse (very recently) and Visual Studio (somewhat less recently) -- and they're both very snazzy to be sure, but I simply don't see a significant difference in productivity between a full-blown IDE and a well-configured programmer's editor when using a powerful enough language. An IDE makes a big different writing in Java or C#, certainly; writing Python or Boo, vim does what I need.

Certainly, I don't doubt that there are problem sets for which the .NET toolchain contains the best tools. I am skeptical, however, that such is true for some overwhelming majority of cases.

Alternatively you can use Boo http://boo.codehaus.org/ , which has a MonoDevelop addin : http://monodevelop.com/Download

Boo is an object oriented statically-typed programming language for .NET/Mono with a Python inspired syntax and a special focus on language and compiler extensibility.

It actually has the feel of Python but has also all the features .NET can offer (contrary to IronPython)... and performance [Boo is on par with C# since it is statically-typed by default... you can use dynamic-typing where you really need it])

Have you tried Boo ? http://boo.codehaus.org/

Boo is an object oriented statically-typed programming language for .NET/Mono with a Python inspired syntax and a special focus on language and compiler extensibility.

It has the best of both worlds ;)

No threading or service module notion. Everything is tied to servicing a web page. Long lived jobs mean long lived web page renders. It also forces you to scale via page hits scaling rather than in other ways. There are more fined grained ways to break tasks up to scale.

Ruby itself is kind of pokey at a lot of things. Sure it's "fast enough" for a lot of things too but are you sure its "fast enough" for the things you intend to do? Or will you write them in some other language and then interface and shim it in? Which may make it perform faster but take a different amount of development time. The scaling of dev time is also a variable, not just the upfront zero to a database CRUD time, but zero to a delivered product time and then the next release time.

The short of it, if you ask me, is a more fundamental issue: it's just not built for big tasks. The architect(s) of Rails approach enterprise software and the various technologies to build it with disdain and look at it like a lot of meaningless engineering for the sake of engineering. There is definitely a dose of that that actually exists in the world but you're a complete fool if you think that the industry as a whole has arrived where they are in that regard without need. There are a lot of high volume, high performance j2ee systems out there that don't do a lot of exotic things; there are no high performance Rails sites that don't do almost everything in an exotic fashion. That all begs the question to me... There is no "Rails way" to do high performance. Unless that means completely unconventional and custom.

That being said, fire up Rails or Grails (if you go that way) and bang out some AJAX enabled CRUDs and I promise you, you'll fall in love with it. Compared to setting up some EJB (pre v3) and building some servlets, it's a fucking dream.

Ruby and Erlang are the two I've spent the most time with so far. I like Ruby enough so far, that I've decided to write the initial
batch of install scripts for OpenQabal in Ruby.

Outside of that wish-list, I also harbor some vague hope of one day finding time to dabble with Forth, Fortran, Perl, and maybe Dylan.

That's why there's Groovy. It makes working with Java pleasant and easy.

Well, there are plenty of voices in the Java community who would like you to learn Groovy.