Earlier quoted context omitted.
TCL, while it has its warts, is a really cool language. I mean, it even basically has fexprs, something most Lisps put by the wayside years ago. When you don't actually care about speed, you can do some pretty cool stuff.
Yes, I worked on a startup that did pretty much something like Ruby on Rails, but with TCL, inspired by AOLServer. The speed critical parts were written in C and loaded as TCL extensions. Back in the first .com wave. It also taught me to never again use a programming language without JIT/AOT compiler on their standard toolchain for heavy loads.
The Idea of Lisp
91–100 of 348 posts
Re: The Idea of Lisp
#92Question: what would a LISP dialect with static typing look like? EDIT: Found an answer: http://stackoverflow.com/questions/3323549/is-a-statically-t...
Common Lisp, Racket, and Clojure all have optional static typing.
Re: The Idea of Lisp
#93Earlier quoted context omitted.
This example of "everything as an expression" doesn't take it as far as Tcl, though. In the above code snippet, the conditional body is surrounded by braces, which are syntax. In Tcl, the second argument to the 'if' command is also an expression, which only uses braces as a quoting mechanism, if it needs to.
I'm not sure I understand why it matters if the syntax requires braces or not. The things inside the braces are still expressions.
set condition-body {puts "Hello, world"}
if { $condition } $condition-body
To get this to run, you need to splice in the condition-body like so, if { $condition } {*}$condition-body
But you get the point.Re: The Idea of Lisp
#94Earlier quoted context omitted.
TCL, while it has its warts, is a really cool language. I mean, it even basically has fexprs, something most Lisps put by the wayside years ago. When you don't actually care about speed, you can do some pretty cool stuff.
Yes, I worked on a startup that did pretty much something like Ruby on Rails, but with TCL, inspired by AOLServer. The speed critical parts were written in C and loaded as TCL extensions. Back in the first .com wave. It also taught me to never again use a programming language without JIT/AOT compiler on their standard toolchain for heavy loads.
Back in the day, aolserver w/ TCL + (open)acs + pgsql/oracle was teh awesomeness compared to LAMP that everyone else was doing. Oh well... :(
Re: The Idea of Lisp
#95Earlier quoted context omitted.
If there's one thing I've learned from programming it's that to build anything good you have to be driven by real use cases.
It's not clear if your comment approves or disapproves the one you've commented.
Re: The Idea of Lisp
#96This great idea of Lisp (the simple syntax of function calls in round brackets) isn't much different than a good macro assembler even back in the 1960's. The only major difference was that more than 1 function could be defined in 1 source code line. (I think that machine code is nothing but a sequence of function calls where the function is the logic encoded in the CPU itself for each opcode.) Is it fair to compare t…
Code layout/indentation is also an issue, but there's a single standard for Lisp, which Emacs is aware of.
Re: The Idea of Lisp
#97Can someone mantion a few features or scenarios that make it the best choice for starting a new project?
Re: The Idea of Lisp
#98Earlier quoted context omitted.
Agreed about linked lists; that virtually all functional languages make them the default/literal data structure is IMO a poor practical design choice (no matter how theoretically elegant) and is the primary culprit for their reputation for slowness. And the tendency for functional compile-to-JS langs to emulate linked lists in Javascript and keep them the default data structure is downright laughable.
(Singly linked) lists are a functional data structure. You can manipulate them efficiently without modifying the lists you started with. You can't do that easily with arrays. So if you base your language around arrays, you're better off making it imperative. Lisp predated level 1 caches. I think it's better to design hardware around the software that runs on it (the Burroughs mainframe/Lisp machine approach), than de…
Lisp DOES predate level 1 cache but we DO have level 1 cache now and it dwarfs all other optimizations on modern computers. Wouldn't it be nice if the hardware was designed to optimize our languages instead of the other way around but I live in this universe rather than an alternate one.
What matters is now, not decades ago.
Re: The Idea of Lisp
#99I'm working on a Lisp-based introductory programming book: https://github.com/rongarret/BWFP Still very much a work in progress. Feedback appreciated.
You may be interested in checking this out for inspiration: http://www.ccs.neu.edu/home/matthias/HtDP2e/ (It's the Intro to CS book used at my alma mater, teaching programming in Racket)
But man after the initial hump, I was convinced that this is the route to go through in order to introduce someone to programming with very solid first principles.
Re: The Idea of Lisp
#100I'm working on a Lisp-based introductory programming book: https://github.com/rongarret/BWFP Still very much a work in progress. Feedback appreciated.
You may be interested in checking this out for inspiration: http://www.ccs.neu.edu/home/matthias/HtDP2e/ (It's the Intro to CS book used at my alma mater, teaching programming in Racket)