Earlier quoted context omitted.
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...
Java Developers
291–300 of 321 posts
Re: Java Developers
#292Earlier 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…
I agree on that. Many things considered the domain of "functional" languages these days, like typeclasses and higher-kinded types are supported in Scala. Saying that Scala is 'not really functional' is more or less denying OCaml, F#, SML (in fact, pretty much every language except Haskell, Idris, ...) the status of a functional language.
F# at least pushes you into a functional style; its support for classes is just interop; this is as opposed to Scala, which really innovates on Java OO. OCaml is specifically OO (hence the O in the name), though with lots of functional features. SML and Scheme...are SML and Scheme. They don't fit nicely into OO or FP buckets.
Would you consider C# to be a functional language? It has lazy streams, generators, and good support for list comprehensions? Or is it just an OO language with functional features?
Re: Java Developers
#293Earlier quoted context omitted.
I agree on that. Many things considered the domain of "functional" languages these days, like typeclasses and higher-kinded types are supported in Scala. Saying that Scala is 'not really functional' is more or less denying OCaml, F#, SML (in fact, pretty much every language except Haskell, Idris, ...) the status of a functional language.
F# at least pushes you into a functional style; its support for classes is just interop; this is as opposed to Scala, which really innovates on Java OO. OCaml is specifically OO (hence the O in the name), though with lots of functional features. SML and Scheme...are SML and Scheme. They don't fit nicely into OO or FP buckets. Would you consider C# to be a functional language? It has lazy streams, generators, and good…
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-oriented code instead of bad functional code where it makes sense. (There a certainly other approaches to enable good functional code.)
I wouldn't consider C# functional, because it lacks purity, higher-kinded types, useful type inference, first-class functions, good support for immutability, dependent types and typeclasses.
(Note that I'm not saying that functional language need to support all of this. But a language which supports none of those items: I think we can make a clear call in that case.)
Re: Java Developers
#294Earlier quoted context omitted.
F# at least pushes you into a functional style; its support for classes is just interop; this is as opposed to Scala, which really innovates on Java OO. OCaml is specifically OO (hence the O in the name), though with lots of functional features. SML and Scheme...are SML and Scheme. They don't fit nicely into OO or FP buckets. Would you consider C# to be a functional language? It has lazy streams, generators, and good…
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, dependent types and typeclasses.
C# has first class functions and has had them for a long time. C# also has real value types via structs, allowing more efficiency with FP styles, better than what Scala can provide on the JVM. Generics in C# are also reified, vs. erasure in Scala, so your run-time and static type system is the same.
Scala has better local type inference than C# (though non-determinstic...), but lacks global type inference like ML, Haskell. Scala also doesn't support general dependent types, settling for a much weaker (must still useful) path dependency. Path dependency is a very OO friendly feature, and in fact really amplifies OOP in general; whereas for FP, path dependency's benefits is limited to records.
Re: Java Developers
#295Earlier quoted context omitted.
I will steal that argument for D.
I think D has a completely different of issues starting by a) small community b) reference compiler is not fully free software c) free compiler (ldc) is not finished d) very few people work on both compilers, etc.
IMHO, D is a better teaching language than Python and a better systems language than Java. I wish Android was written in D. I can't enjoy using a language with significant whitespace or extremely forced OOP.
The core language is good enough already, and better than most. They way it defines functional purity is the way it will be taught in universities in the future. It also embraces concurrency, and this will only become more important as computers get more processors.
What it lacks is libraries, therefore you are right about point a. The lack of a library like Ogre3D is an issue. The lack of an equivalent to jdbc for D is an issue. That's the reason for me to mention D here, the more exposure it gets, the better.
But about points b and c, no way. You deliberatedly ignore the third compiler GDC, which integrates the open source D front end with GCC and produces faster binaries than DMD.
Re: Java Developers
#296I have been using Java for a really long time. I have never seen a "AbstractAdapterFactory" anywhere. Ever. Disclaimer: never did any J2EE BS.
Re: Java Developers
#297Earlier quoted context omitted.
> 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.
Ah, yeah, I remember discussion about this, but didn't know about its result (I'm not active Java developer for some time now). Anyway, I think you've got an idea - immutability assumption may be pretty useful and improve performance in some cases, not decrease it (if you use it correctly, of course).
Re: Java Developers
#298Earlier quoted context omitted.
However - how many developers are turned off of being Android devs by the fact they have to use Java? (and I know that probably many more are attracted because they already know Java but that's not my point)
I was turned off by a.) horribly slow speed of Android virtual machine b.) being hard to code for it with maven c.) I did not particularly liked their xml language for gui. I would have to write mobile, I would use one of those languages that compile into both Android and iOS as much as possible.
Exactly. I personally think Java is fine. It's just that the development environment is much less nice than Xcode.
Re: Java Developers
#299Earlier quoted context omitted.
Just had a look at jDBI and it doesn't exactly look like a simple library to me. There's a lot of run-time annotation processing. Have a look at jOOQ if you haven't seen it yet. There is a pre-compilation stage which generates DAO for you and they can then be used with static type guarantees.
That pre-compilation step, though... How does that play with the IDE? I'm looking into various (more) modern ORM/DB-talky-to-things, and checked out jOOQ but was turned off by that pre-compilation step. I like having my errors bright and red when I type. I also don't like code generation. I'm not closed-minded to it, just don't like it if I can avoid it.
> but was turned off by that pre-compilation step. I like having my errors bright and red when I type.
Too bad. Once you have code generation built in your development process (e.g. combining things with Flyway: http://blog.jooq.org/2014/06/25/flyway-and-jooq-for-unbeatab...), I'm sure you'll get a hang of how things work with jOOQ, and most importantly, you'll get your errors bright and red when you type (or when you build)
Re: Java Developers
#300Earlier quoted context omitted.
Why are you assuming that he is writing a library? I have seen people bloat up simple java applications with provision for future requirements which will never happen in the real world.
Logging is still weird example to pick up for it. First, it make sense to have it configurable in production (and yes we ask clients to raise logging level in production we have no access to in case of troubleshooting). Second, it is not like each java program would be inventing its own super complicated xml like logging configuration. It is pretty much always done the same standard way. Pretty much every java app us…
Sorry the logging thing and the configuration thing wasn't my point. What I was trying to say was all the best practices and standard way of doing things are not set in stone and should be evaluated at every instance. Beginners write very inflexible code. When intermediate, they learn best practices and about making it flexible and keeping room for the future. But only after seeing enough projects in production, one will know which flexibilities make sense to the project at hand and which don't.
For example, some changes even though very easy to implement are very difficult to push in production because of requirement of senior management approvals.
Also, best practices depend on the actual environment that you work on. For e.g. In one of the projects, the DBA team had very cool people compared to the server admins who were a pain to deal with even when we had all the approvals. So we decided to keep the configurations in a table and not xml, as changes could be pushed easily!