Someone's just discovered "yield"

[blakeyrat]

@Snooder said:

No, it hasn't. And the fact that you think it has been solved is what makes you a hack.

I iterated a dozen things just this morning. Maybe I'm a super-genius, but... I still think it's a solved problem and you insisting otherwise isn't going to change my mind.

@Snooder said:

If you find math and the science of computing to be 'tedious', why the hell are you in this line of work?

The math is boring as hell.

The interesting part of computers is how they interact with human beings-- I didn't get into the field of computers to turn myself into a computer, I got into the field of computers to make it easier for computers and humans to interact with each other. Which, as a field of computer science, is at least 20 years behind where it should be.

If you were an astronomer and you worked on pulsars (for example), would you go to the astronomer forum and talk to the guy interested in black holes, and call him a hack? No. Because the field is large and there's room enough for both approaches.

Ditto computer science. I'm interested in one aspect of the "problem of computers". You're interested in another. Fine. No problem. There's room enough for both of us. The only difference is: the bit I'm interested in is way under served compared to the bit you're interested in, so I personally think the bit I'm interested in is more important.

@Snooder said:

Again, this is the kind of thinking that makes you a hack. You don't actually have a passion for the work; for computing, for writing code or designing algorithms.

I have a passion for computing. (I do not have a passion for writing code, at least not anymore, nor for designing algorithms.)

@Snooder said:

edit: To clarify, when I say the problem of iteration "hasn't been solved," I don't mean that there aren't ways to do what you want with existing language constructs. Any turing-complete language can do it. What I mean is that there is ALWAYS a better and more efficient way to do things. Someone who cares about computing should never settle for the status quo and should always be trying to think of ways to code better.

The status quo is programmers designing the same shit over and over and over again and users being confused as fuck. The status quo sucks. If there's ONE thing I support and have posted about on this forum, it's that. I have no idea how you can read anything I've written here and come to the conclusion that I support the status quo.

As for "there's a better way to do X, therefore the way we do X now is an unsolved problem", well. Ok but by that definition "unsolved problem" is meaningless because literally everything is an unsolved problem.

As for "people who improve programming efficiency are the only people who aren't hacks"-- as far as I'm concerned the only reasons to improve programming efficiency right now are: 1) to allow developers to spend more time making their software usable, or 2) to allow more people to become developers, i.e. making software development easier. If you're not working towards either of those two goals, then you're just wasting time as far as I'm concerned.

[blakeyrat]

@Ben L. said:

// I don't know C# syntax, so have some pseudoC#
class Wat {
IEnumerable<Result> Stuff() {
using (DBCursor<DBRow> cur = StartDBQuery()) {
foreach (DBRow row in cur) {
yield return DoExpensiveCalculation(row);
}
}
}
}

And you posted this... why? Use your words, Ben L. I know you're trying to communicate something to me, but what is it?

[Soviut]

@joe.edwards said:

const q = require( 'q' ),
XMLHttpRequest = require( 'w3c-xmlhttprequest' ).XMLHttpRequest,
Promise = q.Promise;

Promises/futures aren't the same thing as generators or coroutines. Promises are chainable and specifically are built to return one value to the next, where as coroutines traditionally cannot because they're already returning an IEnumerator value. While they can both be used to solve async problems, they do so in different ways; Returning values differently and handling errors differently.

[Ben L.]

@blakeyrat said:

@Ben L. said:

// I don't know C# syntax, so have some pseudoC#
class Wat {
IEnumerable<Result> Stuff() {
using (DBCursor<DBRow> cur = StartDBQuery()) {
foreach (DBRow row in cur) {
yield return DoExpensiveCalculation(row);
}
}
}
}

And you posted this... why? Use your words, Ben L. I know you're trying to communicate something to me, but what is it?

Here, blakey. Which one of these is better to use in a customer-facing application?

[Soviut]

@blakeyrat said:

I iterated a dozen things just this morning.

Then you should be pretty familiar with how generators work and when they're a better solution than lists.

@blakeyrat said:

The interesting part of computers is how they interact with human beings-- I didn't get into the field of computers to turn myself into a computer, I got into the field of computers to make it easier for computers and humans to interact with each other. Which, as a field of computer science, is at least 20 years behind where it should be.

