uk_programmer

Your arguments are the same as the copy-pasta. It isn't anything new, it isn't anything convincing and it isn't even an argument really.

> So a relative newbie, eh? I might have expected as much.

Yeah yeah yeah yeah whatever. You conveniently missed out the fact I've been programming since the late 80s, just not as a Software Engineer.

> Understatement. You are not however good at learning or listening. Or debate.

Why should I listen to someone that does the same recycled arguments? I listen to a lot of people, just generally not people who recycle the same old nonsense. You haven't told me anything I haven't heard before.

> Maybe the reason you keep hearing the same arguments is that there is merit to them. Maybe your viewpoint isn't universal and a large number of other people see things a different way. Maybe the reason you aren't convinced is because you don't take the time to listen and understand what others are saying. I understood your points, I accept some of them, for example bash isn't any good for managing SQL databases. You've offered nothing but insults false assumptions and general negativity and that "you don't like it".

I don't think streaming text around between programs is in any way robust. I don't mind the whole "lego pieces" and single responsibility principle. But it is hardly unique to Unix. This tirade against me because I don't agree with your ideology and somehow I am a bad person is quite amusing though. The so called insults were extremely mild so don't pull that nonsense.

Goodbye.

Maybe you are dense. I have heard all these talking points before, many, many, many times. I do not find them convincing. If you regurgitate copy-pasta from 4chan's /g board I am not going to be interested.

> I think you are very naive and I don't see you how will gain experience if you don't wish to listen to anything you don't already understand!

I've been mucking about with computers since the BBC Micro-computer. I have been developing professionally for 15 years. Don't patronise me. I am actually very very cynical.

Seems you are going into the hissy fit. I also don't care about your arguments from authority. Programming against a well defined abstraction will be better than piping things around and easier for people to understand.

> These guys might have done things in ways you don't grok, ways you don't like, or ways you think you know how to do better. The UNIX approach, like all complex things, has pros and cons. But until anything you or microsoft has built has stood up for 50 years, been academically published and cited, maybe won a couple Turing awards and Presidential medals, don't try defend an argument with a simple "it's bogus" or "insane" or "non

This is the Pavlovian response to any criticism of the great unix way. Again all of this is an argument from authority and people used Unix because it was good enough and available. Lets not pretend it was successful because it was so great.

I can manipulate text fine with Powershell without having to use other small programs that may or may not exist on the system. I can also interface with parts of the operating system sensibly. I was reading and writing text files a lot easier with Powershell than I ever did with Bash.

> Look, typed OO pipelines sound like a good idea, but the negative side is this. For example, to deal with the registry, you have to have purpose built library like https://docs.microsoft.com/en-us/powershell/module/microsoft.... that someone needs to write and then everyone has to know. This has to be done for every kind of interface in windows. This is just as complex as Pythons standard libraries or writing C or C++ Win32 code.

You seem to think that this is somehow a negative. I think you should be able to rely on an abstractions. I would rather rely on a well defined and understood interface than writing my own script to manipulate a file. The former is obviously less error prone than the other. Any claim to the contrary is a nonsense.

> But back to the article. It's not valid to just presumptively state like a fact that one is better than the other as the argument. And it's really not valid to compare such different tools head-to-head when it's the whole underlying philosophies of their associated ecosystems that are so different.

Yes one is sane and the other one isn't. I've heard most of these (bogus) arguments before. I hate to sound rude, but I honestly fed up of hearing it.

Not true. While I am somewhat of a novice at powershell, I didn't find that to be the case at all.

> Streams of characters is as loosely typed as it gets. And for processing text files and gluing disjointed tools together, it may seem crude, but is very effective. Especially for quick text processing jobs, or automating series of commands.

Well done for the Pavlovian regurgitation of how piping text output is supposed to work.

I don't like working with it. It is okay for small scripts. However if it is mildly complicated I would use something like Python (not powershell).

Powershell is great for small scripts where you need to do sysadmin tasks e.g. I have a script where I setup my SQL Database aliases for development. Piping text about doesn't help me in these sorts of tasks. I need to go "I need to find where the real database is, and then map those properties to an alias". That works better with piping objects. It works kinda like functional concepts such as map(), reduce() etc.

You should use the right tool for the right job.

> The UNIX shell concept has been honed and refined over 50 years to do exactly what it does, and it does it very well. It is also extremely generic. This choice was on purpose and has stood up well to the test of time.

You know not everyone thinks that Unix was the pinnacle of human achievement.

