hackula1

Some of us are in social circles where almost everyone smokes.

> but it is certainly a toxic substance, in the medical sense.

Excuse me for not accepting the pseudo-science weasel word "toxic". Vitamin C is toxic at certain levels. If you do not bring in more specifics, then what you are saying is meaningless. Just saying "I choose to reserve judgement, but have a gut feeling that it will be shown to be more harmful than cigarettes" is about as far as strong a claim you can make based on the evidence you have presented.

I was referring to the new implementation in JavaScript.

Retire after 10 years of salary work? I don't think so.

IMHO, new languages are dominated by people that are not the best, but are on their way, as they will spend an inordinate amount of time learning from the best in older languages out of necessity. The arrogant go devs of today are likely to be the jaded experts of tomorrow, as they will be forced to learn in ways that devs on an established platform rarely must.

ST is not open source, which makes this argument pretty much moot, and I still doubt this project will ever be a fraction as popular as ST.

Completely agree. I AM a developer, and I still would have no idea how to help 90% of the projects that I use as dependencies. Each developer has their own area of expertise, and it is completely unreasonable to expect everyone to be able to fix everything they use without an ungodly amount of effort. Sure, I know how to code, but if my graphics driver has a bug, someone telling me "hey it's open source, why don't you fix it?" seems like a completely disingenuous response to me.

I have absolutely 0 problem with this, as long as a disclaimer is listed like the OP did. I honestly think this is the right way to do it. Imagine though if apache had some major security flaw uncovered tomorrow and the maintainers said, "This is just an open source project. You are free to look into the issue and fix it yourself if you want. We will merge the pull request when we get around to it.". Managing expectations is-- as usual-- everything.

I recently had a need for an algorithm that did some pretty complex geographical data interpolation that was faster than the existing implementations. The modern vendor library I was using took about a minute to compute.

I searched through some old archives and found a scanned in PDF of the algorithm I wanted to implement from a late 60s fortran implementation. I converted it to node.js and Presto! The thing takes the exact same inputs, gives the exact same outputs, and does it all in... 35 milliseconds.

With the complexity of the algorithm and size of the dataset I am pretty sure it would have taken a mainframe the size of a warehouse and weeks to compute back then, but it showed me that the underlying data structures and mathematics have not changed in the least.

I have always tried to take it to heart that "we stand on the shoulders of giants" and all that, but this was really a turning point for me over the last few weeks, that many of the greats from the past would make us all look like morons if they were around today.

There are implementations of this algorithm in C, C++, Java, Python, Javascript, and probably others, but they are all at least an order of magnitude slower than the one that came out back then, given the same modern hardware, even in a language that is not exactly known for its computational prowess.

I remember seeing code bubbles when you released it and thinking it looked much more promising than the flow-based approaches to abstracting away code files that we usually see. NoFlow and the like tend to ignore the fact that:

1) The approach has been tried countless times before and failed.

2) Programmers don't need code abstracted away. Text is great for telling a machine what to do. The real pain point is in linking pieces of relevant text, something that OOP does pretty successfully, but still leaves some room for improvement.

3) Nobody has 25 feet of screen space to see an entire program on, and scrolling around over giant flows is a huge PITA.

4) Attempts to solve the screen real estate issues through collapsable nesting of flow paths usually lead the same incomprehensible rat's nests of logic that regular old code does.

5) Business people don't want to code, despite their fantasies of kicking all the expensive programmers to the curb. Computers usually do exactly what you tell them to, and talented programmers are different than your typical business people in that they have a knack for taking high level requirements and turning them into highly complex, low level implementations. Someone who has no interest in this sort of work will ever be any good at it IMHO.

6) Building flows requires 99% of the implementation to already be complete. Stringing together prebuilt modules with if/thens is not that difficult or unreadable in textual code anyway.

This is what professional support contracts are for. If someone really wants something implemented that is of no use to anyone else, then they should pay for it.

It is still pretty trivial to find a job in Python, Ruby, or JS in just about any metro area in the US. I do not know anyone in the node.js community that would even go to someplace like monster to find a job. Most of these positions are found through networking with the community, which tends to lead to finding better quality jobs anyway.

