incepted

Ugh... sourceforge.net?

No, thanks.

On top of the weather, which is a big deal to a lot of people, the problem is exactly in what you said: there are two huge tech companies. And that's it.

Basically, if you move to Seattle, you are pretty much restricted to working for Microsoft or Amazon and that's it. Period. Nothing else.

It's a huge career limiting move, make sure you're okay with it.

Pardon my ignorance but I thought by now everyone agreed that Multiple inheritance was the root of all evil.

Hardly.

How it's implemented makes the difference. I'd say the general consensus is that C++' version of it is probably the worst (although to be fair, as much as I dislike C++, its implementation of MI has never really bothered me much in practice).

Modern languages support multiple inheritance of implementations with traits, which have a few additional restrictions compared to classes. These restrictions address some of the flaws that MI can have.

The bottom line is that you will rarely need MI and when you do, its flaws will probably not be much of a hindrance, so overall, it's a pretty overblown problem.

Java (or better, Kotlin) coupled with DropWizard (or Jetty or Tomcat).

Things get dated in engineering too.

The writing has been on the wall for Rails for a while now, we're just seeing an increasingly large number of people publicly moving on from it.

Interesting take but I disagree with one point:

This style of designing abstractions is often quite foreign in programming in the large, and other schools of thought (see Gang of Four) actively encourage weaving cryptic metaphors and anthropomorphising code as a means to convey structure.

The GoF didn't try to anthropomorphize, all they wanted to do is put names on things. Sometimes, these names have some meaning (e.g. Factory pattern) and other times, they have none (e.g. the Flyweight pattern).

The important concept that the GoF book introduced was to name things. What word was used for these names matters little.

In other words, similar to what the author of this piece is trying to achieve (and he does so pretty convincingly).

Here is a penny so you can by some more ram. You can keep the change.

I have a feeling that by the time this happens, a lot of the Python developers will have moved to Go or some other language.

It's always interesting to see the only people who ever talk about JavaFX are either Oracle employees or people who have a financial interest in JavaFX, such as the author of this piece whose business is based on JavaFX.

This is the usual privacy hysteria knee-jerk reaction: "Watch out, the big companies are going to get data on you!".

And people are going to react exactly like they've done before: if the service is worth it, they'll be happy to trade a few bits of privacy about themselves in exchange for the benefits.

Also, I'm not sure the author of this piece understands what encryption is about since he laments that most people don't search with https on. Er... what? If you want Google to search something on your behalf, they have to be able to read the words you type. Encrypting these words so Google can't read them would be comically useless.

Isn't it ironic to write this tool in a language that is not available on Windows[1]?

[1] "Windows support is comming soon. " https://ocaml.org/docs/install.html

Predicting that a company will fail without giving a date is not foreshadowing, it's stating the obvious.

Interesting but since they are designing a revised syntax, I wish they had got rid of Ocaml's semi colon. These stand out in 2016.

The whole article is about Gerber, it should have been called "Why Gerber can't innovate".

As plenty others have already pointed out, the tech industry is currently being led by very big companies that are frighteningly effective at innovating.

Disappointing content from the Harvard Business Review.

Too bad Google isn't more aggressive at keeping malware out of the Play Store.

I don't know, how often do we hear about this kind of malware on Google Play?

Not nearly as often as I would have thought a few years back, especially given that Google does zero reviews of what gets uploaded.

I think their current system is working reasonably well, but obviously, it's not perfect.

Ah, I stand corrected.

Seriously. The fact that Picasa is in this list tells you how meaningless that list is.

From my understanding, Spaces doesn't require any kind of membership anywhere. No accounts.

This could become a big deal if true and possibly rival Twitter for when you suddenly have an interest in something for a few hours/days but want to drop out later.

Show us what you think is a nice DSL then, because you keep waving your hands about DSL but you're not showing a single line of code to prove your point.

These are functions, it doesn't get any simpler than that and it doesn't require learning anything new once you know the language.

Macros are over engineered in comparison since they force the developer to learn a whole new section of the language with its own rules and own compilation lifecycle.

This is why hardly anyone uses macros these days and why most language are embracing the Groovy/Kotlin approach to writing DSL's.

I'm not against GMO, but one thing that I think is a fallacy is the choice between GMO and heavily-pesticided products.

You're right, I made a false dichotomy there, sorry about that.

There is at least a third choice here (non GMO, no pesticides) but it costs a lot more money, so it's not viable for farmers or anyone involved in mass producing tons of crops each year.

Only Monsanto is capable of arguing that the most environmentally friendly option for agriculture is GMO.

No, plenty of objective scientists argue it as well. It's just common sense.

You don't need a PhD to understand that for crops, you will have to choose between GMO or heavily pesticided products. The equation is that simple.

The author of the article certainly has its own agenda but you can make up your own mind about some of the points he makes, in particular the cycle of around the clock pesticide spraying that non-GMO seeds require in order to produce an acceptable crop.

It's time to step back and be a bit rational about all this, the anti-GMO movement is reaching levels of absurdity and hysteria approaching the anti-vax movement.

You cannot implement simple, modular, debuggable, composable DSLs with functions alone.

We've been doing this for at least ten years. Example: [1]

For someone who's convinced that DSL's are the silver bullet that everybody should be using, you don't seem to have kept up with the state of the art of the field much.

[1] https://github.com/Kotlin/anko

Mind naming a single one?

We no longer need macros to create intuitive DSL's any more.

I'd be extremely happy to be able to work on such a well designed project.

You really think the project is well designed just because they use macros, without even looking at the code or knowing the engineers?

Now I really think you're not for real and just messing with us.

I know.

There is no better way of doing things than macros.

We have invented plenty of better ways since Lisp. Much better ones.

I personally use this approach exclusively,

In my experience, most people who are so in love with macros/DSL's work on solo projects.

Are you working on a team? If yes, ask your coworkers what they think about your macros and it should be more obvious to you why macros/DSL's should be used much more sparingly than what you recommend.

I cannot understand those who prefer to write 1000x more code.

You're setting up a false dichotomy. It's possible to not use macros and still keep the amount of code down to a reasonable level.

Lisp is one of the few languages that can say it actually doesn't age; Common Lisp code that was written 20+ years ago is often used today without a single change. You can't say that about most of the popular languages.

Examples?

This is certainly false for most languages in use today: C, C++, Java, even C#: code written in these languages 15-20-30 years ago can still be compiled and run fine today.

I'm not sure what this proves much, though.

I see a lot of talk about how macros can be unreadable and all, but frankly, IMO that's totally backwards.

Why?

Macros are basically syntax defined for a specific task. Why is it so hard to see that this can lead to an explosion of unreadable code if left unchecked? Wouldn't you be concerned if you had to work on a huge code base where most of the code is written using macros?

I would run away, personally.

it was in Lisp age people actually cared about buildings systems that would live for decades.

We still care about this today. Even more than in "Lisp age" because we know how long code will be around. Which is one of the reasons why we have been moving at an accelerated pace toward statically typed languages.

Sure, Lisp has many derivatives, some of which are statically typed.

The most popular Lisp today, Clojure, is dynamically typed, though.