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

Java for Everything

teamten.com

Post reply on HN
Print view View original

311–320 of 344 posts

Re: Java for Everything

#311

Post by twic »

overgard wrote: post #300
twic wrote: post #152

Earlier quoted context omitted.

> I've watched a company spend two years, dozens of developers, and over a million in ESB license fees failing to write a site that was expected to have, at peak, 100 users/day. I'm sorry to hear that. But you understand that this had nothing to do with Java, right? Java didn't make those people do that. That was just good old fashioned human stupidity. It's entirely possible to write simple things in Java, without E…

> The normal approach to writing scalable apps these days is the twelve factor approach I've never even heard of this. I agree with most of this advice, but, I wouldn't exactly call it a defacto standard.

My bad. I suppose i live in a bubble just like anyone else. I do think this is a well-known approach within the bits of software culture that talk about scalability. If you're a regular reader of highscalability.com, or a developer at Netflix, or one of the sad nerds who wish they were (eg me), or you've read the Heroku documentation, you've heard of 12-factor. But no, not everyone has, and in particular not every working stiff who shovels Java for a living.

Re: Java for Everything

#312

Post by evanx »

I'm thinking "Node.js for everything." It's way more fun, more productive, and runs small and fast. Forget threads. I too used to believe "Java for Everything." Over it. Write microservices in Node. Build front-ends in Angular. Talk JSON.

Re: Java for Everything

#313

Post by assertnotnull »

Sooo.. Why Paypal switched from Java to Node then?

http://www.informationweek.com/cloud/software-as-a-service/p...

BTW. I work with Java & GWT and I find it overkill for our needs. It took 5 months to make a 4 views, each with image or video grids and upload button.

On the side. I have on my free time working with Django and have a website with Authentification, comments, categories... In the end, my personal project has more features.. less lines.

Instragram uses Django and so is Disqus. Are those slow?

Re: Java for Everything

#314

Post by _lce0 »

waps wrote: post #230
desdiv wrote: post #202

Earlier quoted context omitted.

I don't understand the point. Are you claiming that search and replace functionality provides the same ease of use as an actual rename refactor ? No, I'm saying you need extra key strokes to activate that rename refactoring functionality, which is unnecessary in an ideal situation. To refactor the java code Foo x = new Foo(); you need to hit the key combo to active your IDE's refactoring thingy, then type the new nam…

Still don't understand. Let's take the changes you need to make : Foo.java ... class Foo { ... } SomeOtherFile.java ... Foo x = new Foo(); ... Equivalent in Python: some_file_in_a_library.py class Foo: ... some_other_part_of_the_program.py: x = Foo() Keystrokes to change the name "Foo", in Java : 1) Position cursor on Foo. 2) Alt-shift-R "Bar" (+ enter) Keystrokes to change this name, in Python : 1) position cursor o…

..plus you need to know where the class is being used!

Being able to refactor classes/methods/variables names without even care where those are used is a huge benefit IMHO

Re: Java for Everything

#315

Post by unclebucknasty »

lmm wrote: post #282
unclebucknasty wrote: post #200

Earlier quoted context omitted.

> You're rearchitecting anyway, creating stable interfaces and putting load balancers in there because those are also things you need to do as you're scaling up. Changing languages is no harder I have to disagree here. With just a little forethought, a good bit of the code can be reusable. For instance, your data access layer. And, the more forethought you put into it, the larger the potential reusability. This doesn…

> In any case, unless you're purposely writing completely nasty throwaway code, there is always some reusability, which typically makes starting from scratch in a new language a much weightier prospect than making some scalability enhancements to the existing base. It's not really from scratch. If you've figured out the correct structure and interfaces to solve your problem you can reuse all that when porting to a di…

>If you've figured out the correct structure and interfaces to solve your problem you can reuse all that when porting to a different language

Well, I think you're underestimating the sheer brute force work needed to port an app with a large-ish LOC base.

But, beyond that, if you've gone through the care of structuring it correctly such that the structure and interfaces are preservable once scalability needs arise, then all the more reason not to port it. Presumably, at that point you'd have, not only the structure, but working code.

So, if it can be so readily adapted to a new language and you're preserving so much code, then why bother porting it? Kind of makes may original argument. Just apply the scalability tweaks on the existing code base and you're done.

Re: Java for Everything

#316

Post by coldtea »

nickbauman wrote: post #304
jerven wrote: post #296

Earlier quoted context omitted.

