momo-reina

Algorithm book using Lisp

https://leanpub.com/progalgs/read#leanpub-auto-data-structur...

Or a book like Barski’s Land of Lisp

https://www.amazon.com/Land-Lisp-Learn-Program-Game/dp/15932...

I would start with Common Lisp.

You don’t own the money you deposit in the banks, the banks do. Through the act of depositing you are lending the banks your money, therefore it’s not your money anymore. They can default on the loan.

See https://thehutchreport.com/your-bank-account-who-really-owns...

Or read https://www.amazon.com/Where-Does-Money-Come-Ryan-Collins/dp...

Highly recommended.

I understand that the box reflects the file changes, however that does not really help me.

I need an Linux Dev environment, that includes all the tools for emacs. I used to just live in the VM, but current performance is terrible, so I'm trying to see what my options are with just connecting to the VM from the host and editing from the host. That means though that all the tools are on the VM (REPL, etc) so I need to find a way to connect running emacs instance in the VM

I heard that the 4k versions get 5, 6 hours at best of battery life, which is what's stopping me from buying one. Have you had a better experience? This is doing dev work.

I just wrote about doing it this way yesterday.

http://www.mozartreina.com/

Cider now has a debugger:

http://batsov.com/articles/2015/06/16/cider-0-dot-9/

Bozhidar Batsov just recently did a podcast with Cognitect where they speak about this and other things related to Slime and the Clojure programming environment:

http://blog.cognitect.com/cognicast/080

I worked as a laborer in my eary twenties in Scotland and they have an apprenticeship system as well for trades like plumbing, masonry, and joinery (carpentry). 6 months in the classroom and 6 months apprenticed to a master.

Software Engineering seems to be moving in this direction but I think this is applicable to almost all fields of study.

Growing up in the Philippines, this is how we used to drink, one guy fills the glass with booze, then passes it down to the next guy in line, who chugs it down then passes it back to have it refilled.

Same glass, same amount of booze, same order in the rounds. Wonder if it's an indio+Spaniard thing? I haven't seen this anywhere else in Asia.

I have a 2nd gen. X1, (the one without the dedicated function keys) and run Arch on it. It's my Dev and play machine, no problems whatsoever and the 2560x1440 screen is addicting. Can't imagine going back to something with less DPI.

Perhaps the comment came out wrong, let me try to be a little clearer.

I'm not trying to create separate categories between front-end, back-end, desktop, CLI, and systems engineers. The distinction I am trying to make though is that yes, while Computing has become a vast field, there simply are some basic fundamental skills that are absolutely required if we want to go beyond our current level of achievement.

These are things that you have mentioned: deep knowledge of algorithms, data structures, software engineering, computer architecture, etc. This is absolutely the MINIMUM requirement Without understanding these things, we will stay at this present level of software engineering forever. Sure we will have mastered the tools, and the current programming-paradigms that these tools teach us, but we will not be able to advance.

Whether one programs in JavaScript, Forth, Common Lisp, or even BASIC isn't the issue. The point that Fogus's post is trying to get across, or at least what I have taken away from it, is that most "serious" programmers are incredibly lacking in what is considered basic foundational knowledge. What field one specializes in is irrelevant, there is just some stuff that everyone has to understand, not necessarily in the way that a specialist in the field does, but at least have more than passing, cursory knowledge of it.

Actually I'd argue that there are quite a few things that programmers should have in common, if by programmers we're talking about serious engineers/computer scientis[1] and not "amateur-hour web designers"[2].

Knowledge of the fundamental concepts talked about on that list of papers, and the history therewith, is what allows us to go past the current level of engineering and actually reach greater heights. Most of the emphasis nowadays is spent on knowledge of specific toolchains, frameworks, etc, instead of actually learning WHY and HOW these things work.

From that basic foundation you can then go into any field and learn the semantics, details, and problem-specific techniques to deal with the problems presented. Without that foundation, we're all just floundering around, becoming proficient in using these tools without actually KNOWING how they work and therefore unable to take them to the next level.

[1] - A conversation with Alan Kay https://queue.acm.org/detail.cfm?id=1039523 [2] - JavaScript isn't Scheme http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt...

In Japan, there are two independently developed maglev trains. One is HSST by Japan Airlines and the other, which is more well-known, is SCMaglev by the Central Japan Railway Company.

The development of the latter started in 1969, and Miyazaki test track had regularly hit 517 km/h (321 mph) by 1979 but, after an accident that destroyed the train, a new design was decided upon. -- Wikipedia

