Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Top Developer Tools of 2016

stackshare.io

Post reply on HN
Print view View original

31–40 of 72 posts

Re: Top Developer Tools of 2016

#31

Post by shuntress »

ysavir wrote: post #23
Arzh wrote: post #19

Earlier quoted context omitted.

Yeah you can call the language a tool, since most languages can get the same job done but some do certain jobs better.

JavaScript has consistently beaten out any other language as the client-side language of choice in both my personal and professional projects. Clearly, it deserves the top spot.

I believe the grandparent is attempting to make a distinction between a tool and (for lack of a better term) a material. With the idea being you use tools to shape your materials to create your end product. You carry the tools with you from project to project but the materials stay in place.

To use the normal house-building analogy, I would say that the Tools are obviously saws, drills, etc. Things that you use on every house you build but that are not part of the house itself. These represent notepad, visual studio, git, etc.

The Materials are wood, nails, etc. Things that make up the house and are not removed when the builder leaves. These represent the actual code (ie, lines/libraries of javascript) you build with your tools.

e: So it's like saying the #1 carpenter's tool is wood.

Re: Top Developer Tools of 2016

#33

Post by shuntress »

skinnymuch wrote: post #28
lojack wrote: post #21

Earlier quoted context omitted.

Absolutely 100%. The only time I ever call a company for support is when they don't have chat. My company provides both chat and phone support to our customers (many of whom aren't technically savvy) and chat is overwhelmingly more used. Support staff can also handle more throughput with chat since you can easily have 5 simultaneous conversations at a time. Outside of analytics, real time chat is almost always the fi…

OP is talking about chat as a feature in a product. You're talking about something completely different - customer support chat.

If your product is a web site, having custom support chat built in to it is a feature.

Re: Top Developer Tools of 2016

#34

Post by ravitation »

ysavir wrote: post #27
mgutten wrote: post #20

Earlier quoted context omitted.

Since we aggregated data across all users, our "web" tools definitely shone through (as you might imagine, there are more web devs than native on stackshare), but given that we included all tools we felt it was more accurate as a description of the methodology. Do you think it would be valuable for us to segment these rankings further next time? Create a couple different rankings?

Sure. It's not so much about splitting it up, though. It's about providing a title that will attract the correct audience. But good luck getting that past marketing.

I mean, it's a list of the top developer tools from StackShare users. If you were going to change the name to something it would have to be something like "The Top 50 StackShare Developer Tools of 2016", that would be correct but also a bit redundant...

Since the data set (StackShare) isn't inherently limited to just web developer tools (it's just biased towards them), titling it "The Top 50 Web Developer Tools of 2016" would just be incorrect and a misrepresentation of the data.

Re: Top Developer Tools of 2016

#35

Post by gglitch »

ohyoutravel wrote: post #5

JavaScript, Python, PHP, and HTML are developer tools? (yes, they're listed in four of the top ten spaces of Application & Data Tool of the Year) Isn't that like saying the #1 business tool is "The English Language"? I guess I expected a list of things people use like this one (which is phenomenal): "Scott Hanselman's 2014 Ultimate Developer and Power Users Tool List for Windows" http://www.hanselman.com/blog/ScottHa…

I'm not missing the point of your satire, but I'd love it if more people considered language arts a powerful tool worth mastering to an advanced degree.

Re: Top Developer Tools of 2016

#37

Post by Arzh »

shuntress wrote: post #31
ysavir wrote: post #23

Earlier quoted context omitted.

JavaScript has consistently beaten out any other language as the client-side language of choice in both my personal and professional projects. Clearly, it deserves the top spot.

I believe the grandparent is attempting to make a distinction between a tool and (for lack of a better term) a material. With the idea being you use tools to shape your materials to create your end product. You carry the tools with you from project to project but the materials stay in place. To use the normal house-building analogy, I would say that the Tools are obviously saws, drills, etc. Things that you use on ev…

I don't think that is a good analogy. The end product (app/house) is what the code actually does. What you use to make that product is a tool, including what language you use.

Re: Top Developer Tools of 2016

#40

Post by waisbrot »

daveguy wrote: post #14

Well, this did point me to a shared password system with an API that I have not seen before: passbolt [ https://www.passbolt.com/ ] I have been looking for something like this for a while to securely access and share credentials from an application. GPL makes me nervous though -- especially AGPL. Does AGPL prevent you from using it as a service from within a separate program? For example, if OAUTH was AGPL would no o…

Probably not, but it depends on exactly how the code is arranged.

AGPL says that anyone who can use your code (via web service) counts as having the code "conveyed" to them, which means the GPL terms apply.

The purpose of this is to stop cases where I put GPL-derived code on a smart TV but say that since I don't let the TV owner touch the code I don't have to open source it. Or I wrap GPL-derived code as a web service and don't offer the source because the GPL'd code stays on my server.

In your example, maybe Facebook takes some AGPL OAuth library and adds 20 lines of code to talk to their database. If they now give you access to call their OAuth service, they must honor a request from you to look at those 20 lines of code. If the OAuth library that you use to talk to Facebook is also AGPL and you give someone access to your service, then you have to release your source to them.

Post reply on HN