latiera's comments

Look at my other response in this thread, ROP isn't trivial these days due to ASLR implementations. Almost always one needs information leak bugs.

The presence of a JIT makes things trivially abusable for the attacker and is a big security risk.

It's not that simple. ROP relies on known or predictable addresses and pretty much all modern OSes have some form of address space layout randomization (which keeps getting better and more sophisticated).

With good ASLR, ROP is not possible without relying on information leak bugs which are finite. So the cost for the attacker increases and it gets harder and more time intensive for reliable exploits to be written.

Allowing JIT for everything is a TREMENDOUS security violation, since it's trivially abusable and page permissions are irrelevant. There are just too many ways for clever attackers to abuse it.

If you want to give back to Pharo in a way that counts, fund improvements to the UI. The font rendering is bad right now and HiDPI screens are not even supported. This makes for a terrible first impression.

Oh but it DOES mean that Rust has no value, at least regarding security. Once you give them the rope, they WILL use it. Let's see if time will prove me right.

Unfortunately, this point of view has little merit.

Security is all or nothing. You can't have a little bit of this and a little bit of that. Unless the parts of the web browser that can be "influenced" by external attacker (directly or indirectly) are written 100% in a memory safe language, you simply have no real security but the illusion of such.

And this is how that hypothetical browser fails, and why it will never amount to anything re: security, since it's gonna end up using a gazillion of C libraries, all of them full of bugs and possibly vulnerable to security exploits.

One could say that Rust also fails by allowing "unsafe" code in its core design but it's still too early to see how that will play out.

Because clojure is garbage?

Also, Java/JVM suck ass, why would anyone willingly work with that whole mess?

An interesting observation would be for the author to start considering why this is true. Why does the "universe" give you what you seek? Why do you get from life exactly what you think you "deserve"? It seems strange, absurd, doesn't it? As if the whole thing is a circus, a movie being played just for you.

Now what happens if you simply do nothing? Nothing at all, no hopes, no aspirations, no worries, no dreams, no passions, just live in the present moment, forget about the past, forget about the future. Why keep chasing some illusion or other, trying to satisfy meaningless urges, illusionary needs that others have placed upon you? Open your eyes and SEE.

Start watching Alejandro Jodorowsky movies.

You are a fool.

You can read this as "mainline Guile Emacs is never gonna happen".

Guile is very low quality software (that goes double, hell, triple, for "non free" platforms like OSX and Windows) and Emacs has a reputation for being rock solid on all platforms it runs on.

The Guile fanboys may wish for Guile to replace the current core in mainline but realistically speaking (Guile has what, 1/2 developers?) that's never going to happen.

If I had to guess, I'd say most Emacs users and developers couldn't care less about Scheme/Guile (if not actively hostile).

The "goal" of meditation/yoga is UNION with GOD.

Where GOD can be anything of significance to you but to those who have experienced it's "the universe", the Void, the Unborn, the Undying and so on.

It's funny how a lot of ppl disregard this and have no clue about the "occult" (magick!) elements of the Art. When "mystical" experiences happen to them, lacking theory/practice and a proper framework to serve as a foundation, they tend to lose the world under their feet.

MOCL is garbage, commercial garbage at that. No thanks.

It's 2014, Python still has a GIL, Guido thinks asynchronous event loops are hot stuff and you're talking about quantum CPUs?

Who needs threads when you get drumroll poor excuse of an asynchronous event loop!! In 2014 no less!

You should be off Python already, no need to wait for Rust.

Ocaml, F#, Common Lisp, Scala/Clojure (if JVM) are languages that blow Python out of the water for anything that's not scripting/throw-away code.

elegant?? It's 2014 and Guido is talking about event loops.

beautiful??? Atrocious more like.

Python is terribly put together (I'd say designed but it's clear no such process has taken place). It's a language that, like PHP and to some extent Perl before it, rewards idiotic behavior, makes it extremely easy to end up with horrible unmaintainable code and requires strict discipline and a lot of experience in order for it to "work" in anything that's not exploratory/throw-away in nature.

