(untitled)

Sometimes I feel that the programming industry and/or hobby community take programming too seriously, focusing on serious matters like correctness, safety, compliance, etc. No doubt these are all important concepts in many contexts contexts, but I think there is room for a casual carefree approach to programming that prioritizes making cute things to have fun. What are some good ways to banish stuffiness from your project? I'm thinking about adding elaborate unicode art to my projects.

>but I think there is room for a casual carefree approach to programming that prioritizes making cute things to have fun. if you're making something that people will rely on to work properly 100% of the time, you can not have this attitude. End of story.

>>16596 >if you're making something that people will rely on to work properly 100% of the time Not everybody is writing avionics software though. Isn't there any room for fun?

>>16597 sure there is. Funny comments and whatever is always fun. I think there's a difference between having fun and "casual carefree approach". I don't want that approach anywhere in my Trusted Computing Base, that's serious stuff for a good reason.

I dont work and i dont care, but as someone who takes his programming seriouslyi have this to say: programs work as intended or they dont, that is the essence and nature of programming itself. I dont approve of people halfassing things, we all do it but its not excuse, software works or it doesnt.

>>16595 Look into "future of coding" stuff https://futureofcoding.org/

>>16599 I feel like OP is more likely refering to the creational engineering process of software which, if obeying to strict rules that are generally perceived as best practise, might be no pleasure, even though the software is not meant to meet any standards other than executing properly.

>>16595 There's always room for fun if you aren't making something that is a work tool. I personally think "emojis" are pure cancer and would find other things to have fun with, like little puzzles and functional ascii arts like the "just another perl hacker" programs, but if you like those emojis, just do it and have fun. Actually your question has nothing to do with programming, you literally ask: "Is it OK for me to like something that other people don't like?" The answer of course is yes. Actually if you don't use violence to make people use your software against their will (like microsoft, google, etc does through government regulations) you can even have fun in non-free work tool codes without being unethical. You would be an asshole, but technically still ethical.

>>16595 Problem: people focus on correctness, safety, compliance too much in programming. Rebuttals (so far): no they don't. Proposed solutions (so far): just do stuff where correctness, safety, compliance doesn't matter. Make a non-networked non-moddable non-updated roguelike game and run it in a browser where it at least probably can't destroy your data. Alternate solution: APL (or J, or Q, or) If you've maintained some normal software even once, and been in the position of having to push changes to it even once, then you'll emphasize a lot with the industry focus, because this is terrifying. There aren't enough tests or compiler checks or peer review or formal checks in the world, and you certainly will not have anything approaching 'enough'. More likely your confirmation that your change was actually OK will be fires not immediately starting everywhere as the result of your change. Sometimes your confirmation will be betrayed: six months later, hey where are the logs/backups/etc. that are supposed to exist? Oh it looks like your thing blew them up and nobody noticed. It's terrifying because you're making changes to something you don't really understand, that is too hard to understand, that you don't have enough time to understand. The industry trend is towards reducing this terror by having machine verification show that your changes don't disagree too much with the thing you don't understand. What APL offers is a radical alternative: actually be able to understand the thing. KEI: it's easier to reason about mathematical relationships when expressed with mathematical notation--because the notation itself aids understanding. Programming can have good notation too. Arthur Whitney: it's easier to find bugs in 4 lines of code than in 200 lines of code.

>>16603 Well what about something like ioccc.org?

>>16604 >KEI: it's easier to reason about mathematical relationships when expressed with mathematical notation--because the notation itself aids understanding. Programming can have good notation too. APLs aren't normal languages without all the formatting or whitespace.

>>16595 >uses * as a concatenation character A programming language after the devil's tongue himself >Director of diversity in Cali Makes sense >>16595 >take programming too seriously, focusing on serious matters like correctness, safety >safety & correctness is "programming too seriously" Please write this in CAPS at the top of ANY code you write: "THIS IS MALWARE". I would really appreciate reading this light hearted totally not serious joke, and I'm sure others would too.

