61–70 of 118 posts
What a confused interview. If the audience is for people who are interested in knowing scala's timeline then saying "isnt Java 8 functional now because it has lambdas" is either dumb or trying to be dumb on behalf of a java audience who doesnt care about the scala timeline.
Or "another language that's becoming popular, Node.js"
> Essentially, the fusion of [functional and object-oriented programming] can have a power that neither of the two paradigms individually can have. I tend to disagree. OOP can borrow some FP stuff (as we see with map/each/select/reject in Ruby for instance, or lambda's in Java); or to take it broader: imperative can borrow some from declarative. But "fusing" the two will cause FP's ease-of-reasoning ("just functions…
So what are you proposing to prevent functional languages form being a complete nightmare from a modularity point of view? (See Haskell.) Module systems aren't much more than castrated object systems, so I don't see a real benefit of picking some half-assed module system over a first-class object system.
I also dont think that Haskell-modules and objects are on the same level, for instance: Haskell's modules do not encapsulate state.
Earlier quoted context omitted.
> Each new release of Delphi attempts to keep as much backwards compatibility as possible to allow developers to continue to use existing code without incompatibility of interfaces or functionality. https://en.wikipedia.org/wiki/Delphi_(programming_language)
I'm pretty sure Delphi died from having to compete with essentially free C# and its better integration with Microsoft's ecosystem. And a little bit from the shifting of the overton window away from paying for languages. And mismanagement of Borland/Inprise. And about a dozen other factors before "lack of (breaking) change in the language".
THE END.
(sadly, as I really liked Borland Pascal)
Earlier quoted context omitted.
I think there's a huge opportunity for FP+OO... but that OO will have to be rethought from first principles (which are lacking in OO). More specifically, I think OO-style code interactions are great but that they need to be separated from ambient mutability, subtyping, subclassing, inheritance, etc. Late binding/open corecursion is really cool however. I would like to see a language which starts with ML modules as a…
I feel that Golang in many ways is on that path, the way it does not allow no-subclassing really got me thinking. > I don't think it would, at the end of the day, look much at all like OO the way that OO appears today Won't it be more like a Actor-oriented thing then?
I'm pretty decent in Haskell and fluent in Go at this point, and it really depends on what you mean by that. Is Go a certain brand of very refined OO? Yes. I've even found certain ideas from PF are surprisingly adaptable [1], the "surprise" being that it's not the usual "Look, Ma, I can map/filter/reduce!" that an OO language borrows from the FP world, which Go is actually really hostile to. (Go does have closures and they are important, but the type system precludes a lot of the "good stuff".)
However, is Go headed in the direction of Haskell? No. It's definitely not. Trying to turn it into Haskell would be nothing but pain. Mutability is pretty fundamental in Go, and while there's a culture of isolating it to goroutines, the language itself does little to help with that.
Earlier quoted context omitted.
A major advantage of typeclass polymorphism vs dynamic polymorphism is that typeclasses enable parameteric polymorphism, and parameteric polymorphism enables reasoning that is lost if types can "pretend" to be a supertype. For instance, in Haskell you can prove a functor instance has at most one implementation (if we disallow diverging values), uniquely given by fmap id === id. GHC can automatically derive it for you…
> For instance, in Haskell you can prove a functor instance has at most one implementation How would one do that?
"The language is the code's biggest API" -- my own words. Breaking that API will result in a new language. Scala, like several other languages (JS, PHP, Perl), has had very little time to iterate on it's syntax before it got widely used. All these languages want/need to make breaking changes to their syntax, at which point they are at risk of becoming fragmented. Python3 was not even so much different, still it was (…
Syntax is absolutely not the issue.
Earlier quoted context omitted.
I think there's a huge opportunity for FP+OO... but that OO will have to be rethought from first principles (which are lacking in OO). More specifically, I think OO-style code interactions are great but that they need to be separated from ambient mutability, subtyping, subclassing, inheritance, etc. Late binding/open corecursion is really cool however. I would like to see a language which starts with ML modules as a…
I feel that Golang in many ways is on that path, the way it does not allow no-subclassing really got me thinking. > I don't think it would, at the end of the day, look much at all like OO the way that OO appears today Won't it be more like a Actor-oriented thing then?
> Essentially, the fusion of [functional and object-oriented programming] can have a power that neither of the two paradigms individually can have. I tend to disagree. OOP can borrow some FP stuff (as we see with map/each/select/reject in Ruby for instance, or lambda's in Java); or to take it broader: imperative can borrow some from declarative. But "fusing" the two will cause FP's ease-of-reasoning ("just functions…
I think there's a huge opportunity for FP+OO... but that OO will have to be rethought from first principles (which are lacking in OO). More specifically, I think OO-style code interactions are great but that they need to be separated from ambient mutability, subtyping, subclassing, inheritance, etc. Late binding/open corecursion is really cool however. I would like to see a language which starts with ML modules as a…
This has already happened. Ideally, good object-oriented code should always prefer immutability over mutability, should prefer interface polymorphism over inheritance polymorphism, should prefer has-a relationships (the OO version of composition) over is-a relationships (subclassing), and so on. Much of this was originally figured out a very long time ago.
So the issue isn't that these standards don't exist; it's that they aren't widely understood among users of object-oriented languages. That, in turn, is because OO is so widely used by so many programmers, including a lot of people with very limited formal training in computer science, that most users of OO languages have very little exposure to any of the literature about what constitutes well-crafted object-oriented code. Certainly less so than in FP, which benefits (in this department) from the fact that it hadn't even begun to escape the ivory tower in any sort of serious way until just a few short years ago. In short, object-oriented programming is a victim of its own success.
It doesn't help that the first really widespread object-oriented language wasn't particularly object-oriented, either.
> Essentially, the fusion of [functional and object-oriented programming] can have a power that neither of the two paradigms individually can have. I tend to disagree. OOP can borrow some FP stuff (as we see with map/each/select/reject in Ruby for instance, or lambda's in Java); or to take it broader: imperative can borrow some from declarative. But "fusing" the two will cause FP's ease-of-reasoning ("just functions…
I think there's a huge opportunity for FP+OO... but that OO will have to be rethought from first principles (which are lacking in OO). More specifically, I think OO-style code interactions are great but that they need to be separated from ambient mutability, subtyping, subclassing, inheritance, etc. Late binding/open corecursion is really cool however. I would like to see a language which starts with ML modules as a…