Live data from Hacker News

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

danluu.com

141–150 of 155 posts

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

#141

Earlier quoted context omitted.

I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code. Records encapsulate data fields within an object, providing a way to model real-world entities.

Very few classes model a real world entity in my experience. Maybe that was the plan but it’s just not the reality of OOP in the industry.

Yeah this is why I always chuckle when people claim that OOP "models the real world".

Oh, because your "FooWidgetController", "FooWidgetService", "FooWidgetRepository" are all real world things?

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

#142

Earlier quoted context omitted.

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.

I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code. Records encapsulate data fields within an object, providing a way to model real-world entities.

> I would say OOP revolves around the concept of modeling real-world entities or concepts as objects in code.

This is just data modeling, has nothing to do with OOP.

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

#143
post #103

Earlier quoted context omitted.

> Addition was not the bottle neck for the 386. It is a bottleneck for MIPS, SPARC, Alpha and not for 386. How so?

The 386 wastes so many FO4 gate delays on other things. I thought I made that extremely clear?

Can you elaborate on where the delays came from?

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

#145
post #39

Good 'jcranmer on the RISC-CISC thing: https://news.ycombinator.com/item?id=39481940

I just want people to start doing interesting things with stack machines again. Like, hardware ones, not VMs (plenty of interesting stuff happening there). But that's the concatenative language lover in me wanting to see more interesting things happen, not some zealot claiming we all should switch to it.

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

#146

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…

Okay, I will have to review the lecture about VLIW, again: https://www.youtube.com/watch?v=nHHsYp7ZkHQ

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

#147

Earlier quoted context omitted.

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.

I’m arguing it’s not FP when you take an OOP language and bolt on lambdas. Lambdas are necessary but not sufficient. You need expression orientation, immutability by default, persistent collections in the standard library, some way to handle monadic code, etc…

Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable).

Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core). For example, clean uses linear types to control effects and purescript / Idris use a custom effect-system. So no, monads are not a requirement, and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().

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

#148
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.

Well, as I see you don't have enough bravery to answer simple question about purpose of mini-computers, so I will.

When computers first appeared, they was big, just because technology limitations made small machines very expensive to use, so scale used to make computations cheaper.

In early 1970s, technology advanced to stage, where become possible to make simplified versions of big computers for some limited tasks, still too expensive for wide use.

Simple illustration, IBM-3033 mainframe with 16M RAM could serve 17500 3270 terminals, and PDP of same time could about few tens (may be 50, I don't know exactly), so mainframes even when was very expensive, but given good cost per workplace.

Known example, PDP used to control one of scientific nuclear reactor. PDP chosen, not because it have best mips/price ratio, but because it was cheapest adequate machine for this task, so is affordable for limited budget.

Very long time, mini machines stay in niche of limited machines, used to avoid much more expensive full-scale mainframes. They used to control industrial automation (CNC), chemical factories and other small things.

Once appeared microcomputers (CPU on one chip), they begin eat mini's space from bottom, when mainframes continue to become more cost effective (more terminals with appearance of cheap modems, etc) and eat mini's space from top.

And in 1990s, when appeared affordable 32-bit microprocessors and became affordable Megabytes of RAM, mini's disappear, because their place was captured by micro's.

To be honest, I just don't know anything we could not name microcomputer now, as even IBM Z mainframes are now have single-chip processor and largest supercomputers are practically clouds of SOCs (NUMA architecture).

And I must admit, I still see PDP's (or VAX's) on enterprises, where they still control old machines from 1990s (they are very reliable even when limited from modern view, but still work).

As I remember, last symmetrical multiprocessor supercomputer was Cray Y-MP, later machines become ccNUMA or just NUMA or even cloud.

https://en.wikipedia.org/wiki/LINPACK

Unix was simplified version of Multics, system considered to run on mainframes (BTW even exists officially certified Unix for mainframes).

You could try mainframes software yourself, it is very affordable now with emulator (sure, be careful about license):

https://en.wikipedia.org/wiki/Hercules_(emulator)

And you will see yourself, how many things borrowed by modern OS's from mainframes.

This is nature, people choose simpler, cheaper thing.

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

#149

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…

With all of the sanctions China is really starting to push RISC forward, challenge ARM, and they are starting to find success. That "No" has absolutely changed to a "Maybe".

https://www.prnewswire.com/news-releases/global-and-china-au...

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

#150

Earlier quoted context omitted.

I’m arguing it’s not FP when you take an OOP language and bolt on lambdas. Lambdas are necessary but not sufficient. You need expression orientation, immutability by default, persistent collections in the standard library, some way to handle monadic code, etc…

Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable). Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core). For example, clean uses linear types to control effects and purescri…

> Immutability by default is not a requirement for functional programming (I mean... if it were, Haskell would be obviously not FP since the 'default' entrypoint is very mutable).

I mean the bindings and collections. For example, when you make an array in JS, the default syntax is a mutable list with a mutable binding:

    let xs = [ 1, 2, 3 ]

> Neither are monads. There are entire FP languages without monads for effects (obviously, you can write a monadic interface in them, but it's not part of the idiomatic core).

I should be more precise - there needs to be some way to mange effects. Monads with syntax extensions is simply the most common (Haskell, Scala, F#, Closure macros)

> and even if they are, modern c++ fully supports them, as does rust, javascript, etc. It's very common in javascript to use Array.map() and Array.flat().

JavaScript does not have good monad support. This is why async/await was added as a new language feature. Yeah, I know you can hack together something with generator functions, but it’s hardly idiomatic.

But we’re getting into the weeds here. My point is: I don’t consider a language to support FP when writing functional code in that language leads to lots of friction compared to what is idiomatic.

Have you ever tried FP in Java? It works for some toy thing but then you hit the lack of TCO, or the ridiculously long type names (not inferred) or the pyramid of doom…

Post reply on HN