skysight-inc/HackerNews huggingface dataset:
thanks everyone for clearing this for me... I guess you learn something every day, even after 30 years of programming. I would have never thought of the infamous "computers are good at processing text" argument. Is there an archive of pro-vi arguments somewhere?
I use only WP. Got two 925 & 520.

I don't think WP will overtake iPhone in sales in that time frame.

Reason #1 - OS restrictions - The multiple restrictions in WP especially app sharing will keep it's market share down.

Reason #2 - perception. Where I live, the perception of people even "experts" (although wrong) is that WP is hard to use.

Reason #3 - availability. Android consistently beat WP on price in the past but that is changing. However, Microsoft is a slow bison. It's product release schedule is haphazard. Low-cost Lumias take up to 10 months before they show up in my market.
It'll need faster distribution methods because people can only buy what they see.
Is there a screencast / youtube video that showcase VIM with most or all the features mentioned by Illniyar ?
> Do you think that if Greece had defaulted on those loans they would have been better off today?

Yes.

> Are you aware that that situation would have meant MUCH bigger cuts to public spending than those requested from the so called Troika?

No, I am not, that's because this scenario is nothing but fear-mongering without any base in reality. It is always put up when an alternative to the current course is discussed but is nothing but hot air. If you are "aware" that your scenario would have happened provide a proof.
One needs to implement life long learning! We are working in a field where there is exponential growth in computing, networking and storage and what computers can do. The robot automation artificial intelligence age are coming!
Ordering food will be automated, cooking food will be automated, the post office will be automated. Shopping will to a large extent be automated, there will be 3D models of your body captured by your cell phone or 3D scanner booth. When you enter the shopping mart of the future, the food will come to you, you will not pick it up unless you want to. Why use a shopping cart when you can have a robotic picker do the work for you?

That said I see different things in different people getting older. Some people like life long learning, they will not have an issue finding jobs. Some people stagnate in their internal development after college, they use the same programming languages and tools as they did several years back. They are probably more in danger of getting obsolete by new tech. I think there is danger in your career path if you stagnate as a growth as a person. This will get worse the older you get unless you change.

With years of experience you will also realize that there is fashion in programmer tool chains, it's not necessarily that Javascript is better than say Ruby or Python but it sure is in fashion. Same can be said about NoSQL tech such as MongoDB it is not per say better than sharded MySQL and Postgres but you should still learn it because your younger peers will like it. I like to learn new stuff so I follow along. This also covers fashion in Javascript libraries such as AngularJS and React, there will something greener in the library field down the line I'm sure of it.

Love to learn! If programming is anything like martial arts you will just get better and more skilled with age, take and go the new tech coming in.
I'm quite sure there's more to software engineering than can be learned in 8-10 years. I spent 7 years working with one tiny part of formal software verification, and still didn't get to the bottom of it. Perhaps it's true in web development, where it does really seem like the industry is
recycling ideas every 18 months. But there's far more depth to the field than just "JavaScript framework n+1" and "Yet another task running tool fundamentally identical to the previous 328, but written by a fashionable company".
> So if Martin Fowler says that it is possible to use a service locator instead of DI in unit testing, then who are you to argue otherwise?

There are good arguments against a service locator - one of them is presented here:
http://blog.ploeh.dk/2010/02/03/ServiceLocatorisanAnti-Patte...

Another argument again the service locator pattern is this: If you ask the locator for a service which has dependencies you have to resolve those dependencies yourself. So you need to know about the specific implemntation of this service interface which defeats the purpse. If you work around that, you end up with something that is pretty close to a DI container.
This is how children need to speak with adults. This automatically helps them to do this by nature and it helps children's behavior.

I raise my child with me all ways saying, "Are you asking or are you telling?" If they tell I ask for a re-do and than 90% of the time it is all set.
My reading is that he wasn't laughing at her plan intentionally. Her plan was so bad that he thought she was joking, and he tried to be polite by laughing at the VP's joke.

There's nothing wrong with him. As I wrote above, as the brain ages, you get more experience and depth and foresight. The problem is that the decisions that use these abilities don't belong to programmers - they belong to managers (in this case the VP).

This is one of the main recipes for perennial frustration - be an older programmer trying to act like a manager from the bottom of the hierarchy.
This is terrible for Datasift, but I really hope they saw this coming. Twitter buying Gnip should have been the writing on the wall.
Ask HN: Will AI be reality before 2050? Will AI steal our jobs?
New Mexico Ends Civil Asset Forfeiture
I suspect that sharing salary info will result in a gradual downward grind in salaries, as people are offended by seeing someone make what seems like big money for easy work. This has been the case with public school teacher salaries.

