What fucking programming language should I use?(wfplsiu.com)
wfplsiu.com
What fucking programming language should I use?
http://www.wfplsiu.com/
20 comments
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.
Agreed, although it gets more tired when you go through all 20 flows, vs just one.
it is a bit tiring. it's like the poor man's half-baked attempt at spicing up their personality (where poor = dull).
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.
There's a wonderful Andy Rooney bit about not using such words because he doesn't want to burn in heck.
FUCK is just a high entropy statement with lots of energy.
Especially when "What the fuck are you building?" is present further in the questionnaire.
I read 'intensity' as 'integrity' and I think I much the sentence that way.
The "really lazy desktop app" choice is Qt, not Visual Basic.
Visual Basic hasn't really existed for decades.
Visual Basic hasn't really existed for decades.
> 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.
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.
There's nothing lazy about C++ plus Qt. Perhaps you meant C plus GTK+?
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.
VB.NET is still a thing isn't it?
Yeah but why lock in with Microsoft when you can have a cross platform app at the same abstraction and difficulty level?
depends on whether the additional platforms are trivially ignorable or not.
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.
No quiz needed, the actual answer should be just "Whatever language you know and can get shit done with".
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.
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.
On the contrary, choosing Erlang for your startup seems to make enterprises nearly salivate to hire you.
Curious then realized it was very light in fun content. There is no way to get to cobol for instance
It got the wrong language for my example, a digital audio workstation with peer to peer collaboration.
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.
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.
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.)
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.
Though Rust is probably more appropriate for your needs, in terms of more modern languages.
It's like 30ms which is completely unacceptable.
As for your workarounds, for real time software, these workarounds are too nondeterministic. Real time is one of the primary features, so you need very predictable performance, and that implies having direct control over things like memory.
As for your workarounds, for real time software, these workarounds are too nondeterministic. Real time is one of the primary features, so you need very predictable performance, and that implies having direct control over things like memory.
>It's like 30ms which is completely unacceptable.
Not really.
https://twitter.com/brianhatfield/status/692778741567721473
I've seen 10ms mentioned as worst possible scenario, which means not coding with the GC in mind.
Not really.
https://twitter.com/brianhatfield/status/692778741567721473
I've seen 10ms mentioned as worst possible scenario, which means not coding with the GC in mind.
Like I said, it really depends on your needs... In a game, even, it would depends... a blink of an eye hickup every few minutes in a game is not a huge thing, depending on the game... many games would never even need a large GC cycle on a modern computer. I mean, look at how many fun games were made in Flash...
Yes, if you're doing really real-time, that's one thing... many things aren't, so it depends... that said, again, if you need really real time, a functional approach and rust may be a better option... or a number of other FP languages, for that matter... or C/C++ if you're a masochist, or really anal with your approach (not really trying to offend C/C++ guys, more pointing out that it's rarely the best pragmatic option)
Yes, if you're doing really real-time, that's one thing... many things aren't, so it depends... that said, again, if you need really real time, a functional approach and rust may be a better option... or a number of other FP languages, for that matter... or C/C++ if you're a masochist, or really anal with your approach (not really trying to offend C/C++ guys, more pointing out that it's rarely the best pragmatic option)
I believe you can turn off the garbage collector in go.
You might be right, but the language certainly isn't designed around not having garbage collection.
i'm not particularly experienced with go, but it does work directly with pointers iirc. all it lacks is an explicit memory free function, i think. is there more to it?
Uh. Citation needed.
I stand corrected, there doesn't seem to be a way to manually allocate and de-allocate memory. Looks like there is a switch to turn off GC, but it's intended for debugging.
You can set the environment variable GOGC=off [1]
There doesn't actually seem to be a way to explicitly free memory though so I doubt this is actually used.
[1]: https://golang.org/pkg/runtime/
There doesn't actually seem to be a way to explicitly free memory though so I doubt this is actually used.
[1]: https://golang.org/pkg/runtime/
It's only intended for debugging purposes, near as I can tell (and I'm not sure why anyone would want to do it in the first place beyond debugging):
https://github.com/golang/go/issues/13761#issuecomment-16772...
https://github.com/golang/go/issues/13761#issuecomment-16772...
[deleted]
I always just choose whatever I'm most comfortable with.
You don't always need an edgy language to use. Just use what you know.
You don't always need an edgy language to use. Just use what you know.
I answered in such a way that I was expecting Python or Ruby but got JavaScript. Is that the joke?
Kids these days. You could replace ALL of this dynamic content with a static page that says:
Use the language that's right for the job.
It's telling me to use Java and Swift for mobile development because hybrid apps suck. But Xamarin is fine, I don't get it.
If I could use cython everywhere I'd probably use cython.
Request: what fucking text editor/IDE should I use?
I enjoy gratuitous profanity and PLs, well done.
..must.. not .. give in.. to .. my.. negativity
Found this really funny, thanks :)
javascript
For desktop app. You will regret it.
Electron and nwjs seem pretty solid... VS Code works really well (for example), and can leverage one of the most diverse module systems around.
I feel the urge to cry.
I'm not saying it's the best option... more that it isn't a bad one, and depending on your needs, can be a good one. If you want to share logic across mobile apps, a web presence and a desktop deployment, leveraging your existing developers and creating a relatively cohesive experience, it isn't a bad thing.