That's exactly what language developers are trying to do as well. They're giving you better tools to make your code more efficient without added complexity, but you're too busy stagnating to learn what they are or how they're used. Instead you waffle between "if it ain't broke, don't fix it" and a systemic case of sour grapes.

[blakeyrat]

@Ben L. said:

Here, blakey. Which one of these is better to use in a customer-facing application?

Well, one's a website with some bullshit Go code, and the other is psuedo-C#. So... neither? WHAT THE HOLY FUCK ARE YOU TALKING ABOUT!

[blakeyrat]

@Soviut said:

That's exactly what language developers are trying to do as well.

Yeah; but they're trying to do it for developers. Well guess what? Developers already know how to use computers to do what they need, this group is already served. The group that isn't, you know the 98% of the population, that's the group we should be focusing on right now.

[Soviut]

@blakeyrat said:

@Ben L. said:

Here, blakey. Which one of these is better to use in a customer-facing application?

Well, one's a website with some bullshit Go code, and the other is psuedo-C#. So... neither? WHAT THE HOLY FUCK ARE YOU TALKING ABOUT!

Would you like to see an example in Python or Ruby perhaps? Both of which have generators and iterators. The fact that you're the only one here who doesn't understand the benefits of generators is pretty telling. You're like purists from 1998 who scoffed at the foreach loop, "the for loop can already do all that stuff, why do we need it?". Meanwhile, all that "morning iteration" you did probably involved a fair number of foreach loops.

[error]

@Soviut said:

@joe.edwards said:

const q = require( 'q' ),
XMLHttpRequest = require( 'w3c-xmlhttprequest' ).XMLHttpRequest,
Promise = q.Promise;

Promises/futures aren't the same thing as generators or coroutines. Promises are chainable and specifically are built to return one value to the next, where as coroutines traditionally cannot because they're already returning an IEnumerator value. While they can both be used to solve async problems, they do so in different ways; Returning values differently and handling errors differently.

I use a generator as a parameter to q.spawn.

[Soviut]

@joe.edwards said:

@Soviut said:

@joe.edwards said:

const q = require( 'q' ),
XMLHttpRequest = require( 'w3c-xmlhttprequest' ).XMLHttpRequest,
Promise = q.Promise;

Promises/futures aren't the same thing as generators or coroutines. Promises are chainable and specifically are built to return one value to the next, where as coroutines traditionally cannot because they're already returning an IEnumerator value. While they can both be used to solve async problems, they do so in different ways; Returning values differently and handling errors differently.

I use a generator as a parameter to q.spawn.

Sorry, I missed that. I became monofixated on the promise as I've seen a lot of people ask about the difference between promises and coroutines recently.

[Ben L.]

@blakeyrat said:

@Snooder said:

Again, this is the kind of thinking that makes you a hack. You don't actually have a passion for the work; for computing, for writing code or designing algorithms.

I have a passion for computing. (I do not have a passion for writing code, at least not anymore, nor for designing algorithms.)

How do you define "computing"? The first definition, by your standard, would mean you became a computer. The second one includes things like using the CD tray as a cup holder or double-clicking the W to open Microsoft Word. The third one is computer [science] and computer programming, which are the two things you said you aren't interested in, but in reverse order.

[boomzilla]

@Soviut said:

@blubbeyrat said:

@Ben L. said:

Here, blakey. Which one of these is better to use in a customer-facing application?

Well, one's a website with some bullshit Go code, and the other is psuedo-C#. So... neither? WHAT THE HOLY FUCK ARE YOU TALKING ABOUT!

Would you like to see an example in Python or Ruby perhaps? Both of which have generators and iterators. The fact that you're the only one here who doesn't understand the benefits of generators is pretty telling. You're like purists from 1998 who scoffed at the foreach loop, "the for loop can already do all that stuff, why do we need it?". Meanwhile, all that "morning iteration" you did probably involved a fair number of foreach loops.

First he rants about how "things haven't changed from the 70s." But then when confronted with an invention of the 70s that makes it easier to write non-sucky (from the user's perspective and the deveoper's) applications, his response is, "I don't need to learn this new fangled stuff!"

He's an angry ball of blub, and I denounce myself for finding that funny.

