Live data from Hacker News

How knowing Lisp destroyed my programming career (2006)

coding.derkeiler.com

281–290 of 433 posts

Re: How knowing Lisp destroyed my programming career (2006)

#281
post #40

For a while now I've had a feeling that all the comments about lack of engineers(especially in software) are vastly underestimated. Probably around 10% of us is capable of doing actual software development. The rest writes plumbing and can handle the project for only as long as abstractions available through libraries can hold the complexity. If we assume most of us don't really know what we're doing, that totally ex…

Any suggestions on how I can get into that 10%?

If I knew, I would do it myself and wouldn't be afraid ;)

Probably the best advise is to learn as much as possible, but focus on basics. I feel people often mistake knowledge for skill and that harms them in the long run.

If you learn a concept, you can use it in anything you create. If you learn a framework, you will have to learn a new one in 5 years. Focus on transferable skills.

Re: How knowing Lisp destroyed my programming career (2006)

#282
post #187

Earlier quoted context omitted.

*how many languages would have given you [the luxury of programming effectively] for twenty years? C++ doesn't qualify, to my mind, because the language has had many iterations and also because, as the post's author points out, writing C++ in the early 90s was not always a pleasant experience. Python and even Perl are good contenders, as they have both been relatively stable languages. I'm not sure Java counts - Java…

I know that Lisp has been largely stable, but are you sure it hasn't changed much? Programming paradigms advance, we didn't even have unit tests or continuous integration 20 years ago (at least not widely adopted in the industry). I find it hard to believe that even a Lisp programmer would be completely "static" across 20 years, i.e. the code written 20 years ago would be truly similar to the code he writes now. So I…

I suppose I was thinking in terms of the OP's timeline - 1980-2000. I imagine the practice of writing Scheme code has changed a lot. Not to mention the number of teams migrating to Clojure.

Re: How knowing Lisp destroyed my programming career (2006)

#283

Half-seriously—but could it actually be true? Because by using a high level language most of the time, you will miss the practice it takes to effortlessly program manually what these languages automate. Between "GC, full numeric tower, CLOS, incremental development" and especially the ease of metaprogramming in Lisp, you may eventually lose the ability to perform the very programming tasks you have automated away for…

Having written a significant number of lines of assembler early in my career, I am happy to delegate the task of register allocation (an NP-complete problem) to a compiler. I don't miss that manual task, and don't think the rest of my career suffers for that.

I also don't particularly miss worrying about malloc/free in my programs, nor having to write multi-precision floating point arithmetic routines.

Re: How knowing Lisp destroyed my programming career (2006)

#284

Earlier quoted context omitted.

> However the market does't care for that. The market prefers short term gains over long term gains. I agree with this. For example, Sun was sold for $5.6B in 2009. [1] While Skype was sold for $8.5B in 2011 [2]. Sun had Solaris, Java, SPARC, and MySQL. Skype was a chat tool. Even today many popular databases find it hard to get billion-dollar valuations, while multiple Social Companies has done it. The market doesn'…

> Skype was a chat tool. > The market doesn't care about core CS. Yeah, implementing a peer-to-peer voice over IP with Skype's late 00s quality (which fell significantly since then) is not "core CS" and is just "plumbing", right.

Skype seems to have floundered not on lack of features, but on app stability and call quality. Honestly, it looks to me like an example of a technically-challenging product that failed by underperforming on core CS.

I'm not sure why it would be framed as low-difficulty, except that consumer-facing tools tend to get written off as simple.

Re: How knowing Lisp destroyed my programming career (2006)

#285
The problem wasn't lisp... The problem was he didn't want to leave his comfort zone.

You can love lisp, Smalltalk, and all those beauty languages, but you should never stick to a single language. NEVER. Go to another, look it's strenghts, and if it's a bit weak on some sides, try to use the nice techniques you learned back to make it better.

To solve any problem, you can use different languages. Of course would be nice to use the nicest languages, but in some contexts they're not the right tool, and in others, you should have to consider outside factors like, how many people will maintain that software. All of them knows how to use the powers of those nice languages? Also, do you think would be easier to rotate people on that project using those languages instead of another ones?

Everyone can learn to use some tool, but experience using others may help you to discover better ways to use new tools.

Re: How knowing Lisp destroyed my programming career (2006)

#286
post #86

Earlier quoted context omitted.

What made it click for me is the nature of scheme: a few, very well thought out abstractions, that compose well to build a really neat language. I never really made friends with other languages. Where scheme composes the primitives for problem solving, I find that languages like python or ruby provide either one way for each different thing, or a very large hammer for every problem you might find, be it list comprehe…

