|
i can understand the urge to dump it on somebody else, but picking an intern seems spectacularly stupid, since you know they're going to be gone soon. we've never had that particular problem anywhere i've worked what i have seen repeatedly is that interns get some small, appealing project like "try to get this new build tool working" or "make a prototype that integrates with this library", and suddenly they're making hundreds of subtle changes and generalizations in the build system for the benefit of some wacky configuration that's inevitably going to start bit-rotting the second they walk out the door
|
#
?
May 10, 2018 22:41
|
|
|
|
| # ? Jun 3, 2024 21:46 |
|
|
Soricidus posted:alternative question: if this is a common problem that totally justifies embedding a scripting language in your build, how come people argued against maven for three pages without bringing it up? because the only people willingly engaging in a build system argument are the people who aren't enlightened to the fact that they're all fucknig terrible
|
|
#
?
May 11, 2018 01:45
|
|
|
Suspicious Dish posted:have you been arguing for 3 pages about why maven is the best and yet it doesn't attempt to solve the one big hard problem that explains nearly all the complexity of other build systems? as I discussed at the outset, maven "alternatives" all threw the baby out with the bathwater. they fixed one problem, and they re-introduced all the other problems maven was meant to solve it is telling that many projects prefer running sed against a maven pom to the adoption of an imperative build system in toto
|
|
#
?
May 11, 2018 01:58
|
|
|
maven is a 90% solution to the problem of project definition and compilation. the missing 10% is the huge problem of parametric builds. gradle is a 0% solution. it is a shell script written for jvm. you could literally replace it with a makefile calling ivy for dep resolution, and your build would probably be more understandable that way.
|
|
#
?
May 11, 2018 01:59
|
|
|
Gazpacho posted:
hold my beer
|
|
#
?
May 11, 2018 02:17
|
|
|
ofc talking about maven is boring, that's the point of maven
|
|
#
?
May 11, 2018 02:19
|
|
|
bluh bluh bluh why isn't filling out a form at the dmv interesting?
|
|
#
?
May 11, 2018 02:23
|
|
|
Brain Candy posted:ofc talking about maven is boring, that's the point of maven no, the point of maven is to not have any surprises thats not the same as it being boring to talk about
|
|
#
?
May 11, 2018 02:55
|
|
|
Why the gently caress would you give an intern a project as important as maintaining a build system? Sounds like you're asking for trouble there.
|
|
#
?
May 11, 2018 02:56
|
|
|
lol if your build system is any more complex than hitting f6 in visual studio
|
|
#
?
May 11, 2018 03:24
|
|
|
Lol if you cannot build your program without visual studio
|
|
#
?
May 11, 2018 03:33
|
|
|
qhat posted:Lol if you cannot build your program without visual studio Nope, just msbuild.
|
|
#
?
May 11, 2018 03:50
|
|
|
Notorious b.s.d. posted:gradle is a 0% solution. it is a shell script written for jvm Notorious b.s.d. posted:it is telling that many projects prefer running sed against a maven pom thats pretty much the same thing at that point, except id rather write a 200 line groovy script than a 200 line bash script (edit: and a groovy script that does the same thing should be much smaller). because i can at least leverage *some* guarantees and get some standard programming features with groovy. i say that as someone that thinks groovy needs a bullet in the back of its head. is it a stretch to assume that those in favor of maven tend to work on larger, more stable codebases and the people saying gradle isnt that bad work on smaller codebases where the flexibility provides more value and the sanctity of the build process is low on the list of priorities? i cant recall build systems screwing me much in the past other than with ant and npm - but those were both at the same place, and it would have been hard to ascribe a single cause of that dumpster fire. luchadornado fucked around with this message at 03:56 on May 11, 2018 |
|
#
?
May 11, 2018 03:53
|
|
|
Helicity posted:is it a stretch to assume that those in favor of maven tend to work on larger, more stable codebases and the people saying gradle isnt that bad work on smaller codebases where the flexibility provides more value and the sanctity of the build process is low on the list of priorities? you have it completely backwards. the smaller, and more rapidly changing, the codebase, the less effort you want to put into the build system. you are writing a needlessly complicated way to solve simple problem, because.... reasons?
|
|
#
?
May 11, 2018 05:52
|
|
|
Helicity posted:thats pretty much the same thing at that point, except id rather write a 200 line groovy script than a 200 line bash script groovy is a better language than bash, to be sure but i don't want to write any lines of script to build a project. and maven will spare me that chore for 90% of use cases
|
|
#
?
May 11, 2018 05:53
|
|
|
qhat posted:Lol if you cannot build your program without visual studio why? too cheap to pay for another licence?
|
|
#
?
May 11, 2018 08:07
|
|
|
at one point we were using the ms fakes framework for our awful, awful integration tests*. at the time this was available in the top two tiers of visual studio but, crucially, not in msbuild. we 'fixed' this tiny roadblock by installing vs2012 onto our build server and calling it a day. it sat like that for a while, quietly building stuff. a few years later, ms rejigged the pricing structure for vs licenses so that ms fakes was only available in enterprise edition. we were, of course, too cheap to upgrade, but also too cheap to spend the time to rip the framework out. so there we languished for a couple of years, unable to upgrade to newer versions of c# because that would require us to upgrade vs - which we couldn't do because it would break the tests that no one really cared about eventually someone was told to go and remove our dependency on ms fakes. they did, and now we can use more modern features! hurrah! i guarantee that there's still most of a vs2012 installation hanging around on the build server, and can't wait for the day when we rebuild it (i hope the new server breaks and then breaks the will of the person sent to fix it) * ms fakes is some magic 'sub this method out at (test) runtime with another function' bullshit. the fact that we used this should tell you all you need to know about the quality of our tests and indeed our entire codebase. why did we need this magic runtime method bullshit? well, our tests used an overridden version of object.Equals that compared stuff like created/modified dates and IDs, which were set in and retrieved from the DB. we used fakes to sub out the Equals method with one that ignored those fields, as well as ignoring microsecond differences between DateTimes created in code vs DateTimes loaded from the DB
|
|
#
?
May 11, 2018 08:26
|
|
|
redleader posted:at one point we were using the ms fakes framework for our awful, awful integration tests*. at the time this was available in the top two tiers of visual studio but, crucially, not in msbuild. we 'fixed' this tiny roadblock by installing vs2012 onto our build server and calling it a day. it sat like that for a while, quietly building stuff. lol forever at windows shops and the poor bastards who work in them
|
|
#
?
May 11, 2018 08:29
|
|
|
.net is cool but i ain't gonna bet my business on it
|
|
#
?
May 11, 2018 08:29
|
|
|
redleader posted:at one point we were using the ms fakes framework for our awful, awful integration tests there is a larger set of testing patterns in which people write tests that depend on a ton of implementation details. basically whenever setting up a mock takes more than 1-2 lines you end up with tests that are very good at testing what your internal class structure looks like you've also made your code refactor-proof since every time you want to make a change all these brittle mock-heavy tests will start breaking because now method "foo" on dependency Y is only called 4 instead of 5 times
|
|
#
?
May 11, 2018 08:55
|
|
|
My workplace gets around it by making everything highly coupled and magic hidden logic in the database with db functions copied from SQL forums where the poster proudly declares, "here's my solution I believe you can never have too much dynamic SQL!" Therefore making it impossible to write meaningful integration tests in the first place.
|
|
#
?
May 11, 2018 09:08
|
|
|
Sagacity posted:ah yes, integration tests in which you still replace half of your code with lots of common OO patterns require mocking. most notably, dependency injection the crime with this poster was imagining that .net has a living ecosystem beyond what they can pay microsoft to guarantee
|
|
#
?
May 11, 2018 09:10
|
|
|
floatman posted:My workplace gets around it by making everything highly coupled and magic hidden logic in the database with db functions copied from SQL forums where the poster proudly declares, "here's my solution I believe you can never have too much dynamic SQL!" Therefore making it impossible to write meaningful integration tests in the first place. this is not necessarily the worst model ever, it's just very old-school people used to honestly believe that the database should be accessed by multiple applications, which created a need for DBAs to be the ones to manage interfaces, which in turn created some truly scary stored procedures stored procedures are code sharing between applications, right? 
|
|
#
?
May 11, 2018 09:11
|
|
|
redleader posted:why? too cheap to pay for another licence? It's called cmake and it's also called not checking effectively generated project files into version control. And don't C# me lest you out yourself as the retard who uses .NET unironically.
|
|
#
?
May 11, 2018 09:31
|
|
|
Notorious b.s.d. posted:this is not necessarily the worst model ever, it's just very old-school The old school model has DBAs, stored procedures and db functions. These, in a way, serve as abstractions that contribute to the maintainability of the application as a whole. We don't have those things for simple, basic day to day tasks like getting data. Everybody writes their own bespoke hell using the ORM. What we do have is hell poo poo I just described. It is a clown circus on fire. I would love to tell you guys more but apparently I have to fix a pull request where I need to put all closing tags on the same line as opening tags in an XML file "for consistency". An XML file, that's read by machines. I hope Johnny XMl parser appreciates the effort I've put into making this file look readable.
|
|
#
?
May 11, 2018 09:48
|
|
|
Notorious b.s.d. posted:.net is cool but i ain't gonna bet my business on it i feel that at the moment the new and cool microsoft is making it a less bad idea, but who knows how long it'll last and what they'll pivot to next. More phones maybe?
|
|
#
?
May 11, 2018 09:50
|
|
|
Now fixing up my methods by putting phpdoc annotations like @throws everywhere. The last time phpdoc was generated was 4 years ago, and nobody knows how to generate it now. Also putting @covers on all lovely tests, so that when I can go to Jenkins and see the code coverage report that's only run once a month and nobody cares about it because I was the first guy that said that if you go to the code coverage page there's a http 500 error and nobody knows what's wrong
|
|
#
?
May 11, 2018 09:51
|
|
|
Notorious b.s.d. posted:lots of common OO patterns require mocking. most notably, dependency injection
|
|
#
?
May 11, 2018 10:57
|
|
|
imo the best build script is A=`pwd`; cd ..; rm -rf $A
|
|
#
?
May 11, 2018 12:37
|
|
|
Krankenstyle posted:imo the best build script is
|
|
#
?
May 11, 2018 12:51
|
|
|
are there good dbas because we could really do with a good dba, as opposed to a bunch of developers occasionally moonlighting as a database person
|
|
#
?
May 11, 2018 13:06
|
|
|
Krankenstyle posted:imo the best build script is Need to submit this as a PR to a couple of repos...
|
|
#
?
May 11, 2018 13:12
|
|
|
qhat posted:It's called cmake and it's also called not checking effectively generated project files into version control. And don't C# me lest you out yourself as the retard who uses .NET unironically. What are you on about? VS natively supports your inferior build tool and language, so continue making terrible decisions without fear.
|
|
#
?
May 11, 2018 15:26
|
|
|
Notorious b.s.d. posted:lol forever at windows shops and the poor bastards who work in them Notorious b.s.d. posted:.net is cool but i ain't gonna bet my business on it Boiled Water posted:i feel that at the moment the new and cool microsoft is making it a less bad idea, but who knows how long it'll last and what they'll pivot to next. More phones maybe? stooooppp it huuuurtts because it's true
|
|
#
?
May 11, 2018 18:35
|
|
|
Fiedler posted:What are you on about? VS natively supports your inferior build tool and language, so continue making terrible decisions without fear. another reason never to create persistent visual studio solutions
|
|
#
?
May 12, 2018 07:05
|
|
|
hey so with people making GBS threads on modern cpu architectures for instruction-level parallelism and nontrivial cache protocols and whatever, what would a better world be like? manual application-level cache janitoring? langs with async memory operations?? itanium??? everything just really slow????
|
|
#
?
May 12, 2018 14:23
|
|
|
valves, lamps and tape reels
|
|
#
?
May 12, 2018 15:09
|
|
|
ynohtna posted:valves, lamps and tape reels he asked for a better world
|
|
#
?
May 12, 2018 15:13
|
|
|
a modern VM on a modern CPU runs stuff pretty close to native speed...I assume this is mostly due to the VM CPU extensions available does the webass VM in browsers at least have the potential for that or is it more like VMs from the olden days where everything was virtualized and there was no VT-d and the like? (its entirely possible that this question is Not Even Wrong) (this is me being ignorant)
|
|
#
?
May 12, 2018 17:09
|
|
|
|
| # ? Jun 3, 2024 21:46 |
|
|
VT-d and the "VM extensions" have very little to do with "language VMs". VT-d is mostly about setting up a context that can pretend to be ring 0, have interrupts, do I/O, run all those fancy privileged instructions. Some of them can be trapped and go into "ring -1" which is where another process handles them (the "hypervisor"). WASM runs fast because it's a very simple language without the complexity (some would say featureset) of JavaScript. You get A Linear Memory that can grow and not shrink, you get Read/Write, you get No GC, etc. So the translation to machine code x86 can be very simple. I expect that when people stand up non-trivial things on WASM (like host bindings, GCs, threads, atomics, SIMD), we'll see the VM performance start to buckle a bit.
|
|
#
?
May 12, 2018 18:23
|
|