I also think that salary data, with no corresponding ability data, will be meaningless.
I absolutely agree. Over the years I've worked with many sharp guys that are 50+ and their experience always commands massive respect from me. People who dismiss the more experienced segment of the workforce are, to me, absolutely, inexcusably incapable of critical thought. If all one sees the glitz of the young guys at TechCrunch Disrupt and concludes that they're the only talented devs out there, I want nothing to do with that person in a professional capacity, to put it plainly.
The main problem with hiring grey beards, as you put it, is that a lot of them aren't amazing, but due to years, they have an authorative attitude and expect to be paid more than your 20 something devs. If it's my money, I'd hire the 20 year old with gaping holes in their knowledge who are willing and eager to learn over the 40s something dev who thinks their way is better because they're 10 years my senior. I have a lot of anecdotal experience where I've rejected folks who were lacking a basic understanding of the pro's and con's of something. These guys aren't rejected because they don't understand the subject, but because they fail to accept there are scenarios where doing something the other way is better, or that at the very least, things at a bit give and take. This, I postulate, is generally because these guys have 10 years of 1 years experience, rather than the experience they're trying to sell themselves as having. These are the type of guys who will struggle when they're older. That said, when it comes down to it, most of the guys I try to hire are older than me. Age isn't a deciding factor, they just tend to be better.
Show HN: Briks - Group Social Posts from Individuals, No Matter Where Posted
Domanik Green is not black: http://www.wtsp.com/story/news/local/2015/04/09/pasco-teen-h...
Combined with sarcasm, you find yourself with trolling.
I am just asking...
The progressive degradation / enhancement trend has definitely faded away. Nowadays it's far too often all (js) or nothing.
Here you go: https://www.youtube.com/watch?v=7sr8cAIwdBs
I agree, the Balsamiq-style sketching is cliche now, and isn't very well implemented in this case. A clean wireframe that doesn't pretend it was handdrawn, and good typography, would be much better.

I couldn't use this as is, unfortunately.
Why did the Angular team choose TypeScript over Dart?
>Never, ever trust another company for your business model.

This is just another thought-terminating cliche not unlike "if it is free, you are a product" and I can't help but respond.

Large technological companies create ecosystems where smaller players can coexist with "hosts" in a mutually beneficial relationship. Ecosystem companies are not able to predict the future of the ecosystem, its evolution for all intents and purposes is mostly unpredictable. Sometimes the relationship works out, sometimes it doesn't.

Startups have 70-90% failure* rate, the possibility of the host cutting of some parts of the ecosystem to integrate their food chains into the corporate borg is factored in the business and investments strategies of the smaller companies.

You should not trust another company for your business model, but building your tech business in the ecosystem of a large fish is an absolutely valid and quite possibly lucrative strategy.

*definitions vary

EDIT success/failure
You achieve absolutely nothing with your casual dismissal and sarcasm.

The fact that you have not made a single counterargument to any of my points betrays a lot.
Not only after Soviet Union fell. Also in the current trade war, Greece's problems from Russian sanctions are negligible when compared to Sweden and particularly Finland. Russian trade was almost 10 % of Finnish exports in 2012 and has since then collapsed. Finland will very soon be in a position where it is not possible to pledge any bailout money for Greece. Even if not counting the political fallout.
What is evil in our profession is that everyone professes some technique or another that has worked for them, without mentioning any specifics about the exact situation in which that technique worked. Infact most programers go out of their ways to avoid mentioning specific experiences, confident that their grand designs generalize across all projects, platforms and languages. Just look up the recent TDD debate with Bob Martin and DHH and see if anyone mentioned one specific project / example.

As a result we end up with long diatribes of barely useful "best practice" advice that is spread by means of cargo-culting and that causes problems down the line.

What we need to collectively do is get off our high horses and start talking about specific projects, situations and problems. Start asking ourselves: Why did our solution work? What was the specific problem and situation? Which properties of the problem made our solution the right one?
To clarify: This coincidences of four-space location are a good thing, and the point is to help find them. Giving them a natural, catchy name is critical to help people understand that they are desirable.

Thanks to those who have contributed so far - much appreciated. Shame this didn't get more upvotes, attention, and/or more suggestions. <fx: shrug />
> The big picture is that computer programming is a field with low barriers to entry and where young people have a significant advantage.

Computer programming isn't just one field, there're several completely different fields. All what you said might be true for the web development field, where the technology at hand isn't really that hard and you apply more or less the same technology and knowledge for each web project.

But there're several other fields where experience and knowledge are a lot harder to gain, and therefore also count a lot more, just look at the systems programming world or the more engineering heavy fields.

