sklogic

59 ms·

331.
by sklogic 11y ago
> There's a question of: If you know 20 programming languages, how well do you know any of them individually? The real question is how well should you know each individual language to be productive? Is knowing dark corners of some
332.
by sklogic 11y ago
And this is great. It means that 99% of the programming jobs will fall to automation in the next few years. A cleansing long overdue.
333.
by sklogic 11y ago
What's your issue with 10-20 programming languages? I'd say 20 is not enough, you need dozens and dozens of languages to be efficient.
334.
by sklogic 11y ago
> more first-class objects is always a good thing Only if they're not enforcing some (actually, the worst possible) evaluation strategy.
335.
by sklogic 11y ago
Fexprs do not offer that much vs. mere static compile-time macros, but they're making compilation impossible, limiting an implementation to a lowly and buggy interpreter.
336.
by sklogic 11y ago
> What exactly are these "most CAD operations"? CSG, place and route (pipes, cables, etc.), design constraint checks, all that stuff. > I bet they follow many links from nodes (note the plural!) in most of them. Not that ma
337.
by sklogic 11y ago
Tbh I do not care that much about the external memory bandwidth, I only need internal plus some slow swapping into external DDR (used at most 4 channels so far) - my use cases are solely streaming, therefore tranceivers are more than enough
338.
by sklogic 11y ago
> Needless to say that this is perfectly compatible with being a lunatics asylum. I see... Yes, I'we been exposed to the quality of the intake of the so-called "new" universities (in the UK). Just did not think they'r
339.
by sklogic 11y ago
Three pre-cooked DDR controller macro blocks. Now think of how many soft controllers can be added with so many spare pins. Also, think of all the high-speed tranceivers to feed the data into an FPGA. For the problems I am working with,
340.
by sklogic 11y ago
Both internal and external. The larger FPGA parts can host quite lot of DDR controllers, but what is the most important thing here is that there are HUNDREDS of single-cycle two-port block rams. No CPU or GPU can match this with their pitif
341.
by sklogic 11y ago
Maybe they will market their next generations as "bigger and better FPGAs" now.
342.
by sklogic 11y ago
CPUs and GPUs got a pathetic memory bandwidth. For this class of problems FPGAs are unmatched.
343.
by sklogic 11y ago
And why then Tesla is successful? A pure GPGPU, no use for gaming whatsoever.
344.
by sklogic 11y ago
PEG is basically a thin abstraction over recursive descent parsing. Everything you can do in a handwritten parser can be expressed mostly declaratively in PEG. And, no, there is no single reason not to use PEG. Especially when the choice is
345.
by sklogic 11y ago
Interesting. Yes, in some cases decompilation can return a higher level code than the original, which is quite an interesting an yet very much unexplored area. I only scratched that while I was working on a static code analysis.
346.
by sklogic 11y ago
> Software seems better at managing complexity if good structure is used. Not until you hit a deep semantic difference between your hardware and a code you're trying to build. For example, there are many things that are best express
347.
by sklogic 11y ago
> It's a really clean abstraction of a computing environment No, it's a clumsy and leaky abstraction which was not well thought out. P-codes are a nice abstraction. AS/400 is a nice abstrction. Dozens of other, better VMs
348.
by sklogic 11y ago
Sorry, I'm under a slow-ban here (currently like 2 posts in 6 hours allowance), so I'll answer to all your posts at once here. > Then my students would have been puzzled by Scheme, which they don't know. Maybe they're
349.
by sklogic 11y ago
The historical reason was error recovery and error messages. It is a solved problem now, you can have it all with generated PEG parsers.
350.
by sklogic 11y ago
Tbh, it is really hard to have an "accurate" model of a very wide OoO core. It is far too dynamic, you instruction scheduler cannot predict the occupancy of the pipelines.
351.
by sklogic 11y ago
Again, compilers are easy, easier than anything else. If the entire thing is "complicated" (although it should not be), it can still be broken into a chain of laughably trivial passes. This is the most beautiful property of the
352.
by sklogic 11y ago
I am talking of the languages that are built on top of Lisp/Forth. I.e., you do not really need any syntax if your underlying implementation language is homoiconic.
353.
by sklogic 11y ago
You should have done it in a homoiconic language like Scheme, where nobody would be puzzled by a notion of an AST.
354.
by sklogic 11y ago
Most languages are transforming one layer of semantics into another. Optimisations are pretty much irrelevant in this notion. Parsing in most cases should either be trivial, or can be skipped altogether.
355.
by sklogic 11y ago
My point is exactly the opposite - compilers are easy, probably easier than pretty much anything else. And courses like this do not help by pretending this is a complex topic and by obscuring what matters with unimportant minutiae (like par
356.
by sklogic 11y ago
Quite a few very usable languages are just fine without any dedicated syntax at all. Think of Lisp and Fort for example. And backend is not just about optimisations, they're mostly insig igicant. Backend is about translating gradually
357.
by sklogic 11y ago
No, I'm arguing against a universality of such a claim. There is a performance/complexity threshold above which hardware or hybrid solution is a way easier than a purely software one.
358.
by sklogic 11y ago
Sorry for the media business argot, it's a set-top box (yes, people still call them this way, with all the flat panels around).
359.
by sklogic 11y ago
I'm genuinely puzzled. What can be beautiful anywhere in the JVM?!?
360.
by sklogic 11y ago
TeX and Metafont. It'd be hard to find anything even matching these gems.

More ›