It attempts to censor the publication of information relating to but not limited to: software vulnerabilities, exploits, exploitation techniques, hacking tools, attacking public outlets and distribution points of that information. Movement followers have cited websites such as SecurityFocus, Securiteam, PacketStormSecurity, and milw0rm to be targets of their cause, as well as mailing lists like "full-disclosure", "vuln-dev", "vendor-sec" and Bugtraq, as well as public forums and IRC channels.
As recently as 2009, attacks against security communities such as Astalavista[1] and milw0rm,[2] as well as the popular image-host ImageShack[3][4] have given the movement worldwide media attention.
To me, that sounds like a group opposed to computer security. Not only do they seek to stop publication of vulnerability information (which will allow vendors to go back to pretending security is not an issue), they are actually attacking others' systems. Perhaps they claim to be improving computer security, but I don't that's what they are actually accomplishing.
If the version number were 4.0.2 instead of 5.0 Enterprises wouldn't be getting their panties in a bunch over this.
Perhaps. But it isn't 4.0.2, it's 5.0. And 4.x is no longer supported. And the upgrade to 5.0 breaks stuff. This does not paint a picture of a vendor that releases stable software that you can depend on well into the future. Is it any surprise that people aren't happy about this? Is it any surprise that the people who would have to support this software are expressing concern?
Even if there were no technical issues and it were just a matter of the version number getting bumped and the old major version being end-of-lifed, there would be an issue. Version numbers mean something. They are an interface, both to humans and to other software. When you break the semantics of that interface, people get upset, and software that uses the interface fails. Remember the shitstorm that happened when KDE 4 was released? It lasted for years. KDE should have known better than to call it 4.0 when it wasn't intended for end users. Now Mozilla is copying that success. I call that foolhardy.
If UTC would be redefined to no longer be adjusted to Earth's rotation, then what would be the point of having UTC at all? We already have a time scale that counts seconds without adjusting to Earth's rotation: TAI
Can someone who has worked with both comment on how SDL compares to Allegro? I used Allegro a lot back in the day to develop games that would run on DOS and Linux, and I've always been happy with it. SDL, I only have cursory experience with, and I've always found it harder to get up to speed. However, this is a long time ago, and seeing all the attention SDL has been getting, I imagine it would have improved a lot. How do they compare nowadays, in terms of developer effort, run-time efficiency, amount of code you need to install, and platform support?
While we're on the subject, could someone explain what the whole point of EFI is? To me, it has always seemed like Intel's NIH answer to Open Firmware. Why would we prefer EFI over Open Firmware?
Linux will likely wind up having to implement a hack too to fix this, which makes them no better or no worse than the bios manufacturers who did exactly the same thing.
As I understand it, the hack is already implemented (pcie_aspm=force). The good thing about it is that you can enable it when you need it, and not use it when you don't need it. If the same is true of the BIOS manufacturers, then I agree it is no better or worse. However, I suspect that the reason Linux needed to implement a workaround is because there is no way for end-users to make the BIOS do it right. In that case, it is more of an example of how two wrongs (BIOS breaking things to make it work with a broken OS) don't make a right.
Bottom line is I get paid to develop software for Windows, and I can do it quickly, easily, and have a lot of fun doing it, but if I had to use the OS X or Linux tools for developing software, I would probably shoot myself.
Maybe it's just a matter of what you are used to, or personal preference. You claim the Microsoft tools are fantastic and clearly better than those for other platforms. I've heard this from other people, too.
I've also heard people say that the development tools for the Mac are fantastic and the best they've ever used. From the cursory glance I took at Xcode back in the day, I was impressed, but I don't use or develop for Mac OS X, so it wasn't really an option for me.
I've worked with Visual Studio a few times, and I'm always glad when it's over and I can go back to the tools I love (they change, but it's currently Emacs with a read-eval-print-loop for the language I'm developing in, and the Unix shell). I actually once quit from a company that developed using only Microsoft's latest and greatest software, because I couldn't stand it.
Yet other people swear by Java and their favorite IDE (Eclipse/IntelliJ/NetBeans). Personally, I think Java is a huge waste of time. The IDEs are very impressive, and actually manage to make Java pretty usable. Still, I'm happy I don't have to do Java development anymore.
One of my colleagues uses Delphi whenever he can. He has developed a lot of software in his career, and has used a lot of other tools before and after, but he says that, for him, Delphi still works best. He's currently looking at Lazarus, because the Delphi that he loves is no longer developed or maintained.
So, strong opinions abound. Perhaps it's personal preference. Perhaps it's what you're used to. For some people, I strongly suspect that it's simply not knowing anything else. But the fact is: many people feel strongly about the technology they use to build software, and what one person prefers, another person abhors.
Cross-platform? Lol... just when I think I've heard it all. I wonder what kind of idiotic apps manager would say - Hmmm we need an application that runs on Windows, Mac and Linux. What tools should we use? - I know - three development teams developing completely separate apps using completely separate languages and tool chains!!! Brilliant!
You laugh, but there are people who claim this is actually the way to go, at least for the user interface. Their argument is that you can never really get the user interface to feel right for the platform, unless you use the tools for that platform.
Since I don't do any GUI development other than in web pages, I don't know if they are right. I just wanted to point it out.
I'm happy to report that read(2), write(2), and all the other syscalls that make up POSIX, and its derivatives, still work the same as they did decades ago.
Great, so it's dead too since it hasn't changed for decades?
Why would you think that? We still have files with bytes in them, pipes, sockets, and all the other things these system calls work on. And since we're still working with the same concepts, and we have a good API for them, why would we want to change the API?
Same as with COM, there's nothing stopping you from using it and it still works the same as it did many years ago. You can still use all the old technologies and they still all work just the same as they used to.
That may be true for COM, but is the same true for ActiveX, VBA, or DirectX? I've worked on an app for a mobile device that was developed in Visual Studio 2008, that would compile in no other version of Visual Studio. Apparently, Microsoft introduced APIs in one version of their flagship development environment and removed them in the next.
I am not saying everything is doom and gloom with Microsoft, but they certainly do kill off support for some of their previously promoted APIs sometimes. To avoid any misunderstandings: I am not saying this is a bad thing, just that it happens.
I think we can all agree there is still plenty of irrationality, prejudice, and discrimination against groups in politics.
Actually, people seem to oppose Christians, Muslims, or atheists, Republicans or Democrats, people who have committed victimless crimes, homosexuals, or women - I guess it's hard these days to _not_ be discriminated against.
I feel the discussion about garbage collection has been held a few tens of thousands of times now, and I find your suggestion that people want a garbage collector so they can get away with sloppy code offensive.
For those who don't know, there are good reasons to have automatic memory management, and most of the arguments against it (e.g. performance, predictable timing) are bogus (automatic memory management is not necessarily more or less performant or predictable than manual memory management). Here are some good reasons to have automatic memory management:
1. Cleaner interfaces. Interfaces to library code often become more elegant and easier to use when you don't have to specify who owns allocated memory.
2. Memory safety. Operations like free in C and delete in C++ break memory safety, because after performing them, the pointer they operated on should not be used anymore, but still can. By contrast, a garbage collector will only reclaim memory after it is no longer referenced, so references that do exist are always valid.
3. Rapid development. Compared to manual memory management, automatic memory management can be expected to lead to less time spent writing code to manage memory, less time needed to think about where it should go, and less time finding and fixing bugs that are bound to crop up.
For an example of how automatic memory management leads to cleaner interfaces, consider a function foo that returns a list of items in some undefined order. You want to present the items to the user in some specific order. If you have automatic memory management, you could write something along the lines of
sort(foo(), [x,y]{/* your sorting code here */})
Without automatic memory management, this would leak both the list returned by foo and the closure used for sorting. So it would more likely become something like
int sorting_predicate(T x, T y) {/* your sorting code here */ } list<T> temp_list = foo(); list<T> result_list = sort(temp_list, sorting_predicate); free_list(temp_list);
Iâ(TM)m excited to announce that we are introducing a new technology that helps C++ developers use the GPU for parallel programming. Today at the AMD Fusion Developer Summit, we announced C++ Accelerated Massive Parallelism (C++ AMP). (â¦) By building on the Windows DirectX platform, our implementation of C++ AMP allows you to target hardware from all the major hardware vendors. (â¦)
So, from a cursory look, this seems to be similar in purpose to OpenCL.
A slower language just means you need to buy more rack space. A more expensive development language (like C++, which needs more skilled coders, more debug time, etc.), means that you need to buy more developer man-hours.
Actually, either of those may be your best option, depending on the parameters.
If a few hundred or thousand dollars gets you hardware that makes your software fast enough, that's probably cheaper than developing for optimal performance.
If you operate at the scale Google does, the extra expense of letting developers squeeze as much performance as possible from the hardware may well be worth it - imagine cutting your hardware requirements, and the size of the army required to maintain all that hardware, in half.
In some cases, optimizing for run-time performance is your only option, because throwing extra hardware at the problem simply won't get you there. I've been in this position before. This is also where I learned that, while picking a better language implementation certainly helps, doing your requirements analysis and architecture right can improve things by multiple orders of magnitude, or take you from impossible to possible.
Finally, you need to consider the impact the run-time has on the users, and who the users are. If you are one of the users, you may well benefit from faster software, even if it costs more to develop.
You are right that, in many cases, run-time performance of the software isn't very important - but those are not the interesting cases. The reason you would measure performance across languages at all is that you care about the cases where this performance matters.
No, they didn't. They compared four languages (C++, Go, Java and Scala) using a single algorithm, and two implementations (initial and improved) per language. Out of those, the optimized C++ turned out to be the fastest and the least memory hungry, whereas the improved Scala version used the least source code, and the improved Go version compiled the fastest.
None of this allows generalization to "best-performing programming language on the market".
It's not for everyone, though. They write, '...it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer.'
This is a very important point. If you are Google, you probably have developers who can do this kind of tuning, and you will probably benefit from it (the developer effort is expensive, but inefficient software may well be more expensive at Google's scale).
In general, though, what you want to consider is not only the best performance that has been produced by the world on a single problem, but also the performance on different problems, the variation in performance between implementations, the average performance, and the development time.
In 2000, Erann Gatt (now Ron Garret) published a paper (PDF) that showed the results of comparing 16 implementations written by 14 programmers, in C or C++ (lumped together), Java, and Common Lisp or Scheme (lumped together). These results show that the fastest programs were written in C or C++, Lisp produced the fastest programs on average, and offered the least variation in performance. Lisp also offered the shortest development time on average.
Of course, this is old data. If anyone has performed a similar study more recently, or including different problems to be solved rather than a single one, I would be very interested.
Meanwhile, the Computer Language Benchmarks Game compares many language implementations across several different tasks, with multiple programs for each task, and shows that the results differ depending on exactly how you measure.
Apparently, if you want the fastest programs, you should go with C, C++, Ada, ATS (Fortran, Common Lisp, and Python also produced fast programs, but weren't as good on average). If you want short programs (which may be expected to correlate with short development time), you might want to go with Ruby, Python, Perl, Lua, or JavaScript. If you want short development time, but also reasonable performance, then Go, Scala, or Haskell may be good choices (or you could go the time-tested route of writing what you can in rapid development languages, and the parts that need to be fast in high-performance languages).
Actually, I am rather happy that the break-ins are being reported. LulzSec is going after high-profile targets, and succeeding. This is a wake-up call for the world: these are targets who should know they are targets, and they're falling to the attacks. We need better security!
Thanks for providing some perspective. It is good to hear observations and opinions that may not align with the views most commonly expressed here.
Still, there are a lot of things in your post that I don't really understand.
I know Silverlight is a running joke on/., and everyone here hates it
Is that so? I thought that Silverlight was just another technology, to be discussed and evaluated like any other. It has its merits, and I have seen several people speak favorably about it on Slashdot.
but I work at a.NET shop and we used Silverlight to create a product. Now, you may think that's insane, but what we wanted to deliver was a very rich user experience over the web that was cross platform.
There are several things here that irk me. I don't think it's insane that a.NET shop would use Silverlight. I mean, if you're already committed to one, it's easy to use the other, right?
What bothers me, though, is the concept of a ".NET shop". So, there is this company that has decided that.NET is going to be their answer to every question they encounter. I know that there are many companies that make this choice, or the same choice, but for a different technology (e.g. Java). But what happened to using the best tool for the job? There is a lot of impressive technology in.NET, but is it really the best tool for every job, now and in the future? In my view, it isn't, and can't be. So I would have my developers learn several technologies, and chose the best one for each project. Any developer worth their salt should have no problem with that, IMO.
Next, the idea that Silverlight was a good choice to deliver a very rich user experience over the web that was cross platform. It may technically be possible (I haven't looked at Silverlight hard enough to know), but the idea that this would be cross-platform is simply wrong. If anyone had seriously looked at it, they would have realized that Silverlight only really works under Windows. Yes, I know about Moonlight, but simply reading the WikiPedia article about it will tell you that what works under Silverlight will not necessarily also work under Moonlight. I am not going to speculate as to why people at your company may have thought Silverlight was cross-platform, but I am going to say that it was the wrong tool for the goal you stated, and someone should have realized this and spoken up. You may deride Slashdot's groupthink, but at least we do get dissenting posts, and they do get modded up, too.
As well, the decision on technology was made over 2 years ago, and back then HTML5 was but a whisper, and Flash was still the big thing TM for interactive "web applications."
I don't think HTML5 would have been a good choice, either, so I am glad to hear you didn't go that route. However, I wonder why you didn't go with Flash, given that, in your own words, it was the big thing TM for interactive "web applications" at the time. It also has a much better track record than Silverlight as far as support for multiple platforms is concerned. So why didn't you go with Flash? Also, since you mentioned HTML5, did you consider using DHTML (AKA AJAX)?
As I said, since we're a.NET shop, Silverlight was a really great alternative to Flash.
Well, opinions seem to differ about that. I think that if you had already decided on.NET, then Silverlight could have been a better choice than Flash (after all, you can write your code for Silverlight in a.NET language). However, if you had put the requirements first, instead of the technology choice, and your requirements included "cross-platform", then I question whether Silverlight would have been the better, or even a good choice.
Anyone have a copy of the first Macintosh OS they want to send me?
You could try contacting Apple. I know they offer versions of System 7 for download; perhaps they will also provide the original if you ask. I think you will also need a compatible Macintosh ROM to be able to actually run it.
Good luck, and have fun. I've always been impressed with what these programmers of yore managed to accomplish. Imagine, an operating system with a GUI, and applications for image processing and word processing, in 128KB of RAM!
Really if you are running a virus scanner on any *nix machine, you're either doing it on behalf of Windows systems (i.e. on a *nix mailserver that has Windows clients) or you're doing something wrong.
I'm not so sure about that. There seems to be a persistent idea that *nix is somehow secure, but that is not actually true. There have been vulnerabilities and exploits for *nix, and I have seen a number of compromised Linux installations. OpenBSD seems to be one of the few operating system projects taking security as seriously as I think they should, but even they have had vulnerabilities in the core system, not to mention vulnerabilities in the applications people run on it. And let's not forget that most of it is written in C, a language known to be full of opportunities for creating vulnerabilities.
Now, I am not claiming that running a virus scanner would be a good idea. It will use up computer resources, but will it actually stop the attacks? However, I think we in the *nix world should work a lot harder to secure our systems than most of us currently do. To give you something to think about: Windows has had ASLR and NX enabled for core parts of the system for a few releases now. Many popular Linux distros don't enable either feature for any software. Also, Linux (the kernel) is huge. What protections does your favorite distro offer against bugs and exploits in code that runs in kernel space?
Oh and if you were really so paranoid you'd be using Chromium, not Chrome.
Calling computer security-minded people paranoid would be funny if it weren't so sad. The truth is that the Internet is full of automatic exploits and there is a large industry built on exploiting software (of which the exploit this story is about is an example). Too many people think they have nothing to fear, while, in reality, governments, script kiddies, and professional criminals are all out to get you. Maybe not you personally, but they will welcome the addition of your computer to their botnet or database, regardless of who you are. Good computer security isn't paranoia, it's protection against the very real possibility that your computer will be used to send spam, participate in denial of service attacks, various criminal activities, or simply to gather information about you and your friends, relatives, and acquaintances.
If you don't see computer security as a big deal, perhaps it would help to imagine what your inbox would look like if there was no spam filtering (spam comprises the majority of all email, and the bulk of email spam is sent from exploited computers), or you can speak to any of the people whose personal data have been used to take out loans or commit criminal activities in their name. I hope that you will never experience anything like that first-hand, but you should know that, if you aren't vigilant about computer security, you may unknowingly be facilitating these things.
I've long been thinking about using or creating and using a real-time language for user interfaces. What I have in mind is a language where you can specify time constraints as part of the contract for functions, and the compiler will then enforce those by refusing to emit code if that code would take longer to run than permitted by the time constraints.
Obviously, there are some hurdles here: not every computer is equally fast, many operating systems introduce unpredictable timing, and so on, but I think it would be interesting to at least see how close we could get. I really think the user experience would be much better if at least the user interface always responded quickly to user input.
I used to use Konqueror 3.x on a 200 MHz Pentium with 96 MB RAM. It was the only graphical browser that both had good support for the Web at the time (HTML4, JavaScript (including AJAX), Flash and other plug-ins, tabbed browsing) and that would allow me to have multiple tabs open and still have the browser respond immediately to mouse clicks.
On top of that, those versions of Konqueror have some nice features that weren't common at the time, such as access keys (press control, then a letter to follow a link) and web shortcuts (type a short keyword and some search terms in your address bar, and you could search the web using your favorite search engine, Wikipedia, or whatever else you would add). Konqueror is a very nice browser even if your machine isn't resource-constrained.
I haven't used the post-3.x versions of Konqueror, but I've always enjoyed 3.x. About the only annoyance is that a number of "Web 2.0" sites don't work with Konqueror, or require tweaks. Support has improved with the increasing popularity of WebKit (which originated with Konqueror as KHTML, but is now used with Safari, Chromium, Chrome, and several other browsers), and most sites will actually work if you set the browser identification to some more popular browser (e.g. Opera, Safari, or Firefox).
If you are willing to use closed-source software, Opera is a very good browser. I don't know about the resource usage of their newer releases, but they are known for packing an amazingly good feature set in a small package. Same as with Konqueror, though, you may need to set the browser identification to some other browser to get certain websites to work with it. Opera makes this very easy to do.
Speaking of grassroots chip design, what is happening with HDCaml these days? I thought the idea was pretty neat when I first heard of it (a hardware design language that is nicer to work with than VHDL and Verilog!), but is anybody actually working with or on it? Or any other improvements on the established languages?
It's not that we can't, we just haven't. Perhaps there isn't enough interest. Speaking for myself, I designed a CPU once, and concluded it wasn't for me. I'm a software guy.
If you want open source 64-bit CPUs with built-in GPUs, by all means go and start the project. It will work if the necessary effort is put in, and it won't have to be all your effort if you can motivate others to help out.
Slashdot Mirror
In the Wikipedia article on Antisec, it says:
To me, that sounds like a group opposed to computer security. Not only do they seek to stop publication of vulnerability information (which will allow vendors to go back to pretending security is not an issue), they are actually attacking others' systems. Perhaps they claim to be improving computer security, but I don't that's what they are actually accomplishing.
WTF? A group actually opposed to computer security, and they are picking up steam? What ... is the rationale behind this?
Perhaps. But it isn't 4.0.2, it's 5.0. And 4.x is no longer supported. And the upgrade to 5.0 breaks stuff. This does not paint a picture of a vendor that releases stable software that you can depend on well into the future. Is it any surprise that people aren't happy about this? Is it any surprise that the people who would have to support this software are expressing concern?
Even if there were no technical issues and it were just a matter of the version number getting bumped and the old major version being end-of-lifed, there would be an issue. Version numbers mean something. They are an interface, both to humans and to other software. When you break the semantics of that interface, people get upset, and software that uses the interface fails. Remember the shitstorm that happened when KDE 4 was released? It lasted for years. KDE should have known better than to call it 4.0 when it wasn't intended for end users. Now Mozilla is copying that success. I call that foolhardy.
If UTC would be redefined to no longer be adjusted to Earth's rotation, then what would be the point of having UTC at all? We already have a time scale that counts seconds without adjusting to Earth's rotation: TAI
Can someone who has worked with both comment on how SDL compares to Allegro? I used Allegro a lot back in the day to develop games that would run on DOS and Linux, and I've always been happy with it. SDL, I only have cursory experience with, and I've always found it harder to get up to speed. However, this is a long time ago, and seeing all the attention SDL has been getting, I imagine it would have improved a lot. How do they compare nowadays, in terms of developer effort, run-time efficiency, amount of code you need to install, and platform support?
While we're on the subject, could someone explain what the whole point of EFI is? To me, it has always seemed like Intel's NIH answer to Open Firmware. Why would we prefer EFI over Open Firmware?
As I understand it, the hack is already implemented (pcie_aspm=force). The good thing about it is that you can enable it when you need it, and not use it when you don't need it. If the same is true of the BIOS manufacturers, then I agree it is no better or worse. However, I suspect that the reason Linux needed to implement a workaround is because there is no way for end-users to make the BIOS do it right. In that case, it is more of an example of how two wrongs (BIOS breaking things to make it work with a broken OS) don't make a right.
Maybe it's just a matter of what you are used to, or personal preference. You claim the Microsoft tools are fantastic and clearly better than those for other platforms. I've heard this from other people, too.
I've also heard people say that the development tools for the Mac are fantastic and the best they've ever used. From the cursory glance I took at Xcode back in the day, I was impressed, but I don't use or develop for Mac OS X, so it wasn't really an option for me.
I've worked with Visual Studio a few times, and I'm always glad when it's over and I can go back to the tools I love (they change, but it's currently Emacs with a read-eval-print-loop for the language I'm developing in, and the Unix shell). I actually once quit from a company that developed using only Microsoft's latest and greatest software, because I couldn't stand it.
Yet other people swear by Java and their favorite IDE (Eclipse/IntelliJ/NetBeans). Personally, I think Java is a huge waste of time. The IDEs are very impressive, and actually manage to make Java pretty usable. Still, I'm happy I don't have to do Java development anymore.
One of my colleagues uses Delphi whenever he can. He has developed a lot of software in his career, and has used a lot of other tools before and after, but he says that, for him, Delphi still works best. He's currently looking at Lazarus, because the Delphi that he loves is no longer developed or maintained.
So, strong opinions abound. Perhaps it's personal preference. Perhaps it's what you're used to. For some people, I strongly suspect that it's simply not knowing anything else. But the fact is: many people feel strongly about the technology they use to build software, and what one person prefers, another person abhors.
You laugh, but there are people who claim this is actually the way to go, at least for the user interface. Their argument is that you can never really get the user interface to feel right for the platform, unless you use the tools for that platform.
Since I don't do any GUI development other than in web pages, I don't know if they are right. I just wanted to point it out.
Why would you think that? We still have files with bytes in them, pipes, sockets, and all the other things these system calls work on. And since we're still working with the same concepts, and we have a good API for them, why would we want to change the API?
That may be true for COM, but is the same true for ActiveX, VBA, or DirectX? I've worked on an app for a mobile device that was developed in Visual Studio 2008, that would compile in no other version of Visual Studio. Apparently, Microsoft introduced APIs in one version of their flagship development environment and removed them in the next.
I am not saying everything is doom and gloom with Microsoft, but they certainly do kill off support for some of their previously promoted APIs sometimes. To avoid any misunderstandings: I am not saying this is a bad thing, just that it happens.
I think we can all agree there is still plenty of irrationality, prejudice, and discrimination against groups in politics.
Actually, people seem to oppose Christians, Muslims, or atheists, Republicans or Democrats, people who have committed victimless crimes, homosexuals, or women - I guess it's hard these days to _not_ be discriminated against.
I feel the discussion about garbage collection has been held a few tens of thousands of times now, and I find your suggestion that people want a garbage collector so they can get away with sloppy code offensive.
For those who don't know, there are good reasons to have automatic memory management, and most of the arguments against it (e.g. performance, predictable timing) are bogus (automatic memory management is not necessarily more or less performant or predictable than manual memory management). Here are some good reasons to have automatic memory management:
1. Cleaner interfaces. Interfaces to library code often become more elegant and easier to use when you don't have to specify who owns allocated memory.
2. Memory safety. Operations like free in C and delete in C++ break memory safety, because after performing them, the pointer they operated on should not be used anymore, but still can. By contrast, a garbage collector will only reclaim memory after it is no longer referenced, so references that do exist are always valid.
3. Rapid development. Compared to manual memory management, automatic memory management can be expected to lead to less time spent writing code to manage memory, less time needed to think about where it should go, and less time finding and fixing bugs that are bound to crop up.
For an example of how automatic memory management leads to cleaner interfaces, consider a function foo that returns a list of items in some undefined order. You want to present the items to the user in some specific order. If you have automatic memory management, you could write something along the lines of
Without automatic memory management, this would leak both the list returned by foo and the closure used for sorting. So it would more likely become something like
Can't speak for others, but in my case it's
Don't know what AMP is and can't understand TFS/TFA
Neither the summary nor the article seem to explain what AMP is.
For the benefit of everyone else who is trying to figure out, here is a link: Introducing C++ Accelerated Massive Parallelism (C++ AMP) To quote from that page:
So, from a cursory look, this seems to be similar in purpose to OpenCL.
A slower language just means you need to buy more rack space. A more expensive development language (like C++, which needs more skilled coders, more debug time, etc.), means that you need to buy more developer man-hours.
Actually, either of those may be your best option, depending on the parameters.
If a few hundred or thousand dollars gets you hardware that makes your software fast enough, that's probably cheaper than developing for optimal performance.
If you operate at the scale Google does, the extra expense of letting developers squeeze as much performance as possible from the hardware may well be worth it - imagine cutting your hardware requirements, and the size of the army required to maintain all that hardware, in half.
In some cases, optimizing for run-time performance is your only option, because throwing extra hardware at the problem simply won't get you there. I've been in this position before. This is also where I learned that, while picking a better language implementation certainly helps, doing your requirements analysis and architecture right can improve things by multiple orders of magnitude, or take you from impossible to possible.
Finally, you need to consider the impact the run-time has on the users, and who the users are. If you are one of the users, you may well benefit from faster software, even if it costs more to develop.
You are right that, in many cases, run-time performance of the software isn't very important - but those are not the interesting cases. The reason you would measure performance across languages at all is that you care about the cases where this performance matters.
Google has released a research paper (PDF) that suggests C++ is the best-performing language on the market.
No, they didn't. They compared four languages (C++, Go, Java and Scala) using a single algorithm, and two implementations (initial and improved) per language. Out of those, the optimized C++ turned out to be the fastest and the least memory hungry, whereas the improved Scala version used the least source code, and the improved Go version compiled the fastest.
None of this allows generalization to "best-performing programming language on the market".
It's not for everyone, though. They write, '...it also required the most extensive tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer.'
This is a very important point. If you are Google, you probably have developers who can do this kind of tuning, and you will probably benefit from it (the developer effort is expensive, but inefficient software may well be more expensive at Google's scale).
In general, though, what you want to consider is not only the best performance that has been produced by the world on a single problem, but also the performance on different problems, the variation in performance between implementations, the average performance, and the development time.
In 2000, Erann Gatt (now Ron Garret) published a paper (PDF) that showed the results of comparing 16 implementations written by 14 programmers, in C or C++ (lumped together), Java, and Common Lisp or Scheme (lumped together). These results show that the fastest programs were written in C or C++, Lisp produced the fastest programs on average, and offered the least variation in performance. Lisp also offered the shortest development time on average.
Of course, this is old data. If anyone has performed a similar study more recently, or including different problems to be solved rather than a single one, I would be very interested.
Meanwhile, the Computer Language Benchmarks Game compares many language implementations across several different tasks, with multiple programs for each task, and shows that the results differ depending on exactly how you measure.
Apparently, if you want the fastest programs, you should go with C, C++, Ada, ATS (Fortran, Common Lisp, and Python also produced fast programs, but weren't as good on average). If you want short programs (which may be expected to correlate with short development time), you might want to go with Ruby, Python, Perl, Lua, or JavaScript. If you want short development time, but also reasonable performance, then Go, Scala, or Haskell may be good choices (or you could go the time-tested route of writing what you can in rapid development languages, and the parts that need to be fast in high-performance languages).
Actually, I am rather happy that the break-ins are being reported. LulzSec is going after high-profile targets, and succeeding. This is a wake-up call for the world: these are targets who should know they are targets, and they're falling to the attacks. We need better security!
Ah, I didn't know Silverlight worked well on the Mac. Thanks for pointing that out!
Thanks for providing some perspective. It is good to hear observations and opinions that may not align with the views most commonly expressed here.
Still, there are a lot of things in your post that I don't really understand.
I know Silverlight is a running joke on /., and everyone here hates it
Is that so? I thought that Silverlight was just another technology, to be discussed and evaluated like any other. It has its merits, and I have seen several people speak favorably about it on Slashdot.
but I work at a .NET shop and we used Silverlight to create a product. Now, you may think that's insane, but what we wanted to deliver was a very rich user experience over the web that was cross platform.
There are several things here that irk me. I don't think it's insane that a .NET shop would use Silverlight. I mean, if you're already committed to one, it's easy to use the other, right?
What bothers me, though, is the concept of a ".NET shop". So, there is this company that has decided that .NET is going to be their answer to every question they encounter. I know that there are many companies that make this choice, or the same choice, but for a different technology (e.g. Java). But what happened to using the best tool for the job? There is a lot of impressive technology in .NET, but is it really the best tool for every job, now and in the future? In my view, it isn't, and can't be. So I would have my developers learn several technologies, and chose the best one for each project. Any developer worth their salt should have no problem with that, IMO.
Next, the idea that Silverlight was a good choice to deliver a very rich user experience over the web that was cross platform. It may technically be possible (I haven't looked at Silverlight hard enough to know), but the idea that this would be cross-platform is simply wrong. If anyone had seriously looked at it, they would have realized that Silverlight only really works under Windows. Yes, I know about Moonlight, but simply reading the WikiPedia article about it will tell you that what works under Silverlight will not necessarily also work under Moonlight. I am not going to speculate as to why people at your company may have thought Silverlight was cross-platform, but I am going to say that it was the wrong tool for the goal you stated, and someone should have realized this and spoken up. You may deride Slashdot's groupthink, but at least we do get dissenting posts, and they do get modded up, too.
As well, the decision on technology was made over 2 years ago, and back then HTML5 was but a whisper, and Flash was still the big thing TM for interactive "web applications."
I don't think HTML5 would have been a good choice, either, so I am glad to hear you didn't go that route. However, I wonder why you didn't go with Flash, given that, in your own words, it was the big thing TM for interactive "web applications" at the time. It also has a much better track record than Silverlight as far as support for multiple platforms is concerned. So why didn't you go with Flash? Also, since you mentioned HTML5, did you consider using DHTML (AKA AJAX)?
As I said, since we're a .NET shop, Silverlight was a really great alternative to Flash.
Well, opinions seem to differ about that. I think that if you had already decided on .NET, then Silverlight could have been a better choice than Flash (after all, you can write your code for Silverlight in a .NET language). However, if you had put the requirements first, instead of the technology choice, and your requirements included "cross-platform", then I question whether Silverlight would have been the better, or even a good choice.
Furthermore, if you
Anyone have a copy of the first Macintosh OS they want to send me?
You could try contacting Apple. I know they offer versions of System 7 for download; perhaps they will also provide the original if you ask. I think you will also need a compatible Macintosh ROM to be able to actually run it.
Good luck, and have fun. I've always been impressed with what these programmers of yore managed to accomplish. Imagine, an operating system with a GUI, and applications for image processing and word processing, in 128KB of RAM!
We just one of the lower bounds in the Drake Equation.
And accidentally, too!
But seriously, insightful post.
Really if you are running a virus scanner on any *nix machine, you're either doing it on behalf of Windows systems (i.e. on a *nix mailserver that has Windows clients) or you're doing something wrong.
I'm not so sure about that. There seems to be a persistent idea that *nix is somehow secure, but that is not actually true. There have been vulnerabilities and exploits for *nix, and I have seen a number of compromised Linux installations. OpenBSD seems to be one of the few operating system projects taking security as seriously as I think they should, but even they have had vulnerabilities in the core system, not to mention vulnerabilities in the applications people run on it. And let's not forget that most of it is written in C, a language known to be full of opportunities for creating vulnerabilities.
Now, I am not claiming that running a virus scanner would be a good idea. It will use up computer resources, but will it actually stop the attacks? However, I think we in the *nix world should work a lot harder to secure our systems than most of us currently do. To give you something to think about: Windows has had ASLR and NX enabled for core parts of the system for a few releases now. Many popular Linux distros don't enable either feature for any software. Also, Linux (the kernel) is huge. What protections does your favorite distro offer against bugs and exploits in code that runs in kernel space?
Oh and if you were really so paranoid you'd be using Chromium, not Chrome.
Calling computer security-minded people paranoid would be funny if it weren't so sad. The truth is that the Internet is full of automatic exploits and there is a large industry built on exploiting software (of which the exploit this story is about is an example). Too many people think they have nothing to fear, while, in reality, governments, script kiddies, and professional criminals are all out to get you. Maybe not you personally, but they will welcome the addition of your computer to their botnet or database, regardless of who you are. Good computer security isn't paranoia, it's protection against the very real possibility that your computer will be used to send spam, participate in denial of service attacks, various criminal activities, or simply to gather information about you and your friends, relatives, and acquaintances.
If you don't see computer security as a big deal, perhaps it would help to imagine what your inbox would look like if there was no spam filtering (spam comprises the majority of all email, and the bulk of email spam is sent from exploited computers), or you can speak to any of the people whose personal data have been used to take out loans or commit criminal activities in their name. I hope that you will never experience anything like that first-hand, but you should know that, if you aren't vigilant about computer security, you may unknowingly be facilitating these things.
I've long been thinking about using or creating and using a real-time language for user interfaces. What I have in mind is a language where you can specify time constraints as part of the contract for functions, and the compiler will then enforce those by refusing to emit code if that code would take longer to run than permitted by the time constraints.
Obviously, there are some hurdles here: not every computer is equally fast, many operating systems introduce unpredictable timing, and so on, but I think it would be interesting to at least see how close we could get. I really think the user experience would be much better if at least the user interface always responded quickly to user input.
I used to use Konqueror 3.x on a 200 MHz Pentium with 96 MB RAM. It was the only graphical browser that both had good support for the Web at the time (HTML4, JavaScript (including AJAX), Flash and other plug-ins, tabbed browsing) and that would allow me to have multiple tabs open and still have the browser respond immediately to mouse clicks.
On top of that, those versions of Konqueror have some nice features that weren't common at the time, such as access keys (press control, then a letter to follow a link) and web shortcuts (type a short keyword and some search terms in your address bar, and you could search the web using your favorite search engine, Wikipedia, or whatever else you would add). Konqueror is a very nice browser even if your machine isn't resource-constrained.
I haven't used the post-3.x versions of Konqueror, but I've always enjoyed 3.x. About the only annoyance is that a number of "Web 2.0" sites don't work with Konqueror, or require tweaks. Support has improved with the increasing popularity of WebKit (which originated with Konqueror as KHTML, but is now used with Safari, Chromium, Chrome, and several other browsers), and most sites will actually work if you set the browser identification to some more popular browser (e.g. Opera, Safari, or Firefox).
If you are willing to use closed-source software, Opera is a very good browser. I don't know about the resource usage of their newer releases, but they are known for packing an amazingly good feature set in a small package. Same as with Konqueror, though, you may need to set the browser identification to some other browser to get certain websites to work with it. Opera makes this very easy to do.
Speaking of grassroots chip design, what is happening with HDCaml these days? I thought the idea was pretty neat when I first heard of it (a hardware design language that is nicer to work with than VHDL and Verilog!), but is anybody actually working with or on it? Or any other improvements on the established languages?
Why can't the opensource community ...
It's not that we can't, we just haven't. Perhaps there isn't enough interest. Speaking for myself, I designed a CPU once, and concluded it wasn't for me. I'm a software guy.
If you want open source 64-bit CPUs with built-in GPUs, by all means go and start the project. It will work if the necessary effort is put in, and it won't have to be all your effort if you can motivate others to help out.