Ask HN: How to bet on autonomous vehicles? - <AUTHOR> If autonomous vehicles takes off this will surely disrupt a lot of areas and change the way our cities are constructed and how we think about getting around. I know there are a lot of challenges and hurdles before this happens on a grand scale, but I am confident that we are moving in this direction. Given this, how would you bet on this today? Are there any companies, or types of companies, that you think could reap a lot of benefits of such a macro-scale development? <comment><USER2> How much money do you have to bet?</comment>


Ask HN: Suggestion for software methodology in growing small-scale company - <AUTHOR> As a co-founder of a software company, I have an experience of working in the various projects in last 3 years. We founded our company with 4 teammates and currently, we growing to 16 teammates. our teams separated into two sub-team:
a) Most of our developers work on developing software solutions (Mobile and Web Applications) b) around 3 or 4 people work on Machine Learning
In some projects, two teams work separately and in some projects works together to develop intelligent and full-stack solutions. usually, we have 5-7 concurrent project in our company.
My challenge is about managing projects that concurrent and dynamic and we have the serious problem in managing project. Do you know any software development methodology or any suggestion that works well in our case? <comment><USER2> So what are the problems you're facing? Coordinating the deliverables? Not enough people to tend to all tasks? Something else?

<comment><AUTHOR> Coordination and collaboration are our main problem. recently we can't manage our tasks and we can't collaborate with each other so we have latency in delivering our projects.

<comment><USER3> Assuming that the system is resource constrained, that is simply the mathematical nature of scheduling. Where there is statistical variation in the arrival and duration and priority of the work, optimal job scheduling is NP- Hard. [1]

With just a few actors and jobs, brute force can find efficient solutions. Just to throw numbers around using staff as a standin for a more complex model of the work:

\+ The search space for 4! has 24 permutations.

\+ The search space for 16! has 2.092279e+13 permutations.

Suggests that maintaining efficiency as the company grows will be hard. Profitability is probably a better metric and finding better clients/jobs by adjusting the sales funnel may be easier than engineering organizational efficiency because sales and pricing can scale linearly using well documented practices while engineering an organization requires dealing with the vast variability among individuals and the day to day variability of their interactions (i.e. the client who is having a bad day because their child is struggling in school).

Good luck.

[1]</comment></comment></comment>


Cmd - A saner way to running external programs from C# - <AUTHOR> https://github.com/manojlds/cmd

<comment><USER3> This won't work for one very simple reason: Windows apps, unlike their *nix counterparts, do not have a unified command line switch format. This will only really be useful for standard getopt(long) implementations, which is a very small portion of the software available on Windows.

<comment><AUTHOR> Very valid point. I am working on the powershell equivalent for this, and I would be happy to support only powershell commands and standard getopt commands.

</comment></comment><comment><USER4> This is a neat use of dynamic/reflection. But why is it "saner"? What's wrong with wrapping the normal process I/O stuff and just doing: cmd("git clone") ?

This is the same question I have when I see dynamic typing used to access data sources. Like reading a CSV file and doing 'row.Field1' instead of 'row["Field1"]'.

Is there really any benefit or point, other than being a cute hack?

<comment><AUTHOR> Yes, it started out as a hack. I wanted to see how close I can get to the Python implementation. I am not envisioning it to be used, but would be happy if someone found it useful :)

</comment></comment><comment><USER5> Nice idea. A few problems spring to mind:

* Doing the following will hang if the stdout buffer fills up:

        var output = process.StandardOutput.ReadToEnd();
        process.WaitForExit();

Take a look at Kudu (Azure's Git publishing platform) for the way they do it: [https://github.com/projectkudu/kudu/blob/master/Kudu.Core/In...](https://github.com/projectkudu/kudu/blob/master/Kudu.Core/Infrastructure/Executable.cs)

* You need to expose a way to capture `StandardError`.

<comment><USER6> It won't hang as long as you're redirecting only standard output. If you want to read both StandardOutput and StandardError, you need to do it from separate threads: either with explicit BeginInvoke/EndInvoke calls as in Kudu, or more simply, by listening on the OutputDataReceived/ErrorDataReceived events then calling BeginOutputReadLine/BeginErrorReadLine.

(The reason for this is that the two streams are redirected to separate pipes, each of which has its own fixed-size buffer. If you forget to read from one pipe while you read from the other, its buffer fills up, and the writer - <USER2> program being executed - blocks. With standard error redirection turned off, the program writes directly to the console, which is safe.)

</comment></comment><comment><USER7> This looks quite awesome overall. I do wonder, though, why you can't do the actual invokation in Cmd.TryInvokeMember rather than Cmd.TryInvoke? That'll get rid of the () at the end of commands, from my quick read.

<comment><AUTHOR> I was thinking the same. I wanted to support cmd.git(git_dir : blah).branch(a: true) kind of scenarios however. Think I would just not go with it if it means removing the extra (). Thanks

<comment><USER7> Yeah, I think skipping the extra () is worth giving that up. Plus, you could do this in most cases: cmd.git.branch(a: true, git_dir: blah)

<comment><AUTHOR> The ugly () are now gone. :)</comment></comment></comment></comment>


iphone apps:  better to provide a lite version or make full version free for a while? - <AUTHOR>

Any stats on this? <comment><USER2> My opinion: if you want to have a free version, you should charge .99 cents for it and reinvest all the proceeds into some kind of smart advertising. This way, you have the satisfaction of knowing you created something another person found valuable, can figure out what paying customers want (you know, the ones you want in the end) versus the kind of feedback free customers might give, and get to learn how visitors to your web site react to various types of advertising.

<comment><USER3> I do not remember which podcast it was on mobileorchard, but they discussed how in their free app many people complained because it was not "feature rich" enough. It seems these people wanted a free app, and that they were not willing to ever buy the real app. None of their comments helped improve the application and did not seem to lead to conversion. There is not much a free app can do that a video on review websites would not do if someone was serious about buying the app.

</comment></comment><comment><USER4> Free lite version wins.</comment>


The Switch From iPhone To Android, And Why Your First Impression Is Wrong  - <AUTHOR> http://www.techcrunch.com/2010/01/09/android-iphone-switch/ <comment><USER2> I've never had an iPhone and recently bought an Eris. This article helps to explain what happened when I showed it to a co-worker who is a long-time iPhone user: he kept fumbling around, and I kept saying "Hit the home icon" or "Hit the back icon."

I couldn't understand why he didn't pick up on this quicker, and he probably thought the phone had a terrible UI. Since every review of every Android phone revolves around the "How does it compare to the iPhone?" question, this article should be required reading for reviewers _before_ they get a Droid phone to play with.</comment>


Mandelbulb: The Unravelling of the Real 3D Mandelbrot Fractal - <AUTHOR> http://www.skytopia.com/project/fractal/mandelbulb.html <comment><USER2> Awesome! I knew something like this had to exist, but never acquired the math skills or the time to dig seriously for it, though I did have a lot of fun render quaternions along the way. I wonder if the techniques used for this could help us in reverse-engineering of DNA (stay with me here...).

Some years ago I came across the _Romanesco Broccoli_ , sometimes referred to as a _broccoflower_ \- the first time I saw I got badly startled, thinking I was experiencing some sort of LSD flashback. But it's real, quite edible (and tasty), and Mrs Browl has since grown several of them in the garden. Check it out here: <http://en.wikipedia.org/wiki/Romanesco_broccoli> and <http://www.fourmilab.ch/images/Romanesco/>

There are many other instances of logarithmic spirals in nature, but few so striking as this one, given its compound structure. Irritatingly, I've had little luck finding any serious analysis of this structure - it turns up on quite a few pages, but mostly with a comment of 'yup, that's fractal all right' or mention of it as a teaching aid for introducing mathematical concepts. The only papers mentioning its genome seem concerned with agricultural considerations like yield and disease resistance. I can't understand why it's not the subject of feverish interdisciplinary study, since it practically screams 'analyze me'. Any thoughts from mathematically-inclined HNers?

<comment><USER3> I think the usual idea is that during development, cell division patterns in the plant apical meristem [1] implement some Lindenmayer system [2]. I don't know if anyone has looked into genetic & molecular mechanisms whereby cell division could be regulated so as to implement an L-system in this way.

[1] <http://en.wikipedia.org/wiki/Meristem>

[2] <http://en.wikipedia.org/wiki/L-system>

\-----

edit: lots of stuff here: <http://algorithmicbotany.org/papers/>

<comment><USER2> Ooh, very interesting - thanks!

</comment></comment></comment><comment><USER4> I showed my two-year old daughter the Mandelbrot set, then this pic: <http://en.wikipedia.org/wiki/File:Mandelbrot_zoom.gif>

She said, "Is that all Mandelbrot's friends?"

</comment><comment><USER5> Here's the 7500x7500 image of it in Seadragon: <http://seadragon.com/view/fnr>

</comment><comment><USER6> Thank you hassy, that really made my day!

Wonderful how mathematics can turn up such incredibly complex stuff from such simple numbers.

be sure you don't miss page 2!

<comment><USER3> page 2: <http://www.skytopia.com/project/fractal/2mandelbulb.html>

good link from page 2: <http://www.bugman123.com/Hypercomplex/index.html>

</comment></comment><comment><USER7> This could lead to some _serious_ procrastination.

<comment><USER6> Let me help you there, how about some CUDA implementation of a real time viewer :) ?

<comment><USER8> I've been working (slowly) on a real-time viewer for a 2D and maybe eventually 3D Lyapunov fractal[0] viewer, and I think implementing the algorithms as a shader program is more practical than using CUDA. After all, CUDA is meant to get around the limitations of using graphics hardware for non-graphics applications, which isn't necessary when you _are_ doing a graphics application.

[0] <http://en.wikipedia.org/wiki/Lyapunov_fractal>

<comment><USER9> Could that same logic of using shaders also apply to flames?

<comment><USER8> I suppose so, yes. It's been possible to do a "reasonable" flame effect since the nvidia 5900 at least [0], and there's been a lot of work on fluid dynamics (including fire [1]) since then.

[0] <http://http.developer.nvidia.com/GPUGems/gpugems_ch06.html>

[1] <http://www.youtube.com/watch?v=ZgoDypGMV50>

<comment><USER9> Oops, should have been more explicit. I meant fractal flames:

<http://en.wikipedia.org/wiki/Fractal_Flames>

Loved that video, though.

<comment><USER8> Oh yeah, I actually wondered about that after I posted :) I was on the fence about this, but all the examples I can find use CUDA, so I guess CUDA is the way to go: <http://www.google.com/search?q=flame+fractal+on+GPU> That makes sense, because it's more about huge matrices (flames are just big histograms) and less about textures on polygons.

<comment><USER9> Yes, there are CUDA implementations such as flam4, but I'm always interested in new possible approaches to the problem, since I'm writing a flame editor and CUDA doesn't play all that nicely with it.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I've slowly been building a Javascript 2D canvas library that renders lots of well known fractals. This just demolished my motivation: 3D is just too damn sexy.

<comment><USER11> Good luck with that JS canvas raytracer that handles surface gradients from iterating arbitrary functions.

<comment><USER10> The JS library was 2D only. I have no intention of writing a ray-tracer in JS. This project erased the motivations on my original project; it didn't persuade me to play with 3D. I'll leave that to someone whose itch needs more scratching than mine.

<comment><USER12> I don't see why this should daunt your 2D efforts - it still sounds like something fun to play around with;)

<comment><USER13> Indeed -- the whole point of projects like that is they make you a better programmer. The program itself is just a nice side effect.

</comment></comment></comment></comment></comment><comment> bjelkeman-again New Scientist has this recent article on how weather patterns may actually best be modelled with 3D fractals. And when you look at some of the pictures on Skytopia you can see where that comes from, some of the really look like cumulonimbus clouds.

[http://www.newscientist.com/article/mg20427335.600-tomorrows...](http://www.newscientist.com/article/mg20427335.600-tomorrows- weather-cloudy-with-a-chance-of-fractals.html)

</comment><comment><USER14> Thank you for sharing this. Absolutely wonderful.

</comment><comment> b-man The little beast looks like a virus. Hmmmm...</comment>


Open Secret About Google's Surveillance Case No Longer Secret  - <AUTHOR> http://blogs.wsj.com/digits/2013/08/26/open-secret-about-googles-surveillance-case-no-longer-secret/

<comment><USER2> On page 8: "On June 6, 2013, the public's already healthy interest in Google's receipt of, and response to, national security legal process skyrocketed."

It appears to me that that this could be a misunderstanding by the journalist. The entire rest of that paragraph is redacted. To my reading, it appears that this could just as easily be a case of "We want to bring to the court's attention the public's desire to have more information about these NSLs, including Google's denial of the scope of NSLs received in reaction to the Guardian article published on June 6th"

So that this would the attorney's way of showing the court that it's not just the redacted company that is affected, but also very public companies like Google.</comment>


Why C++ Is Not "Back" - <AUTHOR> http://simpleprogrammer.com/2012/12/01/why-c-is-not-back/ <comment><USER4> Portability _is_ still a good reason to use C++. If you want to be portable between Android and iOS, for example. C# on either platform requires you to ship an extra 10Mb of libraries, and (especially on older phones) adding C# overhead on top of everything else just doesn't make sense.

I write games, mostly, so performance does matter to me, though I'm not trying to squeeze "every last bit of performance" out of a chip. I just want some parts of the code to be entirely predictable in performance. So C++ and OpenGL are still my tools of choice. Been using C++ for years and would ace that set of interview questions (except possibly the list of algorithms in <algorithms>). And yet...I actually hate C++. It just happens to do the job better than anything else.

And it also happens to interface really well to a REALLY good scripting language, Lua.

To some degree I wonder why everyone focuses so much on Java or C#, when the amount of overhead code you have to write is similar in both cases to C++. Yes the languages are easier to understand, which is good, and they're often wrapped in IDEs that make it easy enough a monkey can produce code that will compile, but it still requires a lot of boilerplate to do just about anything. More than C++ in some cases, though not always. So much that they make the IDEs write a lot of boilerplate for you -- but the overhead is not only in typing out the lines, but in screens and screens of code that distract you from the actual problem you're trying to solve, and that you have to sift through to find the code with the bug you're looking for.

So I stick with C++ for things that need speed, and I use Lua for things that don't -- and I promise you that I can write just about anything in fewer (legible) lines of code in Lua than it would take to do the equivalent in C# or Java. And since # of bugs is proportional to the number of lines of code, I end up way ahead.

<comment><USER5> > Portability is still a good reason to use C++.

Quite true, thankfully WP8 supports native now. If portability is not a big deal, I prefer C# and DirectX (via sharpDX). It's much less code than C++, and just not as insane.

> And since # of bugs is proportional to the number of lines of code, I end up > way ahead.

Can't tell if you are being serious here. That's just not true at all; it's well known that LOC is a poor indicator of bug occurrence.

<comment><USER6> That's interesting, I've read several papers on a direct positive correlation of LOC to # of bugs. Do you have any papers to back up that assertion that there is no correlation. Common sense would dictate that the more places humans can insert an error, the more errors will be inserted.

<comment><USER7> The papers I've seen show that bugs _per line of code_ go down as class size increases, until about 200 lines of code. But since the code is larger, the total number of bugs goes up in larger classes compared to smaller ones (as you would expect). This might be used as an argument against refactoring code into too-small classes, but I'm pretty sure total code length correlates with total bugs. <http://news.ycombinator.com/item?id=3037293>

Edited to remove dumb generality.

<comment><USER5> > I'm pretty sure the only way to minimize bugs is to write less code.

Please think about what you are saying. Such an overly broad statement is so easy to shoot down, I'm sure there are plenty of other ways of minimizing bugs. NASA and Boeing have this figured out, for example, although it is incredibly expensive (formal verification, independent redundancy, extensive testing, static analysis, etc...).

</comment></comment></comment></comment></comment><comment><USER8> Excellent write up.

I am a good C++ developer but my dislike for the language has grown ever since c++11. Many parts of the language are arcane and unfortunately these parts are used over and over again by many programmers either to show of their 'coolness' or because it's the only possible way.

Here try this for size: [https://github.com/boost- lib/bind/blob/master/include/boost/...](https://github.com/boost- lib/bind/blob/master/include/boost/bind/bind.hpp) (sorry if that blurb made you blind)

I also dislike perl. A large amount of perl code contains shorcuts - like $^p or %#p (not real perl patterns but I hope you get the point). These patterns are ungooglable and hard to remember. The only people who know them are those who have spent a lot amount of time with the language.

The result is code that is extremely hard to understand and read.

Languages must be optimized for reading and not writing. Of course, nobody is asking one to go overboard (like COBOL) but reading a computer program should not hurt the brain and should not require years of training.

This is why I will not advocate C++. I would advocate C, Python or JavaScript (yeah javascript, it has it's pitfalls but it's very easy to master). There are possibly other languages like Ruby but I haven't taken the time to learn them.

(BTW, If you want to see how C++ could be done right, look at something Qt from an API point of view).

<comment><USER9> Yes, some of C++ is indeed arcane. But what sets C++ apart from other mainstream languages like Java is that you can optimize for reading to a much greater extent than with other mainstream languages like Java or JavaScript. You can create entire DSLs all within the language. I'm not saying this is always a good idea, but if you want to radically pioritize readability, C++ is a better language than most.

Some of the boost libraries actually demonstrate this very well. If you look at the implementation of the library, you may be intimidated by its complexity (as you have shown with bind), but if you look at examples of its usage, you will often find it a lot cleaner than other languages.

Imagine what you would have to do in Java in order to do what bind does:

      int diff(int a, int b) { return a - b; }
      auto reverse_diff = bind(diff, _2, _1);

      assert(diff(5, 2) == 3);
      assert(reverse_diff(5, 2) == -3);

(Obviously, this particular example is trivial in any dynamic language, but that's a different debate)

I'm not saying C++ is the only or even the best language for creating statically typed DSLs. But it is a language in which you can optimize for readability in a much more radical fashion than in some other mainstream languages.

<comment><USER10> And now consider the confusion of your users when diff is picked up by ADL, but reverse_diff isn't.

A lot of the code that tries to showcase new C++ features often falls short on some of the intricacies of the language or doesn't embed it into a larger scheme of a library. If my library offers customization via ADL across the board that kind of coding goes right out the window.

I'm aware of the proposals to make function objects through ADL, but this is but one example where the complexity of C++ comes to the surface.

<comment><USER9> C++ is undoubtedly complex. I'm not a huge fan of advanced template programming either. But specifically about the ADL problem, I think that bind is used primarily at a call site to create a predicate. Something that can now be done with lambda expressions.

That said, I don't like the fact that each and every feature of C++ comes with a really long list of weird special cases that are impossible to keep in your head.

</comment></comment></comment></comment><comment><USER11> I think the article stays away from a criticism of C++ as a language (being politically correct, perhaps?). Despite knowing most of the answers to the interview questions in the article, I think I wouldn't call myself an expert C++ programmer. The spec is extremely large and daunting. C++ is today the biggest "design by committee" language.

C on the other hand comfortably fits in my head. It might be possible to declare several complicated declarations (especially with pointers) but the language is still largely readable. I would argue that many of the extensions that C++ provides over C feels bolted on (as it was originally) and still not organically part of the language.

The addition of classes and objects in C++ was seen as the most significant addition to C. But over time, I have learnt that sophisticated static type systems like that of ML or Haskell are much more useful and expressive.

At the end of the day we don't need a C on steroids with every feature on the wishlist and a 2000 page reference manual. We need an easy to use expressive systems language. I would rather call it "C with some chosen features" rather than "subset of C++".

<comment><USER12> Go appears to be aiming straight for that spot.

<comment><USER13> And I hope it makes it. Whenever I write C++ I spend far too much time thinking about the language and not enough thinking about the problem I'm trying to solve.

</comment></comment></comment><comment><USER14> _> It seems that many of the seasoned developers have forgotten why we stopped using C++ and moved on to Java, C# and other modern languages._

Did they? Somehow I didn't notice everyone moving to other languages :) C++ has its obvious strengths and is a widely used language. So it doesn't need to come back - it's already here.

 _> C++ is the wrong direction for the future_

I could accept this argument only if author would focus on fundamental features that C++ doesn't readily provide - inherent concurrency safety for example and so on. So languages like Rust can be considered a better direction for the future which lies in massively multicore architectures. But C#? No, it's not a direction for the future in comparison to C++.

<comment><USER15> I stopped reading about the time the author implicitly compared C++ to Java and C#. Sure, these things all share a similar syntax, but one of these things is not like the others.

<comment><USER14> Yes, if something can be considered a competing successor of C++ it has to be from the same compiled family of languages at least.

<comment><USER16> Java was intended as a successor to C++ for the web [1] and I'd say it was quite successful in that regard.

[1]: <http://www.oracle.com/technetwork/java/intro-141325.html#334>

<comment><USER14> That's very questionable. "For the Web" argument falls apart if you consider that Java applets are complete failure. The Web is ruled by JavaScript without any doubt (and if something, ActionScript/Flash programs on the Web are much more common than Java ones).

And while as general purpose language Java is used quite a lot, it can't replace C++ for applications which require best performance. So Java really fills its own niche, and I wouldn't consider it as a full blown successor of C++, even if it was intended to be such.

</comment></comment></comment></comment></comment><comment><USER17> Oh _God_ I know the answers to all those interview questions and I remember _using_ all those features and it seems like an unimaginable Cthulhoid horror now.

<comment><USER18> Same here. After I finished reading the article, I felt the need to program something in Haskell, just to get rid of the smell.

<comment><USER19> It seems like this is the thread where you report 100% success in the questionnaire, so here I am. Actually, I code in C++, ObjC, JS/HTML5 and Python almost on a daily basis. I don't think I could have picked up all the others so quickly if I didn't have a strong C/C++ foundation.

It really helps to know what goes on under the hood. For that, I'd say C++ has strong didactic value.

<comment><USER20> You say, _I don't think I could have picked up all the others so quickly if I didn't have a strong C/C++ foundation._ , but I ask you this: was it the C or the C++ foundation that helped you learn the others? I can see how knowing C could ease the transition to learning JS and ObjC since those both -- superficially at least -- have syntactic similarities to C. But how did knowing C++ help you with those languages, especially Python and HTML? Was it mere familiarity with programming in general that helped or was it something specific to C++?

</comment></comment></comment></comment><comment><USER21> The "C++ too complex" story would be very funny if it was not so sad. It originates from the fake "interview" Bjarne allegedly gave to the "Computer" magazine, here is an example of it (<http://harmful.cat-v.org/software/c++/I_did_it_for_you_all> or just google for "sroustrup x-window interview" there are many similar texts) where Bjarne allegedly says that the goal of C++ was to be so complex that nobody could learn it. It was a cute joke but, naturally, people who had problem getting the joke also had problem learning anything more complex than Java (or Basic, which was more actual at the time). They honestly believed that they cannot code not because of their learning disability but the conspiracy to make the unlearnable language. Over time, the original context has been lost and the joke became the "common knowledge", everyone knew C++ is just too damn complex so it's futile even to try to learn, even its creator does not know it etc etc.

The actual C++, while, indeed more complex than Java, is nowhere close to the rumored complexity. Say, compared to Common Lisp with 40+ special forms and things like "loop" and CLOS, it's just too easy (not that I mean CL is "unlearnable" it's just more complex than C++). Somebody with a STEM degree could learn C++ better than many self-proclaimed "C++ masters" if just read a book and then looked over the standard. But very few people do that, the myth is just too strong.

It's sad because nowadays it gets to the ridiculous point when people will imagine something about the language rules (something very far from the reality) and will refuse to write few lines of code to see the stuff just does not work how they imagined.

The only thing worse than ignorance is false knowledge.

<comment><USER22> there are 25 special operators in common lisp, not 40+.

<comment><USER21> Sorry, my mistake.

</comment></comment></comment><comment><USER23> The problem with C++ is that you either want to write low-level code, in which case you ultimately end up using C, or you don't care about low-level stuff, in which case higher-level languages (python, ruby, java) are much simpler, make it harder to shoot yourself in the leg etc.

<comment><USER24> Low level is different from high performance. C++ is much higher level than C yet still retains its performance.

<comment><USER25> It isn't much higher level, it is just more feature rich. You can still, with minimial tweaking, take any C program and compile it as C++. You just get more of the kitchen sink with C++, and what the article _doesn't_ mention is how a subset of that sink makes code simpler, more maintainable, and more logical.

Just by having templates and classes doesn't make it higher level. It just means it has more feature parity. More higher level is when you can say "aspect X of the execution environment is _barred_ from the language for the sake of abstraction, such as Java's garbage collection or Python's list comprehensions or dynamic types." You _can't_ chose an alternative, so the level is raised on those issues since the language deals with them for you.

<comment> shawn-butler I think what you are both trying to say is that C++ was designed to ensure you "only pay for what you use"? Remarkably successful at that, really.

Kinda falls apart in some cases. For example the standard says with respect to inline functions that:

An inline function with external linkage shall have the same address in all translation units.

So I guess for the purpose of not having to worry about comparing the values of a function pointer to an inline function or worry about assignment semantics? Actually I have never really understood the point of this part of the spec.

Anyway, the cost of this is not negligible, since the linker has to maintain state for those cases where inline replacement is not an option[0]. As a result, even if you don't use this feature of the language, you pay for it with increased link time and object file sizes. But this is a pretty arcane corner case to pick on.

[0]: <http://gcc.gnu.org/onlinedocs/gcc/Vague-Linkage.html>

<comment><USER25> There are dozens of them though, like name mangling bloating code size even if you forego namespaces. Not saying the compiler doesn't have some inherent inefficiencies, but it still is operating at the same level as C.

</comment></comment></comment></comment></comment><comment><USER26> C++ didn't go anywhere to come back. You are probably surrounded by different people now that don't use C++, and hang out on different sites online.

It feels you are trying to find a language that will fit all problems. What happened to using the right tool for the job? C++ is one of the best language choice for a large amount of problems.

</comment><comment><USER27> I agree that C++ is complicated, and the future direction is not c++. but isn't c# supposed to be dead soon? and even MSFT is well prepared to discard it anytime. C is much simpler than C++. whereever c++ is needed, c is a much better option.

<comment><USER28> "The rumors of my death have been greatly exaggerated" - C#, 2012.

</comment></comment><comment><USER29> I think part of the new-found interest in C++ is because of mobile and the need for performance. Ten years ago, we would write something in Perl, Python or Ruby and say, "If it runs slow, buy a new computer." Those days are over. Mobile has re-focused everyone. Code performance matters again and C++ is King of performance.

<comment><USER30> Also the increasing popularity of computer vision on those mobile platforms. You can't realistically do 'serious' CV in anything but C or C++. Maybe in Python, since it has NumPy and bindings to OpenCV and Leptonica. Though I've found it difficult to avoid running out of memory.

<comment><USER5> C# is ok for CV also, especially if you are just writing some glue code to interface with the GPU (which is probably C++ like CUDA code).

</comment></comment></comment><comment><USER31> Eke, not ink.

"Eke out every bit of performance"

<comment><USER32> I also saw that, cringed, and then idly pondered for a bit on whether is more or less awful than the common "eek out every bit..."

</comment></comment><comment><USER33> I feel like every language has a certain domain in which it excels, and every language has it's detractors.

If there was one language to rule them all, then that's what we'd all be using.

<comment><USER34> > If there was one language to rule them all, then that's what we'd all be > using.

That's very charitable to programmers. I don't think it's fair to assume that most--or even many--people choose their language on entirely rational grounds or the quality of each language.

If you just followed popularity, you'd probably end up using Java, and nobody wants to go there.

<comment><USER35> That's pretty uncharitable to say about Java. If it was a bad language it wouldn't be so widely adopted. And you can make excellent software with it - it just depends who's writing the code.

</comment></comment></comment><comment><USER36> "I used to code in C++ until I took an arrow to the knee"

C + any scripting/dynamic/embedded language is probably a better choice for future development than C++.

I friend of mine published long time ago in Gamasutra (or was it Gamedev) a material on.... ahem scripting with C++ - I've talked to him that this is utter non-sense - scripting is possible in C++, but with thnings like UnderC++, Ch (only C), Cern's CINT, etc. His material was on implementing a script-like system using C++ directly.

Then comes boost (he's a big fan of it) - Just a month ago we decided not to use thrift, but google protobuf simply because it wanted boost. We didn't want to litter our perforce with tons of files, much bigger increased linking times, and harder setup. Unfortunately lots of graphics/game /animation oriented houses/studios use it, so there must be something to it. For me plain old STL is good, but the best so far has been write C or C++, but do all your interface in C, only exception being certain hard to make nowadays interfaces like GUI for example (GTK is example where this is gone wrong too, but with C - the API is just too big, and lots of macroses).

</comment><comment><USER37> most popular languages through the decades:

      Python
      Java
      C
      Fortran

platform languages:

      the web browser† = Javascript††

      apple = Objective C

      microsoft = C#

      google = Go

      unix = C

† the web browser is most importantly platform agnostic

†† Javascript and Java are two different languages. Java is more like C.

Java was once the platform language of now defunct sun.

I consider the language of the linux kernel to be C and i386 assembler. Linux itself is too much of a bazaar to have a "platform" language.

and a table:

      lambda calculus | machine memory |
      </comment><comment></comment><comment>----+</comment><comment></comment><comment>----+</comment><comment></comment><comment></comment><comment>--
              Haskell | C              | language as given
      </comment><comment></comment><comment>----+</comment><comment></comment><comment>----+</comment><comment></comment><comment></comment><comment>--
          Common Lisp | Forth          | language as medium

and others:

      Python vs. Ruby
      Assembler

      HTML
      CSS
      SQL
      PHP

      Perl
      Prolog
      Basic
      Erlang

and yet another...

</comment><comment><USER38> C++ is great, and it is a huge language to learn, and it does have lots of pitfalls, and its not easy.

But it'll always be useful in the stack, because like the quote goes its much harder to shoot yourself in the foot than C is, but with much bigger risks. It's easy to mitigate those risks and write clean code, but it basically comes down to only using some subset of the features, C++ sucks the most where it's in template hell.

It's easy to read all the bad about C++ and avoid it, but its something that's reasonably easy to pick up and try, and there's a lot of learnable experiences you can take with you.

</comment><comment><USER39> A lot of what he says is interesting, but I'm not sure if I agree with what he says on the educational benefit of C++. That's not to say that learning how to work at a low level isn't extremely valuable - it is, beyond description - <USER2> I honestly think C++ adds enough abstraction and cruft to actually get in the way of that goal. In my (totally unqualified) opinion, raw C is a much more effective way to get a feel for the innards of the machine, without having to deal with a lot of the overhead that comes from C++.

</comment><comment><USER40> Welll it seams this person is right to me, i did some c++ and c# and a dozen of other languages in the end its more often about development time that make up development costs.

And if your software is slow, blame it on a slow computer, these days there are fast computers much more faster then the old days when speed and short code where seen as an art. The slow computer is a customer cost upgrade, while taking extra weeks of coding is a softwarehouse cost upgrade.

</comment><comment><USER41> I'll keep using my C++ subset, the one that produces great assembly code and is portable to make the apps/libraries I need. The next big language is Javascript anyway.

<comment><USER42> There's no next big language :]

<comment><USER18> So true... but there is a next big paradigm; FP FTW! ;)

<comment><USER43> Isn't that what they say for 30 years by now? ;)

</comment></comment></comment></comment><comment><USER44> When you said simpler, I hoped you'd be advocating less abstraction. Anyway, opinions on C++ largely depend on what kind of software you're developing. If you're not writing high-performance apps, there are more productive than languanges than C++. Otherwise, less abstraction is absolutely neccessary especially for memory management. So C++11 has no choice but to remain as feature rich as it is. You should have to pick what features to work it.

<comment><USER45> The problem is that C wipes the floor with C++ in high-performance apps, while any scripting engine wipes the floor with C++ in terms of abstraction. C++ is simply losing the war to the combination of C with scripting.

<comment><USER4> C++ is identical in speed to C, if you know what you're doing, even if you're using "advanced" features. The only thing C exceeds C++ in is simplicity. Yes you CAN write slow code in C++, but if you need speed, it's there. In the parts of your code where speed isn't AS important, but you're not ready to drop to a scripting language, you can manipulate things with higher-level structures and smart pointers and such.

C++ plus scripting is the best way to go, IMO; you get object-oriented abstractions, better type safety at compile time, and yet you still get speed. Destructors alone make it worth using C++ over C, so you can ensure stack structures clean up on return from a function and can avoid using a "goto exit" model.

And if you need every last percent of speed, you can write that code in a "C" subset of C++. C is still completely there under the covers. Except you have to do more casting.

C is really not much better than a portable assembly language. And I should know, having written commercial games entirely in assembly language.

</comment></comment></comment><comment><USER46> NaCL on Android, P\Invoke on C#, and JNI on Java exist for a reason.

Sometimes the VM gets in the way, sometimes the library, or bit of hardware you need to use, only has a C or C++ interface library.

Learning C++ is still important, because, developers who don't understand how C++ works have little chance of knowing how to find an entry in a COM export table.

C++ isn't coming back, it never really went away.

</comment><comment><USER47> I'm new here, though I'm a long-time geezer at /. First post!

My style there was somewhere between civil and uncivil. This never harmed my karma. I was blunt and/or pointed in my mockery of reasonably smart people tossing off their pet clichés with their brain on dial-tone. I tried to toe the line on sharp yet not vindictive. Usually my posts digressed with a vengeance from an initial sharp retort to something original or constructive. Writing has always been a thing for me that releases frustration when technologies are _unnecessarily_ bloody-minded. I wasn't using /. to establish rapport. But recently the story summaries are achieving new heights of vagueness. I'm like the old dog who finally caught his tail, and noticed the smell.

I clearly recall when Paul Graham became a bit of a meme at /. circa 2004. I still remember the desk I was sitting at when I first read Paul Graham's comments on LISP. So here we go, wading into the C++ bash-fest for old times' sake. (Is it permissible to compose in full paragraphs around here? I guess I'll soon find out. The Y/Z/omega generation's allergy toward paragraphs made reddit a total non-starter.)

I've definitely let my C++ skills languish for the past few years. It's an awfully demanding language if it's not your bread and butter.

One way to characterize C++ is that it's an elegance inversion. Most languages are founded on the assumption that beauty is transitive. If you start with beauty at the bottom and stay true to your aesthetic all the way up, the beauty will bloom as a mature rose. The C++ design aesthetic is that the language designer should not be refactoring his language user's problem domain in order to shoehorn simplicity (and elegance and glory) into his solution domain. There were no end of frameworks back in the 1970s and early 1980s that promised vast productivity increases, and delivered these for the most part, until the dread day came "oh oh, we have a new requirement and this tool we've chosen just won't go there, and backing out now is too painful to even contemplate". (Think Rails, back when every country was laying down a different rail gauge.)

I find it amusing to read the experience of people deploying MongoDB. The thing is, regret has a different price than it used to. A few startups report rapid development on MongoDB for an initial year, then jumping to a different approach when some of Mongo's design eccentricities became problematic. Jumping is a lot less hard than it used to be. This might even have been a good overall development path. Few said that about a major misdirection in the 1980s.

The comment over at the TFA that caused me to sign up and post was a guy saying that every piece should occupy a limited depth of the abstraction stack. He took offense that the language should have high level abstractions and still be able to specify execution details at almost the machine level.

This was actually an almost explicit language design goal. This sentiment is reminiscent of the old "Worse is Better" debate. (Do I have HTML here? No info from the UI. Activate telepathy module: throw ("does not compute"). catch ("induction from sparse"): I guess I'll just post the author's name of the piece I'm referencing: Richard Gabriel.)

C++ doesn't believe that great programs are written on the principle of "no ugly". Ugly happens. This is a property of reality, is it not? Or am I way too old for my own good? The premise in C++ is that low level library implementers have the gory power (pages of closely debated language specification) to conceal some (or even most) of the ugliness they face. Library implementers working at the next level up similarly have the gory power to conceal some of the ugliness they inherit, and also some of the ugliness their own layer introduces. This continues until the final consumer ends up working at a fairly high (and reasonably clean) level of abstraction. The ugliness propagates, but doesn't explode. Incompetence explodes, however, so there is that.

Of course most casual users of C++ don't appreciate the substrata. They get buried in the arcane and baroque syntax required to make this magic work. (C++11 tries to redress this.) This is a whole different tranche of ugliness that stems from the original decision to keep the C language as a proper subset (plus a few design missteps along the way that are deeply regretted, but hard to reverse). Usually on the short list of toxic inheritance from C is the clever declaration syntax. This didn't generalize to OO without introducing some ugly ambiguities. Much baroqueness of the language still stems from this. It's an old language with history, much like Perl. Every new language arrives with a fresh face. A few get used enough to accumulate wrinkles. And we've even learned a few things over the years at how to avoid the worst wrinkles of all. It's nasty, but not ultimately toxic in its own right.

Not so often admitted by these fresh-faced languages is the relief and freedom that accrues to not having to profess to solve every possible problem. Why? Because either C or C++ can be hauled out with a fair certainty that there's no ugliness so great it can't be captured and expressed well enough.

My own opinion is that C++ has faded into its sunset years by finally buckling under its own weight. The baroqueness of the syntax is a finite burden, much like decoding the x86 instruction set as compared to RISC (the amount of circuitry needed to accomplish fit quite easily into a 386, yet we still complain about this overwhelming burden 15 die shrinks later). Nevertheless, it all adds up. I don't think the ROI of learning C++ in a deep way makes sense for younger developers. It's a complex world. There's too many other demands for that cognitive space.

That said, I know that if I run into a problem where turning my back on ugly is not a viable option, C++ is still there for me, with a proven ecology of ugliness containment. In C++, one can always push ugliness from the problem domain back into the solution space, at the expense of some source code eye bleed--supposing your developers are well enough versed to distinguish incompetent solutions elegantly expressed from competent solutions with an ugly expression. This is why I described C++ as an elegance inversion.

There are many languages more beautiful where that isn't true. Think of yourself as a plumber. There's a dirtiness to your world that's simply inescapable. This doesn't stop plumbers from implementing vacuum reflux hoses for optimal sewage containment. Then along comes Fritz Haber who declares sewage obsolete. Be thankful another language built those reflux hoses so your language doesn't have to.

[Shit, no preview! Edit boxes are pathetic for tweaking paragraph flow. Who ever looks at their prose any more as others will see it? WTF. Fire and forget. My first lesson here in the new culture.]

<comment><USER48> Yeah, thanks for that. I'm a little surprised you haven't had more of a response to your perspective on all this actually.

There's so many analogies that one could use that I dare not attempt one. Like if C is like metallurgy, the C++ is like alchemy. I should stop before it appears foolish.

I've moved from C and C++ in big systems feeding financial instruments at hundreds of thousands of items a second through rooms full of computers to PHP and Go and back to C for embedded, where I spend all my time at the moment. So I fit into one of this articles categories. I had a dirty little problem with multiple devices sharing a single bus, with all its chip select and clocking issues, and mutual exclusion with near zero wait states was the problem to be solved. C++ to the rescue. Not because it couldn't be done in C ( or assembler for that matter, an even more magic approach ), but because inheriting the bus made architectural sense.

It isn't hard to read, document or maintain, because the code structure maps well to the underlying fixed hardware. In this case, the language suits. And it all has to happen in less than 32K with all the rest of the code.

There's always a lot of discussion about this language versus that. Generally, I'll use whatever suits, and Javascript and PHP required no learning at all, and I already knew Java to a degree. They are C'ish enough to pick up without effort if one already knows C. Objective-C and Go and Java where the shoe fits, and from what others are saying, Rust is one I need to know.

Independently of Microsofts policy in Windows 8 with IDL and .NET changes, or tossing the idea around as to whether C or C++ should go in the Objective-C mix with XCode and Apple, the thing I can use C++ for is making the best solution possible for fundamental problems with machines, where implementing a concept over a base or virtual machine facility is efficient. In those cases, the argument against efficiency fails.

But it's really a specialisation given the volume of solutions that are needed in the current state of userland software. Horses for courses. There's a lot more volume now, and managed languages are a better fit in that environment. This is the house that Jack built. You don't need a hammer and nails. You want a paint brush.

</comment></comment><comment><USER49> "you have to understand exactly what is really going on" WOW, if you said this at my workplace you would be fired. Good programmers need to know everything that is going on.

</comment><comment><USER50> When you have written something in Java or C# that sells well, I'll rewrite the same app in C++. My selling point will be a side by side comparison in performance.

<comment><USER51> A few percent higher performance is not something that will buy you customers. Especially that after you finish your rewrite, the original will have more features, better stability (already used and proven in production) and... very likely better performance. The biggest impact on performance has architecture an quality of algorithms, not the low-level aspects.

People still like Java Minecraft better than thousands of its C++ clones.

</comment></comment><comment><USER52> Binary incompatibility is one of the my biggest issues with C++. Having to build every library (and its dependencies ) from source is such a pain.

</comment><comment><USER53> So, the argument is that C++ is too hard to learn for the average programmer, and that's why it's not "back"?

I don't get it, isn't that win-win is many situations. I'd rather have a solid developer who can master C++ or at least understand the concepts when explained to him/her, than someone who can't. Basides dealing with compiling/linking (but scons greatly simplifies this), I really don't feel like it limits me much compared to other languages like Python once you know a bit of STL.

<comment><USER54> No. There are increasingly lesser avenues where the raw power of C++ will make a difference. C++ need not be a main stream language when many simpler more elegant alternatives exist. Use it where it is abosultely necessary - <USER3> active memory management, access to hardware and performance are absolutely required.

<comment><USER42> Is C or haskell an elegant alternative?

<comment><USER55> Writing both performant and readable Haskell is difficult IMHO.

<comment><USER34> That's a complicated thing to say. Even unoptimized Haskell tends to be very good when compared with other high-level languages. (Space leaks are more of an issue, but they're not _that_ bad and are more than made up for by Haskell's other relative virtues.)

So for most of your code--the parts that aren't tight and performance critical --it's good enough as is and you can just stick to writing normal, concise and (at least in my experience) very readable Haskell.

However, there are always going to be the sections of code that you absolutely must optimize. And this is certainly not trivial. However, even this isn't too bad, for two reasons.

The first is that much of the difficultly comes with a lack of familiarity: you may know how to optimize C++ or C well, but that knowledge is not going to apply too much. Haskell is very strange, but some people clearly manage to make it perform well consistently, so it's probably a matter of experience. A new C++ programmer will find writing heavily optimized C++ code difficult as well.

The other reason it isn't as bad as it could be is that it's _possible_ at all. You simply can't write very performant Python, so you essentially _have_ to drop down to C. In Haskell, this is also always an option; however, even the hard-to-optimize Haskell is still usually friendlier and easier to work with than C!

In some cases, by using the right libraries and rewrite rules, you can actually maintain most of Haskell's elegance (like being able to express your program as composed maps and folds) while still getting good performance.

<comment><USER56> That is actually one of my concerns about Haskell. It's a bit off-topic to this HN post, but it's relevant to your comment and you seem to have some experience.

I find Haskell's syntax very elegant and concise, but I am scared about performances. Often, I read about three or four different ways to do one thing. If I were to pick Haskell as my go-to language, and let's say I wanted to build a performant (memory wise and speed wise) program, would I have a hard time?

Now obviously, for day to day applications, the performance topic is irrelevant, but how would Haskell compare for the example above instead of, let's say, Ocaml?

<comment><USER34> I think you would have a hard time, but not entirely because of the language's faults. Rather, the core issue is that most of the things you have to keep in mind to write fast Haskell (like dealing with laziness) are very different from what you would have to keep in mind with more common languages that you are already familiar with.

That said, as I noted, the performance is usually good enough even with naively written code; you would only have to spend time optimizing a few select parts of most programs.

Another little problem is that there are not many resources on how to optimize Haskell code. This is a little annoying if you're learning on your own; however, I think it's offset by the Haskell community. I've seen some of the best Haskell programmers give _very_ detailed responses on StackOverflow and the mailing list, so there is always somebody to help you while you're learning.

There are also some advantages to OCaml--it's a very fast language itself and it behaves in a way that's easier to predict especially since you can leverage more of your existing experience. OCaml is also a very nice languages; while I prefer Haskell, I would be perfectly happy with OCaml (and, in fact, I've only used OCaml and not Haskell in production).

I should add a big caveat to this whole post: while I've used both Haskell and OCaml a fair bit, I've avoided doing anything super performance sensitive. I usually care more about having correct, readable code quickly than I do about how fast it runs. So I am definitely no expert on optimizing either Haskell or OCaml!

<comment><USER56> Thank you for your answer.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER57> It seems that the Windows group at Microsoft has a lot of pull , doesn't like the managed stack, and that's why we're seeing a lot of "native is back" and C++ article on Microsoft-centered sites.

If that's the case, I wish Microsoft would bite the bullet and come up with a new native language. Microsoft programmers are for the most part happy C#/.NET and trying to pull them back to C++ is a losing proposition.

<comment><USER58> The funny thing is that there are native code compilers for C#, like bartok in Singularity and Windows Phone 8 deployment with MDIL.

Languages are not native or managed, implementations are.

The way .NET is currently deployed on Windows and whatever else might be happening, is a result of internal politcs at Microsoft.

If they wish to do so, they could go fully native with lets say .NET 5.</comment></comment>


Ask HN: What JavaScript framework will run on an embedded system like ESP8266? - <AUTHOR> For an upcoming project I need a lightweight JavaScript and UI framework to serve a simple dashboard via the ESP8266. <comment><USER2> You could try looking at Espruino, [http://www.espruino.com/](http://www.espruino.com/)

</comment><comment><USER3> What systems have you considered so far?</comment>


PastryKit - iPhone's UI JavaScript framework - <AUTHOR> http://davidbcalhoun.com/2009/pastrykit-digging-into-an-apple-pie

<comment><USER2> I did some reverse-engineering and built a Twitter trends reader on top of PastryKit a while back.

<http://michaelgrinich.com/pastrytweets>

Code: <http://github.com/grinich/PastryTweets>

</comment><comment><USER3> Hey...when I purchased my 1st generation iPhone the 2nd week it came out, I jailbroke it and had Apache + php installed on it. I was then writing & running scripts locally. After awhile I found a decent UI framework and was using it to handle all my scripts. It was pretty cool being able to bookmark the scripts on the home screen and making appear to be a regular installed app. Anyway, here's the link to the wiki of the framework, it would be neat if someone took this and ported it for the ipad..the code is pretty damn simple so it shouldn't be much work....

<http://code.google.com/p/iui/>

</comment><comment><USER4> I would be careful using PastryKit. I know after John's article when some people hosted un-minified versions on GitHub they were soon met with takedown notices from Apple. They may have decided they can't stop everyone un- minifying it but I can't see them letting anyone make any money off using it. Doesn't stop you learning from it though.

</comment><comment><USER5> I'm currently starting an iPad web app - does anyone have any advice or recommendations for using PastryKit (or another js & css framework) for building native-looking iPad apps?

I'm guessing PastryKit, JSTouch, etc could all be reformatted for iPad but wondering if anyone has already tried this?

<comment><USER6> Have you looked at Appcelerator Titanium? That will give you native iPad widgets.

I haven't used it yet but I've been planning to dig in.</comment></comment>


How to Be Secret - <AUTHOR> https://www.tbray.org/ongoing/When/201x/2014/11/14/Being-Secret

<comment><USER2> The comment pointing out that your phone is highly visible while you stroll to the coffee shop is important, as well. If your adversary is anything like "the Firm", never forget what a marvelous tracking device this is.</comment>


3D Hearts Graph in Google Search - <AUTHOR> https://cube3x.com/3d-hearts-graph-in-google-search/ <comment><USER2> Interesting, I would like to see a 3d map project of the hole human body, in this way you can learn without opening books and staff :)</comment>


NHSX Covid-19 App Has Google and Microsoft Tracking - <AUTHOR> https://twitter.com/aral/status/1258476212860715010 <comment><AUTHOR> Further context:

In the UK, NHSX (Technology division of the UK's NHS) rejected the Apple- Google contact tracing API to make their own COVID 19 tracing app using Bluetooth, and the source code for the apps are now open source [0] [1]

[0] [https://github.com/nhsx/COVID-19-app-iOS- BETA](https://github.com/nhsx/COVID-19-app-iOS-BETA)

[1] [https://github.com/nhsx/COVID-19-app-Android- BETA](https://github.com/nhsx/COVID-19-app-Android-BETA)</comment>


Samsung Galaxy Nexus (Prime) revealed: Slower than iPhone 4S, Galaxy S II - <AUTHOR> http://www.extremetech.com/computing/100457-samsung-galaxy-nexus-prime-revealed-slower-than-the-iphone-4s-galaxy-s-ii?obref=obinsite

<comment><AUTHOR> I realize what the author is saying about the GPU being slightly outdated but even at that isn't doubling the ram and having faster CPU's likely to make up for the difference in the GPU?

 __EDIT: Much better explanation found here:[http://www.extremetech.com/mobile/100553-why-the-galaxy- nexu...](http://www.extremetech.com/mobile/100553-why-the-galaxy-nexus-uses- omap-instead-of-exynos)</comment>


NSA collected US email records in bulk for more than two years under Obama - k-mcgrady http://www.guardian.co.uk/world/2013/jun/27/nsa-data-mining-authorised-obama <comment><AUTHOR> So at minimum, the NSA literally knows every single person or entity that I have exchanged emails with, when we exchanged emails, the size of the message, every single website I have ever had an account on, for much of my adult life. And that data is sitting in their archives, indefinitely.

Just let that sink in for a minute.

<comment><USER2> What I found interesting, was that this so called "contact chaining" (where they graph out who you talk to, and two degrees onward) was only approved after 9/11\. Amazing how far we've fallen.

 _The agency "analyzed networks with two degrees of separation (two hops) from the target", the report says. In other words, the NSA studied the online records of people who communicated with people who communicated with targeted individuals.

Contact chaining was considered off-limits inside the NSA before 9/11\. In the 1990s, according to the draft IG report, the idea was nixed when the Justice Department "told NSA that the proposal fell within one of the Fisa definitions of electronic surveillance and, therefore, was not permissible when applied to metadata associated with presumed US persons"._

<comment><USER3> Kevin Bacon had better get on a plane to Ecuador before he's arrested for treason.

</comment></comment></comment><comment><USER4> And according to the article they were emails of Americans with no connection to foreigners.

The claims of metadata being public and being exempted from Fourth Amendment does not resonate with me and even more so with emails. It seems by collecting IP addresses associated with emails, NSA has the ability to compare that with all the other data they may have collected and build a profile on you.

To me it seems to be a violation of the fourth amendment. I do not expect the government to be constantly searching everything about everyone without a probable cause.

</comment><comment><USER5> Every American has to ask themselves, "Is this worth it?" Are the plots stopped and the lives saved worth the loss of privacy, the loss of trust and good will internationally, and most frightening of all, the unprecedented power this gives the government?

I don't think anyone can reasonably say that it is.

<comment><USER6> It's not every American, it's every human being. This isn't just happening in US but most likely in every democratic country as well. We're not special or unique in this area, yes we should be leading the world in terms of how to protect our privacy but we haven't led in that area for decades. So I'm not surprised about this.

Now, as for the question. The problem is after 9/11, everything changed. People did task the government to prevent further 9/11 attacks and sadly, they can only do that by doing what they're doing now. IMO, 9/11 wasn't the point of what the terrorists were doing, but the aftermath of it.

I'm the man who believes that we don't deserve security if we use it to justify the loss of our rights. However, that belief is easily shaken when and if my family are harmed in an attack that could've been foiled, and my first reaction would be, why didn't the government stop it? So, you can see the problem right here.

 _Nothing_ is worth losing our rights over, we fought so many wars to protect it, suffered so many loss as the result of the wars, and yet, we're giving them up easily for terrorism.

<comment><USER7> > Now, as for the question. The problem is after 9/11, everything changed.

I'm not from the US, and this sort of statement really baffles me every time I hear it. There's nothing remarkable about the events really, probably more people get killed by fridges falling on them than by a terrorist attack, yet nobody seems to modify their lifestyle to avoid standing in front of them.

Can you explain to me what actually changed about the American lifestyle? I genuinely have no idea.

<comment><USER8> Don't be obtuse. Of course it's remarkable, the only other reason you ever hear of 3000+ people being killed in the space of a few hours is when there's some large natural disaster like an earthquake.

Now, if you can't work out how the largest terrorist attack in history might have change the stance of the world's largest military superpower, with a knock-on effect on everyone else, then you're not trying. When I saw the events of 9-11 happening on TV I immediately knew it was going to result in years of war, just like the collapse of the Soviet Union obviously led to a de-escalation of military posture.

 _probably more people get killed by fridges falling on them than by a terrorist attack_

Not at the same time, and crucially, not at someone else's pleasure. I'm not American either but the notion that people wouldn't or shouldn't react to something like this is just asinine. Frankly, I'm surprised it didn't lead to greater change in the US than it actually has.

<comment><USER9> Not wanting to sound like an ahole but...

[http://en.wikipedia.org/wiki/Atomic_bombings_of_Hiroshima_an...](http://en.wikipedia.org/wiki/Atomic_bombings_of_Hiroshima_and_Nagasaki)

As for the parent comment, I know it _changed_ everything. But beyond the initial years, how has it changed your life over, say the past 2 years. Is everything _back to normal_? How long do you continue changing your behaviour and living in fear? (I realise you're not American, just asking)

<comment><USER10> Your argument is that Hiroshima didn't change anything?

<comment><USER9> No, your first point. The US has been just as responsible mass death. And of course it changes a lot.

 _Don 't be obtuse. Of course it's remarkable, the only other reason you ever hear of 3000+ people being killed in the space of a few hours is when there's some large natural disaster like an earthquake._

</comment></comment></comment></comment></comment></comment></comment><comment><USER11> I find it amusing the the Guardian seems to position this article in such a way that it is meant to disparage the Obama administration. While the administration is far from above criticism, and a variety of other Guardian reveals do justifiably criticize the President, my personal takeaway from this is a sign that the administration did at least attempt to curb some Bush era privacy invasions—though perhaps to a pitiful extent. Funny how the article doesn't seem to put it that way.

<comment><USER12> The NSA collected US email records in bulk for more than two years and the FISA court renewed collection orders every 90 days.

So the Obama regime didn't curb anything until after the eight or ninth renewal of the program. Pitiful indeed.

<comment><USER11> Are you under the impression that you can review the entire federal government, decide which programs to get rid of, and shut down every one of those programs, during your first year on office?

Because if so, please, run, I'd like to see it happen.

By pitiful, I meant that this shutdown seems minuscule among the variety of other privacy violations—but that hardly justifies the Guardian using this specific reveal as an attack piece.

<comment><USER12> > Are you under the impression that you can review the entire federal > government, decide which programs to get rid of, and shut down every one of > those programs, during your first year on office?

No, I'm not. But I do believe that we were all given the impression that ending unconstitutional wiretaps was going to be near the top of Obama's to-do list.

<comment><USER11> I agree. That's a problem for which he deserves more than a little criticism. But that's not what I was discussing, at all.

</comment></comment></comment></comment></comment><comment><USER13> So Edward Snowden wasn't bluffing when he said there was more... I'm thinking the government is going to try to step up the efforts to bring him (and this will need to include Greenwald) in to stop it all. This is better than tv!

<comment><USER14> Snowden isn't mentioned once in this article.

<comment><USER15> Good. The focus should be on the revelations.

</comment></comment></comment><comment><USER15> How do we know that there isn't another super secretive program, right now, that is still collecting everything?

How can we trust the Government, ever in the future, to tell the truth?

I don't see how this can actually be solved, since most people aren't concerned about encrypting their communications. I can't use encryption to message other people unless they use encryption too.

This is the future. We will be constantly watched.

Please tell me I'm wrong.

<comment><USER16> > I don't see how this can actually be solved, since most people aren't > concerned about encrypting their communications.

They shouldn't need to be. Encryption is cheap, it should happen automatically behind users backs by default.

> I can't use encryption to message other people unless they use encryption > too.

Build the next WhatsApp/Facebook/GMail and integrate encryption to it.

</comment></comment><comment><USER17>
        we provide user data to governments only in accordance
        with the law. Our legal team reviews each and every
        request, and frequently pushes back when requests are
        overly broad or don't follow the correct process. Press
        reports that suggest that Google is providing open-ended
        access to our users' data are false, period.
        -- Larry Page

So, clearly we have a request that is within the law as far the courts are concerned. Did Google push back on this too? Did they succeed? Did the order just not apply to them somehow?

<comment><AUTHOR> Although Google's statements are of minimal value to me, my belief is that Google would not have to be complicit in this particular program. This was likely pulling from fiber taps at ISP backbones.

<comment><USER18> But: such a tap would reveal no information about gmail-to-gmail communication, no? Most gmail usage is via their SSL web app or an email client, and their directions for most (all?) clients specify to use SSL. And in my experience, most people using gmail send most of their emails to other gmail accounts.

</comment></comment></comment><comment><USER19> This program has apparently ended. That probably means a more powerful system is operating currently.

</comment><comment><USER20> Why is the subject of this article Obama? It was a Bush era program that he shut down. But since he didn't do it the day he took office, I guess he is literally Bush Jr. Jr. Great reporting by The Guardian.

<comment><USER21> > But since he didn't do it the day he took office

Well... why didn't he?

<comment><USER22> Perhaps because he isn't omniscient and wasn't aware that it existed?

</comment></comment></comment><comment><USER23> I really wish the Guardian would get someone very technical to talk to these sources and then write a technical report of exactly what's happening. These dumbed down articles make it hard for me to understand what is happening.

The specific question I had is how they jump from email meta-data to IP Logs. If they were collecting all of my IP traffic, that would be a lot bigger deal than email headers. The title and most of the content seem to imply it's only email metadata, so I don't know how to interpret the alarming quotes about having a copy of my brain.

</comment><comment><USER24> And how, with money polluting politics so badly, do you fight this type of situation? A public scandal. And how do you get a scandal? Wait for the inevitable government overreach and someone to leak it, the bigger the better. There are to many people for it not to leak out, no matter how much you try to squash them.

The current situation has been a foregone conclusion for the last decade. This is how the government has worked for years. I'm surprised so many people act shocked by both the government's actions and the leaks.

</comment><comment><USER25> I created a petition with a concept that I think would be a pretty helpful proactive step to start addressing these problems:

[https://petitions.whitehouse.gov/petition/enable-american- so...](https://petitions.whitehouse.gov/petition/enable-american-software- engineers-monitor-nsa-regularly-publishing-general-statistics-its/x6jDvjxk)

Let me know what you think!

</comment><comment><USER26> _" Seeing your IP logs – and especially feeding them through sophisticated analytic tools – is a way of getting inside your head that's in many ways on par with reading your diary," Sanchez added._

It's great to see this information going public, however hyperbolic statements like the above are completely unnecessary and really take away from the rest of the article.

<comment><USER27> In my opinion, though, that statement is not hyperbolic and is very, very true - no matter how scary that may seem.</comment></comment>


The circular economy - <AUTHOR> http://www.nature.com/news/the-circular-economy-1.19594 <comment><USER2> wholesale open sourcing of code from companies going out of business may be one such example of a circular tech economy

</comment><comment><USER3> I know that backplanes (like the old S100 from the 1980s) hit certain performance walls, but they are more adaptable than motherboards. You could swap out any component _including_ the CPU and even the various interfaces. It's nice that single board computers like the Raspberry Pi use so little power, but they are still monolithic and impossible to upgrade.

I wish somebody would make a newer, faster backplane-like form-factor for small computers. The RPi Compute Module is an interesting step in that direction, though it would be better if the RAM was on a separate card.</comment>


Get career security by being "bad and nationwide" - <AUTHOR> http://gilesbowkett.blogspot.com/2007/10/im-bad-im-nationwide-job-security-vs.html

<comment><USER2> Entertaining post esp. for those stuck on the corporate track. The guy pissed off DHH and lived to tell about it!</comment>


I Wrote Down Everything I Learned While Programming for a Month - <AUTHOR> https://dnote.io/blog/writing-everything-i-learn-coding-for-a-month/ <comment><USER2> Here's a poor man's version of dnote in my .bashrc. It's the only thing I've used consistently:

      notes() {
      	local fpath=$HOME/notes.md
      	if [ "$1" == "gvim" ]; then
      		gvim + $fpath
      	elif [ "$1" == "vim" ]; then
      		gvim + $fpath
      	elif [ "$1" == "date" ]; then
      		echo '' >> $fpath
      		echo '# '`date +"%m-%d-%Y-%T"` >> $fpath
      		echo '</comment><comment></comment><comment></comment><comment>---' >> $fpath
      	elif [ "$1" == "" ]; then
      		less +G $fpath
      	else
      		echo '' >> $fpath
      	    echo $@ >> $fpath
      	fi
      }

Insert the current date with `notes date`. Store a note with `notes the earth is about 25k miles around` or `notes dentist appointment Thursday` or `notes purfunctory - carried out with a minimum of effort or reflection #vocab`. Look up recent notes with `notes` or read/search the entire notes database with `notes vim`.

<comment><USER3> Why not just use Notes.app?

<comment><USER4> > Why not just use Notes.app?

Because not everyone uses macOS.

This shell script works on most Unix-like systems unlike Notes.app

</comment></comment></comment><comment><USER5> Interesting study - I think it's a great idea! Though I disagree with the statement 'we do not actually learn much'.

Most learning is very hard to condense into a short note. For example, "Booleans have a toString method in JS" is a tiny factoid that, yes, is something that can be learned. But I think it is only a minor fraction of what is actually learned.

An tennis player may write down what they learn in a month, trying to get better at the game. But ultimately, much of the learning comes from understanding abstract patterns and building up a portfolio of experiences to draw reference to in real-time.

It's the same way with programming - if I work on a game, and use some engine - yes, I'll learn the API to that engine, and maybe some extra factoids about C# I didn't know. But the learning that does me the most good is the more abstract stuff - intuition about how to structure larger projects - how and when to start focusing on performance, rather than features. Stuff that doesn't really boil down to a one liner, and you may not even realized you learned until after the fact.

<comment><AUTHOR> Author here. I agree. Some things we learn cannot be easily quantified. For example, the way I write code has changed compared to years ago. But I cannot put in words what it is that made me so.

It makes me think maybe my tool is better suited for more obvious learnings. One applicable demographic would be beginner programmers because I remember that when I started coding I had to learn many obvious things such as API, language features, etc. And even seasoned programmers are always beginners at some things.

</comment></comment><comment><USER6> I kept a list of bugs one month in the 1980's. I figured this way I'd never make the same mistake twice. I found the sheet of paper years later. Last entry:

Forgot to eat. Got sick.

</comment><comment><USER7> I wrote down everything I learnt from 13 years of solving tricky bugs (194 entries in the file). A very useful and interesting habit that I'm still following.

I distilled the most important lessons here:

[https://henrikwarne.com/2016/06/16/18-lessons- from-13-years-...](https://henrikwarne.com/2016/06/16/18-lessons- from-13-years-of-tricky-bugs/)

<comment><USER8> This was really valuable to read! Thank you so much

</comment></comment><comment><USER9> The approach the author used here is similar to using flashcard apps like anki, except not as well fleshed out.

Normally, in a flashcard app, you would write down a question and an answer. So you can review the question, and see if you can answer it or not. He wrote this down all as a oneliner for each of his "learnings". Its nice to see a frequency graph to see how often you are learning, but it doesn't really serve a purpose besides showing how inconsistent you are learning new things.

I would highly suggest anyone interested in the authors approach to learning to read these 2 articles about spaced-repetition-learning and flashcards, which goes into much more detail.

[https://www.jackkinsella.ie/articles/janki- method](https://www.jackkinsella.ie/articles/janki-method).

[https://www.supermemo.com/en/articles/20rules](https://www.supermemo.com/en/articles/20rules)

Not all things benefit equally from writing things down learned / flashcards. Some things can only be learned through practice, such as learning a sport you aren't familiar with such as football. But flashcards can be beneficial here to learn about the rules of football, the mechanics, terminology, etc.

The hardest part is differentiating what pieces of information benefit from using flashcards and which don't, and consistently recognizing when new information is learned / making a flashcard for it

<comment><USER10> This thread[1] by Michael Nielsen is a good description of the use of spaced repetition to memorize things.

[1] [https://twitter.com/michael_nielsen/status/95776322945477427...](https://twitter.com/michael_nielsen/status/957763229454774272)

<comment><USER11> Here is a pretty exhaustive (Gwern style) overview of SRS:

[https://www.gwern.net/Spaced-repetition](https://www.gwern.net/Spaced- repetition)

</comment></comment></comment><comment><AUTHOR> I wanted to measure how much I was really learning while programming. So I wrote down notes every time I learned something for an entire month in January.

The result revealed that we do not actually learn much and that we have misconception about 'learning.'

<comment><USER12> I don't know that it is fair to extrapolate conclusions about "we" from the single data point of just yourself.

Learning is also about the big picture. Counting the number of factoids that you pick up about specific languages isn't the same thing as gaining a broader understanding of software development, or of a particular framework or even a specific codebase.

<comment><USER13> I can't read the article(blocked at work here), so at face value I agree with you. But then the question is, how do you go about measuring the latter?

<comment><USER12> I'd ask a different question, of why do you need to measure it in the first place? I learn more about our codebase, my productivity goes up -- I deliver more updates, with less bugs, faster as I learn. Do I need to measure the details of how much I learned? Or is it sufficient to just know that I'm grokking more each day, and that is reflected in my work?

Isn't that the mantra of BI? Be careful what you measure, because that is what you will improve.

<comment><USER14> > _Isn 't that the mantra of BI? Be careful what you measure, because that is > what you will improve._

The corollary is that you don't improve what you don't measure.

> _Or is it sufficient to just know that I 'm grokking more each day, and that > is reflected in my work?_

OP's point is, I believe, that you _don 't know_ that you're really grokking much of anything and how much it's actually reflected in your work, because you're not measuring it. This can work if you have good feedback mechanism at work, though.

<comment><USER15> > The corollary is that you don't improve what you don't measure.

I mean, this is a nice saying, but it is pretty clearly not true. Lots of things that aren't measured are improved; we have not measured my two year olds vocabulary at all, but it is certainly improving.

<comment><USER16> Indeed. The correct corralary is "Things that don't improve aren't being measured"

E.g. negating A => B yields !B => !A

<comment><USER17> So measuring learning is a good thing, because it means you will likely be more deliberate in actually getting better at it, as opposed to just leaving it up to chance

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> I've recently switched from a giant append-only text file which I've been using for 18 years, to using TiddlyWiki -- a personal wiki. Each journal entry (or any wiki page within it) can be tagged and you can view pages across tags, so the ideas is to tag the journal with topics and then later transfer it to some learning article about that specific topic (or any part of my past life in general).

I've found that I constantly scan HN etc. for new articles, may read them through and it gets weakly stored in some kind of background memory, but it doesn't really make me form a sufficient opinion on the subject. 15 years ago information was scarce (C/C++ user's journal only came out once a month!) or expensive (E.g. O'Reilly books), or questionable (Usenet groups). Nowadays there's just a constant stream of interesting things happening.

</comment><comment><USER14> I did something similar over last year at work. I put a section called "Insight from today" in the default template I use(d) for everyday work notes, in which I wanted - hoped - to put something new I've learned.

Turned out, I'm not learning new things too much at my $dayjob (or my attitude is wrong). Ultimately, I was disappointed, but it made me reconsider just how much I'm _really_ implicitly learning - turns out that more often than not, those are irrelevant minutiae instead of more fundamental facts. I favor more explicit, focused learning now.

Most notes were obviously about code (Java, JavaFX), some about my mental state while coding. Some more interesting ones:

-

There are some serious reasons[0] for Java not to have Pair<K,V> or Tuple classes in its standard libraries. They mostly boil down to avoiding people using Pairs as cons cells to avoid creating classes that would properly name and give meaning to what is being composed and why.

-

TabPane in JavaFX has a division-by-zero exception in the arrow keys handler when you have 0 tabs in the pane. Note, modulo op (%) can cause division by zero too. Obviously.

-

Storing trees (hierarchical data) in a database -- closure tables. Explanation: [1], HN thread: [2].

-

Thread.setDefaultUncaughtExceptionHandler FTW.

-

Switch-case has lexical scoping on the entire switch block. Example:

      switch(something) {
      case foo:
          String abc = "xyz";
          break;
      case bar:
          //String abc = "uvw"; //wrong - abc already exists; it's scoped for the entire switch
          //System.out.println(abc); //wrong - though abc exists, it won't be initialized in this case block
      }

For per-case scoping, we need explicit blocks.

Nice trick question for an interview, lol.

-

Stress is bad.

\--

[0] - [http://stackoverflow.com/questions/24328679/does-java- se-8-h...](http://stackoverflow.com/questions/24328679/does-java-se-8-have- pairs-or-tuples)

[1] - [http://www.slideshare.net/billkarwin/models-for- hierarchical...](http://www.slideshare.net/billkarwin/models-for-hierarchical- data).

[2] - [https://news.ycombinator.com/item?id=13127938](https://news.ycombinator.com/item?id=13127938)

<comment><USER19> Unrelated to the substance of your comment, thank you for putting up those citation links.

<comment><USER14> They were part of their respective notes, I just reformatted them to be in one place in this comment :).

</comment></comment></comment><comment><USER20> When I started my current position (my first as a developer), I was given a company notebook that I use as a learning log. For each PR I write a bullet point or two of things I learned/mistakes I made in creating the PR.

I go through it every so often to look for patterns, and use them to focus my learning. It helps avoid repeating mistakes, and makes my professional development much more directed/intentional.

I prefer keeping the learning log in a notebook than on the computer, as looking for patterns requires me to review everything I've written. I've found that unexpected connections pop out at me when I do that.

</comment><comment><USER21> I've been doing something similar using jrnl. I use hashtags so I could theoretically look up stuff in the past.

I.e.

> jrnl "@vim type _:noh_ to remove the last search's highlighting"

And then a week later when I can't remember, I could use

> jrnl -n 10 -and @vim

<comment><USER22> Hadn't heard of jrnl before. Love how clean it is and the tagging is awesome. Will definitely be using this, thanks!

</comment></comment><comment><USER23> Looks great. I would try it if I didn't already use Org Mode capture templates. In Emacs you can hit `C-c c` and then choose a template (`n` for "note template" in my system). Then write your note in the box that appears (with Vim keybindings available if Evil is installed). `C-c C-q` to add tags, then `C-c C-c` to save and close the note. Each capture template files the notes away in locations and formats that you designate with short lisp snippets. I have 12 different capture templates for various kinds of information that I want to save.

</comment><comment><USER24> Personally I've found in multiple fields its often harder to quantify, categorize, and explicitly memorize things than it is to just learn them. Usually the most important items are semi abstract (how to organize, when to optimize) or just keep coming up so frequently, you don't really need to plan around it. The repetition that comes from regular work cements a _ton_ of knowledge you don't even realize you are picking up -- its just part of the job. I do take regular notes (on a notes app I'll finish one day, [https://www.striatum.io/](https://www.striatum.io/)) but I use them more for reference, reflection, and to just off-load my mind when I have too many thoughts floating about.

</comment><comment><USER25> I am a fan of being able to take notes, log your own behaviour (and track time) and do other things off the command line. I like the approach.

Pedagogically speaking, I'm curious if this will actually help. It seems to me that note taking and review is definitely an important part of learning, but I've found that writing out in long-hand and being able to draw diagrams helps considerably. None of it useful without regular review, and application too. I'd be curious to hear other people's thoughts on this approach from a retention/review perspective.

<comment><USER26> I'm starting to begin the same set of things(logging, trackign...). Just curious, do you have any tools you like?

</comment></comment><comment><USER27> I wrote something[1] for taking notes while programming in particular, and it's been incredibly helpful. I use a script to roll up a week's worth of notes and review them, and filter "the good parts" into my personal wiki and Anki to review.

[1]: [https://github.com/Az4reus/logrs](https://github.com/Az4reus/logrs)

</comment><comment><USER28> Starting doing same. Learned a lot, as when you write -> you read to plug the gaps. Plus these notes help me to revise my work. Also share toy codes on Github to experiment.

</comment><comment><USER29> I usually use mediaWiki for doing things like this. Thanks for remind me to start the notes again.</comment>


Agile Is the New Waterfall - <AUTHOR> https://medium.com/swlh/agile-is-the-new-waterfall-f7baef5d026d <comment><USER3> _The cost of shipping the wrong thing is much higher than the cost of slipping arbitrary deadlines to ship the right thing._

That assumes you can tell what the wrong thing is before you ship e.g. without feedback. I don't believe you can. Agile is the process we use if we don't know what that 'right thing' is. It's better to ship the wrong thing and then fix it than to spend additional time on what you believe is the right thing only to find that it was actually the wrong thing and have to fix it anyway.

If you know _absolutely_ what the problem is, what the best solution is, and the situation isn't going to change during the course of the project, then even waterfall will work. Agile is being willing to say "I don't know what the solution is" when faced with something and not being stopped by that problem - do what you can, put it in front of a user, gather feedback, and repeat.

</comment><comment><USER4> The main problem of the author is that he as a developer has not fought development to be perceived as stakeholder. Which is the core of all problems.

If every tech related decision requires dev to have explicit buy in and commit, and they are equal partners on the negotiating table - a lot of problems then disappear.

I have recently been very blunt in some exchanges.

"\- How big should the project scale? \- Infinitely! \- In that case I will need infinite time and budget"

I got reasonable estimates the next day.

As a developer it is your job to get the problem right, to evaluate the business case for any feature request and give a better proposition if the initial requests sucks.

And for the hated waterfall - well some big decisions are made at the beginning of the project and are almost immutable - technology stack, module boundaries, module interaction, available hardware.

It is once again your job to make sure that recruiting can deliver the right people, that we can procure the needed hardware and so on.

<comment><USER5> I've worked with the author before. A lot of projects handed to us are toxic from the beginning and while start-ups fail often, the definite default for projects from our customerbase was decidedly dead-by-default even with bright, effective developers that articulate their points to stakeholders well like you're saying is a responsibility.

There's a lot of hate in the replies but I think the context of that experience would make his inflammatory arguments perfectly rational.

<comment><USER6> You will always get a lot of hate if you criticize someone's religion.

</comment></comment></comment><comment><USER7> Yes, agile is basically waterfall when the people "practicing" it are using it in name only. No one promised Agile would be Engineer Driven Development - <USER2> should be team driven development. Anyone (business, product, marketing, engineer, or otherwise) should be advocating for them to lead the process, because thats how Waterfall starts, with one person in charge of decision making.

Agile works when the user is the decision maker, and everyone on the team is advocating for the user (although if its only product that is advocating for the user, that works too). Its a group effort, not something that should just magically work because "we're using agile now".</comment>