I don't know why anybody would chose not to use an IDE, honestly.
Because most IDEs are visually cluttered, rely on the use of the mouse and often enough automatically generate files I have no control over.
I prefer to use Emacs.
I had to use VS for software testing work for a while. It took minutes to load the rather large project I had to test, because it did all kinds of indexing work I never had anything to do with up-front, blocking the stuff I actually needed to do, like only compiling the damn program so I could test the latest version.
So one of my classes (Principles of Languages) is done in a version of Scheme (specifically Racket, more specifically the legacy Racket language "Pretty Big"). While (being forced into) doing everything recursively is an interesting way of thinking, the lack of the program data divide is being pretty cool, and experiencing the great satisfaction being gained when a 3 line program solves your whole program is pretty awesome; it's horriblefying. I mean I don't particularly enjoy the idea of having to take multiple hours to come up with 4-line simple programs that I could crank out non-recursive versions (that probably work faster due to the C++ compiler) for in like 5 minutes. 
It's not helped by the fact that normal Racket has several very helpful functions that our legacy version doesn't support either. 
The time taken to come up with the solution is only a matter of training and writing looping constructs in Scheme should be entirely possible.
Of course they'll be expanded into recursive code, but why should you care about that? The compiler will be doing tail call optimization on it either way, if it is possible to do so.
And ye gods the parenthesis. I can't imaging how normal coders in similar languages survive; it's already gotten bad enough that I've pretty much said "Screw the 'recommended' official coding style, C's 1TBS style here I come!", since at least it wrassles the parenthesis beast enough to make stuff somewhat intelligible, albeit only a little.
*i2amroy goes and cries into his drink
Use parenthesis highlighting. I am working in Common Lisp, the parenthesis don't even register anymore. I am way more put off by all the different and sometimes seemingly superfluous brackets/parenthesis/other delimiters in languages like C/C++. Why the heck do I need to put parenthesis around the frikkin check in branching constructs, even when I'm only referencing a single variable? Why do I need to remember which bracket to use for what purpose?
Once again, it's a matter of training/what you're used to.
Also, the parenthesis allow automatic code formatting, which again helps in spotting structural errors. Sometimes when I change some code and remove closing parenthesis in the process, I check whether I have the correct number of them by re-indenting the following line until it ends up where it was before. It's almost fool-proof.
(It is kinda funny that my professor for the class is one of those hardcore LISP guys who never really gave up on the idea that LISP is "the future of programming". I mean don't get me wrong, LISP-related languages have their uses in places like pioneering new research algorithms and other specific types of work that benefit from it's advantages [though even in some of those fields they're starting to be beat out by things like Python for similar benefits or C++ for speed requirements], but they aren't exactly the language the vast majority of people reach for when they think "I want to code X to do Y", even when said people have been exposed to the benefits of LISP-y languages. Is it a nice tool that you should definitely learn? Yeah, even if only for the practice in a very different way of thinking. But as for "the future of programming", it's almost certainly never going to be the generic language that people grab first when they just need to code a generic something up.)
The thing is, languages with proper macros are the most general – I haven't found a single way of programming that wouldn't be available in Common Lisp via macros and reader macros. There's even a library (a
library!) out there taking most of the parenthesis out of Common Lisp. I'm not using it, since I like my parenthesis and the resulting automatic indentation.
I like Lisp on a theoretical level, but for actual development I'd rather throw bits of boilerplate together than muck around with billions of operators and brackets.
If your program becomes this complex, you use macros to cut down on the complexity. It helps with readability, bug avoidance and boilerplate. It also reduces the use of parentheses dramatically.
As much as I hate to admit it, the boilerplate that most languages impose upon coders is generally meant to allow us to catch our mistakes before we run it. We can't do static analysis in lisp, we have to crawl through the branches of the code seeking the error. In C++, you can do magic with templates and make the compiler sweat until it tests those things for you. With C#, the code contracts can do the same, but without invoking the dark voodoo that are Turing complete templates.
Yeah, static checking isn't really a thing, but testing libraries are.
Also having a REPL in which I can just run parts of my code without needing to compile and run the whole program is damn awesome. I can narrow down algorithmic bugs way easier with a REPL than with static checking.
Actually static checking could probably done in part via macros.
I don't think it's the right language for every level of development. But I think it would be pretty well-suited for a lot of the stuff I do, which is largely data curation, routing, and filtering.
Sure, if it's good for what you commonly do than more power to you. Languages are tools and all that jazz, and you shouldn't be trying to nail screws in with a hammer. But for "expressivity" (Note:, there are a lot of definitions about what exactly it means for a language to "expressive", so pardon me if I'm using a different one here), I think I'm gonna have to say that in the vast majority of cases the human mind when thinking of a step by step process thinks in a way that is much more similar to a language like C++ with it's step and state focused paradigm than that of recursive functional languages. The proof of this can be observed simply by opening up a nearby cookbook, or by googling "instructions to do X" on google where X is anything that you want. I can almost assure you that the instructions you find there will be much more likely to be based around sequential steps with iteration than recursive calls.
Doug Hoyte argued like this in his book "Let Over Lambda": Programming is not so much a process of adding functionality to a codebase but rather a process of changing functionality of a program. The easier it is to change code, the better. He then goes on to introduce a few macros which allows turning a lambda expression into a kind of contextual object by just adding one character and one line. He then implements a Forth dialect in Common Lisp, perfectly embeddable.
The point is: Yes, different languages for different tasks, but Lisp just is able to emulate every other language, conceptually and in Common Lisp even in syntax.
For brackets I think my big problem is simply that because everything uses a relatively same syntax it makes things a lot harder to parse visually, and as such will never be quite as easy as if the syntax was different for different things. It's like if every single building in a town, houses, school, hospital, fire department, police station, was built out of the exact same color yellow brick with fairly similar layouts. Sure I could get a GPS and that would help me find what I wanted, but it would still never be as easy as if every house was built of blue brick, every school of green, every hospital of white, and so forth (though as noted that would lose me the ability to build, say, a red house as the expense of being able to more easily find a hospital when I needed one).
My experience is the exact opposite. I don't mean to say that Lisp necessarily is easier to read but rather that Lisp is not harder to read by design, but because you're used to something else.
Java to me has always seemed like a language that took the extreme utility that composes C/C++ and added just enough Python to it to lose all of the benefits that C/C++ provide, but not enough Python to actually gain the benefits of the easier syntax/etc. that Python provides. (The "run on anything" is kinda a nice feature, though).
"Run on anything" is not a feature of the language, it's only the fact that implementations exist for all major platforms. It assume Java doesn't run on TempleOS – just like most other languages.
Most languages don't require you to care how the hardware works, though. Your standard C++ compiler or PyPy or whatever will do most of the optimisations for you anyway, and that's assuming your program needs optimal performance in the first place.
So I don't think "Lisp doesn't require intimate knowledge of machine processes" makes much sense as an argument. Programming in Lisp is a different way of thinking, but it's not that different.
I think you are underestimating the difference between languages which can add syntax on the fly and languages which cannot.
I, personally, implemented objects with lazy evaluation of their slots and on top of that a library for Algebraic Data Types and pattern matching on those types. I can use these together with iterative syntax, object orientation, data flow programming, functional programming, imperative programming and whatnot, all in one language and if there's a feature I don't already have, there's probably a library out there or I can implement one myself, and it will probably only take a few hours to get a first usable version.
There's two valid criticisms of Lisp I can get behind, though:
1. The lack of maintained libraries.
2. Maybe another language compiles to faster code elsewhere.
The first is a problem of the community, not the language (but still a very real problem) and the second is a non-problem in most cases. At least Common Lisp can do quite a bit of non-obvious optimization, though, and as opposed to C and other languages like it these optimizations can be hidden away and made more readable via macros.
College is probably not doing a favor to Lisp languages, because they pretend as if Lisp was only functional programming because they want to use it to teach functional programming. It is not. It
supports functional programming. But you can do everything else in it, too, and for Common Lisp many of these things are even in the standard.
They should be using Haskell instead and use Lisp to teach macros.
Author
Topic: if self.isCoder(): post() #Programming Thread (Read 884565 times)