[deleted]
The Flub Paradox
41–50 of 77 posts
Re: The Flub Paradox
#42[deleted]
[deleted]
Re: The Flub Paradox
#43You could also summarize this article in one sentence: the choice of programming language is driven by the market and not the opinion of a single person. That means that not always the best one wins, but the one which has most appealing properties. And those are not necessarily the "beatifulness" or some academic aspects, but rather: popularity (and easyness of finding programmers), understandability, availability of…
>summarize this article in one sentence: the choice of programming language is driven by the market and not the opinion of a single person. I wouldn't summarize it that way. More accurate would be: "the effectiveness of a programming language is driven by multi-dimensional factors instead of a single factor such as expressiveness of syntax. One's expert usage of a language can lead him to overestimate its overall eff…
I agree, but then again, the market accounts for all those "multi-dimensional factors".
Maybe what should be added is that there are external and interal factors that decide of which language is better. External factors have been already discussed. Internal ones are those that correspond to the company internal structure, culture, etc. For instance: If you have a team of people writing Java you wouldn't choose Python at all.
Re: The Flub Paradox
#44Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more form…
There are a couple of things I disagree with. First, you are lumping together trends in academia with trends in the industry, and the two are not always in tandem, though they certainly influence one another. For example, Go, a language that certainly goes against this trend, is gaining popularity much faster than any academic or academically-influenced languages (of course, it's easy to grow fast when you're small,…
For those who want to see what Esterel is all about, Céu is a modern language inspired by it (or at least its synchronous concurrency approach).
Re: The Flub Paradox
#45Earlier quoted context omitted.
Ever so slightly ;) I think it admirable that people invest a lot of time in the environments they spend so much time in, but a professional has to be flexible. (It is entirely possible that my sarcasm got out of control here.)
Just out of curiosity, what makes you say IDEs are bad?
The article is negative about IDEs. I was stating that in fact IDE can be a valuable tool for specific areas.
Re: The Flub Paradox
#46The Schlub paradox: a sufficiently Flub language is so far divorced from its target platform that reasoning about the execution characteristics of a Flub program is non-trivial.
In data-oriented design the mantra is, "the hardware is the platform." A given CPU comes with some instructions it understands and our job as programmers is to use those instructions to apply transformations to a stream of data. The optimal language is of course the assembly language of the target platform. However it's often more practical to use a language that compiles down to a target platform's instruction set with the fewest number of transformations (barring the presence of optimizations).
Flub languages attempt to give programmers the tools to write programs which hold some provable invariant, provide denotational semantics, or some combination of these. The benefit of this is some reduced cognitive load, expressive power, and other "soft" features. This power is what lets small teams run circles around Blub programmers in the Blub/Flub paradox.
However the utility of these features and whether they actually do allow small teams to get more work done in less time hasn't been proven to me yet. It may seem tedious to think to think of the statistically significant data-access pattern in a given operation and forming your data-structures and transformations to make that access pattern the fastest route for the target platform... but it has big wins in terms of execution speed of the programs and the maintainability of such programs. One still requires a significant amount of mathematical reasoning and understanding of what a compiler can and cannot do for you.
I'm slowly coming to the opinion that there won't ever be a compiler or Flub language that will give you your cake and let you eat it too. In practice I've found re-usability to be a low-priority concern, generics to be a performance hindrance, and I've yet to find a convincing example of how type-safety is the future of mission-critical software (though there are some promising projects for sure).
Thus in conclusion: I think Blub languages will continue to rule the roost. Flub will come and go and remain fashionable as the OP has alluded to. However I don't think it's the avenue worth pursuing in order to write better programs... too much abstraction makes it rather difficult to reason about what our programs are actually executing on the target platform and for many cases that can be critical. It always comes down to the data and at some-point one needs to consider the target platform anyway. Data-oriented design is one way to think of the data first and allows the programmer to choose the appropriate semantics for the necessary transformations to be expressed by their program.
(I hope I'm making sense).
Re: The Flub Paradox
#47Those are very keen observations and not commonly voiced in that combination. I can't remember the last time I read an article about the development of PLs that I agreed so much with. If I had to venture a guess about future development in PLs, there would only be one pattern that I find reliable enough: In a rough birds eye perspective, PLs have moved from hardware-specific things handling mutable state to more form…
Haskell is a research language with lazy evaluation. Also with a lot of fun type-stuff. I guess you could make a language which tries to be immediately pragmatic. But it is more focused to try to focus on a relatively small area and see how far you can push those concepts. Haskell is just one datapoint. Are PLs moving in one uniform direction, upwards to some kind of "ideal" state? Arguably not until we manage to col…
> Haskell is a research language
The language standard is from 1998, and is mostly unchanged since then. We now have Haskell 2010 and quite a few compiler extensions, but none of the experimental ones are necessary to be used in production. The researchy ones have their benefits, but they also make it pretty clear that they are things not to be toyed with lightly in production code.
Re: The Flub Paradox
#48Earlier quoted context omitted.
I don't think naming names was a mistake; rather, I think the names demonstrate that your thesis doesn't have anything to do with "Beating the Averages". I mean, by your definition, Flub is literally every new language, modulo a few that are too domain-specific. Hell, Flub need not even be a powerful language, just a language with crackpot users. So, rather than about being any averages, it appears to me that your po…
Every day I work with C++, and I've learned not to shoot myself in the foot. If it were the pinnacle of PL development, I would be depressed; there has to be a successor at some point (Data point: who remembers Algol 68 or PL/1?). It would please me if something like Nim gained traction, because it's C++ _done cleanly_. I was just pointing out that adoption of new languages is very much "Crossing the Chasm" - after t…
I apologize for ruffling feathers, by the way; I suspect I have a nasty sense of humour.
Don't worry about it. The other definition of Flub I've seen [0], in Doug Hoyte's Let Over Lambda, comes from a similar place.
[0] "A language that can only thread code by subroutines." [In this case, "thread" has an idiosyncratic meaning.] Basically, anything other than Forth. Or those Lisps with the right sort of macros to re-implement Forth.
Re: The Flub Paradox
#49The Schlub paradox: a sufficiently Flub language is so far divorced from its target platform that reasoning about the execution characteristics of a Flub program is non-trivial. In data-oriented design the mantra is, "the hardware is the platform." A given CPU comes with some instructions it understands and our job as programmers is to use those instructions to apply transformations to a stream of data. The optimal l…
Generics are not a performance hindrance unless you mean executable size or compile times. They run just as fast as code with potentially dangerous casts.
Re: The Flub Paradox
#50The Schlub paradox: a sufficiently Flub language is so far divorced from its target platform that reasoning about the execution characteristics of a Flub program is non-trivial. In data-oriented design the mantra is, "the hardware is the platform." A given CPU comes with some instructions it understands and our job as programmers is to use those instructions to apply transformations to a stream of data. The optimal l…
Funny that you mention data oriented design when I coincidentally happened to mention research on types and data layout in my other comment in this post[1]. Maybe this won't turn out to be practical for data oriented design or for caring about memory layout in particular; maybe it won't or wouldn't give enough positive benefits, like being able to easily change the layout of the data structures without changing a lot of the calling code. But the view that PL research and ideas are all about denying the underlying machine seems to be an overplayed meme. Not to mention the idea that people that want more powerful languages are lazy and don't want to think about engineering considerations, instead preferring to put their fingers in their ears and deny reality; I don't think we will be able to simply send our specifications to the compiler and let it figure out everything for us. Thankfully there are a many more approaches that don't involve a black box like an omniscient compiler.
Jonathan Blows Jai language also has some ideas about being able to easily change between SoA and AoS.