Yeah, dollar cost averaging may be the way to go. There have been a number of times where I've thought to myself "just buy some already" but so far I'm holding out a bit longer to see what happens.
Good luck with the learning! With all the issues ETH contracts have had lately, I'm weary to go there. I'd hate to someday be responsible for someone losing money due to a software bug in one of my contracts. C++ may be a bit much to learn, but I'm starting to look forward to the challenge as EOS becomes more real to me.
Haha....well, if it gets to the point where there are only a couple months left to go and you still haven't found a price window to purchase....then you may wanna take your advice there :) I personally think (hope) it will go down near the later months...but who really knows.
Thanks and good luck to you with EOS! Yeah, looks like they've just done an update to their wallet to help address some security issues but I'm sure there are still more vulnerabilities to be found/exploited. I suppose it's in large part the way you build the contracts too and some folks may not be taking security issues into consideration to the point that they should be before releasing them. Personally, I'm in no rush to get something out there.....I'll be playing with it on the eth testnet for a while until I feel comfortable and that I have a good enough handle on how to address security before I even think about launching any contracts (if I even get to that point).
With EOS I'm guessing that at some point somebody may be able to even build something to let people interact with EOS without having to use C++ (similar to what Stratis or Lisk are doing with Ethereum). Who knows though of course and it certainly won't be me who creates that.
Anyways, take care!
I don't understand why they went with C++ for a smart contract language. C++ will be very error and bug prone. Instead, they could've used a modern, safe language. I hear Tezos is aiming for safety with formal verification.
Dan has blogged about this at length and given interviews on it. It's worth looking into. No language or program is ever perfect, so they are taking the approach that error recovery is a better approach than aiming for perfection. They originally were going with Wren, but it wasn't performant enough. C++ compiled to Web Assembly seems to be super performant and that's what this is all about. Also, there are ways to do type checking which make it pretty solid. Again, see Dan's posts about this stuff. Super interesting.
First of all, since the web assembly will be the target language; I assume, we won't be tied to C++. We can use any language as long as it compiles to the web assembly. This is good news.
On the other hand, I agree there's a tradeoff and that's exactly my point. I think safety and correctness are more important for a smart contract and a language which is easier to reason about would be a better choice. Especially if that platform allows the contracts to be proved correct formally. Functional languages are not that slow with current machines and they lend themselves better for parallel execution.
I'll check Dan's posts. Thanks.