[Mason_Wheeler]

@blakeyrat said:

@Soviut said:

By all means, show an example.

void DoStuff(queryParamsOrWhatever)
{
    records = ShoveDBRecordsIntoListOrTheresABillionRowsSoWhatever();
}

 

Do you understand the difference between eager and lazy evaluation?  Between O(1) and O(N) memory requirements?  Because you appear not to, with code like this.  If you don't get that, it's no wonder the rest of it makes no sense to you.

 

[Snooder]

@blakeyrat said:

If you were an astronomer and you worked on pulsars (for example), would you go to the astronomer forum and talk to the guy interested in black holes, and call him a hack? No. Because the field is large and there's room enough for both approaches.

No, I'm saying that the "astronomer" who goes to an astronomy forum and talks about about he's not interested in either black holes or pulsars, complains that caring about both is for "uber-geeks," and stresses that his real passion is for designing the most ergonomic telescope, or for figuring out a way to make viewing time on the Hubble affordable to the common man is NOT A FUCKING ASTRONOMER.

You seem to be under the impression that "bringing computing to the common man" is part of computer science. It's not. It's about as related to computer science as designing a cheap, stable tripod for telescopes is to astronomy.

Or, (since you actually aren't in the business of writing more usable software tools anyway) to bring the analogy closer to your real life example, writing everyday business logic is like printing a lunar calendar. Sure, it requires knowledge of astronomy. But if it's all you do, day in and day out, without ever stretching yourself to learn more or improve, you can't call yourself a real astronomer. You are a hack who is simply treading down the well-worn paths that better men have hewn just to punch a clock and make a living. And that's fine. It's good to make a living, and there can be pride in doing so. But never, never take that smug fucking superior tone as if the people who actually care about the science, who are actually advancing the broad spectrum human knowledge and understanding are less than you are.

 

[blakeyrat]

@Soviut said:

Would you like to see an example in Python or Ruby perhaps? Both of which have generators and iterators. The fact that you're the only one here who doesn't understand the benefits of generators is pretty telling.

Well if you think I don't, then I don't.

@Soviut said:

Meanwhile, all that "morning iteration" you did probably involved a fair number of foreach loops.

Of course, I'd be stupid not to. That's not even hypocrisy. It's not any kind of argument at all.

I like and promote electric cars, but I drive a hybrid which burns gas. OH NOES I AM INTELLECTUALLY DISHONEST I LOSE ALL DEBATES EVER I-- oh wait you're just an idiot.

[blakeyrat]

@Mason Wheeler said:

Do you understand the difference between eager and lazy evaluation?

Yes. Do you understand the difference between psuedo-code and actual code?

I was asked to perform a task without using the yield keyword. I met those requirements. QED. Fuck off.

[blakeyrat]

@Snooder said:

You seem to be under the impression that "bringing computing to the common man" is part of computer science. It's not. It's about as related to computer science as designing a cheap, stable tripod for telescopes is to astronomy.

Ok, then by your definition (which I disagree with, but whatever), I have no interest in computer science.

[Mason_Wheeler]

@blakeyrat said:

@Mason Wheeler said:

Do you understand the difference between eager and lazy evaluation?

Yes. Do you understand the difference between psuedo-code and actual code?

I was asked to perform a task without using the yield keyword. I met those requirements. QED. Fuck off.

*sigh*  I point out that you missed the point, and you again miss the point in responding. 

When the entire point of what you were asked is to do the equivalent of a construct that performs lazy evaluation on a data set too large for eager evaluation to be practical, putting a magical "stuff it all in a list or whatever" method in there with no explanation of how it works does not meet those requirements, pseudocode or not.

 

 

[blakeyrat]

This is the post I was replying to:

@Soviut said:

@blakeyrat said:

@Ben L. said:

Let's compare the "equivalent" options:

blakeyrat's list: SELECT * FROM table WHERE simple_condition;. Iterate through each item and add the calculated value to a list. Return the list. Requires O(n) time and O(n) space.

yield: SELECT * FROM table WHERE simple_condition;. Iterate through each item and yield return the value. Requires O(n) time and O(1) space.

So blakey, how's that infinite memory computing device coming?

You can do that without the yield, though. Easily.

By all means, show an example.

I don't see any mention of lazy evaluation. In fact, my code is exactly equivalent to Ben L's original, as far as I can determine. Both select all records at once; the only difference is that I made a little remark about how you probably wouldn't want to select * from a table as big as the one Ben L originally mentioned.

I'm sorry that you're having trouble following the flow of the conversation, but that is not my fault. And my psuedo-code solves the problem as presented.

[Mason_Wheeler]

@blakeyrat said:

I don't see any mention of lazy evaluation.

It's implicit in the use of "yield," and explicit in the mention of using O(1) memory.

In fact, my code is exactly equivalent to Ben L's original, as far as I can determine.

See above, re: missing the entire point.

Both select all records at once; the only difference is that I made a little remark about how you probably wouldn't want to select * from a table as big as the one Ben L originally mentioned.

Ah, I see.  So it's not that you don't understand lazy evaluation; it's that you don't understand query result readers.

Here's a hint: any sanely-engineered database library will not return all records at once, even if you select all the records.  Yes, most datasets that the programmer deals with, particularly if the dataset is bound to a UI, do eagerly gather everything, but they're built on top of a lower layer that fetches results lazily from the DBMS, precisely to avoid this sort of problem. So, yeah.  My original point stands, it seems: you don't "get" lazy vs. eager evaluation.

I'm sorry that you're having trouble following the flow of the conversation, but that is not my fault.

 

Right back atcha, bub.

 

[blakeyrat]

Ok you win. I don't fully understand something I don't think is necessary and will never use in practice. Whee. Good for you. You win a trophy or whatever.

[Ben L.]

@blakeyrat said:

Ok you win. I don't fully understand something I don't think is necessary and will never use in practice. Whee. Good for you. You win a trophy or whatever.

What field do you work in, anyway?

[blakeyrat]

At the moment, I'm writing some server code to route text messages. But I probably won't be doing it long, since I'm not digging this job or the company, and I really don't like not being able to write user-facing code honestly.

[Snooder]

@blakeyrat said:

Ok you win. I don't fully understand something I don't think is necessary and will never use in practice. Whee. Good for you. You win a trophy or whatever.

You know what's the best way to develop WTF code? Not understanding the principles involved in a task and then either not giving enough of a fuck to learn, or having so much hubris that you don't think you have to.

We don't win a trophy when you continue to have contempt for the industry in which you practice. All we gain is more shit code written by another shit developer.

[Ben L.]

@blakeyrat said:

At the moment, I'm writing some server code to route text messages. But I probably won't be doing it long, since I'm not digging this job or the company, and I really don't like not being able to write user-facing code honestly.

Okay, let's say your text message delivering server was down for some reason and you have a backlog of 123456789 text messages. Wikipedia says text messages are 140 octets long. For the sake of being over-simplistic, let's say phone numbers and other metadata take up zero bytes. That's 17.28 gigabytes. Again, this number doesn't include any of the record-keeping data or the routing information; just the message payloads.

You have two obvious options: you can pull all the unsent text messages from the database, split them up in code, and send them in batches; or you can pull batches of unsent text messages from the database and send them along.

The options boil down to a choice between having O(n) memory usage or O(1) memory usage. In fact, even if memory is not a concern (as we already know blakeyrat has a magical infinite-memory computer) the O(1) method takes less steps. The only difference between the two options is that the first one has an extra step of adding the database rows to a list. You're iterating over something n times either way. Your method just does it twice instead of once.

[blakeyrat]

Silly me, I thought you were asking out of some sort of personal interest.

[pjt33]

@boomzilla said:

First he rants about how "things haven't changed from the 70s." But then when confronted with an invention of the 70s that makes it easier to write non-sucky (from the user's perspective and the deveoper's) applications, his response is, "I don't need to learn this new fangled stuff!"

Everything old is new again.

[dkf]

@blakeyrat said:

You can do that without the yield, though. Easily.

You never technically need yield, and you can always write the equivalent functionality without it. It's just that sometimes it is much harder to do that.

The hard cases are where you've got non-1-to-1 value transform patterns, either because you've got to remove some or because you've got to add some as you go. You most surely can write the code there without yielding iterators, but the state machine management required is a bit brain-bending and hard to get right. Transforming that chunk of state management nastiness into control-flow and using yield makes it all much simpler (and hence much less likely to be coded wrongly). Getting the code right quickly isn't technically required as such; it's just that it's the sort of thing that people tend to want…

[blakeyrat]

Right and despite all this super magic computer science wizardry, still nobody can fucking figure out how to use your program.

[flabdablet]

@boomzilla said:

@pjt33 said:

@flabdablet said:

@Mason Wheeler said:

The point being made by the OP is that this seems like a silly and needless alternative to simply returning the original sequence.

That would be a perfectly fair point if you were the kind of ableist who believes that it is right and proper for programming languages to support abstractions that are not instantly obvious to any user.

On the subject of being instantly obvious, what is your point? That wrapping a layer of abstraction which adds nothing except execution time is a good thing?

It was blakeysatire.

I thought it was blakeysatire. Then blakey got back in the thread. Apparently it was actually just blakeyparaphrase.

[boomzilla]

It's difficult to understand the thinking behind such statements:

@blakeyrat said:

Right and despite all this super magic computer science wizardry, still nobody can fucking figure out how to use your program.

Your'e raising your normal ignorance to a new level. You're saying that we should spend more time reinventing low level stuff instead of focusing on usability. I thought you were for usability. I guess I should know better by now than to read what you write and assume it could be coherent.

[Snooder]

@blakeyrat said:

Right and despite all this super magic computer science wizardry, still nobody can fucking figure out how to use your program.

What the hell are you talking about? Making sure that users can use a program isn't computer science, it's UI design (which can be either sociology, psychology or art). Nor is it the purview of a *language designer* to make sure that *end users* can use the software built in their language.

[blakeyrat]

We already covered that. Remember? Yesterday? I said, "if that's how you define 'computer science', then I have no interest in computer science." It was just yesterday. Remember it? Come on. Think really, really hard.

[boomzilla]

@blakeyrat said:

We already covered that. Remember? Yesterday? I said, "if that's how you define 'computer science', then I have no interest in computer science." It was just yesterday. Remember it? Come on. Think really, really hard.

But if you're only interested in UI design, what the hell were you doing when you were coding those iterations the other day?

This is like trying to talk to a 5 year old who keeps making things up to justify the inane things he said before, except that's reasonable behavior for the 5 year old.

[dhromed]

@boomzilla said:

But if you're only interested in UI design, what the hell were you doing when you were coding those iterations the other day?

 

It is not remotely strange that someone interested in users vs software would write code. It is not remotely strange that such a person is a programmer.

[dhromed]

@boomzilla said:

@blakeyrat said:

Right and despite all this super magic computer science wizardry, still nobody can fucking figure out how to use your program.

You're saying that we should spend more time reinventing low level stuff instead of focusing on usability. I thought you were for usability.

 

I'm having a hard time extracting that from the bit you quoted. The opposite, rather.

[boomzilla]

@dhromed said:

@boomzilla said:

But if you're only interested in UI design, what the hell were you doing when you were coding those iterations the other day?

It is not remotely strange that someone interested in users vs software would write code. It is not remotely strange that such a person is a programmer.

I don't find that strange either, except that blakeyrat keeps telling us how irrelevant all this programming stuff is to him. Except for when he doesn't. As I said above, it's like talking to a 5 year old who cannot keep his story straight.

@dhromed said:

@boomzilla said:

@blakeyrat said:

Right and despite all this super magic computer science wizardry, still nobody can fucking figure out how to use your program.

You're saying that we should spend more time reinventing low level stuff instead of focusing on usability. I thought you were for usability.

I'm having a hard time extracting that from the bit you quoted. The opposite, rather.

My comment was more of a synthesis of the thread than a simple and direct response. Let's remember that we're talking about a language feature that allows the programmer to lazily iterate through...something...which could be calculated as you go...without having to implement a state machine and get all of that correct. So instead of getting this done easily and focusing on the user's experience, blakeyrat is advocating that we focus on implementing the low level details instead of user experience.

He's not explicitly saying that, but it's the end result of what he's saying. In reality, it's just a new concept that he's not familiar with. He'd probably have the same reaction to abstract classes or primary keys if he didn't already understand those things. But it's his typical pattern of refusing to learn new concepts and insisting that if he doesn't already understand it, it's not worth anything. Which is of course amusing in light of his evangelizing for innovation.

We've often wondered if Spectate is some sort of performance art, but I think maybe blakeyrat is a better candidate for such a thing.

[Buttembly_Coder]

@boomzilla said:

We've often wondered if Spectate is some sort of performance art, but I think maybe blakeyrat is a better candidate for such a thing.

Wait, blakey's an actual person? I thought it was just an account most of you knew the login for, and that you posted whatever you wanted to make more discussion…

[blakeyrat]

I am going to reply to Boomzilla because he is being SO obnoxious in this thread I feel I have to tamp down the idiocy a bit. Last we saw Boomzilla, he was claiming I said the exact opposite of what I actually said. This time, he's saying:

@boomzilla said:

But if you're only interested in UI design, what the hell were you doing when you were coding those iterations the other day?

It's called "having a job". I do the tasks my employer assigns me. You fucking idiot.

The sad part is, you're right: they're putting me on back-end work when I was hired to do (and am best at) front-end work. But guess what? 1) This back-end work is holding up front-end work, and 2) despite how stupid you all think I am, I'm still better at doing this back-end coding than the idiot who was doing it before and broke everything. So I'm doing the back-end work because my employer asked me to and I like getting paychecks.

