Poll: Stance on programming languages
You do not have permission to vote in this poll.
Whichever is practical for the application 14 73.68%
Whichever the user is more skilled in 4 21.05%
blank or die -- there can be only one 1 5.26%
Total 19 vote(s) 100%
* You voted for this item. [Show Results]

Stance on programming languages - Psychology, Philosophy, and Licenses
(07-04-2017, 11:35 AM)venam Wrote: Maybe the language doesn't allow you to do what you want to do.

Another classic case of "your language sucks" then. If it limits your freedom, don't use it.

I guess the OP had other intentions though, not limited to real-world applications.
At work? The best tool for the job. A lot of people say that but never provide their criteria, so here are the major points I consider in order to determine whether or not a language is the best tool to use for a given project:

1. Time to useful knowledge: Do I already know this language or does it look like something I can learn quickly? This is a personal thing which requires honest self-assessment. I can typically learn a programming language to the point of (professional) usefulness within a weekend, sometimes I need a bit longer, but I've gotten pretty good at guesstimating how long it will take me to learn something. If you're a professional software engineer, then you should definitely take the time to self-assess if you're not already doing so.

2. Is runtime performance a concern and if so, to what degree?: If runtime performance is a major concern or if the application requires heavy computation, data manipulation, or parsing of large amounts of text (companies still do this...), then I start comparing task-specific benchmarks online and/or writing my own benchmarks in various languages in order to make an adequate comparison.

3. External dependencies: For each language under consideration, given the tasks, will I require the use of lots of external libraries? Does using those external libraries carry with it additional risks and are those risks acceptable? In general, pulling in a ton of outside dependencies and to a lesser extent, internally maintained dependencies, carries certain risks. For example, if we rely on an external library that all of a sudden ceases to be maintained, or the developer is not very good about keeping up with security fixes. This is a huge problem when required to use a proprietary library or tool, less so in the Free Software and Open Source worlds.

4. Is my team already proficient in the language being considered?: Very similar to #1. It's all well and good if you can learn a language in a matter of hours to the point of usefulness because you're an excellent engineer who knows how to self-assess, but what about your team? If the project requirements don't offer much in the way of prep-time (as is the case in most startups) and your team in general is not quick to pick up languages (or frameworks), then consider placing bonus points on languages they already know.

5. Development time: Is this a time-sensitive project? Is the average speed of development in the considered language acceptable given the project's time constraints? Typically development times are better for languages where I'm "more than just useful", same for my team. This isn't always the case though. Sometimes a language just lends itself to faster dev times, whether it be due to minimal syntax or well designed grammar or ease of understanding the language API docs. For example, Go might have easy to grasp syntax, but the docs, while technically complete, are lacking in the "readable by mere mortals" department. Meanwhile (and I'm probably committing a cardinal sin here), C# has some strange conventions, but the docs are clear as day. If I have a young team and the other criteria point to either Go or C#, as a lead dev, I might lean more toward C# for the benefit of team dev time (and confidence building).

At home? I use what's fun. Typically I'll choose a language that I have less practice in (C, Rust, the lisps, etc) because it's fun to observe self-improvement and I enjoy the puzzles that come up.
Github: https://github.com/darthlukan
CRUX Ports: http://ports.brianctomlinson.com
GPG: 3694569D
"We're all human, act accordingly." -- Me
(07-04-2017, 04:03 AM)jkl Wrote: Go does, of course.

go is a pretty mature and powerful language. why does having a slack channel have a negative connotation on a language's appeal?
Go is an explicitly simplistic language, designed for people who are too dumb for C++. (Paraphrasing Rob Pike here.)
Slack is the hipster version of the IRC and there is no good reason to use Slack for any project unless you want to attract people who are not deeply into tech.
you dont always get to choose. many times the technologies used for a project are based upon requirements like hardware, contracts, existing software, etc. being a versatile programmer means doing what you need to to get the job done. sure a program might be better served written in c vs python, but the client might have other reasons for why they want it in one lang over another.

also, as a polygot programmer/scripter i can honestly say i dont have a favorite language. they all have their faults.
my main interests lie in c and d. for scripting, i prefer shell scripts ( rc and if i must, bash ) and where that fails, i think i'm likely to use python.
(07-04-2017, 02:46 PM)jkl Wrote: Go is an explicitly simplistic language, designed for people who are too dumb for C++. (Paraphrasing Rob Pike here.)
Slack is the hipster version of the IRC and there is no good reason to use Slack for any project unless you want to attract people who are not deeply into tech.

that is quite the paraphrase, yea. it was created not for people who are "too dumb for c++" but because pike was annoyed by the buildtime of an internal google c++ program. my cs colleagues and i use slack daily for collaboration, does that mean all of us are not deeply interested in technology?
perhaps using slack for internal communication is an exemption
How dare you question the all-powerful Lisp!
lisp sucks dude it only abstracts the things that shouldnt be abstracted so have fun with ur overweighted and under-efficient applications dude

Members  |  Stats  |  Night Mode