Earlier quoted context omitted.
Interesting. Functional programming is the only strategy I've seen be successful at building business software. (Hint: you can do FP in Java and it's not even awkward, and SQL is inherently functional).
I work at a FAANG-like company. The code base has almost no functional programming paradigms deployed. It’s a multi-billion dollar company from which I, an IC cog in the machine employee, became a multimillionaire through from the IPO. It’s wildly successful.
Why programming languages matter [video]
111–120 of 129 posts
Re: Why programming languages matter [video]
#112Earlier quoted context omitted.
It’s simply a reflection of the immaturity and terribleness of the state of the art in programming languages. People eventually got around to things like restricting bytes to be eight bits, using a standard character set, and so on. Eventually we will find some language factors that “stick” (e.g. abandon the stupid distinction between statements and expressions) which will become baseline and the space of variation w…
Yeah, your comment is likely the answer. I am just bitter why is all that happening so darned slow. I really hoped that 22 years in my career I would've seen certain problems disappear forever (as in, be solved, formalized, nailed, and never ever discussed again). But alas, nope.
I'm not saying that every existing language has solved it, I mean that it's been shown by modern non-research languages (ex. Rust) that the problem need not exist. Something to be excited about, not bitter
Re: Why programming languages matter [video]
#113Very little innovation in programming languages has happened regarding new realities at the hardware level especially transition from serial to parallel execution.
For a field in which a large fraction (if not a majority) of the people in industry have (nominally at least) science degrees, CS research takes a fairly long time to penetrate into industry. Rust 1.0 had few, if any, features that weren't demonstrated in academia 30 years earlier.
Re: Why programming languages matter [video]
#114Earlier quoted context omitted.
Functional programming is not based off how hardware is implemented. Serial execution of instructions and mutating chunks of memory at a time are all core parts of how the hardware works which aren't functional. Doing graph reduction and making tons of copies will be slow.
Are we still doing this stupid ass reasoning around FP? Is the CPU really that serial, when it literally reschedules your instructions based on the graph of their interconnections? Also, just think about all the optimizations your "serial" programming language does -- are your yourself really write all those mutations? Or is that the compiler, that in many cases can do a much better job? Now what if the language's se…
Yes. Yes, it is because all of that rescheduling and reordering is completely hidden at great effort and expense to make it seem like the instruction stream is executing in exactly in the order specified. If it weren't, lines of code would essentially execute in an indeterminate order and no programs would function.
Re: Why programming languages matter [video]
#115Earlier quoted context omitted.
Yeah, your comment is likely the answer. I am just bitter why is all that happening so darned slow. I really hoped that 22 years in my career I would've seen certain problems disappear forever (as in, be solved, formalized, nailed, and never ever discussed again). But alas, nope.
Would you not consider "null" to be a problem that has been solved? That's the most obvious example to me, it's a problem that used to be extremely prevalent but is now a completely solved problem. I'm not saying that every existing language has solved it, I mean that it's been shown by modern non-research languages (ex. Rust) that the problem need not exist. Something to be excited about, not bitter
But in general, very few such unquestionably good practices are adopted.
Re: Why programming languages matter [video]
#116Earlier quoted context omitted.
same here, some companies are hiring a compiler team for AI in fact. I was told Rice and UIUC provide the best compiler program, though not necessarily AI related, should be similar though.
What does it mean, specifically, "compiler team for AI"? I get it that it's some hot new trend from the last 2 posts, but I'm struggling to imagine what exactly the perfect product should look like and why everyone wants it so bad, allegedly.
In standard processing, the code is so branchy that we often resort to heuristics in order to get 'good enough' perf.
The FLOPS difference between a cpu and gpu is huge. It makes things that are intractable on cpus possible. Without gpus there is no deep learning.
That being said, writing code for gpus by relying on cpu compilers will result in terrible perf. In order to take advantage of the hardware you have to take into account minute details of the architecture that most cpu compilers ignore.
Cache oblivious algorithms are algorithms that know that there is a cache but don't rely on particular cache sizes. It's the way a lot of cpu code is written because it means not having to deal with particulars.
On gpus, particulars matter. For example, to compile a matrix multiply on an Nvidia GPU, you cant just use vectorized multiplies and adds. No. In order to achieve max performance you need to utilize the warp level matrix multiply instruction which requires that you split an arbitrarily sized matrix into the perfect native tensor sizes and then orchestrate the memory loads (which are asynchronous on gpus, and transparently synchronous on cpus) correctly. If you don't you waste millions of dollars (literally).
So whereas on a cpu you might just modify your matrix multiply loops to get contiguous memory access and add some vectorization in and cross your fingers, on a gou your compiler needs to take the trivial three nested loop algorithm, look up the cache size particulars and instruction capabilities for the particular generation of the chip, and then rewrite the loop nesting to make it optimal. All while making sure you don't introduce further memory hazards (bank conflicts), etc. So your simple three nestled loop algorithm gets turned into a nine nested loop monstrosity.
The stakes are much higher here and the optimizations much different. Whereas on a cpu, we kind of give up with the branching complexity, and just do our best since we never truly know the state of the program, on gpus, the algorithms being executed are extremely amenable to static analysis so we do that, and optimize the shit out of them.
Re: Why programming languages matter [video]
#117Earlier quoted context omitted.
Would you not consider "null" to be a problem that has been solved? That's the most obvious example to me, it's a problem that used to be extremely prevalent but is now a completely solved problem. I'm not saying that every existing language has solved it, I mean that it's been shown by modern non-research languages (ex. Rust) that the problem need not exist. Something to be excited about, not bitter
Oh I do like that for sure, but as you said it's a solved problem in very few languages. But in general, very few such unquestionably good practices are adopted.
That's not what I said. What I said was "I'm not saying that every existing language has solved it". TypeScript, C#, Kotlin, Dart are all examples of popular languages that have solved this problem.
Another problem that's currently being solved is the inability to do basic data modeling. In particular, the inability to say "it's A or B". That has been solved in some languages for a long time but is now solved in a number of popular languages too.
There really have been quite a number of advancements in the last 22 years, but sometimes it feels like it's just the bare minimum (ex. being able to do basic data modeling, not having everything be surprise null, etc.). It does seem like it takes a long time for good ideas to propagate into the languages that most people are using. The field is young and it's going to take time for things to mature.
The next big thing is going to be effect/capability systems (tracking which functions do I/O, access the filesystem, etc.). That might take another 22 years to go mainstream, but that doesn't mean progress isn't being made, it just means that we need more new languages that try new things, evaluate new concepts, and establish techniques to be adopted by other languages.
Re: Why programming languages matter [video]
#118Earlier quoted context omitted.
Oh I do like that for sure, but as you said it's a solved problem in very few languages. But in general, very few such unquestionably good practices are adopted.
> but as you said it's a solved problem in very few languages. That's not what I said. What I said was "I'm not saying that every existing language has solved it". TypeScript, C#, Kotlin, Dart are all examples of popular languages that have solved this problem. Another problem that's currently being solved is the inability to do basic data modeling. In particular, the inability to say "it's A or B". That has been sol…
1. We have a describable or demonstrable solution Y for problem X.
2. We have a language that uses Y to solve X.
3. We have several languages that use Y to solve X.
4. Most languages use Y to solve X, and popular languages that don’t are anticipated to do so soon so they can.
5. Any sensible language uses Y to solve X.
> I really hoped that 22 years in my career I would've seen certain problems disappear forever (as in, be solved, formalized, nailed, and never ever discussed again). But alas, nope.
I interpret this comment as referring to “solved number 5”.
And I also find it disheartening that that level of solution, for well known problems, seems so rare.
Re: Why programming languages matter [video]
#119Earlier quoted context omitted.
Same. The dynamic typing helps with prototyping but all MBAs have consistently proven they are NOT willing to have the prototype rewritten in something better later.
I found that it is better to ask for forgiveness than permission.
Re: Why programming languages matter [video]
#120Earlier quoted context omitted.
repl based development, or until people see how cool structural editing really is
Agree on the REPL and exploratory programming! But can’t agree on the structured editing side. I used to do use structured editing (D-Edit on the Interlisp-D machines) and found it annoying, but perhaps that was due to the mandatory mouse use. The structured editing built into emacs is pretty good mainly because it’s an option you can use at any time rather than a single paradigm. Also the only way to use comments in…