@nullius @BenOnceAgain

Thanks for opening up my eyes to the pitfalls of KYC for investors.  With that being said, for any company looking to do business in the US, it would be extremely RISKY to NOT do KYC as you're basically just asking for trouble from the SEC as they want to prevent money laundering.  Please dont shoot the messenger here but until there are more defined rules, KYC imo is a must for anybody doing an ICO and planning on doing business in America unless you'd like to have a morning wakeup knock on the door. 

Now, if a company wants to try and do some offshore type structure to get around the SEC, I think you're still asking for trouble if you're ultimately going to be doing biz in US.  Much better to upfront and transparent about it.

I'd be interested to learn what technologies/safeguards could be used to make KYC more secure though as you all brought up very good points and valid concerns that I haven't heard anybody else discuss online.

I respectfully disagree.  As a company, you would want to ensure your code is reliable and has been vetted by other professionals. 

Your reputation is important if you want to sustain a long term company that provides a service to the world.

I think you just came up with the BILLION DOLLAR IDEA right here!


I'm being dead serious here but one of the reasons I keep coming back to this board is for experts such as yourself, HeRetiK and BenOnceAgain (hey just noticed the little rhyming pattern)

Have you thought of doing an advanced course that teaches best practices?  Why not monetize your knowledge and expertise and simultaneously benefit the community to have better standards and protocols?  

@MIT2K - I second what HeRetiK recommended as the first time I ever looked at C++ code, it looked like ancient hieroglyphics to me but after becoming familiar with the syntax and patterns of higher level languages such as Python, JS, (and my personal faves Clojure and Elixir) made it much easier to comprehend what Satoshi wrote (NOT easy but easier).  With that being said, Nullius' concerns are warranted in that if you're going to be serious about writing code that handles money, there's a whole level of responsibility that goes light years above your basic html/css/JS that's found in regular websites that you'll need to be cognizant of.

What helped me start was understanding the core fundamentals of programming in general vs focusing ONLY on the clerical aspects of any one language.  At the end of the day, we're all just talking to a computer and each language is a tool that was developed for specific use cases since a computer only understands 0's and 1's (assembly language).  And anybody who knows assembly language is just a OG pimp in my eyes.

Here's a free video by Bob Martin who is a funny yet brilliant teacher:
https://cleancoders.com/episode/programming-101-episode-1/show

And the entire clean coder series is great but most of it is in Java although some of it is in Go (programming language by Google and I believe what Ethereum was written in?)
https://cleancoders.com

Regarding fundamentals, there's this former martial arts teacher, Stefan Mischook, whose teaching style I personally liked when I started.   
https://www.youtube.com/watch?v=sRj1dMkoyOw
(Warning: He is NOT a blockchain/bitcoin expert like some of the gentleman on this board but for a beginner, gives a good foundation)

I might add (and I know I might get criticized for this but someone taught me this) that if possible, try to learn, or even understand the basics of a functional language FIRST, before learning JS or Python since you'll develop habits that will help organize your thoughts in a way to avoid messy coupling that could lead to bugs.  Mutable state will fuck you up man and even the new language that ppl are hyped about, Simplicity, is a functional language that has NO loops.  If I have time, I even want to try and pick up a little bit of Haskell which Simplicity borrows from I believe.

@Joaco @alia - I wanted to try to learn Solidity awhile back also but after of all the problems Ethereum had been having, I've been reluctant to invest in something that's not solid (pun intended).  What's your opinions of Solidity?

@hgbing - I'm game.  How about maybe setting up a Slack?  If not, I'll Skype ya.

How would you say your idea expands on NoSQL and could it possibly be utilized with Big Data/Spark and/or new Smart City/IoT projects?  When you mentioned infrastructure, I automatically thought of Smart Cities in the future as that is an area that is exciting for me.

Thanks for this post!  I personally hadn't realized there was a lot of proprietary software being used in this space as I thought the whole point and benefit was leveraging the open source community.  I'll ask my dev partners if they know of TestNet.  I'm personally only familiar with TDD/BDD so love learning about any new testing paradigms that ensure the code is solid and not brittle.


Is it therefore more of a responsibility of the company to manage expectations and even use that as PR to showcase that the team is being extremely thorough in their testing of the code?


Your post gave me an inspirational idea.  Would having programmers who previously worked for banks be preferred since they'll be particularly aware and sensitive to the nature of finance?


This looks exciting.  I tried searching for the Github but is there only an SDK available right now?


Your post reminded me to this older story:
https://dealbook.nytimes.com/2012/08/02/knight-capital-says-trading-mishap-cost-it-440-million/

Nullius, thanks again for the heads up on Simplicity.  I looked over the white paper and asked the Google his thoughts and am excited to give it a test drive in future.  Especially the different combinators and convenants.

Ironically though, you sort of reinforced the point I had proposed earlier, in that by possibly using a functional language (Simplicity is functional), you lessen the chances of bad code due to the nature of functional languages having immutable state.  In fact, Simplicity takes it a step further as they don't allow loops (page 1 of white paper) and use functions written in Haskell, another functional language (pg.24 of white paper) to generate Simplicity.



