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

Java Developers

nsainsbury.svbtle.com

Post reply on HN
Print view View original

311–320 of 321 posts

Re: Java Developers

#311

Post by frowaway001 »

seanmcdirmid wrote: post #294
frowaway001 wrote: post #293

Earlier quoted context omitted.

If you consider a language to be more functional, because it forces you to use functional approaches even where it produces an inferior solution, then F# will certainly win this comparison. Just have a look at F#'s higher-order functions for collections to see what I mean. I consider a language "functional" if it allows me to write good functional code. Scala supports that by enabling me to choose good object-oriente…

The point is that I can use Scala as an OOPL without ever dabbling very much in functional programming (beyond as much as I do in C#). I can't, however, do that with F#, and believe me...I really want a Scala-like language for .NET so I can move on from C#. > I wouldn't consider C# functional, because it lacks purity, higher-kinded types, useful type inference, first-class functions, good support for immutability, de…

> The point is that I can use Scala as an OOPL without ever dabbling very much in functional programming (beyond as much as I do in C#).

So a language is automatically not functional, because other supported paradigms in that language don't suck?

So if OO in OCaml, F# wouldn't suck, they wouldn't be functional either?

> C# has first class functions and has had them for a long time.

I'd say C#'s functions are slightly better than Java's. The distinction between Action and Func is a terrible hack, and both of them are just a thin syntactic layer over delegates. Is that really first-class? They don't even provide function composition in the standard library.

> Generics in C# are also reified, vs. erasure in Scala, so your run-time and static type system is the same.

Bad luck for F#, I guess. Just ask them how much fun it is having to support two different kinds of Generics.

> Scala has [...]

As mentioned, that list wasn't a claim that Scala supports all of them (I think not even Haskell gets all the points).

Re: Java Developers

#312

Post by dragonwriter »

seanmcdirmid wrote: post #294
frowaway001 wrote: post #293

Earlier quoted context omitted.

If you consider a language to be more functional, because it forces you to use functional approaches even where it produces an inferior solution, then F# will certainly win this comparison. Just have a look at F#'s higher-order functions for collections to see what I mean. I consider a language "functional" if it allows me to write good functional code. Scala supports that by enabling me to choose good object-oriente…

The point is that I can use Scala as an OOPL without ever dabbling very much in functional programming (beyond as much as I do in C#). I can't, however, do that with F#, and believe me...I really want a Scala-like language for .NET so I can move on from C#. > I wouldn't consider C# functional, because it lacks purity, higher-kinded types, useful type inference, first-class functions, good support for immutability, de…

> I really want a Scala-like language for .NET so I can move on from C#.

You can't have one because:

> Generics in C# are also reified, vs. erasure in Scala

The fact that this is true of C# vs. Java -- or perhaps more critically .NET vs. the JVM -- is why you can't have a Scala-like language on .NET (its specifically why you don't have Scala itself on .NET, which was a thing, but foundered on this problem.) Reified generics on a platform are great so long as all your (statically-typed) languages have type system just like the one assumed for the platform, but they ruin the interop story for any other type system, and a Scala-like language without a good interop story with the rest of the ecosystem would be pointless.

Re: Java Developers

#313

Post by codygman »

tootie wrote: post #241
mike_hearn wrote: post #206

Earlier quoted context omitted.

It's hard for someone who was not the author to dive in to the middle of the code and understand it, debug it or upgrade it, due to the lack of explicit types. Additionally there static analysis was limited to lint and refactoring tools didn't exist, or at least nobody seemed to use them (I never used PyCharm but I heard it can do some cool stuff). Also for whatever reason these codebases often weren't very well stru…

PyCharm is pretty neat, but coming form IntelliJ it's baby stuff. The tooling around Java can simply not be matched by a dynamic interpreted langauge. Probably ever.

And the more expressive your type system is, the more that becomes true. It will be interesting to see what is done for Idris tooling if it gets some popularity.

There's also lamdu[0] being made for Haskell which is pretty interesting.

0: https://peaker.github.io/lamdu/

Re: Java Developers

#314

Post by sjolsen »

matthewmacleod wrote: post #64
dozzie wrote: post #8

Earlier quoted context omitted.

Simplicity -- none, if talking about the resulting code. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Performance -- poor, regarding memory consumption. Indeed, the sweet spot. > If you need lots of cheap developers [...] Shoddy, you mean. For Haskell or Clojure you have at least a guarantee that the guys you found are decent. It's t…

Simplicity -- none, if talking about the resulting code. Bollocks. Java code can be over-complex and lack elegance, but it's not the worst offender - sweet spot. Stability -- none, regarding possible law suits from Oracle. Yes, it does matter for a company. Yes, Oracle did that in the past. Bollocks. I challenge you to provide an example of a Java developer being sued for using the language. Performance -- poor, rega…

>no manual management

Of memory. Any other resource, you've basically got C with UNWIND-PROTECT and a cheap Schrödingerian knock-off of destructors.

Re: Java Developers

#315

Post by sjolsen »

pjmlp wrote: post #169
agumonkey wrote: post #155

Earlier quoted context omitted.

Lisp macros ? (first-class and generic, not bad for a workaround)

No, faced with the fact that CLOS is also verbose, although in a language that is all about closures, you started to present workarounds how to simplify its verbosity.

CLOS is verbose if all you're doing is encapsulating some state. If, on the other hand, you plan on doing anything remotely interesting, it's very succinct and expressive. Trying to emulate the functionality of CLOS' multiple dispatch and mixins in Java or C++ is hell beyond hell.

As for verbosity, I'll take ":accessor foo" over methods "getFoo" and "setFoo" with inane, useless autogenerated comments any day of the week.

Re: Java Developers

#316

Post by sjolsen »

agumonkey wrote: post #96
pjmlp wrote: post #79

Earlier quoted context omitted.

> OOP is too verbose by it's essence compared to closures. Then CLOS is too verbose?

CLOS is a layer on top of CL, it's optional. Also, LISPs are as verbose as you want them too. If you identify boilerplate you macro it away. It's part of the culture. Some systems (php/symfony2, eclipse/emf) go out of their way to generate unnecessary temporary files, templates and such but it's still cumbersome. To be honest, CL shows its age (mapc, mapl, do, dotimes, loop ...), more functional approaches like sml a…

I find it very strange that you've thrown LOOP in there. It may not be as sexy as canned functional algorithms or simple recursion, but for complex algorithms, it's an absolute joy to use.

I couldn't count the number of times I've been writing C or C++ and wished I could express an idea more complex than "Initialize some variables (which may or may not be of the same type (but not of arbitrary different types)); run while this is true; do this thing after every iteration" without just slapping everything into and in the immediate vicinity of a while-true block. I don't have that problem with LOOP.

Re: Java Developers

#317

Post by k__ »

pjmlp wrote: post #135
k__ wrote: post #95

Earlier quoted context omitted.

Also I thought the point was Java and not OOP. Java devs are known to over-engineer everything. There are many nicer OOP languages out there, where the devs don't tend to do this.

> There are many nicer OOP languages out there, where the devs don't tend to do this. Because they aren't used in enterprise applications. Just give them time.

I don't think "enterprise" is the problem here.

When I got software engineering at university, we learned Java. So all those fancy (mostly over engineered) ideas where taught us with it. When we did some web or IA stuff, we did it in PHP, JavaScript and Python and the lecturer went for small concise solutions.

Re: Java Developers

#318

Post by lpw25 »

frowaway001 wrote: post #286
pjmlp wrote: post #272

Earlier quoted context omitted.

How unique is JavaScript from SELF? In regards to Scala, I would say OCaml has similar capabilities.

I think the biggest difference between Scala and OCaml is that Scala users don't (have to) tell beginners to avoid the OO part at all costs. OO in OCaml feels as if the designers thought "we think OO sucks, so let's implement terrible support for OO to get our point across".

OCaml's object/class system is actually pretty good. It isn't used very often in OCaml because most of what OO gives you can be more naturally expressed in other parts of the language, but that doesn't mean that it's bad. In particular, classes are still the best mechanism for open recursion in OCaml, and should be used when that is what is required.

Re: Java Developers

#319

Post by dmacvicar »

mike_hearn wrote: post #309
dmacvicar wrote: post #306

Earlier quoted context omitted.

I think what you call "development productivity" shows exactly the cancer that makes the Java ecosystem a spaguetti of jars (whith some of them being dead projects) instead of a lasagna where you see libraries use only other libraries from the layer "below". But not, it is the obsession to turn everything into agnostic "engines" and meta-somethings, where everything is abstracted to the extreme with little value. At…

Well, there's exactly the reason I try and avoid distributor packaging as much as possible and prefer to use Maven from upstream. Not only is it much simpler but it means it's not being patched with "ugly hacks" by people who dislike the project. Sorry, Debian proved multiple times that this whole arrangement is a recipe for disaster. Maven is convenient and fast, I think I'll stick with it for now.

So what do you do if you realize one of your dependencies has a very bad security issue that will not be fixed upstream for a while and you need to fix it and ship an update to the customer? (or the same example with a crash bug in one jar, and you can't workaround it)

Re: Java Developers

#320

Post by nawitus »

thathonkey wrote: post #195
nawitus wrote: post #175

Earlier quoted context omitted.

You can use libraries instead of frameworks to avoid reimplementing/reinventing functionality.

But good frameworks are essentially collections of commonly needed libraries (to solve whatever problem the framework is concerned with) wrapped in (hopefully thin) unifying API.

The distinction made in the context of this discussion was that frameworks call your code, whereas you call libraries.
Post reply on HN