Skip Navigation

User banner
Oriel Jutty :hhHHHAAAH:
Oriel Jutty :hhHHHAAAH: @ barubary @infosec.exchange
Posts
0
Comments
53
Joined
3 yr. ago

  • To be fair, the C example could be detangled a lot by introducing a typedef:

     
        
    typedef int Callback_t(int, int);Callback_t *(*fp)(Callback_t *, int);
    
      
  • Both of those declarations look weird to me. In Haskell it would be:

     
        
    a :: Stringbob :: (String, Int, Double) -> [String]bob (a, b, c) = ...
    
      

    ... except that makes bob a function taking a tuple and it's much more idiomatic to curry it instead:

     
        
    bob :: String -> Int -> Double -> [String]bob a b c = ...-- syntactic sugar for:-- bob = \a -> \b -> \c -> ...
    
      

    The [T] syntax also has a prefix form [] T, so [String] could also be written [] String.

    OCaml makes the opposite choice. In OCaml, a list of strings would be written string list, and a set of lists of strings would be string list set, a list of lists of integers int list list, etc.

  • Because let x: y is syntactically unambiguous, but you need to know that y names a type in order to correctly parse y x. (Or at least that's the case in C where a(b) may be a variable declaration or a function call depending on what typedefs are in scope.)

  • I am 100% confident that your claim is factually wrong.

  • I agree with your core point, but no software is intuitive.

  • POV: You open vim for the first time.

  • b == 7 is a boolean value

    Citation needed. I'm pretty sure it's an int.

  • Do you know the difference between a script and a program?

    A script is what you give the actors; a program is what you give the audience.

  • I don't understand the complaint. What exactly is the issue?

  • I'll update my mems when Microsoft decides to implement C99. (Hey, it's only been a quarter of a century ...)

  • Yeah, just don't make any mistakes and you'll be fine. Come on guys, how hard can it be?

  • The same is true of std::endl. std::endl is simply defined as << '\n' << std::flush; nothing more, nothing less. In all cases where endl gives you a "properly translated" newline, so does \n.

  • std::endl provides zero portability benefits. C++ does have a portable newline abstraction, but it is called \n, not endl.

  •  
        
    for (int i = INT_MIN; ; i++) {    ...    if (i == INT_MAX) break;}
    
      
  • Arguably, I never fully learned Bash syntax, but it also is just a stupid if-statement. There shouldn’t be that much complexity in it.

    There isn't. The syntax is

     
        
    if COMMANDthenCOMMAND(s)...elseCOMMAND(s)...fi
    
      

    I believe, if you write the then onto the next line, then you don’t need the semicolon.

    Yes, but that's true of all commands.

     
        
    foo; bar; baz
    
      

    is the same as

     
        
    foobarbaz
    
      

    All the ] and -z stuff has nothing to do with if. In your example, the command you're running is literally called [. You're passing it three arguments: -z, "$var", and ]. The ] argument is technically pointless but included for aesthetic reasons to match the opening ] (if you wanted to, you could also write test -z "$var" because [ is just another name for the test command).

    Since you can logically negate the exit status of every command (technically, every pipeline) by prefixing a !, you could also write this as:

     
        
    if ! test "$var"; then ...
    
      

    The default mode of test (if given one argument) is to check whether it is non-empty.

    Now, if you don't want to deal with the vagaries of the test command and do a "native" string check, that would be:

     
        
    case "$var" in  "") echo "empty";;  *) echo "not empty";;esac
    
      
  • Isn't this COBOL or 4GL or something?