C/C++:
int folderP(char *Name) {
DIR *Dir;
struct dirent *Ent;
if(!(Dir = opendir(Name))) return 0;
closedir(Dir);
return 1;
}
int fileP(char *Name) {
FILE *F;
if (folderP(Name)) return 0;
F = fopen(Name, "r");
unless (F) return 0;
fclose (F);
return 1;
}
Name:
Anonymous2012-03-08 5:27
You can have very fine grained low level control in C and C++. Which Lisp dialect permits this and also integrates with existing libraries of code (so you can spend time on the important stuff and not reinventing the wheel)?
>>5
Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Any sufficiently complicated CL or Scheme program contains an ad hoc, informally-specified, bug-ridden, slow implementation of a mental midget neocortex.
sorry, yes, dealing with file and folder horseshit is the definition of systems programming. why do i even have to think about this old timey nonsense. can't we just rub ipads together to exchange vital info, u queer
>>14
I thought dealing with hardware was the definition of systems programming. Are we all sucking the cock of the Google Goverlords now? Guess it's time to take down the GJS pinups on my ceiling and pucker up for Pike and Thompson.
Name:
Anonymous2012-03-08 12:40
>>16
Not really. Systems programming is all about nerdy daemons, networking, security and what not.
>>6
Any sufficiently complicated Common Lisp or Scheme program contains an ad hoc, informally-specified, bug-ridden, slow implementation of macro-based DSLs.
>>16
Systems programming encompasses all forms of programming involved in building or maintaining a platform (or system) for applications to run on. It is a superset of both interaction with hardware and operation of daemons, among other topics.
C++ to memory map pointerless c structs of your data and then access that from the common lisp foreign data access.
the struct field complies down into 2 instructions and so there's no performance penalty to accessing C instead of common lisp objects.
the lisp garbage collector will never see the data, each pointer to a c object is simply a fixnum and you only ever have to wrap it in lisp to improve debuggability
to allow the lisp to compile into efficent assembly, you can use lots of macros but avoid closures, generics and fancy sequence functions.
>>21
Where are you off to, exactly? Perhaps a thread on /prog/ that isn't a troll thread and is instead filled with insightful discussion about programming?
>>22
>the struct field complies down into 2 instructions and so there's no performance penalty to accessing C instead of common lisp objects.
There is no perfomance penalty accessing defstruct fields.
Name:
Anonymous2012-03-09 2:44
Common Lisp is diarrhoea.
Lisp is shit.
Everything is worse.
>>29
lisp is far too powerful for you.
you could not understand it if you tried
Name:
Anonymous2012-03-09 16:04
>>31
I understand Lisp, so I also understand why almost every Lisp I've encountered so far isn't a proper Lisp.
Name:
Anonymous2012-03-09 17:27
C and C++ aren't enough. Even D isn't enough. It's time for the new lagrange, D++.
Also known as ``Say it. Out loud.'' ``Dubbles.''
Name:
Anonymous2012-03-09 17:38
please use javascript for this type of work, ``thank you!''
Name:
Anonymous2012-03-09 18:33
Despite being having a third of the number of lines, the lisp code still manages to have more brackets than the c code. We don't do system code in lisp because everything soon turns into a clusterfuck of brackets.
Name:
Anonymous2012-03-09 18:40
>>35
If LisP proqrammers new how to fuqing indent they're code, we would don't have this proqlem¡