…I was comparing it to Solidity for my paper, since in Solidity you just create a smart contract (based on the language syntax) and run it, in CC I am confused on why it has a implementation in core code and how would a finished contract look like?
CC are quite a bit different than anything else, so you do need to study the existing examples to see how they achieve their goals. Faucet-CC is one of the simpler ones. CC run natively at full speed with total access to all daemon data. I guess it is like the difference between CPU mining and ASIC, it is more work to make an ASIC, but the result is orders of magnitude more efficient. CC is NOT equivalent to Solidity, in fact, theoretically it is possible to make a single Solidity-CC that would interpret Solidity contracts. CC are able to change consensus rules for the blockchain, Solidity runs an interpreted language under existing consensus rules. Once a CC exists, you interact with it by sending CC transactions.
in fact, theoretically it is possible to make a single solidity CC that would interpret solidity contracts
So basically, if this would be possible we could use Solidity in creating contracts for KMD? So faucet.cpp is the contract at this point?
Yes, once such a CC exists, that would be possible. But considering that we can get things like rogue-CC working in a couple weeks there isn’t much need for Solidity. Also it would be 10x to 100x slower and possibly not viable for any compute intensive things. Maybe we shouldn’t use the word “contract”, smart or otherwise, CC is a TOTALLY different way of solving the same problems. It implements constrained transactions with a specific vout type and using this, one of the nearly infinite things you can do, is implement what are commonly known as “smart contracts”, you could create a smart contract interpreter, you could make a blockchain enforced Sudoku too…