>>16606 Furthermore... >>16603 >Problem: people focus on correctness, safety, compliance too much in programming It is not a "Problem", you thinking this is a "Problem" is ''the real'' problem. If one assumes you messed up the OP and actually meant: Programmers are spending significant resources (mainly time) on coding correctness, safety, and compliance - what are the ways we can achieve the same or better code while being more efficient with resources? Then the answer is simple: Write the program, new feature, etc on paper first. After it is complete move to the computer and type it in. The only mistakes / bugs you make should be typos. (Bugs exist because people make excuses why they 'can't' do this).

>>16607 >you thinking this you're advocating writing programs on paper before typing them in, which does nothing at all to help anyone but the freshest programmer getting 'hello world' right, and here you are responding to my post before reading it all the way to the end. Or even line #2. An attitude of thoroughness is scarce everywhere.

>>16608 >which does nothing at all to help anyone but the freshest programmer >>16607 >Bugs exist because people make excuses why they 'can't' do this Excuses, excuses.

>>16595 >No doubt these are all important concepts in many contexts contexts, but I think there is room for a casual carefree approach to programming that prioritizes making cute things to have fun. >I've never heard of Scratch.

>>16606 >uses * as a concatenation character Well played js, 10/10 would concatnate again.

You can find this on any activity really, saying fun is not encouraged for programming is just plain wrong, plenty of stuff done for fun and for the sake of users having fun. The hardcore hobbyists are what take the thing to the next level though, so they are very valuable too.

Ehhh, code has to be functional, scalable, and maintainable. End of story. You can achieve that with or without stuffiness. Depends on your esthetic sensibilities. I've written production code that is "not stuffy" because I comment it in a way that will make it light to read without sounding like a dumbass. If by 'carefree' you mean writing code like you're never going to have to look at it again then... that's not good. Nobody likes that. You're just writing bad code and then claiming "it's my style!!!" >>16607 How would writing something on paper first make it less buggy in a world where we have IDEs who can do automatic code smell detection, unit testing and code reviews? Most programmers don't write complicated algorithmic logic. Moreover, what is this about spending so much time on coding correctness and compliance when these are things that are built into release pipelines, if not in the environments themselves? i.e. unit testing/integration testing, stuff like scala style which won't let you compile your code if it doesn't adhere to a pre-defined coding style, CI/CD pipelines that do automatic code analysis.etc/

>>16603 > Arthur Whitney: it's easier to find bugs in 4 lines of code than in 200 lines of code. Part of focusing on compliance is making sure that programmers adhere to code standards, an example of which is what Whitney said.

>>16617 >How would writing something on paper first make it less buggy in a world where we have IDEs who can do automatic code smell detection, unit testing and code reviews? >How would making sure the program is correct first make my code less buggy if my IDE has a spell checker & can think for me? Oh well. >Most programmers don't write complicated algorithmic logic IF "Most programmers don't write complicated algorithmic logic" = TRUE AND IF "Most programmers create some bugs in software" = TRUE THEN "Most programmers not writing complicated code create some bugs" = TRUE = Most programmers are dumb/lazy soykafs who don't use the paper* method. *Also known as "planning ahead".

>>16620 I wrote code on paper, back when people still used paper. It's an amusing exercise. It's not anything more than that.

>>16620 >How would making sure the program is correct first make my code less buggy if my IDE has a spell checker & can think for me? I wrote code on paper too my friend, it doesn't make code less or more buggy. If you really think the IDE 'thinks for you' I really doubt you've worked professionally as a programmer. It doesn't. An IDE is not a glorified spellchecker in 2020. Nobody uses an IDE because it can "spell check" - (in reality it can help with browsing a package's methods and classes, for example). It can apply code style, compile rules, etc. Bugs can also be caused by improper understanding of the way a piece of software works. If you really think that good, bug-less software depends on the quality of programmers, again I doubt you've had experience in the industry. It depends more on having good software management. Example: I've worked with good programmers who had to introduce changes to a 2 GB python module that had 0 documentation. Unit tests can get rid of most code issues in your isolated code but no amount of writing on paper will get rid of integration related bugs because you're working in a terrible project that has had 0 documentation available.

>>16623 >I wrote code on paper too my friend, it doesn't make code less or more buggy. >Planning ahead and fixing problems before they occur doesn't make code less or more buggy. If this was my result I would ask myself why I was not doing it correctly. >>16623 >I've worked with good programmers who had to introduce changes to a 2 GB python module that had 0 documentation. >Bugs can also be caused by improper understanding of the way a piece of software works. >Bugs can also be caused by previous programmers not doing things right. > If you really think that good, bug-less software depends on the quality of programmers, again I doubt you've had experience in the industry. >I've worked with good programmers who had to introduce changes to a 2 GB python module that had 0 documentation. >Cites example that "depends on the quality of programmers" >I doubt you've had experience in the industry FWIW, stuff I wrote is sitting around on other planetary bodies, bug free. Good luck pal!

>>16632 Writing code on paper is neither a necessary nor a sufficient condition for "planning ahead and fixing problems before they occur". If you want planning ahead and fixing problems before they occur, you should just advocate that. You can't trick people into doing it. They need to do it. Writing code on paper also will not even help them do it.

