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

281–290 of 321 posts

Re: Java Developers

#281

Post by seanmcdirmid »

pjmlp wrote: post #272
seanmcdirmid wrote: post #143

Earlier quoted context omitted.

HyperCard and AppleScript. And JavaScript is pretty unique at this point. Scala's OO is also pretty unique with traits and type members.

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

Scala's capabilities are not really comparable to OCaml, which doesn't even have traits. JavaScript has many influences beyond Self, and is enough of a mishmash even in its original form to have its own point in the list (at best, a not very similar descendant of self).

Re: Java Developers

#282

Post by seanmcdirmid »

andor wrote: post #187
seanmcdirmid wrote: post #76

Earlier quoted context omitted.

I guess it really depends on your definition of "objects." If it quacks like a duck, its probably a duck. Inheritance is not necessary at all for objects (since at least the Treaty of Orlando).

It's true that there's no definition of "object oriented" that fits every language that has "objects". But that also means that the term "OOP", without the context of a language, is useless in discussions, because it doesn't mean anything. Like Java, Go and Javascript have "objects", but you all know how different they are. So don't make them equal by calling both of them "object-oriented". If structs in C were calle…

Go is fairly OO in its own 1970s style. JavaScript is definitely OO and not many would argue otherwise. C is not: struts don't support encapsulation directly. However, many have invented or reinvented OOP in C (including me) with void* and hand rolled virtual dispatch tables (you can even find that in Linux). Heck, how do you think the first C++ compiler was written? And you could of course do objects in assembly...it's even easy given a few macros. [1]

OOP is simply programming with objects. If you have values that contain encapsulated state, and you are instructing them to do things with that state, you have objects and are doing OOP. You can do that in any Turing complete language, but some languages support it better than others.

[1] http://www.drdobbs.com/embedded-systems/object-oriented-prog...

Re: Java Developers

#283

Post by [deleted] »

seanmcdirmid wrote: post #281
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.

Scala's capabilities are not really comparable to OCaml, which doesn't even have traits. JavaScript has many influences beyond Self, and is enough of a mishmash even in its original form to have its own point in the list (at best, a not very similar descendant of self).

[deleted]

Re: Java Developers

#284

Post by pjmlp »

seanmcdirmid wrote: post #281
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.

Scala's capabilities are not really comparable to OCaml, which doesn't even have traits. JavaScript has many influences beyond Self, and is enough of a mishmash even in its original form to have its own point in the list (at best, a not very similar descendant of self).

> Scala's capabilities are not really comparable to OCaml, which doesn't even have traits.

Yes, it has a bit of everything anyone thought about in FP in it.

However you can make use of traits like feature by mixing in modules and objects, while taking advantage of first class modules in OCaml.

> JavaScript has many influences beyond Self

Sure, but I am unaware of any that make it such a great language.

Re: Java Developers

#285

Post by Dewie »

MrBuddyCasino wrote: post #231
adamors wrote: post #92

Earlier quoted context omitted.

It's not sad, because most developers are mediocre. It may not apply to you, but if you work in the industry long enough you realize that very few of your colleagues are good/great. And there's nothing wrong with that, but if you want to build systems that have to be maintained over multiple years, you somehow have to compensate for that. Java is one compensation.

Exactly. By definition, most developers are mediocre, and thats okay. Platform stability and limiting complexity is really important in the long run, so (luckily, imho) C++ and Scala are non-starters.

> Exactly. By definition, most developers are mediocre, and thats okay.

That doesn't say much. So yes, most developers are average, but what is average? Is it necessarily developers who need training wheels, helmets and elbow pads in order to protect themselves and others?

That may be the reality, for all I know. But that isn't necessarily a timeless truth. Take a room of expert programmers; now most of them are mediocre (average), relative to each other (imagine a really big room with a lot of experts, if you must). But that doesn't necessarily mean that they need languages that cramp their style in order to mitigate whatever damage they might do.

"Mediocre" is the same as "average", but with more negative connotations. Hence, when someone says that some people are 'mediocre', the immediate thought might be "bad". Then it becomes obvious that tools need to hinder these bad developers from screwing up too much. But mediocre is just a relative term, and can mean that they are really bad developers who create 100 bugs for every feature they implement, or that they are really competent, reliable developers.

I won't comment on the skill of the average (mediocre) developer. But I think that saying "most are mediocre" can easily hint at "most are bad" (because of connotations, not necessarily because that was the intent).

