I think the biggest thing is that the answer to just about any programming question you can think of is available with example code with a 2 second internet search. It's great, but it's also bad because kids these days don't have to figure anything out for themselves so they don't learn those skills.

Why? Just keep the current version until a significant vulnerability is found, then switch to something secure.

You have to react rationally, not just emotionally. :P

Upon reaching out to the the dev in question, he went to the extent of saying that he “allowed her” to call the app hers, given certain “circumstances”.

I wonder if these circumstances involved lube.

The 'lambda' he's talking about isn't a lambda function or anything fancy. It's just the name he's using for the speed/space tradeoff knob that compressors commonly give you. So for JPEG, for example, your 'quality' slider is adjusting lambda, but if you're cranking it way up to 99% then you're getting outside of JPEG's 'natural lambda' range and you should probably use PNG instead.

This guy's done quite a few good programming comics.

Isn't that basically DuckDuckGo? (Maybe with the !g option.)

What are you trying to accomplish? How much data? Basically anything up to a few kilobytes, EEPROM or some other kind of non-volatile RAM is the way to go. More than that, just spend the extra dollar or whatever and add a micro-SD reader, and you can store up to I think 256GB on something the size of your pinky nail.

If your company still exists and is profitable in 5 years time you will certainly have rewritten your code in something more efficient. It's not saying "performance doesn't matter", it's saying "performance doesn't matter if no-one ever uses your product." And if your product never reaches the market, no-one will ever use it.

I'm a long time C++ proponent but recently... eeeh, the arsenal of footguns only seems to be expanding and the amount of arcane knowledge required to write bulletproof code is beyond most good coders. I'm hoping one of these days Rust or Go becomes a suitable replacement.

I'm torn. I think Facebook's kinda evil, but then I also thing software patents are a load of crud. So I actually think if Facebook took this one step further and made it "you can't sue anyone for patent infringement", it'd be alright.

Maybe a variant would work if a lot of open source projects adopted it, whereby if you use any software under the license, you had to swear off software patent lawsuits.

My current project is written in a Pascal-like language so I've started all my arrays at 1. It took some getting used to but it has its upsides... hey why are you looking at me like that? :P

Looks cool for web development but I'd be worried about trusting my code to MS with all their telemetry etc. Being open source, though, hopefully someone's already combed through it for all that stuff?

Wow, what BS. Even back in the 90s, anything with a gendered pronoun in a positive context had to be female. Science and maths textbooks used exclusively female pronouns... 'the scientist notices her experiment does X', 'she inverts the matrix' etc. And still, any time anything ever uses male pronouns we have to change them to female pronouns "for equal representation." So fucking sick of it.

EDIT - why would there be an SJW problem in a coding community? It's totally divorced from SJW issues.

You'd think so, but no, not since various SJW trolls decided to use their bullshit as a platform for seizing control of online communities. Example: The attempt to take over Ruby with the 'Contributor Covenant'..

Something to do with CSS pixel widths maybe?

Why is this nsfw? My kids would write better code than most people I've worked with. >.>

That said, I won't teach them "to code", I'll teach them to solve problems. If those problems are best solved by delegating an algorithm to some cheap hardware, then coding's the answer. If they're better solved by a phone call to a vendor, they'll learn to do that. Don't confuse the means for the end.

I was just reading this rant by Steve Yegge and it sounds pretty cool.

Reading comprehension fail. The 36% was the number that could write code that compiled at all. The percentage who could actually solve the problems was much lower (as you say).

Off on a tangent now, but your post reminded me... one thing that absolutely pisses me off is when non-technical people say shit like "you're technical, not artistic". Like, fuck you buddy my work is art, it just also happens to actually solve a problem instead of just being a waste of glue and macaroni like yours.

"Hi, I'm an artist!"

"Oh, you're good at painting? Here's a roller, paint that wall."

- 99% of commercial software development.