That says nothing about what interests me.

[boomzilla]

@blakeyrat said:

@boomzilla said:

But if you're only interested in UI design, what the hell were you doing when you were coding those iterations the other day?

It's called "having a job". I do the tasks my employer assigns me.

This is a fair statement.

@blakeyrat said:

So I'm doing the back-end work because my employer asked me to and I like getting paychecks.

That says nothing about what interests me.

I think that most people aren't doing their "dream job," and even of those who are, a lot of that job is stuff they wouldn't do unless someone were paying them. Many people are nevertheless interested in figuring out how to do the scut work better, or at least more quickly, which is directly relevant to this thread and to you and your situation in particular.

Instead of, like dhromed, saying, "Thanks for introducing me to something I wasn't familiar with," you'd rather say this stuff isn't useful to you, which is cool, I guess, because it gives the rest of us an easy target. The evolution of this thread reminds me of your stock take on how it's a WTF when developers don't know SQL basics (which is spot on, BTW) and refuse to learn. Physician, heal thyself!

[Buttembly_Coder]

@boomzilla said:

Instead of, like dhromed, saying, "Thanks for introducing me to something I wasn't familiar with," you'd rather say this stuff isn't useful to you, which is cool, I guess, because it gives the rest of us an easy target. The evolution of this thread reminds me of your stock take on how it's a WTF when developers don't know SQL basics (which is spot on, BTW) and refuse to learn. Physician, heal thyself!

