Some context for people who have limited knowledge of Scala.
Lihaoyi is one of the most prolific coder's, not just in Scala, but in any language. He looks like he is much to humble and modest to claim so himself, so I will do it for him.
Discussions on Scala on HN tends to contain a somewhat large volume of comments that explicitly or implicitly tries to communicate that Scala is a language that is much to complicated to really be productive in. Lihaoyi is a rather clear example of why this is not true. If this random internet citizens endorsement doesn't convince you maybe the book will :)
I think your argument here is counterproductive. Lihaoyi is a prolific coder but most coder like me are average Joe. How can Scala be useful and make average Joe like me productive. The fact that Lihaoyi is a prolific coder in any language does not help selling Scala.
Haoyi makes libraries that are very easy to use, modelling them after popular Python libraries. If you're interested he recently wrote a long blog about the future of Scala being exactly this approach; make easy to use libraries for people like yourself interested in being productive in Scala quickly.
https://www.lihaoyi.com/post/TheDeathofHypeWhatsNextforScala...
The remaining piece of the puzzle is that Lihaoyi's libraries and general approach is exactly what a joe average coder would want. There is minimal use of advanced features, it is all quite straightforward and simple.
There are other productive contributors in Scala, but among them I would rate Lihaoyi to be among the least "magical". The fact that he is both practical and productive is what makes him unique. I guess my point was that there is a lot to be learned from that. For some nice examples of what it looks like in practice see his series of blogposts titled "how to work with x in scala".
My personal pitch for Scala comes down to two things: developer experience and suitability for projects of all scales.
I frequently miss basic features when I'm using other languages. Some of these include:
- Its system for basic immutable data structures.
- Pattern matching for very concisely extracting and branching on data.
- A really nice immutable collections library.
- Scalacheck for generative testing, driven by the type system.
- A bunch of other nice-to-have syntactic features.
From the perspective of building projects, I appreciate that it can model anything from quick utilities to simple web services to concurrent systems, all within a single JVM. And with tools like Akka, you can move that to distributed systems without having to add external software you have to operate.
I think the parent is just giving background about the author of the book, who wrote all of those tools mentioned. I don't think they're only trying to convince you that Scala is easy, but maybe I'm reading it incorrectly.
SQL is designed for rows of flat data. GraphQL is designed for nested data. It's two very different use cases. Trying to say one is better than the other completely misses the point.
That is no longer exclusively the case. SQL is used in plenty of places to query nested and semi-structured data. In fact I use it on a daily basis. Eg: avro data in/from Kafka, "json" data from MongoDB.
Do you think any GraphQL api backed by a row based data store is a mistake and should be some kind of SQL api instead? The data could be represented either way so I don't really think it matters.
No. You miss the point. SQL has proven robust over a broad set of types of data. People have tried to come up with new systems for objects (OODB), JSON documents (Mongo), and so on. All were disasters. It turned out SQL was the answer all along.
It turns out a generic tool which works well over many use-cases beats a tool which only works in one use-cases. SQL seems to be that tool.
It's possible to do nested data with SQL too.
I'll believe GraphQL is better when I see a case when it works better. So far, the only cases I've seen were from people who didn't fully grok SQL.
I'll mention GraphQL has a completely separate use-case as a replacement for RESTful APIs, where it's not really acting so much as a query language as an API layer. I think it might have some uses there, but as nedbat points out in the thread, it'd be possible to use SQL as a replacement for RESTful APIs too, and it'd probably do better than GraphQL (before you start screaming about security, read netbat's posts; he is definitely NOT talking about a thin layer over a database).
> No. You miss the point. SQL has proven robust over a broad set of types of data. People have tried to come up with new systems for objects (OODB), JSON documents (Mongo), and so on. All were disasters. It turned out SQL was the answer all along.
Document DBs have failed in the general case because most data is relational. OODB is still alive and well; Postgres implements some OODB features, and I would argue graph databases are an implementation of an OODB.
I also think you're lumping SQL and RDBMS together into one term. It's entirely possible to have an RDBMS that does not use SQL; likewise it's possible to have a system that is not an RDBMS that does use SQL. There are addons for MongoDB that let you speak SQL to it.
> I'll believe GraphQL is better when I see a case when it works better. So far, the only cases I've seen were from people who didn't fully grok SQL.
Most of the advantages come from introducing an intermediary data broker (the GraphQL server). As a query language, I do find GraphQL drastically simpler than SQL. We can compare queries for a person, their parents, and their children. I can guarantee the GraphQL query is shorter and more legible. That comes at the cost of flexibility, which I wholly acknowledge.
> I'll mention GraphQL has a completely separate use-case as a replacement for RESTful APIs, where it's not really acting so much as a query language as an API layer. I think it might have some uses there, but as nedbat points out in the thread, it'd be possible to use SQL as a replacement for RESTful APIs too, and it'd probably do better than GraphQL (before you start screaming about security, read netbat's posts; he is definitely NOT talking about a thin layer over a database).
This is the only use case that I'm aware of. There is dgraph, which is a graph database that speaks in GraphQL natively, but they've basically just integrated the API server into the database itself (which I'm not arguing for or against, I just think it's still basically the same stack).
I don't find GraphQL to be easier to learn than SQL. But SQL is a much more helpful and generalizable skill.
That's the second-system syndrome. Once you tack all the stuff on needed for something "simple" to be useful, it gets as complex as the original. Only all the "SQL replacements" do less, and do it less well.
If you want simple, RESTful APIs are a way to go.
(And no, your average analyst doesn't know GraphQL either -- and if you want to go down that learning curve, might as well learn how to do SQL properly in these contexts instead)
I think you'll find that SQL is one of the most widely understood languages. Current programmer education deemphasizes it, but in basically any analytics space, SQL is the lingua franca.
"Understood" is a strong word. There are lots of people with a basic understanding of SQL but who can't write complex queries to do things like represent tree structures and cyclic relationships. I don't think your average analyst can do that.
And even if all the analysts in the world could do such a thing, that doesn't matter if they're not building the applications.
I've written difficult and complex SQL, over a 20+ year period, along with taking a deep dive into relational theory via Chris Date. I'd say I fully grok SQL; well I'm still learning as are the majority of us who are not Chris Date. It's a vast and comolex topic, enough that there are experts specific to it for an entire career. Graphql is great because it's far simpler. I learned how to use it on the front-end in a matter of hours. And learned how to implement it on the backend in a few weeks. It's a different level of abstraction, and shields our front-end devs from many underlying complexities, including but not just the SQL.
I do see your point that for many applications you want the result in a tree, not in a list of rows. I think there should be a relational query language that lets you map from one schema to another schema (or potentially a subset of an existing schema), allowing the result to be another graph (or database in the parlance of RMDBs)
Magnificent piece of technology! Except it gets defeated by a 2$ skimask. This kind of fearmongering isn't really useful as a way of creating political change. If you want people to participate in a reasonable and constructive dialog then convince them to do so with reasonble and constructive arguments.
Do you know that person identification based on gait detection is actively developed and getting decent results? Same with voice.
Also in a really grim scenario, could threaten/kill anyone that hides their face, be it with a skimask, burka or whatever. Or even require positive identification, that your face is found in the database.
I don't have anything valid to back up my claims here, so take what i have with a grain of salt unless you find external validation for it. That being said i will venture a guess:
Yes and no. Neural networks have a lot of nice properties like being easier to grasp, easier to parrallelize(?) and have better tools which i guess is because neural networks are applicable to more problems than SVM's because they are extensible.( see https://en.wikipedia.org/wiki/Recurrent_neural_network for example).
Either way SVM's still do what they do very nicely and in the field of "Human Activity Recognition" where i did my thesis neural networks are practically never used but SVM's pop up from time to time.
Right, scalability is a good point to consider. Along the same vein, my last ml job we ended up using gradient boosting which worked really well, but definitely does not scale to big data (afik.) Robustness is another thing to consider, both svm's and neural networks need a reasonable amount of data-massaging before they behave themselves. Hence the success in image processing where every pixel can be treated equally.
No you may not. Sexual assualt is a despicable crime and offenders ought to be castrated, but it does in no way neccesitate nor does it excuse false accusations. Furthermore if your argument should have any validity it should count for other crimes as well. In that case what is the comfortable amount of false accusations of murder? theft? or any other horrible crime you could possibly come up with. To top it off lets engage in a thought experiment, lets assume that the false accusation rate was 50%. Lets imagine that a person is sexually assaulted, how serious is that report going to be taken? Now imagine the same scenario where the false accusation rate is 0.0%, how seriously is the report then taken?
I make no excuse, nor is it an argument. I expected the number of false positives to be on par with the number of false negatives. Said otherwise, the number of false accusations is way lower than the number of instances of rape that never even go reported.
To me, it goes without saying that I wish all of those numbers to converge to the lowest possible value.
Loving the lyrics :D