Why did jobs move overseas ? If I am a business owner it makes absolutely no sense for me to pay 10x wages just for the privilege of hiring american workers. And if Laws do not change to take into account this differential more and more businesses will leave america.
There's all sorts of things that make absolutely no sense for business owners to do, so we have labor laws because business owners can't be trusted to not fuck everything up for society.
Whose products? I don't see how your comment follows. Are you talking about $90k automobiles or groceries?
GP was commenting on the expense of hiring American workers and wage competition. While there are some moral arguments for higher labor cost such as (ironically) workplace safety, the necessity for laborers to be able to afford the products they make is just nonsense.
Being self sufficient for war and producing excess agriculture product and dumping it on foreign markets are two completely different things.
And two can play at that game - china can make the same 'national security' nonsense argument about information espionage when it comes to the internet.
And in the modern world - the internet is more useful then food for a nation state - america can lose 30 million people and still win a total war as long as its nukes are functional.
-- This is prolly the most arrogant opinion I have --
I think if every programmer started using LISP we would have a massive unemployment crisis - since many software engineers would lose their jobs - as most are forced ( due to the nature of capitalism ) to sell snake-oil solutions to problems already solved 50-60 years ago.
--
I am not a Lisp programmer , so no accusation on smugness pls. I just ended up using Lisp concepts daily when programming terrible languages since that is what the market wants :) # Resume Driven Development
Lisp has some good traits, but it isn't the 'ultimate' language. There are a number of issues with Lisp, for example I've heard debugging Lisp macros can be quite hard, I'd also say optional types is a weakness. Even Sussman, one of the creators of Scheme, classes Haskell as the best programming language we currently have, or in his words "the most advanced of the primitive languages.".
That's not to say Lisp doesn't have merit, because it does, it's easy to pick up, very flexible, and in the right hands can lead to impressive results, but we've still got plenty of work to do to improve the state of the art.
I disagree with your assessment, and I guess with Sussman's appraisal as well.
I believe that you are mistaken in your belief that Lisp isn't the most advanced language. The submitted thread contains many comments that state that Lisp is basically a pure implementation of the untyped lambda calculus. I don't think this is correct -- Lisp is itself a unique model of computing, and it generally unifies Turing's and Church's computational model in a relatively unbiased manner IMO. For that reason, I regard Lisp as the most flexible languages of all "multi-paradigmed" languages. The Lisp machine's software was basically exclusively implemented in Lisp; the fact that developers could comfortably accomplish that testifies to Lisp's flexibility.
In Lisp, entire linguistic constructs can be dynamically created to iteratively solve a problem. That's basically a bunch of buzzwords, but
I think the statement holds significance. I've read comments elsewhere regarding Lisp as the "Maxwell's equations" of PLT. I agree with that. If you're not familiar with the meta-circular evaluator, I encourage you to read up on it, as it justifies this statement.
That being said, Haskell's type system is really fantastic. I'd love an implementation of a Lisp with a Hindley Milner-esque type system.
Basically, I think Lisp is the most advanced language because it captures what a language is perfectly. This makes it free to involve and embrace new ideas, and has contributed to its continual success and long life.
> "Lisp is itself a unique model of computing, and it generally unifies Turing's and Church's computational model in a relatively unbiased manner IMO. For that reason, I regard Lisp as the most flexible languages of all "multi-paradigmed" languages."
I agree that Lisp is a flexible language, what I disagree with is that this automatically makes it the 'ultimate' language. By ultimate language I mean the best language we can ever create.
The reason I can say that is I see Lisp's flexibility as a double-edged sword. On one hand you can adapt Lisp to match a task, effectively creating a DSL for the particular application you're working on. On the other hand, the flexibility means that you cannot automatically assume as much about an application structure compared to some other languages.
This point about application structure is probably easiest to explain through the lens of type systems. Some of the benefits that type systems can give to other languages do not necessarily apply to Lisp. Do any Lisps have type systems? Sure they do, but they're always optional. It is this that causes an issue. Consider if you were writing some application that used a Lisp type system, and now you want to pull in an external library that performs a set of functions that it would be non-trivial to implement. There are no guarantees that this external library has any types you can query, regardless of how you designed your own code.
Whilst I appreciate that some Lisp coders are comfortable with 'rolling their own' when it comes to reusable libraries, I'm sure you can think of libraries that would be a lot of work to put together. For example, a library on natural-language processing.
Lisp has its advantages, but I think we still have room to improve when it comes to programming languages. Even if Lisp can express everything that can be calculated, there are other factors to consider when looking at the merits of programming languages.
Edit: I submitted this reply an hour or so after opening the tab, during which interval several others mentioned Shen (which is good, as it deserves a bit of exposure).
Shen (in particular its type system) is an executable Sequent Calculus system [0] written with a small portable lisp. This derives from a propositional logic system, not H-M over typed lambda calculus.
Thank you for clarifying. Can you comment on the relative expressive power of Shen's type system versus e.g. Haskell? I understand that the former can accept as well-typed terms the other can't; in what way is this a consequence of modeling Shen's type system using the Sequent Calculus versus Hindley-Milner deduction?
The page describing Shen uses the terms "proprietary" and "closed source" as if they're good things when describing the "Shen Professional" dialect. (Compiler? Environment? It's a bit opaque.)
I'm certainly no Free Software zealot, but that's been an almost unfailing recipe for getting a language and its ideas ignored for 20+ years now.
And the creators appear to be reserving some features for the "commercial" version, and also attempting to heavily promote that version in a way which—I think, based on a few decades' experience—will actively turn away the people who might otherwise be interested in using it.
It is a small Lisp based on Klambda, comprised of just 43 instructions, that has been ported to Common Lisp (SBCL), Haskell, Ruby and Emacs Lisp (just this month). It has also been ported to Python, Clojure, Javascript, Java, and the JVM which are not up to Shen 19 certification yet.
Shen has pattern matching, an integrated fully functional Prolog, static type checking and even optional lazy evaluation. It has a very strong type system.
Shen commercial has Griffin, an optimized compiler, SML (Shen Markup Language) to generate HTML, and concurrency.
Popularity has not been my reason for selecting a language. I have been using J, an APL-derived, language for years, and I also like APL, K, and now Q! It is amusing to see developers rediscover APL concepts after 50 or more years!
Anything I can think of using it for. I have used it at several jobs, for fun, and now I'm trying to learn how to build standalone J/Qt cross platform apps. The J runtime runs on Android and iOS too, but my needs are Windows, Mac, Web and Linux for now.
Good luck man. It's a really interesting language. Error messages could use a little more context, but it's super fun to do /r/dailyprogrammer puzzles with it.
True. I still have trouble when I get a domain error due to my thinking about verbs / interpretation order / context / rank not being up to scratch. Would love to get something a little more verbose like "expected ~" or something to help me zone in on what's not working.
Debugging lisp macros is like debugging anything else. You have functions that take an input and produce an output. The input is data, the output is data, and there aren't likely side effects. Use the same tools to debug macros that you would use to debug other functions. We have debuggers, tracers, and the repl to help us debug macros, since macros are just normal lisp functions (that run at a different time than "normal" code).
I agree. As sklogic showed, you can actually get the remaining attributes of LISP by building a Haskell or whatever on top of it. Doesn't have to be Common LISP or even a full LISP. Just the syntax, macros, eval, and basic compiler. One can do the rest in the other language as a DSL.
And then another language as a DSL. And another. :)
Most of these are from the late 70s/early 80s, so not quite half a century.
Debugging – look at Smalltalk if you don't believe me.
Security – Intel i432 didn't sell well, but now we're sure wishing it had. The entire system was built on an object-capability model from the hardware up. The OS and userspace were fully written in Ada.
Persistence – System/38 and AS/400 — everything has a persistent address. All pointers are 128-bit (yes... this was designed in the late 70s). Everything is an object and the OS has a built-in database. You can persist anything effortlessly.
String processing – Regular expressions are useful; SNOBOL is more readable, more powerful, more efficient, and existed in 1962. Awk is a joke.
Declarative programming – I feel like Greenspun's 10th Rule applies at least as much to Prolog as it does to Lisp. The sheer number of cases where embedding a little unification engine dramatically simplifies code is pretty baffling.
GUIs – we've almost caught up to the ease of use of the Dynamic Windows system on Symbolics Lisp machines.
Concurrency – it amuses me that Go gets so much attention lately when it's just a re-skin of Occam from 1983.
Probably more. I feel like i432 and AS/400 in particular were very, very ahead of their time.
Do you really think a very high level processor was the way to go? It seems like we're just going lower and lower in the stack in the more advanced applications.
I mean, on i432 (from what I learned about it) you couldn't even free memory - you were stuck in it's specific instructions, GC, and other elements. It could be an interesting version of a secure execution enclave (like Intel tries to create today), but I'm not sure it would be useful or performant in general processing.
> The sheer number of cases where embedding a little unification engine dramatically simplifies code is pretty baffling.
Would love to learn more about this, having done Prolog back in uni. Know of any good articles or posts showcasing "embedding a little unification engine" in modern/otherwise-sub-par programming?
A lot of things currently done in the javascript world are just people discovering that the "just copy all code into a file" world of things doesn’t work – and so they reinvented modules, after the "kik" debacle, now reinvent namespaces, they reinvent dependency management, etc.
Just look at the javascript world, they have enough examples.
It is a language in a constant changing environment. The web today has different requirements than 20 years ago.
It's not right to criticize the reimplementation of things in different systems. That has to happen...
Abstract concepts that are necessary for software to be useful or practical are applicable despite the alleged changing environment. If they weren't, js/node wouldn't be reinventing these concepts, like package and dependency management. I think it's good to revisit occasionally to see if there's a better way, but my experience with node has always been an amalgam of cognitive arrogance and assumptions about how "those guys" (any other software ecosystem) built a needlessly complex and bloated or slow solution to a common problem. At the end, these solutions are equally complex or lack major features, such as security or stability.
I'll point to one major counterpoint before anyone else does though: JSON turned out to be pretty handy. I am glad we didn't stick with XML, although that's what browsers expected in the early 2000's (Ajax/xmlhttprequest).
> I'll point to one major counterpoint before anyone else does though: JSON turned out to be pretty handy. I am glad we didn't stick with XML, although that's what browsers expected in the early 2000's (Ajax/xmlhttprequest).
You didn't look behind far enough. S-expressions were pretty handy and performed more-less the same task as JSON (besides being used for stuff like representing code). Using XML as a data serialization format was a mistake, and I'm glad we're finally recovering from it, even though it took the new generation to reinvent some wheels to get there.
While the impetus for a left-pad like function is due to a lack of a standard library, that's not what went wrong. Brushing the problem aside as merely a "political issue" shows that you don't understand what went wrong either.
1) The whole culture of bringing in a mass of external dependencies for single specialized functions is to be quite honest rather strange and problematic on it's own. Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time.
2) Bringing in an literally an unknown number of external dependencies is dependency hell. How many different left-pads and left-pad-likes do you have? Do you even know?
3) The justification of trivial functions as standalone dependencies is justified as a vetting process. Somehow by pulling in everything separate will improve code quality? No. Fixing bugs improves code quality. Honestly, someone in this very forum justified left-pad as a standalone because it helped "find edge cases." What's the edge case in left pad? There's literally only two edges. -1 and (padtosize - len(num)). On one end you get an undefined, and on the other, your string is wrong. Even if you walk off the entire string, you get another undefined. It's a lesson 1 Intro to Programming problem.
4) Having a bunch of minimum functions makes choosing the right one impossible, or maybe it doesn't matter at all, in which case what's the point. Seriously. I was going to make a remark about "Why not just implement printf?", when a quick google found THREE! printfs on npm (format, sprint, and qprintf.) And then of course there's left pad if all you want is "%03d".
5) The actually source of the left-pad debacle is autoupdating external dependencies from the Internet. This is a horrifically Bad Idea. It was a Bad Idea before the left-pad debacle, and it's a horrifically Bad Idea after the left-pad debacle. And I have no doubt that the javascript community did not learn this lesson. Instead it appears all that was learned was to be scared of trademark claims.
Autoupdating dependencies is a Bad Idea because it's how you get bugs. Seriously, if the javascript community simply didn't do this, and instead followed the best practices software engineering practices since literally the dawn of external libraries, then the whole left-pad debacle would have been greatly mitigated.
The whole security injection clusterfuck happened because the kid that runs NPM got scared because "code was breaking", of course it's not his code, it's just random code on the Internet, because the javascript community doesn't employ widely implemented best engineering practices. NPM as exploit delivery vector was always there, and it's still there if you don't do proper versioning and vetting of your external libraries. Passing the buck, isn't acceptable.
Left-pad was to the greater software engineering community like the scene at the end of Lord of Flies, when the adult finally shows up, looks around at the chaos and says, "What are you guys doing?"
> Sure there's no standard library, but no one thinks about making one. Instead everyone makes "frameworks" for turning DIVs into BUTTONs for the 86th time.
Well, I know that I brought javascript into this, but there are some stdlibs being built: underscore.js is one nice example.
The problem is not as simple as just a missing stdlib.
The problem is a standard lib that doesn't ship with the browser compounded by the fact that javascript build pipelines can't easily and in fact don't do dead code elimination. So shipping an entire stdlib 60-70% of which you don't actually use to the browser is a terrible idea.
Javascript really is a special snowflake here and refusing to recognize that is problematic to say the least.
It was fairly trivial to foresee the requirements. I was ranting about how stupid html is back in 1993. If things were done the Lisp way back then, we would not have seen any of this "changing environment" epic circus.
CRUD. My day job involves maintaining ASP webform sites which are a set of inputs to create compute contracts. Lots of copy pasted code I'm trying to consolidate. Lacks use of generics or ORM or form models
Not really 'problems' but some examples of things which did not had to be written over and over; we still do so because it is a) hard to reuse software b) we have no source from others c) snake-oil; we want to make money and just giving them something that has been proven to work and just needs a little tweaking doesn't make so much.
Besides 'graphics' and AI we are not doing much different from the 80s at least. The software I write for mobile devices is in essence the same as the software I wrote for DOS/CPM/MSX. The crazy amount of time we spend on the frontend (animations, UI/UX etc) is very different from that time but the functionality is not very different. I actually wrote POS systems (for bars/restaurants) in the 80s (for a friend of the family), 90s, 2000s and this year and the logic / db stuff is the same for these. The only change is the GUI and even that not massively. Why didn't we write a POS in the 80s and just call that 'POS-barres', give it away for free and NEVER again write POS software for bars/restaurants? 'But they have different wishes!'. No they don't. I sold (as being the coder but also the (pre-)sales person); they don't have different wishes; every POS-barres is the same plus/minus some hardware and more (over time) data gathering. For me this falls under snake-oil; knowing my own ex company and my competitors; we sold basically lies ('our software is better' and luckily bar/restaurant owners have no clue what to say to that because if you go into it you would be hard pressed to even see any difference, maybe besides hardware support years back).
This goes for many software systems. My first company wrote educational software sold to almost all schools in the Netherlands; this software is still sold, it runs on the same logic since the 80s (written in (Turbo) Pascal, directly imported into Delphi as unit in the 90s and on); the GUI and ofcourse the data in it was tweaked but the logic did not change.
Sure we can now add advanced data analysis; but you don't have to add that INTO the software; you can do that in the cloud and make a screen to show the analysis results. That doesn't change the software and you could do implement the 'showing of the results' in the 80s. Sure we add AI but that can be added on mostly instead of rewriting from scratch.
Pretty much everything in the enterprise. It simply should not exist. All that CRUD stuff (that should have been automated long ago, it does not deserve all the boilerplate), everything Java, everything that is going on now in the Web. It is all amazingly overengineered. Doing things in an idiomatic Lisp way would have resulted in 1/1000th volume of a code doing 10x more. And, of course, in 95% of the developers being redundant.
(defun foo (x y)
(declare (type (integer 1 12) x)
(type character y))
(make-string x :initial-element y))
And the compiler will provide a compile-time error if someone tries to call (foo 1 2) but will accept (foo 1 #\a). Even cooler, it will provide a compile-time if the developer tries to call foo with a first argument which is not provably an integer from 1 to 12.
In fact, you might even say that it's statically typed since values which have undeclared types are really of type T, but I don't think I'd go that far.
Clojure is a kind of Javified Lisp; if you're looking for a canonical example, the GP provided an example of Common Lisp code, which gives you optional type declarations that are compile-time checked and are used by compilers to generate more optimized code.
Common Lisp not a Lisp derivative: it is Lisp. Someday, of course, there may be a successor language, but Clojure is not.
Clojure is a Lisp-like language with — I'm told — many good and/or interesting idea. I don't know if it's actually the most popular Lisp-like language (I'd think Scheme would be), but it probably is more popular than Lisp. That's sad, but that's life.
I like your term "RDD". It seems like the type of development strategy where you write implementations of hash trees and database whenever you need them.
subscriptions are great for handling black hole callbacks - callbacks that you cannot return back control to the callie.
Examples of this would be web-socket , http-requests , etc.
however elm and cycle.js try to shoe-horn this idea everywhere - which I think is not needed.
Not every event needs to be subscribed to - it pollutes your global stream. Use global stream only when you need to deal with things that move out the execution context of your program.
When I was younger - pre 2008 - I went to a seminar in the middle east.
It was about the future of global energy demand. The person giving the presentation had this graphs - all they could see was growth in global oil and gas demand.
During the seminar I asked one of the presenter about global warming, and how they hope to tackle it.
At least their was no global warming denial but it was unfathomable to them that something like solar could even compete with energy generation using natural gas and oil.
Of-course even I knew back then that solar will not be able to compete - even if solar could be cheapened - it wasn't like these producers had razor thin margins.
Finance seems to be a big employer here - obviously not on the scale of the City but proportionally (Edinburgh isn't that big) it's a fairly high percentage of jobs.
Don't think I've ever seen "sexy" and "actuarial" used together :-)
What do all the actuaries do in Edinburgh then - I've seen to have known loads of them over the years! Or is pensions/life stuff not on the "sexy" side of things?
Of the places I know employ actuaries in Edinburgh: Standard Life, Scottish Widows, Royal London... and there are quite a few consulting actuary companies around as well.
As a life-long windows users I am curious what they mean by 'skilled in Linux' - I use the command line in windows when I am programming with core.utils and never saw the reason to switch to Linux.'
The same problems you cite for node.js are the reasons why a lot of devs love node.js.
Its much easier to do your own research and find the best module to solve a particular problem you are having then to shoehorn into some larger monolithic framework.
Also its a lot more fundamental then that - Node.js has prolly the fastest iteration cycle for any platform out there since its so easy to create your own module - it leads to some sort of Cambrian explosion of innovation and experimentation.
EDIT:
Also OP seems to think callback hell and async programming is bad. The important thing is those things are problems for python/.... too !
Its just that python doesn't have a good programming model to even begin to address those concerns.
JavaScript at-least tries to say - "hey this is a problem we need to deal with - concurrency is a issues we all face "
So when devs complain about callback hell - its just that they have never tried to use python to do async in a neat way.
> python doesn't have a good programming model to even begin to address those concerns
This isn't even close to true. Anything JavaScript has to express logic in the face of asynchrony, Python has too. There are a half-dozen asynchronous web servers written in Python.
There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program, and threads/OS processes are good enough for basically everything except HTTP servers with absurd numbers of concurrent connections.
> There's not as much of a culture of writing APIs that way in Python because it's generally a terrible way to program
I would love to see evidence for you making that statement. Almost every programmer would put out their fav programming language as the 'right' way to program.
> everything except HTTP servers with absurd numbers of concurrent connection
Once you introduce async operations in your code - you need to follow the execution path through. http request can be async - but then what if the http request results you doing a db lookup or some form of file handling ? you need to make the whole thing event driven.
It's not like we didn't have cooperative multitasking for 50 years. Having threads/processes and a scheduler is easier and safer, full stop. Potentially long-running portions of the program don't need to be arbitrarily chopped up to yield control back to the server, because they are pre-empted. Your system is no longer at the mercy of the worst code within it.
Both nginx and Apache's event MPM handle HTTP connections with events while the app backends are still using preemptive threads for running the HTTP handler code, so it's clearly not the case that "you need to make the whole thing event driven." You just need programmers who don't think, "well since the browser doesn't expose threads to JavaScript programmers, clearly they are useless."
That Cambrian explosion is fun when you are programming, but if you are writing a product, you will want to make sure you don't pick a dinosaurus or trilobite to build it on.
Why did jobs move overseas ? If I am a business owner it makes absolutely no sense for me to pay 10x wages just for the privilege of hiring american workers. And if Laws do not change to take into account this differential more and more businesses will leave america.