RoR vs Asp.Net is largely community (and modules) vs tools. Both are important and I am not sure if a combination of the two is even feasible. VS is like crack, it's so good, but at the same time nuget looks like a joke compared to gems. TLDR; nobody is good at everything because different things are optimized for different cases.

The government will often request an RFP that basically entails doing the entire project so that the vendor can do the 5 minute demonstration to show that they are capable of completing the project. This greatly inflates prices, since the stakes for the vendors are so ridiculously high.

Quality of life is up just about everywhere else as well over the last several decades.

Bell and IBM show that this does not always work. MS may be the next example in ~10 years.

Incentives tend trump all, especially in major grey territory like this.

I had a feeling someone would bring this up. My main counter here is that there is a power dynamic at play here that makes it extremely unlikely that a child will be able to decline. Imagine a teacher saying to an 8 year old "Stand up, face the flag, put your hand over your heart, and say these words." To a child, this is not a suggestion, but a command, and few kids are going to stay seated and respond "Sorry teacher, but due to the 1943 Supreme Court decision, I have the right to decline participation and will now exercise that right."

A couple suggestions:

callback hell -- 1) Define your callback functions instead of passing anonymous functions everywhere. 2) Use a control flow library like async. https://npmjs.org/package/async This will greatly help in complex scenarios and the "waterfall" mode is particularly useful to accomplish something similar to chaining where values flow through multiple functions. Callback hell is not really an issue for most people after looking into these two things.

data manipulation -- https://npmjs.org/package/lodash lodash is a fast functional utility library that makes it much easier to do the everyday data manipulation tasks. I pretty much assume this will be a dependency whenever I start a non-trivial project now.

lack of standards -- Most people who really like node.js see this as a feature not a bug. This definitely drives away many people, but the intention is to promote as much choice as possible. Node.js people tend to be obsessed with choice and modularity. This is not meant as "you should think this way too" type explanation, but just a rough description of how the community is, good or bad. That being said, there are some standards out there. For example Felix's style guide is followed pretty well throughout the community (with a couple notable exceptions such as some of TJ Holowaychuk's stuff) http://nodeguide.com/style.html.

mocha output -- It appears you have your reporter option set to "spec". This is a great reporter for visualizing a set of features, but for integration with something like Jenkins, I would recommend "tap" instead. It is also pretty trivial to write your own reporter, and then you can get whatever type of output you want. https://github.com/visionmedia/mocha/wiki/Third-party-report...

mocha integration testing -- I agree that the example you showed was more of an integration test than a unit test. Mocha is not really doing anything to discourage unit testing though, and I would note that integration tests can be valuable. If it were me, I would tend to have my unit tests working against the actual module, instead of an endpoint, which is kind of sloppy.

I hope that helps though :) I know it is often frustrating coming into a new language ecosystem, especially a "friendly-anarchy" oriented one like node.js.

The whole idea of a "pledge of allegiance" strikes me as extremely creepy. Having our kids giving their daily state worship by saying a "prayer" and physically submitting themselves to a state icon is something that I would expect would upset both secular people like myself and religious people.

I would not mind them too much if their time frames were more reasonable. A 2 year software patent would seem ok in my mind.

Discouraging 50% of the population from contributing just seems a bit inefficient to me.

If a 20-30% downpayment seems completely unrealistic, then you are probably not in area that you can afford. A home is like a car, in that nobody forces you to buy the Porsche, and you can always buy something in a cheaper area. A location with a median home value of 600k is definitely in the "Porsche" category of locations. Go find yourself a Camry.

Android clearly went in a different direction post-iPhone.

80% does not a monopoly make. Microsoft was in an entirely different position at the time.

MBA is great but this saying is dead wrong.

For me, mbpr 13 is a really good balance between usability and portability. I was Thinkpad + linux for years, but I find the mbp hardware feels a bit sturdier, compared to other options in the same price range. The main contender for me was the Thinkpad Carbon, but I liked the feel of the mbp keyboard and trackpad a bit better (The latest TP has weird rounded keys).

I am not a professional by any means, but I use an oscilloscope frequently when building guitar effects pedals. Being able to see a fuzz pedal's "clip" is extremely useful.

This pretty much sums up how that would go down.

Q:

Should return 3 for this test case

x = add(1, 2) assert.equals(x, 3)

A:

function add(a, b){ return 3 }

The headline should replace "code" with "markup" for clarity.