[jmillikin]

I agree with you regarding Perl, but you're completely wrong regarding Haskell and Python. Both languages, though high-level, allow direct unchecked access to pointers.

> I would be delighted to see you cause a segfault in Haskell without taking advantage of an implementation bug.

  import Foreign
  main = peek nullPtr

Or, more complicated but less obvious:

  import Data.Typeable
  import Data.ByteString

  data Wrap a = Wrap a
  	deriving (Show)

  instance Typeable (Wrap a) where
  	typeOf _ = typeOf ()

  main = let Just (Wrap bad) = cast $ Wrap () in print (bad :: ByteString)

> Python has clean indentation baked in at the implementation. All major interpreted languages don't allow you to muck around with pointers.

  >>> import ctypes as c
  >>> c.string_at(0)
  Segmentation fault

[cmallen]

This isn't really part of the usual work environment. Just because you can import a library and go nuts with it doesn't mean it's an everyday part of the language.

I mean really, kind of missing the point don't you think?

It's not even like Haskell makes it trivial to mutate the pointers in a natively Von Neumann-esque manner.

Monads don't count either.

Example: how often have you seen unsafe C# code (pointers) used in a production web app?

Counterpart to the above: How often do you see pointers used in C? All the time

Presenting the pathological case isn't refuting what I'm saying, it's just affirming it by showing how far you have to go out of your way to abuse your memory access, whereas in C, it's just a part of how you code. (Functors, for example.)

[jmillikin]

Pointers are absolutely part of the average Haskell and Python work environment -- it's impossible to get reasonable performance without them. Of course, Python programmers like to stick the important parts in an extension module (written in C, naturally), close their eyes, and pretend they're not doing anything "unsafe".

> It's not even like Haskell makes it trivial to mutate the pointers in a natively Von Neumann-esque manner.

Haskell has a module specifically for manipulating pointers[1]. There's no inherent safety in using Haskell rather than C for pointer based code.

> Monads don't count either.

This sentence makes no sense, and makes me think you've never (or seldom) used Haskell before.

> Example: how often have you seen unsafe C# code (pointers) used in a production web app?

Somewhat often -- pointers are used in database adapter, template engines, graphics rendering, and any code which needs to call into foreign libraries.

> Counterpart to the above: How often do you see pointers used in C? All the time

That's because C is used in code where performance is absolutely critical, which demands having control over memory layout and management. Pointers aren't a symptom of using C -- using C is a result of needing pointers.

[1] http://haskell.org/ghc/docs/latest/html/libraries/base-4.2.0...

[cmallen]

>Pointers are absolutely part of the average Haskell and Python work environment -- it's impossible to get reasonable performance without them.

I think that making calls to functions implemented in C via the FFI would be more productive. I've never heard of anyone using pointers in Python for anything.

>This sentence makes no sense, and makes me think you've never (or seldom) used Haskell before.

Sure it does, performing an arbitrary mutation on an already known variable (location in memory) in Haskell is very intentionally non-trivial due to striving for purity as a functional language. (Copy rather than overwrite behavior as a default.)

>That's because C is used in code where performance is absolutely critical, which demands having control over memory layout and management. Pointers aren't a symptom of using C -- using C is a result of needing pointers.

Uh, the whole, "C only uses pointers for speed" thing is completely incorrect. All the experienced C programmers I know use pointers simply because they're the most direct and portable means of writing terse code that is still performant in spite of the brevity. I mentioned functors for a reason.

This is more pedantic than some of the conversations I've witnessed in ##C on Freenode, come on.

You're missing the point by a greater distance than Christopher Columbus missed the West Indies in the late 15th century.

[jmillikin]

> Sure it does, performing an arbitrary mutation on an already known variable (location in memory) in Haskell is very intentionally non-trivial due to striving for purity as a functional language. (Copy rather than overwrite behavior as a default.)

This paragraph 1) has nothing to do with monads and 2) is incorrect. Monads exist to enforce in which order computations are performed. And there's nothing difficult about mutating memory in Haskell; aside from a lack of built-in syntax, it's a close equivalent to C.

  import Foreign

  main = do
  	p <- malloc      -- p = malloc(sizeof(char))
  	poke p 'a'       -- *p = 'a'
  	peek p >>= print -- printf("'%c'\n", *p)
  	poke p 'b'       -- *p = 'b'
  	peek p >>= print -- printf("'%c'\n", *p)
  	free p           -- free(p)

[tel]

Strictly, both of these are possible. Technically, it's well known that type systems cannot be perfect in the sense of consistency and finding all "good" programs. Therefore, socially, it's known that there are bad neighborhoods like Foreign, Typeable, and System.IO.Unsafe where one has to be extremely careful while playing around.

So, sure, you make a great, fun technical point, but at the same time Haskell as a language and a community has very, very carefully worked to make sure people don't make segfaults — actually, they tried to make sure people don't even write ugly code with polluted namespaces and odd global state.

Perl, C, Java just haven't (as much).

[rntz]

The overall point the post you replied to was trying to make, it seems to me, was that it's not about what bad things you can or can't do in a language, it's about whether the language encourages or facilitates bad habits. You can muck about with pointers in Haskell, but it's made very obvious - by the community, by the documentation, by the typesystem - that you're doing something potentially unsafe and risky. Similarly, though perhaps a little less so, with Python etc.

As has been said before, it's not important what a language makes possible, so much as what it makes easy -- and, I'd like to add, what it makes hard.