Disqus - Latest Comments for dnene

Re: Configuring a secure Ubuntu Linux Virtual Private Server

Dhananjay Nene — Tue, 07 Jan 2014 22:46:58 -0000

It probably will be in /etc/apache2/conf-available as security.conf. Request you to study the documentation of your current version and adapt accordingly. It will not be feasible to guide you through each step given many versions might have changed since the long time ago this blog post was written.

Re: /var/log/mind

Dhananjay Nene — Fri, 04 Oct 2013 01:45:16 -0000

I am afraid I am not entirely sure how this will play out in an overall business context, though I grant one could pull it off. Notions like an elected origin (especially where the origin may not have remained current with the earlier disconnected origin) are likely to be hard ones to address.

Re: /var/log/mind

Dhananjay Nene — Fri, 04 Oct 2013 01:43:12 -0000

Thanks for that link. It is a useful addition.

Re: Configuring a secure Ubuntu Linux Virtual Private Server

Dhananjay Nene — Wed, 18 Sep 2013 22:41:09 -0000

This tutorial was written a long time ago. I continue to apply similar steps on my ubuntu boxes. It should largely hold true. But I haven't tested this tutorial specifically with 12.04.

Re: Exploring Java8 Lambdas. Part 1

Dhananjay Nene — Tue, 26 Feb 2013 16:53:33 -0000

I think python, ruby and many other languages have had lambdas for a long time and aren't as averse to breaking backward compatibility. I think the current structure is as a result of not changing much in an existing language and yet managing a substantial feature introduction (and also keep options open for more features in the future). The interesting part is that they've managed this without substantially impacting the Collections API, an API which was hardly designed for this scenario. In fact with scala you can just do

List("Larry", "Moe", "Curly") map ("Hello " + _ )

Re: The inverse of IoC is Control - Comoyo Engineering

Dhananjay Nene — Fri, 08 Feb 2013 18:25:48 -0000

I think one of the places I have found non code configuration useful is in product implementations. Different installations of the same product can configure many parameters differently based on local considerations without requiring an on site recompilation.

Re: Clojure/core — (take 5 baishampayan-ghose)

Dhananjay Nene — Sun, 18 Mar 2012 10:16:12 -0000

I've worked with BG on various tech events and have seen his commitment to spreading tech knowledge in general and clojure in particular, and thats very respect worthy. Working with a language not frequently used always creates its own challenges and joys. and to the limited extent, I've seen their products, they've been confidence inspiring.

Some of the comments here are disappointing, off topic, and tenuous innuendos. Really unworthy of further comment.

Re: Why OSGi? Or why not using it makes your JVM runtime unsafe.

Dhananjay Nene — Fri, 17 Feb 2012 04:10:03 -0000

No, it is not about encoding the dependencies in .poms as opposed to .jars. The reason they are in .jars I suspect is because the class loaders anyway access these jars and thus make use of metadata in them rather than opening up alien pom files. Its probably just a tactical call.

One would've imagined tools such as Maven/Ivy would've resolved this problem. But as I started using OSGi, i learnt there is often a long list of transitive dependencies, not all of them necessarily playing by the same rules. Some of them contain a breadth of features, many of which are not relevant to typical users. So such jars do not end up documenting the transitive dependencies required to support less used features, since they will not be required by most users. But there is no information left behind to indicate the optional use cases where additional jars will be required.

Re: One Div Zero: Too Dense?

Dhananjay Nene — Thu, 16 Feb 2012 23:00:44 -0000

Regexes themselves are a class of compaction of information which requires the programmer to disassemble it in his mind. Even as they attempt to solve another problem of compaction (often created by a non programmer), that of compacting multiple pieces of information into one string.

But it really comes down to the fixed cost of learning the method of compaction and unraveling. I spent the time attempting to understand regexes early on and that helped a lot. And the same is true about many of the dense functional expressions as well. Learn them well, and they are easy to work with.

The issue really is not with dense code. It is with "learn it well". There are 100 things that compete for a programmers learning attention. For some it is important to learn it well and then deal with it competently. Some find it not so important given other competing priorities and choose to learn just enough to move on.

Re: Scala needs terraces

Dhananjay Nene — Thu, 12 Jan 2012 11:26:24 -0000

Perhaps these are two different ways of looking at it. But I never perceived these as different languages. Just a "compilation profile" if I may use such a word, which allows a subset of language to be leveraged. Yes, a beginner may get an error/warning with regards to some code constructs, but compared to the amount of cognitive effort a scala programmer would normally incur during programming, this seems like a pittance.

Having said that I of course do not mean to contest your disagreement. I'm sure there are good reasons each one of us might feel differently.

Re: Scala needs terraces

Dhananjay Nene — Thu, 12 Jan 2012 06:47:07 -0000

There are organisations which control and teams who self manage. I believe self managing teams could be better served by some tooling support. Organisations which tend to control, are more likely to issue diktat's anyways (I've seen a few coding standards in the past which suggested "thou shalt not ..." even when there was no tooling support). So yes, what you say is a valid point, but I suspect that we'll see good applications and bad applications of the feature, in some cases even if tooling support was not offered.

Re: Scala needs terraces

Dhananjay Nene — Thu, 12 Jan 2012 02:12:05 -0000

Fair Point. Compiler switches would tend to absolutely classify important language characteristics, whereas terrace identification could be driven by evolving needs.

Re: http://blog.vivekhaldar.com/post/4525315474

Dhananjay Nene — Wed, 28 Dec 2011 13:12:48 -0000

I'm afraid, I find it hard to agree with your central premise - that of OOP favouring immutability. Both the paragraphs you quote refer to "not messing with the internal state" which is completely different from immutability. (incidentally, I had to hunt for the second paragraph in your blockquote, which I eventually found in section IV of the same paper)

