
What makes programming languages easy and why you want one that isn't - fiedzia
http://fiedzia.blogspot.com/2017/02/what-makes-programming-languages-easy.html
======
gh02t
So the author has a great point, that languages are suited to different
things. I like this.

What I don't like is the implied "only people doing stuff that _I_ think is
hard are _real_ programmers." The author seems to believe that people chose
"easy" languages because they are less skilled as a programmer (see the bit at
the end). Which is forgetting the original point, which is that languages all
have their strong points.

While it's true that I wouldn't trust someone trying to write an OS kernel in
Javascript, I also wouldn't trust someone writing a web page in Fortran.
There's a difference between hiding complexity when you need access to it
(what the post is complaining about) and unnecessarily inviting complexity.
Being able to understand when to choose between them is the real desirable
trait.

Edit: I'm also not sure how relying on the language to guarantee safety is
much different from relying on a complex beastie like a c++ compiler to be
correct.

~~~
fiedzia
> What I don't like is the implied "only people doing stuff that I think is
> hard are real programmers.

That's not exactly my what I want to say. My point is more like "You may not
see a point in becoming a soldier and its not a career for you, but be glad
that those who defend you have big guns, so stop complaining that they are
heavy".

> I'm also not sure how relying on the language to guarantee safety is much
> different from relying on a complex beastie like a c++ compiler to be
> correct.

Compiler are way more likely to be correct then people who use them. Problem
with C++ (that Rust is trying to solve) is that the correctness of the
compiler does not translate to correctness of compiled code, just as
correctness of your text editor does not guarantee that you won't make typos,
if it doesn't provide spellchecker. (I really like this analogy)

~~~
skybrian
> You may not see a point in becoming a soldier

You might want to try saying that a different way; this metaphor is a problem.

It comes across as a slightly more colorful way of putting down people who use
other languages as not "real" programmers - you're saying they should find
another career. Or at best, maybe they are real programmers but they should be
using harder languages?

In practice, most of the important code that everyone relies on to defend us
(assuming here you mean security-critical or safety-critical code) is not
written in Rust. So who are the real "soldiers"?

There's certainly a case to be made for using safer languages for critical
code. On the other hand, using stricter static analysis for existing languages
(and other kinds of testing like fuzz testing) will find bugs quicker and
avoids boiling a few oceans.

~~~
fiedzia
> It comes across as a slightly more colorful way of putting down people who
> use other languages as not "real" programmers

This is not my intention.

> In practice, most of the important code that everyone relies on to defend us
> (assuming here you mean security-critical or safety-critical code) is not
> written in Rust. So who are the real "soldiers"?

Rust is relatively new. The real soldiers who use C bravely fight with of-by-
one errors and buffer overruns and I really don't want them to do that.

> There's certainly a case to be made for using safer languages for critical
> code.

We can afford using safer languages for a lot of code.

> On the other hand, using stricter static analysis for existing languages
> (and other kinds of testing like fuzz testing) will find bugs quicker and
> avoids boiling a few oceans.

No, it will not. It may find few bugs here and there, but will leave whole
classes of problems untouched. You can't bolt security onto a language. And we
do not want to find few bugs, we want to be sure they are not there.

------
tylerhou
Why can't we accept that programming languages are just tools and we should
pick the best one for the job?

If I'm only going to run a script every few months and high performance isn't
necessary, why should I pick a "hard" language like C rather than a scripting
language like Python? The same holds true conversely; I don't want to use
Python for code that has to run close to the metal.

Furthermore, if I need to iterate quickly, I wouldn't use something like C
where there are too few abstractions for me to program at a quick-enough rate.
If I work at a company like Google I presumably have enough money to buy all
the computing power I should need, so performance of the code isn't as
important as developer time. Or, if I'm prototyping some software and I want
to work out the kinks in the architecture, why should I spend more time
programming in C than just throwing together a quick solution in Python?

Something else:

>If you do _anything_ I am relying on, I do not want to hear that you use such
"easy" language, period. If you are careless enough to rely on people not
making mistakes, I do not want to deal with you.

Most mature, high level ("easy") languages are relatively bug free for most
use cases. Even if you're using a "hard" language, you're still relying on
other people not making mistakes---whoever made your compiler, whoever made
the processor and hardware your machine code is running on. Are you to say
that you don't even want to deal with yourself?

~~~
slavapestov
> If I work at a company like Google I presumably have enough money to buy all
> the computing power I should need, so performance of the code isn't as
> important as developer time.

Google and other big cloud shops care a lot about energy usage actually, and
contrary to popular belief many server-side applications are CPU and memory-
usage bound.

Energy consumption is important on mobile as well.

~~~
fiedzia
> Google and other big cloud shops care a lot about energy usage actually,

Indeed they do. If you have one server, or a 100, doubling that is not a
problem. If you are Google, doubling your energy use requires finding new
country to provide it.

