I'd like to see the Documentation, Community and News content on the front page, rather than hidden away on those separate pages. The new design adds an extra, unnecessary level of indirection in order to get to this useful information.
885 karma · joined December 29, 2013
As an occasional Haskell user, I'm served much, much better by the existing site than by this new design. The existing one lets me get to the information I'm looking for with minimal effort. This new site denies me that accessibility, I'm afraid to say.
I don't see the point in trying to attract new users if doing so also means harming the experiences of established users. Drawing in new users becomes pointless if retention starts to suffer.
The existing design seems to do a good job of using the space available to convey a large amount of important and relevant information, with very little effort required from the viewer.
For example, a viewer of the existing site can quickly get to various types of documentation right away, without having to click on a link to visit a dedicated "Documentation" page, like with the new design. The same goes for news and community details, as well. An inefficient, unnecessary extra link click or press is now needed to get to very core information.
It isn't worth making an informational website look "pretty" if that means ruining its ability to effectively convey information.
Viewing the existing site in a desktop browser, I get to see the description of Haskell, and a bunch of useful links about learning it, downloading an implementation, using it, and participating in the community. Recent news items and upcoming events are also visible, as is the search field.
This new design lacks pretty much all of that. Instead of useful content, links and functionality, all I'm seeing are large areas of purple and white, and an extremely blurry photo, along with content of very limited value.
I just can't see this new design being beneficial in any way. It makes it much harder to get useful information about Haskell, which seems very contradictory to what a website like this should be doing.
And pointing out such flaws in somebody's work is not a criticism of the person. Nor is it an "attack" on somebody to request that they have their house in order before trying to put the houses of others in order.
On the other hand, GNOME 3 was a debacle, without any doubt. KDE 4 resulted in nowhere near the level of backlash and response that GNOME 3 did. I mean, GNOME 3 was and is so bad that it spawned two rather significant and ongoing salvage attempts in MATE and Cinnamon, in addition to completely driving away a lot of existing users. We just didn't see anything close to that with KDE 4.
So I'd be very, very hesitant to make a claim like "It's likely 1/3 of the world's population won't be meaningful consumers in this century."
It's also important to remember that Java is still in this position even after almost 20 years of development. And this is development undertaken by large companies that were or are quite well funded, and have had very talented individuals work on this technology.
If they've yet to get consistent C++-level performance out of Java or the JVM, it's most likely factors inherent to those technologies that are to blame.
Why should I wastefully send unneeded markup that inflates the size of my email several times larger than what's actually needed?
"Cross platform" means supporting all of the widely-used platforms at a given point in time, and supporting them well. Today, that includes at least Windows, OS X, and Linux. Some would even extend that to include the BSDs, Solaris, AIX and HP-UX.
Like others have pointed out, GTK+'s support for OS X and Windows has been very, very lacking. It's nowhere near as seamless as that offered by Qt, Swing, or SWT.
It is the defaults that matter. They're what give a particular distribution its unique characteristics.
Sure, you can go out of your way to install the software necessary to make one distribution comparable to some other distribution, but that doesn't mean they're really the same to begin with, even if their names may be similar.
Let's ignore the fact that it's a trivially small example to begin with. I don't think it's very representative of larger apps, especially ones that are far more complex than a very simplistic blog system.
And let's ignore the fact that the SQL-based one is around 10% shorter than the MongoDB one, too, in terms of their line counts.
The SQL-based one makes the queries very clearly visible. It's easier to find the queries, and for anyone who knows SQL it's very clear at a quick glance what they're doing. It's much harder to isolate the queries in the MongoDB one. The visibility of the SQL queries makes maintenance easier, and performance tuning easier.
And I don't buy the dynamic query argument. Those are often the most fragile ones used, and should generally be avoided, if possible. It's better to have two or more similar queries than it is one that's built dynamically. Even then, it's often possible to write a single query with more complex filtering that can handle numerous very different cases.
At best, the MongoDB example is roughly equivalent to the SQL one. In practice, you're trading off a huge number of benefits of relational databases (SQL usually being one of them) for little to no gain when opting for MongoDB instead.
There's no emotion involved, in fact.
It's about rationally looking at a given tool, considering its capabilities, considering how it can be beneficial and harmful in a given situation, and considering how it compares to similar other tools.
Sometimes this analysis is in favor of a given tool. PostgreSQL is a good example of this. It excels in many different ways, including some that overlap with MongoDB and other so-called NoSQL databases.
Sometimes this analysis is not in favor of a given tool. MongoDB is a good example of this. It has some pretty serious issues, and there are often better alternatives.
When people suggest to not use MongoDB, it's generally not some emotional response due to "hate". It's usually because they've considered what it can do and how it works, and it turns out that in pretty much all cases there is a better alternative available that should be used instead.
A given channel, or even entire networks, would often start out pretty free. Dissenting discussion and arguments were allowed, if not encouraged. Users could hold and share their own beliefs without fear of repercussion. It was generally a fun experience. The channel or network would see growth.
But as the community became larger and more established, certain users would often end up becoming ops, and they'd start to enforce their own beliefs upon the entire community. People would start getting kicked or banned unnecessarily for very minor "violations", which most often involved just holding a different opinion than an op.
These kicked or banned users wouldn't come back, those users who liked them would have less incentive to return, and eventually there'd be more people getting booted or leaving than there would be new people coming and returning. The channel withers. If this happens with enough channels, the network withers. As networks wither, IRC itself withers.
I've personally worked with some brilliant embedded software developers and compiler writers who likely wouldn't know what a robots.txt file is, because they've focused their skills and talents elsewhere. Despite not knowing what a robots.txt file is, they're still far more technically capable than even the best web developers I've ever encountered.
PostgreSQL itself isn't responsible or affected, contrary to what the "Vulnerabilities Affecting PostgreSQL" phrasing suggests at a glance.
Short-term and long-term stability are needed for just about any serious software application or system. They're useful to have even for short scripts that might be reused later on.
And he said he was "terrified" by C++. I explained why he shouldn't be. I'm not sure why you're getting worked up over that.
C++ gives you immense power and a huge range of functionality to choose from, and some of the complexity arises from this. It has a very long history, which also contributes to the complexity. And it's first and foremost a pragmatic language, which of course brings in some complexity in order to deal with the inherent complexity of reality.
If something is seen as "complex" in C++, there's usually a good, or at least understandable, reason for this. You can usually find technical documents or discussion that justify why things are they way that they are, and the reasoning is usually quite sound. And in many cases, it's possible to safely ignore or just not use large portions of the complexity that C++ offers without facing any sort of a penalty or harm.
It's very different from the complexity that languages like JavaScript or PHP bring. The complexity there is usually unjustifiable, and often due to very rushed work, a lack of understanding and poor design, or a lack of care and consistency. They suffer from serious flaws and complexity that were not justified when introduced, and were subsequently not cleaned up or fixed once recognized. They suffer from harmful complexity, while C++ offers beneficial complexity.
Going to individual academic institutions may be one way, but this would also be quite localized, and hard to scale. It also misses intelligent people who are unable to afford to attend such an institution, especially in a place like the United States where the cost can be prohibitive for many, even with scholarships and other aide.
Reddit probably isn't a good place. There's more snobbery and faux intellectualism there than there is actual intelligence, and that's even when focusing on the more intelligent subreddits. It's similar for those who regularly contribute to Wikipedia. It's more about politics there than it is about intelligence.
Digg is pretty much dead. Slashdot is nearly dead. HN has a rather limited audience. A lot of intelligent people voluntarily choose not to use Facebook, Google+, Twitter, or other social networks due to privacy concerns.
So 4chan does look like a reasonable alternative. There's a large audience, its members are probably smarter on average than you'd find elsewhere, and it avoids many of the problems with the other websites or social networks that put a lot of focus on identity.
I think it's great what Rust could potentially offer software developers. But it's still pretty theoretical at this point. The language and standard libraries aren't sufficiently stable enough for serious, long-term use, currently. I hear we may start to see the beginning of such stability at the end of the year, but until it actually happens, Rust isn't very useful, while C++ is.
Yes, it is a very powerful language and there can be a lot to it, but it shouldn't "terrify" you.
These days, it's generally quite easy to avoid much of its C heritage (including potential security pitfalls) if using the so-called "modern C++" techniques, but the extra power and flexibility is still there if you do ever need it. There are numerous ways of easily avoiding manual memory (or other resource) management, too. The STL and Boost, among numerous other libraries that are out there, offer lots of convenient, high level functionality. The portability of C++ code is often quite excellent, the language and its standard libraries are quite stable, and there are multiple commercial-grade implementations from numerous vendors/projects. You probably won't find anything else that gives you a high degree of performance along with high level abstractions, while also giving you the peace of mind that your code will still compile just fine years or even decades from now.
While it's certainly possible to to overboard and misuse C++ to a point where it causes serious problems, one of the best things about C++ is that it doesn't force you to do that. You generally don't pay for what you don't use, and it's certainly possible to use a very effective subset of the language much as one might use Java or C#, or even Python and JavaScript.
I'd say that C++ is even easier to use than JavaScript is. C++ is much more sensible in so many ways, and nowhere near as quirky or just outright broken in fundamental ways like JavaScript, while also providing at least some type safety and other compile-time checks.
If you want a stable, portable, safe, well-supported language that offers high level functionality without the performance tradeoffs of other languages, then I think that a modern subset of C++ could very well be exactly what you're looking for.
Stability isn't something that happens overnight. It takes a lot of discipline, and this discipline has to be ingrained within the very project itself. I don't see this as the case with Rust.
And D isn't a new language, by any means. It has been out there for well over a decade now. That should be more than enough time for it to achieve relatively widespread usage, were it to actually offer sufficient benefit over C++ and its other competitors.
I don't dispute that languages like Java, C# and Go being widely used. And while the systems built with them may be critical within a very local scope, such as at the company level, pretty much all software of global importance is still implemented in C, C++, or some mix of the two. This is true almost 20 years after Java came on the scene, almost 15 years after C# did, and almost 5 years Go did.
Go is perhaps the only case where this may change, given how its implementors have expressed interest in porting their existing C code to Go. But that still won't change the fact that the operating systems, databases, and other software systems that Go code often interacts with are still very likely to be implemented using C and/or C++.
There have been some encouraging developments, of course. But they've had their own drawbacks that are often worse, in practice, than the problems of C++.
D is an example of this. A lot of new and existing C++ code probably could be written in D instead. But D lacks the widespread adoption and support that C++ offers. This translates into there being fewer third party libraries available, which increases the burden on programmers to an extent that's usually unjustifiable during commercial development And this, in turn, helps prevent the adoption of D.
Rust is another example. It theoretically sounds like it could be a replacement for C++, but that's only true in the far future. The language and its standard libraries have yet to show any real signs of stability. We've been hearing that there may be a 1.0 release at the end of 2014, but time is quickly running out on this. Even then, it will merely be where D is at that point. While there may be a fair number of Rust libraries in existence at this point, many of them have become broken due to language or standard library changes, many are woefully incomplete, and many are totally abandoned.
Then there are Java, C#, Go and others which claim to be successors or potential replacements, and perhaps this is true in a very limited subset of cases. But the remaining situations where they aren't suitable are large in number and quite critical.
Furthermore, we are continually seeing C++ adapt and evolve. It's getting new features and functionality that these competitors are offering, while still usually giving far more freedom and control to programmers, far better performance, far better portability, far greater practicality, and continued use for serious new software projects. These factors combine to make it an even more difficult situation for potential C++ replacements. They just may not bring enough to the table to warrant replacing C++ for a majority of its users or potential users.
Such memory and CPU consumption problems are often blamed on vague "third-party extensions", even when they happen with fresh installations on systems that have never before had Firefox installed. Or they're otherwise blamed on the user somehow, even when the user is engaging in a perfectly reasonable workflow.
And even if the problems don't happen on one system, they very well could be happening on another system, as this very incident shows quite well.
This part of the article is particularly relevant: "Shortly after that, while on a plane I tried pdf.js on my Mac laptop. I was horrified to find that memory usage was much higher than on the Linux desktop machine on which I had done my optimizations. The first document I measured made Firefox’s RSS (resident set size, a.k.a. physical memory usage) peak at over 1,000 MiB. The corresponding number on my Linux desktop had been 400 MiB!"
This matches very well with what so many Firefox users describe as happening to them. The memory consumption ends up skyrocketing to well above what it reasonably should be. Gigabytes of memory are unjustifiably consumed.
Perhaps now instead of ridiculing or ignoring people who report such issues, those in the Firefox community will perhaps do the responsible thing and take them seriously. It should be very obvious now that memory consumption problems can happen on one system, while not happening on another.