Hacker News Reader

Comment by ZenPsycho | Hacker News Reader

Okay so may I ask what is the point of this question? (edit; I guess asking for clarification is looked down upon here?)

View on HN

As for my reply to your deleted reply:I thought you were tongue-in-cheek.

As for my reply above: "you should not have that problems" does not make them go away: some problems solved by software are inherently complicated and cannot be reduced to some simple API calls or a 5kloc code base. Composition of 100 multiple 5-kloc code bases still makes them a 500-kloc code base with all mutual dependencies.

Just saying "you should not write so much code" might display inexperience with problems which fall outside of the currently common javascript apps ...

It perhaps depends on how those 100 multiple code bases were written. I won't lie and say I have experience with inventory systems. But I will take the position of the young upstart dipshit and suggest perhaps the reason you end up writing such huge tangled messes is you just haven't thought of a better way to do it. Javascript might not be the best tool for such jobs though, the way the number type works- on its own, makes it impractical for accounting tasks.

I'm completely with you that messiness is best tackled by loose-coupling parts early on. It's only that I found the combinatorics of many small systems not so much easier to tackle than their monolithic counterpart.

The worst is even that you (or somebody else) begins with good intentions ... and then , 4 software generations and law changes later, the complexity starts to smell.

Heijlsberg argues, that javascript will be harder to refactor in those cases. I can't really disagree with him.

So it find it's not so much lacking thought. The current thought for some is "let's use javascript", let's see what comes of that... :-)

I couldn't watch the video. I am starting to think though, that the sweet spot is to not just simply use javascript for everything and hope for the best- or to use java or something else and enjoy the sweet refactoring IDE glory, but a synthesis of making well tested components in a static language that you orchestrate with a scripting language- (if I have a choice, I actually would probably choose lua). In my experience so far, a lot of tangle often comes about by a confusion of library code and application code- the two styles of programming are very different. A module is very structured and regular, while application code seems to be ad hoc, specific, and irregular. There's nothing stopping both from being written in the same language, but if you decide that libraries go in one language, and application code goes in another, there's smaller risk of the two accidentally forming interdependencies. Then you set the goal that the dynamic portion of the program is to never exceed 2000 lines of code- and you have the basis for --- an experiment at least. Since really that's kind of what we are all doing. It's pretty well known by now I think that nobody has discovered a One True Way of doing this software stuff.

We haven't really figured out how to write large complicated applications- Static analysis is no magic bullet, and neither are dynamic languages. I think what we are seeing is just a kind of physics of the mind- reactions and re-reactions to unpleasant experiences we've all had, and are trying to avoid, which leads us to polarise on the static/dynamic divide.

Reply on news.ycombinator.com