What's worked in Computer Science: 1999 vs. 2015 (2015) • Hacker News Board

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#111

Post by anon291 » Sat, Mar 16, 2024, 3:43 AM UTC

ildjarn wrote: post #43

silvestrov wrote: post #18

I'd say that " pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. records in Java. You get most of the benefit of FP while keeping all of the other good stuf from an imperative language.

What mainstream languages have a good suite of FP features though? If you try to write mostly pure code in Java I’m afraid you’re in for a bad time, despite the (big!) improvements of records and lambdas. Minimum viable FP starts at OCaml, F#, Scala and Closure, yet none of these are mainstream.

Hold on... Purity and functional programming are different things. Functional programs can be pure but not necessarily.

Functional programming means functions are first class citizens and can be constructed on the fly. Modern python, c++, rust, even java now do this.

Purity is a nice to have (and arguably rusts borrow system enforces a kind of purity).

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#112

Post by dehrmann » Sat, Mar 16, 2024, 4:47 AM UTC

macintux wrote: post #54

silvestrov wrote: post #18

I'd say that " pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. records in Java. You get most of the benefit of FP while keeping all of the other good stuf from an imperative language.

Hybrid languages are sub-optimal in a lot of ways. One of the joys of functional programming are the guarantees that imperative languages can't offer (primarily immutability).

> Hybrid languages are sub-optimal in a lot of ways.

The real world is messy and stateful.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#113

Post by dehrmann » Sat, Mar 16, 2024, 4:57 AM UTC

jayd16 wrote: post #21

I guess from some sense, all web apps and all GUI apps using the GPU are using parallelism. That's almost everything. Those are both leveraging shared-nothing type architectures so you can think in a single thread and apply it to concurrent work loads for parallelism. Does that not count? What would satisfy this category?

I think the dream of parallelism in 1999 was that CPUs aren't going to get much faster in terms of clock cycles, so how will algorithms run on more data. This is a bit dumbed-down, but things like sorting in parallel.

It turns out that local data didn't quite scale like that, we got more ram and SSDs, and that coordination usually makes small-scale parallel algorithms prohibitively expensive. Where parallelism does work today is some flavor of SIMD like vector instructions, parallel matrix multiplication on a GPU, or map-reduce.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#114

Post by tubthumper8 » Sat, Mar 16, 2024, 5:18 AM UTC

gardenhedge wrote: post #82

tubthumper8 wrote: post #70

Earlier quoted context omitted.

Definitely agree that mainstream languages are adopting functional features, but records aren't a functional feature. Records are basic data modeling and something that has been around since the beginning of programming languages, whether procedural or functional. It's one of the bare minimums of having a type system, and Java didn't have this due to the misguided belief that "everything is an object". I think record…

Java records are object-oriented construct

Maybe. It depends what the definition of "object-oriented" is, which depends what the definition of "object" is. Neither of which has any semblance of agreement among programmers.

Many people would define an object as something that has externally visible behavior and internally hidden _data_. Objects could never be compared to each other for equality, because one could not access the internal data, only its public behavior. However, Java records can be compared for equality which objects would not.

Java records also cannot be extended from. Inheritance is the only uniquely OOP feature, which doesn't apply here either.

So I'm not sure that Java records are an object-oriented construct. First, the precise definition of OO should be established, and then we'll see

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#115

Post by paulddraper » Sat, Mar 16, 2024, 6:10 AM UTC

ildjarn wrote: post #43

silvestrov wrote: post #18

I'd say that " pure Functional programming" has become a no. But "Functional programming approach" has been subsumed into existing programming languages, e.g. records in Java. You get most of the benefit of FP while keeping all of the other good stuf from an imperative language.

What mainstream languages have a good suite of FP features though? If you try to write mostly pure code in Java I’m afraid you’re in for a bad time, despite the (big!) improvements of records and lambdas. Minimum viable FP starts at OCaml, F#, Scala and Closure, yet none of these are mainstream.

Java streams.

java.time

Valhalla even

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#116

Post by mcbishop » Sat, Mar 16, 2024, 6:22 AM UTC

bananabiscuit wrote: post #59

abainbridge wrote: post #29

Earlier quoted context omitted.

Yep. RISC was interesting when gate budgets for CPU pipelines were seriously limited. It was interesting because before RISC the industry had been merrily spending the gate budget increase on adding lots of use-specific instructions. The RISC people pointed out that if you removed support for all the fancy instructions you had enough gate budget for the ALU to be nicely pipelined, and then you could wind up the clock…