I had eluded to "clean coding" in an earlier post.  Whether you like Agile or not, many lessons taught by Uncle Bob relate to the issues brought up in this thread:

"Clean code is simple and direct.  Clean code reads like well-written prose"

https://www.goodreads.com/work/quotes/3779106-clean-code-a-handbook-of-agile-software-craftsmanship-robert-c-martin

If we're depending on the open source community as a whole to advance these new ideas and new paradigms, I think it's vitally critical to write code so that anybody else can take it further very easily.  

In regards to forking, I went to a great seminar last week where a VC/ICO investor brought up an interesting point in that since forking is more commonplace, what differentiating value can a company offer other than the product?  For me, the answer was obvious.  Great community of intelligent programmers.  So the question is what do intelligent programmers want in a company?  I think it was JFK who said:

"Ask not what your programmer can do for you, rather ask what you can do for your programmer" (drum hit!)

In regards to new coin announcements with critical business details missing, I completely agree.  (pls can somebody explain why Cryptokitties has done so well and what their monetization strategy is??)  

Part of the reason I joined this forum is my startup was going the traditional VC route, working on getting ACTUAL METRICS & TRACTION first but some of our competitors launched successful ICOs so I'm hoping to learn from all of you why any sane investor would invest in an ICO with NO metrics?  We want to be the exact opposite and have maximum transparency, great metrics, great programmers (pm me) before we would even think of launching an ICO.

For those of you who aren't familiar with the VC venture capital world, ICOs are an existential threat to their industry, which is ironic since they are usually the ones disrupting entire industries.  This is great for programmers who have great ideas because unless you're lucky enough to find a VC who shares your vision of the future, it can be very time consuming to raise capital.  

Lastly, our company is a B Corp (public benefit corporation) and we'd like to set it up as a Teal corp for maximum transparency but am curious if people even care about that.  
https://www.strategy-business.com/article/00344?gko=10921

Hi Nullius, thank you for your very blunt and honest answer.  I appreciate it.  

I'm going to start learning Simplicity ASAP.  

If anybody else here knows of any resources of how to best learn it, it'd be greatly appreciated.

Thanks in advance!
Z

Do you think certain practices such as TDD/pair programming/ and certain languages such as using a functional like Haskell/Lisp/F#/Clojure/Elixir/Erlang would've prevented these types of situations to begin with?  While anybody working with the web HAS to be proficient at JS, due to bugs from mutable state and potential tight coupling, I've really been reluctant to dive deep into C++/Python/(anything JS related Node/Solidity) when by just using another language, all of these potential threats are mitigated by default of the language.

Plus, as you mentioned, people would be in jail for losing large amounts of money, the potential liability a company has, to me at least, makes this a no-brainer. 

This thread is just another reminder of how important clean code principles are. 

Z

In your opinion, any particular flavor of Linux or even Ubuntu is a better option than Windows or MacOS?  I used to have a dual boot on my older Acer laptop back in the day but haven't felt the need to on Macbook

Very cool! So the Clojure project was a blockchain project or something unrelated?  Yes, the brackets/parens are a lot but have you watched any of the designer of the language, Rich Hickey, videos on youtube?  His view of the world and how the mind thinks are really inspiring.  Here are two that I really enjoyed:

Hammock Driven Development (warning, he covers meditation in it)
https://www.youtube.com/watch?v=f84n5oFoZBc

Here is an interview between him and Brian Beckman.  I wish all discussions around programming could be done in this manner:
https://www.youtube.com/watch?v=wASCH_gPnDw

As for TDD, good to hear you practice it (also with blockchain projects?) but agree with you that there's a certain point that it becomes too much.  I think that was DHH's point in those videos and of course the infamous Ruby Conf where he fired the initial shots at TDD:
https://www.youtube.com/watch?v=wASCH_gPnDw

(warning: Tons of F-bombs in DHH vid)


You make a great point but as I was reading your post, I remembered an article that Paul Graham from Y Combinator said regarding using a Lisp language when everybody was making Java WAS A COMPETITIVE ADVANTAGE.  I'll paste the link below and some of the text:

http://www.paulgraham.com/avg.html

"Software is a very competitive business, prone to natural monopolies. A company that gets software written faster and better will, all other things being equal, put its competitors out of business. And when you're starting a startup, you feel this very keenly. Startups tend to be an all or nothing proposition. You either get rich, or you get nothing. In a startup, if you bet on the wrong technology, your competitors will crush you.

Robert and I both knew Lisp well, and we couldn't see any reason not to trust our instincts and go with Lisp. We knew that everyone else was writing their software in C++ or Perl. But we also knew that that didn't mean anything. If you chose technology that way, you'd be running Windows. When you choose technology, you have to ignore what other people are doing, and consider only what will work the best.

