Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×

Comment: Re:Developers, Developer, Developers (Score 1) 125

"He pushed them aside by killing development systems (VB6,FoxPro)"

Except VB6 and Foxpro were never really developer tools. They were tools for non-developers to get basic programming tasks done. That was kind of exactly why they were developed- things like Visual C++ were always the tools targeted at professional developers.

"the Win32 API, to slowly become more irrelevant with endless layers of cruft built on top"

Win32 API became irrelevant, because it's become increasingly irrelevant. Why on earth would you want to keep an outdated API that's now decades old in it's design and origins as your primary development target when no one is using it? That just doesn't make any sense whatsoever. It doesn't make sense to maintain something that's inefficient to develop with, and I say this as someone who cut my teeth on Windows development with C and Win32 API many years ago. I have fond memories of it but I've no idea why you'd give a shit about it in this day and age.

Your argument is classic of someone incapable of dealing with change, which, in the world of technology is probably one of the least desirable traits you can have. You can boil your argument down even further when you talk about layers of cruft, you can say using C with the Win32 API is in itself a layer of cruft built on top of just doing everything in pure assembly, which is a layer of cruft on top of just doing everything directly with machine code and fuck the APIs.

"Ballmer wasn't bad; his jumping around on stage shouting "Developers!" showed that he knew what the true value of Windows was: the external developers who wrote Win32 code for retail products or company-internal developers."

Except no one's actually done that for the best part of two decades now. Even before .NET really took off it was far and away MFC that was used for the majority of Windows development. Win32 API development was already largely dead when Gates left for all but the most basic things like setting up a message processing stub to get a DirectX or OpenGL program going.

"However, his middle-empire stage was a shift to focusing on selling to enterprise customers. This isn't a bad things by itself, but by taking his eye off the "Developer!" ball and focusing elsewhere, he guaranteed that plenty of developers went elsewhere."

So what? The enterprise became more important, fat client applications gave way to web applications. Ballmer doubled the profits of Microsoft during his tenure, so it looks like his focus change was exactly what the majority of businesses and developers needed. The fact there's a handful of luddites that bemoan the decrease in usage of Win32 API is meaningless because you're such an irrelevance in the grand scheme of things- most people can deal with change and follow necessary trends, even if you cannot. That's not a problem with Ballmer or Microsoft, that's a problem with you. You can't blame Ballmer's capability for pursuing necessary change for your inability to change.

People shifted to Java because it was a paradigm that gained a lot of hype in both business and academic circles and had a 6 year headstart on .NET and that happened well under Gates' reign not Ballmer's. Mis-steps such as VisualJ++ were the reason for that. By the time Gates stepped down as CEO, .NET hadn't even been released so Ballmer's tenure was the one that was responsible for taking all those devs lost during Gates' reign back because a combination of a far more competitive .NET, and Oracle's screwing of Java has helped grow the .NET community massively.

"It's interesting to see how Nadella is shifting the focus again and broadening it (Windows 10 on Raspberry Pi, for example). Time will tell if Nadella is simply being an anti-Ballmer or if this glasnost is signs of a more fundamental shift in the way Microsoft does business. I hope it's the latter."

It's neither. It's a continuation of the status quo, or did you completely miss that Ballmer also pushed Windows 8 on ARM? This increase in scope of platform support, and move to open sourcing of APIs started well within Ballmer's years. Nadella is just continuing what was already started. It's not a change in direction, it's business as usual as it has been for some time now.

Comment: Re:I don't see how this is a "Poor Google" situati (Score 1) 312

