Why I have no favorite programming language | Hacker News Reader

Why I have no favorite programming language

ilya-sher.org

58 pointsilyash58 comments

Interesting points. As a long-time sysadmin; a big fan of Bash, Ruby, and Go; and a bemused observer of "we need to replace the shell!" manifestos like this one, I have long believed that the low-friction of system-level interaction you get from Bash is inextricably linked with its contradictory, confusing, and error-prone syntax. You can't have one without the other. Ruby is one step up the chain. Still easy to get going on a project, much cleaner syntax and more consistent behavior, but the abstraction separates you just enough from the OS that it's no longer trivial to interact with files, processes, and pipes, and instead there has to be an API. Then a language like Go, carefully designed to be as self-consistent and predictable as possible, but the trade-offs are enforced error handling, higher LOCs-to-functionality ratio, and the compilation cycle, and now interacting with OS-level abstractions like files and pipes becomes a major chore, not a magical puzzle of joy like Bash sometimes feels like.

I wish the author good luck with his NGS, but I don't think it's possible to make something as direct as Bash that has all the other features the author wants. But more power to him for trying.

Although, looking at the Github page, I get the impression the author is writing software to automate AWS deployments after getting fed up with Terraform and CM tools, rather than a Better Shell Language. Maybe it's both, but the 100% AWS example code does not remotely appeal to this AWS sysadmin.

When the replacement of bash comes it will seem like a complete 'no-brainer'. In my opinion what should be happening is they should completely decouple the engineering from the interactive shell. The shell should just be a series of aliases and shorthands translating into something more robust.

But I also think they should move away from plain text for everything as well. Almost everything in a unix system could be better served with some kind of standard system of typing. Config files, program inputs (give universal tab completion) ... etc.

So I tried powershell and found it to be terrible. It seems like the implementation is killing the idea, stack traces all over the place - rather than helpful errors - and different types for file system objects (I cannot quite remember exactly what) making it hard to combine operations.

Perhaps it seems superficial, but one of the reasons I don't like PowerShell is because the language is ugly.

There is something about using capital letters for commands that really bothers me. It may be an OCD thing, bc I use lower-case snake_case for all variable/class names in Lisp, C, C++, and Python.

I don't usually do any work on Windows, but when something came up where some scripting had to be done, I just installed the Cygwin and was done with it.

> Almost everything in a unix system could be better served with some kind of standard system of typing.

Lightly typed data (like strings you must parse) is more future proof at the expense of leaving more potential for bugs (escaping whitespace).

Strongly typing requires the shell designers to provide more opinions. More opinions provide more opportunities to be wrong about what needs we will have in the future decades.

It sounds to me like you would be happy with a python3 REPL that automatically 'import's certain libraries. I don't know if it is possible to configure the REPL like that, but you could probably script it!

That's possible with a PYTHONSTARTUP file.

https://docs.python.org/3.6/using/cmdline.html#envvar-PYTHON...

I actually worked with someone who did exactly this: they replaced their bash shell with the python shell. It took them a year to get it comfortably working, and they were constantly tweaking on it, but it did work.

Some tasks were harder, some easier, but it was all quite entertaining to see.

> Bash is inextricably linked with its contradictory, confusing, and error-prone syntax. You can't have one without the other. Ruby is one step up the chain.... Then a language like Go...

To be fair, this is use case for shared libraries. I've not dabbled much in Ruby or Go, but in Python there are terrific libraries for handling filesystems, sockets, HTTP request, etc. Most of them (e.g. Requests) have terrific 'Pythonic' interfaces, one doesn't even feel that he's left Python for some decades-old legacy interface.

That is certainly one of Python's strong points, at least from my perspective. I haven't touched much code in a number of years, as I've had no reason to, but Python keeps tempting me.

While generally a horrible idea, I can start a simple http server with a simple one-line command from the terminal. Yeah, it's probably not smart - but I find myself using simple things like that more and more often - and I'm just a retiree with a small home network.

If anything draws me back into programming, it's going to be Python or Java.

Have you met our lord and savior, Ammonite Shell on Scala? http://ammonite.io/#Ammonite-Shell