At my firm are a lot of >50 year old people, which are valued a lot for their knowledge, and our work isn't about getting shit done as fast as possible, but about getting something done right.
I agree with your basic point, but I'm not sure you even need the mutability requirement to capture one of the underlying issues: you have an implicit dependency on something elsewhere in the system. Even if that something is constant, or at least constant during any particular program run, it still means you can't change the code that sets it up without checking your entire code base for unintended consequences. From this point of view, mutability just makes an existing fundamental problem worse, though it introduces new problems as well.
I think the logic goes that out of everyone at this company -- probably dozens or hundreds since OP says it's well known locally -- OP was the one that the plaintiff knew about and called up. Probably because the OP is a big-mouthed trouble maker and everyone knew it. Or something.

Whereas everyone else at the company were good team-players and kept their mouth shut and head down, so the plaintiff wasn't sure if s/he could count on their testimony or if they even knew anything.

Again, just explaining how someone might fear the logic would go. Not saying anyone does or should actually think like this.
The interesting thing about engineers is that they have very little tolerance for these destructive social shenanigans. Courtesy and politeness are one thing, but ignoring such a flagrantly flawed plan goes beyond courtesy and into professional negligence.

When empirical thought is your bread and butter, as it is in the case of software developers, it's hard to see why you should have to acquiesce to the VP's ego. If one intentionally stays off the political tracks, there really is no reason they should have to play unreasonable political games. Workplaces would be much more efficient if we accepted, or at least heard, the advice of the people who get paid for their expertise, instead of cowering in fear that we may damage the ego of some fragile soul who ended up in management because they were not competent to do any real work directly.
The point is not that there is nothing to learn after 8-10 years. There is enough to learn for multiple lifetimes. The point is that after 8-10 years additional learning/experience will not give you a competitive advantage compared to younger programmers.

Also, I can see why someone would downvote my post above, since it describes an unpleasant reality. But I think it is crucial for young programmers to be aware of this dynamic!
not when compared to all other profession that require a degree, constant lerning and are higly specialized (each enginering branch is not interchangeable, as well as within the same branch specializing in one area reduces your employment prospects in others)

also, the majority of managers are not the one that are in charge, taking decisions, managing risks and settings directions; middle managers types are way more common. and I do respect those of them that work well, but they are so hard to find that I'll stand by the 'most' in 'just organize things'.
* No tabs.

-> multiple vim plugins provide really confortable tabs.

* No project structure.

-> plugin. if you want that kind of tree next to your editor. (i.e. Nerdtree)

* in my IDE (eclipse based or intellij based) I can ctrl-click a class/object/other to navigate into that object's definition

-> tag search plugin. Haven't played with it much though.

* in my IDE I can search for classnames, I can press ctrl-T to find who inherits from something, ctrl-alt-H to find who uses something etc...

-> I believe there are some plugins for but here i haven't seen anything good so far.

* auto-complete(with annotation to tell you what the function variables are)

-> you complete me. plugin.

* debug inside your IDE

-> good point. have to wait for Neovim for this - I believe. Installing current WIP version from neovim is on my todolist. ;)

* run code-lint, auto-build on typing to detect errors, etc...

-> syntastic.

* auto refactor (I.E. extract method, move variable, extract class etc...)

-> good point. don't know any good plugin.

* format all your files according to your pre-specified project guideline.

-> plugin.;)

* sharing you IDE configuration with other contributors

-> here truly most IDEs suck. For vim you find lots of shared vimconfig on github.

* showing when files are/aren't in version control and integrating version control so that you view history in your IDE.

-> if you need to do in the editor... there is plugin for that. However, i found git command line is usually find. and for more serious committing I use GitX (L).
- DI doesn't add a lot of overhead. You don't really explain where it is EVIL, just that it is NOT STRICTLY NECESSARY ALL THE TIME.

- It handles complex cases such as dependency X should be a singleton, or inserting a layer of caching in front of dependency Y.

- It handles cases where dependency Z requires runtime logic to determine which implementation to use. You can do things like in PerformanceCriticalPackage use the HighPerformanceLogger and use some other logger else where. Want to switch these around, only need to touch the DI wiring logic.

- I find it keeps modules that use other modules "cleaner" without having any kind of dependency construction logic in them.

> Design patterns are an option, not a requirement

Using in DI is a design pattern and I agree all usage of design patterns need to be justified. However not using DI and manually creating dependencies is ALSO a design pattern! You need to justify using either, or something different.

Of the available options, using DI is generally the safest bet, especially if you want consistency throughout an application, since it's likely you will want this power somewhere.
Yeah. I only heard about "dependency injection" a few months ago, and my reaction was that my brain just didn't get it, because, like, why are you making a huge deal about such a simple thing? If we made this much of a big deal out of every idea in programming, we would never be able to get anything done.

Since then I keep hearing about "Dependency Injection" so my impression is that it's gaining in popularity. But my kneejerk reaction is always that if someone is talking about this subject, they probably are not a very good programmer, just like if someone is talking about how important UML diagrams are. It is maybe a hasty conclusion but that is where my brain goes.
You can load a die but you can't bias a coin (2002) [pdf]
Greece should have flirted with Russia earlier? I don't get that.

