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

The Flub Paradox

steved-imaginaryreal.blogspot.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: The Flub Paradox

#51

Post by iopq »

cousin_it wrote: post #17
Anderkent wrote: post #8

Is the idea of a single language that's clearly better than anything else, for everything, a common one? If one thinks of languages as tools, it seems pretty obvious that different languages will be the best tool for different kinds of tasks. Are you writing a REST wrapper around an existing java toolset? Clojure's your friend. A cryptographic, secure communication library? Rust is probably (going to be? in a couple…

What if it's a large project where you have to do all these things? Would you run ten different language runtimes, each with its own garbage collector? Would you pay the cost of marshaling and unmarshaling data at the boundaries? What about training new programmers to understand and extend your system? What if you want to move some functionality from one part of the system into another, can you do it easily? Etc, etc…

The great thing about Rust is that it doesn't need to be garbage collected, so it's easy to use inside a Ruby project. That's why you can use Rust in a lot more places than you would use Java.

Re: The Flub Paradox

#52

Post by Dewie3 »

jerf wrote: post #36
stevedonovan wrote: post #24

Earlier quoted context omitted.

It was perhaps unfair to single Rust out given that it is so young, but there are costs to any innovation, and the first cost that leaped out at me was stories of long compile times. Besides, extraordinary claims require extraordinary evidence. Personal anecdotes of increased productivity remain anecdotal - it may be more a property of the programmer than the language. I don't personally have a horse in the race, but…

I really don't expect Rust to exhibit what most people mean by "increased productivity", ever. Most people mean something fairly local by that, or at most medium sized, that it allows them to take some task and write code faster than other languages that accomplishes the task. Rust is always going to labor under the disadvantage that it holds you to a higher degree of correctness than other languages, and at best it…

The standards one holds emerging technologies to tends to be proportional to how much one personally dislikes them. (and of course the corollary vice versa)

Re: The Flub Paradox

#53

Post by apalmer »

No offense, but the whole essay hinges on some core concepts that are NOT logically robust, hence the ultimate 'paradox' is really simply an application of reductio ad absurdum

Basically the premise of what it means to be 'powerful' is at best ill defined, and most likely is not logically consistent.

More or less there is no clear qualitative definition for 'powerful', nor is 'powerful' meaningful across all developers, organizations, or application.

Now by an empirical definition in this context the meaning of 'powerful' is clear. 'Powerful' means how strongly the program language selection correlates with successful projects... based on that the 'powerful' languages are pretty much the 'blub' languages. there are many many successful PHP, Java, and especially C projects.

Re: The Flub Paradox

#54

Post by RHSeeger »

> It could have easily been something much worse, like Tcl.

Ouch. Tcl might not be the right choice for many situations, but it's a fantastic language for many. It is, by far, one of my favorite languages to work in.

Re: The Flub Paradox

#55

Post by aaronem »

raverbashing wrote: post #14
smitherfield wrote: post #9

Earlier quoted context omitted.

I knew C; C was a friend of mine. Javascript, you're no C! When it appeared, C was a revolution in programming languages. It offered a combination of performance and expressiveness that simply outclassed anything else available (still true today, 43 years later, if more narrowly). It instantly became the most popular and held that position to this day, becoming a major influence on virtually every other popular progr…

> much superior, existing scripting languages (Python, Ruby, even Perl or some Lisp dialects) were passed over Python existed in 1995, but I doubt it was very known at the time. Ruby was created in 1995 Lisp is older, sure, but maybe there were concerns about the syntax and interpreter requirements? "But, all things considered, it was as close to perfection" Pascal didn't have a braindead way of dealing with strings.…

>Lisp is older, sure, but maybe there were concerns about the syntax and interpreter requirements

As I understand it, Brendan Eich originally spent a lot of effort on a Scheme implementation to serve the browser-scripting role for Netscape/Mozilla, but couldn't get it done in time and hacked up Javascript in a hurry to prevent an even worse alternative from becoming the de facto standard.

Re: The Flub Paradox

#56

Post by agentultra »

Dewie3 wrote: post #50
agentultra wrote: post #46

The 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…

> But the view that PL research and ideas are all about denying the underlying machine seems to be an overplayed meme.

Well I am not terribly hip to what's "played out," but I don't intend to disparage academic research.

What I am concerned with is the idea that you can't have mathematical reasoning and correct programs in the absence of a VM and some combination of denotational semantics and program invariants and other features-du-jour. The trade-offs for "expressivity," are not zero and we throw them out rather casually these days. Other trade-offs such as "correctness" also have a cost and non-trivial trade offs for compile times, run-time support, etc. And it makes reasoning about these characteristics more difficult the more abstract Flub is from a real machine.

> Jonathan Blows Jai language also has some ideas about being able to easily change between SoA and AoS.

His work is pretty cool and I have been following it from a distance.

The paper you linked to looks interesting. I wish I was an ACM member so I could read it!

Re: The Flub Paradox

#57

Post by Ygg2 »

_lce0 wrote: post #21

> The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by rea…

Scala, Rust, Haskell, JavaScript, VHDL, ASM and PHP :P

If joke languages count then Brainfuck and BS[1]

[1]https://skillsmatter.com/skillscasts/6088-the-worst-programm...

Re: The Flub Paradox

#58

Post by JanneVee »

_lce0 wrote: post #21

> The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those. You were also safe if they said they wanted C++ or Java developers. If they wanted Perl or Python programmers, that would be a bit frightening-- that's starting to sound like a company where the technical side, at least, is run by rea…

It is not the languages themselves that are scary. It is the people using them. So if the competition look for e.g. Erlang programmers and you don't for some kind of messaging app. Then you should be worried. If they use it for big files, then you should be less worried. Because they need to solve a few more limitations in Erlang/OTP to make it work well.

Re: The Flub Paradox

#59

Post by AnimalMuppet »

michaelochurch wrote: post #38

This is intelligently argued and articulate but the content is a bit lacking. First, Paul Graham isn't an expert on languages. He wrote a decent Lisp book, years ago. Relative to VCs, he's a technical genius. Relative to technical geniuses, he's a VC. I respect him for taking iconoclastic positions against the Establishment, and I miss that Paul Graham, but... he has serious blind spots when it comes to, say, statica…

But a good IDE won't make you take your hands off the keyboard. See, for example, IntelliJ. There are keyboard shortcuts for everything.

Re: The Flub Paradox

#60

Post by _dps »

michaelochurch wrote: post #32
tempodox wrote: post #12

Those 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 isn't "overdone". It's extremely principled and requires that, for example, you put the existence of stateful effects (e.g. I/O) in the type system. It requires you to specify state (to a degree, and with escape hatches); it doesn't eliminate it. Haskell isn't that much of an investment when you consider what is gained. See, learning any new code base takes 3-6 months, and if the code is great, you learn a lo…

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice.

I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful like all the mathematics that I love. But then I try to use it and, objectively, I get less done (even though I knew what an endofunctor was before even seeing Haskell!).

My longest stretch of trying to use Haskell every day was about 3 months at which point I was still substantially less productive than my preferred mix of C/Python/Lua (I mainly do heavy-lifting numerical work coupled with low-latency server designs). I also feel like I get more done in OCaml.

So, you being someone whom I identify as similar in skills to myself, I ask you: what gives? :-)

Post reply on HN