I'd say Japan got into the technology quite early...

13" 2011 Air, dev work done in Arch Linux run through VBox.

> GH Hardy wrote: “there is no permanent place in this world for ugly mathematics.”

There is no permanent place in this world for spaghetti code....

I enjoyed reading the code =)

Without mentioning the usual Emacs, AutoCad(AutoLISP), and ITA:

[0] Google App Inventor http://googleresearch.blogspot.com/2009/08/under-hood-of-app...

[1] Quickdocs is written in Lisp http://quickdocs.org/

[2] Jak and Daxter http://www.gamasutra.com/view/feature/2985/postmortem_naught...

[3] Maxima http://maxima.sourceforge.net/

[4] Prime Trader (Lisp Works) http://www.lispworks.com/success-stories/netfonds-primetrade...

[5] Franz success stories http://www.franz.com/success/

Jao's old blog[1] is a treasure trove of information. Modern Lisp hackers like him, Zach Beane and Edi Weitz are great representatives for the Lisp community: incredibly talented and yet very humble and more than willing to help out those just starting out in Lisp.

[1] http://programming-musings.org/

Online simulator: http://cnotmz.appspot.com/

These were the exact points raised at #lisp. They also tried to explain the CL idiom to a recursive problem which I don't really recall except the fact that I didn't understand it...

I included it because I felt it was too good to leave out despite the fact that it uses Scheme. Lisp in Small Pieces is also mostly Scheme, though some CL features are covered in detail (I was look for some excuse for it to make the cut).

I'll edit the post though and note those two things to avoid potential confusion.

Yeah I've blown the stack more times than I can recall when using non-tail recursion. I do enjoy recursion, it seems like a clean and elegant solution, though I'm ridiculously preoccupied with writing non idiomatic code.

Pascal Costanza has an interesting opinion[1] on why TCO wasn't included in the ANSI standard.

[1]http://www.p-cos.net/lisp/guide.html

Jao, author of Geiser, talks about the impact they had on his development in his post A Scheme Bookshelf[1]. Are there any CL equivalents?

[1]http://programming-musings.org/2007/01/31/a-scheme-bookshelf...

I had a few discussions with some guys at #lisp, they looked over some code I'd written that was recursion-heavy, and they were of the mind that since Tail-Call Optimization is not in the ANSI standard and therefore implementation dependent one should be careful when using them.

Now that totally changes if you're writing Scheme...

Thanks for the heads-up, I wasn't aware of CLQR. Will definitely check it out.

LoL is definitely one of the major highlights in my reading plan.

The E in Emacs was contributed by Stallman, this was when he had already joined the project. Previously, the project had another name and other hackers were involved.

"Frustrated, Steele took it upon himself to the solve the problem. He gathered together the four different macro packages and began assembling a chart documenting the most useful macro commands. In the course of implementing the design specified by the chart, Steele says he attracted Stallman's attention.

"He started looking over my shoulder, asking me what I was doing," recalls Steele.

For Steele, a soft-spoken hacker who interacted with Stallman infrequently, the memory still sticks out. Looking over another hacker's shoulder while he worked was a common activity at the AI Lab. Stallman, the TECO maintainer at the lab, deemed Steele's work "interesting" and quickly set off to complete it.

"As I like to say, I did the first 0.001 percent of the implementation, and Stallman did the rest," says Steele with a laugh.

The project's new name, Emacs, came courtesy of Stallman.[1]

I think Coders at Work, by Peter Seibel, also talks a little about this in one of the interviews.

[1] Free as in Freedom

Ah that might be it, I'm also quite ignorant of Scheme and thought that most Schemes would be able to run without problems; seems like only Scheme48, MITScheme and Kawa are supported.

How is this any different to SLIME? Most of the time you connect to a running LISP system though SLIME/SWANK, you don't frequently shut down the system when you do debugging/development. Introspection is basically built-in most implementations of (Common) LISP.

Can anyone elucidate on the main differences between Slime and Geiser? The Geiser main page says that Slime is/was part of the inspiration but others are also mentioned.

I can't wait for that to happen, I learned Emacs for the sake of CL development... I was actually thinking of learning Clojure just to check out LT.

i can tell you that after going through only a few chapters of SICP, it radically changed the way i wrote code. i took the MITx 6.00X programming course after and was incredibly uncomfortable at using destructive methods (to give an exmaple), even though i used to write and think code in that way.