
My 2019 programming language hierarchy - SIRHAMY
https://labs.iamhamy.xyz/posts/2019-programming-language-hierarchy/
======
zoom6628
Mostly agree. My go to language is python. Used c# in last job and it improved
much over past few years.

When I need blinding speed I can use nuitka to compile python scripts.

On the rare occasions needing speed and cross platform coupled with my lessons
to avoid wasted effort I turn to Lazarus/fpc because code is simple and
Lazarus takes care of the target platform stuff so I don't have to.

For IOT bare-metal stuff you can't go past C. It just works and after learning
it's quirks you will see how other IOT tools are largely hacks or compromises
to avoid learning C.

~~~
caseymarquis
<rant> I think you're right that there's no viable alternative to C for IOT
right now. However, I also think we need to collectively move past C in this
space. The compile, run, debug cycle in embedded electronics is just too slow.
I don't really mind the language, just the painfully slow development (and
lack of package management). uPython and similar are a move in the right
direction, but I think we need a minimalist crossplatform bytecode runtime to
become standard on every popular embedded platform. This runtime needs
frictionless c FFI (with the ability to seemlessly drop into c at any point,
though it may require a recompile), and to be designed with embedded in mind.
Actors and RPC should be first class citizens, as should remote inspection of
systems over the wire, hotswapping running code, and the security needed to do
those things safely (easy to get started with automatic self signed
encryption). I think that every attempt at doing this so far is focusing on
creating hobbyist boards for people who don't want to learn c instead of
creating this ideal runtime with seemless c ffi (allowing easy adoption on new
platforms), or is not lightweight enough to run on $4 chips like the ESP32. I
think that most likely this platform will need to be written in c, and provide
simple hooks for tying the networking libraries for individual boards
together.

I was looking into building this for something my company needs, but then a
Taiwanese company approached me about a low cost industrial modular linux
device with hotswappable i/o they're developing. At this point I just shrugged
and figured that seemed a lot easier than building a better wheel.

The thing is, I can use a $400 modular linux device because my market can bear
it, but I was looking at developing the other set of features for inexpensive
micros. Virtually every market can bear the cost of a $4 chip. </rant>

I apologize for the rant, it just physically pains me that this doesn't exist,
and that embedded development is so primitive.

~~~
bluesnowmonkey
Actors, RPC, remote inspection, hot swapping, you're talking about Nerves
right?