> a very large hammer for every problem you might find, be it list comprehensions or generators or whatever OO voodoo you can come up with. List comprehensions, to me, are what makes Python a productive (or the most productive) prototyping language. It allows me to think and program in mathematical relations without much fuss. Add to that nice sets and dicts (needed for asymptotic efficiency), and I can easily forgiv…

Whatever programming language you are using, at some point or at some representation the compiler will start generating code. The difference is that the default code representation of lisp allows it at source level, making writing (and debugging) them a lot easier. An if statement in python generates a shitload of bytecode that the optimizer then does what it pleases to. With lisp you can watch that process by watching the source->source transformations of macros and the optimizer.

Macros allow us to extend the language. It is not just C-like code generation. The loop constructs of common lisp, or the for loops of racket (or my own reimplementation for guile scheme) are macros.

With lisp macros we can express zero cost abstractions that in other languages would have a lot of overhead, and make them feel like a regular language construct (CLOS started like that)

My own racket-like loops for guile generate code that the optimizer can then turn into optimal code: https://bitbucket.org/bjoli/guile-for-loops/overview

The downside being that macro expansion slows down compilation. My workstation can expand about 1000 loop macros/s with guile and a couple of orders of magnitude more using my chez scheme prototype (somewhere above 100k)

Re: How knowing Lisp destroyed my programming career (2006)

#287

Earlier quoted context omitted.

The gains from Lisp-like support of live-environment programming are not small, but they are hard to communicate succinctly. The costs are real, but not onerous for a language designed to support such features. But a person designing and implementing programming-language tools has to deliberately choose to provide the needed features because implementing them after the fact raises the costs and lowers the benefits. T…

On a fundamental level, there's not much difference between Lisps and any other language with real runtime eval. It's just that, say, in your average JS project you're going to have a lot of state all over the place, state that depends on side effects. I don't think Lisps do much to solve that. Clojure helps by discouraging state and side-effects, namespaces let you have everything sort of be a global in a manageable…

It's not just about having eval(), it's also about having tooling to exploit its capabilities. I'm currently learning OpenGL with CL, and if I make a change to my main loop, I just hit a few buttons to recompile it without interrupting anything. As soon as it's finished compiling my loop silently switches over to it and the output reflects the new version of the loop.

I have a Discord bot written in CL. If I want to add a new command or feature, I write it, hit a few buttons, and it seamlessly integrates with my bot without interrupting anything it's doing.

If I have a problem with a macro, I can hit a button to have it expand right there in my code, and when I see the problem I hit a button to unexpand it.

The editor will even catch errors and ask what you want to do, without interfering with other threads, which has been very useful while developing my bot.

Re: How knowing Lisp destroyed my programming career (2006)

#288
On a tangential topic : I am intimidated by how myriad experiences with programming languages HN commentators on this thread have. I have been in this industry for about 8 years and am considered an above average developer in my current company. I have primarily worked with Java, while fiddling with others here and there. No experience with pure functional languages such as Lisp or Haskell. Am I missing out some important part of the developer experience?

Re: How knowing Lisp destroyed my programming career (2006)

#289

Oh wow, I was first introduced to Java in my undergrad and somehow I had some serious issues with the whole OOP stuff. Thankfully, I took some AI courses, which came with LISP and I was so excited to use it everywhere. Unfortunately, however, doing basic I/O, networking (this is around 2006) and testing was too complicated for me so I dropped it again in favor of C++ in grad school (performance was also an issue, we…

Practical Common Lisp[0] remains the near-standard text, I believe. It's amazingly good, and shows how useful it can be to develop one's own syntactic abstractions with the practical example of an MP3 ID3 parsing system. I can't recommend it highly enough.

Peter Seibel's second book Coders at Work is also excellent.

0: http://www.gigamonkeys.com/book/

Re: How knowing Lisp destroyed my programming career (2006)

#290

Earlier quoted context omitted.

I reckon all software is plumbing. Plumbing as in taking data in, processing it, and pushing the data out. Doesn't matter if it's a database, a compiler, or a CRUD app; it's all just plumbing.

No, plumbing is taking prebuilt pieces like pipes and elbows, joints, valves and just putting them together. There are plenty of software that is not about taking pre-existing packages and gluing them together, but rather involves construction from the ground up. Building a CRUD app using an existing framework, and an existing rest API with little to no custom business logic is plumbing. Using sci-kit for your ML app…

> Writing your own novel ML/deep learning algorithm, shoving the data in and out of GPUs is not plumbing.

This is plumbing as well by your definition. Writing your own novel ML/deep learning algorithm also take "pre-existing packages" and glues them together. Unless you are actually going to write your own custom OS, Language and drivers you are going to reuse stuff.

I don't think there is anything wrong with using pre-existing packages and the like. We all are doing that anyways unless your are Terry A. Davis off course.

Post reply on HN