|
Master_Odin posted:At least you can also put newlines in that allow easier reading in a text editor but when parsed form a continuous line. Yeah, with how important github (and thus markdown) is for open source, you'd think pypi would hurry up and up their markdown game.
|
#
?
Sep 13, 2017 20:42
|
|
|
|
| # ? Jun 5, 2024 13:28 |
|
|
Master_Odin posted:At least you can also put newlines in that allow easier reading in a text editor but when parsed form a continuous line. It's funnier if you make a single long incomprehensible string that compiles to something pretty Personally I write READMEs using ASCII art
|
|
#
?
Sep 13, 2017 21:43
|
|
|
QuarkJets posted:It's funnier if you make a single long incomprehensible string that compiles to something pretty pre: _________________________________________________________________________
\______ \_ _____/\______ \_ _____/\_ _____/\_ ___ \__ ___/
| ___/| __)_ | _/| __) | __)_ / \ \/ | |
| | | \ | | \| \ | \\ \____| |
|____| /_______ / |____|_ /\___ / /_______ / \______ /|____|
\/ \/ \/ \/ \/
.___ ___________ __ __ ._.
| | ____ \_ _____/__ __ ___________ ___.__. / \ / \_____ ___.__.| |
| |/ \ | __)_\ \/ // __ \_ __ < | | \ \/\/ /\__ \< | || |
| | | \ | \\ /\ ___/| | \/\___ | \ / / __ \\___ | \|
|___|___| / /_______ / \_/ \___ >__| / ____| \__/\ / (____ / ____| __
\/ \/ \/ \/ \/ \/\/ \/
|
|
#
?
Sep 14, 2017 06:04
|
|
|
I can't tell if y'all are joking or not, but I've used bigass ascii art comments before to make sections easy to find in code previews/Atom's minimap. It works great and looks 1337 as hell.
|
|
#
?
Sep 14, 2017 16:27
|
|
|
Tetris in Game of Life posted:The underlying idea of this project is abstraction. Rather than develop a Tetris game in Life directly, we slowly ratcheted up the abstraction in a series of steps. [..] First, we used OTCA metapixels as the foundation of our computer. [..] The next step was to construct a variety of fundamental logic gates to serve as the basis for the computer. [..] From here we developed an architecture for our processor. [..] From here it is just a matter of implementing Tetris on the computer. To help accomplish this, we have worked on multiple methods of compiling higher-level language to QFTASM. We have a basic language called Cogol, a second, more advanced language under development, and finally we have an under-construction GCC backend. The current Tetris program was written in / compiled from Cogol. I have absolutely no words. E: Just have a look at this, where every pixel is a bit over 2048x2048 Game of Life pixels: 
Loezi fucked around with this message at 17:03 on Sep 14, 2017 |
|
#
?
Sep 14, 2017 16:59
|
|
|
quote:That means the final product will have a bounding box of 2,940,928 x 10,407,936 (plus a few thousand extra for the borders of the metapixels), with a population between 29,228,828,720 and 79,048,585,231. With 1 bit per live cell, that's between 27 and 74 GiB needed to represent the entire computer and ROM...I included those calculations here because I neglected to run them before starting the script, and very quickly ran out of memory on my computer.
|
|
#
?
Sep 14, 2017 17:45
|
|
|
Fuckin' lmao
|
|
#
?
Sep 14, 2017 18:27
|
|
|
Just because you can, doesn't mean you should 
|
|
#
?
Sep 14, 2017 18:28
|
|
|
Love it!
|
|
#
?
Sep 14, 2017 18:33
|
|
|
Pretty amazing. Honestly though Wireworld is way better for imaginary computers
|
|
#
?
Sep 14, 2017 18:38
|
|
|
Jesus Christ that's insane. I don't know why you would ever dedicate so much time to a project like this, but I can't say it's not impressive.
|
|
#
?
Sep 14, 2017 19:41
|
|
|
So I asked for code review, and the next day the guy comes back with a bespoke Python script to render the dependency graph of my stuff because apparently it's impossible to tell wtf my code is doing. 
|
|
#
?
Sep 15, 2017 00:04
|
|
|
Did you get too crazy with inheritance, or try to do functional programming?
|
|
#
?
Sep 15, 2017 00:49
|
|
|
Corla Plankun posted:Did you get too crazy with inheritance, or try to do functional programming? I've learned that functional programming is a great way to write something that makes people incredibly goddamn lost when they try and read it.
|
|
#
?
Sep 15, 2017 00:52
|
|
|
I feel like it is especially hard to read in python because you can pass functions around but the type system isn't expressive enough to help with the cognitive load.
|
|
#
?
Sep 15, 2017 00:53
|
|
|
Pollyanna posted:I've learned that functional programming is a great way to write something that makes people incredibly goddamn lost when they try and read it. I'm sure I've asked this before, but are there any functional languages that aren't syntactical clusterfucks? gently caress "elegance," I want something readable and learnable by outsiders.
|
|
#
?
Sep 15, 2017 01:04
|
|
|
McGlockenshire posted:I'm sure I've asked this before, but are there any functional languages that aren't syntactical clusterfucks? gently caress "elegance," I want something readable and learnable by outsiders. I believe that one you truly understand the nature and utility of monads, you'll see that pure functional languages are the most readable of any programming language.
|
|
#
?
Sep 15, 2017 01:16
|
|
McGlockenshire posted:I'm sure I've asked this before, but are there any functional languages that aren't syntactical clusterfucks? gently caress "elegance," I want something readable and learnable by outsiders. Python code:
|
|
|
#
?
Sep 15, 2017 01:23
|
|
|
McGlockenshire posted:I'm sure I've asked this before, but are there any functional languages that aren't syntactical clusterfucks? gently caress "elegance," I want something readable and learnable by outsiders. That's one of the design goals of Elm. It has no first-class monads or type-classes yet, I think in part because the lead thinks people find them confusing and distracting. I think it's successful in that respect.
|
|
#
?
Sep 15, 2017 01:37
|
|
|
functional programming owns bones but you have to have a good type system to keep you within the lines. using it with a duck typed language like python is just asking for pain. if you want to try functional programming in an imperative systems language try rust. it's nice and the compiler optimizations will surprise you with how good they are.
|
|
#
?
Sep 15, 2017 01:50
|
|
|
The thing about F# that I have trouble wrapping my head around is the immutability of objects. I grew up on assembly, BASIC and Algol-derived languages, and my brain just doesn't think like that. As an aside, in one class in school we had to find a solution to the "8 queens" problem using Lisp. Due to my inability to figure out how to end the recursion, my program printed out all the solutions. Still got credit though
|
|
#
?
Sep 15, 2017 02:05
|
|
|
LongSack posted:The thing about F# that I have trouble wrapping my head around is the immutability of objects. I grew up on assembly, BASIC and Algol-derived languages, and my brain just doesn't think like that. F# has a mix of mutable and immutable stuff, and you can explicitly make some of the latter immutable (usually a bad sign though), so it depends on your approach really. But yeah, functionally you gotta get used to the idea of passing data into things and using the result that comes out. It completely changes how you approach problems, just because trying to do things the usual way ends up really awkward Honestly the biggest problem with F# for me was the freedom to do things functionally or in an OO style, I feel like if I'd been railroaded into a purely functional way of doing things it would be easier to grasp. I mean 😵, and this is when you know exactly what you need to do
|
|
#
?
Sep 15, 2017 03:28
|
|
|
McGlockenshire posted:I'm sure I've asked this before, but are there any functional languages that aren't syntactical clusterfucks? gently caress "elegance," I want something readable and learnable by outsiders. I'd argue that LISPs have very nice syntax. Sure there are a lot of parentheses, but the syntactical simplicity makes it very easy to tell what is going on.
|
|
#
?
Sep 15, 2017 03:56
|
|
|
baka kaba posted:It completely changes how you approach problems I have yet to come across a problem that required functional programming. Quite probably, this is because of the types of problems that I need to solve.
|
|
#
?
Sep 15, 2017 04:00
|
|
|
LongSack posted:I have yet to come across a problem that required functional programming. Quite probably, this is because of the types of problems that I need to solve. Or the way you're going about solving them. (Not that that's a problem!)
|
|
#
?
Sep 15, 2017 04:18
|
|
|
Oh I mean if you do it in a purely functional way, you tend to approach the problem differently, just because the kind of stuff you're going to be bolting together works in a different way Like I said though, F# offers enough OO-style stuff (especially with all the .NET library stuff that doesn't have a functional wrapper) that you can happily do things that way and basically have some pure functions that you use like static methods. You're not really forced into a functional approach
|
|
#
?
Sep 15, 2017 04:23
|
|
|
LongSack posted:I have yet to come across a problem that required functional programming. Quite probably, this is because of the types of problems that I need to solve. I doubt there's many problems that require functional programming, but I've personally found functional programming (F# specifically) to lead to cleaner architecture, code that is concise and easy to test and far less worry about runtime errors and exceptions.
|
|
#
?
Sep 15, 2017 04:50
|
|
|
Functional programming is a style that is achieved by being explicit about the inputs and the outputs of the components of your code. In addition to arguments and return values of functions, state (including the state of the machine) is an input and side effects (including mutation of state) are outputs. Pure functional languages like Haskell represent all inputs and outputs as arguments and return values, including using things like the State and IO monads to encapsulate statefulness and side effects. Some variants of extremely imperative languages like BASIC don't even give you facilities other than mutating global state. Which makes sense, as under the hood that's what the machine is doing. More moderate languages, including any OO language worth its salt, can be used in either a functional or an imperative style. If your goal is to describe what the machine is doing, then use an imperative style to represent it. But you should err on the side of preferring a functional style, so that the dependencies of each component are explicit. That makes it easier to understand. As a helpful side effect, it also makes it easier to decompose the program, which is useful when e.g. writing unit tests.
|
|
#
?
Sep 15, 2017 04:50
|
|
|
VikingofRock posted:I'd argue that LISPs have very nice syntax. Sure there are a lot of parentheses, but the syntactical simplicity makes it very easy to tell what is going on. Well, we don't know for LISPs specifically, but we have some proper data on how easy languages are to learn. Turns out learning C or Java is as hard as learning a language with literally random keywords. But given that unbalanced parentheses, curly brackets, square brackets and quotation marks, or using these different symbols interchangeably are literally the most common mistake for novices, increasing their amount might not be the key to victory. Don't know enough about LISPs to say how the results of this study match the LISP-like languages' design, maybe someone else can comment on that.
|
|
#
?
Sep 15, 2017 05:32
|
|
|
Loezi posted:Well, we don't know for LISPs specifically, but we have some proper data on how easy languages are to learn. Turns out learning C or Java is as hard as learning a language with literally random keywords. But given that unbalanced parentheses, curly brackets, square brackets and quotation marks, or using these different symbols interchangeably are literally the most common mistake for novices, increasing their amount might not be the key to victory. LISP uses a single kind of parenthesis, and any decent editor will show the matching open parenthesis when you type (or move over) a closing one. The whole "too many parentheses" complaint is just whining. People having religious wars over whether semicolons should be optional could never happen in LISP.
|
|
#
?
Sep 15, 2017 08:11
|
|
|
Zopotantor posted:LISP uses a single kind of parenthesis, and any decent editor will show the matching open parenthesis when you type (or move over) a closing one. The whole "too many parentheses" complaint is just whining. Even if we assume 50-50 split between "unbalanced things" and "mismatched things", unbalanced parentheses (or equivalent characters) would be the top cause of errors in that study. And based on my experience (yeah yeah, plural of anecdote is not data), I'd assume apriori that unbalancing is more common than mismatching. It's a shame that they don't distinguish between those two error types, but that's what we gotta run with. We have proper evidence to support very few of the things we believe about programming performance and the effects of the programming language on it. Based on the little data we have available, novice programmers loving up parenthesis is an extremely common source for errors. Sure, you can hand wave the problem away by saying "The IDE will take care of it", but to me that sounds like something that could be said on nearly every criticism of any programming language. Consider for example Go, generics and the response "Sure, we don't have generics. But your IDE can just have a code generation tool". In my view, the little data and evidence we have is something that absolutely should be considered in language design. If people consistently gently caress something up, maybe that is not the optimal way to go on about the things. And that applies to every language out there. Disclaimer: I've never used LISP, so I don't really have any strong opinions on it. Edit: Here is another study that supports the first one. If you sum up all the subtypes of errors caused by missing parentheses and extra tokens (that is, an unnecessary parenthesis), they are together the second most common error category, right behind "cannot resolve identifier". Loezi fucked around with this message at 09:06 on Sep 15, 2017 |
|
#
?
Sep 15, 2017 08:55
|
|
|
I mean, gently caress, after years of professional code bashing I still write unbalanced parentheses and brackets once stuff gets nested enough and I stop paying attention for a moment.
|
|
#
?
Sep 15, 2017 11:15
|
|
|
Those types of studies can be interesting but there's so little data in the matter that it's very difficult to deduce much beyond the simple statement that novice programmers make mistakes, for some definition of "novice programmer". If advanced programmers make the exact same mistakes, we'd have to ask if those are isolated to a particular programming paradigm or if those mistakes survive despite a wider range of experience. Attempts to study error rates in varies programming languages reveal some of the systemic issues, but most focus on public repositories, due to the large sample size available, and those are often filled with novice code. We have examples of interfacing designed with natural language concerns in mind, but people apparently lean more toward enforced structure, or the appearance of it, even if it has no bearing on language functionality. It is interesting that, in the world of programming, most are happy to be shoved quite deeply into arbitrary strictures. If we told them they had to brush their teeth, they'd whine, but tell them to ride the spacebar like they're a 1985 WordPro user and they'll do it. Perhaps the reality is that novice programmers should be seen as novice programmers, and those with proven experience should be considered senior programmers. Perhaps novice programmers should not be touching applications that require high performance, security, or are otherwise important. Maybe not everyone can be a good programmer, coder, or developer.
|
|
#
?
Sep 15, 2017 16:04
|
|
|
Newsflash: experienced programmers make mistakes all the goddamn time, and the only reason you don't hear about it is because one of the main skills separating experienced programmers from novices is that experienced programmers are usually able to figure out what they did wrong on their own. I don't have any data to back this up, but my intuition is that the mistakes that experienced programmers make pretty closely parallel the mistakes that novice programmers make, too. Sure, experienced programmers are more likely to get race conditions or other obscure bugs, and less likely to get the super-basic poo poo like missing semicolons, but that doesn't mean that they 100% of the time remember to put a semicolon in the right place. Maybe we should be designing programs so that it's hard to make subtle typos that render the program invalid.
|
|
#
?
Sep 15, 2017 16:18
|
|
|
I think it might be good to split mistakes into syntactic and semantic mistakes. Experienced programmers make less syntactic mistakes and resolve them without too much fuss, but it seems like novice to experienced programmers will continue to make the same semantic mistakes until the end of time. Memory leaks and poorly vetted asynchronous code pervade every code base despite the hundreds of years of brainpower poured into them by experts. It's hard to pin this on a particular programming style or language, really. It just turns out that writing code that is both fast and safe on many different architectures is really hard and as the reality changes (Moore's law observation looking dead) all of the assumptions your language makes on a given architecture slowly become wrong. The only difference between a novice and experienced programmer in this aspect is the ability to use tooling to verify the assumptions made in their program. Novices struggle with running memory and cpu profiles which makes it difficult to understand the impact of a change on a performance benchmark and, as a result, they could make mistakes when fixing things in a high performance library. But that's what code review is for. Novices very much should work on complicated codebases; it is the experts responsibility to make this balance possible.
|
|
#
?
Sep 15, 2017 16:54
|
|
|
Personally, I gently caress up semicolons all the drat time. If someone designed a language that didn't yell when I did that, and instead just silently made the code do something that wasn't at all what I intended it to do, that would be a really lovely language. Structure in a programming language is really good. It disambiguates the programmer's intention. If you wrote all the structure to do a thing, that is probably the thing you intended to do - whereas if you missed part of the structure, so it's not obvious, that's an error, the programmer needs to fix the structure (one way or the other), and in doing so clarify their intent.
|
|
#
?
Sep 15, 2017 16:57
|
|
|
The difference between a novice and an expert is the cumulative number of mistakes made.
|
|
#
?
Sep 15, 2017 17:36
|
|
|
Bongo Bill posted:The difference between a novice and an expert is the cumulative number of mistakes made. Ten thousand mistakes! Or to put it another way, it is entirely possible to make a ton of mistakes and still not be an expert at anything other than loving up.
|
|
#
?
Sep 15, 2017 17:47
|
|
|
baka kaba posted:But yeah, functionally you gotta get used to the idea of passing data into things and using the result that comes out. It completely changes how you approach problems, just because trying to do things the usual way ends up really awkward Honestly that's the thing that bugs me the most about a bunch of languages. I first learned coding on perl 5 twenty years ago and processing data by passing it through a bunch of map operations and doing tricks like the Schwartzian transform became second nature. Doing the same operations in other languages often feels clunky. Python's list comprehension syntax is an example of doing it right, but it's also infuriating in that they hide such a good thing behind an undiscoverable name.
|
|
#
?
Sep 15, 2017 17:47
|
|
|
|
| # ? Jun 5, 2024 13:28 |
|
|
TooMuchAbstraction posted:Ten thousand mistakes! I do not fear the programmer who has made ten thousand mistakes; I fear the programmer who has made one mistake ten thousand times.
|
|
#
?
Sep 15, 2017 18:08
|
|