8

As I start learning Salesforce and start diving deep into a rather large project, I can't help but wonder why they chose to write a new, proprietary language instead of going with extensions or libraries to a similar language like Java.

From a learning perspective, I'd rather learn a skill that I can transfer to another application or project rather than learn a proprietary skill but I'm sure I'm missing some key reasons why they did this. My hope is that it wasn't for purely business reasons/to give people more of a reason to get engrossed in their ecosystem.

Improve this question
0

3 Answers 3

Reset to default
5

Actually, Salesforce didn't "invent" Apex. Apex which stands for Oracle Application Express was originally created by Mike Hichwa at Oracle. Salesforce pays them a license fee each year to use it. The first release of Apex was in 2004. Oracle still releases their version of it today.

Salesforce's version of Apex is different than Oracle's as Salesforce has indepently developed it to suit their platform and needs since the time they began using it and making it available to developers. Once you've learned some Apex, you'll understand that it doesn't have the countless libraries that Java does which can make it very daunting to learn. It does share Java and C#'s OOP patterns and has similar class structures, however it's more strongly typed.

There are nuances to the differences that benefit the Salesforce internal architecture. Most of those are there to preclude a developer from doing things that could be detrimental to it's multitennant architecture and Salesforce's ability to manage it while others are likely an oversight since Apex wasn't a "port" of Java, but a new language instead.

Improve this answer
8
  • When you encounter a situation where you wish you had all the libraries of Java, is that when you start writing your own? Do you call out to a self-made API-endpoint on your own server where you handle the data? What's the best way to handle that inevitable situation?
    – qarthandso
    Nov 12, 2016 at 16:09
  • 1
    I can't say I've encountered that situation. The Salesforce community has many libraries of code available on Github and elsewhere. One doesn't write Apex code to do anything that can be done via point and click; instead only to supplement it.
    – crmprogdev
    Nov 12, 2016 at 16:14
  • Makes sense. As a beginner to this whole ecosystem myself, is there a particular book or resource that you've found to be invaluable? Maybe something that wasn't created by Salesforce?
    – qarthandso
    Nov 12, 2016 at 16:17
  • 3
    Oracle's HTMLDB was released in 2004 but retro-actively rebranded as ApEx the same year Salesforce's Apex was released, in 2006. Apart from branding, they are completely different technologies.
    – Robert Sussland
    Nov 12, 2016 at 21:02
  • 1
    @crmprogdev Apart from Salesforce's Java running on "a" JVM, nothing else you've said in this comment or the above incorrect answer is true. Please, you are spreading incorrect information here, both about the timelines, as well as about the IP, and also about the relationship between the two completely separate technologies.
    – Robert Sussland
    Nov 14, 2016 at 2:34
3

From the Docs

https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro.htm

Salesforce has changed the way organizations do business by moving enterprise applications that were traditionally client-server-based into an on-demand, multitenant Web environment, the Force.com platform. This environment allows organizations to run and customize applications, such as Salesforce Automation and Service & Support, and build new custom applications based on particular business needs.

While many customization options are available through the Salesforce user interface, such as the ability to define new fields, objects, workflow, and approval processes, developers can also use the SOAP API to issue data manipulation commands such as delete(), update() or upsert(), from client-side programs.

These client-side programs, typically written in Java, JavaScript, .NET, or other programming languages grant organizations more flexibility in their customizations. However, because the controlling logic for these client-side programs is not located on Force.com platform servers, they are restricted by:

  • The performance costs of making multiple round-trips to the Salesforce site to accomplish common business transactions

  • The cost and complexity of hosting server code, such as Java or .NET, in a secure and robust environment

To address these issues, and to revolutionize the way that developers create on-demand applications, Salesforce introduces Force.com Apex code, the first multitenant, on-demand programming language for developers interested in building the next generation of business applications.

At least thats the official version

Improve this answer
2

You might find this Peek Under The Hood Of The New Apex Compiler video interesting as it talks a lot about the challenge of being able to compile and cache any of millions of Apex classes.

A benefit of Apex (to Salesforce) is that it is tightly controlled by Salesforce to only support features that fit with the overall platform architecture. But as you are starting to realise there are downsides for anyone writing significant amounts of code. Here is a post that I wrote when first moving from Java to Apex.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .