shadowmint

Unfortunately posting more or less the same comment in many threads just makes other people do exactly the same thing in frustration and destroys the entire comment thread with copy-paste wars.

It's bad forum etiquette everywhere, not just on HN, and it ruins the conversation for everyone.

> When more than one person makes the same provably false claim

/shrug

Right or wrong regarding the content, you're not a one-person-army out there to single handedly defeat all the wrong-doers on HN.

If you're just here to tell people they're flat out wrong, rather than actually have a conversation, you're just spamming the thread.

Have you considered the reason you keep getting the same response to all of your posts in this thread is perhaps because you keep making the same assertions in slightly different ways?

Calm down dude; we get it. You don't have to post the same comment over and over again to make your point.

You'll have a make more meaningful conversation if you stick to one thread and actually engage rather than just copy/paste your reply.

Funny how no one has any meaningful advice, just some snark about those dang young developers. Get off my lawn!

That line wasn't the important part of this post. This one was:

> You should also have a global self-development plan. If you can’t put it into practice under the scope of the project, you should spend your free time on it.

Damn straight.

If you work somewhere with tight deadlines and rubbish code quality, and you're just sucking it up and writing rubbish code, you're part of the problem.

You should always have a plan about how to become a better more effective developer where ever you end up working. Sometimes that means plan to spend 10 minutes a day talking to your project manager. Maybe review code the last 1/2 hour of the day. Maybe make some internal tools to help automate your job.

Don't just sit there and be miserable; if your job/company sucks and you can't find a way to change it, at the very least make it a stepping stone to something better.

Some idle advice from my experiences working in places which sucked:

- If you write code, it should be good code. Even if other code is bad, that's no excuse to stop caring.

- ...but, you dont need to refactor that. Just do what you have to do, and make it as good as it can be under the circumstances. Don't break other things when you make things cleaner and better; that makes PMs think that 'good code' = 'break features'. Disaster.

- If you ship rubbish to 'come back and fix later', you'll never come back and fix it.

- Don't just comment out code and replace it a quick fix. Don't [Ignore] failing tests. If code is going away, take responsibility of actually delete it.

- Don't leave 'TODOs' in your code; either do it, or don't. No one is ever going come back and do your TODO. Not even you. That's what issue trackers are for.

- Some developers don't like running with 'trainer wheels' or 'guard rails' as they refer to unit tests. Ignore these people. Always write tests. The worse the place you work is, the more desperately you need those tests.

- Project managers (unless utterly incompetent) don't care about deliverables per se; they care about managing expectations. Estimate. Review your estimates. Try to deliver on your estimates.

- Don't work overtime unless it'll actually make a tangible difference for a specific deadline. :)

The point isn’t that no one does it, its that its hard to do right.

...and that is flat out the case for c++, unequivocally.

In rust you’d expect it to be better, because of (reasons rust is good here, like safety, having a package manager and an ecosystem, etc etc), but practically, there are too many halfbaked solutions, too much ‘use nightly’ and few good stable proven solutions to look at.

Rust isn’t the right solution for every problem, but it should be a good solution for secure very high performance network services.

Its definitely a good goal for the year~

> But everything I can see as an engineer says that Magic Leap’s display hardware is not going to have very good image quality and it is going to be expensive to make.

So what? What are we supposed to take away from this?

Even if true, its clearly not stopping them, and its not clear if that will or will not make a successful consumer device.

If its rubbish, a few of people will lose a lot of money and we’ll all move on with our lives a bit disappointed, but otherwise not really caring.

The sooner they ship whatever it actually is, the better.

This kind of idle speculation is just gossip.

I think this a well made point that many developers fail to appreciate.

Some processes are there to make people productive, prevent them from distractions and help resolve issues...

...but an equally important set of things you’re doing is providing estimates and feedback to the business, so they can make strategic plans and not look stupid to customers.

A lot of process fails (particularly in agile) seem to stem from failing to understand why they’re being done.

