This seems like a good contract to the typical (american-inspired) secrecy around governmental systems. I would also like to believe open source makes software more secure, but I'm not sure if there is any research that confirms it.
Oh, and cool its made in python and not some enterprise java or .NET :)
We're getting off topic, but you do know that it's perfectly possible to write decent Java or C# without it being "enterprise", right? (whatever that means)
I'm starting to get sick of this "ruby/python/nodejs = cool, java/.net = slow bloated enterprise crap for men with suits" attitude that keeps reappearing here on HN.
Whether your work environment is cool, whether your code is decent and snappy, all that has very little to do with your programming language choice. Admittedly, if you compare modern Ruby to VB6 you might conclude that VB sucks, but that's an unfair comparison since the technologies are a decade apart. It's like saying Python rocks because you hate COBOL.
You can work at a scrappy startup and code lean C#, and you can work at a bureaucratic departmentalized hell and code AbstractProxyProviderFactoryProviders in Python.
And, yes, you can even work at a bureaucratic departmentalized hell and code decent Python. Or Java. Or C#. Or Ruby.
Indeed, and so it's uncool and crappier than Python? How is that related? The OP clearly used the term "enterprise" with a negative connotation. I doubt he was referring to a brand name.
I suspect the implication was that being written in Python makes the code more accessible to "normal" people, both to read and (perhaps to an even greater extent) to run. If it were written on .NET one would likely (because Mono is incomplete) need a Windows server to run the code. If it was written using Java there is a decent chance it would require some pretty complex configuration and possibly a license of some sort from Oracle. I might be misinterpreting the comment, but when I personally poke fun at Java or .NET for being "enterprise-y", this is more or less what I'm talking about.
Actually though, it's rather difficult to run into Mono incompleteness when making a web app these days. Mono's mostly lacking Windows-specific stuff like WPF (UI-framework). Used to lack Entity Framework but that's solved since MS open sourced that. You can take an existing ASP.NET app and there's a very high chance you can just build it with xbuild and host it with Mono's xsp server.
More generally, I do see your point but I believe it's a little outdated; the time that Java apps just had to be built on 200k lines of XML is long gone as well.
It's obviously a matter of taste, but I find it difficult to accept that well-written Python would be easier to read than well-written C#. C# is more verbose in places and less verbose in others. Writing crap code is about as easy in both.
Are there really places where C# is less verbose by any significant margin? The only thing I can think of is that a well-written LINQ library lets you abstract away a tremendous amount of heavy lifting into a clean and declarative query, but other than that pretty much everything requires more keywords, punctuation and declaration in C#.
Don't get me wrong, C# is relatively explicit and regular, which does wonders for its readability especially in large projects with many collaborators. But brevity is not one of its strong suits, nor should it be.
Indeed, lamdas and LINQ. The moment you're using functional primitives that don't fit in Python's list comprehensions well, C# becomes a lot less verbose, and certainly less obtuse.
The OP did not use any such language ("crappier").
As noted, Oracle uses the term "enterprise", which I take to imply a corporate approach to language implementation the coincides with service/support agreements and other business models.
For what it is worth, the JVM is second to none for interpreted languages in my book. At the same time, I don't use it and if I ever find myself going back, it will be for Scala. I don't much care for Oracle's brand of innovation (I don't think it is sustainable).
Tell me something, from your perspective: Why should an aspiring technologist learn Java over Python?
Java cannot be written without a code completion IDE (unless you are a masochist), python OTOH, does not have such limitations. Forget runtime performance, coding in Java sucks more than any other language in my 'limited' experience. com.java.cookie.JarFactoryMakingMonkeyWrenchFrenchFriedOnionTrainPlaneJaneSpain.... you get the point. Want to counter that? Show me tight, non-verbose, working code in Java. At the end of the day, what you call a 'pissing contest' is rooted in a figment of truth and reality.
Quite a few Versions of EJB's were pretty terrible, and early Java Web Technologies had a bit of obsession with XML. However, current Swing is pretty pleasant to work with, and I think that most of the Java have stems from early PHP developers. If you had worked with PHP, with database queries and page formatting in one file, all the crazy MVC crap with business objects and and stuff must have seem needlessly complicated. And even if noone does develop like that now (I hope, anyway), the meme that Java is terrible prevails.
EDIT: new Java, for example, looks about like this [1] and that's not all that complicated, even though I would like it more with webflow (technology for describing webpage in term of flows -- each flow is basically FSM with method calls specified on transitions and FMS-wide persistent storage).
Because java these days seems relegated to legacy code or the 'enterprise environment'. And that's fine with me, I've always hated it in any environment.
The concept of 'write once, run anywhere' is fine and dandy in concept. Until you realize that it's a huge install base AND that there are 40 or so 'subversions'(updates) to each version. If I had a dime for every time i've seen a dozen java installs on a box, I'd be a rich man.
It is truly the worst of both worlds. Python does the 'write once run anywhere' better. C/C++/Go/etc do compiled, binary work. Java is a bloated, half compiled mess.
It's funny that you defend it so, using the 'age' argument. You do know that python is years older than both Java and C#? It's popular because it's done right, and has a good, open community, not because it's "new and trendy."
Java and the JVM are in still in prolific use - the JVM is a terrific piece of engineering. It features prominently in a bunch of large-scale web architectures (be it as straight Java, Hadoop, Scala or whatever). Note of these are traditional enterprise or legacy environments.
I've never seem a major schism in Java or the JVM on the scale of the split between Python 2.x and 3.x. All my installs require (_at least_) two versions of Python as a result. In fact it was only just recently that Debian/Ubuntu consolidated from shipping with 3 versions of Python to 2.
If you're talking about install base then I guess you're limiting this to client apps - because none of the issues you mention are an issue for server environments... Unless you are running a dozen Java pieces of tech that all require a specific version? In the last 10-15 years I've only ever seen the need for two Java versions once. And that was on AIX. On POWER chips. And it was a vendor, not a technical requirement.
JVM works, but let's not get carried away there. It still has method size limit of 64Kb here in 21st century, it is stack-based (reducing the possible optimization space considerably), and has no provisions for proper lexical scoping.
People port languages to JVM for its ubiquity and massive amounts of library code, but I assure you none does it for some technical advantage.
Why do you think the use of a stack reduces the optimization space?
There are plenty of models for stack optimization. Even if you don't go down the purist track, plenty of approaches use register-allocation and optimize from there. Feels like an outdated CISC vs RISC argument.
People also use the JVM because of it's Memory Model and robust threading.
JIT is a feature to get around lack of performance in stack-oriented, archaic, bytecode VM. I'm not going to argue about it's practical performance merit, but it's not really an advantage over a native code compiler found in bunch of other languages (since it is a native code compiler itself).
GC has arguably been the best thing Java brought along into mainstream, but it has been a solved problem for a while. The strategy that Java GC adopts, while a natural fit for Java and a host of other procedural languages, is suboptimal for many others.
Could you perhaps expand a bit on what could be done on GC on non-procedural languages? I am suspecting that you mean that there are some tricks that could be employed by functional programming language runtimes.
Hotspot GC is not the best there is for all uses (as Azul Zing JVM manages to forego stop-the-world collections altogether), but I am not aware that any popular runtimes have GCs that perform even close to JVM (perhaps .NET?)
And for long running processes (where compilation time does not dominate), JIT is of course theoretically superior to AOT compilation.
I would also like to believe open source makes software more secure
I would think in general that it does, but you also would have to be certain that the software actually running on the official voting system is the same as the "open source" version. I think that's a tough one.
Oh, and cool its made in python and not some enterprise java or .NET :)