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

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

danluu.com

Post reply on HN
Print view View original

71–80 of 155 posts

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

#71

Post by marcosdumay »

bluescrn wrote: post #58
bdw5204 wrote: post #47

Earlier quoted context omitted.

At the moment, x86 is mainly hanging on in legacy spaces because of backward compatibility. Everything new is RISC including Apple's newer Macs. Windows computers still run on x86 because people buy Windows to run legacy code. Playstation and Xbox run on x86 because that makes porting games from Windows more convenient. My view, even when I was studying RISC V in grad school around 6 years ago, was that RISC is clear…

> At the moment, x86 is mainly hanging on in legacy spaces because of backward compatibility. x86 platforms also tend to let you run your own code, and are associated with 'proper computers/proper operating systems' where you have full access to your own device. The vast majority of non-x86 devices are of the 'locked down and dumbed-down' variety. Content consumption devices built around monopolistic App Stores and t…

> not just little devices like the Pi

What you are dismissing is by-the-book disruptive competition.

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

#72

Post by acchow »

cgh wrote: post #38
pyuser583 wrote: post #26

Earlier quoted context omitted.

TS really stands out as amazing. It’s realized a lot of the promise of strong typing.

How so? It looks a lot like a less-rich Java, whose type system has existed for literally decades. In fact, the generics syntax and type erasure was directly influenced by Java.

Tho Typescript does have structural types, mapped types, union types, optional types, type aliases..... Bunch of useful type features.

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

#73

Post by canadianfella »

marcosdumay wrote: post #69
Terr_ wrote: post #61

Earlier quoted context omitted.

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.

[dead]

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

#74

Post by jcranmer »

stevefan1999 wrote: post #14

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…

RISC/CISC is near the top of the list of "things emphasized in education that bear little relevance in practice". RISC isn't so much a single coherent design idea as a collection of ideas, some of which have won out (more register files), and some of which haven't (avoid instructions that take multiple clock cycles). The architectures from the days the "debate" was more relevant that have had the most success are the ones which most thoroughly blurred the lines between classical RISC and CISC--namely, Arm and x86.

> I think there is another blurry line between superscalar and VLIW architecture, too.

No, the line is pretty damn sharp. The core idea behind VLIW is that having hardware doing dynamic scheduling (as superscalar does) is silly and the compiler should be responsible for statically scheduling all instructions. The only blur here is that both VLIW and superscalar envision having multiple execution units that can be simultaneously scheduled with work, but who is responsible for doing that scheduling is pretty distinct.

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

#75

Post by abainbridge »

thesz wrote: post #53
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…

You are not quite right about pipelined design being faster. At least, not without substantial effort. https://en.wikipedia.org/wiki/R2000_microprocessor "The R2000 is a 32-bit microprocessor chip set developed by MIPS Computer Systems that implemented the MIPS I instruction set architecture (ISA)..." "The R2000 was available in 8.3, 12.5 and 15 MHz grades..." https://en.wikipedia.org/wiki/I386 "The Intel 386, origin…

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 course in about 1997, and he dispaired at how all the clever RISC stuff in the Patterson and Hennessey seemed irrelevant when Intel could just throw money at the implementation (and fab, I guess) and produce competitive chips despite their (allegedly) inferior architecture.

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

#76

Post by za3faran »

ildjarn wrote: post #45
cgh wrote: post #38

Earlier quoted context omitted.

How so? It looks a lot like a less-rich Java, whose type system has existed for literally decades. In fact, the generics syntax and type erasure was directly influenced by Java.

Typescript has far more powerful type constructs than Java.

Such as?

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

#77

Post by jnxx »

caditinpiscinam wrote: post #30
devjab wrote: post #2

The phone networks and basic infrastructure for the internet in many countries wouldn’t work without Erlang. Which is functional… but maybe that doesn’t count?

On the other hand, the banking infrastructure in many countries wouldn't work without COBOL, scientific research wouldn't work without MATLAB, and healthcare wouldn't work without MUMPS. Many languages and paradigms, good and bad, end up entrenched within an industry.

> COBOL

> MATLAB

> MUMPS

One of each uglier than the one before. But:

Is there something we can learn from these examples? Are there good reasons for these languages being adopted? And are the Racket designers with their approach of "a language to define interoperable DSLs" up to something?

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

#78

Post by jnxx »

sophacles wrote: post #52
hosh wrote: post #15

Do GPUs and TPUs for AI count towards parallelism?

I don't think so, they still tend to fall into the "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." statment, for the most part.

What could be a different case is Clojure. But I am not sure, and the performance characteristics of Clojure make it well-suited for server-style concurrency, but not so much for high-performance parallelism.
Post reply on HN