Live data from Hacker News

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

danluu.com

61–70 of 155 posts

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

#61

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).

The moment you have any database or filesystem or remote-service, the hybridization starts anyway.

Sure, technically a single computer's local RAM is being managed with strict guidelines, but that correlates less and less to overall application state and behavior these days.

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

#62
> Lampson further remarks that to do parallel programming, what you need to do is put all your parallelism into a little box and then have a wizard go write the code in that box. Not much has changed since 2009.

I would like to see a reevaluation of this take with respect to Rust. When we're talking about Rust's safety features, we usually focus on memory safety, because that has the biggest impact on security. But there are lots of memory safe languages, and I think it's actually Rust's thread safety features that are the most unique. (Lots of shared type system machinery between both sets of features.)

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

#63
post #56
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.

I code in C# and use a ton of LINQ when writing business logic. It's FP-ish enough to avoid logic mistakes. The mediator design pattern, which is kind of bringing another FP paradigm to the OO world, also features heavily.

I think this is the point really, not that mainstream, "general purpose" languages support FP well, but that FP ideas and aspects have been adapted into many of them.

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

#64

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.

Have there been recent attempts? Maybe it's just, like, speciation, by this point in time.

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

#65

I would like to suggest that the classical taxonomy of RISC/CISC dichotomy is basically non-existent nowadays -- namely because both sides have influenced each other. It is well known that CISC has taken a lot of inspirations from RISC designs (such as having a lot more registers in x64), and RISC designs also taken some inspirations from CISC (such as having SIMD/vectorization units). In other words, the line betwee…

I agree that the line is pretty thin, but would draw it as: fixed-width versus variable-width. I think the M? line of Apple CPUs, with extremely-wide parallel decode, has been a game changer. The performance per watt is really off the charts. That's partly due to integrated RAM and all, but mostly due to microarchitectural changes, which I believe to be a massive step function in superscalar bandwidth (wider decode, huge ROB, huge numbers of ports). It seems like the power-hungry decode stage has been tamed, and I think this is because of fixed-width instructions in arm.

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

#66
post #51
post #6

Fascinating about how ARM has made tremendous strides in the “high end” market since 2015. I would argue that I would categorize RISC as a “yes” with its absolute dominance on mobile and now moving into data center not to mention all the embedded use cases.

I still have to agree with Dan. "If there's any threat to x86, it's ARM, and it's their business model that's a threat, not their ISA."

I would have believed this before the M1, but now I think fixed-width instructions are great for parallel decode, so there's a real threat now which is attributable to RISC.

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

#67
post #9

> Fancy type systems We are taking steps to this direction. By adding optional typing to dynamic languages Python and JavaScript/TypeScript. And then type checker tools and local programming style guides are making using these maybe less optional, and more mandatory.

Sum types have definitely been making a big splash. I'd also look at how C++ has added concepts and Go has added generics. Local type inference is also commonplace too, even Java has it.

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

#68
post #9

> Fancy type systems We are taking steps to this direction. By adding optional typing to dynamic languages Python and JavaScript/TypeScript. And then type checker tools and local programming style guides are making using these maybe less optional, and more mandatory.

Those would be considered basic type systems. For "fancy", you gotta dive deeper into the lambda cube (tho generics I guess in 1999 would be fancy and one step in).

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

#69
post #61

Earlier quoted context omitted.

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).

The moment you have any database or filesystem or remote-service, the hybridization starts anyway. Sure, technically a single computer's local RAM is being managed with strict guidelines, but that correlates less and less to overall application state and behavior these days.

The promise of FRP was to solve this problem. It makes "state change" a first class object, and organizes your code around it.

The problem is that nobody made an usable FRP system yet. It's not obvious why it's so hard, and everything feels like it should be easy. But everybody just keep failing.

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

#70

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.

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 records being added is more of a symptom of that belief weakening.

There are functional features that have made it over to Java which are the things related to functions, i.e. lambdas and such which are a welcome addition.

Post reply on HN