Yeah but "I want a CRUD web app for a clothing store to manage their inventory" is easier than coding it, given that you really don't care about the details at that point.

You're right that the English requirements were underspecified, they were still more than adequate for a human programmer to follow. Software tools will (in the next decade, IMO) be able to take such a high level description and fill in the blanks to produce a useful result.

Is there a way to understand something without modeling it?

Who's in charge of that team, though? The code quality and overall architecture are the responsibility of the lead developer, not the drones.

Also, depressingly, 'cookie cutter crap' is 99% of software development. Realistically, most companies need Yet Another CRUD App or Yet Another Web Portal, it's actually incredibly hard to find paid work where you're solving interesting problems.

Depends what you want out of your job. It pays alright, not as well as some trendier areas of software development which are also a lot easier, but it's very rewarding if you love a good challenge. You'll be a lot more interdisciplinary compared with 'standard' software dev because you'll need a good understanding of whatever hardware you're controlling (which often includes mechanical systems, etc.) You also need to be able to make the most of low-end processors while meeting hard realtime requirements.

He's using C++ these days running on small embedded Linux systems. The place where he works has a pretty cool setup with automated unit testing and simulation.

Devs who don't give a shit and just bash out crappy code don't give a shit about it. News at 12.

I would not hire her as a sysadmin, no. :P

A lot of those seem to be missing the point (or they suffered through whiteboard interviews that missed the point). A whiteboard interview shouldn't be about your ability to recall language- or library-specific interfaces. It should be about your ability to understand and solve a problem.

If you don't know how to get the length of a string in Python 3, that's not a problem. If you don't know that getting the length of a string is a thing you can do, then that's a problem.

One of my friends made the jump from psych nurse to embedded software developer at around 35, and he's doing great. It all comes down to attitude and effort, though.

Properly implemented AGILE is actually pretty alright. Basically, scrum boards / kanban / whatever you call it is just a fancy to-do list, and that's what any software development methodology boils down to: a to-do list to track all the shit you have to remember to do.

There's nothing wrong with having a 5-minute standup meeting (and it should only be 5 minutes) with your team at the start of the day. It's a good way to keep communication open and you'll often get quick solutions to blocking problems. It's also a good way to make sure everyone actually knows what they're going to be doing that day.

Deliberately work on something small and self-contained that I can completely finish in a short time. I get my motivation from finishing useful things, and large well-engineered systems can take months or years before I actually see my work /do/ anything. So if I'm starting to get depressed about my work, I do some home-handyman stuff or work on a throwaway "hack project" that I can knock off quickly without worrying about over-engineering it.

Absolutely depends what I'm doing. I multitask like a boss if I'm doing admin / paper pushing / organisation stuff. If I'm coding or designing then hell no, it takes me half a day to get my head properly into a task if I haven't worked on it for a while. Do one thing, do it well, finish it, do the next thing.

What are strengthX and strengthY?

As a fellow git victim, I heartily agree with this post.

I love the way that they tagged that as fiction, as if to make sure nobody mistook it for a genuine interview. :P

I stick by my criticism of C++'s minefield of undefined behaviour, but I totally agree with your reasons as well. Of course, a sufficiently ingenious fool can make a hash of a job in any language, but C++ is particularly vulnerable to a certain kind of clever-yet-clueless coder, the kind who turns any task into an opportunity for mental masturbation and so ends up producing a giant pile of intricate, carefully crafted, very clever, yet mostly useless crap.

The deeper I get into it, the more convinced I am that C++ is a terrible language.

It's still probably my favourite language, for all its faults, and if you steer clear of all the 'here be dragons' parts it can be very useful. But there are so many things about it that (if you adhere strictly to the spec rather than just going with "what real compilers do") are pure pants-on-head.

I think part of the problem is that C++ isn't a well-defined language in its own right. It's a systems implementation language, and it's designed to be as flexible as possible, so you can't really talk about "C++" on its own. You have to talk about "C++ on [specific hardware] using [specific compiler]". As soon as you do this, all the undefined stuff goes away and you have a real language.

