This group is mostly dormant, but this deserves a full thread of its own.
https://twitter.com/nmartignole/status/532907910134005760
This basically happened a long time ago. Both the audience and cast of The
Java Posse diverged into two directions:
One faction of the Java Posse migrated to funct
Was there any news from JavaOne at all? Even with Google searches, I can't
come up with anything. And there is no discussion here?
No JDK 9 news? No feature announcements? No cool white papers?
On Sunday, September 28, 2014 9:48:55 PM UTC-5, clay wrote:
>
> I'm surprised that
On Sunday, May 4, 2014 12:29:24 AM UTC-5, ranjith wrote:
>
> I am wondering if there are any other suggestions..
>
Back on the OT: I love scalawags with Dick Wall and others. It seems that
Java Posse has been unofficially phased out in favor of these newer
podcasts that cater to more specific n
On Monday, September 29, 2014 2:30:38 AM UTC-5, fabrizio.giudici wrote:
>
> It depends. When you have heterogeneous groups where you have to enforce
> some order, declarative is better because you can force people to stick
> with a standard way to do things.
>
Maven gives a very superficial
I'm surprised that I can't seem to find any coverage at all of JavaOne. No
live blogs or tweets. No posts on this group. Nothing?
The Java enthusiast community seems to have scattered. I would think even
the Scala fanatics are excited about JVM improvements that benefit them:
value types, vm le
Wow, I'm surprised that people prefer Maven over Gradle.
I prefer Gradle for a few reasons:
- Way more concise. Gradle has a much cleaner syntax and doesn't require
mountains of XML for everything. Each library dependency in a typical Maven
pom often uses five lines of XML which is silly. Gradl
I did permutations of two [0..4] values. Extending to three/four should be
straight forward.
Haskell, do notation version:
do { a <- [0..4]; b <- [0..4]; [(a, b)] }
Haskell, bind version:
[0..4] >>= (\a -> [0..4] >>= (\b -> [(a, b)]))
Scala, for comprehension (just like Haskell's do notation):
edit: I can't answer your "direct question"...
I wish this forum had edit functionality.
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to javaposse+unsubscr...@goo
I can't answer your direction on Dick Wall's post, but to briefly comment
on Scala for comprehensions:
- They desugar into map/flatMap and filter if you use the for filter.
- Martin Odersky himself explains for comprehensions including the desugar
process in his part of the Reactive programming
On Wednesday, June 11, 2014 5:12:27 PM UTC-5, KWright wrote:
>
>
> With the best will in the world, I'd never even consider writing e.g. a
> device driver in Scala. Nor code for an embedded device with tightly
> constrained resources.
>
I would never consider using any language for a task comp
e.
>
> It's also almost one of *the* bases, barring the 100s of special cases it
> is a really simple language, kind of fundamental the same way Scheme,
> Smalltalk and Forth are (i.e., hard to reduce further without losing real
> capability).
>
>
> On Wed, Jun 11, 2014 at
On Friday, June 6, 2014 12:31:34 PM UTC-5, KWright wrote:
>
> Nope!
>
> C or Idris, I'll also accept Assembler.
>
> and Scala's the least bad you can get if otherwise tied to the JVM. :)
>
I completely understand why you prefer Idris/Haskell over Scala and Scala
over Java.
But why on Earth woul
On Tuesday, June 10, 2014 9:47:13 PM UTC-5, Josh Berry wrote:
>
> Apologies, I was a definitely too absolute in my claim. I was more just
> going on admittedly anecdotal evidence that most truly cross platform
> applications that aren't a) ugly, or b) dog slow are not written in Java
> and re
On Wednesday, June 4, 2014 11:21:48 AM UTC-5, Josh Berry wrote:
>
> Pretty sure c/c++ will remain the best cross platform option for a long
> time. Whatever promise of Java and related languages as providing cross
> platform environments, this just never happened. Closest would actually be
> .
http://www.oracle.com/technetwork/java/javase/downloads/index.html
I'm surprised how much useful JDK additions are included that I haven't
heard much about. java.time and streams/collections are awesome, but
everyone knows about those.
Here are a bunch more useful additions:
CompletableFuture:
well-known the formula you cite as-is fails catastrophically
> for floating-point numbers and the numerical remedies for roundoff problems
> are expensive enough that you don't want to do them all the time.
>
> -Joe
>
>
> On Mon, Mar 17, 2014 at 10:55 PM, clay >wrote:
&g
Why does jdk 8 java.util.DoubleSummaryStatistics not track variance or
standard deviation?
It provides mean, min, max, count, sum... But no variance? That's the other
major statistic that can be calculated trivially by Var(X) = E[X^2] -
(E[X])^2
Java 8 hits final release today, right?
--
You
"arse operator"?!?! Did you just make that up? Very funny...
On Friday, February 28, 2014 8:03:40 PM UTC-6, Reinier Zwitserloot wrote:
>
>
> RIght. I forgot about the scala 'arse' operator. My mistake.
>
--
You received this message because you are subscribed to the Google Groups "Java
Posse" g
> "...any discussion will instantly devolve into a scala fanboy fest? This
post turned into one halfway throughout clay's 1st post!"
I am both a Scala and Java-phile. Lots of Scala fans feel the same way.
Dick Wall is a good example. He prefers Scala, but he still likes Java, and
the JVM commun
> "Anyone have any thoughts on
(http://java.dzone.com/articles/think-twice-using-java-8) and
(http://coopsoft.com/ar/Calamity2Article.html)"
These two articles are criticizing just parallel streams or collections.
The same general feature exists in Scala and C#, most people don't use it
or con
Java doesn't have an official REPL, but it has many widely used high
quality options. Groovy is largely a superset of Java, so groovysh works.
Beanshell REPL works. I've seen other free Java REPLs on the Internet. I
often build my Java projects with SBT and use the built-in Scala console
REPL t
> "The theory of good enough..."
I would restate this as a trade off between perceived transition costs vs
benefits. Learning effort is a transition cost.
The United States failed to convert to the metric system despite major
effort because the perceived transition costs exceeded the perceived
On Friday, February 14, 2014 7:43:31 AM UTC-6, Russel wrote:
>
> And still way behind Groovy as well, And Ceylon. And Kotlin.
>
> And Groovy is now a static language as well as a dynamic language.
>
Scala isn't just another language. It is a highly polished, production
ready tool that offers a
was already doing.
On Thursday, February 13, 2014 2:34:31 PM UTC-6, KWright wrote:
>
> Would now be a good time to advocate in favour of the Play framework?
>
>
> On 13 February 2014 20:25, clay > wrote:
>
>> I'd second the recommendation to use an embedded serve
I'm disappointed there is not a peep about JDK 8 in this forum.
IMO, the main features are:
- Cleaner lambda expression syntax than the anonymous inner class route
from Java 1.1
- Functional collections in the standard JDK as opposed to relying on
somewhat obscure add-on libraries like Function
I'd second the recommendation to use an embedded server.
I was really happy with Grizzly. I couldn't see any advantages that
embedded Jetty had over embedded Grizzly
Also, Spring works fine with embedded servers. Lots of people are doing
that. I did that, although I would prefer to not use Spri
I was happy with using a trivial /etc/init.d service wrapper that just
calls "java -jar .jar" on startup and does a process kill for
shutdown.
It seems silly to use a more heavy-weight tool that actually requires a
license purchase.
There are tons of conversations on this exact topic of Java s
Have you considered an embedded server rather than the traditional
multi-tenant approach with .war/.ear archives and web.xml descriptors?
On Monday, February 3, 2014 10:42:58 AM UTC-6, Hayden Jones wrote:
>
> I am writing a java ee 6 application and am trying to decide to mark my
> filters with
What do you want in "exists" and "forAll" that can't be done with the
current "isPresent" and "forEach"?
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to javaposse
Wow! Nice!
I'm surprised it got added so quietly after such extensive debate, and
months after everyone gave up asking. I'm definitely not complaining.
Yes, a JDK8 standard equivalent to guava fromNullable or fj fromNull would
be nice as well. I can live with what they have though.
On Thursday
Outer local variable capture works basically identically in Java 1.1
lambdas and Java 8 lambdas. It is inaccurate to say that 1.1 lambdas
capture values and 8 lambdas capture variables. Java 8 doesn't require you
to explicitly write "final" on captured variables like previous versions of
Java,
To summarize the benefits of Java 8 lambdas over Java 1.1 lambdas:
- Nicer, less bulky syntax. IDEs like IntelliJ already auto format/pretty
Java 1.1 style lambdas, but it's nice not to rely on tools like this.
- Cleaner VM implementation. Java developers don't read their byte code and
don't car
Is there any substantial difference beyond the less bulky syntax?
I purchased and skimmed Venkat's draft e-book on functional programming in
Java 8:
http://pragprog.com/book/vsjava8/functional-programming-in-java
My first disappointment is that if you've seen his live presentations on
functiona
"A Java™ Parallel Calamity"!?!?
This is the most childish, baseless attack I've ever read.
If you are going to attack this technology for performance, you need some
kind of benchmarks to even begin to look like a serious criticism and not
just childish insults without any point.
When JDK7 lau
I would also add that if boilerplate code drives you nuts, you may want to
simply consider Scala. That language really addresses most of the lombok
issues, and since they don't have to patch it on top of a legacy language,
they were able to address the issues more elegantly. Scala handles the
g
What is really wide open about Java is that anyone can write a library,
framework, build system, code analyzer, ide, jvm language, etc, and that
there is a broader community and culture around that. The Java ecosystem
has a really strong track record of success stories: Ant, Maven, JUnit,
Scala
-- Ryan Schipper
>
> On 19 December 2012 10:22, Fabrizio Giudici
>
> > wrote:
>
>> On Tue, 18 Dec 2012 23:30:30 +0100, clay >
>> wrote:
>>
>> Every recommendation is a system based on some secure server storing
>>> passwords.
>>>
&g
Every recommendation is a system based on some secure server storing
passwords.
How about hash systems? I use http://passwordmaker.org/
It normalizes the site URL, concatentates with your email and a master
password, hashes (MD5) that full string, converts the binary hash to text,
and there is
first parameter of the functional interface method:
>
> Arrays.sort(names, String::compareToIgnoreCase);
> On Nov 3, 2012 10:54 AM, "clay" > wrote:
>
>> State of the Lambda #4 (
>> http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-4.html) says
>&g
y sure I've done
> ClassName::methodName in my experiments with FunctionalJava and Java 8.
> Doesn't the State of the Lambda cover that too?
> On Nov 2, 2012 6:54 PM, "clay" > wrote:
>
>> AFAIK,
>>
>> You can't do ClassName::instanceMe
Dick, your person/address/zip example perfectly illustrates the benefit of
Option/Optional.
This is precisely the functionality that JDK8 is purposefully omitting and
that we are debating.
I've written some static function add-ons to support this optional flatMap
type use case and ported your
said 'with proper support', regarding the returned collection
> type. :) But sure, adding a .into wouldn't be too bad.
>
> On Fri, Nov 2, 2012 at 6:09 PM, clay >
> wrote:
> > First, you can't use the :: method reference syntax with a variable.
nutes to understand
> but after that even the most determined anti-flatmapper will be able
> to curse, rewrite, fire the writer of but ultimately understand code
> like this without any real trouble.
>
> On Fri, Nov 2, 2012 at 5:22 PM, Fabrizio Giudici
> > wrote:
> >
In hindsight, a simpler solution (with static import of custom toIterable
method) would be:
final List zips2 = new ArrayList();
for (Person p : people) { for (Address a : toIterable(p.addressOption)) {
for (String z : toIterable(a.zipOption)) { zips2.add(z); } } }
--
You received this message
Dick, your person/address/zip example perfectly illustrates the benefit of
Option/Optional.
This is precisely the functionality that JDK8 is purposefully omitting and
that we are debating.
I wrote some optional flatMap adds-on for the latest JDK8 lambda build,
ported your person/address/zip ex
aside, it's amazing how small an amount of code we're really
> talking about. I just implemented Option and List including map and
> flatMap in JavaScript for fun on the way home from work (and missed my
> stop!).
>
> On Thu, Nov 1, 2012 at 9:39 PM, clay >
> wrote:
OK, I wrote Optionals for JDK8 which adds static functions map, flatMap,
and toIterable
http://pastebin.com/HZ1suSRt
(I would probably adjust the generics type boundaries if this was a serious
effort)
So that these work:
map(optObj, (o) -> ...);
flatMap(optObj, (o) -> ...);
for (T t : toIterab
Scala's implicits clearly have some of the same drawback as C#'s extension
methods in that it can make code hard to understand and hard to read.
I haven't learned Scala's implicit feature well enough to comment on them
yet.
On Monday, October 29, 2012 12:01:59 PM UTC-5, Ricky Clarkson wrote:
>
y remember seeing other places, but I can't recall exactly
where right now. Even without a green field implementation like Haskell,
having a good Optional type is still valuable even in a mixed null/Optional
environment.
On Tuesday, October 23, 2012 7:22:54 PM UTC-5, clay wrote:
>
> Has
."
If Optional flatMap/iteration is wrong for the JDK, no one is making that
argument at all.
The pro flatMap/iteration side has very clear and easy to explain reasoning
and logic.
On Tuesday, October 30, 2012 3:02:00 PM UTC-5, Christian Gruber wrote:
>
> It's more than
On second thought, I retract my last post.
If a there is a better design for a Java Optional that can be demonstrated
with pure reason, then the better design should be used.
This isn't about converting Java into another language, it's about making
optimal technical decisions and choosing bette
ok, the Brian Goetz responded to these concerns:
http://mail.openjdk.java.net/pipermail/lambda-dev/2012-October/006365.html
The JDK perspective makes sense now. These guys are definitely super smart
guys. Goetz's book on concurrency is great, and I apologize for suggesting
that the JDK authors
ended to solve reasonably well though.
>
> On Sun, Oct 28, 2012 at 10:47 PM, clay >
> wrote:
> > Is there a legitimate complaint about the Java 8 virtual defender
> methods?
> > That seems like a great enhancement. I haven't heard any objections.
> >
> >
Is there a legitimate complaint about the Java 8 virtual defender methods?
That seems like a great enhancement. I haven't heard any objections.
I understand that people will complain about everything. But with the
Option/flatMap/iteration issue, there is a very specific, technical,
articulate,
On Friday, October 26, 2012 4:06:36 PM UTC-5, Roland Tepp wrote:
> Instead of degenerating yet another thread into Java vs Scala debate
> (which it starts getting dangerously close to), what would be the thoughts
> on how we can actually influence Java 8 to have a proper Option type
> instead o
I prefer this algebraic data type design that is standard in every other
implementation of Option/Optional/Maybe (Scala, Haskell, F#, Functional
Java library, Atlassian's library, and even Guava)
However, as mentioned earlier, JDK 8's Optional is completely and
purposefully avoiding this, and h
Using the latest lambda build, I just tried to write:
public class FixedOptional extends Optional implements Iterable
which may be arguably better than using one of the many existing excellent
independent implementations (Functional Java, Atlassian).
Unfortunately the none/empty constructor is
On Thursday, October 25, 2012 1:15:31 PM UTC-5, fabrizio.giudici wrote:
> I think I'm not fully understanding this. For the record, I'm definitely
> not a Scala fan, and I definitely don't want all the Scala features in
> Java, but I'd like to be able to use Option with the least effort.
>
No, Iterable is a single method interface. It has only: "Iterator
iterator();"
java.util.streams.Stream has flatMap (and the collections implement Stream)
On Thursday, October 25, 2012 2:53:50 PM UTC-5, Ricky Clarkson wrote:
>
> Yep, Iterable has a whole bunch of methods including flatMap.
>
>
"Not everyone [...] has a choice over what language gets used."
If people can't make ideal technical choices for political reasons, then
that is a political problem rather than a technical one.
I can't fault programmers who try to "sneak" useful or stimulating
technologies around the stifling c
On Thursday, October 25, 2012 5:48:30 AM UTC-5, Mario Fusco wrote:
> ... if Java 8 wants really do a step toward the functional world, I
> honestly don't see why such a fundamental (and let me say trivial) thing
> like an Option (and possibly an Either) shouldn't be available in the core
> Java
curried methods in FJ could be replaced with method references in Java 8,
> for instance.
>
> The main difficulty is that FJ tends to use abstract classes instead of
> interfaces, and lambdas can only target interfaces. This means breaking
> API changes unless they look at introd
easons and resulting API may not be to your preferences, but its not
> Optional nor even @Nullable Rationall r. The reasons are
> present(). You just disagree. And reasonable, professional adults can
> sometimes do that.
>
> Regards,
> Christian
> Sent from my iPhone.
>
I read every Option related message in the September archives
The primary debate is whether Option should or should not be added to the
JDK.
We've heard that before and I respect both sides. I appreciate the elegance
and high level abstraction and the ability to factor lots of common if/else
l
Has anyone seen java.util.Optional in the new Lambda builds?
Why is there no flatMap?
Why does it not support iteration (can't do a for loop over an Optional)?
Why doesn't it have Some/None subclasses?
Why does Scala and Functional Java get this right yet Guava and now the
core Java guys compl
On Tuesday, October 16, 2012 2:25:59 AM UTC-5, Markus Backman wrote:
> The technology choice is being debated at the moment and the different
> choices are:
> * REST style JSON/XML services + some JavaScript framework(s) on the
> client.
> * Portlet 2.0 (JSR 286) + JSF 2.0 (JSR 314)
>
I'm worki
A quick test with Python 3.2.3 and numpy int arrays yields (I also tested
2.7.x and the results weren't much different):
arrayTest with n=1.0e+03 completed in 0.14937710762023926 seconds
arrayTest with n=1.0e+04 completed in 1.50266695022583 seconds
arrayTest with n=1.0e+05 completed in 14.913049
Micro-benchmarks are statistics, and of course, you can angle your
benchmark to tell whatever story you want. Yes, this stuff is subject to
various tricks and short-circuits
OTOH, You can drown out anything with enough skepticism and if you are so
emotionally entrenched, you can refuse to belie
OK, I couldn't help myself: reran Java test code on JDK7. Wow:
Java 8 Primitive test n=1.0e+06 completed in 0.108 seconds
Java 8 ArrayList test n=1.0e+06 completed in 1.804 seconds
Java 7 Primitive test n=1.0e+06 completed in 0.165 seconds
Java 7 ArrayList test n=1.0e+06 completed in 1.908 second
Scala Results:
Scala Array Test and for loops. n=1.0e+06 completed in 0.961 seconds
Scala Array Test and while loops. n=1.0e+06 completed in 0.130 seconds
This is with Scala 2.10-M7 and JDK 7u7.
First, obvious gotcha. whlie loops run *way* faster than for loops with
ranges in Scala. I thought t
C#/Mono results:
Primitive test n=100 completed in 0.2528684 seconds
ArrayList test n=100 completed in 1.0193116 seconds
Quick + Dirty Interpretation:
C# int[] is dramatically faster than List, even with the lack of
boxing. In this one-off benchmark, List took ~4x the time.
Also intere
On Wednesday, October 3, 2012 3:48:35 AM UTC-5, Russel wrote:
> Are you sure int[] goes "much faster"? Define "much"? I bet the
> difference in performance between ArrayList and int[] in Java 7
> and Java 8 is a lot less than you might suggest based on Java 1.0. No
> measurement, no conclusion.
Reinier Zwitserloot, you are correct regarding inter-version compatability.
I just think there was some confusion.
Kevin, "[C# tuples] can be stack-allocated, and elements inside such a
tuple don't need to be boxed. This is a *significant* difference!"
.NET tuples are reference type classes, n
27;s like a break from
the hard stuff.
On Tuesday, October 2, 2012 3:11:19 PM UTC-5, Simon Ochsenreither wrote:
>
> *I first typed my response to your comments, but it looks that it became
> more of a rant about the current state of the Java ecosystem. So nothing
> against you, clay,
(IntMapper, int, IntBinaryOperator): int
>- mapReduce(LongMapper, long, LongBinaryOperator): long
>- mapReduce(Mapper, U, BinaryOperator): U
>- noneMatch(Predicate): boolean
>- reduce(T, BinaryOperator): T
>- sorted(Comparator): Iterable
>- uniqueElements
If I download the latest build from http://jdk8.java.net/lambda/, I can use
lambdas perfectly, but I don't see the new functional enhancements to
collections (filter, forEach, map, etc). Anyone know when this will be
available?
On Tuesday, October 2, 2012 12:44:35 PM UTC-5, clay
http://mreinhold.org/blog/_aux/j1-2012-tech-keynote-fx+se+em.pdf
On Tuesday, October 2, 2012 10:29:36 AM UTC-5, Simon Ochsenreither wrote:
>
> Do you have any links, slides, videos, talks etc.?
>
> Haven't seen anything yet. At least the videos are not yet available afaik.
>
--
You received this
I think everyone would agree that Java has been very slow to evolve
relative to just about everything else.
However, Is the CLR ahead of the JVM? Really? Is C# ahead of Java? How so?
The big important features that C# has that Java 7 lacks are already in
Java 8: concise, first class functions,
I've read through the slides for the major talks this year. They presented
the exact same Java 8 content at last year's JavaOne 2011 show: lambdas,
collection library updates, etc.
Is there anything new this year? typesafe is showing off their new products
which are amazing. But is the core Jav
I will be disappointed if all these anticipated JVM enhancements offer no
measurable or noticeable improvement to Java 8 over current versions of
Scala.
The only advantage I see is that the byte code is cleaner and doesn't need
as many internal Java class files like what Scala generates. This s
Java 8 is finally getting anonymous first class functions which is a
feature that has already existed in many (most?) other JVM languages such
as Scala for many years.
One big difference is that Java 8 is using invokedynamic method handles and
sacrifices Java 6 backward compatability while the
ome clunky ORM.
>
> Jersey + JQuery (Mobile) is hard to beat in regard to maintainability,
> flexibility and performance. Keep it simple, use Java where it makes sense,
> but don't aim for the world to be completely wrapped in Java as is the
> traditional conservative pseudo-re
Just curious, why not use the latest Ubuntu? Is there a problem with the
newer releases?
I'm currently using Ubuntu 12.04 (I plan to just stay synced on the current
final release) for my development workstation and I love it. My only gripe
is switching between different external monitors on my
Play definitely counts as both a Java and Scala web framework. The HTML
templates use a Scala DSL, and the Play framework requires Scala and SBT,
but you can write all of your controller classes and back end logic in
either Java or Scala. Java is definitely a fully supported language.
The other
Kevin, in hindsight, I disagree with you.
Scala's for/yield returns a collection, in this case a collection of size
0-1 which is an Option, which lets you do this:
val barOpt : Option[Bar] = for (f <- fooOpt) yield getBarFomFoo f;
instead of:
val barOpt : Option[Bar] = fooOpt map getBarFromFoo
If your front end devs that are more comfortable with HTML/JS/CSS, why
don't you use a strictly HTML/JS/CSS front end that talks to Java REST
services and drop the server-side HTML templating engine?
On Thursday, August 9, 2012 8:56:05 AM UTC-5, zentr...@yahoo.co.uk wrote:
>
> I'd like to hear p
By itself, Option and flatMap are pretty simple, even for "Joe Java" types.
But even though it's simple to study and learn in isolation, one could
argue that it grows the barrier of entry to the language. New programmers
don't like to hit a huge wall of multiple foreign constructs and syntaxes.
I believe you know Scala better than I, but that is the "ternary" operator,
not "tertiary"?
On Friday, July 27, 2012 4:04:34 AM UTC-5, KWright wrote:
>
> Or with the tertiary operator:
>
>
--
You received this message because you are subscribed to the Google Groups "Java
Posse" group.
To view
Here is a simple example that illustrates the benefit of Option beyond
avoiding null exceptions:
Here is a traditional piece of logic using traditional null if-checks. This
is using Scala syntax but would be equivalent in Java.
val variableAMayBeNull: A = methodThatMayProduceA();
if (variableAM
On Monday, July 23, 2012 12:10:57 PM UTC-5, fabrizio.giudici wrote:
>
> And WTF is going to be included in Java 8 at
> this point, apart the first class functions?
>
Java 8 is still a big release. Adding lambdas well will be a big deal, but
additionally:
major collections library update. Hea
On Friday, July 20, 2012 2:42:36 PM UTC-5, KWright wrote:
"This isn't about Java-the-language either, it's about Java-the-platform;
getting the module system in place would benefit everybody. Right now it's
looking very much as though Java 8 is only including features that already
exist in oth
Wow, I didn't realize Scala had already completed this. If I may ask, what
is the advantage of JVM level support?
One of my Scala expert colleagues said this was the only feature he could
think of in addition to Jigsaw that was needed at the JVM level.
On Friday, July 20, 2012 3:39:24 PM UTC-5,
Is tail call recursion support coming to JVM?
Many algorithms are most elegantly expressed in a recursive nature.
Textbooks and academics typically use the most appropriate and elegant
notation available, but a JVM programmer is expected to manually avoid
recursive code due to the lack of inter
Jigsaw type modularity is the #1 big, important feature for the JVM, IMO.
But, I expected this delay... there was too little public progress for them
to be close to be making a 2013 final release date.
Project Lambda (first-class functions, and concise anonymous functions) are
obviously old new
I have used JSF 1.x quite a bit: it was pretty terrible. There is no good
reason to use it.
I've built web apps with REST (Jersey) web services + client side HTML/JS
with jQuery and ExtJS but without a server-side HTML templating piece. I
love this approach, but sometimes a server-side HTML tem
JSF is awful. I would absolutely move off of that.
The first thing I would suggest doing is considering if a traditional
server-side HTML templating framework fits the project.
You may not, in which case I would suggest writing server-side web services
(with Jersey or something similar) and a s
On Tuesday, June 19, 2012 4:45:07 PM UTC-5, Casper Bang wrote:
>
> Yes, that's the world view some seems determined to paint. However, the
>> truth is that nothing in the Ecma specs contain anything Microsoft/Windows
>> specific. Ignoring for a moment who's behind the standard, C# is for all
>>
"Look, I get it, Microsoft were a$$es in the past and you can of course
spread all the FUD you want on your very own podcast - but realize that it
makes you sound like old grumpy men with an agenda"
C# was never meant as a platform agnostic language that competed on its
merit and could be mixed
Casper bashes everything Java related: the language, the JVM, Swing, Maven,
the IDEs and raves about everything Microsoft related: NET, C#, Mono,
Anders is his hero, etc. All this on a Java group. And then complains about
bias and FUD because not everyone shares his perspective. The Mono team
o
On Monday, June 4, 2012 10:14:07 AM UTC-5, KWright wrote:
>
>
> Haskell uses Maybe, which is directly equivalent to Scala's Option. It
> just does it a bit more elegantly because the lack of subtyping allows for
> full H-M type inference.
>
The major difference between Scala's Option and Hask
1 - 100 of 215 matches
Mail list logo
