code-dog

Good point - what is clojure actually for?

... and you have to work really hard to make C or C++ run any faster than the JVM. For all normal levels of programmer effort there is no difference or the JVM is faster.

I see your point, but then money is money. So, why pay MS anything? Why is computing treated in this unique way where minimizing cost is not standard practice?

Oracle moving on from the 1.6 doldrums was a huge plus for Java and the JVM. Now the buzz is around 1.8 with lambdas and enhancements to performance of invoke dynamic.

Makes sense - the JVM is fast and stable. It comes with a huge array of tooling and its own built in debugging system. It is well supported and cross platform. Why would you not want to take advantage of all that good stuff?

Yes! Someone gets it!

In this case a team could work across the project. One on the parser/lexer one on AST translation, one of code generation, Two on the runtime and 1 on build/ci. I think that makes 6.

That is true. As someone who thinks both ways (craft and day job) the issue with Scala (that with which I have the most experience) is the tooling.

The JVM has a huge advantage over the CLR in that Mono is nothing like as well supported as Oracle supports the JVM and Microsoft's CLR is Windows only - which makes it far to expensive for cloud computing.

No reason it should take that long. The article suggest 6 person years - which could mean 6 people for 1 year.

I would love to see if this is the same on Linux...

I guess that is not the real point of the post. It seems to be more about keeping grounded and not taking 'the buzz' too seriously.

Could not have put it better myself.

I like scala but the compiler is slooooooooow. The tooling needs work before it can be main stream.

The implementation is compiler dependant. Nevertheless, it would appear that the normal implementation is to create something which looks like a normal object with pointers back to the state it closes around. In theory it should be fast and light. The problem (as always with C++) is ensuring that the things to which the pointers point does not go away. Smart pointers help - but they are slow...

Which kinda goes to my point about out of memory exceptions - they generally end up being fatal sooner or later. Trying to catch them just results in memory running out somewhere else. The only place you can deal with them is if the code is doing something you expect to cause memory issues because it is consuming an atypically large amount of memory (like a cache or some such) which you can get away with shrinking.

... because the compiler knows how big the function like object will be at compile time when the template is used but it only knows it at runtime if the class is used. ...

I am guessing this is the situation?

That is really nice. Could you expand on how this works a little "You can also avoid problems with exceptions and std::function’s dynamic allocation by using a template instead:"

I get your points. In general, the use cases for this pattern are not production code. The post points out this is not a good way of handling resource and that the example is about debugging. It would be up to the implementer to ensure the finally clause does not throw and exception or to catch it (I think there is something about nesting).

As for memory allocation failures, my experience is that depends a lot on the platform. It is a common misconception that dynamic memory is likely to run out and therefore we need to worry about that but not automatic memory. However, I have seen stack overflow many many many more times than a genuine 'out of memory'. Further, if an application has actually run out of memory so badly that a allocation of the closure's internal storage barfs then I suspect it cannot be retrieved. Naturally this does not apply if your platform has a very low heap size (e.g. realtime hardware or some such).

But it never unseated IMS - that is a bit of a kicker.

As someone who has done the interviewing thing, I can see where this article is coming from. I don't really buy into all of it though. All this stuff about being a great communicator. That is cool but not always required. I have spent a lot of time working with amazing people who are crap communicators and crap people who are great communicators.

But - I am sure a lot of people interviewing use indicators like these so it it worth knowing about them.

Finally, on the CV thing. This is a hard issue because agents look for buzz words. If you've done a lot of stuff you need to write a lot to get all the buzz words in. That is the only way the agent will forward our CV. Then - you cannot tailor the CV to the job because you did not submit one for that job, you submitted one for buzz words.

Nice links thanks. Would you agree that there is at least a similarity in purpose between Currying in functional languages and fluent interfaces? It seems to me that techniques and ideas from partial application and currying are useful in the design and implementation of fluent interfaces.

Now the idea of open digital communication is well established, legal frameworks will not be able to do anything but slow it down. Whilst the US government is producing laws to stop free/open digital coms they are also developing stuff like internet-in-a-suitcase which is designed to get around 'repressive governments' which do to allow open access to the internet. This indicates the stupidity of using legal systems to control communication in this way.