Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Object Oriented Programming

medium.com

Post reply on HN
Print view View original

321–330 of 355 posts

Re: Goodbye, Object Oriented Programming

#321

Post by eru »

discreteevent wrote: post #299
eru wrote: post #279

Earlier quoted context omitted.

Yes, VBA is a break away from the nice purely functional world of spreadsheets. Simon Peyton Jones once did some work on giving Excel more programmatic power without having to go to VBA. http://research.microsoft.com/en-us/um/people/simonpj/Papers...

The paper deals with more examples of calculations: convert fahrenheit to celcius, calculate volume. It does not cover interactive applications. I hope you are not redefining the problem to fit the solution which can be a weakness of pure mathematicians and functional programmers (and negative though it is I have to add: Its a waste of everybody's time. It would be much better if people were direct about what their s…

Yes, Excel is limited. Yet, people manage to solve lots of business relevant problems within its constraints.

Excel is very interactive: you can change input and immediately get a different output. (I think you were trying to talk about a different restriction. Excel is very limited in the kinds of inputs and outputs you can make, and even more so in the kind of side-effects you can cause.)

Re: Goodbye, Object Oriented Programming

#322

Post by cousin_it »

eru wrote: post #319
cousin_it wrote: post #294

Earlier quoted context omitted.

Can you use lambda calculus to prove the correctness of quicksort? :-)

Depends on which version you are talking about. If you are happy to prove correctness of tree-sort, which does the same comparisons as quicksort, it's straight-forward. If you want to talk about the clever in-place quicksort, you'll want to talk about a slightly more complicated model. Either implicitly, where you still model everything as lambdas, or explicitly: you can model state (like an array) and its manipulati…

So that would be the traditional analysis of quicksort, mucked up with linear logic terminology so you can't see what's going on.

The sweet spot of lambda calculus is structurally recursive algorithms on trees. You can use it for other kinds of algorithms, but there it just makes things harder, and I've never seen it solve a problem that wasn't solved first by other means.

Re: Goodbye, Object Oriented Programming

#323

Post by rubber_duck »

igouy wrote: post #304
rubber_duck wrote: post #277

Earlier quoted context omitted.

That's not a very strong point -those benchmark sources usually look like "C in language X" and not like "idiomatic use of language X" - I'd bet they don't use immutable data structures and hand optimize code avoiding common patterns in functional programming for perf. Which is my point - there are languages that can compile to similar code as C/C++ if you write similar code - but the idiomatic code is still slower b…

Instead of looking at "benchmark sources" you just seem to be guessing about how the programs are written.

I did look at the source and it seemed that way (imperative code using flat arrays) but I don't know enough OCaml to say with certainty.

I have worked with other functional languages (Clojure) and I have optimized GCed code and it mostly boils down to what I said - writing C/C++ like code in language X to get as close to hardware memory model (avoiding GC by pooling, increasing cache coherence, using value types or manually unfolding data structs, etc.)

I haven't seen a magical way for high level data structures based on trees (used for persistant strucutres) to outperform arrays

Re: Goodbye, Object Oriented Programming

#324

Post by lmm »

seanmcdirmid wrote: post #312
lmm wrote: post #263

Earlier quoted context omitted.

> And how often does that occur in practice for most of the programs people write? Even the most hardcore Haskell programmer isn't going around proving theorems about their modules beyond what the type system can provide for free (and that is true of statically typed OO also). "What the type system can provide for free" isn't static. Part of working in that kind of language is structuring your code such that importan…

> "is this piece of code equivalent to this other piece of code?" is what I'd venture to suggest programmers spend most of their day asking, and Haskell-like languages make that easier to answer. It is a boring question to ask, and one that doesn't come up much in my work. Does this mean Haskell-like languages are not appropriate for my domain?

It means your domain is alien to mine, and I can't tell you what is or isn't appropriate.

For me programming is about automating some business process or at least something you already know how to do, so it's a case of: 1) transcribe the doing into plain code 2) factor out patterns/redundancy in the code. (In practice this is interleaved, and 2) results in building up a language for expressing the domain in code which in turn simplifies 1) - indeed, when adding new functionality it's often a case of first transforming the current code into a representation that makes the new functionality simple). 2) is where the vast majority of the work lies and what takes up the time. Just as good writing is good editing, good coding is good refactoring. At least in my domain.