------
tormeh
The problem is that for small projects you want a permissive language. For big
projects you want a restrictive one. Since projects are generally written
according to the "worse is better" school of thought it's better for a
language to make it quick to get going with a small project than easy to
maintain a huge one.

~~~
fiedzia
> The problem is that for small projects you want a permissive language. For
> big projects you want a restrictive one.

I'd say that the important factor is the cost of a bug, not project size.
There are many small project that absolutely crucial to get right, as well as
some large ones that are not. I do not have a problem with people choosing
what they need, only with the fact that (sometimes superficial) simplicity
becomes the only factor in this decision.

------
pvg
If one of the bins has criteria like 'performance' and 'complexity, how do
Java and Python both end up in it? This seems in the 'not even wrong' category
to me but perhaps I wasn't able to follow the argument.

~~~
fiedzia
Both hide memory management from you. Which works great until it doesn't.

~~~
pvg
Yeah but you tie it to performance which, other than in specialized cases, is
not really a limiting factor - i.e. the performance spectrum of python, js,
go, Java. And why aren't js and go in that category? Having read the comments
here, was this post intended as some kind of veiled bit of Rust advocacy? Not
that there is anything wrong with that per se, I'm just trying to understand
what you're on about to better inform you how you are wrong on the internet :)

~~~
fiedzia
Not advocacy per se, but undeserved bashing (and not just Rust - you may
replace it anything that's non trivial for beginners). This is some response
for posts saying "Rust is bad because I'cant get past compiler errors, while
some other language will not complain at all, and that should be fixed".

------
thinkpad20
> If you do _anything_ I am relying on, I do not want to hear that you use
> such "easy" language, period. If you are careless enough to rely on people
> not making mistakes, I do not want to deal with you. And if I am working on
> ensuring high reliability, I will choose tools that provide as much
> guarantees as possible, artificial simplicity be damned.

This to me is a bit absurd. First of all, the "easy" language he's referring
to here is C, and if I read this correctly it sounds like he's saying any
software written in C is not worth using, which is patently absurd.

Regardless of whether that's actually his viewpoint, programs and libraries
which are well-written, in any language, are simply tools which one can use
without needing to worry about what language they're implemented in or whether
or not the author used generics or pointers or whatever. Language matters if
you're writing the code, reading it, or linking against it, and otherwise it's
not worth worrying about (as a general rule). Of course, if the tool or
library in question is slow or resource intensive, this might be due to
language choice, but poorly written, buggy, and underfeatured code can be
written in any language. Choose the language that suits you, suits your team,
and suits your project.

~~~
fiedzia
> he's saying any software written in C is not worth using, which is patently
> absurd.

I'm saying that choosing C guarantees a lot of problems for users. You will
have such amount of bugs, that as a user, I refuse to be your beta-tester.

> programs and libraries which are well-written, in any language, are simply
> tools

Some languages make creating well-written program much harder than others.
There is strong correlation between "its written in C" and "it exposes your
ssh keys".

> Language matters if you're writing the code, reading it, or linking against
> it, and otherwise it's not worth worrying about

It also matters when you estimate code quality and likelihood of your data
being exposed or corrupted or a time from "it compiles" to "we feel safe to
use it in production". Its not the only factor, and perhaps not the most
important one in many cases, but I believe in value of formal verification
more then I believe in humans ability to get millions of malloc/free pairs
right.

> poorly written, buggy, and underfeatured code can be written in any language

Again, in theory yes, in practice some languages make it much easier than
others.

------
tluyben2
What is it with all the language picking and language wars? Maybe I just grew
up in a good learning environment because I had to, computers were simply not
fast and had very little memory; on my first home computer it only had built-
in Basic so I started with that, but it was slow, so went to assembly but that
was annoying for anything but games so went to Pascal and later C but that was
annoying for business software, so I went to DBase/Clipper etc etc. I would
say that 'a good programmer' is not that bothered by switching languages when
it is the right thing to do for the job at hand. Whatever language that is,
easy or hard is not very interesting in my opinion and experience.

Like I said in another thread; I picked C# for a project because the software
needs to run in banks and deal with bank IT departments. That's Java/.NET and,
because we needed apps as well and we were already proficient in Xamarin, we
chose C#.NET. Not because I like the language (I do, especially for later
versions) or think it is hard or easy, but because it fitted.

We wrote a prototype in Python before that and the first bank we worked with
had the CTO looking very puzzled and then, after some research on their side,
said they cannot have that in their infrastructure; Windows servers with
Java/.NET they had. And the IT staff to manage that, not other 'esoteric'
stuff. However, already before that, we started rewriting that prototype to
C#, this was just an extra sign we did the right thing.