>>16606 >>Director of diversity in Cali >Makes sense From https://docs.julialang.org/en/v1/manual/strings/: >While * may seem like a surprising choice to users of languages that provide + for string concatenation, this use of * has precedent in mathematics, particularly in abstract algebra. >In mathematics, + usually denotes a commutative operation, where the order of the operands does not matter. An example of this is matrix addition, where A + B == B + A for any matrices A and B that have the same shape. In contrast, * typically denotes a noncommutative operation, where the order of the operands does matter. An example of this is matrix multiplication, where in general A * B != B * A. As with matrix multiplication, string concatenation is noncommutative: greet * whom != whom * greet. As such, * is a more natural choice for an infix string concatenation operator, consistent with common mathematical use. Thanks for your input tho.

>>16595 if you want to have fun learn ruby/python. >programming industry and/or hobby community take programming too seriously that's the type of activity that pedantic people tend to like more. what's probably more important is ux.

>>16595 Imagine creating a software that someone will use to pass an exam and fail because the software bugged on him. Therefore that would change his results and create an alternate different path from his expectations .... What is critical depends not only from universal definitions but sometimes from personal views. Software must at least be neutral in that prospect.

In the university my obsession with correctness started. Probably because of the formal logic course and others. Writing a program which correctness was not proved using mathematical basis gives me anxiety. I'm scared to use algorithms or code not from the applied field books, even if it has been tested. Working in the industry gives me a headache and I feel I could quit anytime... Yeah, by the way, OP is totally wrong.

OP, I think you are conflating the purpose of programming with technique. Technique should be flawless whenever possible — especially when it involves things like airplanes. Purpose can be like...anything? You can certainly have fun with libraries like Processing or openFrameworks. Those audio-visual utilities are what pushed me to keep on programming in the first place. I'm a enterprise Java developer today solely because I had fun drawing stuff with Processing during college. Follow zach lieberman or inconvergent on twitter if you wanna see people using programming as part of an artistic process (or listen to Autechre).

>>16639 >is a more natural choice....consistent with common mathematical use. So a PROGRAMMING language uses * instead of + for string concatenation because "common mathematical use" != "common programming use" which makes it a "natural choice" for PROGRAMMING? OK. >>16639 >Choosing an alternative concatenation to other _programming_ languages that _programmers_ code in which makes it a completely "natural choice" for _programming_. Thanks for the laughs tho.

>>16671 you're basically the person who the OP is complaining about.

>Sometimes I feel that the programming industry and/or hobby community take programming too seriously, focusing on serious matters like correctness, safety, compliance literally who does this? anyone who thinks they are doing this is bikeshedding on pointless soykaf like improving the password hashing algo. meanwhile, the rest of their code is indeed not correct, not safe, and not compliant

>>16617 >Ehhh, code has to be functional, scalable, and maintainable. End of story. Why does code have to be maintainable? A ton of software is written once and is then considered completed. How many C64 games do you think are maintained?

>>16747 if you do it right the first time, sure. Almost nothing is made right the first time, even by master programmers.

>>16756 Why should their be an obligation that programmers either produce perfect work or else support their software? Why shouldn't there be room for people who are just goofing off in their garage? Do we scold people who buy a table saw and haphazardly make soykafty furniture for fun? Of course not. Why should programming be any different?

>>16761 There's a difference between stuff I write for myself personally, and the stuff I expect other people to see. In either case the first draft is always hot garbage, and inevitably my code has to support additional features I need but didnt plan for, error checking. This can happen even in well defined systems like math programs. I eschew best practices all the time, but I never show it to anybody because they would not understand any of it. I think you're unlikely to see people encouraging such on lainchan because this is. a group setting , so for collaboration to happen code presented to this grouo should at least be clean enough for random passers-by to understand.

>>16663 How long have you been working with this unmet desiee for mathematical correctness?

>>16761 there is. But there's a huge difference between messing around on your own and releasing things for other people to run. Shoddy code has real world consequences.

>>16772 Yeah, even if its just some silly middleware, some day 20 years from now, some guy like me will be looking at your code, yelling at you through the screen because you made the only library that implements some functionality and it is like kicking dead whales down the beach. Like the time lisp couldnt load all my dependencies because the authors used #\Nul instead of #\Null and I had to write another program to go through all my installed libraries and fix that typo.

>>16772 >Shoddy code has real world consequences. Agreed. Even if all one is doing is some Access form with a little VBA, one should still take the time to get things right - if only to avoid calls/texts from co-workers when on vacation complaining that something isn't working, ruining your time off.

>>16595 I think programming is like Jazz. You can have a lot of fun playing jazz but a lot of the fun comes from mastering your instrument and understanding why things sound good and doing it fast enough to do improv. There is a charm to things being soykafty on the front but beautiful on the inside, but if it's all soykaf then it's just soykaf, you know? The fun of engineering to me is making something that works correctly and is technically correct as well. Banging rocks together in hopes of making a fire isnt interesting but understanding what rocks to use is.