Re: Goodbye, Object Oriented Programming

#325

Post by vegabook »

pjmlp wrote: post #267
vegabook wrote: post #115

Earlier quoted context omitted.

yep... I was just dunking a hobnob while writing some good old imperative C. Did anybody notice that Vulkan, "the future" of graphics APIs, doesn't f*ck around with OO or Functional?

However Metal, DirectX and the console APIs do. Khronos are the ones that still leave in pure C world. Hence why most researchers went to CUDA in terms of language support and now they are trying to catch up with SYSCL and SPIR.

yeah, but they're not the future.

Re: Goodbye, Object Oriented Programming

#326

Post by pjmlp »

vegabook wrote: post #325
pjmlp wrote: post #267

Earlier quoted context omitted.

However Metal, DirectX and the console APIs do. Khronos are the ones that still leave in pure C world. Hence why most researchers went to CUDA in terms of language support and now they are trying to catch up with SYSCL and SPIR.

yeah, but they're not the future.

The future is what the majority game developers with weight in the industry decide to use.

Re: Goodbye, Object Oriented Programming

#327

Post by moron4hire »

Shorel wrote: post #310
moron4hire wrote: post #165

No project ever failed specifically because of the paradigm--or programming language, even--used to implement it. Project failure is a people problem.

Monotone (when compared to git). https://en.wikipedia.org/wiki/Taligent https://en.wikipedia.org/wiki/AI_winter These are two C++ and one Lisp failure. And language did play a big role in each failure.

You have completely misinterpreted these projects.

Re: Goodbye, Object Oriented Programming

#328

Post by qwertyuiop924 »

rubber_duck wrote: post #323
igouy wrote: post #304

Earlier quoted context omitted.

Instead of looking at "benchmark sources" you just seem to be guessing about how the programs are written.

I did look at the source and it seemed that way (imperative code using flat arrays) but I don't know enough OCaml to say with certainty. I have worked with other functional languages (Clojure) and I have optimized GCed code and it mostly boils down to what I said - writing C/C++ like code in language X to get as close to hardware memory model (avoiding GC by pooling, increasing cache coherence, using value types or m…

No, that won't happen, but a lot of the code that you write in a functional language can be optimized far better than another language, because the compiler has more, stronger guarantees about your code.

Re: Goodbye, Object Oriented Programming

#329

Post by qwertyuiop924 »

justin_vanw wrote: post #317
qwertyuiop924 wrote: post #159

Earlier quoted context omitted.

>I don't have any idea what you're talking about when you say 'functional came before OO'. Lambda calculus is technically the first functional language, and predates computers. But if we're talking about actual programming languages, SASL, one of the earliest functional languages actually implemented, was released the same year as Smalltalk, and was influenced by the older ISWIM, which was never implemented. >I'm gue…

How is 'the same year as smalltalk' predating it? Simula was working in like '67, which is like 5 years before smalltalk. My point is that functional languages do not predate OO languages, and if anything come later, and you never really addressed that.

>How is 'the same year as smalltalk' predating it?

That's just the first one that was implemented. The IDEAS reach far further back. ISWIM was '66, it it's not the oldest.

>My point is that functional languages do not predate OO languages, and if anything come later, and you never really addressed that.

Between my points on Lisp, ISWIM, Lambda Calculus, and others, I think I did that quite adequately.

Re: Goodbye, Object Oriented Programming

#330

Post by seanmcdirmid »

lmm wrote: post #324
seanmcdirmid wrote: post #312

Earlier quoted context omitted.

> "is this piece of code equivalent to this other piece of code?" is what I'd venture to suggest programmers spend most of their day asking, and Haskell-like languages make that easier to answer. It is a boring question to ask, and one that doesn't come up much in my work. Does this mean Haskell-like languages are not appropriate for my domain?

It means your domain is alien to mine, and I can't tell you what is or isn't appropriate. For me programming is about automating some business process or at least something you already know how to do, so it's a case of: 1) transcribe the doing into plain code 2) factor out patterns/redundancy in the code. (In practice this is interleaved, and 2) results in building up a language for expressing the domain in code whic…

I do research working on new experiences, like live programming environments. Nothing is really known, there is no spec, everything is a design prototype, code is disposable in a fail-fast kind of way. So I'm pretty extreme, I can see where other domains are very different.
Post reply on HN