I do a lot of coding in PHP ; not because I particularly like it, but my
clients ask for it, I have 100s of 1000s of lines of legacy code in it going
back the end 90s. For my embedded work I would not (and cannot) use either
C#/PHP so I would not try; assembly or C/C++ (or a Java subset).

Programming languages are tools; they are fun to play around with, but when
doing real work (which includes side project), just pick something you can get
shit done with the fastest/best (some balance between those) (that can be
Haskell, Coq or Prolog as well; they do not have to be 'traditional'
languages).

~~~
fiedzia
> but when doing real work (which includes side project), just pick something
> you can get shit done with the fastest/best (some balance between those).

This is where I disagree. If you do that, you are trading quality for your
convenience, and as (potentially) your user, I do want you to work harder.

~~~
matt_wulfeck
But users almost _never_ care about the underlying technology. In my
experience they care about usability above all else. Most the time they have
no clue what's powering the other side and that's by design.

I think the GP and yourself have different values. I don't want to speak for
him/her but I think I can relate: don't allow perfect to be the enemy of good.

~~~
fiedzia
> But users almost never care about the underlying technology.

I guess it heavily depends on who are you working with. If your users don't
understand and don't require security, it will not be provided. My users often
have customers who care about those things, so it goes back to me.

------
BigJono
I don't have a lot of experience with a ton of different languages. But it
seems bizarre to me that he lists Javascript as an example of a language that
is restricted and unable to do various things.

I have never once run into a problem that isn't easily solvable with
Javascript. If anything I find it has the opposite problem, there's too many
different ways to do particular things and unless others are using the same
"subset" of the language that you are, their code becomes extraordinarily
difficult to grok.

~~~
fiedzia
> it seems bizarre to me that he lists Javascript as an example of a language
> that is restricted and unable to do various things.

* No exceptions (practically) * no built-on ways of providing abstractions * No concurrency at all for a very long time * No way of dealing with binary data

Those things were added later (classes, webworkers, arrays) when they became
absolutely necessary. But it started and lived for a very long time as very
minimal language.

> I have never once run into a problem that isn't easily solvable with
> Javascript.

Swallowing errors. Code quality. Solvable with typescript and others, but I
wouldn't call it "easily sovlable".

~~~
inimino
If you think JavaScript didn't have ways of providing abstractions until
classes were added, you don't know JavaScript.

------
xiaq
> 1\. Restrict what language can do. Without pointers, you won't have to
> explain what pointers are and won't have to introduce complex mechanism to
> deal with them.

Pointers are not complex, and pointer operations are not complicated. They are
difficult for human to understand, but pointers are a most basic thing to CPU.

If your language doesn't have pointers, it almost certainly has references. At
least for machines, pointers are simpler.

~~~
fiedzia
> Pointers are not complex, and pointer operations are not complicated.

That's the understanding of simplicity I am fighting with. Yes, concept is
simple. Getting it right in any non-trivial code is nearly impossible (without
some form of verification).

------
threatofrain
Programming languages are hard based on how many independent concerns they
want the programmer to juggle in their communication with the compiler.

Hopefully every single burden the language has its user juggle is one which
provides good tradeoff, but generally people value performance, safety,
ergonomics, and maintainability.

------
drtz
> 3\. Give the developers ultimate freedom and let them do whatever they want.
> If the compiler never complains, beginners are happy... Example: C.

This leaves me wondering how the author would classify assembly or machine
code.

~~~
fiedzia
> This leaves me wondering how the author would classify assembly or machine
> code.

If you want to go in this direction, I'd suggest writing 1's and 0's. Can't go
wrong there :-)

Btw, I actually am writing some assembly. So far I've found it very permissive
(and that bit me hard).

~~~
thinkpad20
> I actually am writing some assembly. So far I've found it very permissive

Were you expecting otherwise?

~~~
fiedzia
I didn't have much expectations, as I am doing it first time. But yes, I was
hoping for a bit more hand-holding from asm utils. I've set wrong asm dialect
and nothing detected that. Not the kind of friendliness I like.

~~~
lowmagnet
I think assemblers won't have that sort of protection because they don't
assume you're going to run on the same arch as your build.

~~~
fiedzia
It wasn't different then the one I was running on, it was different then I had
code for. And it compiled. So either asm dialects have subtle differences that
change semantics but not form, or asm silently ignores errors.

------
ekvintroj
Just one thing: consistency. It's a shame that the author didn't mention
Smalltalk.

~~~
fiedzia
I don't have experience with it. I see a point in consistency as an important
factor here though.

------
novia
Your post had three spelling errors in it before the end of #1, so that's
where I stopped reading.

~~~
dang
Please don't post rude, unsubstantive comments to HN.

This is an international site. We're fortunate that non-native English
speakers take the trouble to share their thoughts with us here. How many of us
could read them if they didn't?

~~~
novia
My apologies to fiedzia. I did not realize you were a non-native English
speaker.