To be fair, if he were saying "I'd rather spend my time learning how to make more accessible or usable software, rather than learn language features I don't believe I'd use.", that would be fine. Completely useless to the thread, but fine.

Similarly, if his complaint was that "Too many software developers spend their time learning programming tricks rather than how to make more usable software.", that would also be fine, and relevant to the thread.

I'm thinking his point, stated in an incredibly ham-fisted way, is that he believes The Industry focuses too much on Software as a thing made of Lines Of Code, and not enough as a thing that people who aren't programmers have to use. Essentially, the same soapbox he tends to claim as residence in most threads.

Edit: called it.

[blakeyrat]

@boomzilla said:

Many people are nevertheless interested in figuring out how to do the scut work better, or at least more quickly, which is directly relevant to this thread and to you and your situation in particular.

"scut?"

Who said I wasn't interested in ways to do my back-end coding better or more quickly? Where are you getting that from? Definitely not anything I typed.

@boomzilla said:

Instead of, like dhromed, saying, "Thanks for introducing me to something I wasn't familiar with," you'd rather say this stuff isn't useful to you,

Right; it's not useful to me. But now I know it might be useful in some hypothetical future situation, and if that situation arose than I'd definitely think back to this operator and use it. I'd be stupid not to. Just because I didn't say "thank you" doesn't mean I wasn't also introduced to it in this thread. I guess I didn't realize that you had some magical rule that says "everybody who doesn't post a thank you message didn't learn anything from reading the thread".

