> 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.
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).
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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]
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.
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.
"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.
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)
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.
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'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 :
62 comments
[ 2.4 ms ] story [ 102 ms ] threadWhy 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.
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.
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.
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).
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.
https://github.com/ilyash/ngs#have-you-heard-of-project-x-ho...
I really am hoping that Lisp and specifically Racket can become the tool for the DSL since that is what they do really well.
Yeah, isn't that the problem that Lisp macros have been the solution to for decades now?
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.
Help me fix this line: https://github.com/kurocha/tagged-format/blob/283d9bb1c91768...
In Ruby it would be
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.
Your flatten function could be a lot simpler (and without quadratic runtime):
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:Maybe some day PyPy will be it.
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.
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 tried asking #haskell on freenode about "using ghci as a shell" and everybody thought it was a horrible idea. Oh well :(
(There are people who've done work in this direction, but none of them haven't broken out to any significant amount of followers.)
[1] https://hackage.haskell.org/package/shelly
[2] https://hackage.haskell.org/package/turtle
[3] https://hackage.haskell.org/package/hell
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.
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.
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.
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.
https://docs.python.org/3.6/using/cmdline.html#envvar-PYTHON...
Some tasks were harder, some easier, but it was all quite entertaining to see.
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.
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.
Even if just to learn from them what they did wrong.
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.
Basically, he didn't do due diligence in PL. ;)
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
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.
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.
For more info, see http://rperl.org/performance_benchmarks_nbody.html
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)
> 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.
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 :
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 :
but if you want sigilless parameter names, you have to use a backslash : which is quite ugly.Just make the sigils optional already.