I would say the transaction model of datomic would have saved Mt Gox from its problems dealing with atomic transactions, however that's more due to datomic's design and poor design of the Mt Gox system than a clojure specific thing.
On Monday, May 5, 2014 6:21:47 PM UTC+12, Magnus Therning wrote: > > On Mon, May 5, 2014 at 12:13 AM, Evan Rowley > <rowle...@gmail.com<javascript:>> > wrote: > > The question we have to ask is: Would use of a (specific?) functional > > language prevented these? My opinion: > > > > Probably not in the case of Mt. Gox because their problems had more to > do > > with their application design. > > There is no language that will prevent logical errors, that is true. > There's that old saying that "a good programmer can write Fortran in > any language" ;) However, choosing language wisely will allow you to > concentrate on solving the 'real' problem at hand, and relieve you > from solving unrelated problems (memory management, dealing with > pointers, etc). It will also simplify reasoning about your code. I > haven't found enough information about the Mt Gox bug to judge whether > their demise could have been avoided using a better language. It sure > sounds like they were doomed no matter what. > > > As for Apple, I think the 'goto' feature is missing from at least > Clojure. > > Both Haskell and Erlang have 'goto', but it's use isn't encouraged. I'm > > thinking that because these languages are functional, the goto feature > works > > in a safer manner that wouldn't have allowed Apple's code to work with > the > > failed certificate check. But that's just a guess. > > I'm pretty sure there is no 'goto' in Haskell, it's not a keyword in > the language. There are ways of using continuations to implement goto > in monadic code, but I'm pretty sure that would be possible in > Scheme/Clojure too then. > > 'Goto' isn't a keyword in Erlang either! > > > For OpenSSL's Heartbleed, I'm going to say that this wouldn't have been > > prevented even with functional programming. The problem lies in the > design > > of the heartbeat code. One thing I do have to wonder about is whether or > not > > this heartbeat code would have been designed differently if it were done > in > > a functional programming language. It's worth keeping in mind that the > > higher level of abstraction most functional programming languages have > would > > have contributed to a different design. > > I think the base cause of OpenSSL Heartbleed is the presence of > pointers in the language used. In fact, I am convinced that if the > developer community would move en masse to language that don't have > pointers we'd see a huge fall in reported security vulnerabilities. > > > FreeBSD's TCP bug *might* have been prevented if the functional > programming > > language's runtime did effective memory management. I'm going to assume > that > > everyone here agrees that functional programming languages have > > well-designed memory management. > > Hear, hear! > > /M > > -- > Magnus Therning OpenPGP: 0xAB4DFBA4 > email: mag...@therning.org <javascript:> jabber: > mag...@therning.org<javascript:> > twitter: magthe http://therning.org/magnus > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
