|
bucketmouse posted:That lead me indirectly to this. You've linked to the same page there.
|
# ? Sep 4, 2013 09:06 |
|
|
# ? Jun 8, 2024 08:40 |
|
bucketmouse posted:That lead me indirectly to this. Only thing I can think of is why. Why would anyone in right mind invent this abomination. And comments are illegal. I mean WTF? You can make comments in brainfuck for fucks sake. Its like someone who never saw code invented language and all he knew, was that computers work well with numbers.
|
# ? Sep 4, 2013 15:29 |
|
evilentity posted:Only thing I can think of is why. Why would anyone in right mind invent this abomination. And comments are illegal. I mean WTF? You can make comments in brainfuck for fucks sake. Its like someone who never saw code invented language and all he knew, was that computers work well with numbers. If you read up on the history it makes more sense. It was never intended to be a programming language - rather it's the IR/opcodes and immediates for a VM that you were supposed to program via a quasi-wysisyg RAD environment that was so bad the programmers found it easier to just write the IR themselves.
|
# ? Sep 4, 2013 15:48 |
|
I don't even see the code. All I see is blonde, brunette, redhead.
|
# ? Sep 4, 2013 17:15 |
|
bucketmouse posted:That lead me indirectly to this. Why would they program in this directly, even with the tools they wrote? Would it have been that hard to write a C compiler for it? Or any kind of compiler, really. If the original tools for generating the machine code sucked that much, how long do you spend wading in that poo poo before you realize that making a high level compiler would save tons of time?
|
# ? Sep 4, 2013 17:42 |
|
How accessible were those tools in 1990? That's when the super NES came out, and most of those games were still hand-rolled asm.
|
# ? Sep 4, 2013 17:52 |
|
I mean, like, I can understand not wanting to go to the trouble of writing a compiler; it takes a *lot* of working with it to justify that. But why would you not at least wrap the parser with something that lets you have comments?
|
# ? Sep 4, 2013 17:55 |
|
Slanderer posted:Why would they program in this directly, even with the tools they wrote? Would it have been that hard to write a C compiler for it? Or any kind of compiler, really. If the original tools for generating the machine code sucked that much, how long do you spend wading in that poo poo before you realize that making a high level compiler would save tons of time? There's a bunch of discussion over in the Hacker News thread, but here's the most pertinent comment (emphasis mine): jloughry@hn posted:Mostly, it was lack of time; keeping up with compliance changes is a full-time job at any bank, and there wasn't time for 'science projects'. What tools did get written were done to scratch a personal itch, and were done late at night and on weekends, outside of work hours. Sometimes I get glimpses of this parallel programming culture where improving skills or tools beyond the bare spartan minimum to get today's to-do list finished is considered a waste of time, and it scares the hell out of me. If that type ran computing, we'd still be using punch cards.
|
# ? Sep 4, 2013 17:56 |
|
JawnV6 posted:How accessible were those tools in 1990? That's when the super NES came out, and most of those games were still hand-rolled asm. Now that I think of it I wonder why they didn't at least make up assembly mnemonics for each IR opcode and bang out an assembler for their made up assembly language instead of working directly w/ opcodes. e: oh i see now Movac posted:There's a bunch of discussion over in the Hacker News thread, but here's the most pertinent comment (emphasis mine): ;_;
|
# ? Sep 4, 2013 17:56 |
|
They eventually did write tools for it, but the original group of developers that switched to writing the opcodes directly were ex-mainframe guys that had been doing that sort of thing their entire career and so were pretty good at it and didn't properly consider that there were better ways to do it.
|
# ? Sep 4, 2013 17:57 |
|
Plorkyeran posted:They eventually did write tools for it, but the original group of developers that switched to writing the opcodes directly were ex-mainframe guys that had been doing that sort of thing their entire career and so were pretty good at it and didn't properly consider that there were better ways to do it. The fact those ex mainframe guys still write code like that no matter what language is a real horror.
|
# ? Sep 4, 2013 20:06 |
|
Plorkyeran posted:They eventually did write tools for it, but the original group of developers that switched to writing the opcodes directly were ex-mainframe guys that had been doing that sort of thing their entire career and so were pretty good at it and didn't properly consider that there were better ways to do it. This is why I always try to immerse myself in new poo poo all the time. I never want to be those guys.
|
# ? Sep 4, 2013 21:20 |
|
You can go too far off that end as well, you know the type of programmer who went from perl to php to ruby to rails to django to flask to python to never learning how to do one thing well, just how to tweak the language/framework du jour. I can see how a constrained environment that had already been burned on tooling once would eschew it. All it takes is another debug that root-causes to an error in the mnemonics that takes a day or two to sour on the whole proposition.
|
# ? Sep 4, 2013 22:03 |
|
JawnV6 posted:You can go too far off that end as well, you know the type of programmer who went from perl to php to ruby to rails to django to flask to python to never learning how to do one thing well, just how to tweak the language/framework du jour.
|
# ? Sep 4, 2013 22:21 |
|
Movac posted:Sometimes I get glimpses of this parallel programming culture where improving skills or tools beyond the bare spartan minimum to get today's to-do list finished is considered a waste of time, and it scares the hell out of me. If that type ran computing, we'd still be using punch cards. This happens maybe more often than people realize. In my experience it can occur when a programming group is directly subservient to a business group engaged in something profitable but repetitive. Programming is odd in that the work you do can directly lead to making that same work easier and better - but to a business line, this may not be acceptable for "moral" reasons. They're paying you to make THEIR work easier and better, not to improve your own lot, and if they have to slog through repetitive tasks day in and day out, the programmers shouldn't get it any easier. This means that "I did it on my own time" won't always keep you in the clear - I've been trashed for that, too. It's far better to keep any improvements completely off the radar. I realize people will think I'm full of poo poo, but I've worked in the legal software industry for years and have been lectured at length about this hostility. "Programmers think they are so special. Well, they should suffer like the rest of us."
|
# ? Sep 5, 2013 02:26 |
|
Sometimes you find great coding examples outside of Github: https://canary.pw/search/?q=mysql_connect+-localhost (Yes. This is me shamelessly linking my own website.)
|
# ? Sep 5, 2013 04:20 |
|
Movac posted:Sometimes I get glimpses of this parallel programming culture where improving skills or tools beyond the bare spartan minimum to get today's to-do list finished is considered a waste of time, and it scares the hell out of me. If that type ran computing, we'd still be using punch cards.
|
# ? Sep 5, 2013 10:37 |
|
Dependencies can trip you up as well, especially if you develop for a platform that's based on obsolete technologies. Sharepoint only recently moved on to .Net 4.5, so there was no point in studying the Task Parallel Library or async/await. It's still based on ASP.Net 2.0, so no MVC or Razor will be used here.
|
# ? Sep 5, 2013 11:52 |
|
Gazpacho posted:What should really scare you is that, given the wrong incentives (a steady flow of needed-yesterday tasks and a "culture of frugality"), you too would become a knuckle-dragger. Yep, there really doesn't need to be a lot. Any project manager that makes a habit of dropping deliverables needed today on your task list will kill any dreams of optimising process. You'll end up with hours estimates pared down to the minimum, so they'll just stack up the tasks and you'll be unable to get the time to go beyond getting it working to getting it working well. Eventually you'll resist change reflexively, and stunt your growth as a developer. Basically, don't get chained to these jobs for too long cause they're 100% poison.
|
# ? Sep 5, 2013 12:34 |
|
Maluco Marinero posted:Yep, there really doesn't need to be a lot. Any project manager that makes a habit of dropping deliverables needed today on your task list will kill any dreams of optimising process. You'll end up with hours estimates pared down to the minimum, so they'll just stack up the tasks and you'll be unable to get the time to go beyond getting it working to getting it working well. Eventually you'll resist change reflexively, and stunt your growth as a developer. One of my friends recently got a job where the business routinely says, "We don't mind if it takes longer, we're more concerned with quality and improving our process". I accused him of getting a job in Bizarro World.
|
# ? Sep 5, 2013 13:11 |
|
Ithaqua posted:One of my friends recently got a job where the business routinely says, "We don't mind if it takes longer, we're more concerned with quality and improving our process". Are you sure he's not lying to you?
|
# ? Sep 5, 2013 13:14 |
|
prefect posted:Are you sure he's not lying to you? Pretty sure. The business has been burned so much that they're happy to spend a few extra hours on quality. He was hired to take over their dev team, and the previous guy wasn't altogether competent. He regales me with stories of discovering that business-critical applications have horrible, revenue-losing bugs, and also aren't in source control. Or that developers don't think twice about patching code directly in production, so no one has any clue if what's in source control even accurately reflects what's in production.
|
# ? Sep 5, 2013 13:20 |
My last employer did not even use source control. We would just copy the source with a new name and the date appended after it, butt_shipper.pl.090513
|
|
# ? Sep 5, 2013 16:14 |
|
Maluco Marinero posted:Yep, there really doesn't need to be a lot. Any project manager that makes a habit of dropping deliverables needed today on your task list will kill any dreams of optimising process. You'll end up with hours estimates pared down to the minimum, so they'll just stack up the tasks and you'll be unable to get the time to go beyond getting it working to getting it working well. Eventually you'll resist change reflexively, and stunt your growth as a developer. you just described my previous two jobs. The reflexive resistance to change is definitely a thing and it's a real killer.
|
# ? Sep 5, 2013 17:15 |
|
Don Mega posted:My last employer did not even use source control. We would just copy the source with a new name and the date appended after it, butt_shipper.pl.090513 It amazes me not only that this still happens today but it seems to be a "solution" reached independently by bad developers everywhere. It's a sort of convergent evolution of dumb.
|
# ? Sep 6, 2013 01:03 |
|
In the absence of vc software that's the easiest (read lazyiest) solution to reach.
|
# ? Sep 6, 2013 01:30 |
|
Hard NOP Life posted:In the absence of vc software that's the easiest (read lazyiest) solution to reach. And it's several orders of magnitude easier to use than git. It's inexcusable for a professional software shop, but if the software's tangential and/or unprofessional, I'm with you, it's the easiest thing that can work.
|
# ? Sep 6, 2013 02:39 |
|
A team I sat next to had this really weird senior dev. They were using clearcase, and basically everyone would email him their changes for the week on friday, and he would manually merge and commit things once a week.
|
# ? Sep 6, 2013 03:24 |
|
Just bumped into this in a client's codebase:C# code:
|
# ? Sep 6, 2013 03:30 |
|
unixbeard posted:A team I sat next to had this really weird senior dev. They were using clearcase, and basically everyone would email him their changes for the week on friday, and he would manually merge and commit things once a week. That's the least painful way to use ClearCase.
|
# ? Sep 6, 2013 03:32 |
|
Using ClearCase is like volunteering to get mugged so you can then have a icepick jammed in your eye socket.
|
# ? Sep 6, 2013 04:44 |
|
Monkeyseesaw posted:It amazes me not only that this still happens today but it seems to be a "solution" reached independently by bad developers everywhere. It's a sort of convergent evolution of dumb. I have it on good authority that version control at Wind River consists of a bunch of ISO-9660 disc images.
|
# ? Sep 6, 2013 04:59 |
|
Ithaqua posted:They could've just done if (char.IsNumber(firstLetter)) ௲
|
# ? Sep 6, 2013 05:06 |
|
I don't think unicode support is high on their list of priorities.
|
# ? Sep 6, 2013 05:58 |
|
I believe his point was that there are a lot more numbers than 0-9, so the two snippets are not equivalent.
|
# ? Sep 6, 2013 07:21 |
|
The real solution, of course is char x = category.DisplayName[0]; if (x >= '0' && x <= '9') { ... }
|
# ? Sep 6, 2013 07:58 |
|
unixbeard posted:A team I sat next to had this really weird senior dev. They were using clearcase, and basically everyone would email him their changes for the week on friday, and he would manually merge and commit things once a week. It is like merge request only done manually and without diff patches.... pokeyman posted:And it's several orders of magnitude easier to use than git. It's inexcusable for a professional software shop, but if the software's tangential and/or unprofessional, I'm with you, it's the easiest thing that can work. Git is pretty easy to get the same effect once you learn a couple basic commands. I usually find the hardest part with git is to get developers to understand the concept of no central repo. Well that, and getting them to start making commits of less then 1000 lines at a time.
|
# ? Sep 6, 2013 15:20 |
|
HFX posted:Git is pretty easy to get the same effect once you learn a couple basic commands. I usually find the hardest part with git is to get developers to understand the concept of no central repo. Well that, and getting them to start making commits of less then 1000 lines at a time. Agreed. I found that git adds greater complexity to maintaining a "repo", and removes complexity from managing code during development. Once I understood how it tracks and merges code through the use of pointers, it made me wonder how I stayed sane without it. We definitely had some bumps at work moving from SVN to git, but it was definitely worth every headache; however, there were some that definitely made their opinions known when it came to this change, or really any change in their development process.
|
# ? Sep 6, 2013 16:55 |
|
HFX posted:Well that, and getting them to start making commits of less then 1000 lines at a time. This is an issue for a few select people here. They treat source control more as a way to save your work at the end of the day, rather than a series of individual modifications, and think that it's too much work to commit after each logical set of changes.
|
# ? Sep 6, 2013 18:12 |
|
|
# ? Jun 8, 2024 08:40 |
|
This may be unpopular but I think git is a bit of a coding horror in the fact that it fails to really hide any details of its implementation and makes source control more complicated than it should be. I really didn't grok git until I realized my branches were pointers and my commits were nodes in a graph. I've never had to understand the internals of any source control system like that before. This is coming from someone who uses git at work and likes git and understands how it's more empowering than, say, SVN but the learning curve on it is much sharper than it could (and should) be.
|
# ? Sep 6, 2013 20:42 |