I would recommend you to read a much clearer enunciation by Dr. Alan Kay about his thoughts on OOP here : http://userpage.fu-berlin.d... Again, you are unlikely to find a focus on immutability. In fact to quote from the same,

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of

Clearly, hiding of state has more to do with encapsulation than immutability.

In addition even assuming for a moment that OOP favoured immutability, the leap into wondering whether OOP == FP, also seems to be quite bold. There are other aspects of FP, eg. functions being first class entities, higher order functions, or composition etc. which make FP not just a immutable OOP.

Re: My Reasons for Leaving .NET

Dhananjay Nene — Mon, 14 Nov 2011 16:31:08 -0000

Good for you, you're going to be doing something you enjoy more. The best wishes for your career shift.

What surprises me is that you did not chose to call this post "My Reasons for Adopting Ruby / Mac / Unix / Hacker Culture".

What also surprises me is that if you believe you have the ability to take on Node.js, Scala, Clojure, iOS, and Android. going forward as you've mentioned, why would you want to "leave" .NET especially since continuing to leverage all that you've learnt with .NET will only be of assistance.

Or are you concerned about the amount of effort it takes to learn Ruby that it will be impractical to retain your accumulated .NET knowledge or keep updated with the .NET happenings? If yes, it would be important to consider that many of Scala, Clojure, iOS, node.js etc. are only likely to involve far more investment to learn than Ruby ever did. And would you then want to leave Ruby to join Scala, leave Scala to join Clojure .... ?

Re: http://blog.vivekhaldar.com/post/11570467259

Dhananjay Nene — Tue, 18 Oct 2011 14:32:46 -0000

If a software is fast enough with slow disks, shouldn't it be fast enough with fast disks?

Re: SIP-12 - Uncluttering Scala’s syntax for control structures. -

Dhananjay Nene — Fri, 14 Oct 2011 09:31:35 -0000

Could you consider changing "for x <- 1 to 10" to "for x in 1 to 10", or "x <- 0 until N" to "x in 0 until N". Keeps to the spirit of uncluttering, and minimises the imposition on the cognitive effort invested by the reader.

Re: Which risk would you manage? What would you want to prove? Programming Languages and Type Systems

Dhananjay Nene — Wed, 12 Oct 2011 04:26:19 -0000

Olle,

I've no experience with Perl, but I would think a python code base can remain useful for long even as one becomes a big player. My thought is that the maintainability of larger code bases has far more to do with appropriate refactoring being conducted at each stage as the code grows, than with the nature of language typing.

There exist large, well maintained python projects (eg. Django / SQLAlchemy etc.).

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 07:08:06 -0000

Agreed. Like any exercise the process needs to be consistent with the objectives, and there could be multiple ways of approaching the same.

=== a futile exercise by excessively aggressive (ie. code one would not write under reasonable situations) code

If I could make a statement objectively on that count, there is some likelihood this post would not have stood retracted. In the spirit of that retraction, it does not make sense for me to open up a topic in the comments that I closed out in the main body.

Having said that the comment could also be considered to be applicable to contexts outside this blog post.

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 06:30:56 -0000

I'm afraid I do not agree. And quite strongly too. I suspect it might be best to leave it at that as a difference in views.

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 06:18:36 -0000

Seems to me we're now going in circles. So there's probably some incomplete communication.

=== But we’re talking about user code implemented in Java, and Java library code implemented in Java – the same level. ===

I'm talking about coding styles implemented consistently across languages - not java alone, not cPython alone, not PyPy alone, not another language alone. I'm certain that I find the distinctions in performance based on the different coding styles useful and relevant, and think I'm better off because of the same. I'm also certain that I did not consider per language coding style selection, as much as I selected a portfolio across them.

At this point, I am unable to respond intelligently since, to the extent I've understood your points, I believe I've responded to them, and any attempts to respond will simply result in a restatement. So the gap probably lies in something we are unable to communicate.

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 03:00:12 -0000

Yes, but you are discussing code that is one level deep (not the code that the user wrote). At the user code level the distinction remains.

What is important is that I have an idiom which exposes the difference when such exists (such as cPython) and may not if the underlying implementation tends to a similar structure (eg. Java). Your statements just help me solidify my perception that it is important to bring in such different idioms even if they do not always result in different internal code under all cases.

That the Java code has references does not defeat the necessity of the idiom. That the python code implementation reacts so differently supports the activity that idiom was specified to bring out the differences in performance.

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 02:55:04 -0000

In fact this is a good case to plug for benchmarking using different styles of code as opposed to just one fastest possible way since it can a) highlight some particular strengths or weaknesses of a runtime, b) is likely to provide a better commentary on which styles suit which runtime and c) is less likely for the benchmarking to consistently be made into a futile exercise by excessively aggressive (ie. code one would not write under reasonable situations) code.

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 02:47:25 -0000

Yes, but benchmarking code through writing the same logic different ways helps me understand the stresspoints in a more nuanced way than just the "usual suggestions" :)

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 02:30:38 -0000

Umm .. not sure if I am unable to understand your point.

I see here from my very first commit that distinction does remain

OO Code having references
https://github.com/dnene/jo...

Element Recursion using a linked list

https://github.com/dnene/jo...

Re: Contrasting Performance : Languages, styles and VMs – Java, Scala, Python, Erlang, Clojure, Ruby, Groovy, Javascript

Dhananjay Nene — Mon, 29 Aug 2011 02:02:23 -0000

As I mentioned in my extended comment above (you may not have had a chance to see my addition regarding cPython) - the difference is actually quite relevant here. Java is not the only language being benchmarked. It may not make a big difference for Java, but it could for other languages (and in this case it does).