It has same terse syntax as bash but much more structured (and easy to add more) because language is powerful. The downside is its slow, but that might have changed already with Scala Native.

The key is it is full scala with some extra niceties that do the stuff bash does. So you get full power of a programming language, extended down to do stuff bash does. Better approach IMO than extending a shell "up" to more and more expressive power towards a quirky programming language.

The author has opinions on a number of projects in this space including Ammonite.

https://github.com/ilyash/ngs#have-you-heard-of-project-x-ho...

> I don't think any amount of tinkering with existing languages (maybe except a lot of it with Lisp) can make these languages as usable for shell as new language that was specifically designed to be a shell language.

I really am hoping that Lisp and specifically Racket can become the tool for the DSL since that is what they do really well.

He starts creating a new language based on complaints about 5 common languages. IMHO, he should start by understanding why so many people are fond of these 5 languages and why they were so successful. Then, he should understand that people do not only have different tastes, but also different way of thinking that may imply different style of programming. A good language is often a compromise between different requirements.

Personally, I start with bash for very trivial tasks. As soon as there is data to manipulate, I switch to perl. If program gets bigger and needs to be split into modules or classes, I switch to python (I am less fluent in ruby and go). Sometimes I switch to python earlier because of some libraries. If the program gets more bigger, needs to be maintained or suffers from slowness, I switch to java. My favorite language is perl, but I use the one that fits best.

If performance is your issue then use RPerl with your existing code.

For more info, see http://rperl.org/performance_benchmarks_nbody.html

Interesting. I also start in bash. I then move to sed|awk|bash (extremely powerful). Then I move to TCL or Python. Then I move to swig libraries for either language. Maybe C or intel asm if I miscalculate the problem. But I sometimes move to C first if speed is the issue and I have reusable code for the problem available.

> Inconvenient/verbose work with files and processes. Yes, there are libraries for that but there is no syntax for that

Why would a language concern itself with files and processes? This is precisely why libraries are for. And with languages like Ruby, you can pretty much make the syntax.

> I would like to fill the gap

Every time we decide the solution to a problem is a new language, we end up with two problems. There are valid reasons to invent new languages, but such a narrow domain-specific problem is not one of them.

I really don't understand his critique on python. Being able to do functional programming is still great. He doesn't have a lot to say about python.

To be honest, python is just the greatest thing ever. It's not penetrating well because there is no money behind it like java or go. Like I said, if there was as much money spent on python that there is on js, it would be just great.

Creating a good enough programming language is very hard because it requires experience in engineering and all the compromises it entails, and it also requires not trivial compsci skills. Creating a maintaining a language is hard.

I love your enthusiasm. I agree with the points about functional programming in Python though.

Help me fix this line: https://github.com/kurocha/tagged-format/blob/283d9bb1c91768...

In Ruby it would be

    output.puts "\t\t#{vertex.join(' ')}"

What to fix about it? Looks good to me.

You could use f-strings (introduced in Python 3.6) to get rid of the `.format(`. https://www.python.org/dev/peps/pep-0498/

The `[str(value) for value in flatten(vertex)]` part is missing in your Ruby. I assume that happens in some method of the vertex? You could make your vertex iterable as well.

Python philosophy prevents you from getting rid of the `str(x) for x in v` because "explicit is better than implicit", so join will not auto-convert stuff into strings.

Since you like map, you could shorten it a bit by doing

    map(str, flatten(vertex))

instead of the list comprehension.

Only suggestion I have is not to build a list explicitly: .join(str(value) for ...)

