ad hoc Programming
-
C# sort of has it too, with deconstructing: Deconstructing tuples and other types | Microsoft Docs[^] It's quick and easy to do with tuples, but you can add any number of Deconstruct methods to a class as well. I see destructuring (in any language) as another tool in your toolbox that can be helpful if used judiciously. Of course, that depends on people having good taste and knowing when to use something, and when not to. X| I also find it mildly amusing that every language seems to be slowly implementing features Common Lisp had decades ago - destructuring bind, in this case. I'm convinced that Lisp programmers are playing the long game and aiming to achieve ultimate victory by very gradually changing every programming language into Lisp. Maybe some variant of Greenspun's Tenth Rule in action here. :laugh:
Ryan Peden wrote:
Of course, that depends on people having good taste and knowing when to use something, and when not to
Agree 100% and that really is my point. These new features are really great when used at the appropriate time. I just see that now in many cases all programming is becoming these bits and pieces type of things and many newer devs think this is correct. A Training / Teaching Problem, Really It is most likely the fault of the training and not the language, of course. It's just becoming quite pervasive and I believe is leading to a lot of crapware that does a few things right, looks shiny but then has bugs that no one can find because the maintenance is a nightmare.
Ryan Peden wrote:
every language seems to be slowly implementing features Common Lisp had decades ago
That's fantastic you mentioned that, because I often mention this new functional-type aspects of new languages and people mention old languages had this already. I believe it. Again, I think these new things are great. It's just that they are so often meant to be used 20% of the time and instead they are implemented 98% of the time. :) Great discussion.
-
Ryan Peden wrote:
Of course, that depends on people having good taste and knowing when to use something, and when not to
Agree 100% and that really is my point. These new features are really great when used at the appropriate time. I just see that now in many cases all programming is becoming these bits and pieces type of things and many newer devs think this is correct. A Training / Teaching Problem, Really It is most likely the fault of the training and not the language, of course. It's just becoming quite pervasive and I believe is leading to a lot of crapware that does a few things right, looks shiny but then has bugs that no one can find because the maintenance is a nightmare.
Ryan Peden wrote:
every language seems to be slowly implementing features Common Lisp had decades ago
That's fantastic you mentioned that, because I often mention this new functional-type aspects of new languages and people mention old languages had this already. I believe it. Again, I think these new things are great. It's just that they are so often meant to be used 20% of the time and instead they are implemented 98% of the time. :) Great discussion.
Yeah, exactly. Every feature needs to be used responsibly. It's like...when I was a child, I loved grape Kool-Aid. It was tasty and fun. I would have happily drank a gallon of it per day. But the adults in my life wouldn't let me. Now that I'm an adult, I could drink a gallon of Kool-Aid every day, because nobody would stop me. But I don't, because I'm not crazy. Everything in moderation, right? But with features like destructuring, some developers don't have that sense of moderation. They think that since you can destructure, you should destructure everything. Heck, now that I think about it, maybe they are sitting there guzzling grape Kool-Aid as they destructure every second line of their JS. If you're going to go overboard you may as well go all-in. And you're right - it's funny how most new features are really that new at all. Maybe if we had all learned from Perl, developers would be cognizant of the horrors of destructuring run amok and be a little more hesitant to pull it out of their JS toolbox too often.
-
C# sort of has it too, with deconstructing: Deconstructing tuples and other types | Microsoft Docs[^] It's quick and easy to do with tuples, but you can add any number of Deconstruct methods to a class as well. I see destructuring (in any language) as another tool in your toolbox that can be helpful if used judiciously. Of course, that depends on people having good taste and knowing when to use something, and when not to. X| I also find it mildly amusing that every language seems to be slowly implementing features Common Lisp had decades ago - destructuring bind, in this case. I'm convinced that Lisp programmers are playing the long game and aiming to achieve ultimate victory by very gradually changing every programming language into Lisp. Maybe some variant of Greenspun's Tenth Rule in action here. :laugh:
-
Last night herself was watching a show and I decided to start reading a book to learn React. :sigh: I know, but I wanted to see what it does. The 2nd chapter of this book (Learning React: Modern Patterns for Developing React Apps 2, Banks, Alex, Porcello, Eve, eBook - Amazon.com[^]) melted my brain!! I discovered JavaScript Destructuring!
Quote:
Destructuring assignment allows you to locally scope fields within anobject and to declare which values will be used.
Code Sample
const sandwich = { bread: "dutch crunch",
meat: "tuna", cheese: "swiss",
toppings: ["lettuce", "tomato", "mustard"]
};
const { bread, meat } = sandwich;
console.log(bread, meat); // dutch crunch tunaYou see, the sandwich object can be all chopped up and turned into separate objects. It's very cool AND very terrible! Destructured Array
const [firstAnimal] = ["Horse", "Mouse", "Cat"];
console.log(firstAnimal); // HorseSee, now you have a variable that contains the first value. Suppose you want a variable that contains the last value.
const [, , thirdAnimal] = ["Horse", "Mouse", "Cat"];
console.log(thirdAnimal); // CatGetting To A Point I'm getting to the main point, here and I think it has a pay-off Now we also know that JavaScript (and many modern languages) have the concept of a anonymous functions (C#) or arrow functions in JavaScript. They are very convenient and helpful and can make code much more readable.
hello = val => console.log("Hello " + val);
hello("test this") // Hello test thisThink About the Young Impressionable Minds Now, think about new devs who come along and learn this stuff first thing. Suddenly this is the beautiful code. It is amazing. You can do anything at anytime. It's
Don't worry, all this will go away as the business model moves to low code / no code solutions. :laugh:
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
I see your deconstructing and raise you
var. I die a little inside every time I see C# code that looks like Javascript.varwas meant for implicit typing of generated types without accessible symbols (e.g. anonymous types).I love var and auto *hides* *peeks out* I hate duck typed languages though
Real programmers use butterflies
-
I love var and auto *hides* *peeks out* I hate duck typed languages though
Real programmers use butterflies
-
:laugh: We've all got a little inconsistency in us. I like Typescript but despise raw Javascript.
I agree with you about typescript. I actually think it's kind of refreshing to have hard types over the top of JS. It almost makes me want to use it. I may have to soon as I'm about to code a VS Code extension (bless VS Code)
Real programmers use butterflies
-
I agree with you about typescript. I actually think it's kind of refreshing to have hard types over the top of JS. It almost makes me want to use it. I may have to soon as I'm about to code a VS Code extension (bless VS Code)
Real programmers use butterflies
-
It has finally replaced visual studio for me, but then i've been doing a lot of development for cross platform including unix, windows, apple, and even arduinos so I'm not coding on a windows OS primarily. I'm on linux right now. But I really like VS Code. The cpp extension intellisense is still a bit rough around the edges compared to visual studio, but much better than other offerings even at that. and the extensions.. i can view any kind of file i want. The 31 flavors of makefile, an html file, hell, even a graphviz dot file, complete with graphical preview. It's fantastic. I don't need 20 editors in my kit anymore. And I think extensions can sync across machines so you might not have to set it up over and over again every time you change machines, although don't quote me on that. I'm still looking into it.
Real programmers use butterflies
-
C# sort of has it too, with deconstructing: Deconstructing tuples and other types | Microsoft Docs[^] It's quick and easy to do with tuples, but you can add any number of Deconstruct methods to a class as well. I see destructuring (in any language) as another tool in your toolbox that can be helpful if used judiciously. Of course, that depends on people having good taste and knowing when to use something, and when not to. X| I also find it mildly amusing that every language seems to be slowly implementing features Common Lisp had decades ago - destructuring bind, in this case. I'm convinced that Lisp programmers are playing the long game and aiming to achieve ultimate victory by very gradually changing every programming language into Lisp. Maybe some variant of Greenspun's Tenth Rule in action here. :laugh:
Ryan Peden wrote:
you can add any number of Deconstruct methods to a class as well
You can also add deconstructors as extension methods:
static class DateExtensions
{
public static void Deconstruct(this DateTime value, out int year, out int month, out int day) => (year, month, day) = (value.Year, value.Month, value.Day);
}var (year, month, _) = DateTime.Today;
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
Last night herself was watching a show and I decided to start reading a book to learn React. :sigh: I know, but I wanted to see what it does. The 2nd chapter of this book (Learning React: Modern Patterns for Developing React Apps 2, Banks, Alex, Porcello, Eve, eBook - Amazon.com[^]) melted my brain!! I discovered JavaScript Destructuring!
Quote:
Destructuring assignment allows you to locally scope fields within anobject and to declare which values will be used.
Code Sample
const sandwich = { bread: "dutch crunch",
meat: "tuna", cheese: "swiss",
toppings: ["lettuce", "tomato", "mustard"]
};
const { bread, meat } = sandwich;
console.log(bread, meat); // dutch crunch tunaYou see, the sandwich object can be all chopped up and turned into separate objects. It's very cool AND very terrible! Destructured Array
const [firstAnimal] = ["Horse", "Mouse", "Cat"];
console.log(firstAnimal); // HorseSee, now you have a variable that contains the first value. Suppose you want a variable that contains the last value.
const [, , thirdAnimal] = ["Horse", "Mouse", "Cat"];
console.log(thirdAnimal); // CatGetting To A Point I'm getting to the main point, here and I think it has a pay-off Now we also know that JavaScript (and many modern languages) have the concept of a anonymous functions (C#) or arrow functions in JavaScript. They are very convenient and helpful and can make code much more readable.
hello = val => console.log("Hello " + val);
hello("test this") // Hello test thisThink About the Young Impressionable Minds Now, think about new devs who come along and learn this stuff first thing. Suddenly this is the beautiful code. It is amazing. You can do anything at anytime. It's
Here young programmer: take this rope. Take as much as you need...
cheers Chris Maunder
-
Last night herself was watching a show and I decided to start reading a book to learn React. :sigh: I know, but I wanted to see what it does. The 2nd chapter of this book (Learning React: Modern Patterns for Developing React Apps 2, Banks, Alex, Porcello, Eve, eBook - Amazon.com[^]) melted my brain!! I discovered JavaScript Destructuring!
Quote:
Destructuring assignment allows you to locally scope fields within anobject and to declare which values will be used.
Code Sample
const sandwich = { bread: "dutch crunch",
meat: "tuna", cheese: "swiss",
toppings: ["lettuce", "tomato", "mustard"]
};
const { bread, meat } = sandwich;
console.log(bread, meat); // dutch crunch tunaYou see, the sandwich object can be all chopped up and turned into separate objects. It's very cool AND very terrible! Destructured Array
const [firstAnimal] = ["Horse", "Mouse", "Cat"];
console.log(firstAnimal); // HorseSee, now you have a variable that contains the first value. Suppose you want a variable that contains the last value.
const [, , thirdAnimal] = ["Horse", "Mouse", "Cat"];
console.log(thirdAnimal); // CatGetting To A Point I'm getting to the main point, here and I think it has a pay-off Now we also know that JavaScript (and many modern languages) have the concept of a anonymous functions (C#) or arrow functions in JavaScript. They are very convenient and helpful and can make code much more readable.
hello = val => console.log("Hello " + val);
hello("test this") // Hello test thisThink About the Young Impressionable Minds Now, think about new devs who come along and learn this stuff first thing. Suddenly this is the beautiful code. It is amazing. You can do anything at anytime. It's
It's all great until you come to debug it, then as a colleague mentioned to me, you find yourself having to refactor the code just so that you can put breakpoints in useful places. I was taught structured programming back in university in 1988 and while I like a lot of these modern developments they do also need to be used with care bearing in mind that someone is going to have to debug this at some point.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I see your deconstructing and raise you
var. I die a little inside every time I see C# code that looks like Javascript.varwas meant for implicit typing of generated types without accessible symbols (e.g. anonymous types).For writing code
varis great, for reading codevaris not always so great. I reckon at least 90% of my time is spent reading code.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
For writing code
varis great, for reading codevaris not always so great. I reckon at least 90% of my time is spent reading code.“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
I agree on the last two points, but I can't say I agree on the first.
var x = retrieveValue();
What type is
x? You could use intellisense in most IDEs to see but that takes time. It also has another subtle but potentially nefarious problem: it shows the actual type but not the type you need. In situations where you require a super/base type but receive a sub/derived type, you may be fooled into thinking that the code expects the sub/derived type if you aren't familiar with the architecture (e.g. maintainers, new contributors). There are a slew of problems that could come from this. Personally I feel like that last point is largely irrelevant despite being potentially serious since the greater issue is that you've willingly become less expressive purely to save a couple keystrokes. That's just my 2 cents though. I know some projects that liberally usevarand have kept the issues under control even if I'd argue the time spent on control outweighs the keystrokes saved. Also in all fairness my argument blurs the read/write line a bit, but maintenance inevitably requires modifying/writing code. -
I agree on the last two points, but I can't say I agree on the first.
var x = retrieveValue();
What type is
x? You could use intellisense in most IDEs to see but that takes time. It also has another subtle but potentially nefarious problem: it shows the actual type but not the type you need. In situations where you require a super/base type but receive a sub/derived type, you may be fooled into thinking that the code expects the sub/derived type if you aren't familiar with the architecture (e.g. maintainers, new contributors). There are a slew of problems that could come from this. Personally I feel like that last point is largely irrelevant despite being potentially serious since the greater issue is that you've willingly become less expressive purely to save a couple keystrokes. That's just my 2 cents though. I know some projects that liberally usevarand have kept the issues under control even if I'd argue the time spent on control outweighs the keystrokes saved. Also in all fairness my argument blurs the read/write line a bit, but maintenance inevitably requires modifying/writing code.But who the hell is naming their function
retrieveValue?"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
But who the hell is naming their function
retrieveValue?"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
