331–340 of 502 posts
Earlier quoted context omitted.
Seems only two of us here.
Perhaps the only two who still enjoy it. :) I'm working on the latest revision of a client's CF intranet app that been in use for fifteen years, now.
Earlier quoted context omitted.
You know, modern Fortran isn't awful. Fortran 77 code however, is frighteningly ugly to look at.
IMO, it's more than not awful , it's great! I wish I had picked it up sooner as a mid-level language for mathematical and scientific computing (over C++). Additionally, you can connect Fortran to Python dead simple with `f2py`.
It took me about a week to find out that the author of a model i worked on didn't know about `from copy import copy`, which explains a great deal about why their ODE solver wasn't working.
Many folks have said it here but I'll say it again: Common Lisp. I have been using it professionally for 5+ years as a full-time employee at various companies. Some big-name ones, some smaller start-up ones. The mean Lisp team size has been around 4, but I did work on a project of 15 Lisp programmers. None of these projects were legacy code. Some were in places you wouldn't expect (embedded, multi-processor systems o…
You mention several benefits, how many of those do you feel apply to all "lispy" languages, and how many are specific to Common Lisp [in your opinion]?
The one exception is maybe Clojure, but I find Common Lisp to be all around better at the problems I've worked on (namely ones where at some point or another, a native machine code compiler is required). Clojure' async/immutability story seems good for larger distributed systems, though, and interoperation with Java is invaluable to some projects. (Though, Common Lisp does have an implementation atop the JVM, called Armed Bear Common Lisp. This is one of the many benefits of an official language standard.) But by using Clojure you are definitely locking yourself into a single implementation.
Smalltalk. It's the "secret weapon" for a backend service. Allows fast mutability and is unbeatable at productivity and exploration.
Are you using a particular version? Pharo? Squeak? Commercial?
ColdFusion/CFML. All day, every day. Although a heavy dose of the newer hotness and the eventual migration of everything I work with off of it is in the works. Still enjoy working with it though. Very productive.
I am working on a new project in Django that is going to be interesting, so we'll see how that pans out.
Earlier quoted context omitted.
I find that clear notetaking is amazing in guiding discussions. Being the one who sends out the meeting summary with next actions and clarifying remarks or being able to refer back to meeting notes gives me an amazing power in making decisions or resolving disputes. Just because I'm the one who's writing stuff down, I'm somehow given the authority to say "this is what we decided at the meeting".
Absolutely! Can I ask if you are taking these nodes the old fashioned way with pen and paper or are you using a program to do this? I myself have found out that during meetings I prefer to use a pen and paper but it is mostly just notes that I take for myself.
The summaries always go out as emails, of course, and if I paper note-take, I try to take a picture and upload it to onenote or sharepoint.
SQL, bash,awk & sed
"PHP", It's not old, but it's not hip and plenty of people believe it deserves to die and has nothing to offer :-)
Tcl. It works really well as a cross-platform (*nix/Windows) alternative to shell scripting that doesn't suffer from the same problems as the POSIX shell (see http://www.dwheeler.com/essays/fixing-unix-linux-filenames.h... ). It builds on the same foundation of everything being text but with a few changes to the substitution rules builds something a lot like a Lisp on top of it.
Can it integrate with Unix command-line filters and tools roughly as well as shell can? Interested.
It can read/write stdin/stdout (just as any scripting language can) so it can be used to write additional filters/tools that don't exist in the standard set that can then be used from shell as with any other tool.
But if you mean using it to create a pipeline out of existing command line tools, then yes, but with a bit more boilerplate than plain shell needs. The built in "exec" command has an almost shell syntax for starting pipelines, and the "open" command supports the same syntax, so it is 98% "as well" in that regard. But to avoid getting stuck in a deadlock trying to write data to a pipeline that is returning filtered data to the script requires turning on Tcl's event driven file IO, which is where the extra boilerplate comes from.