I was going to rebut most of your angry ramblings. Then I read this and I remembered why it pointless with talking to people like yourself. You think there cannot be any discussion on a topic outside of what you think it correct because you have decided that you have the correct opinion.

I said "this shouldn't matter".

If a student wants to go to University they are means tested which determines the amount of grants / loans they are entitled to. Race isn't a consideration only wealth (based on household income).

> The problem is the tone the reader experiences. Most of the time, it doesn’t appear that commenters are actively trying to make their comment condescending, dismissive, or any of the other subtle variations of unwelcoming we see. These are people earnestly trying to help others, even if their tone is off.

What tone the reader experiences and how they deal with it is entirely up to them. I am fine with on a site that abusive language is flagged, but something that is perceived to be unfriendly by a robot. This is just folly.

I certainly won't be contributing anymore. I don't want to be on a site that has a robot flagging human interaction.

EDIT: Abusive language filters usually don't work that well. I put in someone's real name into a system and the system flagged it for "abuse" their surname was "Cummings".

Also the term "faggots" (which in the UK is a meal you can buy in the supermarket) has been censored on social platforms.

https://www.rt.com/uk/468436-google-censors-faggots-peas/

Because guess what the context in which you are using a word is important. So most of theses places can't get abusive filtering right. They won't get this right either.

Poor/Lazy developers will find ways around more stringent checks.

Other countries (some that may not care about the well being of their citizens) will be quite happy to take your place hierarchy and exert their influence over the world as they see fit, which may well be to the detriment to your nation (and nation is comprised of its people).

He is saying "things look bad now, but things can get better".

I've justified quite clearly why I think it is a good idea and in my original post I said quite clearly "It is upto you". It is trivial to turn on in the IDE and it improves readability outside of the IDE.

> Use implicit typing for local variables when the type of the variable is obvious from the right side of the assignment, or when the precise type is not important.

> Do not use var when the type is not apparent from the right side of the assignment.

> Do not rely on the variable name to specify the type of the variable. It might not be correct.

Your example has me inferring the type from the method name which isn't dissimilar to what they are advising against here.

TBH I should have known I would get a comment like this, where everyone lives in utopia and everything is always obvious to another person, nobody ever had a bad nights sleep or not feeling their best etc etc.

There are plenty of times where it may not be obvious what the Type it is returning even with quite decent coding standards and in any event I think it helps readability and isn't a huge ask. You can get Resharper / Rider to do this as a project setting (Visual Studio can probably do this out of the box now) in your repo and then the IDE will just do it for you.

https://www.newtonsoft.com/json/help/html/SerializationAttri...

I would avoid using dynamic (I believe underneath it is basically the same as the Dictionary<T, U> anyway, howeve r I don't really care to look it up).

Also regarding var. It is best IMO to use var when evident i.e. If the var right hand side is obvious what the type is use var, if it isn't use the Type name.

e.g.

When you should use var (it is evident from the right hand side)

    var name = "Joe Bloggs";

    var myVariables = _service.SomeMethod();

Don't tell me about how your competitor is bad. Tell me what you offer in comparison to your competitor.

I have used quite a few frameworks over the years and there is always some PITA issue you have to deal with.

> It sounds like you’re not really working on apps frameworks like react are supposed to deal with, (7 files of typescript) so why do you care?

You don't need large frameworks to scale something. You can just do it with applying the right patterns (that these large frameworks use) and get 80% of the benefit. However that requires (shock and horror), thinking for yourself and learning how things work properly.

That is quite an assumption.

I personally would use a field with a structured format e.g. XML (most RDBMS systems can deal with XML easily) and different types of address field e.g. postcode, zip code etc.

Then you could use a strategy for each country when dealing with it in your application.

You can use multi-targeting to move parts of your code over to .NET Standard. So if you start with your base projects and move your way up, gradually your code will become compatible between .NET core and .NET Framework. This will help you remove any .NET Full Framework / Windows specific bits. Where you have to have things that are specific to each OS you can then just configure your DI so it will inject the Windows specific / Linux specific implementation.

For those that are not aware of multi-targeting here is a great article on it:

https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargetin...

Typically if 25% of my users use IE11, I will just make sure it works with IE11. If I have to stay use an older version of the library I will just use that unless I can polyfill or patch the lib to work with older versions of IE.

Then again I am kinda strange in the fact that if it should work in an old browser (and time permitting) I will normally make sure it works well enough that it is functional in that browser.