This is especially true in a startup. In a big company, you can do what all the other big companies are doing. But a startup can't do what all the other startups do. I don't think a lot of people realize this, even in startups.

The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year.

The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.

Back in 1995, we knew something that I don't think our competitors understood, and few understand even now: when you're writing software that only has to run on your own servers, you can use any language you want. When you're writing desktop software, there's a strong bias toward writing applications in the same language as the operating system. Ten years ago, writing applications meant writing applications in C. But with Web-based software, especially when you have the source code of both the language and the operating system, you can use whatever language you want.

This new freedom is a double-edged sword, however. Now that you can use any language, you have to think about which one to use. Companies that try to pretend nothing has changed risk finding that their competitors do not.

If you can use any language, which do you use? We chose Lisp. For one thing, it was obvious that rapid development would be important in this market. We were all starting from scratch, so a company that could get new features done before its competitors would have a big advantage. We knew Lisp was a really good language for writing software quickly, and server-based applications magnify the effect of rapid development, because you can release software the minute it's done.

If other companies didn't want to use Lisp, so much the better. It might give us a technological edge, and we needed all the help we could get. When we started Viaweb, we had no experience in business. We didn't know anything about marketing, or hiring people, or raising money, or getting customers. Neither of us had ever even had what you would call a real job. The only thing we were good at was writing software. We hoped that would save us. Any advantage we could get in the software department, we would take."

Hello, sorry to bump this older thread but was curious if anybody had an opinion now in 2018 on which languages would be most helpful for bitcoin/blockchain projects?

C++ is what bitcoin is written in

Go is mature port for Ethereum but the bug with the Parity wallet in Solidity?

Many local coding schools are pitching Python as good language and since I also have an interest in data science/GIS, this would be nice since I'd be knocking out 3 birds with one stone but I also like Clojure based on the designer of the language, Rich Hickey.  Love his talks on Youtube.

Haven't found much on Scala but since Spark is built with Scala, was hoping to somehow work on how blockchain and Big Data might compliment each other?

I know Tezos was built on Ocaml but if I'm going to learn a language that has both functional and OO elements, then I'd prefer to stick with Clojure.

Lastly, not sure if how concurrency/parallelism directly impacts blockchain but if it does, why aren't more projects built using Elixir/Erlang?

Any thoughts greatly appreciated!

thanks in advance,
Z

Hello all,

First time posting here but looking to become a fellow, positive contributing member to this forum.

Sorry to bump this older thread but I did want to continue the discussion over using functional programming for blockchain/crypto projects and add that I think the CONTEXT is very important since as Nikisev mentioned, Bitcoin has scaled but doesn't C++ have BOTH functional and OO attributes?  

Unless you're Satoshi Nakamoto, statistically speaking, why would any programmer NOT use functional programming if they had the option due to the potential future bugs stemming from tight coupling and spaghetti code?

@nikisev - You brought up a good point in that if it works and allows fast bug fixing, then what's the problem?  But that means that the entire system would be DEPENDENT on YOU, right?  While the code can scale, what about the physical operations if you also have to run a business, manage other engineers, etc  

If you have to hand that codebase over to someone else, much less the open source community (which isn't that the point of ICOs to support the general community?) adds the possibility that someone else might have more challenges in maintaining that codebase than you since they won't know all the intricacies and nuances that YOU, the initial architect, had.  Versus had they used a functional programming language from the beginning, there would be NO risk of that at all.

Here's a good video by Uncle Bob of Cleancoders, who uses humor to make his point, that really changed my perspective of using languages/preemptive organizational practices to prevent decreased productivity and lost of morale for the engineers due to "spaghetti code".  

I recommend the whole video for actual business analytics but if you only have 2 min, 29:08 to 31:00 gives a simple description of the potential problems a company can face that non-technical people would never, ever know.  

https://cleancoders.com/episode/clean-code-episode-1/show

As for TDD, there was actually good Youtube discussion between the designer of Rails, DHH, who thought TDD was crap, Martin Fowler, and the actual inventor of TDD, Kent Beck.  It's a 6 part series so I'll just paste the link to the first episode:

https://www.youtube.com/watch?v=z9quxZsLcfo&t=2s

DHH made very good points that TDD isn't for everybody and actually decreased HIS productivity.  But to my novice thinking, what he failed to convince me of is that his style of working would work for an entire team since not everybody can be a genius like him and Nikisev.  If you have to rely on junior programmers on some level, wouldn't it make sense to have a very EASY way to find bugs and ideally prevent bugs from even happening?

I think that's what Elixir (based on Erlang) is good for since it tells you the exact error a lot of the time and Clojure (which still offering OO programming to attract Java guys) has the best practice of relying on the REPL.  I've never worked with F#/Haskell or Ocaml but seems to me like they'd all be better choices than a language such as Javascript

Anyways, looking forward to your thoughts as I'd like to start developing blockchain apps but C++ or Go don't inspire me as much as Elixir or Clojure.  And definitely NOT JS and hope that WebAssembly will someday free web apps from so dependent on it.

Z