Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Emacs Problem

sites.google.com

Post reply on HN
Print view View original

31–40 of 41 posts

Re: The Emacs Problem

#31

Post by lispm »

eklitzke wrote: post #4

One solution that Steve didn't discuss is JSON. To be fair, JSON wasn't that popular in 2005, but it's still a great solution. The way it works is that their are no mandatory newline characters in JSON. Whitespace between lexical elements is ignored, and any embedded newlines in strings can be escaped (i.e. as \n). So a log format that a few people are using today is like this: {'kind': 'foo', 'id': 1, 'msg': 'hi'} {…

S-Expressions

    (:kind foo :id 1 :msg "hi") (:kind bar :id 2 :msg "there")

Re: The Emacs Problem

#32

Post by 1amzave »

snprbob86 wrote: post #20

Uuugh... XML... how I hate you. Everyone should need to learn Lisp, even if you never ever program it, simply to avoid developing some of these poisonous XML-flavored tools. He mentions Ant specifically. Let me tell you, as an unwilling Microsoft Build expert, XML should be NOWHERE NEAR your build system. He puts down Makefiles, but as someone who wrote a Makefile for the first time after years of Ant and MSBuild, it…

> If anything, Makefiles are too powerful and too close to turing complete.

"Close to"? Not a formal proof of Turing-completeness (and may only work with GNU make, not sure), but...

  [me@host: ~]% cat fibo.mk
  dec = $(patsubst .%,%,$1)

  not = $(if $1,,.)

  lteq = $(if $1,$(if $(findstring $1,$2),.,),.)
  gteq = $(if $2,$(if $(findstring $2,$1),.,),.)
  eq = $(and $(call lteq,$1,$2),$(call gteq,$1,$2))
  lt = $(and $(call lteq,$1,$2),$(call not,$(call gteq,$1,$2)))

  add = $1$2
  sub = $(if $(call not,$2),$1,$(call sub,$(call dec,$1),$(call dec,$2)))

  fibo = $(if $(call lt,$1,..),$1,$(call add,$(call fibo,$(call dec,$1)),$(call fibo,$(call sub,$1,..))))

  numeral = $(words $(subst .,. ,$1))

  go = $(or $(info $(call numeral,$(call fibo,$1))),$(call go,.$1))

  _ := $(call go,)
  [me@host: ~]% make -f fibo.mk
  0
  1
  1
  2
  3
  5
  8
  13
  21
  34
  55
  89
  144
  233
  377
  610
  987
  1597
  ^C

Re: The Emacs Problem

#33

Post by lelele »

jcapote wrote: post #2

It would be interesting to see an emacs implementation in language better suited for text manipulation like Ruby or Perl.

Emacs Lisp is better suited for text manipulation than Perl or Ruby. Powerful regexes just don't cut it, you need text related abstractions.

Emacs clones based on both Scheme and Common Lisp have been written, but they haven't taken off.

Re: The Emacs Problem

#34

Post by mahmud »

1amzave wrote: post #32
snprbob86 wrote: post #20

Uuugh... XML... how I hate you. Everyone should need to learn Lisp, even if you never ever program it, simply to avoid developing some of these poisonous XML-flavored tools. He mentions Ant specifically. Let me tell you, as an unwilling Microsoft Build expert, XML should be NOWHERE NEAR your build system. He puts down Makefiles, but as someone who wrote a Makefile for the first time after years of Ant and MSBuild, it…