Retrospectives aren’t for planning technical debt sessions; they’re there to explain why you didn’t deliver on time. You made some bad estimates? Well, if you don’t go back and review them, guess what, you’ll never get any better at it.

Were those deadlines arbitrary? Maybe, but aren’t you glad you didn’t have to sit in a meeting explaining why things won’t be delivered when you said they would, and oh yes, how stupid you are and so very sorry, its not good enough is it.

Those are meetings no one wants to have.

If you’re forcing your workmates to have them by half heartedly doing a process, your team isn’t doing their job; even if they’re highly productive and produce high quality output.

Scrums aren’t a tech briefing. No one really cares what you did yesterday. Its your chance to ask for help if you need it, and a chance for the team to make sure everyone is on point and not drifting off into Q-space working on something irrelevant.

Basically, whatever the process, people don’t just magically ‘get it’: you have to actually articulate what you’re doing, and who’s benefit it is for, or its a meaningless mess of going through the motions.

...yes, but that comes with burden of complexity and (usually) bad design decisions (like using core async).

Its not just night & day, closurescript > js; a lot of very good stuff exists there, but immutable by design isn’t a silver bullet that magically makes problems go away, and it (cljs that is) does introduce its own problems.

Practical examples of where cljs is tangibly a better choice is probably more useful to people.

For example, I personally have fought a cljs modal that kept an open channel waiting on user input; but when the modal closed, the channel was still there waiting and when it reopened there were now two channels, both getting input events, doing twice the work. Bad design, and not fp at all.

How did immutable structures help? Not at all. The author just used a global state atom to store everything anyway.

I’m just saying; yes, in clojure immutable is on by default, and that is good... but I don’t think I’ve observed, particularly, better code & lower bug rates in the cljs code I’ve worked on as a result...

I'm not even going to bother.

Nuget is such a pile of rubbish it's not even worth arguing about; if that's the best package manager you've ever used, you should really go check https://github.com/fsprojects/Paket out.

(they also helpfully articulate why nuget isn't really very good)

The irony is that the folk from go-world have finally acknowledged the package management solution they have is really terrible, and they're building a lovely new one (https://github.com/golang/dep).

Maybe sometime in the future you'll be eating your words, when go has a lovely package manager.

...and c# still has nuget.

:)

When was the last time you wrote a micro service that compiled to a single binary and interop'd seamlessly using grpc in C#?

I'm going to guess the answer is never, because it's basically impossible to do.

Do you care? I doubt it, but some people really do.

It's just different use cases for different things. Sure, go has its problems, but needing a large heavy IDE isn't one of them. That's really important to some people.

/shrug

> Oh, and when I have to use Go, I find a chore to write generic code...

Oh man, don't even start. If you don't like go, don't use it. It was just one example of tooling that's better than C#. Rust, node, clojure, heck, even python has a better story for 'pick up and start using' than C# does at the moment.

Do we really need to start digging down into how fundamentally terrible nuget is as a package manager, and how I personally find it like installing Master of Magic using 3 1/4 inch disks one by one when it screws up, or the feed screws up (like it did TODAY for about 4 hours)?

nah. No one cares.

Let's just leave it at: There are some valid concerns people have with the C# ecosystem, and using C# on non-windows platforms. It's a work in progress.

At least we now have a coherent direction for everything going forward~

To be fair, C# is a chore without good tooling.

I used to use omnisharp with atom and frankly it was just rubbish. It crashed all the time and required constant restarts, and (still) takes a massive amount of time (and memory) to start.

I went back to using golang, and didn’t regret it for a second. The tooling in go is excellent and you can use a simple editor for many things. That’s really compelling for people.

So... to be fair, if you were to idly pickup .net core as a linux user, and expect vim or emacs to do the job, you’ll find it a terrible experience.

...but, with the right tooling, it can be really great. vs, cscode or rider (not free) make using c# a pleasure to work with.

