LaTeX woes - Sympathy for the Blakeyrat


  • area_pol

    @PleegWat Of course, the functionality is there, but why does bash need to have this crazy syntax when countless other languages show us that you can write programs in a readable and easy to understand way.



  • @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    The problem with types is that not everything has the same types. They encode a whole bunch of assumptions, and those just aren't universal.

    So let's just assume everything's text!!!!!

    Despite the fact that 95% of data people work with in 2016 is not text and can't be reasonably interpreted as text.


  • Java Dev

    @Adynathos That becomes a choice between terse and verbose languages, which has nothing to do with whether the caller or the callee does glob expansion.



  • @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    The problem with types is that not everything has the same types. They encode a whole bunch of assumptions, and those just aren't universal.

    So let's just assume everything's text!!!!!

    Because keyboards and parsing aren't a thing!!!!!

    Despite the fact that 95% of data people work with in 2016 is not text and can't be reasonably interpreted as text.

    If it can't be interpreted as text, how are you going to type it in to your PowerShell window?


  • Discourse touched me in a no-no place

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    If it can't be interpreted as text, how are you going to type it in to your PowerShell window?

    You just have to type in the byte sequence for the value, preceded by the GUID for the type. TIC



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    Because keyboards and parsing aren't a thing!!!!!

    Ok, I want to use the CLI to automate this video effect in a Vegas-like application. How do I use "keyboards and parsing" to accomplish that?

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    If it can't be interpreted as text, how are you going to type it in to your PowerShell window?

    I guess it can't be done. You'll just have to take out that sword and commit seppuku.


  • Impossible Mission - B

    @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    Well, as far as I know the basic principles of Unix file names have been for almost forever:

    • A valid file name can contain anything except / or the null terminator
    • Wildcard expansion and parameter splitting are done by the shell. So if you write a program tex and someone calls it as tex *.tex in a folder with three .tex files, you will find the file names in $1, $2 and $3 and you should not mess around any further with those parameters.

    ...which makes it essentially impossible to do something that, in DOS, is trivial: ren *.old *.new. And because decades worth of *NIX programs are dependent on this broken behavior, it's also essentially impossible to fix.

    @ben_lubar said in LaTeX woes - Sympathy for the Blakeyrat:

    @fbmac said in LaTeX woes - Sympathy for the Blakeyrat:

    glob expansion done by the shell was a terrible idea

    Sure, let's just have every goddamn program need to handle the shell's job. It's not like implementing it in one place is any better than implementing it in 100000000 places.

    This statement assumes that there is one globally right way to handle it. As my example above demonstrates, that is not the case.

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    The only exception to this argument was with 1620-bit operating systems such as MS-DOS, where the amount of space available for passing arguments around was incredibly limited. Passing unexpanded globs around worked better in that situation. But there just was never any advantage to doing that once you've got computers with more than a few megabytes of memory; it's a hang-over from DOS and it keeps on causing low-level trouble even now.

    Again, how do you handle pattern-matching cases such as ren *.old *.new if the shell does glob expansion before passing the arguments on to the command?



  • @masonwheeler said in LaTeX woes - Sympathy for the Blakeyrat:

    Again, how do you handle pattern-matching cases such as ren *.old *.new if the shell does glob expansion before passing the arguments on to the command?

    Here's a command that you can run on any Linux machine right now:
    rename 's/old$/new/' *.old


  • Discourse touched me in a no-no place

    @masonwheeler said in LaTeX woes - Sympathy for the Blakeyrat:

    ren *.old *.new

    Well, you can do ren \*.old \*.new if you want. Or ren "*.old" "*.new". It's not really a very common operation.


  • Java Dev

    @ben_lubar Debian-based. Redhat has rename .old .new *.old, and that's just substring replacing so even this example doesn't work as intended.



  • @PleegWat said in LaTeX woes - Sympathy for the Blakeyrat:

    @ben_lubar Debian-based. Redhat has rename .old .new *.old, and that's just substring replacing so even this example doesn't work as intended.

    On redhat, you'd need to install regex-replace.



  • @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    Ok, I want to use the CLI to automate this video effect in a Vegas-like application. How do I use "keyboards and parsing" to accomplish that?

    Hmm, I imagine you have a function written that takes your video, in some format, and effect and time and other arguments. And then you type the function's name, and the video's name, and the effect, and the timing, and other arguments into your video REPL.

    Kind of how it worked in Flash and a million other video tools with scriptable REPLs.



  • @masonwheeler said in LaTeX woes - Sympathy for the Blakeyrat:

    @Grunnen said in LaTeX woes - Sympathy for the Blakeyrat:

    Well, as far as I know the basic principles of Unix file names have been for almost forever:

    • A valid file name can contain anything except / or the null terminator
    • Wildcard expansion and parameter splitting are done by the shell. So if you write a program tex and someone calls it as tex *.tex in a folder with three .tex files, you will find the file names in $1, $2 and $3 and you should not mess around any further with those parameters.

    ...which makes it essentially impossible to do something that, in DOS, is trivial: ren *.old *.new. And because decades worth of *NIX programs are dependent on this broken behavior, it's also essentially impossible to fix.

    That syntax is stupid anyways. It's a simple hack for simple situations but if I would do a ren document_*_page?_*.doc *_*_?.doc it falls over. It should not use wildcard characters if it aren't wildcards but placeholders for matches of other wildcards. And then it's just a half-baked attempt at regular expressions. So, then, just use a proper regular expression library.



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    The problem with types is that not everything has the same types. They encode a whole bunch of assumptions, and those just aren't universal.

    So let's just assume everything's text!!!!!

    Because keyboards and parsing aren't a thing!!!!!

    Despite the fact that 95% of data people work with in 2016 is not text and can't be reasonably interpreted as text.

    If it can't be interpreted as text, how are you going to type it in to your PowerShell window?

    I think his point is that "text is a simple universal serialization method" isn't really true. Text encoding is still a huge problem, with some systems (or applications) only supporting single code pages or encoding (Windows-1252, UTF-8, UTF-16LE, ASCII) and some systems like databases not directly supporting or not supporting encoding per se, but instead requiring language choices by way of collations. (You ever come across a system that claims to support UTF-8 but doesn't actually support multi-byte UTF-8 characters?)

    If dkf's problem with a type-aware shell is that, "[types] encode a whole bunch of assumptions, and those just aren't universal," well, you don't really solve that by switching to the text type. All it does is funnel you into solving the type problem once because what happens is the shell picks a default text encoding and systems/applications are expected to abide by it. If (or when) they don't, you've got to use an application that's type aware. In other words, you still need a type provider for explicit conversions. While PowerShell has an iProvider for each native data type, in *nix you stream through iconv. iconv is your type converter.

    "But this way we only have to solve it once!"

    Yes, but the problem with text-only is that you lose meaning. You might lose the fact that a value is a string and not a numeric value, or vice-versa. You might lose the fact that a parameter is a date. Part of the reason that dates are notoriously difficult to work with is because serializing them as formatted text is really ugly. In the end that means your system has to know how to parse every data type it needs. That requires you to use named parameters or fixed positions to do anything with shell commands, because there's essentially no way for the types themselves to convey meaning. It's more difficult to overload a bash shell command than a PowerShell cmdlet or script because PowerShell can say, "Oh, I got an item of type X, so I need to behave like so." With shell commands, you've got to use switches to indicate desired behavior, or else the program has to know how to decide what to do. It can't just know from the type. Additionally, each program still has to hope that any sending program sends in the expected format -- so you're changing type-aware to string-format-aware -- and similarly still has to format output in a way that another program can still interpret it (otherwise you'll be doing regex tricks to reformat data).

    Obviously, it gets back to the old Windows vs *nix philosophy argument of "everything is an object" vs "everything is a string." There's benefits and drawbacks to both methods. But "just format it as plain text" isn't really that simple because text isn't that simple. It only looks simple in *nix because, well, most programs that are still used are relatively well behaved and use expected formats.



  • @masonwheeler said in LaTeX woes - Sympathy for the Blakeyrat:

    This statement assumes that there is one globally right way to handle it. As my example above demonstrates, that is not the case.

    But at the same time, having a standard way to handle things across the whole OS is better than having each program do the exact same things its own way, since it at least means the things that won’t work, do so predictably.



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    and other arguments into your video REPL.

    I'm sorry, I thought we were talking about the shell. Are we not? :moving_goal_post:



  • @blakeyrat a REPL is a shell is a REPL.



  • @Captain So the answer to the question of, "how would a text-based shell handle non-text data like a series of video edits" is "don't use the shell at all". Gotcha.



  • @blakeyrat use the right shell. The one with the tools you need.



  • @blakeyrat You do understand that Bash and PowerShell are programming languages, and that a shell is just a loop that processes one programmer/user fed instruction at a time, right?



  • Is there any way I could reply to that without you calling me an idiot for the 587th time?

    Look. Here's my fucking point:

    • A system that assumes all data is (or can be represented as) text in 2016 is fucking stupid

    You can accept that point, or not accept it. But stop fucking grilling me. Since there's absolutely no way I could answer your question without you just calling me an idiot yet again. If you want to disagree, just disagree. Without asking me 57,000 stupid questions. It's ok for more than one opinion to exist in the universe.



  • A system that assumes all data is (or can be represented as) text in 2016 is fucking stupid

    587: all data can be represented as text. At the very least, it is always represented as ones and zeros, and can be printed that way. Or you can find more compact encodings.

    The program that consumes data must parse or decode the data. This is true whether you're typing the data in or feeding it to a bona fide executable function (like C or C# or whatever). The executable must know how to handle its input.

    This is true for PowerShell. This is true for Bash. This is true for Haskell and C#.

    Without asking me 57,000 stupid questions.

    Ok, I want to use the CLI to automate this video effect in a Vegas-like application. How do I use "keyboards and parsing" to accomplish that?

    You type instructions into a shell that supports the instructions you want done



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    The program that consumes data must parse or decode the data.

    PowerShell doesn't. (Necessarily.) If you pass in a DateTime to a PowerShell Cmdlet, it doesn't need to do any parsing or decoding at all. It gets a DateTime. Complete with all the helper functions attached to the DateTime class.

    Oh look you just edited your post to add:

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    This is true for PowerShell.

    No, it's fucking not. That's exactly what makes PowerShell better.

    (Not really true in C# either, although it depends on how the program is built. If it's a DLL using something like MEF to implement itself as a plugin in another application, then it gets full .net types also with no parsing required. Think of, for example, a Paint.NET plugin.)



  • @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    PowerShell doesn't. (Necessarily.) If you pass in a DateTime to a PowerShell Cmdlet, it doesn't need to do any parsing or decoding at all. It gets a DateTime. Complete with all the helper functions attached to the DateTime class.

    So what, you just "pass in" a whole binary object without naming it? And you think the run-time doesn't have to pull the data you pass in apart to use it?



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    So what, you just "pass in" a whole binary object without naming it?

    Your Cmdlet has a name for it, of course, and the Cmdlet that sent it to yours has a name for it, of course, but there's no requirement that those names are the same name.

    Just like there's no requirement that just because the calling function uses "ass" as the DateTime's name the callee function must use "ass" as the DateTime's name.

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    And you think the run-time doesn't have to pull the data you pass in apart to use it?

    .net? No, it doesn't. Why would it?



  • @blakeyrat because a date-time consists of a day, month, year, and so on, encoded as a number of seconds since 1970 (or whatever .NET does) and if you want to find out what date a date-time holds, you need to decode the date-time...



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    and if you want to find out what date a date-time holds, you need to decode the date-time...

    By that logic, every object oriented program needs to "decode" every object it deals with every time it deals with it.

    I mean, ok, sure, if that's how we're defining the word "decode". But it's not the definition I'd expect.

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    because a date-time consists of a day, month, year, and so on, encoded as a number of seconds since 1970 (or whatever .NET does)

    You should read the implementation, it's pretty interesting.



  • @Captain Bash is even less of a programming language than PHP.

    PHP is a language accidentally invented by Rasmus Lerdorf at a certain point in time. Bash is a language accidentally hoarded together by hundreds of people over several decades.



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    PowerShell doesn't. (Necessarily.) If you pass in a DateTime to a PowerShell Cmdlet, it doesn't need to do any parsing or decoding at all. It gets a DateTime. Complete with all the helper functions attached to the DateTime class.

    So what, you just "pass in" a whole binary object without naming it? And you think the run-time doesn't have to pull the data you pass in apart to use it?

    Yes. It's Windows. Windows deals with objects, not character strings.

    Everything in PowerShell uses native .Net data types. You run Get-Date, you're basically calling Datetime.Now (or, [System.Datetime]::Now in PowerShell syntax). That returns an object of type System.DateTime, with all the fixings.

    You can use Get-Member to get the details of objects you're working with (the definition column is truncated here):

    PS C:\> Get-Date | Get-Member
    
    
       TypeName: System.DateTime
    
    Name                 MemberType     Definition
    ----                 ----------     ----------
    Add                  Method         datetime Add(timespan v
    AddDays              Method         datetime AddDays(double
    AddHours             Method         datetime AddHours(doubl
    AddMilliseconds      Method         datetime AddMillisecond
    AddMinutes           Method         datetime AddMinutes(dou
    AddMonths            Method         datetime AddMonths(int
    AddSeconds           Method         datetime AddSeconds(dou
    AddTicks             Method         datetime AddTicks(long
    AddYears             Method         datetime AddYears(int v
    CompareTo            Method         int CompareTo(System.Ob
    Equals               Method         bool Equals(System.Obje
    GetDateTimeFormats   Method         string[] GetDateTimeFor
    GetHashCode          Method         int GetHashCode()
    GetObjectData        Method         void ISerializable.GetO
    GetType              Method         type GetType()
    GetTypeCode          Method         System.TypeCode GetType
    IsDaylightSavingTime Method         bool IsDaylightSavingTi
    Subtract             Method         timespan Subtract(datet
    ToBinary             Method         long ToBinary()
    ToBoolean            Method         bool IConvertible.ToBoo
    ToByte               Method         byte IConvertible.ToByt
    ToChar               Method         char IConvertible.ToCha
    ToDateTime           Method         datetime IConvertible.T
    ToDecimal            Method         decimal IConvertible.To
    ToDouble             Method         double IConvertible.ToD
    ToFileTime           Method         long ToFileTime()
    ToFileTimeUtc        Method         long ToFileTimeUtc()
    ToInt16              Method         int16 IConvertible.ToIn
    ToInt32              Method         int IConvertible.ToInt3
    ToInt64              Method         long IConvertible.ToInt
    ToLocalTime          Method         datetime ToLocalTime()
    ToLongDateString     Method         string ToLongDateString
    ToLongTimeString     Method         string ToLongTimeString
    ToOADate             Method         double ToOADate()
    ToSByte              Method         sbyte IConvertible.ToSB
    ToShortDateString    Method         string ToShortDateStrin
    ToShortTimeString    Method         string ToShortTimeStrin
    ToSingle             Method         float IConvertible.ToSi
    ToString             Method         string ToString(), stri
    ToType               Method         System.Object IConverti
    ToUInt16             Method         uint16 IConvertible.ToU
    ToUInt32             Method         uint32 IConvertible.ToU
    ToUInt64             Method         uint64 IConvertible.ToU
    ToUniversalTime      Method         datetime ToUniversalTim
    DisplayHint          NoteProperty   DisplayHintType Display
    Date                 Property       datetime Date {get;}
    Day                  Property       int Day {get;}
    DayOfWeek            Property       System.DayOfWeek DayOfW
    DayOfYear            Property       int DayOfYear {get;}
    Hour                 Property       int Hour {get;}
    Kind                 Property       System.DateTimeKind Kin
    Millisecond          Property       int Millisecond {get;}
    Minute               Property       int Minute {get;}
    Month                Property       int Month {get;}
    Second               Property       int Second {get;}
    Ticks                Property       long Ticks {get;}
    TimeOfDay            Property       timespan TimeOfDay {get
    Year                 Property       int Year {get;}
    DateTime             ScriptProperty System.Object DateTime
    

    Or get static members with Get-Date | Get-Member -Static.

    But you can say things like:

    $Yesterday = (Get-Date).Date.AddDays(-1);
    

    PowerShell is an imperative .Net environment. You can call on any class in the entire .Net Framework or load external libraries. You can also call on older Com+ libraries, but you get some weird results doing that because, well, Com+ doesn't conform to .Net conventions.

    You can do both this:

    ls C:\
    

    And this:

    ls HKLM:\Software\Microsoft
    

    And they both work because both the FileSystem and the Registry providers implement the necessary hooks that the Get-ChildItem cmdlet uses (which is what ls is aliased to). And you can load other providers as you need, such as SQL Server, or others.

    That's the advantage of PowerShell. The disadvantage is that PowerShell is a shell written by programmers, not system administrators. That means it took them inordinately long to add in things that administrators would consider basic requirements, but stuff like Base64 encoding were there from the start. Working with file permissions, for example, is still a huge pain in the ass because you have to work with Windows' Access Control Lists (ACL). That means you have to instance an Access Control Entry (ACE), associate it with an ACL on an item, and then determine the inheritance of that ACL.

    PS C:\> Get-Acl C:\Windows\notepad.exe
    
    
        Directory: C:\Windows
    
    
    Path        Owner                       Access
    ----        -----                       ------
    notepad.exe NT SERVICE\TrustedInstaller NT AUTHORITY\SYSTEM Allow  ReadAndExecute, Synchronize...
    
    PS C:\> Get-Acl C:\Windows\notepad.exe | Select-Object -ExpandProperty Access
    
    
    FileSystemRights  : ReadAndExecute, Synchronize
    AccessControlType : Allow
    IdentityReference : NT AUTHORITY\SYSTEM
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None
    
    FileSystemRights  : ReadAndExecute, Synchronize
    AccessControlType : Allow
    IdentityReference : BUILTIN\Administrators
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None
    
    FileSystemRights  : ReadAndExecute, Synchronize
    AccessControlType : Allow
    IdentityReference : BUILTIN\Users
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None
    
    FileSystemRights  : FullControl
    AccessControlType : Allow
    IdentityReference : NT SERVICE\TrustedInstaller
    IsInherited       : False
    InheritanceFlags  : None
    PropagationFlags  : None
    

    But just about everything coming out of a cmdlet is an object:

    PS C:\> (Get-Acl C:\Windows\notepad.exe | Select-Object -ExpandProperty Access)[0].IdentityReference
    
    Value
    -----
    NT AUTHORITY\SYSTEM
    
    
    PS C:\> (Get-Acl C:\Windows\notepad.exe | Select-Object -ExpandProperty Access)[0].IdentityReference.GetType().FullName
    System.Security.Principal.NTAccount
    

  • Discourse touched me in a no-no place

    @BaconBits said in LaTeX woes - Sympathy for the Blakeyrat:

    Yes, but the problem with text-only is that you lose meaning.

    That's guaranteed anyway. An integer really does not have more meaning than a string in any meaningful way. Your program might invest that integer with extra meaning, but if you hand that to someone else they probably won't understand the meaning anyway. (Unless you document it, but that works well enough for strings too. ;)) Look in the Registry — it's typed in the way you seem to prefer so it will do for an example of what happens in the wild with your scheme — and tell me whether you can determine the meaning of an arbitrary DWORD value that is currently set to 3. (You can't. You need more info. That's exactly my point.)

    Of all the things you can pass that actually have some inherent meaning, virtually all of them either have defined ways of converting them to a string or they are “live documents” (and passing them around has a whole load of separate complexities of its own, such as being a significant step up in terms of security complexity). Most self-describing pure values that can be passed around are documents when encoded, such as in ASN.1, XML, JSON or YAML.



  • @blakeyrat Bollox. Most of it is.



  • @blakeyrat You should read the implementation, it's pretty interesting.

    I'll check it out.



  • @BaconBits said in LaTeX woes - Sympathy for the Blakeyrat:

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    PowerShell doesn't. (Necessarily.) If you pass in a DateTime to a PowerShell Cmdlet, it doesn't need to do any parsing or decoding at all. It gets a DateTime. Complete with all the helper functions attached to the DateTime class.

    So what, you just "pass in" a whole binary object without naming it? And you think the run-time doesn't have to pull the data you pass in apart to use it?

    Yes. It's Windows. Windows deals with objects, not character strings.

    You say that as if your keyboard (the thing you use to type into the PowerShell console) has "object" keys.

    Nope, what it has is character keys, and you pass strings into the console, and they are parsed and interpreted in terms of objects. It is just notation, and some scaffolding to resolve which method is getting called.

    Everything in PowerShell uses native .Net data types. You run Get-Date, you're basically calling Datetime.Now (or, [System.Datetime]::Now in PowerShell syntax). That returns an object of type System.DateTime, with all the fixings.

    I get it. Do you get me?



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    Nope, what it has is character keys, and you pass strings into the console, and they are parsed and interpreted in terms of objects.

    I think you've worked with Lunixes so long you're incapable of thinking any other way.

    Let's say you use PowerShell to run the command "CreateLogEvents" and pipe the output into "EatLogsYum". A LogEvent is a DateTime EventTime, string EventMessage.

    You the user never type in a date. And EatLogsNum never sees a date in text form that it then has to parse.

    The keyboard is not the only way to input data into a PowerShell cmdlet.



  • Edit: Stupid NodeBB.



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    @BaconBits said in LaTeX woes - Sympathy for the Blakeyrat:

    @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    PowerShell doesn't. (Necessarily.) If you pass in a DateTime to a PowerShell Cmdlet, it doesn't need to do any parsing or decoding at all. It gets a DateTime. Complete with all the helper functions attached to the DateTime class.

    So what, you just "pass in" a whole binary object without naming it? And you think the run-time doesn't have to pull the data you pass in apart to use it?

    Yes. It's Windows. Windows deals with objects, not character strings.

    You say that as if your keyboard (the thing you use to type into the PowerShell console) has "object" keys.

    Nope, what it has is character keys, and you pass strings into the console, and they are parsed and interpreted in terms of objects. It is just notation, and some scaffolding to resolve which method is getting called.

    Everything in PowerShell uses native .Net data types. You run Get-Date, you're basically calling Datetime.Now (or, [System.Datetime]::Now in PowerShell syntax). That returns an object of type System.DateTime, with all the fixings.

    I get it. Do you get me?

    No, not really. At least, not unless your point is really just that trivial.

    If your point is that the command line syntax parser (or compiler, for that matter) only works with character data, then sure -- but the command line syntax parser is a hell of a lot more strict about what makes a valid command line than what makes a valid string of characters. A syntax is a rigorous structure for an object. It can be validated and verified (returning a syntax error if it fails to parse). That does not mean that an arbitrary text string is in and of itself a useful means of interprocess communication without all that structure surrounding it.

    And sure, you run ls C:\Windows\ | Out-Host -Paging as written in text, but that doesn't mean that the ls (Get-ChildItem) cmdlet is sending text to the Out-Host cmdlet.

    Your point is basically "a line parser has to read text so everything is just text." That's like saying, "Everything is just 1s and 0s." It's not wrong, but it's not meaningful, either. It's so meaningless to abstract that far that it's not even the right way to think about it because it doesn't lead you anywhere. The intricacies of parsing a command line and doing syntax validation are not particularly relevant to understanding how pipelines work. Similarly, nobody gives a shit what PowerShell.exe or /bin/bash have to do to make a G appear on the screen when you press that key. None of that tells you how to script better or how the system works or what you can do with it. They certainly don't tell you anything about how they're different.



  • @BaconBits said in LaTeX woes - Sympathy for the Blakeyrat:

    Your point is basically "a line parser has to read text so everything is just text." That's like saying, "Everything is just 1s and 0s." It's not wrong, but it's not meaningful, either. It's so meaningless to abstract that far that it's not even the right way to think about it because it doesn't lead you anywhere. The intricacies of parsing a command line and doing syntax validation are not particularly relevant to understanding how pipelines work.

    That's not quite my point. But you're getting close.

    There's no point kvetching about the transport mechanism used to pass arguments around, because they all rely on the same principles: parse/deconstruct a data structure,, type (either with explicit type checking or as part of the next step) and execute.

    It's JUST A TRANSPORT LAYER. A protocol. A notation. How boring!

    It could use SSH via carrier pigeons, but in the end, the callee has to interpret the data it receives, which means (possibly) typing, interpretation and execution.



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    There's no point kvetching about the transport mechanism used to pass arguments around, because they all rely on the same principles: parse/deconstruct a data structure,, type (either with explicit type checking or as part of the next step) and execute.

    But that's not true in PowerShell.


  • Discourse touched me in a no-no place

    @BaconBits said in LaTeX woes - Sympathy for the Blakeyrat:

    A syntax is a rigorous structure for an object.

    That's an oversimplification. Syntaxes are rather more complicated than that once you get into the details, and just how more complicated depends on exactly what you're trying to do.



  • @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    @BaconBits said in LaTeX woes - Sympathy for the Blakeyrat:

    Yes, but the problem with text-only is that you lose meaning.

    That's guaranteed anyway. An integer really does not have more meaning than a string in any meaningful way. Your program might invest that integer with extra meaning, but if you hand that to someone else they probably won't understand the meaning anyway. (Unless you document it, but that works well enough for strings too. ;)) Look in the Registry — it's typed in the way you seem to prefer so it will do for an example of what happens in the wild with your scheme — and tell me whether you can determine the meaning of an arbitrary DWORD value that is currently set to 3. (You can't. You need more info. That's exactly my point.)

    Mmmm.... I kind of agree here. An integer may not express perfect meaning, but it does tell you the possible operations you can do with it. You know how to add and multiply. You know all possible values. With a string, you won't know any of that. So adding type does convey a lot of meaning, and if you're using a system that allows for classes or structured data types it conveys a lot of meaning.

    Of all the things you can pass that actually have some inherent meaning, virtually all of them either have defined ways of converting them to a string or they are “live documents” (and passing them around has a whole load of separate complexities of its own, such as being a significant step up in terms of security complexity). Most self-describing pure values that can be passed around are documents when encoded, such as in ASN.1, XML, JSON or YAML.

    Right, sure. I'm not saying it isn't a problem that can't be worked around or that data can't be represented as text. I'm saying it's not an easy problem with a simple solution. I'm saying there's value in passing typed objects. After all, it's not like we often serialize and deserialize when passing parameters to functions in our own program (unless we're using JavaScript...). You can make a string act like other types of data, but doing that is complicated. You often have to choose between something very robust like XML with a schema definition, something very dynamic like JSON, and something with a very basic, fixed structure like a CSV, INI, or delimited string.

    The point is that you're almost always using the same algorithm to serialize or deserialize your meaning. Most often you're either using a method described by RFC to give structure and meaning to a string from an alien system, or you're using the same program or class with methods purpose built to do that. You're doing tricks to make text behave as though it weren't text so you can pretend you're just passing objects.

    Obviously, though, there's a lot of instances where you can't do that. That's why we have application protocols and RFCs and all sorts of data interchange methods so we don't have to have the equivalent of an SQL driver just to connect to a web server. PowerShell, however, since it understands all those .Net objects can actually pass those objects. You have an object of type System.IO.FileInfo and a cmdlet that takes System.IO.FileInfo, you don't pass System.IO.FileInfo.FullName and have the cmdlet marshall the object. Just pass the object.

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    @BaconBits said in LaTeX woes - Sympathy for the Blakeyrat:

    A syntax is a rigorous structure for an object.

    That's an oversimplification. Syntaxes are rather more complicated than that once you get into the details, and just how more complicated depends on exactly what you're trying to do.

    Sure. My point was that a syntax was at least as complex as an object, not that a syntax was a type of object.



  • @dkf plus it ignores an object system's and language's semantics. Languages with exactly the same syntax can have completely different semantics.



  • but it does tell you the possible operations you can do with it. You know how to add and multiply. You know all possible values.

    Why would you want to multiply, for example, ordinal numbers? Or numeric user ids (that happen to be ordinal numbers)?

    Yeah, you can define ordinal arithmetic, but is it meaningful to anybody outside of set theorists?

    So, using a language like Haskell, I can define new types for these numbers with new kinds of semantics. But @dkf's point is that the new types I'm defining encode certain assumptions -- that an id is an ordinal number -- which won't be true in all systems.

    With a string, you won't know any of that. So adding type does convey a lot of meaning, and if you're using a system that allows for classes or structured data types it conveys a lot of meaning.

    That's the exact same problem. But guess what, the "string" is irrelevant. It's just a transport mechanism for the data. It is the data that has to be interpreted by the callee.

    We can adjust our language here a bit: the callee expects the data in some format and can't handle data that isn't in the right format. But either way, the callee is going to de-construct the data to get at the parts of the data it really needs.



  • @Captain said in LaTeX woes - Sympathy for the Blakeyrat:

    But either way, the callee is going to de-construct the data to get at the parts of the data it really needs.

    Again, I get what you're saying, but I disagree with the words you're using.

    If I have two C# functions, and I pass a DateTime from one to the other, and the other function does Console.WriteLine( dateTime.Ticks );, nobody would describe that as the second function "de-constructing the data". It's just not terminology I've ever heard a human being use before.



  • using json as input/output would have about the same effect as powershell's use of objects



  • @fbmac no? Then you still have an arbitrary blob of string data, rather than a specifically defined blob of memory. It could only be worse.


  • Discourse touched me in a no-no place

    @ben_lubar said in LaTeX woes - Sympathy for the Blakeyrat:

    Sure, let's just have every goddamn program need to handle the shell's job.

    O ye of little imagination. How about an OS service that provides (say) an array of file names?


  • Discourse touched me in a no-no place

    @blakeyrat said in LaTeX woes - Sympathy for the Blakeyrat:

    If I have two C# functions

    Then you already have a common semantic basis, the CIL. (That's why the CIL is important in the .NET ecosystem.) With that common semantic basis, a call can be just a call. People can still fuck up badly, of course (nothing stops that) but there's no really horrible stuff like one side expecting arguments to be packed in a different order to the other. A more subtle incompatibility occurs when you try to match up two languages where one uses mutable objects and the other works strictly with immutable objects (no, you don't normally see the latter in the .NET ecosystem; the immutable value model doesn't sit too comfortably with the CIL model). Where you've got immutability, you can get much better parallelism with lower costs, but it's really quite a different perspective; one naturally prefers different algorithms.

    The key point? Between processes, you don't even have that level of compatibility (because most of the exciting things are insecure as fuck or make your brain hurt when you try to figure out how to implement them). So you're mostly stuck with passing copies of documents around, and different programmers interpret those documents differently. The documents might represent an integer, or a string, or a love letter, or orders to launch all the missiles, but they're just documents.



  • @fbmac said in LaTeX woes - Sympathy for the Blakeyrat:

    using json as input/output would have about the same effect as powershell's use of objects

    1. But PowerShell competitors don't use JSON, they use "whatever, there's no spec or standard"
    2. Converting a video clip to JSON would make it HUGE

  • Impossible Mission - B

    @ben_lubar said in LaTeX woes - Sympathy for the Blakeyrat:

    @masonwheeler said in LaTeX woes - Sympathy for the Blakeyrat:

    Again, how do you handle pattern-matching cases such as ren *.old *.new if the shell does glob expansion before passing the arguments on to the command?

    Here's a command that you can run on any Linux machine right now:
    rename 's/old$/new/' *.old

    @dkf said in LaTeX woes - Sympathy for the Blakeyrat:

    Well, you can do ren \*.old \*.new if you want. Or ren "*.old" "*.new". It's not really a very common operation.

    @PleegWat said in LaTeX woes - Sympathy for the Blakeyrat:

    @ben_lubar Debian-based. Redhat has rename .old .new *.old, and that's just substring replacing so even this example doesn't work as intended.

    @ben_lubar said in LaTeX woes - Sympathy for the Blakeyrat:

    @PleegWat said in LaTeX woes - Sympathy for the Blakeyrat:
    On redhat, you'd need to install regex-replace.

    So, like I said, there is no way to do it in *nix. There is, instead, a variety of different nonstandard ways, that vary widely depending on which distro you're using and which packages you have installed.



  • @masonwheeler said in LaTeX woes - Sympathy for the Blakeyrat:

    So, like I said, there is no way to do it in *nix.

    That statement is equivalent to:

    There is no way to start a car using a car key.


Log in to reply