The parts about buffer overruns and other certain common errors were older parts of the system. The cool part (and I'll have to read the paper) is how they formalized timing to prove against timing attacks.
For those curious, this is all based on the Curry-Howard correspondence, which links type checking of programs to proofs. Given this, you can create a language whose type system allows you to prove certain things about the program. You can then use an SMT to prove that a translation from F* to another language is correct.
There's even formal models of ARM and there's a provable version of L7, a microkernel.
I honestly think the next big wave is going to be applying formal verification to more practical systems. Bugs and security cost, and these tools are powerful ways to address those issues.
Granted, given the use of X86-64, there's always hardware issues to be addressed, but even there, formal verification is important.
Nobody in this country has the right to demand other party sell anything, so no, separating fools from money on Amazon isn't a right, not even close.
There are many freedoms more important the right to be wrong. The right to life and liberty, for one. Being an idiot, lower on the list.
Finally, plenty of countries manage very well even without the First Amendment. I wouldn't say America would be one of the countries, We are young, brash and tend to forget history too easily. In many countries, 300 years is just one step on a much, much longer history. Maybe when we are 500 years of age, we'll be more okay with saying being so stupid as to actively threaten the lives of others isn't a right, Maybe we will be a just tiny bit more focused on the life, liberty and happiness for *all*, versus being obsessed with every tiny or useless of individual liberties with little or no thought to their actual costs.
I always find it a bit odd when people mock the Federal Government for being useless via a website on the Internet. The government which funded all the foundational research to create the internet. Software, hardware, you name it. Companies like Google, Cisco, Sun, etc. all got their start from research grants and funding from the federal government.
And yet, when people suggest that companies that exist solely because of federal investment and infrastructure should pay taxes to support the next generation of new ideas and (gasp), a functioning society, people scoff.
A bit late to the party, but this is more complex then some of the responses of "the lambda makes sense"
Firstly, the above does show the pains of mixing older APIs with newer features. The method list that takes a FilenameFilter has been there a lot time. And yes, in this case, the compiler is going through a lot of steps to make sure the lambda matches that type.
But you still have to know that there is a overload of list that takes that object. That's not really good functional style, because it's specific. What's better functional style is:
directory.list().filter(s -> s.endsWith(".foo"));
Because in functional programming. filter is "generic". It means: I expect a collection of items, and my return value is a collection of all items for which the lambda expression is true. Therefore, the lambda takes one argument that is the type of an item in the collection (in this case, a String from a String[]) and returns a bool.
But, in Java, this doesn't work either, because String[] doesn't have a filter method on it. We have to turn it into a Stream like so.
But, what's the signature of filter? More specifically, what is the type of the argument it takes? Well, that's:
Predicate<? super T> predicate
Ah, type erasure. Which means, we have to have things like IntStream, DoubleStream to filter on collectons of integers.
Compared to C#, this is clunky. Firstly, C# is more consistent about what can be viewed as a collection (more precisely, what is enumerable) This comes from having syntax to iterate over a collection of objects from the start. Secondly, C# doesn't has type erasure, and handles value and reference types consistently in generics. So, we can say something like
I won't get into the signature of Where, because it uses another C# feature, expression trees. Basically, expression trees allow things like EntityFramework to turn certain C# queries into SQL. It's not magic (certain errors can't be caught until runtime), but it's damn powerful.
Java has a lot of legacy, and it can make things very complicated. C# choosing to break backwards compatibility with it's older non generic classes worked out really well. That and how they handle enumeration (yield return) really meshes very well with functional programming. Yes, it's Microsoft, but Anders Hejlsberg did a great job of designing C# and it has held up.
Did you know the latest version of Java introduced the var keyword, so, no, it's not about Visual Basic. If you are talking about late binding, which is useful for COM and the like, that's dynamic, but dynamic is also really useful for functional or scripting languages.
It's a required feature for using anonymous types, which are super useful in many cases. And it doesn't change anything about type checking.
Licensing complications. Sure, the OpenJDK exists, but you have to test your long standing and legacy applications against it. Of course, you should do that, because old versions of the Java runtime really have security issues. Oh and if you aren't careful and get caught in an audit, that can hurt.
Adding language Features. C# and.Net was dogging them a bit in this area. But type erasure and some other aspects of the type system still makes functional style code just clunky (special streams and functions for int, doubles, longs). The way they did lambdas was pretty hacky.
Modules and the new versioning. Java 9 added modules, but it's a bit clunky, to put it kindly. We have Java 10 and 11, with 12 to come, and nobody really wants to deal with new versions of the JVM on that rapid of a time scale. But, he rate of adoption of Java 8 and newer features is slow. I still see tons of Java programmers that have never used streams. But, that hybrid functional/OO style can be very useful.
With Erlang/Elixir,.Net Core, Go, Python, NodeJS and even modern C++, Java is just being squeezed out in terms of being used for newer projects. But, with so much code out there, it will live for quite some time.
Because, good enough for Google is good enough for everyone, right? And if it's not, they'll just do it anyway. Sure, I'm just old and grouchy, but I liked it when the IETF and the RFP process was a forum for very intense discussions with many researchers and industry leaders really working things out. Lately, it seems to be much more of a rubber stamp for big companies' technical ideas.
Didn't see much mention of this, but the whole fine art system is basically a way for the really rich to trade wealth without taxation or regulation. The galleries, museums and auction houses play their role in making sure the prices stay high, including just making up bids, refusing to sell to certain people and so on. It's a great way to launder money too.
And Bansky is playing right into it. If they really didn't care about that system or capitalism, they would refuse to let any of their art to be sold at auction or not allow any one piece to be valuated for more than the average yearly wage in a given country (as an example).
And this is a perfect example. The owner of the destroyed piece can keep it around and when they have a really good day on the market, they loan it to a museum, which gladly says "well, it's now worth ten million because of the novelty, so we value your donation at 1 million" and poof, there's 1 million they don't have to pay taxes on thanks to their kind donation. Rinse, repeat. It's a scam for the super rich, nothing more.
CA is where software is put to pasture and slowly dies. It seems like this is okay, but they will charge you quite a premium to use it until it finally keels over. Honestly, I can say that it is worth the effort o remove anything they have from your organization. Or move to another one if you can.
There is plenty of commentary in Buddhism on why serious meditative practice needs to be done with an proper teacher and inside a proper community to avoid these very issues. Cutting Through Spiritual Materialism is a great text that discusses this issue and how to approach it from a Tibetan Buddhist perspective. This is really nothing new, far from it.
And, yes, if you have a set of random people meditate with no or little guidance for four weeks, there will be a ego boost. Longer term, directed practice is required for real change.
None of these are really huge problems. There really is no performance hit for strings as a primary key. If it's a candidate key, it's fine to use. And array lists are a very reasonable general implementation of a list interface.
You can write bad queries in any language, but LINQ and Entity Framework actually does a pretty reasonable job of optimization. Besides, SQL is equally easy to abuse. And I'll take slower performance in the face of easier to maintain code. Which is a big reason ORMs do exist.
But, since it's Microsoft, I know people will insist it is impossible that.Net is actually a reasonably well coded platform, but it is.
There's some good points here, but i would note that Python as a language has its fans as well and some would argue it is quite well designed overall. Personally, I find Ruby can be a bit too clever in places, but such things are a matter a taste.
I don't disagree that the adoption of NoSQL could be problematic, merely that those looking for speed of implementation are increasingly adopting it and it is displacing Rails. Fairly or unfairly, Ruby is often tied to Rails, and as interest in Rails subsides, it is a drag on Ruby as a whole.
Meanwhile, Python is getting a nice boost from use in Machine Learning and CS education and that may cement its future. It is used a lot in scientific computing and has been for quite some time.
But, Ruby may gain a foothold in another domain. The future is always uncertain, but I was to bet, I would bet it against it right now.
In the end, it says little about the quality of Ruby as a language. Worse is Better, after all.
Code lasts a log time, so there will be users here and there. But, I highly doubt it will thrive. Python is gaining and has an advantage of very good interoperability with C libraries and improving overall performance thanks to projects like NumPy and the like. It's use in data science and other projects as well as in CS education will continue to help the overall implementations, Python competes in the language space that Ruby is in, and I think it does it very well, even with the issues around the 2/3 versioning. Honestly, Ruby is behind Python, and that gap is increasing.
The original advantages of Rails are disappearing. More and more of the MVC work is moving to the client side, and the server side is increasingly oriented towards just providing REST services. The amount of server generated HTML, a big part of Rails initially, is very rapidly decreasing. And while Rails is evolving, that legacy still exists. And other stacks have caught up. NoSQL make the ActiveRecord pattern much less needed for example. So, if you want raw speed in terms of time to implement, Node and the MEAN stack are really more competitive. Of course, that speed comes at a real cost and NodeJS has it own problems.
All in all, Buby faces enough challenges that will take too long to fix via language and runtime changes for its future to be vibrant. I expect it will fade in the face of Node, Python and even the resurgence of strongly typed frameworks (Java, C#, Scala) alongside newly revived languages like Erlang (and it's modern cousin Elixir) that embrace patterns for scaling that serve the whole modern web well.
For the same reason Scala and Go has them, when dealing with functional programming with classes it is really useful to select and filter only the wanted properties of objects (possibly with multiple different types, mind you) without having to declare every possible permutation of them as it's own class. It's still type checked and you don't lose type safety. There's more advanced uses as well.
I know it is easy to think C# must be bad because of Microsoft, but it is a very well designed language and other languages have adopted certain aspects of it because they are useful and aid developer productivity.
.Net Core has been running on Linux for over a year, and while you don't get everything, you get quite a lot. It's not nearly as tied to Windows as it used to be and it is become more of it's own independent ecosystem.
Windows 10 does support minimal processes (likely Server 2016 does as well) which are just what pico processes are, but not associated with a specific kernel mode driver. And they are all processes, they have the same level of context isolation as full processes.
(https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/) They just don't have the standard blocks and core library loaded into them. They are still a user mode process with their own address space.
Also, creating new processes in Windows is not horribly more expensive than Linux, it's quite competitive. There's still some people that insist that because Win32 doesn't use the fork model, it much be horribly inefficient, but the reality is that process creation in win32 uses a lot of the same optimizations that Linux does and for most cases, performs very well. I've seen a lot people run benchmarks in which they fork a lot to prove how much faster it is, but never bother to exec, which is what CreateProcess (and the like does) APIs in Win32 do and what is done in the vast majority of cases.
Cygwin was slow because it had to emulate the exact semantics of fork for all cases as well as support Windows 95/98. When support for non NT kernel systems were dropped, the overall performance improved as newer APIs could be used. Cygwin got a bad rap for being slow early and never shook it, even those modern versions don't have the same problems.
Threads may be more common in Windows as the underlying WIN32 models were stabilized and useful. In the Unix world, each vendor had their own models and it took longer for pthreads to truly be accepted.
I don't have enough space to address some of the other claims, but the windows kernel is not nearly as broken or bad as many think or claim. Most of those claims are really nothing more than "well, it's not Unix/Linux, so it must be awful". The reality is way more complex. And, yes, with time, WSL could have excellent overall performance for the applications and use cases it is targeted for.
Nope, you got it exactly right. A large database of faces tied to identifiable information has real value, This is a way to help Google catch up with LinkedIn and Facebook (who, with Instagram is way in the lead) in terms of data.
Orwell got it wrong, we didn't need the government to oppressively remove our privacy, we gave it up in return for Pavlovian instant gratification. The like button was ingenious, it truly was.
It's not surprising. Firstly, most of the framework seem to ignore the lessons learned from those "old" desktop GUI frameworks. But it makes sense, those frameworks take full advantage of a language with easily expressed class inheritance which overall is a excellent match for GUI based systems. It doesn't translated to raw JavaScript, and you get a lot of reinvention. Take React. Mixing markup and code seems very easy, but it ignores that ASP and JSP already did that, and it turns out not to be very maintainable (read, a spaghetti nightmare) in the longer run.
Yes, I know Facebook uses it. But, Facebook really has one big web application and all the resources and them some to maintain it. Doesn't apply to anybody else, really.
And others insist on purity and want lightweight frameworks that just help mashing together HTML and CSS with the DOM, but if that worked, there'd be no frameworks. It's still too low level for many. Angular is the only one that's kind of interesting, as it seemed to accept that you need a more expressive language (TypeScript) to do this better in terms of maintenance and ease of use. Any brilliant team can make anything good out of anything, the point of frameworks is to lower the bar to obtain average quality from average teams.
All of this still doesn't address that HTML/CSS isn't a great core GUI abstraction and that any web page sits in a browser that are using just those libraries. But, they keep piling on. Like WebGL. OpenGL works and has way more experience under it's belt, and I'd argue that if C/C++ makes you too nervous to use, you probably shouldn't be writing a program using OpenGL like abstractions in the first place.
I'm fine with mobile and desktop applications being the preferred model. Nothing wrong with targeting a specific OS.
There is a massive amount of tooling and infrastructure needed to design a modern CPU architecture. Sure, you can start with open designs that are 20 years old, but you'll need to add massive amount of changes around out of order execution, speculative execution (yes, it caused this problem, it's also a critical optimization), cache management and coherency and so on. A lot of this requires highly specialized workers that expect to be paid well for their expertise.
Much better to invest to formal verification research and tools, but that is already happening at all levels from academics to industry.
Honestly, I don't know why it took Oracle so long to really push their own cloud solution (after all, it's a chance to lock customers down even more), but it's really a bit too late. AWS and Azure have been doing this for years. SQL Server is going on Linux, Aurora is getting better and better. Postgres is a great option, there's the whole NoSQL option if you want. Personally, if they get taken down quite a few notches, so much the better.
Active Directory is good, until it's landed with too many insane Group Policy Objects. Seriously, it'll make some people's lives just a living hell, especially developers. It's astounding what will fail to install when you can't check for updates. But, then again, you can put them and their machine in a different group with a different set of policies, but I haven't been to a shop yet that realizes that's totally a thing.
And yea, let your developers have the latest OS and updates. Make them the canaries in the coal mine. They'll appreciate the freedom and understand when it goes bad.
The JSR process has become massively slow with tons of large companies fighting by proxy. Honestly, I think.Net Core may find a bigger place in the overall ecosystem alongside Go and NodeJS. Sure, Java isn't going anywhere, but some of the issues that Java 9/Jigsaw are trying to deal with don't exist in.Net, and C# has adopted some very useful language features.
Also, the.Net Core is simplifying some complex use cases that Java 9 is trying to adopt. They are depreciating AppDomains in favor of OS level isolation (processes, threads) while still allowing for unloading/replacement of assemblies. Similarly, they are backing off the code trust model, moving again to OS level mechanisms. Their reasoning is pretty sound, it was complicated, didn't really work as expected and why not simplify and just support what most people actually do.
It's not prefect and there's work to be done, but it might really gain traction..Net has great APIs for the kind of strongly typed data transformations enterprise apps do. They still have build chain issues and cross platform tooling needs to mature, but really, if all the major players in the JSR keep butting heads like this, Java will face even more competition than it already does.
Also, this all impacts other languages. Scala and Kotlin have to jump some hoops to support certain features, but they are still tied to the JVM and its core mechanisms, which why this was a part of Java 9 in the first place.
It's a very useful way of thinking about certain problems and it is often simpler that a lot of pattern heavy code. Take something like a template method. With functional programming just provide the functions to the method or instance. It accomplishes the same thing without an explosion of subclasses.
There's a lot of other classic OO patterns that aren't needed or just done a lot more cleanly with higher order functions and other functional programming paradigms. It's also unfortunate that people assume functional programming is embodied in one language. Haskell is indeed a functional programming language (a highly opinionated one), but so is LISP and Scheme, which have completely different approaches.
And FP paradigms are more and more common. List comprehensions in Python are just bog standard adoptions of map and filter higher order functions from functional programming.
I didn't know what it was until I looked it up in the article. So basically you want me to remember that some guy came up with a name for using inheritance and if I don't remember it I'm a bad programmer?
Just as an aside, it's some gal. Barbara Liskov, Turing award winner. While I don't disagree such questions aren't the best in interviews, a bit of history also doesn't hurt. Also, in some circles, the SOLID acronym is gaining traction, and Liskov substitution principle is the L.
Many programming people are aware of Richard Gabriel's essays on why C and related languages became the dominant programming paradigm ( https://www.jwz.org/doc/worse-...). In essence, sometimes those ugly compromises are just what people really want (or even need).
Many have argued that JavaScript is a excellent example of this phenomenon, but there's one big difference. Everybody is trying to replace JavaScript. Some are bolting on new keywords to the language, others are pushing features and some have just started using TypeScript. Here's the thing. The history of C, the "worse" language in the article, had a long history of usage (still does), and C++, for better and worse, sought only to argument, not replace C. In the end, JavaScript is not worse, it is broken.
We know that strictly typed object oriented languages do really well for UI based systems. The notion of hierarchy of control classes works. The Document Object Model even acknowledges that by suggesting it too fits that model (but really doesn't do that). If they really want to make an UI ecosystem, they will either continue to hack it together at an increasing expense, or they will get an ecosystem that does it better. Personally, I think the hacks will go on for a long time, because cross platform UI markup, programming frameworks and a new language for that all? Very difficult to do, and there is too much invested in the "Web way" to just steal what works from Microsoft, Apple, Android and so on.
And, the thick client model is making inroads and maybe that will continue. Mobile apps are a thing, maybe desktop apps will gain traction as people realize you can still gain similar levels of control and data collection with those as web pages (sad, but that's how we pay for things now).
In the end, language design is very hard. It's actually not hard to hack up a bad version of Scheme or Lisp (that's what JavaScript is). It is very hard to fix all the problems if your language is a success. A proper set of fundamental types matter. Lexical scoping matters. Proper typing and a effective type model matters. And that's not even talking about the core frameworks that a good language needs, because that's a whole new set of challenges. I just hope that if there is a JavaScript replacement, that they follow in the fine programming language tradition of just stealing what works and carefully replacing what doesn't. C++ stole from C, Java stole from C++, C# stole from Java (and Delphi). F# stole from Haskell, Haskell stole from OCaml which stole from ML and everybody steals from Scheme and Common LISP now. Just do it and don't be too clever about it.
Slashdot Mirror
The parts about buffer overruns and other certain common errors were older parts of the system.
The cool part (and I'll have to read the paper) is how they formalized timing to prove against timing attacks.
For those curious, this is all based on the Curry-Howard correspondence, which links type checking of programs to proofs. Given this, you can create a language whose type system allows you to prove certain things about the program. You can then use an SMT to prove that a translation from F* to another language is correct.
There's even formal models of ARM and there's a provable version of L7, a microkernel.
I honestly think the next big wave is going to be applying formal verification to more practical systems. Bugs and security cost, and these tools are powerful ways to address those issues.
Granted, given the use of X86-64, there's always hardware issues to be addressed, but even there, formal verification is important.
Nobody in this country has the right to demand other party sell anything, so no, separating fools from money on Amazon isn't a right, not even close.
There are many freedoms more important the right to be wrong. The right to life and liberty, for one. Being an idiot, lower on the list.
Finally, plenty of countries manage very well even without the First Amendment. I wouldn't say America would be one of the countries, We are young, brash and tend to forget history too easily. In many countries, 300 years is just one step on a much, much longer history. Maybe when we are 500 years of age, we'll be more okay with saying being so stupid as to actively threaten the lives of others isn't a right, Maybe we will be a just tiny bit more focused on the life, liberty and happiness for *all*, versus being obsessed with every tiny or useless of individual liberties with little or no thought to their actual costs.
I always find it a bit odd when people mock the Federal Government for being useless via a website on the Internet. The government which funded all the foundational research to create the internet. Software, hardware, you name it. Companies like Google, Cisco, Sun, etc. all got their start from research grants and funding from the federal government.
And yet, when people suggest that companies that exist solely because of federal investment and infrastructure should pay taxes to support the next generation of new ideas and (gasp), a functioning society, people scoff.
Because in functional programming. filter is "generic". It means: I expect a collection of items, and my return value is a collection of all items for which the lambda expression is true. Therefore, the lambda takes one argument that is the type of an item in the collection (in this case, a String from a String[]) and returns a bool. But, in Java, this doesn't work either, because String[] doesn't have a filter method on it. We have to turn it into a Stream like so.
But, what's the signature of filter? More specifically, what is the type of the argument it takes? Well, that's:
Ah, type erasure. Which means, we have to have things like IntStream, DoubleStream to filter on collectons of integers. Compared to C#, this is clunky. Firstly, C# is more consistent about what can be viewed as a collection (more precisely, what is enumerable) This comes from having syntax to iterate over a collection of objects from the start. Secondly, C# doesn't has type erasure, and handles value and reference types consistently in generics. So, we can say something like
I won't get into the signature of Where, because it uses another C# feature, expression trees. Basically, expression trees allow things like EntityFramework to turn certain C# queries into SQL. It's not magic (certain errors can't be caught until runtime), but it's damn powerful. Java has a lot of legacy, and it can make things very complicated. C# choosing to break backwards compatibility with it's older non generic classes worked out really well. That and how they handle enumeration (yield return) really meshes very well with functional programming. Yes, it's Microsoft, but Anders Hejlsberg did a great job of designing C# and it has held up.
Did you know the latest version of Java introduced the var keyword, so, no, it's not about Visual Basic. If you are talking about late binding, which is useful for COM and the like, that's dynamic, but dynamic is also really useful for functional or scripting languages.
It's a required feature for using anonymous types, which are super useful in many cases. And it doesn't change anything about type checking.
Oracle is sucking the life out of it.
Licensing complications. Sure, the OpenJDK exists, but you have to test your long standing and legacy applications against it. Of course, you should do that, because old versions of the Java runtime really have security issues. Oh and if you aren't careful and get caught in an audit, that can hurt.
Adding language Features. C# and .Net was dogging them a bit in this area. But type erasure and some other aspects of the type system still makes functional style code just clunky (special streams and functions for int, doubles, longs). The way they did lambdas was pretty hacky.
Modules and the new versioning. Java 9 added modules, but it's a bit clunky, to put it kindly. We have Java 10 and 11, with 12 to come, and nobody really wants to deal with new versions of the JVM on that rapid of a time scale.
But, he rate of adoption of Java 8 and newer features is slow. I still see tons of Java programmers that have never used streams. But, that hybrid functional/OO style can be very useful.
With Erlang/Elixir, .Net Core, Go, Python, NodeJS and even modern C++, Java is just being squeezed out in terms of being used for newer projects. But, with so much code out there, it will live for quite some time.
Because, good enough for Google is good enough for everyone, right? And if it's not, they'll just do it anyway. Sure, I'm just old and grouchy, but I liked it when the IETF and the RFP process was a forum for very intense discussions with many researchers and industry leaders really working things out. Lately, it seems to be much more of a rubber stamp for big companies' technical ideas.
Didn't see much mention of this, but the whole fine art system is basically a way for the really rich to trade wealth without taxation or regulation. The galleries, museums and auction houses play their role in making sure the prices stay high, including just making up bids, refusing to sell to certain people and so on. It's a great way to launder money too.
And Bansky is playing right into it. If they really didn't care about that system or capitalism, they would refuse to let any of their art to be sold at auction or not allow any one piece to be valuated for more than the average yearly wage in a given country (as an example).
And this is a perfect example. The owner of the destroyed piece can keep it around and when they have a really good day on the market, they loan it to a museum, which gladly says "well, it's now worth ten million because of the novelty, so we value your donation at 1 million" and poof, there's 1 million they don't have to pay taxes on thanks to their kind donation. Rinse, repeat. It's a scam for the super rich, nothing more.
CA is where software is put to pasture and slowly dies. It seems like this is okay, but they will charge you quite a premium to use it until it finally keels over. Honestly, I can say that it is worth the effort o remove anything they have from your organization. Or move to another one if you can.
There is plenty of commentary in Buddhism on why serious meditative practice needs to be done with an proper teacher and inside a proper community to avoid these very issues. Cutting Through Spiritual Materialism is a great text that discusses this issue and how to approach it from a Tibetan Buddhist perspective. This is really nothing new, far from it.
And, yes, if you have a set of random people meditate with no or little guidance for four weeks, there will be a ego boost. Longer term, directed practice is required for real change.
None of these are really huge problems. There really is no performance hit for strings as a primary key. If it's a candidate key, it's fine to use. And array lists are a very reasonable general implementation of a list interface.
You can write bad queries in any language, but LINQ and Entity Framework actually does a pretty reasonable job of optimization. Besides, SQL is equally easy to abuse. And I'll take slower performance in the face of easier to maintain code. Which is a big reason ORMs do exist.
But, since it's Microsoft, I know people will insist it is impossible that .Net is actually a reasonably well coded platform, but it is.
There's some good points here, but i would note that Python as a language has its fans as well and some would argue it is quite well designed overall. Personally, I find Ruby can be a bit too clever in places, but such things are a matter a taste.
I don't disagree that the adoption of NoSQL could be problematic, merely that those looking for speed of implementation are increasingly adopting it and it is displacing Rails. Fairly or unfairly, Ruby is often tied to Rails, and as interest in Rails subsides, it is a drag on Ruby as a whole.
Meanwhile, Python is getting a nice boost from use in Machine Learning and CS education and that may cement its future. It is used a lot in scientific computing and has been for quite some time.
But, Ruby may gain a foothold in another domain. The future is always uncertain, but I was to bet, I would bet it against it right now.
In the end, it says little about the quality of Ruby as a language. Worse is Better, after all.
Code lasts a log time, so there will be users here and there. But, I highly doubt it will thrive. Python is gaining and has an advantage of very good interoperability with C libraries and improving overall performance thanks to projects like NumPy and the like. It's use in data science and other projects as well as in CS education will continue to help the overall implementations, Python competes in the language space that Ruby is in, and I think it does it very well, even with the issues around the 2/3 versioning. Honestly, Ruby is behind Python, and that gap is increasing.
The original advantages of Rails are disappearing. More and more of the MVC work is moving to the client side, and the server side is increasingly oriented towards just providing REST services. The amount of server generated HTML, a big part of Rails initially, is very rapidly decreasing. And while Rails is evolving, that legacy still exists. And other stacks have caught up. NoSQL make the ActiveRecord pattern much less needed for example. So, if you want raw speed in terms of time to implement, Node and the MEAN stack are really more competitive. Of course, that speed comes at a real cost and NodeJS has it own problems.
All in all, Buby faces enough challenges that will take too long to fix via language and runtime changes for its future to be vibrant. I expect it will fade in the face of Node, Python and even the resurgence of strongly typed frameworks (Java, C#, Scala) alongside newly revived languages like Erlang (and it's modern cousin Elixir) that embrace patterns for scaling that serve the whole modern web well.
For the same reason Scala and Go has them, when dealing with functional programming with classes it is really useful to select and filter only the wanted properties of objects (possibly with multiple different types, mind you) without having to declare every possible permutation of them as it's own class. It's still type checked and you don't lose type safety. There's more advanced uses as well.
I know it is easy to think C# must be bad because of Microsoft, but it is a very well designed language and other languages have adopted certain aspects of it because they are useful and aid developer productivity.
.Net Core has been running on Linux for over a year, and while you don't get everything, you get quite a lot. It's not nearly as tied to Windows as it used to be and it is become more of it's own independent ecosystem.
Windows 10 does support minimal processes (likely Server 2016 does as well) which are just what pico processes are, but not associated with a specific kernel mode driver. And they are all processes, they have the same level of context isolation as full processes.
(https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/) They just don't have the standard blocks and core library loaded into them. They are still a user mode process with their own address space.
Also, creating new processes in Windows is not horribly more expensive than Linux, it's quite competitive. There's still some people that insist that because Win32 doesn't use the fork model, it much be horribly inefficient, but the reality is that process creation in win32 uses a lot of the same optimizations that Linux does and for most cases, performs very well. I've seen a lot people run benchmarks in which they fork a lot to prove how much faster it is, but never bother to exec, which is what CreateProcess (and the like does) APIs in Win32 do and what is done in the vast majority of cases.
Cygwin was slow because it had to emulate the exact semantics of fork for all cases as well as support Windows 95/98. When support for non NT kernel systems were dropped, the overall performance improved as newer APIs could be used. Cygwin got a bad rap for being slow early and never shook it, even those modern versions don't have the same problems.
Threads may be more common in Windows as the underlying WIN32 models were stabilized and useful. In the Unix world, each vendor had their own models and it took longer for pthreads to truly be accepted.
I don't have enough space to address some of the other claims, but the windows kernel is not nearly as broken or bad as many think or claim. Most of those claims are really nothing more than "well, it's not Unix/Linux, so it must be awful". The reality is way more complex. And, yes, with time, WSL could have excellent overall performance for the applications and use cases it is targeted for.
Nope, you got it exactly right. A large database of faces tied to identifiable information has real value, This is a way to help Google catch up with LinkedIn and Facebook (who, with Instagram is way in the lead) in terms of data.
Orwell got it wrong, we didn't need the government to oppressively remove our privacy, we gave it up in return for Pavlovian instant gratification. The like button was ingenious, it truly was.
It's not surprising. Firstly, most of the framework seem to ignore the lessons learned from those "old" desktop GUI frameworks. But it makes sense, those frameworks take full advantage of a language with easily expressed class inheritance which overall is a excellent match for GUI based systems. It doesn't translated to raw JavaScript, and you get a lot of reinvention. Take React. Mixing markup and code seems very easy, but it ignores that ASP and JSP already did that, and it turns out not to be very maintainable (read, a spaghetti nightmare) in the longer run.
Yes, I know Facebook uses it. But, Facebook really has one big web application and all the resources and them some to maintain it. Doesn't apply to anybody else, really.
And others insist on purity and want lightweight frameworks that just help mashing together HTML and CSS with the DOM, but if that worked, there'd be no frameworks. It's still too low level for many. Angular is the only one that's kind of interesting, as it seemed to accept that you need a more expressive language (TypeScript) to do this better in terms of maintenance and ease of use. Any brilliant team can make anything good out of anything, the point of frameworks is to lower the bar to obtain average quality from average teams.
All of this still doesn't address that HTML/CSS isn't a great core GUI abstraction and that any web page sits in a browser that are using just those libraries. But, they keep piling on. Like WebGL. OpenGL works and has way more experience under it's belt, and I'd argue that if C/C++ makes you too nervous to use, you probably shouldn't be writing a program using OpenGL like abstractions in the first place.
I'm fine with mobile and desktop applications being the preferred model. Nothing wrong with targeting a specific OS.
There is a massive amount of tooling and infrastructure needed to design a modern CPU architecture. Sure, you can start with open designs that are 20 years old, but you'll need to add massive amount of changes around out of order execution, speculative execution (yes, it caused this problem, it's also a critical optimization), cache management and coherency and so on. A lot of this requires highly specialized workers that expect to be paid well for their expertise.
Much better to invest to formal verification research and tools, but that is already happening at all levels from academics to industry.
Honestly, I don't know why it took Oracle so long to really push their own cloud solution (after all, it's a chance to lock customers down even more), but it's really a bit too late. AWS and Azure have been doing this for years. SQL Server is going on Linux, Aurora is getting better and better. Postgres is a great option, there's the whole NoSQL option if you want. Personally, if they get taken down quite a few notches, so much the better.
Active Directory is good, until it's landed with too many insane Group Policy Objects. Seriously, it'll make some people's lives just a living hell, especially developers. It's astounding what will fail to install when you can't check for updates. But, then again, you can put them and their machine in a different group with a different set of policies, but I haven't been to a shop yet that realizes that's totally a thing.
And yea, let your developers have the latest OS and updates. Make them the canaries in the coal mine. They'll appreciate the freedom and understand when it goes bad.
The JSR process has become massively slow with tons of large companies fighting by proxy. Honestly, I think .Net Core may find a bigger place in the overall ecosystem alongside Go and NodeJS. Sure, Java isn't going anywhere, but some of the issues that Java 9/Jigsaw are trying to deal with don't exist in .Net, and C# has adopted some very useful language features.
Also, the .Net Core is simplifying some complex use cases that Java 9 is trying to adopt. They are depreciating AppDomains in favor of OS level isolation (processes, threads) while still allowing for unloading/replacement of assemblies. Similarly, they are backing off the code trust model, moving again to OS level mechanisms. Their reasoning is pretty sound, it was complicated, didn't really work as expected and why not simplify and just support what most people actually do.
It's not prefect and there's work to be done, but it might really gain traction. .Net has great APIs for the kind of strongly typed data transformations enterprise apps do. They still have build chain issues and cross platform tooling needs to mature, but really, if all the major players in the JSR keep butting heads like this, Java will face even more competition than it already does.
Also, this all impacts other languages. Scala and Kotlin have to jump some hoops to support certain features, but they are still tied to the JVM and its core mechanisms, which why this was a part of Java 9 in the first place.
It's a very useful way of thinking about certain problems and it is often simpler that a lot of pattern heavy code. Take something like a template method. With functional programming just provide the functions to the method or instance. It accomplishes the same thing without an explosion of subclasses.
There's a lot of other classic OO patterns that aren't needed or just done a lot more cleanly with higher order functions and other functional programming paradigms. It's also unfortunate that people assume functional programming is embodied in one language. Haskell is indeed a functional programming language (a highly opinionated one), but so is LISP and Scheme, which have completely different approaches.
And FP paradigms are more and more common. List comprehensions in Python are just bog standard adoptions of map and filter higher order functions from functional programming.
I didn't know what it was until I looked it up in the article. So basically you want me to remember that some guy came up with a name for using inheritance and if I don't remember it I'm a bad programmer?
Just as an aside, it's some gal. Barbara Liskov, Turing award winner. While I don't disagree such questions aren't the best in interviews, a bit of history also doesn't hurt. Also, in some circles, the SOLID acronym is gaining traction, and Liskov substitution principle is the L.
Many programming people are aware of Richard Gabriel's essays on why C and related languages became the dominant programming paradigm (
https://www.jwz.org/doc/worse-...). In essence, sometimes those ugly compromises are just what people really want (or even need).
Many have argued that JavaScript is a excellent example of this phenomenon, but there's one big difference. Everybody is trying to replace JavaScript. Some are bolting on new keywords to the language, others are pushing features and some have just started using TypeScript. Here's the thing. The history of C, the "worse" language in the article, had a long history of usage (still does), and C++, for better and worse, sought only to argument, not replace C. In the end, JavaScript is not worse, it is broken.
We know that strictly typed object oriented languages do really well for UI based systems. The notion of hierarchy of control classes works. The Document Object Model even acknowledges that by suggesting it too fits that model (but really doesn't do that). If they really want to make an UI ecosystem, they will either continue to hack it together at an increasing expense, or they will get an ecosystem that does it better. Personally, I think the hacks will go on for a long time, because cross platform UI markup, programming frameworks and a new language for that all? Very difficult to do, and there is too much invested in the "Web way" to just steal what works from Microsoft, Apple, Android and so on.
And, the thick client model is making inroads and maybe that will continue. Mobile apps are a thing, maybe desktop apps will gain traction as people realize you can still gain similar levels of control and data collection with those as web pages (sad, but that's how we pay for things now).
In the end, language design is very hard. It's actually not hard to hack up a bad version of Scheme or Lisp (that's what JavaScript is). It is very hard to fix all the problems if your language is a success. A proper set of fundamental types matter. Lexical scoping matters. Proper typing and a effective type model matters. And that's not even talking about the core frameworks that a good language needs, because that's a whole new set of challenges. I just hope that if there is a JavaScript replacement, that they follow in the fine programming language tradition of just stealing what works and carefully replacing what doesn't. C++ stole from C, Java stole from C++, C# stole from Java (and Delphi). F# stole from Haskell, Haskell stole from OCaml which stole from ML and everybody steals from Scheme and Common LISP now. Just do it and don't be too clever about it.