Have you already established a language for your project or team?
Yes: Keep using that fucking language. Unless you can't accomplish your goals with your current language, you're setting back progress by starting with a new language.
No: Are you building a mobile app?
Yes: Are you building for Android, iOS, or both?
Android: Looks like you're using fucking Java. Hybrid apps suck.
iOS: Use fucking Swift. Hybrid apps suck.
Both: Time to learn fucking Java and Swift. Hybrid apps suck, so your dumb ass needs to learn both.
No: What the fuck are you building?
Web app/Networked application: Is it a client-side app?
Yes: Looks like you're stuck with fucking JavaScript you poor bastard.
No: Are you working for an established enterprise or a startup?
Enterprise: Just use fucking Java. No one ever got fired for choosing Java.
Startup: Do you give a shit about concurrency?
Yes: Do you know why you give a shit about concurrency?
Yes: Are you into functional programming?
Yes: Do you need to use the Java Virtual Machine for some fucking reason?
Yes: Use fucking Clojure
No: Use fucking Rust or Elixir. I've got you this far, choose whichever one doesn't look like shit to you.
No: Use fucking Go.
Not really: I didn't think so you asshole. Just use Ruby - probably with Rails - and get the fuck out of my office.
No: Do you need static types?
Yes: Use fucking Dart
No: Do you want only one language in your codebase?
Yes: You're stuck with fucking JavaScript, but you already knew that
I don't care: Are you already familiar with at least one programming language?
Yes: Are you nostalgic for the web of the early 2000s?
Yes: You should probably stick with fucking PHP
No: Use fucking Ruby
No: Use fucking Python. It's easy to learn and very powerful.
Desktop app: How fucking lazy are you?
Really lazy: Damn it. Just use fucking Visual Basic. I hope you're proud of yourself.
Sort of lazy: Just use fucking Java.
I'll sleep when I die: Do it properly in some fucking dialect of C
Maybe I'm getting old. I love these sorts of technology selector flowchart things in general. However, the trope of throwing in a bunch of random "fucks" and getting a ton of upvotes for it feels played out to me.
It's just poorly done. The bits like "I hope you're proud of yourself" and "Just use Ruby - probably with Rails - and get the fuck out of my office." are actually how you write in this style; the rest just seems like a templated "I'll write it like this and then come up with something better" first pass, that never got fixed.
Off topic from the article, I don't understand the purpose of using profanity and then censoring it. Writing things like F!@K just seems like a weird middle ground that loses the intensity of cursing and the professionalism of not cursing.
I originally titled the article with the censored version as that was the name on the page. I believe they censor it on the first page as a way around workplace filters, as there's a SFW button at the top. I think once you get into it, the language is uncensored.
We always unbowdlerize titles. But I don't think "f!@k" is much different from "darn" or (hmm) "dang". People have been doing this to profane words for a long time, probably for as long as profane words have existed.
There's a wonderful Andy Rooney bit about not using such words because he doesn't want to burn in heck.
> The "really lazy desktop app" choice is Qt, not Visual Basic.
Qt has nothing to do with laziness. It's simply a well thought-out GUI toolkit which looks good and doesn't require tons of boilerplate code to get a hello world app to work.
Nowadays, if other GUI toolkits aren't as user-friendly as Qt, someone has dropped the ball.
Coming from a web-dev background, it feels like the "really lazy desktop app" solution of the day is Node-Webkit/Electron. Everything else requires multi-platform testing.
It would be nice to be able to back up a question. It was pretty funny, but having to start over every time to check out the whole decision tree was a bit tedious.
I would say that if one does not have experience with an enterprise stack they should really choose to work with one irrespective of whether they are a startup or no. Your startup will probably fail anyway. The experience you get is the only thing that you'll be left with. And if you chose to work with chicken-scheme and what not, good luck putting that on your CV.
Most "enterprise" stacks introduce complexity that isn't ever going to be needed really early on, and in general that slows down initial development, and the road to something that does its' job. Many of them are over-engineered and a bad fit, used badly too often.
Of course the alternative is understanding your problem domain and picking appropriate tools and approaches instead of using (insert .Net or Java framework here) for everything.
This is a hard real-time problem. There's a well-known general solution for hard real-time problems: split the problem into a data plane and a control plane, and then program those separately and network the components together (e.g. as two processes communicating over a unix domain socket.)
You can write your GUI in Visual Basic or Node or whatever-the-hell, as long as you've got your audio engine written in something with deterministic latency. If you specify a protocol ahead of time, those can even be separate teams with separate competencies!
Sadly, none of the real-time audio/video/image processing software companies seem to have caught onto this. I guess it's only really "well-known" in the network programming world. (A few game companies seem to have figured it out as well, but not nearly the majority.)
It kind of depends, Go's GC cycle in recent releases is minimized so that no GC cycle will last more than N milliseconds (I forget the specific amount), depending on your specific timing needs, it may be acceptable... You can also write your program so that objects/references are held and GC doesn't happen, depending on your memory constraints and needs (ram is cheap, and systems with 64-256GB are possible relatively inexpensive, compared to developer pay for a month)
Though Rust is probably more appropriate for your needs, in terms of more modern languages.
[+] [-] hythloday|10 years ago|reply
[+] [-] Maken|10 years ago|reply
[+] [-] matobago|10 years ago|reply
[+] [-] matobago|10 years ago|reply
[deleted]
[+] [-] ocfx|10 years ago|reply
[deleted]
[+] [-] StevePerkins|10 years ago|reply
[+] [-] derefr|10 years ago|reply
[+] [-] Tempest1981|10 years ago|reply
[+] [-] hnbroseph|10 years ago|reply
[+] [-] klinskyc|10 years ago|reply
[+] [-] publicfig|10 years ago|reply
[+] [-] dang|10 years ago|reply
There's a wonderful Andy Rooney bit about not using such words because he doesn't want to burn in heck.
[+] [-] massemphasis|10 years ago|reply
[+] [-] m52go|10 years ago|reply
[+] [-] carlisle_|10 years ago|reply
[+] [-] otabdeveloper|10 years ago|reply
Visual Basic hasn't really existed for decades.
[+] [-] bubuga|10 years ago|reply
Qt has nothing to do with laziness. It's simply a well thought-out GUI toolkit which looks good and doesn't require tons of boilerplate code to get a hello world app to work.
Nowadays, if other GUI toolkits aren't as user-friendly as Qt, someone has dropped the ball.
[+] [-] copperx|10 years ago|reply
[+] [-] derefr|10 years ago|reply
[+] [-] richardwhiuk|10 years ago|reply
[+] [-] misthop|10 years ago|reply
[+] [-] Mahn|10 years ago|reply
[+] [-] lumberjack|10 years ago|reply
[+] [-] tracker1|10 years ago|reply
Of course the alternative is understanding your problem domain and picking appropriate tools and approaches instead of using (insert .Net or Java framework here) for everything.
[+] [-] derefr|10 years ago|reply
[+] [-] stephenitis|10 years ago|reply
[+] [-] AndyKelley|10 years ago|reply
It said use Go, but Go is garbage collected and that is unacceptable for an app that needs to process real time audio with low latency.
Same thing applies to any networked video game.
[+] [-] derefr|10 years ago|reply
You can write your GUI in Visual Basic or Node or whatever-the-hell, as long as you've got your audio engine written in something with deterministic latency. If you specify a protocol ahead of time, those can even be separate teams with separate competencies!
Sadly, none of the real-time audio/video/image processing software companies seem to have caught onto this. I guess it's only really "well-known" in the network programming world. (A few game companies seem to have figured it out as well, but not nearly the majority.)
[+] [-] tracker1|10 years ago|reply
Though Rust is probably more appropriate for your needs, in terms of more modern languages.
[+] [-] copperx|10 years ago|reply
[+] [-] d0lph|10 years ago|reply
[+] [-] gravypod|10 years ago|reply
You don't always need an edgy language to use. Just use what you know.
[+] [-] pbreit|10 years ago|reply
[+] [-] fucking_tragedy|10 years ago|reply
[+] [-] capote|10 years ago|reply
[+] [-] jokoon|10 years ago|reply
[+] [-] clishem|10 years ago|reply
[+] [-] VeejayRampay|10 years ago|reply
[+] [-] Dowwie|10 years ago|reply
[+] [-] coderKen|10 years ago|reply
[+] [-] kylehotchkiss|10 years ago|reply
[+] [-] akerro|10 years ago|reply
[+] [-] hockeybias|10 years ago|reply
[deleted]