The dotnet cli tool is still quite terrible (how do you install dotnet watch again? why does it take 25s to restart a simple web app? You think git has obscure inconsistent incomprehensible command line flags...? ha! remind me why ‘dotnet build’ is running like 50 shell commands from the .csproj file...but only in this configuration you didn’t specify excplictly? surprise!) ...but its usable, and its slowly improving.

I feel like a lot of C# enthusiasts shoot down complaints as people being rubbish, or trolling or ‘doing it wrong’; but the reality is c# on a platform other than windows is new, and still pretty raw.

Pointing people in the right direction (you do need a proper IDE) and acknowledging that doesn’t suit everyone is better than telling them they’re ‘doing it wrong’; thats just jerk behaviour and comes off as fanboiism.

I think a lot of what makes SOLID valuable is that its articulating patterns that make sense to people because they’re obviously good ideas.

S -> don’t write spagetti code.

O -> If you want your code to be extendable, explicitly choose the parts that can be extended so you can predictably deal with new functionality.

L -> If you extend code, don’t screw it up so the code doesn’t work the same way. Extensions shouldn’t break stuff.

I -> Make your interfaces tiny.

D -> Dependency inversion to make things testable; because testing is good right?

Well, DI is always a bit contraversial, but at least its easy to say why its good; its just a bit of pain to setup.

The interface segregation has always been the odd one out for me.

One method interfaces? I know the golang best practice folk love that stuff too, but I just find it irritating when I have to work on code that uses it extensively.

Anyone actually explain tangibly why its a good idea?

If you’re using it to defend against workmates who might abuse an interface with too many functions on it... well, thats kind of lame imo.

Sure, mega-interfaces are bad... I guess... but so are objects with massive sets of methods on them. Why the special focus on interfaces?

It depends, is that work based on the free work of others?

Taking advantage of the community and not contributing back for others to benefit (as you have, for free) seems selfish to me.

Maybe if he proportionately (based on LOC or something) donated any income to his upstream dependencies?

...but I suspect that wouldn’t leave much.

500-600ms is, to be fair, a big one time cost.

The downsides are pretty darn significant though. I can’t imagine a situation where I would trade ‘starts a bit faster’ for ‘throw away all parallelism in code’ personally... but hey. Plenty of people use node for very serious stuff.

I suppose I just think this is an example of fast and cheap on the fast/cheap/good scale.

yes. and multithreaded.

Theres no meaningful reason to use cljs other than to avoid java or if the java runtime isn’t available (eg. browser).

Extremely relevant quote from the talented Mr Ng:

> “When the Chinese government announces a plan like this, it has significant implications for the country and the economy,” says Andrew Ng, a prominent AI expert who previously oversaw AI technology and strategy at China’s biggest online search company, Baidu. “It’s a very strong signal to everyone that things will happen.”

ie. There is going to be a tonne of money poured into this.

Will it make a difference, tangibly to economic transformation? Who knows...

...but anyone sitting here scoffing that China can’t make itself a world leader in a field by simply pouring money and support onto the problem needs a serious history lesson.

They have before, and there is every indiction they will again, here with this.

More interesting: will it be as transformative as everyone is hoping?

I'm pretty sure this already well covered in https://www.tensorflow.org/programmers_guide/

I don't think reading this will give you any understanding of what tensorflow is useful for, or how to do it.

The steps of writing a tensorflow program are always like the 'how to draw an owl'; first you define some simple tensors... then just, do the rest of it.

Step 1: Define tensors and inputs. OK!

Step 2: Linear regression. OK! (useless, but sure)

Step 3: Generate high resolution cat videos from a corpus of dog videos. Uh... ????

There are plenty of very good simple introductions to tensorflow.

The tensorflow tutorials themselves try to drop people in 'from the top' with high level practical examples, so we're good on that front too.

What's missing is a middle ground of 'and then do something practical but simple'.

You know what the 'best practice' advice for working with a GAN is?

Find someone else's implementation, copy it, and tweek the hyper parameters, change the input.

This is why I recommend people learn keras, not tensorflow; because it isn't super production ready and practical, but it will let you learn to build and test models easily.

