171–180 of 184 posts
Earlier quoted context omitted.
As-is, CS really is much closer to a branch of mathematics than a science.
Eh, in a similar way to how theoretical physics is mostly math. Math is the tool you're using, but the assumptions are all based on real-world observations.
Earlier quoted context omitted.
Honestly, that describes exactly my programming workflow when working in Clojure. The whole process happens in Clojure. This language is small enough to write on a single piece of paper Check, Clojure is one of the most concise language out there. I use it for hand writing code or when coding on my phone, because its so short. fully contains all of its abstractions Yup. In fact, you need to change your mindset, you d…
Um. Here's the first part of Clojure's docs [0]. Compare and contrast: "A pitch is a frequency. 440Hz is an A pitch. There are twelve pitches. Each pitch differs from the previous pitch by the multiplicative constant twelfth-root-of-two. Twelve pitches in a row doubles the frequency, creating an octave ." It only takes four or five paragraphs to mathematically describe the basis for chromatic notation. If Clojure ful…
I'm exactly saying that I believe the ability to quickly run and test your program is most important, more so then to prove properties from its code description. And that's specifically the strengths of Lisp dialects like Clojure. Are you saying something different?
Earlier quoted context omitted.
I spent months working on a Lisp project in college. I pretty much hated it. Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of master…
> Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators Is it that "Some people" don't like those, or that "some people" have been to Algol-style languages first, and they can't easily adapt to the other style? > Maybe I "didn't have good enough teachers," but for every other language I've eve…
BZZZZT! Wrong answer!
I started with BASIC and transitioned from there to assembly language. Wrote several games and device drivers in assembly language (BASIC was too slow) and then learned Forth. Tried really hard to like Forth, and played with it for a while; loved some aspects of the language, but couldn't wrap my head around how to write a game with it, so I gave up and kept writing games in assembly language.
Pascal was my next language, and that wasn't until later. Much later than that I finally got to C.
You might think of BASIC as Algol-like, though I'd say it's more Fortran-like. Assembly language, though, is about un-Algol as a language can be, as is Forth.
Earlier quoted context omitted.
I spent months working on a Lisp project in college. I pretty much hated it. Some people (myself included) don't like the aesthetics of Lisp as a language, nor do we like the enforced functional program structure, nor do we like the lack of infix operators. Maybe I "didn't have good enough teachers," but for every other language I've ever learned I didn't need those "good teachers" to achieve a strong level of master…
Some would go to fight with a Long Sword, others would prefer a Katana. I think that's fine. Master what works best for the way your mind and body works. That said, I'd hate for languages to adopt a lowest common denominator just so companies feel then that all programmers can replace any other and all code base is understandable by all. That would be like having every sword fighter fight with a knife. After a while…
Like our pg? Who loves Lisp to death, and made his first major app (a web page store generator, if I recall) in Lisp? But then after selling it to Yahoo -- ported it to another language (Python?) so that other developers could actually modify it?
It's not "lowest common denominator" to expect a language to stay within certain bounds of flexibility. If every single project has so many macros that it's effectively a DSL that no other programmer anywhere understands, then you've created a software package that becomes instantly unmaintainable if the wrong people get hit by a bus.
In college, by the time I picked up Lisp, I had already used:
* Assembly Language * Basic * Pascal * Forth * C++ * Recursion
And I'd already worked on video games professionally (in 1987, in a project for Lucasfilm Games, before they became LucasArts).
Java and C# had yet to be invented. At the time, there weren't libraries and documentation to speak of in any Lisp, so that's something. It was Common Lisp (as well as "elisp" on the Atari ST, which of course was completely incompatible...).
Since then, I've used tail calls (in Lua, and soon coming to JavaScript), collection mappings, pure functions, higher order functions, and all that, in many other languages. I just still hate Lisp, and while I have no problem understanding how to use Lisp, I don't see the advantage of using it over using other languages, and in particular I am finding static types to be critical in large system architecture, which are completely lacking in Clojure and other Lisps.
Earlier quoted context omitted.
Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk. The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image! It sounds great in theory, once t…
> No matter how good your environment, you do not beat the collective effort and productivity of file-system based tools. I bet people said the same about trains and ships. There was a lot of work put into horse-powered infrastructure and first cars and trains were very slow and bad. Same with boats: at the time steam-powered ships were created wind-powered clippers were 5 times faster and much more reliable.
But somehow it never happened.
Earlier quoted context omitted.
Some would go to fight with a Long Sword, others would prefer a Katana. I think that's fine. Master what works best for the way your mind and body works. That said, I'd hate for languages to adopt a lowest common denominator just so companies feel then that all programmers can replace any other and all code base is understandable by all. That would be like having every sword fighter fight with a knife. After a while…
>I don't know, sounds like it's just not as awesome for you, but probably is that awesome to all those famous people saying it is. Like our pg? Who loves Lisp to death, and made his first major app (a web page store generator, if I recall) in Lisp? But then after selling it to Yahoo -- ported it to another language (Python?) so that other developers could actually modify it? It's not "lowest common denominator" to ex…
I don't see the advantage of using it over using other languages
That's probably the best question to ask, I think sometimes there's a lot of false benefits to new/different tools, that while cool, rarely add real value.
My observed (but not measured) benefit was enhanced productivity. That said, I'm not sure how much of that is due to Clojure being a Lisp, or more that I switched from Java/C# which are staticly typed and verbose, to a dynamic language. I don't encounter the issues I do in JavaScript and Python (which I have experience with) as much with Clojure though. Mostly that they get harder and harder to maintain over time. Again, I'm not sure this is because of Lisp, I feel it's more due to Clojure's choice to be a functional language first, with default immutability and managed reference types, as well as its smart choice of abstractions, like open polymorphism using protocols and multi-method and CSP instead of event hell.
The only thing I feel are benefits brought over from Lisp are the interactive REPL workflow, concise notation, code that can be used as an extendable serialization format and configuration format, as well as macros (as double edged sword). Macros have helped me in rare times, to avoid having to write verbose code, but at my work we have very few macros even after 2 years of accumulated code, I think we added 5 or 6 macros only. And I wouldn't want to have more, for the reason you mentioned, we're not looking to use our own custom programming language, and add too many macros and that's what you get. By the way, Clojure chose to not have reader macros, which other Lisps have, and are the ones where you can really go crazy changing the very syntax.
I'd be just as fund of another language that would be functional, immutable, interactive and with smart abstractions. I can live without macros, even though I love a good macro when you need one. I would prefer a syntax with only expressions, not a fan of statements, because you're restricted on where you can use them. And I like concise syntax for having to type less and read less, able to see more at once. I reckon not all Lisps fits this description, so maybe its really not Lisp I should evangelize, but Clojure specifically. Elixir also fits this description, that I know of.
On static vs dynamic type systems, I still don't know. I like types, they feel good to have, but I just don't feel they really help, I think they're a false sense of safety, and they just slow you down. That said, maybe they pay back in the long term maintainance, I'm still unsure though.
Earlier quoted context omitted.
Yep...incidental computation. Also: "primarily"/"mostly". Not all/none.
Hmm, maybe a lot of computation is outsourced to server farms, but "clients" still do a lot of it: image processing, codecs, scheduling, layout, speech recognition, etc etc.
What is speech recognition for? Communication.
etc.
I think you keep arguing against something I never said, which is that computers do no computing whatsoever.
Earlier quoted context omitted.
Speaking personally, I don't want to work with an image based language. That's an argument against both Lisp and Smalltalk. The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image! It sounds great in theory, once t…
> The problem with image based languages is that you've thrown away your file-based tool system. You're so used to your favorite text editor, source control system, etc? So sorry, we're building better tools! And when your code is ready, you just deploy the image! First, what's bad about that? Our text editors and source control systems are indeed crap compared to what we could get with image based systems with inher…
However no image based system is poised to take over the world. And I'm willing to bet my salary that none will ever have sufficient mind share to do so. Programmers switch languages, environments and operating systems. When you add switching tooling to the learning curve, you've just created a barrier to entry to the environment, and programmers are going to spend time learning something that is not applicable to whatever else they do next.
So you wind up with using "awesome tool if you just understood it" where your hires don't. And the "awesome tool" probably isn't quite what those people find most productive. So it becomes a constant frustration.
Move back to a text based language, and this problem goes away. People use the tools that they know. I'm probably going to write code in 4 different languages this week, and have to look at what is going on on a half-dozen machines..and won't need to switch tools.
On having a textual representation, yes you can do that. And then you've changed your image based language into just being yet another VM for another language. Whether you write code in Java, JavaScript or Python in the end it runs in a VM, and that doesn't matter.
As for LISPs in general, it depends. What I've seen with Lisp has mostly been image based, but I don't use Lisp very often.
Earlier quoted context omitted.
So is python, which is a much nicer language.
You don't know what you're talking about. Python process needs to be bounced, or has to watch files and bounce itself on change. The PHP runtime is designed to read the file on each request. You have to go out of your way to require restarts (it is an optimization). PHP has the only mainstream runtime AFAIK that is designed this way (+ the model is stateless, so each refresh really is one). I'm not a PHP fan but it b…
On top of that, I was comparing Python to JavaScript and wasn't even talking about PHP, which, as you rightly discovered, I have very little knowledge about.