Re: [C/C Europe 25][DISCUSSION]

[Claude Warren]

Is there any more interest in working on Community over Code 2025 (next
year)

On Wed, Mar 20, 2024 at 9:56 AM Claude Warren  wrote:

>
> OK, Let's keep the conversation here and prefix any CoC Europe 2025
> messages with [C/C Europe 25].
>
> Are either of you planning on attending C/C Europe 24 in Bratislava?
> Have either of you worked on a conference before?
> Do either of you have a particular thing you want to do for the conference?
>
> Claude
>


-- 
LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [C/C Europe 25][DISCUSSION]

[Aye, Elijah]

Hello Mrs. Warren, I am interested in working on community code as one of the 
developers. I am a cybersecurity major and have experience with coding 
software. I have attached a copy of my resume for some of my background 
information, have a happy Monday miss!


From: Claude Warren 
Sent: Monday, March 25, 2024 1:20:34 PM
To: dev@community.apache.org; Claude Edney; koti.gundapan...@gmail.com
Subject: Re: [C/C Europe 25][DISCUSSION]

CAUTION: This email originated from outside your organization. Exercise caution 
when opening attachments or clicking links, especially from unknown senders.

Is there any more interest in working on Community over Code 2025 (next
year)

On Wed, Mar 20, 2024 at 9:56 AM Claude Warren  wrote:

>
> OK, Let's keep the conversation here and prefix any CoC Europe 2025
> messages with [C/C Europe 25].
>
> Are either of you planning on attending C/C Europe 24 in Bratislava?
> Have either of you worked on a conference before?
> Do either of you have a particular thing you want to do for the conference?
>
> Claude
>


--
LinkedIn: http://www.linkedin.com/in/claudewarren


Aye, Elijah.docx
Description: Aye, Elijah.docx

-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

[GSOC 2024] New Idea: A Minimal Superset of Java | JavaPlus

[Caleb Brandt]

Hi all,

I had a new idea I wanted to propose for this year's Google's Summer of
Code.  I sent this to the Groovy mailing list first for an initial look, so
when you're done reading, you can check out the replies that have already
been sent here
.
However, I wanted to share it with you all here too since the deadline is
coming up soon.

If you find this idea interesting at all, please consider mentoring!  And
if you think this just sounds like a worse version of Groovy: it is!  Check
out the replies on the Groovy thread to learn why that's actually *really
important* to have in the Java ecosystem.


Motivation:

If you're anything like me, you love Java.

I mean, how could you not: Java is unparalleled when it comes to
readability and structure and *power*.  You can track data flow through a
program at a glance, there are a thousand easy-to-use and *intuitive*
libraries, and - as much as I love C++ - there aren't any ambiguous
operators, syntax that's only valid in one specific place, or random macro
usage in the main library functions.  You know exactly what something does
just by looking at it, and that's *still* such a breath of fresh air even
in the modern programming space.  These new languages try to be as concise
as possible for writing, but they sometimes forget that people have to
*read* the dang thing too, am I right?

But... Java can also be a bit *too* verbose at times, can't it? We only
recently got a concise syntax for POJOs in the form of Records, and they
come with their own set of stipulations that make using them somewhat
niche.  And that's not to mention the continued waiting for destructuring
declarations, the getters and setters left floating around in the class,
the endless if-elseif trees checking the same value against different
things that make it so hard to track... There are a few areas of
improvement; let's say that.

Languages like Scala and Kotlin try to remedy this, but they end up with
their own problems like enforced programming models, completely overhauled
libraries that lose the intuitiveness of Java's, and just the overall
learning curve of being a *completely different language*. They *are*
incredibly powerful, but they lose the familiarity that comes with Java.

What we need is the ability to just... *add some stuff to Java*, without
making people learn a whole new language to use it.



So what if we did?

*Proposal: Add Some Stuff To Java*

Essentially, the plan is to make a set of syntactically-sugary-delicious
constructs that transpile to plain ol' Java 8, similar to how TypeScript's
advanced features still compile to ECMA2016.

The biggest thing is to make it as *approachable* as possible.  When you
see a new language, you expect to have to learn how to translate your
thoughts to code all over again, so this is intentionally *not a language*,
just a small set of language *extensions*.  By transpiling to Java source
code instead of compiling to bytecode, it also allows us to use the
first-class static analysis tools developed by for-profit companies like
Jetbrains without needing to write our own inevitably less-refined versions.

The core principles are *zero overhead* and *improved readability*; this
isn't remaking the wheel, or constructing overhauled libraries, this is
just adding shorthand for ubiquitous features that we wish we could have
saved time doing by hand.  It's gotta feel like you're just using a version
of Java from the near future; no syntax weirdness, just more-concise
constructs so it's easier both to write *and* to read.

Things like:

   - Getters and setters being *part of the variable declaration*, and
   being called via the property name itself;
   - If/else-if trees that check the same variable against different things
   being allowed to be in the form of a `switchif` statement, similar to
   Kotlin's switch statements;
   - Python-style group imports with local renaming, so people can still
   give their methods and classes descriptive names without being forced to
   type the whole thing out *every single time* they want to use it;
   - Kotlin-style `with` blocks for the convenience and readability of
   "chaining" when chaining isn't an option;
   - The `as` keyword so you aren't forced to relearn lisp every time you
   want to cast something;
   - Destructuring declarations using *annotations* instead of waiting for
   pattern matching to come through;
   - Operator overloading so we can do things like "accessing lists through
   brackets" and "doing boolean algebra in a readable manner", again declared
   using annotations so method names remain informative; and
   - All syntactic sugar added since Java 8, now available for us living in
   the past (and also most of the world, because they don't even *make* a
   JRE for the latest version anymore) to use freely too.


This would be accomplished using a Gradle plugin as a preprocessor,
converting any of our JavaPlus co