...and if there's one 'programmers guide' to tensorflow, it's exactly that:

You don't just 'build' a tensorflow model; problem solved off you go.

Nope, you're going to be going back and tweaking and changing and randomly trying different stuff over and over again until you stumble into a 'good enough' solution to run with.

...and that solution; it might almost work for some other similar domains... but it probably doesn't generalize. You'll probably have to do the whole thing from scratch again.

Machine learning. Fun times.

> What are the properties of Clojure that cause programs written in it to have so many bugs?

Well, I can only speak from my own experience, but twice now I've personally seen enthusiastic talent python programmers create clojure projects which 'did all the things':

- used core-async heavily, including blocking channels that are never resolved in the UI.

- massive 'global application state' top level atoms that are mutated arbitrarily throughout the application

- massive complicated one line reduce/map/whatever where people are trying to be clever and reduce the lines of code, because 'fewer lines of code is better'.

I think it's telling when you get a 'walk through' from the person who wrote the code, and they have to stare at it, trying to figure out why it was they needed 10 different channels as they're explaining it.

After thinking about it quite a lot, my conclusion is that I would recommend against clojure for the same reason I would recommend against C: It's easy to mess it up.

Clojure allows you to create very complex applications; and you have all the tools to shoot yourself in the foot.

I don't think I'd tell people to migrate off clojure, but if the opportunity came to work on a new project, I would run away unless at least 50% of the people had actively used it before.

(and by comparison, my experience with a relatively novice team using elixir has been extremely positive; so yes, I do actually think this is a reflection on a clojure itself, not just 'insert any unknown programming language here').

We already have tools that let us do the 'right thing' if we spend enough time and money on it.

Another relevant quote from that paper, with regard to formal verification methods:

> Any new software technology in this field must address both the cost and time issues. The challenge here is daunting because a reductions of a few percent is not going to make much of an impact.

> Something like an order of magnitude is required.

I think that's pretty much spot on.

I think that's really the issue I see; we don't need more arbitrary tools that just add yet more complexity to already complex systems.

We'll see.

I think the netstandard -> all platforms approach, combined with the aggressive depreciation of old .Net 4.6.x versions is a road map for the future.

Maintaining two entire release chains, the 4.x and the .Net core 2.x, is an impossible long term strategy.

I would be absolutely astonished if the 4.x line is quietly folded away and depreciated ('unsupported') once the netstandard surface area means the code bases that no longer run on the .Net core fall to significantly small fraction.

At that point there will just be 'one' .Net again, and it will be .Net core, on all platforms.