>>17571 This is the most accurate bit about programming in the whole thread. 100%. I write good code because I know the moves, and I have a general idea of what I want. I have the emotions that I want to convey, the moves I want to instill, the concepts I want to encode. I have a solid background in theoretical and practical computer science that facilitate this. Without that background, I would flounder.

>>17571 Why does programming have to be like jazz? Why can't programming also be like a child smashing up a drumset for fun?

>>18700 Sure, let the child segfault over and over again.

I would argue that since bugs exist at all, that nobody really cares that much.

>>18705 What's wrong with that? What's wrong with a child or hobbyist writing broken code?

>>16595 Every office you visit nowadays looks like kindergarten.

>>18709 American tech corporations infantile developers fresh out of college to encourage them to retain their unhealthy college work/life balances. E.g. working on the weekends, working late into the evening, etc.

>>18708 Because then the broken code might somehow become popular. Then you get lots of people build upon that code and end up with garbage like OpenSSL. You can play with code as much as you like in private. However when code or binaries are released the developer should take the necessary steps to ensure that their program is of the highest possible quality. Ideally people would be knowledgable or interested enough to filter subpar code, but experience has shown this to not be the case.

>>18720 >Because then the broken code might somehow become popular. Who said anything about distributing the code?

>>18721 The OP is talking about "the programming industry", "the hobby -communuty-", etc. All those imply that others will use your code in some way, so in a sense the code will be shared and distributed to others. In short distributing the code is a huge part of the thread. If the code is not to be used by others in any form: distributing it, releasing a binary, a web service or whatever then there is no value in talking about its quality (except maybe from judging the author) and care about correctness, safety etc.

>>18744 I am the op. I think that the programming industry imposes on the hobby community by encouraging the mindset that code should always be written to industrial standards. This includes, but is not limited to, the notion that the only reason to write code is so that other people can use it.

>>16595 I guess it depends on your own standards and philosophy rather than what the industry expects of you. I work as a software engineer for a small dev company and we always try to be as clean and tidy as possible, because we know that other people from the same company will by dealing with that code in order to maintain it or port it somewhere else, and we don't want to give a hard time for ourselves, so yeah. But when I'm working on my own personal hacky projects the code is either all over the place or as finely tuned as necessary. So I'm guessing that context is more important than anything in this case. Also of course corporate talk will try to have you up to industry standards at all time, they want an army of robots writing clean code so they don't waste time and resources dealing with your bullshit and this industry was built on the backs of hobbists.

>>18746 I am asking you to consider that there might be reasons to program other than to generate revenue for shareholders. Consider for instance grandma passing the time by playing around with python instead of doing crossword puzzles.

>>16595 >What are some good ways to banish stuffiness from your project? Break guidelines for fun while no one is watching

>School For Poetic Computation https://sfpc.io/

>>18745 i like this thread. don't have my thoughts together enough to say anything intelligent (hence the sage) but i think you're on to an interesting idea OP.

>>16598 i don't think anyone's suggesting you put non-serious stuff in with your serious stuff. if i'm understanding OP's point correctly it's that the non-serious stuff doesn't get enough attention on its own terms. idk if i fully accept that premise, since i can think of a few areas where more whimsical programming is still very much appreciated, but i do think there's some truth to it. >>16595 OP, the spirit you're after is seemingly alive in >video game modding (particularly homebrew and hacking) >demoscene >amateur machine learning experimentation >zero budget itch.io porn games and probably a lot more places i'm not thinking of.

>>18813 also >gratuitous arduino home automation >most things people do with 3d printers >most things people do with webgl and/or CSS3 animations

>>18814 >datamoshing scripts >abusing your social media api key

>>16599 I do it less and less every year but when I really enjoyed programming I'd find things and just fuarrrk with things. Make up nonsensical algorithms and then have them put pixels on the screen according to some properties. Or just do off the wall soykaf like set the video mode to a bunch of random numbers and draw random soykaf. No kidding I did it once and the video card had a few weird glitches forever after. I honestly don't get too much pleasure out of what I do for work and the sort of programming and computing I do enjoy seems to have no value and not that many people seem to be into it.

Creative coding

Take your normal person soykaf out of programming. If you're not having fun coding what are you even doing it for? Want something fresh? Make a game, a 64k demo, play with crypto, whatever. Software development has become full of normal people that buy into the fancy instagram dev meme. Sure not everything needs to have a full-fledded dev lifecycle or 100% coverage testing but I feel new devs get up and running all too easily thanks to everything relying on frameworks.