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

121–130 of 155 posts

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

#121

Post by datavirtue »

kfajdsl wrote: post #42
t43562 wrote: post #17

Earlier quoted context omitted.

IMO the day python types become mandatory there will be a fork. It would be such a total betrayal of it's reason for existing that we would have to invent another untyped or duck-typed language again.

For me the primary purpose of TypeScript is to give my editor information about interfaces so I don’t have to do the menial back and forth of accidentally making a typo in a function name, object param, etc. I find myself using less type hints in Python because the story for REPL driven development is so much better than JavaScript, and that takes most of the pain away.

Giving the editors hints in this case is very expensive.

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

#122

Post by pyuser583 »

skybrian wrote: post #101
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.

I haven’t used Java in many years, but TypeScript’s structural types give it a different flavor than I remember from Java. Unlike in Java, most of the types I define aren’t classes or interfaces. It’s just data that has an expected shape. Check out the design of Zod, for example. I have a bunch of Zod types for the validation of incoming JSON messages. This automatically generates the corresponding TypeScript types t…

In functional programming, a type is just a function that returns a list of possible values. It’s not a class.

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

#123

Post by mike_hearn »

aleign wrote: post #11

What is "capabilities" supposed to mean?

It means that the permission (capability) to do something is encapsulated into an unforgeable bearer instrument that can be stored, passed around and so on. An open file handle (descriptor on UNIX) is a capability, because if you have it you can use it to read and maybe write to the file, and because you can send it to another process, at which point that process also has the capability to read and write that file.

Capabilities are one of those concepts that's a bit like FP or RISC. It sounds elegant but in the real world experience is mixed, so it's rare for a system to rely on it purely. Most real security systems today are built on semi-static permissions granted to domains defined by some third party identity system. Capabilities do get used, but mostly in the sandbox context and mostly as a detail.

So I think Dan is not quite correct that mobile platforms use capabilities. Users assign permissions to specific apps semi-statically there. The lowest levels of the OS may use a small set of capabilities as part of the implementation, but granted permissions are not generally easy to send around to other apps.

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

#124

Post by peterfirefly »

simne wrote: post #91
bananabiscuit wrote: post #59

Earlier quoted context omitted.

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.

> Is there something about RISC that is still makes it better than CISC when it comes to per-watt performance? CLASSIC CISC was micro-coded (for example, IBM S/360 have feature, you could make your custom microcode for compatibility with your inherited equipment, like IBM-1401 machines or IBM-7XXX series, or for other purposes), and RISC was with pipeline from birth. Second thing, as I understand, many CISC existed a…

> CLASSIC CISC was micro-coded

Sometimes. Far from always. Some would have a complicated hardwired state machine. Some would have a complicated hardwired state machine and be pipelined. Some would have microcode and be pipelined (by flowing the microcode bits through the pipeline and of course dropping those that have already been used so less and less microcode bits survive at each stage).

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

#125

Post by simne »

peterfirefly wrote: post #124
simne wrote: post #91

Earlier quoted context omitted.

> Is there something about RISC that is still makes it better than CISC when it comes to per-watt performance? CLASSIC CISC was micro-coded (for example, IBM S/360 have feature, you could make your custom microcode for compatibility with your inherited equipment, like IBM-1401 machines or IBM-7XXX series, or for other purposes), and RISC was with pipeline from birth. Second thing, as I understand, many CISC existed a…

> CLASSIC CISC was micro-coded Sometimes. Far from always. Some would have a complicated hardwired state machine. Some would have a complicated hardwired state machine and be pipelined. Some would have microcode and be pipelined (by flowing the microcode bits through the pipeline and of course dropping those that have already been used so less and less microcode bits survive at each stage).

Please give classic CISC examples, which was not microcoded and why you think they classic.

From my opinion, NONE of microprocessors could be considered classic CISC.

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

#126

Post by timeinput »

simne wrote: post #125
peterfirefly wrote: post #124

Earlier quoted context omitted.

> CLASSIC CISC was micro-coded Sometimes. Far from always. Some would have a complicated hardwired state machine. Some would have a complicated hardwired state machine and be pipelined. Some would have microcode and be pipelined (by flowing the microcode bits through the pipeline and of course dropping those that have already been used so less and less microcode bits survive at each stage).

Please give classic CISC examples, which was not microcoded and why you think they classic. From my opinion, NONE of microprocessors could be considered classic CISC.

The PDP11-20 (the first PDP11) was not microcoded.

The PDP11 is the machine that unix was developed on.

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

#127

Post by simne »

timeinput wrote: post #126
simne wrote: post #125

Earlier quoted context omitted.

Please give classic CISC examples, which was not microcoded and why you think they classic. From my opinion, NONE of microprocessors could be considered classic CISC.

The PDP11-20 (the first PDP11) was not microcoded. The PDP11 is the machine that unix was developed on.

Did you know for what purposes (targets) made mini-computers and why they was limited?

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

#128

Post by fourfour3 »

bdw5204 wrote: post #47
ipython wrote: 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.

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…

> Playstation and Xbox run on x86 because that makes porting games from Windows more convenient.

I expect it helps a lot that AMD can easily provide competitive x86 and GPU cores in one SoC, as they’re already building similar APUs - just with smaller graphics segments?

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

#129

Post by keybored »

sampo wrote: 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.

The author thinks that Formal Methods are a Maybe because chipmakers while Fancy type systems are a No. I think the bar is pretty high for Type systems (in the mind of the author).
Post reply on HN