But that's not what I'm talking about. My gripe is with an community/industry/whatever that spends time creating things like yield (which, as has been pointed out many times in this thread, can easily be implemented without special compiler support) when they should be spending that time creating things that actually increase the usability of software and/or improve the user experience for everybody. The priorities are completely ass-backwards.

It's possible for people to use and benefit from something they fundamentally disagree with. That's not hypocrisy, as people have tried to paint it in this thread. It's not any argument at all. I can both use and benefit from yield and also criticize the industry who spent time creating the constructs when there was much more important work to be done. I can both use and benefit from git while decrying how terrible it is, usability-wise.

@boomzilla said:

The evolution of this thread reminds me of your stock take on how it's a WTF when developers don't know SQL basics (which is spot on, BTW) and refuse to learn. Physician, heal thyself!

The "refuse to learn" part is all in your head. I have no idea where you're getting that from.

[boomzilla]

@blakeyrat said:

@boomzilla said:

Many people are nevertheless interested in figuring out how to do the scut work better, or at least more quickly, which is directly relevant to this thread and to you and your situation in particular.

"scut?"

Who said I wasn't interested in ways to do my back-end coding better or more quickly? Where are you getting that from? Definitely not anything I typed.

Who said I included you in "many people?" In any case, I assert that it would be useful to you in spite of your vehemence up thread.

