Nah, if it's this topic, more like how AllegroCache object-database maps high-level commands on database manipulation in LISP that look similar to regular manipulation of objects to lower-level LISP that's more efficient which compiles to machine code that efficiently implements those structures on target CPU. Typical ORM's take two things that are very different from one another and never intended to match up then try to force them to match up. Not a great example.
Here's another for you: Lilith. Assembly is messy. So, they create a stack machine (M-code - P-code variant) that idealizes it plus easily compiles to it or implementable at CPU level. Then, they create a 3GL called Modula-2 that's closer to how they express programs but has underlying model of M-code and outputs M-code. In theory, they could go further like 4GL's did to build domain-specific languages that abstract away boiler plate with code generation but still consistent with Modula-2 style. And so on. Easier in functional languages but I'm sure you can see the pattern.
That's what you usually get out of the DSL or interpreter approaches if using a LISP, Haskell, or imperative language designed to make it easy. Languages designed to do them well. A series of transforms with a certain amount of consistency from start to finish. These days, there's even safety techniques for the transforms that they didn't have way back in the day. :)
China is building... and building and building. Houses mostly. It's basing its growth on housing and industry like the US economy.
The problem with that is that a LOT of Chinese people cannot buy a house. They simply don't have the liquid money or the same access to credit that American's do (for better or for worse).
So what they have now is a glut of supply in their housing market (built upon credit), with a lack of demand. And really there is no way for the Chinese government to create that demand. They can't go the QE route because your currency is restricted. You don't have diversified industry to kickstart. Steel is down. And you're already saddled with both domestic and foreign debt.
I'm no economist, but the future isn't that bright for China. Imo a Chinese collapse could be worst than an American one.
I wouldn't use the word "collapse", but a "crash" is definitely in the cards. The political system is too fragile to think that it can survive a crash, so they are trying to kick the can down the road as far as possible, which will just make the inevitable crash worse.
Holding wealth in the dollar means holding wealth in a depreciating asset. Gold, silver, bitcoin, real estate, etc much preferred.
But given that my income and expenses are head up (at the moment), I'm in the same boat ... 7k net in and 7k out, a lot of which is me re-buying my own CC debt with loans from lending club, etc.
Bitcoin is by definition depreciating. Precious metals have very little utility and are only used as stores of value. They can not generate dividends and are therefore likely to under perform in the very long term: http://www.businessinsider.com/buffett-on-gold-2012-2
Real estate can be a decent way to store money long term because of the rent you can collect. Because many people are highly leveraged with real estate, selling before your mortgage is paid off can be very volatile.
Good real estate investment: Buying a rental property.
Bad real estate investment: Buying a bigger house than you need for yourself hoping it will go up in value.
> one of the main reasons we tend to use WhatsApp and Slack, even for corporate communications as silly as that sounds -- because you can type long messages on it on the keyboard/desktop but also have access to it on the go.
I was excited about prolog when it first gained popularity in the 1970s for exactly this reason. Then I discovered that real programming in prolog hides some of the reasoning necessary for programming (like the time needed for a computation to finish) behind abstractions of the language. (I.e. The cut operator ruined for me)
>If you want to get shit done, and make sure the types are correct, and make sure all side effects are properly managed and accounted for, that's Haskell's niche.
Dont Clojure's immutable types handle the side-effect issues well? Without the contortions that Haskell puts you through.
Clojure's immutable types mean just that—the values are immutable (e.g., in CL you could do (defvar x 42) (setf x 84), but in Clojure the equivalent is not allowed).
But there are many more side effects than changing variables. Clojure makes no guarantees that a given function is referentially transparent, nor does it promise that a given function doesn't write to stdout/stderr, read from stdin, change the file system, make a network connection, send missiles to foreign countries, etcetera.
The 'io!' macro marks a code block to have side effects which prevents using it in a STM transaction as 'dosync' might need to execute the functions multiple times in case of conflicts during the optimistic locking.
In the sense C programmers use the term? Why should humans be trusted with identifying all operations that can't be safely performed within a transaction?
