More shitting on JS. It's ok though.
Chris Lattner on the Realm WWDC 2017 Swift Panel
91–100 of 120 posts
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#92> Look at Javascript or any of these other languages out there. They started with a simple premise (“I want to do simple scripting in a web browser”) and now people are writing freaking server apps in it. What happened there? Is there a logical leap that was missed? How is this a good idea? [Audience laughs] Sorry, I love Javascript too. Iʼd just love to kill it even more. Emphasis mine. Not that I disagree completel…
It's interesting to see people talk a bunch about how nothing is good or bad, it's all a bunch of trade offs, and then they eventually tip their hand. I think people should just come out and say what they think is good or bad.
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#93Earlier quoted context omitted.
Who are these people, were they professional programmers? How hard were they trying? Perhaps they just wanted a better Java? Where I work we do have some business people successfully writing Haskell. I've worked on very large codebases in many large organisations with C++, Java and Haskell. Haskell certainly wasn't the horror story.
> Who are these people, were they professional programmers? How hard were they trying? Perhaps they just wanted a better Java? How hard should they have tried? Should they have burnt the midnight oil? This Java you talk about, is still in the top 1-3 languages by programmers, is it not? And supposedly Haskell is easier (according to the parent comment) but at the same time needs people to try harder to get it than Ja…
> This Java you talk about, is still in the top 1-3 languages by programmers, is it not?
I'm disappointed that you appear to judge technology based on popularity. By this argument, JavaScript trumps Java.
> And supposedly Haskell is easier (according to the parent comment) but at the same time needs people to try harder to get it than Java? It can't be both...
I can assure you, having learned both, that understanding Java and all its idioms/patterns is at least as hard as learning Haskell, especially if one seeks to build concurrent software (where the intricacies of Java's complex memory model cannot be ignored).
Because of the immense amount of investment already made, likely these people give up when they realise they cannot make much use of it in Haskell, at least not at first.
> No, but it was the new novelty on greenfield staff.
You've made an incorrect assumption. The Haskell codebases I have worked on, in both cases, have been large and over a decade old.
Anyway, my original post was about the controversy of subtyping, not Haskell versus Java.
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#94I think that very important aspect of achieving world domination for Swift is front-end development for Web (with compiler targeting JS or Web Assembly)
In a way many iOS and macOS applications are front-end software. It much more makes sense to make Swift available for other kinds of front-end development that for server-side coding.
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#95Earlier quoted context omitted.
> The issues with inheritance based OOP Inheritance is just one of multiple facets of safe code reuse in OOP. Aggregation, composition, encapsulation are as are much as fundamental notions in OOP as inheritance. So i think reducing OOP in general, and java in particular to "inheritance based OOP" is a miss characterization > are that it fits very few problems well, that it usually causes lots of problems and that man…
Aggregation and composition are almost the same, are not distinguished in e.g. Java and exist in pretty much every rogramming language regardless if they are object-oriented. Inheritance is presented everywhere as the go-to method for structuring everything in languages supporting inheritance. The whole java class library consists of huge class hierarchies. Every non-trivial java code base I have seen is heavily infe…
Patterns are just observed recurrences in a large sample of artifacts. Many people naively see the design patterns book as instructive, when in reality it is just retrospective.
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#96Earlier quoted context omitted.
ML languages are simpler, but require paradigm shift.
Shouldn't the paradigm shift factor into the calculation of the simplicity? "It's simple once you've changed how you think about stuff" just hides the complexity in a prerequisite.
> Shouldn't the paradigm shift factor into the calculation of the simplicity?
Not at all. You sound like you're looking for excuses not to learn something new!
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#97Earlier quoted context omitted.
> The issues with inheritance based OOP Inheritance is just one of multiple facets of safe code reuse in OOP. Aggregation, composition, encapsulation are as are much as fundamental notions in OOP as inheritance. So i think reducing OOP in general, and java in particular to "inheritance based OOP" is a miss characterization > are that it fits very few problems well, that it usually causes lots of problems and that man…
> Aggregation, composition, encapsulation are as are much as fundamental notions in OOP as inheritance. You say that as if these things are not just as easily expressed in FP -- if not even easier. Aggregation is just records-of-records. Encapsulation is just "abstract data types", e.g. ML modules with abstract members, or non-exported data constructors in Haskell. Another option would be simply closing over whatever…
OOP is simply programming with objects. You can do that in a language of functions, you can also program with functions with a language of objects.
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#98Earlier quoted context omitted.
Who are these people, were they professional programmers? How hard were they trying? Perhaps they just wanted a better Java? Where I work we do have some business people successfully writing Haskell. I've worked on very large codebases in many large organisations with C++, Java and Haskell. Haskell certainly wasn't the horror story.
> Who are these people, were they professional programmers? How hard were they trying? Perhaps they just wanted a better Java? How hard should they have tried? Should they have burnt the midnight oil? This Java you talk about, is still in the top 1-3 languages by programmers, is it not? And supposedly Haskell is easier (according to the parent comment) but at the same time needs people to try harder to get it than Ja…
He said Haskell was simpler than C++ which might be true. Doesn't mean it's easier. I'm more familiar with F# and C#. I'm guessing that the F# language is simpler in as far as having fewer language concepts. But many people struggle and would find it more difficult, at first. Brainfuck is even simpler yet even harder for many people.
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#99> What irritates me is when people say classes are bad. Or subclassing is bad. Thatʼs totally false. Classes are super important. Reference semantics are super important. If anything, the thing thatʼs wrong is to say, one thing is bad and the other thing is good. These are all different tools in our toolbox, and theyʼre used to solve different kinds of problems. Couldn't agree more
Subtyping adds huge amounts of complexity to type systems and type inference. Dart even chose to have an unsound type system because subtyping and parametric polymorphism (generics in Java) were deemed too hard for Google programmers to understand. The Go designers agreed. Haskell and OCaml are a joy to program in, in part because they (mostly) eschew subtyping. So yes, subtyping is controversial.
Dart is not unsound (anymore), and they rely heavily on nominal subtyping. Ironically, typescript is unsound, and it relies heavily on more functional structural subtyping (in both cases soundness matters not much). Neither language has particularly good type inference. I believe Go is also structural, though without generics, its type system is bound to be simple either way.
Re: Chris Lattner on the Realm WWDC 2017 Swift Panel
#100Earlier quoted context omitted.
ML languages are simpler, but require paradigm shift.
Shouldn't the paradigm shift factor into the calculation of the simplicity? "It's simple once you've changed how you think about stuff" just hides the complexity in a prerequisite.
> Shouldn't the paradigm shift factor into the calculation of the simplicity?
No, because it's path dependency, not complexity.