@blakeyrat said:

Right; it's not useful to me. But now I know it might be useful in some hypothetical future situation, and if that situation arose than I'd definitely think back to this operator and use it. I'd be stupid not to. Just because I didn't say "thank you" doesn't mean I wasn't also introduced to it in this thread. I guess I didn't realize that you had some magical rule that says "everybody who doesn't post a thank you message didn't learn anything from reading the thread".

I don't have any such rule. The thank you is often more of a tone thing, and was more for emphasis. In any case, thanks for the admission here.

@blakeyrat said:

But that's not what I'm talking about. My gripe is with an community/industry/whatever that spends time creating things like yield (which, as has been pointed out many times in this thread, can easily be implemented without special compiler support) when they should be spending that time creating things that actually increase the usability of software and/or improve the user experience for everybody. The priorities are completely ass-backwards.

Yes, you've belabored this a zillion times, but there's still a time and a place to edumacate people about the tools they need to use to do just that. You've been sounding like the sort of people you argue against who continue to use low level languages when appropriate higher level languages exist.

@blakeyrat said:

It's possible for people to use and benefit from something they fundamentally disagree with. That's not hypocrisy, as people have tried to paint it in this thread.

I agree that's not hypocrisy (and I made a similar point in another thread recently). You're the only one who has mentioned that in this forum.

@blakeyrat said:

The "refuse to learn" part is all in your head. I have no idea where you're getting that from.

I'll admit that part of my conclusion was based on previous threads, but there was also stuff like this:

@previously on blakeyrat said:

I iterated a dozen things just this morning. Maybe I'm a super-genius, but... I still think it's a solved problem and you insisting otherwise isn't going to change my mind.

@previously on blakeyrat said:

Ok you win. I don't fully understand something I don't think is necessary and will never use in practice. Whee. Good for you. You win a trophy or whatever.

But based on this post, you seem to have accepted that there's something useful here, so I guess at some point you agreed to learn, and I was wrong.

[HardwareGeek]

@blakeyrat said:

But that's not what I'm talking about. My gripe is with an community/industry/whatever that spends time creating things like yield (which, as has been pointed out many times in this thread, can easily be implemented without special compiler support) when they should be spending that time creating things that actually increase the usability of software and/or improve the user experience for everybody. The priorities are completely ass-backwards.

FTFY

Both activities are necessary for end-user usability. If nobody spent time improving languages, end-users would suffer. Usability wouldn't even a topic for serious discussion, because we'd all still be programming in assembly language on our 80486s*; if we were lucky, UI usability might have advanced to the level of Windows 3.1.

You can argue about the amount of effort that should be spent on "computer science" like language development relative to the amount of effort that should be spent improving UIs, but both are necessary. Boomzilla's point, I think, is that language improvements allow developers to get the program logic right with less effort, therefore allowing them to spend more time working on the UI. (Whether they actually do so, and whether any extra effort they do put into the UI actually improves usability, or just results in Firefox ++$VERSION and Windows 8, are entirely different questions.)