Of course, regarding requirements for compensation from Germany, it would have made sense to ask those in 1980, i.e. before joining an economic community with Germany, a community whose purpose was to put back wars and their compensation requirements, and start up a free trade area and bind economies together to avoid further clashes and wars.
I initially thought, hey great that's something you simply include and have a base layout that's a great starting point for any type of project, but after looking through the document I realized that it comes with as many "modules" as bootstrap or other full-blown "css-frameworks". Wish they just made a better and more consize and proven {normalize.css reset.css base.css}

Some of the styles are nice and ready to copy though, ie. the table styles, but not sure what the intention of this project is.

--

→ What lightweight css-starter-kit would you choose for any of your upcoming projects? Other than reset.css or normalize.css of course :)

I don't like bootstrap and similar, because it's just too large and most people end up using all of the classes and the whole javascript instead of only the stuff they need. Bootstrap is absolutely great for projects that quickly need a whole "UI Theme" fix.
The US Patent Office Trashes Key Portions of the Infamous 'Podcasting Patent'
Adding up to a big win – MIT News
The Best Ever Sludge Metal Song About Particle Physics
> "Global variables" is really language specific terminology for global data.

Strange, I thought it was terminology for global variables.

> What I mean by "globals" in the scope of testing is "side-effects"

Which is as whole different kettle of mackerel. Minimising side-effects is, of course, excellent advice, and can help with testing. But global variables and SL are not the same thing as side-effects.

Your example (of testing a database) seems very confused to me. You're talking about coupling now. Not global variables. Why would you suddenly need a database connection? Why does the existence of global mutable state mean that nothing in your code can be tested independently? You seem to be imagining the worst case of coupling as an argument against service lookup.

The last paragraph seems blatantly false. You're again straw manning this version of an SL that is mutated in arbitrary places through the code-base and therefore can't be tested in isolation, and neither can the components that use it. That is a strange version of SL you have here, and one that DI wouldn't help with.
I really like LyX!

http://www.lyx.org/

For beginners or people who don't know / don't want to learn Latex, it's great. It's a bit more clunky if you're more of a latex "power-user" and want to customise stuff, but still possible, though a regular latex editor might be a better choice in that case.
Interesting idea, but it essentially requires users to build up a significant online presence to be trusted. Many people do not have the time to do this, and some just value their anonymity. How would this work for those users?
Here's a plan: move outside the Silicon Valley circle jerk. You won't get a ridiculous superstar salary, but you get the chance of working on actual products instead of throwaway MVPs.
<div class="col col-6 sm-col-4 md-col-3 lg-col-2 px2 mb3">...

Another example of something that's tiny and super fast for prototyping but produces code bloat and non-semantic classes. Looks great otherwise. No SASS version?
> Startups have 70-90% success

Don't you mean failure rate?

> You should not trust another company for your business model, but building your tech business in the ecosystem of a large fish is an absolutely valid and quite possibly lucrative strategy

Yes, as long as if you have a Plan B if/when your relationship is cut (a valid Plan B is to close shop and try to do something else with the expertise gained)
I disagree that it's a "thought-terminating cliche" - it certainly shouldn't be. There's a difference between trusting someone, versus using them to your advantage but having an exit strategy.

I agree entirely that there is value, sometimes significant, in exploiting the ecosystem created by a larger fish. You'll see that in my comment, wherein it says:

... leverage off XXXX to
start with ... be able
to shed [it] and replace
it with something else.

You are saying the same thing I've said, but emphasizing that starting in the jaws of a larger fish is sometimes worth doing, and sometimes they'll deign to let you survive there.

Consider, though. If you become successful - which is surely your aim - then you will come to their attention, and they will do whatever they like.

So I repeat: Don't trust them. Use them, yes, but don't trust them.
I started with MiKTeX [1], an all-in-one package including TeXworks. Even tough it's a nice software-package to start with, I would (indeed) recommend using Texmaker instead of TeXworks. It packs more features, but is nonetheless not very complicated.

[1]: http://miktex.org/download
I've always found these "lego" languages cumbersome to use, even as a novice. I think a nicer alternative would be to use a (simplified) IDE with good code completion, error highlighting as-you-type, edit-and-continue etc..

Funnily, one of my first languages (after Basic and Pascal) was VB6, which had for that time an excellent IDE.

If I had back then something for C/C++ as good as XCode / Vim YouCompleteMe / ReSharper C++, I would have been much less scared by pointers. Just write `myvar.` and if it doesn't complete, try `->`. If you forget an address-taking & or a dereferencing *, you'll likely get a red wavy underline and correct it easily without compiling.

Maybe combine that with a snippet palette, and a good help function, and you have someting that is both great for learners and for advanced users.