by Xest (#49436345) Attached to: Google, Apple and Microsoft Squirm As Global Tax Schemes Scrutinized

No one owes any website a business. If you setup a sign based on the premise that you need all ad-revenue to survive, profit, and make a living then you're one of that sizeable statistic of people whose businesses fail for the simple fact that you were hopeless at business.

It's like saying you should feel guilty for not bothering to look at adverts in free newspapers and skimming right past them. No you shouldn't. If someone is giving access to something with no upfront payment they have no expectation of payback. If the business model doesn't work, it doesn't work, tough luck.

I don't buy the doomsday scenario of there being no useful sites on the internet if we all have this attitude because I remember the internet from long before ads were commonplace. There was still equally as good information about, in fact, I learnt much of what I know about programming in that era, the only difference is it was all less bloated by presentation.

There should be zero guilt in blocking ads because accessing URL is NOT a contract implicit or explicit that you will accept all content from that URL, nor that you will read every aspect of it. If either of these things were true we'd be legally obliged to download malware, and legally obliged to read every last disclaimer and copyright notice on every site. There is no such obligation, and ads are not special cases, we neither have to read them or receive them, and no one should feel guilty for refusing them.

If a site shuts down because it couldn't afford to run because of ad revenue yet people visited with ad blockers then all that tells us is that there was a business model for the content if free, but not if ad sponsored. Sites with such small viewership typically used to be hosted by bundled ISP hosting. Those large enough to justify proper hosting are large enough to make enough from those that don't use ad blockers or to run as subscription sites.

A business is either viable, or it's not, if it's not, then no one should feel guilty about it's demise.

Comment: Re:Couch programmers bashing again. (Score 1) 182

by Xest (#49391359) Attached to: Modern PHP: New Features and Good Practices

You still seem to think spawning new processes is in any way a passable form of multi-threading in a high load environment as opposed to spawning new threads. This alone shows you're not fit to have any kind of discussion on this topic.

For starters, it means you can handle drastically fewer concurrent tasks because it has by far a higher memory and CPU footprint to do so. That's before you factor in the problems of shared data meaning you're probably also duplicating data in your separate processes (i.e. each process will probably have to have it's own copy of any configuration data).

But this is just one of many reasons why PHP is shit, stop trying to claim it's not whilst basically inadvertently arguing that it is.

Comment: Re:Ballsy, but stupid ... (Score 2) 308

by Xest (#49377845) Attached to: Attempted Breach of NSA HQ Checkpoint; One Shot Dead

I absolutely agree with the latter half of your post, that these guys got what they deserved for trying to ram a military checkpoint, but I disagree that non-lethal options couldn't have worked.

I say this because I live in the UK, where non-lethal is the only option available to most our law enforcement officers, and they stop aggressive drivers regularly without harm. Even where armed police are involved they typically shoot the vehicle unless there's evidence one of the people in the car physically has hold of a gun and has started firing back. I do not believe it increases the overall risk to people doing the stop, because our officers also have far lower casualty rates than yours by just about every metric breakdown.

On a base like this I'm surprised they don't just have retractable barriers in the floor that a car simply cannot pass until the barrier has been lowered after being given permission to enter. From there it's trivial to hold guns up at the people in the car and tell them to get out slowly, without having to actually shoot them. These sorts of barriers are widely available, as are one way barriers that pop down when driven over, but block if you try and reverse back meaning such a vehicle would be completely trapped between two sets of barriers.

So whilst I disagree with the AC's view that these people shouldn't have expected to be shot, I do think there's some merit in his point that in the US the gun has in far too many circumstances become the first course of action, when it should really be the last.

Comment: Re:Product Placement Taco Bell (Score 2) 18

by Xest (#49352795) Attached to: Ordnance Survey Releases Mapping Tools

So Slashdot shouldn't post anything about new product or data releases ever because it's product placement?

It's not like Slashdot is shilling for some ultra-rich company in this case that's just trying to make a quick buck off the user base here. Ordnance Survey is the UK government's official mapping agency - it's a government department, not a private company.

More governmental data being release to the public is a good thing, as it's a continued expansion of transparency and freedom to access data that the tax payer pays to produce in the first place. Open access to data is a big deal in the tech world right now, and it's exactly the sort of thing a tech site like Slashdot should cover as a result - this isn't a story about the latest iWhatever.

Comment: Re:people are going to be saying (Score 1) 737

by Xest (#49344253) Attached to: Germanwings Plane Crash Was No Accident

I'm surprised at this point there's not been more effort to allow remote override of aircraft such each plane can have it's autopilot enabled remotely overriding the pilot's actions. I know there's always the fear of hacking, but would that really be much of a threat if:

1) The worst you could do remotely was enable an enforced pre-programmed autopilot course.

2) The system was secure with a one-time key that's set on the runway by an authorised individual

If you put this equipment in an area of the aircraft that's inaccessible during flight I don't really see how this could be a problem? Surely if you've reached a point where radio and radar contact have stopped making sense, and the pilot isn't responding sufficiently, you should be able to remotely force a plane back on course against the will of the pilot in this day and age? It would even likely save lives in the case of cockpit de-pressurisation and so forth. I get that you wouldn't want to do this all the time because the pilot is always going to have better situational awareness and might need to do things manually, but when the pilot is the problem, doesn't this make sense?

Is there a fundamental reason why this can't/won't work or is it simply that there's not been enough will for or interest in this sort of thing yet? It seems odd that we're talking about releasing secure self-driving cars, yet the far easier problem of self-flying planes (that frankly is already a solved problem anyway in modern drones) seem to be out of the question right now.

Comment: Re:Couch programmers bashing again. (Score 1) 182

by Xest (#49343743) Attached to: Modern PHP: New Features and Good Practices

"multithreading can be used to implement async io but it is not a requirement, see node.js."

Oh god. Node.js uses IOCP, which implements a thread based model. Did you think it used magic or something?

No wonder you're posted AC, you're just embarrassing yourself. Acting as living proof that PHP developers are clueless. Well done, you've successfully proven my points throughout.

Comment: Re:Couch programmers bashing again. (Score 1) 182

by Xest (#49342819) Attached to: Modern PHP: New Features and Good Practices

Okay, so it sounds like I was right then after all if you're conflating curl hacks which require the spawning of a completely different process and a full blown TCP connection to achieve anything with an actual proper threading solution or async IO implementation (FWIW I find it amusing that you claim multithreading and async IO are completely unrelated things and then pretend curl is an async IO implementation- facepalm. You don't even know how PHP's curl library works).

I was going to reply in a bit more detail to everything in between, but then I got to this section of your post and realised it's fruitless as you don't even understand the basics:

"You're still going to spend 90% of your time waiting on blocking io. you can't complete your request until that io request is done, sure if i have 30ms of php code executing and a 180ms sql query I can use asynchronous io to make that entire request take 180ms instead of 210ms, but you're still spending the bulk of your time waiting for that 180ms sql query."

There's two problems with this:

1) You still demonstrate that your knowledge doesn't stretch beyond basic CRUD environments, you believe that everything you do on the web is simplistic web front-end, database backend CRUD type stuff. This is false, and if you had any worthwhile professional experience you'd know that a lot more typically goes on behind the scenes than my first website type setups (but that's probably also why you think PHP is acceptable, because you're not doing anything that matters).

2) On one hand you're talking about high throughput environments, and on the other you're talking about a process only handling one client at a time, which is what I was referring to when I talked about the PHP way. In more professional environments you don't need a whole new process for each concurrent request. That's a massive amount of unnecessary overhead, and environments like .NET and Java allow you to simply process other incoming requests in the same process whilst one is awaiting IO.

You seem to completely lack any grasp of the cost of firing up processes, as you seem to believe that spawning a process is an equivalently performant thing to do as firing off a new thread. It's sad, and you just prove my point that PHP folks only support PHP so vehemently because they don't know any better.

There's a reason that PHP stirs up hatred towards it more than anything else (well, except maybe Javascript) - it's because it's objectively shit, and the only ones that can't see that are those that are inexperienced and don't know any better. Languages like C# and so on just aren't even close to as controversial because for the most part they largely just work as you expect them to, and aren't as poorly designed.

Comment: Re:Couch programmers bashing again. (Score 1) 182

by Xest (#49336425) Attached to: Modern PHP: New Features and Good Practices

Yeah you're right, I haven't touched PHP in a couple of years now so I haven't seen anything about (nor can I find anything even now) PHP's new async support for the things you list. Yes I'm aware it's now got some half-arsed threading support hacked in to move away from basing attempts at multi-threading on curl hacks, but it's not me you need to be telling this to - it's the other guy whose argument that PHP is fine performance wise is because you're spending 90% of the timing waiting on blocking IO, which is obviously nonsense. This was historically the PHP way and it shouldn't come as a surprise to someone claiming to be well versed in PHP that this is a deeply entrenched way of doing things in the PHP community for that very reason, but it's never been the way of doing things in the languages I mentioned because they've all been designed to support it from the outset.

At the end of the day, in things like C++, Java and .NET you've got control of asynchronicity through the entire stack, but with PHP you're still limited by a strict bunch of fudges.

Comment: Re: Sometimes bad tools are just bad. (Score 1) 182

by Xest (#49334517) Attached to: Modern PHP: New Features and Good Practices

The problem is that people like you will continue to deflect the problems away because you're not competent enough to understand them in the first place. You don't know your code is broken.

The fact that you don't know that the type system is broken means that you're wholly unaware that any code you have written involving integers can behave completely differently when you move your codebase from a 32bit system to a 64bit system. It means you probably don't realise that your code is failing when you expect '0.0' to translate in a boolean expression to 0.0 as '0' does 0. It means you probably aren't aware of bugs stemming from the fact that the confused implementation of arrays such that they're partially ordered list, partially hash maps, but that the inherent conflicts that arise mean they fail at both can create nonsensical iteration. It means you don't realise that you have to explicitly declare a global as global, but if you do it might not actually be global depending on where you make the declaration.

But perhaps maybe you do know these things, you're just too much of a PHP fanboy to accept that these sorts of gotchas and faults you have to deal with are problems that people using almost any other language do not. Perhaps you've simply sold it to yourself that it's okay that these inconsistencies and this poor design exists on the language, because you've fallen into the trap of becoming a one trick PHP pony and have cornered yourself with nowhere to go. I've yet to meet anyone with a broad amount of experience across multiple languages (and I mean working on multi-year projects with different languages, not just hacking something together for a day) that really believes that PHP is somehow equally as good as everything else - when someone is genuinely experienced enough to be objective, it becomes obvious that PHP is just a poor choice. I know this precisely because I have not just worked on, but led a multi-year PHP project and have worked on multi-year Java, C#, and C++ projects too - I know that PHP is just objectively bad. It didn't stop us delivering on type and on budget, but it did cut our profit margins by about 10 - 15% on the project compared to if we had used C#, Java, or even RoR.

You talk about customers and revenue streams, but that's exactly when PHP's faults matter - what's a customer going to prefer, PHP with it's higher development costs because of the sorts of poor design above requiring greater development effort, greater unit test coverage, and/or greater testing, or the language that doesn't have those problems and lets developers get things done faster because they don't have to deal with them or even a remotely similarly sized amount of equivalent problems as PHP has and still often get a performance boost to boot given how painfully slow PHP is and how terribly it handles threading (meaning it's blocking and limiting requests more than is optimal).

PHP is fine if you want to do a "doesn't matter" hack project quickly and dirtily, but when professionalism and money is involved it's about the worst option going - it's quirks, problems, and low performance add an inherent cost increase to any development done with it. If you don't understand this it's probably because you just don't know any better, as you've proven with having to even ask the question as to what's broken with the PHP type system.

The TCO of PHP is the overriding reason as to why it's a bad choice, and that's why I'm surprised you try and write off it's problems by implying they're not an issue in the real world when money and customers are involved as that's precisely when it's quirks do become a problem. Obviously you've never had any accountability or responsibility for delivering a project with maximised profit margins, maximised customer happiness, and maximised stability, performance and maintainability or you'd know full well that you've spouted an awful lot of nonsense.

Comment: Re:PHP is fine (Score 1) 182

by Xest (#49334503) Attached to: Modern PHP: New Features and Good Practices

"I'm fed up with the equivocation PHP fans trot out whenever any criticism heads their way. Yes, the quality of a language really does have an effect on the quality of the code you write with it. This is plain for anybody to see, and if you don't see the difference in quality, then you should seriously question your competence."

Absolutely and evidence of this is always only a Google search away. Search on how to do something with a database and the results you get are riddled with things like SQL injection vulnerabilities, even when the source of the official documentation.

There's a reason why like 90% of websites that get hacked nowadays are running PHP - because the community is full of people who just don't know why their language is bad, and because they don't know why their language is bad, they definitely don't understand why their own code is bad.

"Now this is a totally brain damaged algorithm. Gag me with a smurfette." -- P. Buhr, Computer Science 354

Working...