And the simple fact that taking code provided by a remote service and just using it as is just handing the keys of your server over. LISP homoicity is nice but its a bad, bad idea to accept LISP code over the network from any client. Documented dataformats that are not executable are enough of a security risk that sending an executable around is not a great idea. (Should have been attached to grandparent, as I agree…

You really don't get it do you. An s-expression doesn't have to be evaled to be read. I just keep getting downvoted here. It's like offering a machine gun to a caveman and getting clubbed to death with it.

>An s-expression doesn't have to be evaled to be read.

Yeah, so you get a serialization format that's the same as your code. Big deal. And you have to live with your code having the same look as a serialization format. Even McCarthy wanted to give Lisp a proper syntax.

>It's like offering a machine gun to a caveman and getting clubbed to death with it.

More like it's coming to Paul Graham's house to tell him all about this new wonderful Lisp thing thing you've discovered. I mean, this is HN, what makes you think those that answered you don't already know and/or use Lisp and its homoiconicity properties?

Being used as a serialization format is perhaps the least interesting and useful property of Lisp code.

Re: Java for Everything

#317

Post by abalone »

bad_user wrote: post #251
abalone wrote: post #239

Earlier quoted context omitted.

> they can't make the code as easy to comprehend as it would be in a more expressive language. It's a little hard to make a general statement using an vague term like "expressiveness". Static typing can actually make things clearer . That's a kind of expressiveness. You can know with complete certainty what type of data the code works with, just by looking at it. No need to rely on a certain set of unit tests living…

Static typing can make things clearer, indeed, however Java has really shitty static typing. Also this is a common misconception: > You can know with complete certainty what type of data the code works with, just by looking at it. First of all, the type is only a limited view of the shape of the underlying data, written from the perspective of the business logic using it. In a micro-services architecture it happens o…

> In a micro-services architecture it happens often to see the same data exposed with types that are often very different

You mean micro-services that use dynamic instead of strongly typed APIs? That's really more a critique of such architectures than the facility of static typing.

> Tell me, what does a String tell you? What does a Double tell you?

It tells you you can't use a String where a Double is needed, without unit tests, from the very moment you type the reference in your IDE.

You're correct that it doesn't eliminate all possible problems such as validating the unit of measurement, and that it's not sufficient documentation in and of itself. But that's not the goal of static typing. It's there to eliminate a very large swath of problems through simple declarations in code.

Re: Java for Everything

#318

Post by unclebucknasty »

fsloth wrote: post #240
unclebucknasty wrote: post #237

Earlier quoted context omitted.

Downvotes (especially without comments) as an expression of disagreement are just plain silly. Are we eight-year olds?

This behaviour - downvoting without explanation irritates me too when there is very lucid and concisely structured argument you can oppose. As such, I do not find your argument for verbosity normalizing convincing :) I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context. For numerical algorithms, where a multiplication is just as verbose in a…

Well, I can appreciate the reply versus a downvote, but "I do not find your argument [against] verbosity normalizing convincing." :)

>I fail to see how normalizing some risk metric against a verbosity of language will provide any valid data in the general context.

OK, then let's look at the corollary: that is, not normalizing against verbosity would mean, roughly, that you're claiming that a language that is twice as verbose would yield twice the bugs over the same app. I don't think that's the case nor what you intend to say.

I think you're also confusing complexity with verbosity. An extremely terse language can be very complex, and may even suffer from readability issues.

Overall, the notion of LOC alone being a risk-metric absent any additional context seems an oversimplification.

Re: Java for Everything

#319

Post by AnimalMuppet »

desdiv wrote: post #47
rzwitserloot wrote: post #22

Earlier quoted context omitted.

DISCLAIMER: I write mostly java, at home and at work. Refactoring goes a lot further than just renaming types. A refactor script _WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so given the right utilities (and if you use java for everything, it's _MUCH_ easier to become an expert at the tools!) this is not any more effort at all. However, there are refactors for things that are much more di…

Refactoring goes a lot further than just renaming types. A refactor script _WILL_ rename both sides of 'Foo x = new Foo();' to 'Bar x = new Bar();', so given the right utilities (and if you use java for everything, it's _MUCH_ easier to become an expert at the tools!) this is not any more effort at all. Ctrl-Shift-R B A R No, not much effort at all. Just twice as many keystrokes. I wouldn't even mind the verbosity if…

Great, I suppose, but you didn't answer his execute() example at all. I don't care if you do it in vim, emacs, or an IDE, the problem is that in a dynamic language, you can't do it safely at any speed or with any number of keystrokes. Counting keystrokes is therefore completely beside the point.

Re: Java for Everything

#320

Post by jtheory »

nickbauman wrote: post #201
jtheory wrote: post #172

Earlier quoted context omitted.

I wrote a SOAP webservice -- not because I'm insane, but because our business relies on data sent to us. We could certainly tell everyone that they'll need to write code to send us the data we need to be of use to them. Or we could look at the installed systems that hold their data, and see what built-in support those systems have for external integrations. And so: we quickly added a simple SOAP endpoint. About seria…

So you're consuming data of an existing (legacy) SOAP service? Or complying with exisiting clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service. If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that be…

> So you're consuming data of an existing (legacy) SOAP service? Or complying with existing clients of a (legacy) SOAP service? That's not the same as writing a new SOAP service.

Neither; we're accommodating large, complex systems that only have a few options for "send selected data elsewhere". "Web services" (meaning SOAP) tends to be on that list, plus often other options that are completely unacceptable like "FTP".

> If the language you're using is already expressed in a form that does not need serialization, then you don't have to serialize it. This is the very essence of languages that are homoiconic. Perhaps you should familiarize yourself with that before down-voting what I have to say about it.

I'm someone who responded to you; I didn't downvote anything. I can try again: I use serialization all the time, to convert in-memory data structures into something I can send over a connection (or to disk, etc.), then to reconstitute them back into in-memory data structures on the other end. So I don't yet see how homoiconic languages play into serialization.

Post reply on HN