[dkarapetyan]

I'm not really a programmer. All my training is in abstract math so whenever I see people arguing over language X and Y it always seems weird to me. I don't write code until I've sketched things out with pencil and paper and by necessity I have to disentagle the syntax of the language from the essence of the problem. Turns out when I do things that way translating the solution back into a language X ends up being the easy part and it really doesn't matter what the target language ends up being. Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation.

So I don't think it goes hand in hand. The fundamental bottleneck is always what's in your head.

[nnq]

> just shifts how I encode the solution

And this is actually the most important thing in industry software development.

It affects:

1. how easy it is to modify an existing codebase: eg., can you add feature X before your competitor even after you app grew to 1M LOC?

2. how easy it is for a new developer to start working productively on you codebase

3. how stable your software is: do modifications introduce subtle bugs that make the whole thing more and more unstable until it becomes unusable?

4. how secure your software is: how easy (read "cost effective") is it to write secure code without having to take 10x longer to do this?

From a business perspective, the "fundamental bottleneck is always what's in your head" problem can always be solved by temporarily hiring a few super-smart consultants with "bigger heads" that can get over this bottleneck, the rare times when you have the problem...

The rest of the time, the "shape of your code" is 100x times more important than the abstract formulation of an elegant solution. Because what you do 99% of the time is "re-shaping" existing code to do slightly different versions of what it already does, not solving interesting problems...

So yeah, at this level, languages can make all the difference!

[tangled]

This is approach is great for greenfield development, but when it comes to software maintenance I find myself having to think in terms of the target language so that I can formulate the right long-term solution for the codebase in question.

[dkarapetyan]

Yes, this is true. For maintenance projects I've noticed that before I can sketch things out I have to translate the existing codebase into the proper abstract domain but in my experience this is just an extra step and does not negate the general approach of thinking in a domain that is completely free of programming language related issues.

[metaobject]

But depending on the language you intend to use, you may approach the problem from a different angle. A Lisp solution may look very different from a Python or C solution.

[sheepmullet]

The same is true in maths as well.

[sklogic]

A way from your formal specification of a solution down to a particular language set of features can be enormously long.

A trivial example can be translating a formal grammar - codified as just few lines of BNF - into a low level language (say, C, or Java). Good if your grammar can be expressed as recursive descent directly, and even in this case you'll end up spitting out hundreds of lines of code, most likely making a lot stupid mistakes.

So, language does matter a lot. BNF is a right language for this task. C or Java are not right, period. Programmers should not waste their precious time translating abstract concepts down to the boring languages minutiae - they must always use the same level of abstraction as their problem domain requires.

[vorg]

> I'm not really a programmer. All my training is in abstract math

Back in mainframe days, that training would've been the easiest way to get work as a programmer. Nowadays, much "programming" is gluing together pre-written open source stuff using glue languages like Bash, Javascript or Groovy by staff who entered programming as business people transferring from other departments then left a big mess for someone else to clean up when they used their embellished experience to get another job, probably with "architect" in its job title, somewhere else. If you've done any hobbyist stuff using something like Lisp or Haskell, then think twice before saying you're "not really" a programmer.

[gnaritas]

> and by necessity I have to disentangle the syntax of the language from the essence of the problem.

Doing that is why programmers prefer different languages, some language allow that to be easier than others do. Some language allow a much more direct expression of the essence of the problem.

> Adding macros and types just shifts how I encode the solution and in no way affects its abstract formulation.

Sure it does, it allows you express the abstract formulation more directly with less syntactic fluff. Ideally you wind up with a DSL that allows the problem to be solved as tersely yet readably as possible.

[Goladus]

In my experience, the more interesting reasons to choose languages come from the "platform and ecosystem" categories rather than syntax.

Lua: It has clean, clear syntax but its real value is the implementation, which is geared towards use as an embedded language.

Javascript: The language isn't bad but were it not for being the browser scripting language it never would have gotten so popular and tools like node.js probably wouldn't even exist.

Java: Native language on the powerful JVM.

C/C++: Direct access to various operating system and hardware libraries not available anywhere else.

Perl: Deployed widely on unix systems making it very useful for scripting and system administration.

SQL: For querying relational databases.

Granted, within each category, you might have syntax preferences. I would never use Ruby or Perl if I could use Python, for example. I prefer JSON for serialization(robust and simple) but for manually encoding a complex data structure, YAML is far more comfortable. That's all syntax. But picking the right language for a job usually requires going beyond the syntax.

[gnaritas]

> In my experience, the more interesting reasons to choose languages come from the "platform and ecosystem" categories rather than syntax.

I agree, but that doesn't have anything to do with what I said. I didn't say anything about choosing a language for a particular job, I said what makes programmers prefer a language which is very much syntax.

> Javascript: The language isn't bad but were it not for being the browser scripting language it never would have gotten so popular and tools like node.js probably wouldn't even exist.

If it were not for being the browser scripting language, it would not exist, so any reasoning beyond what it might have been otherwise is fallacious as it would not have been at all.

> Java: Native language on the powerful JVM.

Nope, portability across platforms made it popular.

> But picking the right language for a job usually requires going beyond the syntax.

Not disputed, but still unrelated to my point which is about syntax. I'm discussing syntax, it's off topic to and rude to tell me not to discuss syntax which is basically what you're doing.

[Goladus]

I was not attacking you. I just used your comments about syntax to make a point more relevant to the thread started here: https://news.ycombinator.com/item?id=10183420

[gnaritas]

No worries, I never said you were attacking me.

[Goladus]

> I'm not really a programmer.

The real question is do you understand how a computer works. There's mapping a solution into a programming language, but programming language is just a tool to help with the real goal which is to map the solution to the computer itself.

> The fundamental bottleneck is always what's in your head.

Expressing a correct solution in a programming language is just the first step. It also has to be performant, usable, and accessible. Language choice usually has implications in those categories.

[Scarblac]

This works for small programs you write on your own. Even then, the kind of problems you even try to solve in Matlab are different from the ones you try to solve in JavaScript.

But in business, you often program within some framework (which makes some things easy, other things hard), glue together tons of open source libraries (what's available in different languages differs a lot), and you work on huge codebases in teams (and different languages get in your way in different ways).

[pjmlp]

I have a good CS background and follow a similar approach.

We were lucky that back they excel in throwing all the paradigms at the students and have enough lectures about pure algorithms and data structures regardless of the language.