I like the second answer. And in that vein, here's my answer - Change the '45' to whatever number you wish to divide. :D

while (X > 0) C = C + 1;

I just break the project down into chunks that should take more-or-less a day to implement. Any chunk that I'm not confident can be done in a day gets subdivided. Then add up the chunks and that's how many days you think it'll take. Double that number, and that's what you tell the project manager. Double it again, and that's what you tell the client.

So far it's worked out to be pretty accurate, at least on short ( < 2 week) projects. :)

Edit:

A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?”

“It will take one year,” said the master promptly.

“But we need this system immediately or even sooner! How long will it take if I assign ten programmers to it?”

The master programmer frowned. “In that case, it will take two years.”

“And what if I assign a hundred programmers to it?”

The master programmer shrugged. “Then the design will never be completed,” he said.

• The Tao Of Programming

The artist saves whatever artwork (2D pictures, 3D meshes, rigged animated characters, whatever) in some file format that their software can save to. You then write code (or use a library which already contains code) which knows how to read those files and load the images, vertices etc. Once you have the data for the artwork loaded into your program, you can do whatever you want with it. Draw it on the screen, animate it by redrawing the screen and moving it a bit every time you redraw, whatever you want.

The hard bit is deciding what you want it to do. Once you know that, it's usually pretty obvious how to get the effect you're after.

If you are "new to development" then the last thing you should worry about is "how your project scales." You don't need it to support 100M concurrent users, you need it to fucking work do something useful.

1) Make it work.

2) Make it work right.

3) (OPTIONAL, FOR EXPERTS) Make it work fast.

If 10 people love the thing you built and they tell their friends about it, then maybe you have 50 users. If not, go find out why and fix it. Rinse and repeat. If you get massive organic growth to the point where your hacked together thing can't keep up, hire one or two people who know what they're doing to fix it.

Did you watch the video? :P

With a name like munge.c what did you expect? :P

Edit: If you want documentation, maybe start with the README?

Careful you don't end up hacking too much time!

JavaScript. :P Seriously though, Rust seems pretty good for systems programming.

As you've discovered, a brute force approach is trivial but runs very slowly, O(N^2) to find all primes up to N. There's a bunch of well known algorithms, like the Sieve of Eratosthenes, to speed it up. :)

Thanks for having a crack at it, at least! :)

I think I'm on the right track now. It turns out that WSAAsyncSelect() (which wxSocket uses internally to get callbacks) will only send one message after each call to recv(), but sometimes this message will be sent while the data is still being recieved, before select() / recv() can see it. So if you only ever call recv() from the event handler, AND it's guarded by a call to select() to see if there's any data waiting, then you can get very rare situation where a message is generated, select() says there's no data waiting, and so recv() is never called, which means no new events are generated. This seems to be what's going on inside wxMSW.

What this has to do with modal dialogs, I have NFI, except I guess they introduce some time lag that uncovered a race condition or something.

Edit: Nope, while I still think that's one problem, it looks like you were right about the message loop. Windows events still get handled but wxWidgets' internal events don't seem to get pumped while the dialog's message loop is running. Blah.

Yeah, they do their own little event loop inside ShowModal() but that should still pump the main event queue, right? My main window still gets other messages (timer ticks, etc.) Or does wxTimer not use the same event queue?

That's the thing, though, it goes for management too. Good management, I mean really good, skilled, smart people in management roles, is amazing. Think of Ted in Better Off Ted. The problem is, due to a variety of effects (the Peter Principle, the simple fact that good smart non-managers are indispensable because they're actually doing vital work, etc) you often end up with numbnuts in management roles wrecking the whole thing.

The #1 reason why Agile fails:

