Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Estonian E-Voting Source Code Made Public

news.err.ee

Post reply on HN
Print view View original

131–140 of 144 posts

Re: Estonian E-Voting Source Code Made Public

#131

Post by shiven »

Afforess wrote: post #95
joelthelion wrote: post #87

Earlier quoted context omitted.

There is a verbose and enterprisy smell to the language itself. Just compare the hello worlds in java and python... Apart from that, I agree with you.

Let's not. Unless you think we should also be comparing memory footprint, performance, etc of said 'Hello World'. Language pissing contests are dumb. Languages are tools, each serves a specific job.

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.

Re: Estonian E-Voting Source Code Made Public

#132

Post by skrebbel »

sirclueless wrote: post #120
skrebbel wrote: post #115

Earlier quoted context omitted.

Thanks for taking a guess. 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…

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 fo…

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.

I think that's the only place, though.

Re: Estonian E-Voting Source Code Made Public

#133

Post by currywurst »

shiven wrote: post #131
Afforess wrote: post #95

Earlier quoted context omitted.

Let's not. Unless you think we should also be comparing memory footprint, performance, etc of said 'Hello World'. Language pissing contests are dumb. Languages are tools, each serves a specific job.

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…

Please take a look at the Apache Lucene and Tinkerpop Blueprints codebase that will soundly meet all your parameters.

Re: Estonian E-Voting Source Code Made Public

#134

Post by rospaya »

oneandoneis2 wrote: post #56
technimad wrote: post #4

No matter how open the code is. It is extremly hard, if not impossible, to ensure this code is running on the actual systems. E-voting sounds intersting in theory, but in practice it is basically not worth the trouble. It is way more complex than a regular system with ballots and the only gain is that the results can be published sooner.

Actually, E-voting could revolutionalize politics. Right now, we have to have presidents, prime ministers, even kings; making all the big decisions for us because that was the only practical way. E-voting makes it possible for the population to be consulted on any major decision. This, IMHO, is the reason it's so unpopular amongst politicians. Right now in the UK, for instance, MPs get to vote on their own salary inc…

Direct democracy doesn't work most of the time.

Re: Estonian E-Voting Source Code Made Public

#136

Post by anon_java_hater »

oellegaard wrote: post #36

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 :)

>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.

OSS is more secure because it's easier to verify than machine code. The fact that it is still not easy to verify is simply a flaw in the choice of PL/build system. Obviously if you try to verify a project in C, you're not going to get far, as the behaviour of most of the code will be undefined. Code written in the E programming language (http://erights.org) for example, is orders of magnitudes more easy to verify, simply due to forced encapsulation and that the semantics of it are much more obvious.

Re: Estonian E-Voting Source Code Made Public

#137

Post by eonwe »

varjag wrote: post #130
jwilliams wrote: post #127

Earlier quoted context omitted.

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_) t…

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.

I'd think that JVM JIT and GC count as technical advantages.

Re: Estonian E-Voting Source Code Made Public

#138

Post by varjag »

eonwe wrote: post #137
varjag wrote: post #130

Earlier quoted context omitted.

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.

I'd think that JVM JIT and GC count as technical advantages.

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.

Re: Estonian E-Voting Source Code Made Public

#139

Post by eonwe »

varjag wrote: post #138
eonwe wrote: post #137

Earlier quoted context omitted.

I'd think that JVM JIT and GC count as technical advantages.

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 str…

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.

Re: Estonian E-Voting Source Code Made Public

#140

Post by TeMPOraL »

rospaya wrote: post #134
oneandoneis2 wrote: post #56

Earlier quoted context omitted.

Actually, E-voting could revolutionalize politics. Right now, we have to have presidents, prime ministers, even kings; making all the big decisions for us because that was the only practical way. E-voting makes it possible for the population to be consulted on any major decision. This, IMHO, is the reason it's so unpopular amongst politicians. Right now in the UK, for instance, MPs get to vote on their own salary inc…

Direct democracy doesn't work most of the time.

If it was as fluid as up-voting posts on HN, maybe it could? If for even every minor decision you could vote directly or pass your vote to a representative (who could either vote for all collected votes or pass them forward to another representative), then maybe this kind of fluid, real-time changing network democracy could work?

I have no clues about potential issues or failure modes of this, but the concept is interesting and - I think - worth discussion.

Post reply on HN