Both are undergoing development
Both support hardware accelerated 2D out of the box
Both are licensed under the zlib license -- that's right, you are now free to statically link SDL to your programs
SFML is mostly supported by one developer, a much smaller team than the one behind SDL
SFML is only aimed at Windows/Linux/OSX for the moment, while SDL supports a much wider range of platforms
SFML 2.0 is pretty unstable at the moment, with the lead developer stating that he's prepared to completely break parts of the API prior to the 2.0 release
SDL 1.3 is probably pretty unstable as well
SFML has a much more friendly API than SDL, in my experience, although this is limited to usage of 1.2
Given my limited knowledge of SDL 1.3, I'm not sure which is the better library to side with. I originally jumped ship from SDL to SFML because of its friendlier API and hardware accelerated 2D graphics, but if SDL 1.3 is going to feature similar hardware acceleration along with a brisker, more reliable pace of development, my inclined to side with it. Can /prog/ convince me to pick a camp?
SFML is a free multimedia C++
That's all I need to know.
Name:
Anonymous2011-11-21 3:06
>>1
I'm evaluating SDL 1.3 and other libraries as well right now, for window management and OpenGL context setup for Linux and possibly FreeBSD support.
SDL 1.3 is pretty nice, but it comes with a lot of stuff I don't want, and disabling it with the autoconf script doesn't work (it still gets compiled in). I'm doing my own task-oriented parallelism and threading, and have better timers and asynchronous file io code.
I'm half-debating just doing a simple X11 wrapper for window management and user interface events, and using the Mesa EGL wrapper over GLX to handle interfacing with OpenGL. In the future, I may write a Wayland backend.
On Windows, OSX and iOS, I'm already using the native APIs behind my own abstraction layer, so I wouldn't be using SDL there anyway.
SDL also isn't very good at handling multiple output-adapters and lacks support for OpenCL.
Name:
Anonymous2011-11-21 3:19
Wise /prog/rider would choose the neither side.
Just create wrapper lib around both of these libs and use both of them, allowing advanced users to change lib(or using different lib on different platform)s. Just make config like
backend=backend_sdl.dll
>>6
Yes, wise /prog/lodytes prefer to make more work for themselves. Don't forget Allegro and XNA support.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 8:45
SDL 324kb dll
SFML 24000kb in 5 DLLs
The latter could be as fast as sepples allows it but adding twenty mb of bloat is not excusable for library which is a minimal layer over OpenGL
twenty mb of bloat twenty mb
Do they still use 56kbod modems in Russia?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 9:12
Speed of transfer isn't the problem, it just indicates there is alot of code for very little function.
Consider that for 24mb would be enough to contain entire DirectX 8.1(11.8 MB as full install),OpenGL(2mb with GLUT, all bells and whistles),3-4 sound libraries and still not reach even 20 mb.
>>10 it just indicates there is alot of code for very little function.
So what? Maybe it's infinitely decompressed or something, anyway, why do you care about functionality density per megabyte? Why is this a metric that one should strive to optimize?
I feel like you maybe read too many books which brainwashed you with patriarchal preconceptions.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 9:48
>>11
Its simply called bloat. I don't read books, i just see this library advertised as "fast and efficient".
Not to mention that SDL.dll does not include networking and audio, last time I checked.
Even if you were to include libsndfile-1.dll (325 120 bytes) and openal32.dll (208 896 bytes) for some reason, you would still be very far away from 20mb.
>>16 .a
Those are supposed to be statically linked into your program executable file and pruned by the linker. The actual size is much smaller.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:11
>>18
The post wasn't about them, its about the DLLs. The whole library is at 24mb of DLLs.
Name:
Anonymous2011-11-21 11:27
>>12 Its simply called bloat.
And why you say that as if it were something bad? I don't read books,
Then you got yourself brainwashed by something else. i just see this library advertised as "fast and efficient".
What's slow and inefficient about it?
>>13
well, that's kind of my point. You see people trying to create something under some artificial constraints. You can call it "art" or "intellectual masturbation", or whatever, that's OK, no problemo.
But if you forget about the fact that the constraints are artificial, then you get brainwashed by the semi-imaginary peer pressure which tells you that no "bloat" is good, because it's good, because look at how respected fr are, you should respect what respected people do and try to be respected as well, so stay away from the bloat! First rule of the no-bloat club: don't question why bloat is bad!
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:40
>>21
When logic fails a brainwashed individual, he resorts to an ad hominem, preferably one which implies that the interrogator belongs to them, the enemy which seeks to destroy the group to which the individual belongs.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 11:55
>>24
I don't have to prove that bloat is bad, it obvious that functionality which comes at lesser cost is better than one that comes at higher cost.
You can fiddle with gigabyte sapping, memory leaking VMs and gigantic libraries all day, that typical for AAA-class Enterprise Software Developers, its just not as efficient or elegant in terms of design as >>13
>>16
My bad; I realize now that you have the supplied pre-compiled DLLs that were built using MingW. Of course it's going to be bloated shit; don't blame SFML, blame the retardation that is MingW.
Name:
Anonymous2011-11-21 12:09
I don't have to prove that bloat is bad, it obvious
Heh.
that functionality which comes at lesser cost is better than one that comes at higher cost.
Define cost.
You can fiddle with gigabyte sapping, memory leaking VMs and gigantic libraries all day, that typical for AAA-class Enterprise Software Developers
Here we can see how brainwashed individual tries to further assert his ad hominem and the notion that the questioner belongs to a hostile class, which is why his questions are dangerous to even try to answer.
its just not as efficient
You must say that it is not as efficient three times, only then it will become true. Two times are not enough.
or elegant in terms of design as
Oh, yes, sure, it's not "elegant", it's not "beautiful", it's not a piece of art -- not something created under pointless constraints.
By the way, while we are at it, do you realize that we are discussing the size of the binary, not the source code? Not that it is terribly important, since your rinsed and dried brain blows fuses when it detects questioning of your silly beliefs either way.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:18
>>28
>not something created under pointless constraints
These are qualities of the software, have less size,less more use, more speed are not "pointless"
>CSFML is not C++ so using that supposed ``bloat'' as reason to pick on C++ makes no sense.
Thats exactly why its larger its filled with useless Sepples functions, which mingw compiles in.
Name:
Anonymous2011-11-21 12:25
>>29 These are qualities of the software, have less size,less more use, more speed are not "pointless"
I didn't think your brain would literally short-circuit, ha ha ha.
You poor creature, have you ever been as far as decided even do more like?
>>29
No, it's larger because MingW is a terrible compiler. Clearly you have never actually even bothered to build any windows executables with it or you would be familiar with that. What goes in the VC++ redistributables is pretty much statically linked into every MingW executable in existence and that is the reason it generates massive bloat. It being C++ or C has literally nothing to do with it.
Of course, IHBT since you clearly never even bothered looking at CSFML's source if you say things like its filled with useless Sepples functions.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:29
>>30
I don't think so, i meant to type 'less memory use', but missed a few keys.
Is memory use, size of program, speed of execution one of "pointless constraints"?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:33
>>31
>never even bothered looking at CSFML's source
I checked the DLLs in notepad, all are filled with thousands of Sepples functions at the end.
>>32 Is memory use, size of program, speed of execution one of "pointless constraints"?
Depends on the actual values. For instance, the difference between 20mb and 2mb used by an in-memory image of library on an 4Gb machine, for a 3d graphics application, is irrelevant, the 2mb memory consumption constraint is artificial, and spending any effort whatsoever to fit the library in the constrained space is pointless.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 12:59
>Depends on the actual values
I see you have some sense, now what would make a library less efficient? Having more size is just one of symptoms, bloated OOP abstraction
layers and generally unoptimized, low-quality code.
>spending any effort
The effect is multiplied by thousands of programs where programmer did not spend any effort. The next enterprise code monkey which is assigned to a program just wants the monthly banana for least effort and will be as lazy as the last.
I see you have some sense, now what would make a library less efficient? Having more size is just one of symptoms, bloated OOP abstraction layers and generally unoptimized, low-quality code.
You are speaking out of your anus.
In this particular case it was demonstrated to you that the "bloat" of the binary was not caused by any of these things.
Brainwashed people tend to ignore facts in favour of "ideologically correct" reasoning.
>>16
1, those are the C SFML bindings, not the default C++ ones.
2, you listed every possible version of the library there. Both the release and debug versions of both the static and dynamically linked libraries.
Can we ignore the impostor FrozenVoid now and get back to discussing the actual merits of SDL 1.3 and SFML 2.0?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-21 13:41
>those are the C SFML bindings, not the default C++ ones.
here are C++ bindings, i don't see how this improves the size
Directory of C:\download\SFML-1.6-dev-windows-mingw\SFML-1.6\lib
Worst case: 9 MiB of DLLs, plus some linking overhead should add around 10 MiB of overhead to your program.
Typical case: You use the static libraries and only the parts of SFML that you actually used are linked in. The overhead is a fraction of that of using the dynamic libraries.
In either case, SFML doesn't add enough overhead to your executable to impact distribution. Even the 9 MiB of DLLs (plus the libsndfile and openal DLLs) easily compress down to a 1.5 MiB 7z archive, or a 2.5 MiB zip archive.
I have beet rolled.
Name:
Anonymous2011-11-21 14:18
>>11,20,28
protip: processors aren't going to be getting faster for much longer, and same with storage densities increasing.
software, meanwhile, has gone farther and farther from the limits of efficiency. what you could do with 64KB in the 80s with a 10MHz CPU now takes megabytes or even gigabytes and gigahertz-level CPUs.
it's about time they realized how much waste has been going on.
>>45
We're all going to work for video games. Why else would we program?
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 1:51
>>46
For the art. If you lack that creative spark which drives you to program, you won't create programs, you would implement or rework existing ones.
Name:
Anonymous2011-11-22 2:55
>>47
Video games are the best art a programmer can make.
Name:
Anonymous2011-11-22 3:30
I, for one, welcome our new video game overlords.
Name:
Anonymous2011-11-22 4:17
Lisp OS should provide it's own graphics and audio API. Loading FFI libs is mediocre solution at best. Besides graphics and audio, everything else could be done internally. And we need better alternatives to ZLIB/PNG, because they arent the right thing. I.e. PNG doesnt support random access, meaning that things like http://en.wikipedia.org/wiki/MegaTexture cannot be easily packed into single PNG. PNG is also bad for sprites and GUI elements, which are frequently clipped, meaning no full decompression needed.
Sorry for a long rant. I just hate Worse is Better KISS solutions.
>>50
You will never amount to anything of significance.
Name:
Anonymous2011-11-22 6:18
>>53
My failure wont stop Unix/Linux from being a crappy OS.
Name:
Anonymous2011-11-22 6:38
>>50
Ever heard of the Single Responsibility Principle or Do One Thing And Do It Well?
Attempting to build file formats that handle a multitude of use cases will only amount to a format that is mediocre everywhere.
PNG, or Portable Network Graphics, has largely been successful at providing ``portable network graphics'' file format with lossy compression and adequate support for different pixel formats.
In fact, why would you even think about using PNG for textures, mega-textures, and the like outside of prototyping a game? PNG is a good intermediate format during development of a game, and provides an interchange container between the content creation tools and your engine's preprocessing tools. But in the context of game development, that's all it's meant for.
Generally, you set up your engine preprocessing tools to convert images to either raw or a special compressed format that your GP can decompress using specialized hardware at no cost, like DXTC/S3TC or PVRTC. That way, loading in a level's texture is super fast, you just do a single unbuffered POSIX read or Windows ReadFile call for the *entire* texture into a memory buffer and transfer it to the GPU using the relevant Direct3D/OpenGL call, no additional processing or decompression required.
It also results in simpler code and less bloated game binaries. All of the bloat and complexity is hidden in the preprocessing aka mod tools.
he wasn't questioning the sexuality of "ey" you fucking retard. It is no secret you are a feminist piece of shit.
Fuck off and die.
Name:
Anonymous2011-11-22 7:27
>>59
All lossless format can also be lossy because nothing prevents the encoder from changing the data in order to increase the compression efficiency.
Name:
Anonymous2011-11-22 7:56
>>55 Single Responsibility Principle or Do One Thing And Do It Well?
Yes. PNG is responsible for being slow and not allowing random access. PNG is also responsible for being a binary format, when sane people want symbolic expressions: you know, putting quickly object placement info into extension chunk, so one could use PNG for holding maps for a video game, which are also rectangular and compress well.
-> ls -ahl SDL-1.2.14.tar.gz SFML-1.6-dev-linux-32.tar.gz
-rw-r--r-- 1 matt users 3.9M Nov 22 05:53 SDL-1.2.14.tar.gz
-rw-r--r-- 1 matt users 713K Nov 22 05:55 SFML-1.6-dev-linux-32.tar.gz
The actual source of SFML is much less than SDL.
Name:
Anonymous2011-11-22 7:58
>>63 implying documentation, image files, configure and unit tests are actual source code
-> du -sh SDL-1.2.14/src/ SFML-1.6/
6.9M SDL-1.2.14/src/
2.2M SFML-1.6/
Here. The entire SFML directory is just source code because I didn't download the SDK. The /src directory in the SDL directory is 100% source.
3 times bigger.
Name:
Anonymous2011-11-22 8:05
>>59
It was a typo. I also meant ``GPU'' when I said ``GP''.
Name:
Anonymous2011-11-22 8:06
>>62 so one could use PNG for holding maps for a video game, which are also rectangular and compress well.
No, you don't get it. PNG was never meant for that, so stop wishing it did.
If you want that, create your own file format.
Name:
Anonymous2011-11-22 8:22
SFML is C++ crap, meaning it can be used only with that crap language. So it's totally useless.
>>77
It looks like C but that is all. Your code is valid in Java too, so should we say learning GLSL requires Java knowledge?
Name:
Anonymous2011-11-22 8:47
>>73
What if I dont believe in Set Theory? There are no standalone linear algebra book - all use some kind of "vector space over rational field" pseudoscience.
It's based on C! C99 to be specific, with extensions for vector processing/SIMD.
Man, you don't know shit.
And you don't need graduate level math in order to understand OpenGL. All you need is a basic understanding of geometry, trigonometry, and linear algebra. Linear algebra is so simple that you can teach it to kids in junior high school or perhaps earlier. Fuck, I taught it myself when I was 13 learning to do VGA demo coding in DOS with Pascal, C, and x86 assembly back in the early 90s. Are you admitting that you're more stupid than a kid who is just hitting puberty?
>>81 C99 will reject for(int i = 0;, because of int inside for.
Confirmed for retard. C99 does actually allow you to scope variable declarations within the for loop. Try it out. The following code compiles without error or warnings.
// $ gcc -Wall -Wextra -pedantic -std=c99 -o test test.c
#include <stdio.h>
int main() {
for (int i = 0; i < 5; i++)
printf("%d\n", i);
return 0;
}
>>87
I can smell your butthurt across my screen. Don't act smart if you are not.
Name:
Anonymous2011-11-22 9:17
>>79
Where ever you see "vector space over rational field," just replace it with "vector space over computable real field."
Linear algebra has nothing to do with infinity or non-computable reals. It's all about solving computable systems of linear equations. Your vector space could be over the whole numbers for all it cares.
x = 5y + 3
y = 3x + 4z + 2
z = 9x - 17
Solve for x. That's all linear algebra concerns itself with.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 9:19
If >>70 don't like OpenGL that much, i have to remind, software rendering is several orders of magnitude slower and there is no magic SSE hack which is "at the same speed as GPU" since GPU has thousands of fully parallel cores and CPU is limited to max 4-8 cores explicitly managed by the program(not by hardware,as in GPU parallel calculations). Software rendering is fit only for small, low-resource games and demos.
Perhaps when GPU features are merged into CPU die entirely the need for separate GPU will disappear, and OpenGL will become historical curiosity, but today isn't the year of integrated GPU(despite AMD efforts).
>>91
Indeed, the future of software rendering is on GPUs or the remnants of GPUs once they're fulling merged with CPUs. And graphics code will likely be done in OpenCL or DirectCompute or languages like them as they are sufficiently low-level and provide decent abstractions for tile/wavefront-oriented parallelism.
>>94
I hope Nouveau project finishes OpenCL support for Nvidia's cards soon.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 9:39
CPU makers are slowly waking up to the fact you can cram enough stuff on the die to make motherboards obsolete for real desktop systems
Like the design of system on a chip, all functions are merged into a single die which can be controlled by CPU maker exclusively.
>>94
Proper OpenCL 1.1 conformant drivers were completed by nVidia back in September, but had some performance problems. I can't remember if they've since fixed them... the drivers in the main repository for Linux Mint are still the September release, and I've been too lazy to bother manually installing the ones on nVidia's site.
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-22 9:50
OpenCL/DirectCompute are only beginning >>93 once its a CPU feature there will be a huge amount of asm and C apis you could not be locked
into a single model, since you on the level of the CPU opcodes which are standard(far more than locked, proprietary GPUs which require driver interfaces) you can write anything, you don't need to depend on a driver,a library or an API anymore(and construct your own from the vector opcodes).
I can't wait for those days. Hopefully Trusted Computing won't get in the way.
Name:
Anonymous2011-11-22 9:57
>>98
Yeah, but OpenCL/DirectCompute compilers are decent enough (most are based off of Clang/LLVM) and getting better, no reason to bother writing in assembly language. The vector intrinsics are sufficiently assembly-like already and usually have a one-to-one mapping with the underlying SIMD/SIMT/MIMD opcodes.
I don't see nVidia, AMD, Intel, ImgTech, S3, etc. all agreeing to a common ISA for programming GPU hardware any time soon, at least not this decade, so using a portable language will continue to make sense well into the future.
But you're right, the GPU/CPU memory model will at least be merged so you can just copy data around and pass pointers across CPU/GPU boundary and it will just work. That at least will make things easier.
>>99
Those days are already here, depending on your requirements.
I'm working on an OpenCL based voxel ray-caster and deferred shading renderer as a personal research engine. You won't be able to maximize hardware performance quite as good as if you were using OpenGL/Direct3D due to software driver inefficiences and hacks, but you can expect to be able to get around 75% through OpenCL currently.
Battlefield 3's renderer uses DirectCompute for it's deferred shading composition passes (although it still uses Direct3D pipeline to render polygonal geometry into the g-buffer).
Name:
Anonymous2011-11-22 10:09
>no benchmarks nope nope nope
Name:
Anonymous2011-11-22 10:46
>>90
Then why introduce "continuous spaces"? Why not just say that we deal with finite array of cubic voxels? Say (make-vector (* 1000000 10000000 1000000)) should be enough for all video game purposes. And it's proven to exist inside observable universe and it's easier to understand, because you can give real example - array of pixels on screen. But no! Instead of pixels algebra pseudoscience invents these retarded "infinitesimal" "points", that has nothing to do with JRPG video games.
Name:
Anonymous2011-11-22 10:52
>>105
BTW, beside spaces, they also introduce these "cyclic groups", which at first look like usual logical-and operator, but then it'll be reveled that they are fucking useless, cuz CPU's modulo operator doesnt work that way.
Name:
Anonymous2011-11-22 10:55
>>105
Because the Jews always have to find a way to stick their infinite sets into places where they don't belong. You should know that by now. It's like how Jewish politicians piggy-back their pork on completely unrelated legislation.
Linear algebra works quite fine without infinite sets. Matrices and vectors are just convenient notation. And as a formal system, it is comprised of simple algebraic identities, relationships and rules for managing, transforming and solving different aspects of linear systems of equations.
Name:
Anonymous2011-11-22 11:05
>>106
Cyclic groups are artifacts belonging to group theory, a sub-domain of category theory. It is quite divorced from ZFC.
It's not typically used much in computer games or graphics programming, but it does have relevance to repeating tiled or mirrored texture coordinate systems for repeating a texture across a wall or floor or something. Generally, modern GPUs have a builtin fmod circuit in each texture sampling unit for approximating the modulus of floating-point numbers, but older GPU hardware would internally convert floats to quantized fixed-point integers and use logical-and integer arithmetic.
That said, I don't see how you think they're completely useless. A CPU's modulo operator can and does work that way in an associative cyclic group.
Linear algebra works quite fine without infinite sets.
You're still a fucking stupid shit. This might be a bit too terse for you, but I'm going to take an example from work. Try and follow along you mental miget.
I have a data structure such that, when converted to a series of vectors, becomes an "infinite set". The reason why I want this data structure to be a series of vectors is because I'm interested in the cluster of data at any given point.
This cluster of data can be calculated by finding the eigenvalues of the corresponding matrices. And guess what? The fucking model relies on the notion of an infinite set.
>>109
Infinity is made-up bullshit, champ. It has no place in programming.
Name:
Anonymous2011-11-22 13:29
>>110
Ah yes, spoken like someone who never has, and probably never will work as a computer programmer. Did you even make it beyond high school calculus?
Name:
Anonymous2011-11-22 13:43
I dunno, but to make a final fantasy style game, one needs just a nice looking charset (rip these from rpgmaker games) and a reasonably fast blitting routine.
Name:
Anonymous2011-11-22 13:51
>>109
Sorry, you're wrong. You can represent non-computable reals, the continuum itself, in computer programs. It's impossible.
Name:
Anonymous2011-11-22 13:52
>>113
Damnit, I meant you can't represent non-computable reals, the continuum itself, in computer programs. It's impossible.
Name:
Anonymous2011-11-22 13:57
>>113
No you fucking stupid shit jew. You're confusing uncountable with countably infinite. Again, you're stupid. And again, you don't have the mental capacity to be a programmer.
So again, did your monkey ass even make it beyond calculus? I bet not.
>>115
Nope. And I believe you are the Jew. After all, they're the ones who conjured infinity out of the thin air along with their sky God who demands the blood of the goyim.
>>116
Computable numbers and countably infinite are'nt the same thing you fucking idiot. Again, did you make it beyond calculus? I bet not. Now go scrub another toilet you mental midget.
Name:
Anonymous2011-11-22 14:15
>>117
You're the one who said "countably infinite." I said "non-computable reals." I got an A+ in Calc 100 & 101, and without sucking any cocks like I know you had to. I then went on to take second and third year calculus courses and other courses on other subjects of mathematics, and have since graduated.
Infinitesimals merely encapsulate some interesting logical predicates in the form of consistent algebraic rules regarding asymptotic boundary conditions of recursive processes. If you've ever had to write code which computes transcendentals, derivatives or integrals in computers using numerical methods, you would know this.
Name:
Anonymous2011-11-22 14:20
If you've ever had to write code which computes transcendentals, derivatives or integrals in computers using numerical methods, you would know this.
Been there, done that. The point is, I don't think you have any clue as to what you're talking about when it comes to infinity. And again, I think you're fucking stupid.
>>118-119
There are such things as computable reals (they are also countable). There are of course uncomputable reals which cannot be touched by us in any way, except sometimes described (see: chaitin's constant as an example).
>>120
I still don't this this guy has any kind of real clue when it comes to the concept of infinity and it's relation to countability. Maybe this idiot should have taken to learn a real programming language like haskell instead of studying brain damaged shit like SICP...
>>130
It's great! But I will tell you, true independence comes from freedom, and freedom in today's ``dog-eat-dog'' world means job security. Apart from kodak_gallery_programmer who is a true master of actual and potential infinities, no one quite knows how I do what I do. But I do it, of that you can be sure!
>>140
Redditors adore bacon though (also blame corporations for making Americans fat with HFCS, also publicly hate on fat Americans hoping to pass for thin Europeans, also adore bacon).
Name:
Anonymous2011-11-26 23:57
>>138
Inferior jewish languages, like C/C++ and Pascal, are especially popular in russia, so there is a high chance he is slav, in a sense being slave to jews-khazars. Anyway, only beheading will clear him in a face of the one and only God, Creator and Sustainer of the universe, Who is similar to nothing and nothing is comparable to Him.
Name:
Anonymous2011-11-26 23:59
>>139
We mourn the death of Gaddafi at the hands of shabbos goyim infidels.
Four slots were filled by G. J. Sussman (Artificial Intelligence Laboratory, MIT) and a similar number by D. S. Wise (Department of Computer Science, Indiana University). Both belonged very much to the LISP subculture, neither of the two proved a single theorem, both showed too much and made such heavy use of anthropomorphic terminology that they were painful to listen to. Sussman's transparencies were printed, but overloaded; Wise's transparencies were handwritten, but very messy. Not used to Sussman's lecturing style - is it called "teaching by example"? - I found him very tiring to listen to; he spoke very fast but told very little, since he used most of his words to go in detail through a number of almost identical examples. Wise struck me as rather old-fashioned: he seemed to talk about the implementation of LISP in very much the same way as people did in the early sixties. LISP's syntax is so atrocious that I never understood its popularity. LISP's possibility to introduce higher-order functions was mentioned several times in its defence, but now I come to think of it, that could be done in ALGOL60 as well. My current guess is that LISP's popularity in the USA is related to FORTRAN's shortcomings. Edsger W. Dijkstra, Trip report, Newcastle, 19-25 July 1981, EWD798.
Name:
Anonymous2011-11-27 11:27
You probably know that arrogance, in computer science, is measured in nanodijkstras.
Alan Kay, keynote speech at OOPSLA 1997
Name:
F r o z e n V o i d !!mJCwdV5J0Xy2A212011-11-27 12:45
Despite having invented much of the technology of software, Dijkstra eschewed the use of computers in his own work for many decades. Almost all EWDs appearing after 1972 were hand-written. When lecturing, he would write proofs in chalk on a blackboard rather than using overhead foils, let alone Powerpoint slides. Even after he succumbed to his UT colleagues’ encouragement and acquired a Macintosh computer, he used it only for e-mail and for browsing the World Wide Web.