Oh dearie me... Everything depends on GObject, they wrote Vala to have a high-level programming language, they wrote GObject Introspection to generate bindings for all other languages, yet they think it's a good idea to ditch all of this and move to Rust (no inheritance, which is crucial for their Gtk+ widgets), only because it's so hip right now?
They lost their mojo because of their weird decisions in the past and not because their stack isn't hip. How many JavaScript developers did they attract by writing the Gnome Shell in JavaScript? And the Rust community is a tiny fraction of the JavaScript community.
They are trying to turn a donkey into a racehorse. And if they do a full rewrite, people will have forgotten about Gnome by the time they are finished. Someone give them Joel Spolsky's article on refactoring to read.
> I agree with the article. Vala is a wonderful language, but it doesn't have the necessary tooling built around it.
Sure but they had like 10 years to do that, I remember a french guy who ever wrote a complete IDE with autocompletition + package manager for Vala on Windows. Support from the Gnome Foundation ? zip .
No, I'm talking about gdb support, for example. I'm talking for a testing framework (right now you have to write your own build process capable of bundling the unit tests with your source).
They still had 10 years to do that. complaining about the lack of tooling they didn't develop is idiotic, they are in charge of the language themselves.
Well, not all people have the expertise or willingness (in case of volunteers) to work on this. Switching to Rust would allow them to leverage somebody else's work.
Also, GObject itself made a lot of sense in an era when C was dominant. Maybe now, not so much.
Switching to Rust isn't going to solve Gnome management problems. You could make the case that they should ditch Gtk and adopt Qt, it would actually make more sense than rewriting Gtk in Rust given the amount of work it represents. But you complaining about the tools that don't exist is still ridiculous, the problem is why these weren't developed at first place.
Breivik was an isolated incident, deadly but isolated non less. There is no correct response to terrorism. All terrorists are different. The IRA isn't the FARC or this or that palestinian groups or Al Qaida or Daesh. Sometimes there is a political solution, sometimes there isn't. There is no political solution with Daesh, these people want to exterminate their enemies, the only solution is to exterminate them before they do.
> This assumes that these groups believe their actions will lead to a direct outcome.
Daesh believes the ends of times are coming and the final battle against "evil" is near so they are just doing Allah's bidding, they believe nothing has changed since the 8th century and they are fighting "the armies of Rome". Do you really think it is rational thinking ? do you really think their can be some kind of political solution in that case ? Daesh is forcing no change upon the enemy, they want to exterminate them like Nazis wanted to exterminate the Jews.
Not the OP but let's take a tree. In F# it's trivial to describe what a tree structure is with the type system. In Java, you'll need to use the Composite pattern and write classes (tree + leaf) to create a tree like structure. Thus the Composite pattern is made irrelevant in F# since an algebraic type system allows you to describe an intent without writing imperative code.
Good type systems are a trade-off between complexity and expressiveness, but it's something that is hard to get right. Obviously Java's type system is simpler thus in theory easier to learn. But in practice F#'s is easier to use if understood and might lead to smaller thus more maintainable code bases.
The issue is that in a lot of shops design patterns have turned into a religion and not just a tool to help thinking. I've seen managers like that.
If you didn't implement 15 different design patterns in this or that code base that was "bad design", even if it unnecessarily made the code more complex.
I've seen iterators classes written when a simple for loop would have done the trick. I've seen chains of responsibility implemented when a basic switch statement would have been enough. Of course the code wasn't meant to be refactored in anyways. In fact complexity led to inability to refactor anything as nobody had a clue what went where ... and of course to manage all that bullshit we had to write tons of factories, because instantiating a single useful object now took 30 lines of code ...
Agree, that's a real issue, just like managers who treat agile as a religion and sadly give a fundamentally good thing a bad name.
Good programmers know the importance of YAGNI and the root of all evil that is premature optimisation. They should be well equipped to avoid over-engineering while still getting the learning benefits of patterns.
Chain of responsibility, for example, is a pattern I learned via GoF, have found it to be useful on several occasions. I quite possibly never would have known about it otherwise. At best, it would be left to chance for me to stumble on it or refactor into it enough times to recognise the pattern.
> For instance, MVC is a very popular design pattern. When you read code built according this pattern, even if you are not familiar with the language or framework, you know what kind of thing to expect to find in different parts of the program.
The problem with MVC is that it lost any accurate meaning.If you tell me "my app is MVC", I vaguely understand it has a view, a controller and a model but it doesn't tell me if the controller sits between the view and the model or the view directly observes changes in the model.
If you take a pattern like the Chain of Responsibility, or the Command pattern, the goals are clear because they are usually made of a single or at most 2 collaborators. MVC is sometimes a mix between the strategy and the observer, sometimes it isn't yet people still call that MVC.
The major problem for me with MVC, is that people build complex applications on an MVC framework and then try to shoehorn various things that are definitely not views, models, or controllers, into the pattern.
I've seen applications that control hardware where a class called 'model' twiddles bits on an interface port and then blocks until it sees some bits twiddled in response. Or where the 'controller' actually goes off for an hour to do heavy data processing (using the web servers thread pool as a job queuing system).
In both these cases, those things should have been in descriptively named classes that accurately described what they did. In the latter case, trying to adhere to a pattern gave the application a strange architecture that could have unforeseen problems.
I'm not sure if MVC is even the right pattern for a lot of modern web applications with a thick client or that describe a workflow. Often it feels like you are shoehorning there.
However, I'd say these are cases of 'doing it wrong' that don't prove the overall approach bad. I picked MVC because everyone has heard of it.
This is why I disagree with the shared language interpretation of design patterns. Once you slap "MVC" or any other name on some code, you'll constantly be second-guessing whether new code is violating the pattern. The goal is to produce working, efficient, secure, maintainable software, not to implement patterns.
I think design pattern books would be more helpful if they deleted all the pattern names and just called the book "A collection of a-ha! moments in C++" or whatever. Readers could skim through the chapters every couple of months until they stop having a-ha! moments. The "patterns" may or may not emerge in the reader's code, depending on what works best for a specific project.
Design patterns are just a way to convey an idea. If I name something a factory, everybody knows its purpose. If I name something a prototype then people who are familiar with patterns know it will have some "clone" method. So it's a bit like UML redux. But one only need iterators if the language one uses doesn't allow you to naturally express custom iteration without requiring you to write a class or some other boilerplate.
The article demonstrates that fact pretty well.
It's also a good way to judge how practical a language is. I don't need to write iterators in a language that has generators for instance. I don't need to write factories in a language that supports closures... But then people selling all these expensive modelling tools would be out of business ...
> How about OVH, online, GoDaddy, Digital Ocean, Linode???
None of them really are AWS competitors. The competition is Azure and Google Cloud (and a few other enterprise oriented IAAS but not really opened to the public). And frankly, Google Cloud is actually getting really good. Just compare Google Cloud interface with AWS ... it's day and night. And I was extremely critical of App Engine PAAS before and its stupid limitations (and the joke datastore is) so I'm not a Google fan boy at all, quite the contrary.
It wouldn't surprise me if, by the end of 2020, Google Cloud takes a significant size of the market. Right now it has still a few problems though, but nothing that cannot be fixed on the long run. I'm personally thinking about recommending GCloud over AWS to my clients, especially if they end up fixing 1 or 2 few stuff ASAP.
Azure of course it better for anything Windows and .Net related.
They are not competing directly but their numbers is still important to know the market(s). They are big companies with many customers, they shouldn't be dismissed.
I agree that it's important to size the VPS market, as it directly competes with one of the primary things people come to AWS or GCP for ("How do I host my site?"). As a side comment mentions, I might also include GoDaddy as well as DreamHost and the underlying brands of Endurance, since again so much of the "cloud" is really just people running WordPress "brochure ware" sites.
Having said that, you should realize that some of those companies (GoDaddy, Endurance) are public and even indicate how large they are from an infrastructure sense. Ultimately, VPS and/or website hosting comes down to charging customers $5/month for approximately $0 in infrastructure. The "real" infrastructure money is in either large compute, or "serious" sites. So it is important, but ultimately they'll round towards 0.
Disclaimer: I work on Google Cloud, and have never worked for any of the other companies mentioned.
Just in case we're not already working on them, feel free to send me your few things and I'll route them to the appropriate PMs and engineers. (Contact info in profile)
> Has anybody working towards serverless version of wp?
I'm curious on what a "serverless version of wordpress" consists of, please enlighten us on the technical details of a serverless wordpress, sincerely. And how would you have a "serverless shopping card" too ? I'm really curious about the how it. If you're talking about a static blog generator then it already exists (Hugo,...) is this what you call serverless ?
Most blog content is static, why would you need to use lambda for anything ? you already get automatic scaling by putting static files on S3. What Wordpress functionality would need to be implemented with Lambda ?
I run a static blog on S3 using Lambda. I upload a markdown post to an S3 bucket, Lambda runs Hugo (could be Jekyll, or whatever) to regenerate the appropriate files, then uploads it to an output buckets, invalidates the files it needs to in Cloudfront, etc.
Not infeasible to think you could use Lambda to generate a static cache of a WP site onto S3 and update files on demand.
I read "serverless" in this context to mean a statically generated site, yes. I also infer that dynamic content like authentication, shopping carts, forms, etc would be third party solutions via Ajax and CORS.
I built a service [1] for this latter part (authentication, CORS sql database, and static file hosting). The pieces one could use to build anything for a statically generated site. Adoption has been... non existent up to now.
> I just wish adobe would get their act together and release photoshop and friends for linux.
Never going to happen, there is no lucrative market on Linux for these kind of tools, Adobe isn't going invest millions for a handful of potential users. Even smaller players don't bother with Linux. MacOS is still where the money is for tools for creatives.
It also doesn't help that Linux is very fragmented. Supporting Linux means that you have to support your application for many different desktop environments, glibc versions, kernel versions, etc. They could require, say Red Hat Enterprise Linux 7 and the latest Ubuntu LTS, but there would still be a large number of support requests from people who run some distribution forked from Ubuntu, etc.
Another problem is that a lot of Linux-related communities are very hostile towards proprietary software, let alone proprietary software with DRM that requires a subscription. So, they will run into anything from unwillingness to help with problems in base libraries to people who will sue them to show that they violated the GPL in some way.
Adobe will not go there unless they absolutely have to.
> It also doesn't help that Linux is very fragmented. Supporting Linux means that you have to support your application for many different desktop environments, glibc versions, kernel versions, etc.
This is often said, but rarely true; if you standardise on the latest Ubuntu LTS for example, other distros will be able to provide packages to make the app work there, see i.e. Steam or Swift.
> Another problem is that a lot of Linux-related communities are very hostile towards proprietary software, let alone proprietary software with DRM that requires a subscription. So, they will run into anything from unwillingness to help with problems in base libraries to people who will sue them to show that they violated the GPL in some way.
Again, not really true, see i.e. JetBrains, which is rather popular on Linux.
Also the smear campaign around the GPL is getting rather old; it's simple, adhere to the license and you'll be fine.
Adobe, Microsoft etc. also requires you to adhere to their license. Why is that fine, but complying with the GPL as per wishes of an author of software you're making use of, why is that not fine?
> Another problem is that a lot of Linux-related communities are very hostile towards proprietary software, let alone proprietary software with DRM that requires a subscription. So, they will run into anything from unwillingness to help with problems in base libraries to people who will sue them to show that they violated the GPL in some way.
DRM is in it self hostile to the user. Never seen anyone against subscription based software or willingness to pay for good software in those Linux-related communities that you describe. If anything, in those communities people wouldn't pirate you're software as much as Windowse users. In my experience Linux users are more understanding that making good software is hard work and they appreciate it more.
Why is okay for Adobe suing people for license violation and not vice versa?
https://siliconislandblog.wordpress.com/2016/10/31/thoughts-...
> and support a preferred programming language (Vala)
https://launchpad.net/elementary