My first suggestion would be to add a line break after format( , remove the [ ] and rename the loop variable to a single letter.

    output.write("\t\t{0}\n".format(
                 " ".join(str(x) for x in flatten(vertex))))

But it looks like your core problem is that try you force another language's idioms onto python.

Your flatten function could be a lot simpler (and without quadratic runtime):

    import itertools
    def flat(l):
        return itertools.chain.from_iterable(
            flat(e) if isinstance(e, (list, tuple)) else [e]
            for e in l
        )

But that is still not what you actually want – you only wrote this function because you have it in ruby. What you actually want is:

    def format_vertex(lst):
        return " ".join(
            format_vertex(e) if isinstance(e, (list, tuple)) else str(e)
            for e in lst
        )
    output.write("\t\t{}\n".format(format_vertex(vertex))

Python will be the greatest thing ever when it takes the up the lessons from Smalltalk, Dylan and Lisp, and actually produces fast code, with AOT as an option.

Maybe some day PyPy will be it.

The problem is it is clear Guido doesn't like functional programming -- his official statement is that "filter and map should die and be subsumed into list comprehensions". Yes, list comprehensions can do many of the things you can do with map/filter/reduce, but in a way where the functional idiom is obscured and one which is not easily converted to and from other languages.

Guido may dislike many things, but filter and map are still there, so what's the problem?

Sounds like that guy needs to check out Powershell.

It has a lot of the missing features that bash is missing according to the author and is a very underrated scripting language.

It has support for linux and you may write Cmdlets in Python or other languages for that matter.

The guy already checked out Powershell: https://github.com/ilyash/ngs#have-you-heard-of-project-x-ho...

Well several items on his list is incorrect so I don't believe he has tried it that much tbh :)

I don't have a favourite too, but it happened to be that I know to most about the one I work with every day.

I'm really happy with using F# to write true microservices using the Unix Philosophy.

F# makes me learn to be a better programmer and it's fun, so there's that. Coding using the Unix Philosophy gives me all the goodness that the author seems to want, all without having to install yet another shell. The only pieces of the bash shell I'm developing are the pieces that help solve the problem in front of me. Everything else is stuff that the next guy can't pick up off the web.

I don't like being a fanboy. Maybe next year I'll start playing around with Haskell. But rewriting/replacing the shell? E-gads. You'd have to make a tremendously better case than this author does. (Insert long discussion here about tools, frameworks, and bad coding discipline)

> The Sigils syntax does not resonate with me.

I'm a Perl fan and I have to say that sigils should go. Or at least become optional.

Most of the times it's just one character too many.

Say you want to write an anonymous function with three arguments like f(a,b,c) = a+b c

In Perl (either 5 or 6), you could for instance write :

    sub ($a, $b, $c) { $a+$b*$c }

It's not that long, but each "$" is kind of a visual stain that beclouds the variable name.

To me, it would make sense for instance that read-only variables would have no sigil. It's already the case in Perl 6 for constant, since you can write :

    constant pi = 355/113;

but if you want sigilless parameter names, you have to use a backslash :

    sub (\a, \b, \c) { a+b*c }

which is quite ugly.

Just make the sigils optional already.

"Compiled" as a negative side? Really? Compiler is my best friend, and that's why I don't like interpreted languages - you have to (mostly) actually run all the code paths to make sure they're correct.

Being a polyglot developer is a very wise way to go. Languages are like different tools, and each job has an appropriate tool -- trying to use one language for everything is like trying to fix everything with a hammer.

Call me crazy but I love Bash. At my first programming job I spent months working on Ansible scripts to get a deployment project going. In hindsight, Bash would have been far more effective (for me). I eventually ended up provisioning all my own systems with shell scripts.

Relevant project: https://github.com/ryanpcmcquen/config-o-matic

I highly encourage this kind of experimentation!

Unix has a long tradition of neat little languages that make system programming easier... but none of them is all that good.

I planned to make a language like this myself, and still do, in the back of my mind. Ever since running into Nix and NixOS, I've felt that I have to integrate that worldview into the hypothetical language/shell design. Not sure how.

Funny there's no mention of Powershell, wonder if he knows about it.

Even if just to learn from them what they did wrong.

> Funny there's no mention of Powershell,

There is, https://github.com/ilyash/ngs#have-you-heard-of-project-x-ho...

> what they did wrong.

Syntax and overall feeling when using the language among other things.

Would love to hear the author's opinion on node with async/await? I sometimes use it for sysadmin tasks, and it's quite enjoyable. Mostly due to the great ecosystem. ES is certainly not made for sysadmin tasks, but I prefer it over go/python/Ruby/Perl.

Hi.

> async/await

Callbacks, promises and async do not resonate with me at all. I find them inconvenient.

In addition, my recent trauma is changing functions from sync to async (promises) in Node.js. We had to do it because the functionality of these functions changed. You have to change all the callers ... and their callers and so forth.

I really prefer top-to-bottom execution.

> Mostly due to the great ecosystem.

You mean available npm packages?

> ES is certainly not made for sysadmin tasks

Yep, that's why it was not mentioned in the post.

TL;DR: OP hasn't tried haskell yet ;p

Neither Perl 6.

I'm programming-language-curious. I tried Haskell and read a lot about perl6.

Haskell melts my brain. Maybe it's getting better later, I tried about 3 days.

perl6 - sigils are still there (even more of them) and overall feeling is not that different from perl5 despite such great improvements as named function parameters :)

I know you're joking, but I would really like to have the Haskell type system in my shell with suitably-typed versions of the standard utilities: sed, awk, grep, etc.

I tried asking #haskell on freenode about "using ghci as a shell" and everybody thought it was a horrible idea. Oh well :(

If what most people thought were always the way taken we wouldn't have any of the great things we have today. In other words: try using it as a shell anyway, write the needed pieces of infrastructure, and share the results! :)

(There are people who've done work in this direction, but none of them haven't broken out to any significant amount of followers.)

Thanks for the encouragement! For those at all interested, some of the existing tools/libs in this arena are

    * shelly [1],
    * turtle [2], and
    * hell [3].

I currently don't have much Haskell experience, but I do keep a ghci session open, hoping that the frustrations of using it as a shell push me to both learn and create.

[1] https://hackage.haskell.org/package/shelly

[2] https://hackage.haskell.org/package/turtle

[3] https://hackage.haskell.org/package/hell

ilyash, I think you should see if http://www.oilshell.org/ might be worth your time. (not the author, but I respect it's goals)

I hate them all equally.

I immediately think of the very relevant XKCD about standards https://xkcd.com/927/

Over my career as a developer I've learned to just embrace whatever I'm working on. Soon enough I learn the peculiarities of the language and framework, and I'm productive. Most of the time the productivity gain from the perfect language and/or framework is minor, compared to the time I spend thinking about a solution.

Personally I'd just select a reasonably available tech, say F#, and use that if I want to write my scripts in a functional way. Over time you make your own library of useful functionality, and you don't have to fight your way around the language because you get to know it well.

I came here to repost that XKCD if nobody else had yet.

This is exactly why Powershell was invented - a desire to Replace the Shell with something Object-Oriented. Powershell passes .NET objects from function to function through the pipeline, instead of passing simply strings. (Sometimes the objects are strings, but not always).

No haskell where embedded DSLs shine. He can implement his "ideas" easily there and then proudly present them to the world.

Basically, he didn't do due diligence in PL. ;)

well, i do like go ...

While I do sometimes wish Python was even more functional, I don't understand why the author mentions map and filter when those are actually still built in. If you like map and filter then just use them. The lack of a built in identity, compose and reduce is annoying, though.

He said they were second class citizens not that they didn't exist. They're slower than list comprehension. There was a performance question on SO I remember where the comprehension was 1 or 2 orders of magnitude faster.

Edit: Guido wanted to do away with all of map, filter, reduce and lambda in Python 3 [0]

[0]: http://www.artima.com/weblogs/viewpost.jsp?thread=98196

There was a performance question on SO I remember where the comprehension was 1 or 2 orders of magnitude faster.

That sounds really really weird. The worst I've seen is maybe a factor of 3-4 in some corner cases, largely related to how python does lambdas.

Can you find a source for the performance difference? I can't imagine why they would be different.

To me it sounds like a DSL created by much more powerful language would be really better than a completely separate prog. language. But if he wants to do it why not. It's just at some point a programming language per se will be used / abused to do much more than it was designed for. And that is why even to this day we can see a lot of bash "web","automation" code glued together in the wild.

>To me it sounds like a DSL created by much more powerful language would be really better than a completely separate prog. language.

Yeah, isn't that the problem that Lisp macros have been the solution to for decades now?

Garbage feedback from a prima-donna. Yay: I can't code in your crap because it's 2017 bro. Twitwit nonsense.

Reply on news.ycombinator.com