|
i picked up beautiful code and forgot why and thought i must have boought it in a rare lapse of bsd programming judgement but now im excited to read it
|
#
?
Mar 21, 2016 01:02
|
|
|
|
| # ? May 11, 2024 06:18 |
|
|
(in that series, i enjoyed 'masterminds of programming' more. programmers are bad at docs and uh it shows in 'beautiful code' my fav chapter is the kernighan and pike chapter and it's an excerpt from practice of programming)
|
|
#
?
Mar 21, 2016 01:07
|
|
|
I like documentation a whole lot and I feel it is systemically undervalued as part of development. You know culture around it is bad when some people have been broken to the point they don't trust any docs at all because of so bad/outdated some of it has become. I try to apologize every time someone has to go dig into the source.
|
|
#
?
Mar 21, 2016 01:44
|
|
|
or digging through the tests b/c they're easier to read than the source w
|
|
#
?
Mar 21, 2016 01:48
|
|
|
I want to write my own linter slash static analyzer slash maybe custom macro expander tool (it's kind of open ended) is antlr the right place to start
|
|
#
?
Mar 21, 2016 01:49
|
|
|
Bloody posted:I want to write my own linter slash static analyzer slash maybe custom macro expander tool (it's kind of open ended) is antlr the right place to start yeah i think so. antlr is really good, but be prepared to spend $30 or type filetype:pdf into google, as you'll need the book to get anything at all done with it.
|
|
#
?
Mar 21, 2016 02:03
|
|
|
alternately: is this a reasonable thing to do in haskell and if so is it possible to reuse these antlr grammars i found i dont want to write my own grammar
|
|
#
?
Mar 21, 2016 02:15
|
|
|
tef posted:christ ???
|
|
#
?
Mar 21, 2016 02:20
|
|
|
it is weirding me out that people found it that useful because i swear i've written the same thing over and over again
|
|
#
?
Mar 21, 2016 03:41
|
|
|
tef posted:it is weirding me out that people found it that useful because i swear i've written the same thing over and over again we have a 10xer who buries everything under a million layers of abstraction which makes maintaining his stuff a herculean effort it's nice to get some buy in from other team members to actively reduce the complexity of our code
|
|
#
?
Mar 21, 2016 03:50
|
|
|
Bloody posted:alternately: is this a reasonable thing to do in haskell and if so is it possible to reuse these antlr grammars i found i dont want to write my own grammar This is definitely a reasonable thing to do in Haskell, and is IMO one of the places where the language really shines. You can either use alex + happy to automatically generate a lexer + parser (similar to using lex and yacc in C), or you can roll your own fairly easily. I've personally never used alex and happy, but there are tutorials on the above-linked sites and there are lots of examples of their use out there. For example here is a chapter on using alex + happy to write a compiler for a toy functional language, and here is an example of someone writing a Python 3 interpreter using them. If you want to roll your own parser, I would recommend using either MegaParsec or Earley. The former is an actively-maintained fork of a pretty well-known parsing library called Parsec, and the latter neatly handles things like left-recursive grammars while allowing you to write directly in Haskell (instead of needing a separate tool like alex and happy). You also might want to look at trifecta, which is known for allowing you to write very cool and pretty error messages. VikingofRock fucked around with this message at 05:54 on Mar 21, 2016 |
|
#
?
Mar 21, 2016 05:52
|
|
|
parsec is pretty cool + good
|
|
#
?
Mar 21, 2016 07:13
|
|
|
MononcQc posted:I like documentation a whole lot and I feel it is systemically undervalued as part of development. You know culture around it is bad when some people have been broken to the point they don't trust any docs at all because of so bad/outdated some of it has become. documentation is never specific enough for me. Qt documentation on QObjects and the signal/slot system for example is pretty wishy-washy, especially regarding cross-thread signals and the inevitable setup/teardown mess. reading the sources spared me a lot of experimentation, which I'm never super comfortable about because I tend to work on environments that lack a REPL or even a simulator that works
|
|
#
?
Mar 21, 2016 10:52
|
|
|
VikingofRock posted:This is definitely a reasonable thing to do in Haskell, and is IMO one of the places where the language really shines. You can either use alex + happy to automatically generate a lexer + parser (similar to using lex and yacc in C), or you can roll your own fairly easily. I've personally never used alex and happy, but there are tutorials on the above-linked sites and there are lots of examples of their use out there. For example here is a chapter on using alex + happy to write a compiler for a toy functional language, and here is an example of someone writing a Python 3 interpreter using them. If you want to roll your own parser, I would recommend using either MegaParsec or Earley. The former is an actively-maintained fork of a pretty well-known parsing library called Parsec, and the latter neatly handles things like left-recursive grammars while allowing you to write directly in Haskell (instead of needing a separate tool like alex and happy). You also might want to look at trifecta, which is known for allowing you to write very cool and pretty error messages. awesome, tyvm
|
|
#
?
Mar 21, 2016 11:45
|
|
|
Wheany posted:has there been any studies if people like "whoops, something went wrong, lol" -type errors more than "database error, error code 0xdeadbeef, please contact your system administrator" -type errors? I read one once that said if you provide a error code or specific message that users won't read it or c/p it anyway not sure how scientific it was
|
|
#
?
Mar 21, 2016 12:33
|
|
|
~Coxy posted:I read one once that said if you provide a error code or specific message that users won't read it or c/p it anyway In my experience of teaching: it takes some coaching to get new students to actually read compiler/interpreter error messages
|
|
#
?
Mar 21, 2016 12:54
|
|
|
i meant more the tone of "aww, snap" type 'cute' errors compared to dry "notepad.exe has encountered an error and needs to close" type errors.
|
|
#
?
Mar 21, 2016 13:05
|
|
|
hackbunny posted:documentation is never specific enough for me. Qt documentation on QObjects and the signal/slot system for example is pretty wishy-washy, especially regarding cross-thread signals and the inevitable setup/teardown mess. reading the sources spared me a lot of experimentation, which I'm never super comfortable about because I tend to work on environments that lack a REPL or even a simulator that works Yeah. I guess this is one of the most challenging things. And even people's behaviour doesn't help. In general, the attitude is that people want short concise documentation that tells them how to get going, but they also want a comprehensive documentation that gives all the details. The result is that if you write short concise docs, you have to possibly omit elements and people dislike it, and if you write comprehensive docs, people find it too long and will skip around to code samples and only focus on that. I'm not sure what to do there ever.
|
|
#
?
Mar 21, 2016 13:13
|
|
|
is it hosed up if my build process includes building tools that run the back half of the build process like some sort of hosed up nesting doll build process
|
|
#
?
Mar 21, 2016 13:53
|
|
|
not really. i mean, if the tools change often enough that it's worthwhile to potentially rebuild them all the time, then it makes sense to me then again i hate every build system and nothing infuriates me more than trying to build a project for the first time. as far as i'm concerned adding some bullshit to a build process is just adding more to the existing pile of bullshit
|
|
#
?
Mar 21, 2016 14:04
|
|
|
MononcQc posted:Yeah. I guess this is one of the most challenging things. And even people's behaviour doesn't help. In general, the attitude is that people want short concise documentation that tells them how to get going, but they also want a comprehensive documentation that gives all the details. a helpful thing i'm sure you already do is to write a good declarative first sentence/paragraph, with the details below it you can see it in git commit guides, javadoc guides, etc. those who just care about what a thing are satisfied by your punchline, people who want to read more read more. links are great for this too but i think that part of the problem is trying to do two things at once; a tutorial is not the same thing as documentation. documentation as i'm meaning it is part of the specification of the code. it's a reference that you read as needed, where a tutorial is generally intended to be followed linearly. of course the line is blurry when you put code in the proper documentation, but even then those tend to be simple examples rather than something that forms a narrative
|
|
#
?
Mar 21, 2016 14:42
|
|
|
Bloody posted:is it hosed up if my build process includes building tools that run the back half of the build process like some sort of hosed up nesting doll build process not at all. your final output depends on the tools used to create it, there's nothing wrong with encoding that dependency in the build process instead of leaving it as an ad-hoc "oh yeah and it only compiles with this special snowflake compiler version" bit of oral tradition if you do do that, though, you're really going to want to have good caching so that you're not actually burning time and cpu cycles recompiling the tools for the 99% of builds where they haven't actually changed
|
|
#
?
Mar 21, 2016 15:14
|
|
|
cool. in this case the tool is just a wrapper to automate the fpga build process so its build time is very trivial compared to the fpga build process time it would be nice to do something about the hard dep on "this specific hosed up version of the fpga build chain" but lol at that ever happening
|
|
#
?
Mar 21, 2016 15:16
|
|
|
in a good build system the tools are defined in the pom and discovered and pulled in at build time. everything else is variations on terrible scripting.
|
|
#
?
Mar 21, 2016 15:21
|
|
|
i'll make sure to let the most user/customer-hostile vendors in the world know that their build systems are bad and should be replaced by maven, i am sure they will be responsive
|
|
#
?
Mar 21, 2016 15:25
|
|
|
user-hostile is the industry standard for build systems.
|
|
#
?
Mar 21, 2016 15:29
|
|
|
i loving hate how ruby allows optional parens gently caress you ruby, i want to know at first glance if you're a goddamn method rather than searching the entire codebase
|
|
#
?
Mar 21, 2016 16:23
|
|
|
im fuckin around with megaparsec and these tutorials are lackluster
|
|
#
?
Mar 21, 2016 16:25
|
|
|
Blinkz0rz posted:i loving hate how ruby allows optional parens lol ruby.
|
|
#
?
Mar 21, 2016 16:27
|
|
|
although theres a good chance my difficulties stem from having at best a loose grasp of this whack rear end lang
|
|
#
?
Mar 21, 2016 16:32
|
|
|
Doesn't Scala take that to a dumber step forward where you can omit the dot and parantheses all you want, so your method calls can turn in to a list of words with no punctuation
|
|
#
?
Mar 21, 2016 16:33
|
|
|
everything in scala can be implicitly used infix iirc
|
|
#
?
Mar 21, 2016 16:34
|
|
|
Shaggar posted:lol ruby. yeah the huge downside to chef
|
|
#
?
Mar 21, 2016 16:36
|
|
|
piratepilates posted:Doesn't Scala take that to a dumber step forward where you can omit the dot and parantheses all you want, so your method calls can turn in to a list of words with no punctuation scala is bad too
|
|
#
?
Mar 21, 2016 16:48
|
|
|
piratepilates posted:Doesn't Scala take that to a dumber step forward where you can omit the dot and parantheses all you want, so your method calls can turn in to a list of words with no punctuation Only for methods with one arg. So "butts.filter(isGross)" is the same as "butts filter isGross". On the other hand it's kinda useless because it's far more common to have a method inside too like "butts.filter(_.isGross)". But then the underscore syntax needs brackets anyway so the infix syntax is "butts filter (_.isGross)" which is a loving joke Ps the same applies to all lambdas which the underscore syntax is sugar for
|
|
#
?
Mar 21, 2016 16:59
|
|
|
Bloody posted:cool. in this case the tool is just a wrapper to automate the fpga build process so its build time is very trivial compared to the fpga build process time how frequently does the wrapper change? this seems like it should be solvable by pulling a known good binary at build-time if its not already present on the box, but i dont know what your build system looks like so maybe thats not an option. or i guess if it takes longer to download the binary than to compile.
|
|
#
?
Mar 21, 2016 17:38
|
|
|
reasonably frequently, at least for now. it's mostly an academic question i guess; basically everything i do is only ever seen or used by me  in haskell news, i think i know what a monoid is now. not sure what they have to do with endofunctors yet tho
|
|
#
?
Mar 21, 2016 18:09
|
|
|
Bloody posted:im fuckin around with megaparsec and these tutorials are lackluster
|
|
#
?
Mar 21, 2016 18:16
|
|
|
piratepilates posted:Doesn't Scala take that to a dumber step forward where you can omit the dot and parantheses all you want, so your method calls can turn in to a list of words with no punctuation Groovy does that I think
|
|
#
?
Mar 21, 2016 18:18
|
|
|
|
| # ? May 11, 2024 06:18 |
|
|
Bloody posted:reasonably frequently, at least for now. it's mostly an academic question i guess; basically everything i do is only ever seen or used by me functors in haskell are endofunctors. do you know what functor is yet?
|
|
#
?
Mar 21, 2016 18:24
|
|