Re: Java Developers

#286

Post by frowaway001 »

pjmlp wrote: post #272
seanmcdirmid wrote: post #143

Earlier quoted context omitted.

HyperCard and AppleScript. And JavaScript is pretty unique at this point. Scala's OO is also pretty unique with traits and type members.

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

Re: Java Developers

#287

Post by okr »

ffriend wrote: post #269
djulius wrote: post #211

Earlier quoted context omitted.

+1 for the "toy immutable functions". Immutability everywhere is the current hype, but like mutability it has its advantages/disadvantages. The main consideration is the tradeof between performance(best for mutability) vs ease of use of development (best for immutability). However on HN, the war is dogmatic whereas reality is not that black and white. As a Java developer, I find immutable String and primitives very c…

> The main consideration is the tradeof between performance(best for mutability) vs ease of use of development (best for immutability) No, no, no. Immutable data structures are not actually inefficient, they are just different. They were designed for different tasks and work better in that tasks. Imagine, for example, that you need to traverse list of customers in a large multithreaded application. While traversing,…

> IIRC, Java String are immutable to allow creating substrings as views on the same char array, ...

If you point to substring() as a view of a string, nope, that behaviour has changed for quite some time already. Surprisingly for me as well, back then.

Re: Java Developers

#288

Post by seanmcdirmid »

pjmlp wrote: post #284
seanmcdirmid wrote: post #281

Earlier quoted context omitted.

Scala's capabilities are not really comparable to OCaml, which doesn't even have traits. JavaScript has many influences beyond Self, and is enough of a mishmash even in its original form to have its own point in the list (at best, a not very similar descendant of self).

> Scala's capabilities are not really comparable to OCaml, which doesn't even have traits. Yes, it has a bit of everything anyone thought about in FP in it. However you can make use of traits like feature by mixing in modules and objects, while taking advantage of first class modules in OCaml. > JavaScript has many influences beyond Self Sure, but I am unaware of any that make it such a great language.

Scala's OO features are more like Java's done better. OCaml is this weird object system that is structural most of the time sometimes nominative, and then there is that weird ML module system. Ah...I totally forgot about Moby. [1]

JavaScript has been very successful, and got a whole generation of programmers playing around with prototypes without knowing it.

[1] http://moby.cs.uchicago.edu

Re: Java Developers

#289

Post by seanmcdirmid »

seanmcdirmid wrote: post #279
DCKing wrote: post #110

Earlier quoted context omitted.

It's unfair to call Scala 'not really functional'. Although I agree it allows for very rich OO programming, dismissing it as merely adopting "some FP abstractions" and comparing it to LINQ is bordering on FUD. To substantiate these claims, you have to at least give an example in which Scala falls short in being a functional programming language. Interestingly, Scala's combination of OO and FP has given it (besides a…

Compared to the real functional languages (Haskell), the only reason I can think of that scala is called a functional language is because the community would be insecure in their smugness otherwise. You can totally use scala as a better java dipping into FP occasionally as you would in C#. It's not like say F#, which really forces you into a functional mindset. Post functional is as vacuous as post modern, ultimately…

Rich Hickey makes a similar argument:

http://www.codecommit.com/blog/scala/is-scala-not-functional...

Re: Java Developers

#290

Post by frowaway001 »

dmacvicar wrote: post #268
wtetzner wrote: post #105

Earlier quoted context omitted.

Any particular reason you wouldn't recommend it at work?

Oh, I also disliked implicit conversions a lot. I considered them a wart at some point. Made everything hard to read and reason about. Almost every other way of "extending" a type would have worked better in practice eg. Xtend’s Extension Methods.

Extension methods have mostly the same drawbacks as implicits, but none of the advantages.

It's not like Scala developers didn't know extension methods before designing implicits.

Instead, they tried to come up with a more useful, principled way, which also covers a lot of the stuff which is hardcoded and implemented ad-hoc in other languages (like implicit conversions in Java).

In the end, I think they made the right call:

- Implicit parameters are the basis for abstractions which unify the "strategy pattern" of OO languages with FP's typeclasses,

- implicit classes provide extension methods, but are better in pretty much every regard (higher reusability, less error prone) and

- implicit conversions cover the ad-hoc conversions everyone takes for granted, without having to hard-code these hacks into the language (e. g. don't like Java's/C#'s/... implicit convert-everything-to-String conversion? Don't import it in Scala).

Post reply on HN