4 ms·

Now that I'm a PowerShell expert, the idea of dropping down to a *nix shell that only knows how to pass text around is appalling. Like, "the 1970's called, they

Now that I'm a PowerShell expert, the idea of dropping down to a *nix shell that only knows how to pass text around is appalling. Like, "the 1970's called, they want their shell back" kind-of appalling. And so what if it's a few extra characters to script stuff in it? I can make aliases for whatever I want, there's tab-completion for everything, everything is self-discoverable, there's Get-Help and Get-Command (alias gcm) to find everything that's available to me, and, by the way, it's all just a language projection on top of .NET... it's all great. It's like any other language... until you bite the bullet and really learn it, you don't know. And the idea that Windows isn't built for scripting is from the 1990's. For the last 15 years, there's (almost) nothing that Microsoft ships that can't be automated/scripted/controlled from a command-line.

metaobject 9y ago
Maybe it's just me, but the capitalization of the commands is really annoying.
- gruez 9y ago
  why? it's all case insensitive anyways. plus tab completion puts in the correct case.
  - sigsergv 9y ago
    Perhaps because one need to hold shift too often.
    - detaro 9y ago
      again, it is case insensitive, no need to use the shift key.
lottin 9y ago
C is from the 1970's. Lisp from the 1950's. Just because something is old it doesn't mean it's bad. And likewise, new doesn't imply better.
- IshKebab 9y ago
  Well, C is pretty bad, compared to modern languages. It's full of buffer overflows, undefined behaviour, etc. Just because something is popular doesn't mean it is well designed.
  - jstimpfle 9y ago
    Man, will this sentiment ever die... You know Stroustroup, there are only two kinds of languages: The ones everybody bitches about and the ones nobody uses. Please guys, demonstrate a better way. Make that better language. There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share". Man, these people make tons of scripting and DDL languages to get their game done. If they knew a better (more practical) approach than using C in the critical places, they would do it. Yes, you get buffer overflows and memory management bugs. Much more so if you are a beginner, but also if you're very experienced. But people just haven't found a practical alternative. How would you even be able to define what a valid buffer region is, if so many functions are basically custom allocators, declaring a certain sub-slice of the buffer they were given (taking pointers / indices), and handing it to the next function? It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping.
    - IshKebab 9y ago
      > Make that better language. Rust, Go, Swift, etc. Even C++. > There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share". The only thing that is still pretty much all C is kernels. Game engines are usually C++ (a much safer language). Databases are written in all sorts of languages. Sure the big old ones are C or C++, but that's because they are old! > But people just haven't found a practical alternative. They have. Garbage collection works in a lot of cases. Rust has its lifetime & borrowing system. C++ has proper smart pointers (finally). > It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping. I take it you haven't used Go. It has slices. They work fine. No buffer overflows.

metaobject 9y ago

Maybe it's just me, but the capitalization of the commands is really annoying.

gruez 9y ago
why? it's all case insensitive anyways. plus tab completion puts in the correct case.
- sigsergv 9y ago
  Perhaps because one need to hold shift too often.
  - detaro 9y ago
    again, it is case insensitive, no need to use the shift key.

lottin 9y ago

C is from the 1970's. Lisp from the 1950's. Just because something is old it doesn't mean it's bad. And likewise, new doesn't imply better.

IshKebab 9y ago
Well, C is pretty bad, compared to modern languages. It's full of buffer overflows, undefined behaviour, etc. Just because something is popular doesn't mean it is well designed.
- jstimpfle 9y ago
  Man, will this sentiment ever die... You know Stroustroup, there are only two kinds of languages: The ones everybody bitches about and the ones nobody uses. Please guys, demonstrate a better way. Make that better language. There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share". Man, these people make tons of scripting and DDL languages to get their game done. If they knew a better (more practical) approach than using C in the critical places, they would do it. Yes, you get buffer overflows and memory management bugs. Much more so if you are a beginner, but also if you're very experienced. But people just haven't found a practical alternative. How would you even be able to define what a valid buffer region is, if so many functions are basically custom allocators, declaring a certain sub-slice of the buffer they were given (taking pointers / indices), and handing it to the next function? It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping.
  - IshKebab 9y ago
    > Make that better language. Rust, Go, Swift, etc. Even C++. > There is a reason most kernels are developed in C, most databases are developed in C, most (AAA) games are developed in C. And it's not "C has the necessary mind share". The only thing that is still pretty much all C is kernels. Game engines are usually C++ (a much safer language). Databases are written in all sorts of languages. Sure the big old ones are C or C++, but that's because they are old! > But people just haven't found a practical alternative. They have. Garbage collection works in a lot of cases. Rust has its lifetime & borrowing system. C++ has proper smart pointers (finally). > It's just not practically possible to make a formalism that guards against buffer overflows here. You could make a "slice"/"buffer" datatype, but that would just just increase the line noise and keep the bugs at the countless locations of wrapping/unwrapping. I take it you haven't used Go. It has slices. They work fine. No buffer overflows.