Of course the (mostly?) clueless masses love it, because they feel empowered. But really ask yourself, what has Python brought to the table in terms of paradigm shifts? It's no Lisp, Haskell or Ocaml.

Hell, even Java looks to be better, especially for beginner/mediocre programmers.

Bleh.

I like how he says 'compiled c++ (to javascript) is immune to buffer overflows' yet completely sidesteps the real issue at hand: Every major javascript virtual machine is riddled with security holes. In Firefox case (no sandbox, no process-per-tab, one of the worst C++ codebases I've ever seen security-wise, _infested_ with memory leaks and UAFs) these holes can effortlessly lead to system compromise. In Chrome case, significantly more work is required.

Emacs eshell. Amazing.

I know CL, I know Haskell. Really what OP said has nothing to do with refactoring (which is indeed painless in Haskell) but more to do with interactive programming.

Haskell is not terrible at interactive programming, but compared to Common Lisp and Smalltalk, it's garbage.

And this is exactly why it feels so kludgy and awkward when one tries to do bottom-up programming and organically evolve his program, the standard way of programming in CL and Smalltalk since they are image-based languages that are designed for exactly this.

This is one of the benefits that one with no prior experience in working in this way can quickly attempt to dismiss, but it's really THE most important reason for someone to use CL rather than Haskell. By having a language that allows you to program in a live environment, from the inside and keep the entire system running at all times, you become one with the machine. The feedback loop is kept extremely short, and you're in a constant state of flow.

It's too bad when people dismiss CL (and Smalltalk) based on trivialities (type systems) that are completely irrelevant in the grand scheme of things. Writing code in Haskell to me feels like a sterile, boring process similar to working out mathematical proofs. That's not to say that Haskell doesn't have its place. When the domain is well-defined and I know exactly what I want to do and how I'm about to do it, I'm more inclined to reach for Haskell or Ocaml than Common Lisp.

This is not the case for me most of the time however. When I program for myself, I find that I often have a general idea of what I want to do but no specifics in mind. It is then that I reach for Common Lisp in order to flesh things out and get inspired if you like. Or, similarly, when I'm doing a project that is hard, the domain uncertain, something with solutions that are not obvious ahead of time. Common Lisp and Smalltalk shine for these sort of problems, there is nothing else that comes close in my opinion.

Common Lisp but not Scheme/Racket I hear you say? Yes, this is indeed the case. Racket is just bad at interactive development of the kind I just described, because its developers deemed image-based programming 'too confusing' and removed all support for it from the IDE. This should also explain why it's not mentioned at all in the original article. Moreover, I find that in order for someone to truly appreciate how empowering image-based development is, one needs years of writing code in traditional non-image based languages. Which is why the best feature of Lisp in my opinion is swept under the rug by most newbie programmers who try out Lisp. They lack the experience to realize what they are missing.

Which is also why the original post author completely misses the point. The real power of Lisp comes from what I just described, not from 10 or 20 bullet points that one needs to side-by-side compare with other languages. By his admission he is a newbie programmer, and a newbie to Lisp too, made evident by his misunderstandings about the Common Lisp macro system vs Scheme "hygienic" macros. Hopefully he will grow and learn to appreciate Lisp for what it really is.

Finally, writing code in Common Lisp or Smalltalk makes me feel like an architect of my own private universe. This is exactly what programming should feel like, an organic process, fusing mind and machine together if you like.

It's not Python that's slow, but scapy, which is dog slow. In fact, it is so slow that it should come with big WARNINGs that it's only really meant for interactive use. Do the dissection yourself or use something built for that purpose.

It's really surprising to me that lots of ppl are using scapy for things that require performance but then again if you look at the scapy website or the docs, it's not immediately apparent that their tool is not meant for this. Which I guess says a lot about the scapy developers rather than the scapy users.

tl;dr Scapy is a joke, performance-wise.

I am addressing Guile being in my view one of the worst Scheme implementations out there, StumpWM has nothing to do with this. Being tied to, effectively, a single platform does.