Significantly, there seems little to no indication (https://github.com/dotnet/core/issues/43) that winforms and WPF are going to .Net core.

You might argue that Microsoft is a legacy beast, and they won't abandon their developers by dropping support for old versions, but they already are doing that in the 'you can install it, sure, but it'll never get any more updates' (#1, #2), so you know.

Don't bet the farm on a WPF app. Just saying.

#1: https://blogs.msdn.microsoft.com/dotnet/2015/12/09/support-e...

#2: https://support.microsoft.com/en-us/help/17455/lifecycle-faq...

This surprises no one.

I'm more interested in: what's the future for UWP apps now? Another dead end like silverlight?

A cross platform UI library that runs on .Net core (ie. windows, mac, linux, android, ios), some kind of hybrid of ??? and Xamarin forms could potentially be quite a nice tool... but its pretty hard to be excited about the prospect with their track record of killed off UI frameworks so far.

nah.

I think you could quite easily quantify the effect various tools have on a code base; adding unit tests, using a repl, static vs. dynamic etc. on the various aspects of your code:

- How quick/easy is it to add new features?

- How often do you add new bugs?

- How long does it take to fix bugs?

...but I think you could also look at the impact individual bad actors (the 'dont care' programmers) have on the same code base.

Now, because the 'dont care' programmers hack out rubbish at the speed of light, it may superficially appear that the net impact on the code base is balanced; more features, more bugs... but that rubbish slowly spreads out into the code base, and incrementally trigger a cascading bug creation rate for all the programmers.

Now, if you want to suggest that tools can add enough value to overcome the negatives from having rubbish programmers, I'm all ears, because I've never seen a tool that can do that. The bad programmers just abuse the tools or ignore them.

So... in that context, I think its fair to say, more tools really achieves nothing much, when bad programmers and bad programming practice results in such catastrophically bad outcomes for software.

Maybe, if you can make your tools nice enough and add enough processes you can kind of force bad programmers up a notch. I appreciate that; but the question really is, why are there so many programmers who are so rubbish? Why do they never seem to get better? Why don't they care?

Do you really think you engineer a solution to that? ...because I think it's a social problem, not a technical one.

Maybe some tools can help, and maybe not everything Uncle Bob says is gospel... sure; but I think this is just stupid:

> Uncle Bob gives terrible advice. Following it will make your code worse.

I think history has objectively shown this is false; but of course, you're welcome to have your own opinion without any substantive basis other than that opinion itself if you like.

> When you need to ask a colleague something, walk up to his/her desk instead of dropping a message

'Did you get that email I sent you?'

Ahhhhhh~ No. Please don't.

There's plenty of good advice on this article, but be careful that the things that you do for yourself don't negatively impact other people; that's not be healthy, its being thoughtless and selfish.

I'm not going to continue repeat the arguments which have been made exhaustively about the benefits vs. draw backs of these approaches by other people. There are plenty of articles which cover this topic... all I can say is please read them.

If you still don't see any value in these tools, don't use them.

All I'll say is this:

In my experience, people tend to consider their applications to be simple enough that a simple solution is sufficient.

However, in reality, that seldom seems to be the case.

UI is hard to get right, and has a tendency to drift towards complexity over time as more features are added: I can think of several people who have picked the naive simple solution and regretted it later; to the point of rewrite in some cases.

People who picked the complicated solution sometimes regretted the extra burden of complexity, but I don't think I've ever seen this as a cause for large scale failure or rewrite.

May I just say your consistently friendly helpful manner in this thread is deeply appreciated. Thank you.

Only at a relatively trivial scale; and certainly, do that if your application is simple enough. There's probably a fair number of applications that clearly fall into the 'simple enough not to need redux' category.

That's a good approach, seriously. You don't need redux at that point; don't use it. I'm not even suggesting such applications are 'trivial'; they probably just don't have excessively complex component hierarchies and interactions.

...but please read this really quite old article if you haven't before: http://blog.ploeh.dk/2012/11/06/WhentouseaDIContainer/

This is an argument that has literally been made a hundred or more times before, and nothing has changed about it.

Sure, this article is about dependency injection, but its essentially the same domain. You can argue that manually passing props is the same of 'poor mans' dependency injection, and it certainly has value in that there's 'no magic' in it.

...and certainly, you fall into the pit of pointlessness and frustrations when you use magic, but there's no convention to make the magic 'all work without surprises'; but the same issues still apply.

Once the application reaches a certain size, the maintenance burden of the 'simple' approach becomes prohibitive.

/shrug

Well, what's your solution?

I mean, I've seen people drop redux into a single stand alone form for no reason other than they hadn't used react before, so they picked up a tutorial and the first thing it said to do was use redux.

So, I'll happily agree that there's a whole lot of people using this without any need for it.

...but there is a need for it for some people, and for those people, what's your alternative? Raw react? Have you actually tried that? Passing all the props down from child to child to child to child? It's not awesome, I assure you.

Are there redux alternatives out there that solve the same 'single source of truth' problem I've never heard of?

What are you using?

> There is no need for something to track "when, why and how your state was updated and what part of the application triggered the state update".

...or is that simply not a problem that some people have? I'll certainly agree to that; but then, why are you using react?

If your UI isn't dynamic, why are you building an SPA? For fun? The good old MVC tech stack works perfectly well for static data display and forms.

You know why react exists? ...because complex interactive forms are hard to do right, and because interactive user interfaces that do something more complicated than CRUD operations are actually quite difficult to do right.

The MVVM pattern with data binding is the 'best' solution out there for most UI application framework, and react is successful specifically because it allows you to manage complexity by creating a hierarchy of components instead. That's a really powerful effective technique, there's no question.

Redux lets you manage the state for that hierarchy in one place. It lets you build large react hierarchies and know exactly what state the UI is in at any point in time, in one place. Why? ...because managing state in 100 different locations is complicated.

What you're seeing is tools to help manage complexity; but you only need to use them when your complexity reaches a threshold that triggers the need to use them.

If you don't have a complex problem, you don't need complex tools to manage it.

> has been turned into an over-complicated mess by the community of developers, by gluing it with over-complicated add-on technologies.

What you're seeing is the application of tools to solve a problem that doesn't exist for the specific domain you're looking at.

That doesn't mean they don't solve the problem; it just means your problem doesn't require that level of complexity management.

It's quite frustrating.

I hear the 'its too complex' as an argument from so many people about using libraries and tools, and want 'something simple' instead; but I've hardly ever heard someone pitch a viable alternative instead, just complaints. Too much tooling. Too much complexity. Over engineering.

So, tldr: When you do have a big complex react application with complex UI interactions... what's the alternative?

If there is one, I'd like to hear about it.

Unfortunately the epic comment thread, very talky, none of the key stack holders involved, largely irrelevant chatter...

Is a case in point of why github isn't the answer for everything.

This is well said... although I think its unlikely to be a popular opinion with people at a personal level, but I hope the people who find themselves disagreeing take a moment to reflect on it.

While I think it's fair to say these sorts of applications do disrupt people and reduce their productivity, I'm certain that they help focus team efforts in a way that meetings just don't.

You can't split off 3 members of the team and have an important technical discussion during a meeting (or if you can, your project manager / meeting organizer isn't doing their job). You can't come back later and see exactly what it is you said that you'd do after a meeting. You can't tell a bot to create a bunch of tickets or what the current status of a system is.

If you find that your chat apps are not providing you with any value, maybe you're using them for stupid purposes like sharing funny pictures & this mornings cool tech blog post, or you're subscribed to the support channel, or your team is treating them like a social hang out space.

It's not that its a bad tool; its that you're using it wrong.

I think you've misunderstood my point; I don't think that at all.

I'm specifically criticising the focus polymer has on creating user interaction elements.

My point is that this sort of low level functionality isn't the right place to focus; most low level components you need already exist. What people is a way to build robust application UIs (and yeah, that includes having a root level <App/> component).

For comparison, read:

https://www.polymer-project.org/2.0/start/

'build custom ui widgets' <-- wrong, this isn't a problem most people have.

vs.

https://vuejs.org/v2/guide/#Composing-with-Components

'build your application from components' <-- right.

Personally, I think there's an important lesson here, and its the same lesson that polymer is learning as it stumbles around trying to convince people to use it.

Most people don't actually derive much benefit from writing custom UI widget primitives.

Certainly, that's a useful thing for a UI toolkit builder to be able to do, but tangibly, for most people, it's not actually useful.

I don't have time to invest hours implementing `ImageDropDownSpinner` as a custom element. <select> is good enough for me, and heck, maybe I'll use some 3rd party widget if I need something special.

That's not why react, vue, angular, etc. are winning the mind share of 'how to build web apps'; building UI widget is far less interesting than the ability to decompose your UI into a custom hierarchy of re-usable self contained units of functionality, that only at the lowest level actually involve UI components, is extremely powerful.

They might look like custom widgets, but <PageFoo> isn't a UI widget, it's your entire application; that's the difference.

It's easy to say this was a revolutionary idea, before its time, and it would have flown today instead of vanished into obscurity... but I think it missed the mark; it didn't solve problems people were actually having.

...but to be fair, it's easy to look at 'Web Component' efforts (like Polymer...) and go... yeah, this seems very familiar...