161–170 of 433 posts
Using any language for twenty years straight is going to make you complacent - but goodness, how many languages would have given you that luxury?
Perl was launched in 1987.
Python was launched in 1991.
Java and Javascript were launched in 1995.
C# was launched in 2000.
So the newest out of the popular languages is already 18 years old.
You don't need Fortran or Cobol or Lisp to have been able to do this... It's already almost 60 years since that time.
Earlier quoted context omitted.
Nerds screw up everything we touch. I don't think we mean to. Whatever the system, we make it more complicated, er featureful. Then we add an abstraction layer. Then we make that layer more complicated. Repeat and rinse. Some abstraction layers help more than they hurt, but the ratio is about 1-in-10 or so. For any given project, there are probably a dozen cool-sounding frameworks or layers, one of which is absolutel…
Being able to solve people's problems doesn't mean you need to be able to program. What is a "real programmer", anyway? Is it knowing how a CPU works? Managing memory? If you rely on the garbage collector, do you really know what you're doing? If you write a Rails app without fully understanding HTTP, are you just plumbing? Does it matter? The reason we build tools and abstractions is to allow us to accomplish higher…
Earlier quoted context omitted.
> only a handful of people is capable of actually developing software project Failures here are almost definitely related to lack of adequate mentorship rather than anything else. College doesn't go half the way to prepare you to be a successful engineer. There are people out there that can be self-motivated to do better, but in almost all those cases they're building skills that do the dirty work but don't feature b…
College doesn't go half the way to prepare you to be a successful engineer. This is something I'm hearing alot at the moment, and not just about engineering. What would you say college taught you?
What learning those things does do is drastically increase your future flexibility as a developer - new databases, new languages, new jobs entirely, whatever. It's all built on the same primitives and if you have that fundamental understanding it makes it easy to ramp up on new technologies given you have the willpower and motivation. There's still a learning curve for specialized fields (of course) but that's fine.
Colleges may well be adapting since I left, but the main issue is that people aren't really holding you to the standards of software that exist at capable software firms. Correctness is about all that matters in university. Students don't know how to optimize for testability, maintainability, deployability, monitorability, etc etc. And learning and developing those skills makes you far better at the 'correctness' bit too.
There are some courses that are collaborative, but in industry the code you write can affect hundreds or thousands of other engineers and there can be real economic consequences of issues in your work (see: plenty of interns/new hires that have had the opportunity to kill $100,000-$1,000,000 or more in revenue by taking down a site - not blaming them, it's just an issue that actually exists in the real world). The order of magnitude is just so different.
This isn't a problem per se, I don't think universities should be expected to perfectly prepare you for this (this is why internships are crucial, and are one of the strongest interview signals for new grads). But somebody does have to - the onus is really on employers of new grads to raise functional engineers if they want to have top notch engineering teams.
I'll be honest - I didn't really grok CS until my first internship had passed, but that one summer really changed both my existing knowledge and my desire to build those skills further. I'm really grateful to have worked with some people that sparked that interest in me. I was at a 2-fulltime-dev startup with a ton of opportunity to work on different pieces of the stack, and it was just tremendously fun.
Side note: an interesting note on taking down applications is that as software enterprises get more mature and taking down a site is that much harder, it feels like (to me) that new engineers in your organization actually have a less opportunity to learn-by-doing for the foundational pieces. This is a very bizarre catch-22 that I suspect has real consequences for the growth of new engineers in software organizations. Very hard to calculate that effect though.
Earlier quoted context omitted.
Your confusion will go away once you recognize that Scheme is not Lisp. For most purposes, Lisp means Common Lisp, or one of the Lisps that ended up merging into Common Lisp. That means that Lisp does all of these things and more, which you might not expect if you've only seen Scheme/SICP: * Multi-paradigm programming (functional programming in the immutable sense is not dominant, the Lisp OOP system is top class, mu…
To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language)
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…
Well, the cheapest, safest assumption is that your skill level is about average and the majority of the programmers you 'll meet are going to have the same kind of skills as you.
Earlier quoted context omitted.
To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language)
Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.
For all practical purposes CL, Scheme, Clojure and Elisp are all lisps.
Earlier quoted context omitted.
JavaScript is for HN what sex is for highscool : those who talk the most about it are those who practise it the less. I was using JavaScript professionally in 1999 and still write it almost every day. Not sure what that makes of your sex analogy: maybe I'm the middle aged guy who goes "free love used to be much better in my day"? You probably know what I meant by "make npm work" — dealing with the messy dependency ec…
I concede that I know what you meant by "make npm work" but I am sorry to hear that you have your left hand busy trying to figure out what's this week's fashionable way to pass around some data in this month's fashionable framework and your right hand busy trying to make npm and Webpack work . More than 18 years of it must have been such a chore. I am glad this is not how either my coworkers or I spend our time using…
I find I’m roughly as productive in JavaScript as in C. Webpack feels more complex than CMake. That’s a rather low bar for productivity.
Earlier quoted context omitted.
Maintaining a distinction between "actual software development" and "plumbing" is elitist, even if you're placing yourself on the downside of that comparison and setting yourself up for imposter syndrome. You can get an awful lot done by "plumbing". Entire businesses like SAP are built on it. It can also be mission critical; in SpaceX, is the literal plumbing of hydraulic fluid and fuel flow unimportant? No.
> Maintaining a distinction between "actual software development" and "plumbing" is elitist... Is the distinction between an aerospace engineer and aircraft mechanic "elitist"? Which would you prefer to have designed the next aircraft you fly in? Plumbing is really what the vast majority of us do. With varying levels of skill, we glue various pre-written libraries and packages together with a bit of business logic, s…
Irrespective of the title, can they design and build the object in question. This applies to all fields.
The point that we must look at is whether or not the problem before us can be solved by us. It doesn't matter if you build from the ground up or use some pre-built parts. Is the solution going to work and solve the problem at hand. If it does then you have success, if it doesn't then you have failure.
It is a matter of understanding the problem (in terms of the problem space), what solutions you use only matters if you can't solve the problem.
The conclusion was inescapable: the problem wasn't Perl or C++ or Java, it was me. I just wasn't a very good programmer any more. Lisp's power had made me complacent, and the world had passed me by. Lisp can't help you if you're too smug for your own good. Disclaimer: I'm a Lisper.
Non-English speaker. What does "smug" mean?
Earlier quoted context omitted.
To add to the confusion, this Wikipedia article says that Scheme is "one of the two main dialects of Lisp." https://en.wikipedia.org/wiki/Scheme_(programming_language)
Well, it was true, at least until clojure. Now we've got clojure, common lisp and scheme.
DEFINE ((
(LENGTH (LAMBDA (L)
(PROG (U V)
(SETQ V 0)
(SETQ U L)
A (COND ((NULL U) (RETURN V)))
(SETQ U (CDR U))
(SETQ V (ADD1 V))
(GO A) ))) ))
LENGTH (((X . Y) A CAR (N B) (X Y Z))) ; ---> 5
(defparameter length-cl (lambda (l)
(prog (u v)
(setq v 0)
(setq u l)
A (cond ((null u) (return v)))
(setq u (cdr u))
(setq v (1+ v))
(go a))))
(length-cl '((x . y) a car (n b) (x y z))) ; ---> 5
To me, a "dialect" implies that you're in the same language but some users of that language just say things a bit differently to each other. "Howdy" vs "Yo". So "add1" and "1+" might be an instance of a dialect change from 1960. For Common Lisp, "sb-ext:run-program" would be the SBCL "dialect" / implementation's way of running an external program while "run-shell-command" might be Allegro CL's. Is Scheme's call/cc a dialect of Lisp60's prog and go? Clojure doesn't have goto at all.. Racket is much cooler than standard Scheme and has nice packages like https://docs.racket-lang.org/control-manual/index.html but is that a dialect equivalent? At what point does the C equivalent of all the above just become another dialect on the way Lisp says it? (And if you're using Common Lisp as the basis Lisp... do Clojure and Scheme have regional dialects that let them say what CLOS says, or what the condition system says, with minor changes?)
As I said at the top I don't think it matters that much, when people talk about "a Lisp" I just assume they mean something with an s-exp syntax and macros, when people talk about "implementing Lisp" I assume they mean "implementing [a] Lisp" but I kinda wish they meant Common Lisp. Such a loose definition raises the question why other langs are described as Algol-like or C-like and never "an Algol" or "a C", or a dialect of either, but whatever.