> If anything, Makefiles are too powerful and too close to turing complete. "Close to"? Not a formal proof of Turing-completeness (and may only work with GNU make, not sure), but... [me@host: ~]% cat fibo.mk dec = $(patsubst .%,%,$1) not = $(if $1,,.) lteq = $(if $1,$(if $(findstring $1,$2),.,),.) gteq = $(if $2,$(if $(findstring $2,$1),.,),.) eq = $(and $(call lteq,$1,$2),$(call gteq,$1,$2)) lt = $(and $(call lteq,$…

"The language of GNU make is indeed functional, complete with combinators (map and filter), applications and anonymous abstractions. GNU make does support lambda-abstractions."

http://okmij.org/ftp/Computation/#Makefile-functional

Re: The Emacs Problem

#35

Post by Xurinos »

jrockway wrote: post #17
Xurinos wrote: post #8

Did anyone else think of CL-PPCRE as they read through the "lisp does not have regular expression support" implications? That was answered by the comparison of elisp to modern Common Lisp, and I wonder if anyone has done any work to make CL-PPCRE work for elisp. In spite of being someone's library, it is much faster than perl's built-in regex support. There is a point to be made for the idea that you are solving the…

Most of those benchmarks are against Perl 5.8, the version of Perl released in 2002. 5.10 had major regexp engine improvements, and 5.12 had minor improvements. Anything is fast when you compare it to 10 years ago.

I actually ran my own tests to see the difference, including tests against hash speed and so forth. But it is good to know there are other benchmarks out there that correlate with what I found, even if older ones. Has anyone published new ones?

Re: The Emacs Problem

#37

Post by mofey »

kuahyeow wrote: post #7
eklitzke wrote: post #4

One solution that Steve didn't discuss is JSON. To be fair, JSON wasn't that popular in 2005, but it's still a great solution. The way it works is that their are no mandatory newline characters in JSON. Whitespace between lexical elements is ignored, and any embedded newlines in strings can be escaped (i.e. as \n). So a log format that a few people are using today is like this: {'kind': 'foo', 'id': 1, 'msg': 'hi'} {…

"XML is better if you have more text and fewer tags. And JSON is better if you have more tags and less text. Argh! I mean, come on, it’s that easy. But you know, there’s a big debate about it." — Steve Yegge http://simonwillison.net/2008/Jun/15/steveys/ That's the problem with discussing old articles. Information gets updated

Not really. The arguments still hold.

Re: The Emacs Problem

#38

Post by jrockway »

loewenskind wrote: post #30
jrockway wrote: post #26

Earlier quoted context omitted.

Lexical scoping is mostly for defensive reasons; its absence shouldn't prevent you from writing code. It only prevents a very narrow category of bugs -- a type of bug that is especially uncommon in elisp, because most variables are bound with let, rather than set with ... uh ... set. That means, even if you accidentally use a variable name that the caller has, you still don't clobber the caller. Some parts of Emacs a…

Dynamic scope is fantastic and I dislike using any language that doesn't have it. That said, I find it annoying in emacs to write code that uses menus because what I would like to do is build the menu and attatch a closure to the different "buttons". Since I couldn't find a way to get callable closures using the cl package I ended up writing some kind of global button-position table. Yuck. As to your point about "glo…

You just have to consider callbacks to be a (function . closure) pair, instead of just a function.

Re: The Emacs Problem

#39

Post by loewenskind »

jrockway wrote: post #38
loewenskind wrote: post #30

Earlier quoted context omitted.

Dynamic scope is fantastic and I dislike using any language that doesn't have it. That said, I find it annoying in emacs to write code that uses menus because what I would like to do is build the menu and attatch a closure to the different "buttons". Since I couldn't find a way to get callable closures using the cl package I ended up writing some kind of global button-position table. Yuck. As to your point about "glo…

You just have to consider callbacks to be a (function . closure) pair, instead of just a function.

Hrm... I should have thought of that. I'll blame it on time constraints!

Re: The Emacs Problem

#40

Post by jrockway »

loewenskind wrote: post #39
jrockway wrote: post #38

Earlier quoted context omitted.

You just have to consider callbacks to be a (function . closure) pair, instead of just a function.

Hrm... I should have thought of that. I'll blame it on time constraints!

Yeah. Emacs Lisp requires you to solve problems in a different way than you are normally used to. I guess that's bad. But once you figure it out, it's not too much of a productivity drain, which is what matters in the end.
Post reply on HN