171–180 of 394 posts
When I discovered the Magazine (back un the 90's) I wasn't ready to code for windows nor win32 because I was a broke student with a 1MB 80286; but I am pretty sure reading and rereading that code and articles made me learn more C/C++ than most books or courses I took later.
Mr. Petzold: If we meet someday, the beers are on me!
Considering the magnitude of its impact on science, engineering and culture (as well as the tremendous force released), this line from the IGNITION subroutine in the BURN_BABY_BURN module of the Apollo AGG source code does it for me: https://github.com/chrislgarry/Apollo-11/blob/master/Luminar...
# HONI SOIT QUI MAL Y PENSE
# NOLI SE TANGEREBit tricks. Like public static int bitCount(int i) { i = i - ((i >>> 1) & 0x55555555); i = (i & 0x33333333) + ((i >>> 2) & 0x33333333); i = (i + (i >>> 4)) & 0x0f0f0f0f; i = i + (i >>> 8); i = i + (i >>> 16); return i & 0x3f; } It was like magic for me when I encountered it first time.
The one that blew my mind when I was in college was a simplified version of quicksort in Haskell. It's just so elegant and clean. quicksort :: Ord a => [a] -> [a] quicksort [] = [] quicksort (p:xs) = (quicksort lesser) ++ [p] ++ (quicksort greater) where lesser = filter ( = p) xs Now surely someone may come along and point out how this isn't a true quicksort[0] because it doesn't partition the elements in place, but…
Quick sort comes with a steep penalty. Worst case is O(n^(2)). The reason quicksort is good is because it's in place. Once you throw away the in place aspect of quick sort, it's straight up bad. This implementation of quicksort is actually a great example of why functional programming sucks. It silently transforms an O(1) space algorithm into an O(n) space one, and adds an enormous constant time overhead. Algorithms…
If having to think a bit harder about your sorting algorithm is why functional programming sucks, can I give examples of every bullshit concurrency problem I’ve had in Java as an example of why imperative programming sucks?
Persistent data structures are a bit slower but largely become non issues if you deal with concurrency and avoid a lock that you would have otherwise required in C or Java.
It’s not like the people who wrote Haskell are idiots; most of these data structures end up sharing a lot of data, and a “new” structure is often only the diffs from the previous version. Not to mention that since you have a compile time guarantee that the data isn’t going to change, you effectively avoid any need for defensive copying.
I’m sure you can find some benchmark that proves C++ is faster in the most technical sense, but for network and multithreaded applications, it’s not even close; it’s so much easier to make sure a functional concurrent language is actually correct that the benchmarks become almost irrelevant.
This returns the greatest value (passed ? or max_value column):
?^((?^max_value)&-(? min_value^((?^min_value)&-(? :v/./,/./-j
Somewhat more readable version:
:vglobal /./ .,/./- join
(define eval-expr (lambda (expr env) (pmatch expr [`,x (guard (symbol? x)) (env x)] [`(lambda (,x) ,body) (lambda (arg) (eval-expr body (lambda (y) (if (eq? x y) arg (env y)))))] [`(,rator ,rand) ((eval-expr rator env) (eval-expr rand env))]))) There's an amazing talk about it: https://www.youtube.com/watch?v=OyfBQmvr2Hc
Bash fork bomb (do not run, this will crash your system if it's not configured properly): :(){ :|:& };:
What is a proper configuration to avoid that?
(define eval-expr (lambda (expr env) (pmatch expr [`,x (guard (symbol? x)) (env x)] [`(lambda (,x) ,body) (lambda (arg) (eval-expr body (lambda (y) (if (eq? x y) arg (env y)))))] [`(,rator ,rand) ((eval-expr rator env) (eval-expr rand env))]))) There's an amazing talk about it: https://www.youtube.com/watch?v=OyfBQmvr2Hc
Great. In 90 minutes I may be able to know what you're talking about.