• As always with the software engineering methodology du jour, it's seen by non-technical management as a silver bullet that lets you build software with unskilled staff, so they hire cheap, submissive developers.

Seriously, I've been in Agile teams and it freaking rocked. I've been in other Agile teams and it sucked donkey bollocks. It all comes down to the people in the team.

Absolutely true, and as I said in another post, it makes git really good for the specific use case you describe, with a huge team working in a very parallel and decentralised manner. (In fact, Linus wrote git specifically to deal with this case, so it ought to be good at it!) And if that's what you're doing, then by all means, use git.

In my experience, though, that kind of environment is very rare. Usually when people say "I need version control" they're working solo or in a small team. Concurrent modification can be avoided with a trivial amount of communication, and the extra capability that git provides for industrial-strength merging just isn't used often enough to justify the extra workload.

Programming, and computers in general, won't be your thing for long if you make it an ego issue to learn about every single technology out there, no matter how poor its cost:benefit ratio is.

Git is a great tool for a very specific use case, which is managing the industrial scale branching and merging maelstrom that is Linux kernel development. It's really not a very good tool for most common version control use cases, but fanboys' cargo cult mentality combined with a juvenile "if you think software is annoying to use then you're just not good enough at it" attitude means it gets used everywhere even when not appropriate.

I used git for the past three years, finally got tired of its inexplicable bullshit, and migrated back to SVN. It's great, it's simple, it's quick, it works.

Just use SVN.

05 REM WEDDING KNIGHT

PHP is like a greasy hamburger. There's probably more stuff in there than you really need but hey, it gets the job done for pretty much everyone and it tastes alright.

Hahahahahah truth.

Original

Kinda both. They're easier to understand because modern programming languages are better defined, more consistent, and less quirky. They're harder to understand because software today is multiple orders of magnitude more complicated so there's more stuff to understand.

As if.

Goes back to training my new AI to call me 'mummy'

OpenGL first. There's so much inertia to keep OpenGL around that you're guaranteed to see a good OpenGL-on-Vulkan implementation sooner or later.

IMO the specific high level graphics API that you learn isn't that important. The concepts are all basically the same, so the exact name of the functions you use to feed textures, vertex arrays, transform matrices, and shaders into the GPU are kind of irrelevant.

What kind of game are you making? Game AI is almost always tightly coupled with the specific game, and doesn't bear much similarity to "real" AI. So for a chess AI you'd vary its difficulty by changing how many ply it looks ahead, whereas for a FPS bot you'd change its reaction time and aiming accuracy (or if you want to get really cheesy, just bump up its hitpoints and damage). An RTS bot or a Tetris game would just throttle its actions per minute.

Take a read through the gamedev.net AI forum - there's tons of good info on there iirc. Also there are regularly good articles on Gamasutra from commercial game devs about all sorts of things, including AI.

Python's a good learning language but (IMO, I know the rest of the world disagrees) not a great beginner language. It's very dense and you need to understand a ton of very high level programming concepts (weird variable scoping rules, OO, dynamic typing, lambda functions, list comprehensions, lazy evaluation...) to properly use it. People think C is hard for beginners but all you really need to learn is functions, control structures, and to get the concept of pointers and you're pretty much set.

Excellent point on the human lifespan thing. People do plateau to a certain extent, at some level determined by their native ability, but often people do still keep improving somewhat. Kind of like the way hobbits (being longer lived) are still considered 'children' into their 30s.

That's why not many people are genuine experts in more than 2-3 things.

He's talking about gitting gud, not just writing some hello world crap.

Haha fair enough. :) And I know you did say it was for personal interest, so many 'don't use Win32' replies must have been annoying. Like when you want to write your own 3D engine complete with rasterizer, and you ask a question about (say) Gouraud shading, and get 500 responses saying "use opengl lol". :P

Stray thought - if you're interested specifically in Win32, once you get the hang of it have you thought about contributing to ReactOS? That will start to become more and more relevant as old NT and XP boxes finally die, there's decades' worth of software which won't run on newer versions of Windows and can't be updated for whatever reason (lost source, etc.)

