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

Computer Science from the Bottom Up (2013)

bottomupcs.com

Post reply on HN
Print view View original

151–160 of 161 posts

Re: Computer Science from the Bottom Up (2013)

#151

Post by qwertyuiop924 »

Xenograph wrote: post #150
qwertyuiop924 wrote: post #119

Earlier quoted context omitted.

That wasn't my point. My point is, even if you know the theory behind compilers, and maybe have written a few yourself, you probably will have difficulty understanding GCC, Clang, or another production compiler unless you've done work with such a compiler before. That is, your friends' awe of the compiler is not only justified given their skill level, it's also likely justified at your skill level as well (although a…

The awe you're describing and the "awe" of his friends are very different, AFAICT. What you describe is perfectly healthy and reasonable: GCC/etc are unquestionably complex systems that can't be fully understood without thorough long-term study and experience. Oversimplifying them would be reckless, and so the average user of them should possess a certain awe and respect for them. But this is different from having no…

I agree. So I suppose that awe is a bit different.

Re: Computer Science from the Bottom Up (2013)

#152

Post by qwertyuiop924 »

kazinator wrote: post #146
qwertyuiop924 wrote: post #143

Earlier quoted context omitted.

With a compiler smart enough to aggressively cull any uneeded dynamism, it might be possible. But it would still be hard.

A pragmatic view, perhaps, is that as a tool, a given Lisp environment doesn't constraint how fast a solution we can devise to a problem in some manner. That really fast solution might not simply be a Lisp program fed to the Lisp compiler. Suppose you're required to solve a problem with very high performance, and it has to be expressed in some high level language. No high level language achieves it using any straight…

So a custom Assembler using CL as a macro language? That works.

Re: Computer Science from the Bottom Up (2013)

#153

Post by kazinator »

taeric wrote: post #103
qwertyuiop924 wrote: post #93

Earlier quoted context omitted.

Of course. But OTOH, we shouldn't immidiately discount LLs when writing code, just because the perf isn't optimal. >but hardly means that we should be against writing fast software. On the contrary. Lisp is slow. Python is slow. Ruby is slow. Smalltalk is slow. What do these languages have in common? Dynamism. They trade speed for other that were, in the language designer's opinion, equally or more important than bei…

I wouldn't say it is the dynamism as much as the lack of control. Specifically, if you write your code non idiomatically and control all allocations, the languages probably gain a lot on speed. Unless you need inline assembly. Some lisps allow this. I find that taking these lessons to database access patterns helps a lot. Know your data access, and the data structure design has meaningful discourse. Don't know your a…

If you don't know the access patterns, you can't pick the best representation if the prioritized list of criteria determining "best" begins with access speed. If the list begins with something else, you may still be able to pick the best one.

Re: Computer Science from the Bottom Up (2013)

#154

Post by junke »

qwertyuiop924 wrote: post #152
kazinator wrote: post #146

Earlier quoted context omitted.

A pragmatic view, perhaps, is that as a tool, a given Lisp environment doesn't constraint how fast a solution we can devise to a problem in some manner. That really fast solution might not simply be a Lisp program fed to the Lisp compiler. Suppose you're required to solve a problem with very high performance, and it has to be expressed in some high level language. No high level language achieves it using any straight…

So a custom Assembler using CL as a macro language? That works.

SB-ASSEMB, for example. https://www.pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembl...

Re: Computer Science from the Bottom Up (2013)

#155

Post by jdhendrickson »

delsarto wrote: post #91

Thanks, I wrote this! It was a bit of a different time, when docbook was the way to publish, when Itanium was the 64-bit architecture, things like go and rust didn't exist and we used bitkeeper. But most of it is still relevant, and despite acquiring 2 kids since I started still have some ideas. Yes yes, it's not Alan Turing-esque computer science. I have taught algorithms and data structures courses as well as opera…

It's not often you brush up against someone whose work you read and enjoyed. Thanks for what you wrote. It helped me become a better programmer.

Re: Computer Science from the Bottom Up (2013)

#156

Post by RandomOpinion »

gravypod wrote: post #44
vvanders wrote: post #42

Earlier quoted context omitted.

I'd actually argue an FPGA/CPLD is a slightly better approach, simply because you have block memory that acts very much like "cache" and makes it abundant why system memory is so much slower. Since you have timing statistics it also makes it really easy to demonstrate pipelining and many other modern "quirks" of processors that have a large impact on performance.

The barrier to entry in the FPGA world is tooling and expression. If that hurdle is solved then I'd be all for it. It will usher a new era of electrical engineering design that is as cheap as software desgin making it practical for students to try EVERYTHING on their own. To conduct similar experiments as I have with computer in electronics (as I'd like to do one day so I can get to the same place I am in electronics…

>The barrier to entry in the FPGA world is tooling and expression.

Re: tooling, both major vendors of FPGAs have free basic versions of their tools (e.g. Xilinx's Vivado and ISE Webpack) and supported development boards are available for $99 or less (e.g. Digilent's Arty Board).

Re: expression, both Verilog and VHDL permit gate level modeling. Verilog even has gates as language primitives.

Re: Computer Science from the Bottom Up (2013)

#157

Post by taeric »

kazinator wrote: post #153
taeric wrote: post #103

Earlier quoted context omitted.

I wouldn't say it is the dynamism as much as the lack of control. Specifically, if you write your code non idiomatically and control all allocations, the languages probably gain a lot on speed. Unless you need inline assembly. Some lisps allow this. I find that taking these lessons to database access patterns helps a lot. Know your data access, and the data structure design has meaningful discourse. Don't know your a…

If you don't know the access patterns, you can't pick the best representation if the prioritized list of criteria determining "best" begins with access speed. If the list begins with something else, you may still be able to pick the best one.

Fair. And yes, I was assuming "best" as in the fastest or most predictably bounded.

I did not think I was stating anything profound.

Re: Computer Science from the Bottom Up (2013)

#158

Post by Ar-Curunir »

Klockan wrote: post #149
Ar-Curunir wrote: post #22

Earlier quoted context omitted.

Algorithms and complexity theory are independent of any physical model of computation; they capture what it means to compute . The entire field of theoretical computer science stands as a counterexample to your comment. Computer science is not about software engineering.

Computer science assumes that the code is run on a machine with a very specific set of operations since otherwise you wouldn't be able to calculate time complexity. The set of operations were deliberately chosen to be a reasonable abstraction of a modern computer. Thus computer science would look very differently if computers had different capabilities. For example, lets say that a new computer could switch places of…

The extended Turing thesis says that whatever is efficiently computable in one "reasonable" model of computation, is also efficiently computable in another reasonable model of computation.

Of course, the truth of this thesis has been called into question with the advent of quantum computers, but it holds otherwise.

Re: Computer Science from the Bottom Up (2013)

#159

Post by MartijnHoutman »

ivoras wrote: post #104
delsarto wrote: post #91

Thanks, I wrote this! It was a bit of a different time, when docbook was the way to publish, when Itanium was the 64-bit architecture, things like go and rust didn't exist and we used bitkeeper. But most of it is still relevant, and despite acquiring 2 kids since I started still have some ideas. Yes yes, it's not Alan Turing-esque computer science. I have taught algorithms and data structures courses as well as opera…

Just as idle inquiry about the "CS" term, do you think the name "Computer science" would still apply (and did it always apply) to things such as CPU and OS architectures, the toolchain, etc - basically the subject of your e-book? I am under the impression that there's a distinction between "Computer Science", which is algorithm and data structure design and analysis, and "Computer Engineering" which is basically ever…

I studied CS at Utrecht University in the Netherlands, and there the 'C' stood for 'computational' or 'computing' science, which always made sense to me.

I still know very little about how a computer works on a hardware/low level, but I do know about how the calculations are being done from a higher level.

Re: Computer Science from the Bottom Up (2013)

#160

Post by ZenoArrow »

gravypod wrote: post #134
ZenoArrow wrote: post #130

Earlier quoted context omitted.

>"The barrier to entry in the FPGA world is tooling and expression" Regarding tooling, I'd say it's not quite the barrier it used to be, now that Project IceStorm exists. http://www.clifford.at/icestorm/

If you're writing VHDL or Verilog then it's for electrical engineers, not humans. The barriers include bad description languages. You should just have an EDA system. It will take time for pros to use but will be easy for beginners (especially considering that the output of the EDA will usually be what they did)

The GP mentioned 'tooling and expression', I mentioned tooling, you're mentioning expression.

Aside from that, other HDLs than just Verilog and VHDL do exist, such as Chisel and CλaSH:

https://chisel.eecs.berkeley.edu/

http://www.clash-lang.org/

Also, whilst I'm sure open source EDA tools could be improved, some of the basic building blocks exist, it appears to be more of an issue of packaging than availability. Seems like EDA tooling is a niche that a specialist Linux distro could fill (if tutorials are also provided).

Post reply on HN