charriu

Relevant blog post about the leaked preview by Scott Aaronson: https://www.scottaaronson.com/blog/?p=4317

German has both of those.

During downtime between 2 jobs, I used to look at different languages for like half a day each, just to see what they did differently compared to the ones I already knew. I was mostly interested in concepts, not syntax.

This has helped me to be quicker when picking up new languages or even frameworks. Because, well, nothing is ever really new, right?

(Note that I would not recommend this strategy to a complete beginner. You need something to compare what you are discovering to.)

As for recommendations, I would suggest you look at what kind of problem you're trying to solve. If you could benefit from the infrastructure something like Java EE provides you, choose Java or kotlin (those are mostly interchangeable). For scripting, choose bash or python. For client-side web stuff, JavaScript. And so on.

This prevents dynamically created queries using lifetimes. It does not search for ' characters.

Process modeling requires some reading up front, I think. Integration into our application was relatively easy - activities implemented as Java classes with a reasonably good API.

As for results, we are quite happy with camunda. No issues with performance, incident handling, etc. We have about 100k new process instances/day, with 5-10 steps per process (3 different processes), some of which run over multiple days.

Our system is based on the Camunda process engine (in a Java EE environment). There's a central process server (or cluster) running the process engine, with events to start process instances.

Workflows are defined using bpmn and then executed by the engine. Errors are reported to the process engine as "Incident", which then show up in the management ui/apis. These can be retried any number of times.

We also have an older system based on Carnot/Stardust/IPP. This one used JMS messages everywhere.

None of course, but I think that's the point of the complaint. For a feature supposed to increase convenience, it didn't go as far as it could have. Still, I'm glad var is in there. (Now, my employer just needs to get off of Java 8...)

For a company, yes. Individual license is much cheaper, but the devs need to pay for it themselves.

While this is technically true, the fourth one is basically on life support. I wouldn't expect to find software or even many websites using it.

In case anyone is still reading this and is interested: http://www.enterprisedb.com/postgres-plus-edb-blog/marc-lins... shows that as well.

It's not quite infinite, I think. Each of the stat bonuses is limited to 50 levels IIRC, so there is an effective limit of 800 paragon levels (16 stats * 50 levels each - would take quite a while to reach).

It is a much better game now, regardless.

To 1: If you alter the contents, it's hash would change, thus it's address would change, if I understood correctly.

http://www.usno.navy.mil/USNO/time/gps/usno-gps-time-transfe... says: "The GPS epoch is 0000 UT (midnight) on January 6, 1980."

So no, gps time is not defined before 1980.

I realize that this not related to the topic of the post at all, but... why on earth would you (try to) make a pun and then add "(Haha, get it?)" at the end? At least for me, that takes all the fun out of getting a joke :(

A coffee brake? Yes, please.

(in the screenshot)

What's funny is that it performs better than many "pure" NoSql alternatives. I remember an issue on github, where the poster said they replaced mongodb with postgres and increased performance by an order of magnitude or something like that.

I personally never understood why java has built in types vs. reference types. Why should I care, instead of just letting the compiler handle that for me?

I agree with most of your post. I don't think the license was valid for the laptop/roaming, however ("roaming usage is not covered by CERN's AllSIM licence").

Uh... Neat?

Yes.

Guessing the correct key by chance doesn't give you the (necessary) information that the key was correct, because any number of other keys results in correct-looking messages.

"Merges with upstream by automatically accepting local changes"

For some reason, this scares me. Is there more info on that somewhere?

Most programmers I've met are not in fact regex "literate". They may be able to write one, but understanding what one does, or even modifying it? Well... So yeah, black box.

There might also be the small problem of actually building the fusion engine first. I don't think that's something we're really able to do right now, is it?

I think the first section confuses a couple of things.

First, a program can be compiled (static) or interpreted (dynamic) as stated in the article. However, that does not mean that you can't have a dynamic type system in a compiled language, or vice versa.

Also, if you add type inference, the examples given for variables in dynamic languages are perfectly valid examples for variables in a language with a static type system (the type would just be defined on first assignment).

I think the plugin is still available as an export target - at least the website doesn't say anything different.

And "Wo ist Walter" in german :)

I'm a bit worried about ES6 making the language harder to understand.

For example, scoping: For backwards compatibility reasons, var has to stay function scoped. But now we also have let, which has different scoping rules. Also, Symbols: [Symbol.iterator]() - what? Why?!

On the other hand, stuff like arrow functions, template strings, modules and tail optimization are awesome.

Everything except quoted strings is case insensitive.

I don't think there is any way around the hardware requirement if you want any kind of decent graphics experience. You need to calculate each scene twice (once for each eye), otherwise you're not going to get stereo vision.

And unless you want to view your minecraft world in 3D, that's going to result in hefty hardware requirements.

I'm writing this from the standpoint of someone who did a small game project with the rift dev kit 2: It's good that they're taking their time.

When the DK2 was released, the drivers were a horrible mess. The hardware was kinda okay, if you didn't mind seeing the pixel grid. Blurring was better than with DK1, but still an issue. Lots of people still got motion sickness from just wearing the rift for a short amount time.

Now, don't get me wrong: I'm exited for VR. But I don't want a piece of so-so hardware that's just gonna lie around on my desk. I want something that's actually supported by software (games) I use (play) and fun to use.