Win32 is about a million years old and is not how Windows application development is done nowadays. So I've got two answers for you depending on why you want to go back to Win32.

1) If you have a specific reason to use Win32 (ie. you specifically want to target Windows 95 for some reason): Win32 is easy to access from C++, you can just call the API functions directly. Back in the day I started out with a book (Sams Teach Yourself Windows 95 Programming or something like that) and from there just figured it out from the API documentation, Win32 is pretty straightforward once you get your head around message loops, handles, events etc. and the documentation is great.

2) I know you said you're not interested in learning something else, but Win32 isn't going to be around much longer and unless you want to be stuck in the past like those Amiga guys, it's worth trying something newer. These days I use wxWidgets for my Windows development, it's a (very well designed IMO) C++ library which started out as a wrapper for the Win32 API and so will be familiar to you from the start, and it's just nicer than raw Win32. Kind of like what MFC should have been. Plus you get cross-platform capability and future-proofing for free.

You're gonna get shit for this one but JS has grown into a serious language, and (because of its flexibility) can do anything that the more "respectable" (aka wanky) CS languages can do.

Seriously? C is what almost all important software in the world is written in. Not your fucking instagram web app crap, but stuff that runs power grids and comms satellites. What would you suggest, that they start by playing with play-doh?

Because it's cheap. Cheap is good.

No go.

Hah, same.

When dealing with large amounts of data, don't forget small efficient tools too! Like the Linux command line.

Nice sum-up of the issues, I see it pretty much the same way. On the one hand, giving someone a pre-made answer on a plate does them a disservice in terms of the value they get from their education, and it can be like feeding seagulls, where suddenly you're getting spammed with every first-year assignment question around.

On the other hand, sometimes they're fun little exercises to do just to inject some variety into your day.

Is there a rule in this sub against doing peoples' homework for them?

Deep learning is one of those fields where the overheads of Python aren't that important, because the heavy number crunching is all done inside highly optimised C libraries or on the GPU. Any slight speed penalty is outweighed by the arguably-nice syntax and the flexibility of an interactive command line.

Oh. :/

At least your username is relevant. :P

If you're into this stuff, take a look at Neural Networks and Deep Learning. It's a pretty good introduction, pitched at students with a basic understanding of calculus, linear algebra and programming in Python, but new to modern neural networks.

OK, I'm just gonna come out and say it.

Git is fucking terrible as a mainstream source control system.

Don't get me wrong, it's a great power tool for Linus to manage the kernel code with. And it's super useful when automated or in some other niche use cases.

But for a simple user who wants to put some files in a magic box and have the same files (or older versions of them, even) come out later? Its commands are arcane, it's disturbingly fragile, errors that can occur are obscure and sometimes silent so they can remain undetected for months, and error messages are either opaque or misleading.

Overall the whole thing requires a deep understanding of the underlying system in order to really use it properly. Maybe that's OK for an in-house tool (which, as I understand it, is really what git is) but not for a default tool for everyone.

Too late, the idea is out there and so someone will make it before too long. And as pointed out, if it's doable out in the public domain as a personal free-time project, then government agencies almost certainly have been doing it for years.

The grammar-obfuscator project idea is a great one, it'd be interesting to see how people would approach it.

Graph of languages: https://i.imgur.com/7ZQ2CE4.png

Vertical axis: Rank on Stack Overflow.

Horizontal axis: Rank on github.com.

So basically your four quadrants on that graph are:

• Bottom left: Less popular.
• Top left: Hard/annoying/fiddly.
• Top right: More popular.
• Bottom right: Easy.

Oh totally, any time you start putting your obsession with a particular paradigm above the need to write good code, you end up with unreadable crap.