* Because the software used to design modern processors would be about 20 years less powerful than that used now

[Snooder]

@blakeyrat said:

But that's not what I'm talking about. My gripe is with an community/industry/whatever that spends time creating things like yield (which, as has been pointed out many times in this thread, can easily be implemented without special compiler support) when they should be spending that time creating things that actually increase the usability of software and/or improve the user experience for everybody. The priorities are completely ass-backwards.

The problem here, and what I'm trying to get you to understand by making a distinction between computer science and "non computer science," is that's complete bullshit. Someone who spends his time on improving compilers or on updating language features is a computer scientist. He is likely NOT a UI or UX specialist. Nor does he need to be. If he spends every waking hour thinking up better language features and zero time on trying to make his language accessible to users, then he's a great computer scientist doing a great job. And if he does the opposite, then he's a shit computer scientist doing a shit job.

Language features do not need to be accessible. Software programming and design tools are not something that *need* to be made easier for idiots. It's nice to have yes, but what *needs* to be done is to make progress and advancements for the people who are actually going to use said language features. Choosing to cut a 'yield'-like functionality so that an idiot with zero training or skill can slap together code is NOT the direction the industry needs to go. And you are the only eccentric trying to force it there.

[blakeyrat]

@Snooder said:

Someone who spends his time on improving compilers or on updating language features is a computer scientist. He is likely NOT a UI or UX specialist. Nor does he need to be.

Wrong. Programming languages have users, therefore they have user experiences.

@Snooder said:

If he spends every waking hour thinking up better language features and zero time on trying to make his language accessible to users, then he's a great computer scientist doing a great job.

Wrong.

@Snooder said:

Language features do not need to be accessible

They don't "need" to be, but they certainly should be. Why do you think C# is a better language than C++? (Although, I guess, maybe you don't believe it is...)

@Snooder said:

Software programming and design tools are not something that need to be made easier for idiots.

The "for idiots" part of this is a baseless insult of 95% of the population of the planet, and in their defense let me reply: fuck you too.

@Snooder said:

It's nice to have yes, but what needs to be done is to make progress and advancements for the people who are actually going to use said language features.

If you have a 100 coders who can make a task 10 times faster, you've accelerated the world by 1,000 times. If you have 10,000 regular joes who can (thanks to easy-to-use programming environment) can make their tasks even twice as fast, you've accelerated the world by 20,000 times.

You have to consider the end-goal here. If your end-goal is, "me and and my upper-middle-class cronies make a lot of money", then good news, we're already there. That's not my end-goal though.

[Mason_Wheeler]

@blakeyrat said:

If you have a 100 coders who can make a task 10 times faster, you've accelerated the world by 1,000 times. If you have 10,000 regular joes who can (thanks to easy-to-use programming environment) can make their tasks even twice as fast, you've accelerated the world by 20,000 times.

 

Someone get this guy a copy of The Mythical Man-Month before he makes an even bigger fool of himself...

 

[Ben L.]

@blakeyrat said:

@Snooder said:

Software programming and design tools are not something that need to be made easier for idiots.

The "for idiots" part of this is a baseless insult of 95% of the population of the planet, and in their defense let me reply: I just called 95% of the people on the planet idiots.

FTFY

[Ben L.]

@Mason Wheeler said:

@blakeyrat said:

If you have a 100 coders who can make a task 10 times faster, you've accelerated the world by 1,000 times. If you have 10,000 regular joes who can (thanks to easy-to-use programming environment) can make their tasks even twice as fast, you've accelerated the world by 20,000 times.

 

Someone get this guy a copy of The Mythical Man-Month before he makes an even bigger fool of himself...

 

If there is 1 pregnant woman, the baby will appear in 9 months.

Therefore, if there are 2.365×10¹⁶ pregnant women, the baby will appear in 1 nanosecond.

It's just simple blakeymath!

[blakeyrat]

@Mason Wheeler said:

Someone get this guy a copy of The Mythical Man-Month before he makes an even bigger fool of himself...

I've read it. I don't get the relevance to my post.