[https://nerves-project.org/](https://nerves-project.org/)

~~~
caseymarquis
Nerves is too resource intensive, but that's the right idea. AtomVM is closer
to what I'm thinking, except ideally I want static typing that's interoperable
with C, and the readme for the project would be something like: Here is a
bunch of C code with some functions you need to fill in. Compile these two
files for your device, and fill in all of the second file's function bodies.
We maintain versions of the second file for common boards. If you add a c
function to the second file, our tooling allows you to call it from the
runtime.

C FFI is really critical, as that allows you to use all the existing libraries
on a given platform.

So, a runtime language with elixir/erlang features, but with the C FFI of Nim.
But Nim is compiled, and we need bytecode for rapid iteration.

The challenge is that what is nearly universal right now is a c compiler, but
the board is always different. S7 scheme has the right idea with a single c
file, but is too resource intensive and wasn't built for embedded electronics.

There is definitely an unfilled niche for rapid embedded application
development. We're either going to get a $4 RPi in a chip someday, or the
platform I'm describing needs to be created. Those are the routes I see to
embedded RAD.

------
c3534l
Are we doing Tier-Lists on HackerNews now?

    
    
        S Haskell, Rust
        A Python, C, Go, Julia
        B Prolog, Assembly
        C C#, Java, C++, Scala, ML
        D Ruby, Groovy, R
        F LISP, XML, Bash, VB

~~~
forrestthewoods
I like your list.

Where do you put JavaScript? For me it’s an F.

Python I think needs a distinction. It’s an A for small projects that can be
owned by a single person. But a C for projects large enough to warrant
multiple developers. Dynamic languages don’t scale without a huge amount of
extra tooling.

The Python ecosystem gets a B. But the environment gets a D.
[https://xkcd.com/1987/](https://xkcd.com/1987/)

~~~
m45t3r
Python can easily get a B for large projects if you use something like mypy.
However sure, where the language really shines is as a substitute for scripts,
so smallish pieces of code.

And environment... It is complicated. It is not that it is that bad, however
it sure lacks some polish. The solution is not easy either since even if you
solved the problem today (like using poetry), there is still the whole
backwards compatibility problem.

There is various hacks to make things easier, however in the end the problem
is still more complicated than it should.

~~~
zmmmmm
> Python can easily get a B for large projects if you use something like mypy

I'm curious if that's actually true - my actual experience is that it actually
suffers horribly in large projects because as the size and complexity goes up
it's just harder and harder for its heuristics to not produce false positive
typing errors. It worked great on a small library where it could see the whole
source and everything was well annotated ... but that's sort of the context
where it is least needed in the first place ...

~~~
m45t3r
Well, Instagram [1] and Dropbox [2] are probably the biggest Python projects
in the whole world, and they both are using mypy and seem to be successful.

And my particular experience with it is very positive, even if my project that
is using it is still small (it is getting bigger though, and mypy is really
helping me to refactor it when I needed).

Most of the "false positives" that mypy reports to me end up being code that
is overly cleverly, and rewriting it to make mypy happy also improves the code
quality.

[1]: [https://developers.facebook.com/videos/f8-2018/type-
checked-...](https://developers.facebook.com/videos/f8-2018/type-checked-
python-at-instagram/)

[2]: [https://blogs.dropbox.com/tech/2019/09/our-journey-to-
type-c...](https://blogs.dropbox.com/tech/2019/09/our-journey-to-type-
checking-4-million-lines-of-python/)

------
BuckRogers
Nice list, I enjoyed it, and agreed on C#. I'm over my Python phase, I
wouldn't use it for anything today for many reasons. Also agreed on Rust, the
way I put it is that it's the "best programming language that I'll never use".

I haven't met a programming language that I hated, and find them all pretty
similar. My ranking criteria is different as a result. Top metric is "keeping
the lights on", then my second metric is what it enables me to (easily) do. My
main technical requirement is that it has good tooling, well-supported (no
breaking versions), and is fast, because software always gets extended and
ends up longer lived than first intending.

I'm originally from a small city, and may one day return. C#/Java let me keep
the lights on for decades going forward in any locale. I also don't have any
complaints with those languages and their chosen abstraction layer, which I
think Java nailed for most business applications in the 90s and the target
hasn't been better hit since.

------
IshKebab
> [Python is] fast enough for almost everything

That's a bold statement. Also I feel like he's missing a few cons for Python:

* The 2/3 mess (yes it is still a thing)

* The insane packaging situation. Packaging a Python app is a nightmare.

* Dynamically typed

And some extra cons for Javascript:

* The insane prototype system

* Basic things are broken and have never been fixed: ===, type coercion, still no 64-bit integers as far as I know.

* Dynamically typed

> Assembly: Too low-level. V verbose. Kinda confusing. I choose Python.

Lol when would your two options ever be assembly or _Python_??

Not a bad list though.

~~~
Rotareti
_> The 2/3 mess (yes it is still a thing)_

It's still a thing for the (loud) few who couldn't manage to move to 3 after
10 years. The rest just went on. The ecosystem is on 3 [0] and it has been for
years now.

[0]: [http://py3readiness.org/](http://py3readiness.org/)

 _> The insane packaging situation. Packaging a Python app is a nightmare._

The packaging story in Python is in the middle of a big transformation from
legacy tools to modern npm/yarn/cargo-like tools. pipenv [1] and poetry [2]
are the most popular contenders. It will take a while until the community
settles on this, but both tools work already.

[1]: [https://github.com/pypa/pipenv](https://github.com/pypa/pipenv)

[2]:
[https://github.com/sdispater/poetry](https://github.com/sdispater/poetry)

 _> Dynamically typed_

Python 3.5 introduced type annotations. It is now possible to write statically
typed code in Python via mypy [3], which from my experience works similar well
as TypeScript works for JavaScript.

[3]: [https://github.com/python/mypy](https://github.com/python/mypy)

------
lostmsu
I am the same, but with Python and C# flipped, as my projects usually grow
waaay beyond what can be comfortably sustained with Python. IMHO, refactoring
tools are nice to have for anything beyond 1,000 lines, and a must for
anything beyond 10,000.