Is there something about RISC that is still makes it better than CISC when it comes to per-watt performance? Seems like nobody has any success making an x86 processor that's as power efficient as ARM or RISC.

A great discussion on this: Lex Fridman's interview of David Patterson.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#117

Post by ildjarn » Sat, Mar 16, 2024, 8:16 AM UTC

anon291 wrote: post #111

ildjarn wrote: post #43

Earlier quoted context omitted.

What mainstream languages have a good suite of FP features though? If you try to write mostly pure code in Java I’m afraid you’re in for a bad time, despite the (big!) improvements of records and lambdas. Minimum viable FP starts at OCaml, F#, Scala and Closure, yet none of these are mainstream.

Hold on... Purity and functional programming are different things. Functional programs can be pure but not necessarily. Functional programming means functions are first class citizens and can be constructed on the fly. Modern python, c++, rust, even java now do this. Purity is a nice to have (and arguably rusts borrow system enforces a kind of purity).

> Functional programming means functions are first class citizens and can be constructed on the fly.

FP is much more than this one language feature.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#118

Post by ildjarn » Sat, Mar 16, 2024, 8:21 AM UTC

gardenhedge wrote: post #82

tubthumper8 wrote: post #70

Earlier quoted context omitted.

Definitely agree that mainstream languages are adopting functional features, but records aren't a functional feature. Records are basic data modeling and something that has been around since the beginning of programming languages, whether procedural or functional. It's one of the bare minimums of having a type system, and Java didn't have this due to the misguided belief that "everything is an object". I think record…

Java records are object-oriented construct

OOP is about bundling state and behaviour into units that hide their internal mechanisms by some kind of interface.

Records can have no state - compared to regular classes - so they are an anti-OOP feature.

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#119

Post by abainbridge » Sat, Mar 16, 2024, 11:04 AM UTC

thesz wrote: post #85

abainbridge wrote: post #75

Earlier quoted context omitted.

Interesting. An R2000 did run programs faster than a 80386, right? This was a few years before my time. From a quick google now, it looks like the R2000 was about 3x better than the 80386 at Dhrystone MIPS/MHz. I guess an accurate comparison of how the R2000 and 80386 spent they gate budget and what they got in return would involve a lot of detail. I remember my compsci professor giving us the computer architecture c…

My point is that you cannot get design much faster in terms of clock frequency by just pipelining. Pipeline unrolls state machine and overlaps different executions of the state machines. But the bottleneck, which is addition, is there in all designs and you need additional effort to break it. (also MIPS has [i]ntelocked [p]ipeline [s]tages - that "IPS" in MIPS; I implemented it, I know - exception in execution should…

I think the Wikipedia page [1] agrees with your main point.

I said pipelining allowed you to increase the clock rate, which isn't the best thing to say.

The wiki page says, "instruction pipelining is a technique for implementing instruction-level parallelism within a single processor. Pipelining attempts to keep every part of the processor busy with some instruction by dividing incoming instructions into a series of sequential steps (the eponymous "pipeline") performed by different processor units with different parts of instructions processed in parallel."

And, "This arrangement lets the CPU complete an instruction on each clock cycle. It is common for even-numbered stages to operate on one edge of the square-wave clock, while odd-numbered stages operate on the other edge. This allows more CPU throughput than a multicycle computer at a given clock rate, but may increase latency due to the added overhead of the pipelining process itself."

[1] https://en.wikipedia.org/wiki/Instruction_pipelining

Re: What's worked in Computer Science: 1999 vs. 2015 (2015)

#120

Post by anon291 » Sat, Mar 16, 2024, 12:55 PM UTC

ildjarn wrote: post #117

anon291 wrote: post #111

Earlier quoted context omitted.

Hold on... Purity and functional programming are different things. Functional programs can be pure but not necessarily. Functional programming means functions are first class citizens and can be constructed on the fly. Modern python, c++, rust, even java now do this. Purity is a nice to have (and arguably rusts borrow system enforces a kind of purity).

> Functional programming means functions are first class citizens and can be constructed on the fly. FP is much more than this one language feature.

Yes, the field of FP is much more, but the core of FP is that. A language doesn't become non-FP simply because it has some imperative abilities, or logic programming builtin, etc.