I can definitely see how FP's lack of side effects makes it attractive for concurrent processing (although 'real' OOP's messaging gives similar advantages without IMO being so restrictive) but as so often happens with neat software development tricks, it often seems to devolve into mental masturbation on the part of ivory-tower coders.

Any extremist approach to software development is less effective than a pragmatic approach, and functional programming (while it has its uses) seems to attract zealots more than most. Hiding your branches in lambda functions just obfuscates your code.

Evil. I like it.

Using tabs in source code should be a firing offense.

JavaScript isn't the same thing it was back in the days of Netscape 4 vs IE5. It's actually a real, semi-standardized language now.

Now that looks all kinds of awesome. Bookmarked for later tonight. :D

7zip.

Do project work. Write programs to generate cool pictures. Write a game. Write a web server. Update your web page. Get an Arduino and build a line-following robot. Pick something that fascinates you and excites you, and get your hands dirty. The best way to learn software development is by doing, and the best way to learn design is to run through the whole project lifecycle over and over and over again.

Edit: Also, and maybe most importantly, pick up one of your old projects after a few months. Look at it with fresh eyes, see the mistakes you made, how you could have done better. Brush it up so it's as good as you now can make it. Repeat this with the same project every few months. The best way to learn to maintain code is by doing so.

I was all ready to disagree based on your title but I think you actually make good points. People who are highly intelligent but can't step out of their own head to consider how their work is being used are useless. People who have to be 'perfect' either work incredibly slowly because they're terrified of making mistakes, or they deliberately don't check for their own mistakes because they deny they could even exist.

If you care more about your users than about showing off your vast intellect, you'll produce code that's simple, useful and maintainable. If you're humble enough to admit you might make mistakes, then you'll test your software thoroughly.

Like any methodology, when used properly by good people, Agile is a fine way to do things. The problem is shitty management and shitty team leadership, which you get in 90% of places because Sturgeon's Law.

Don't throw the baby out with the bathwater, though. Automated testing (including unit tests) is fantastic and is absolutely indispensable for working with a large codebase. Unit testing lets you change code without causing regressions and (if your tests are any good) with some degree of confidence in your changes from the moment they pass the tests. If you're afraid to change things or add things because it'll break a bunch of tests, that means your codebase is fragile and you need to refactor it into something less scary and spaghetti-like.

Exactly. Agile grew out of 'extreme programming' which grew out of rapid prototyping, which grew out of the observation that usually when you start a software project, you don't know what the hell you're doing. The best way to build a great product is to get hacking, and iterate on what you've got until it becomes awesome. Agile is basically a formalization of this, and it's great for what it's great for.

However, it's a terrible way to build a system when you know from the start what you're building. It's also a terrible (or at least, very expensive) way to build things that aren't just pure software. Like any methodology, it's terrible for the things it's terrible at, and shouldn't be seen as some panacea.

Sadly, in recent years Agile development is seen as the hammer to use for all development nails, and worse, it's been used in half-baked half-arsed implementations by thousands of teams that call what they're doing 'Agile' but are actually just doing shitty programming.

As an aside, though - unit tests (and automated testing in general) is (IMO) the single greatest thing to come out of the software development world in the past decade. It seems like a lot of wasted time and overhead when you start out, but if you expect your software to ever exist beyond version 1.0, it's a small price to pay for free regression testing forever. You know how software gets exponentially harder to maintain as it ages? Automated testing is the way to fix that.

Spot the pure maths junkie. :P

Ooh, nice puzzle. I think the number of zeroes is equal to log_k x for the smallest integer k which produces an integer logarithm.

There's probably a nicer way to phrase that.

Ooh, pretty! Gonna have a play with this later. :)

I came to the same conclusion 15 years ago when working in web dev. Your customer wants to run their own web site, so you build them a CMS. They want it to be more flexible so you add features. They want to be able to script and style and alter the layout and and and... you've looped right back around and what they really want is Apache + PHP.

s/some/almost all/g